From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents
Este artigo introduz uma taxonomia de processo e uma rubrica de pontuação de seis dimensões para avaliar comparativamente seis frameworks emergentes de desenvolvimento de software de IA, revelando uma convergência em direção a artefatos persistentes e revisão humana, ao mesmo tempo em que destaca um compromisso estrutural entre profundidade de processo e portabilidade, juntamente com riscos críticos como deriva de especificação e dependência de plataforma.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você contratou um aprendiz brilhante e hiperveloz para ajudá-lo a construir uma casa. Este aprendiz é um agente de codificação de IA. No passado, você poderia apenas gritar: "Construa uma parede para mim!" e torcer pelo melhor. Às vezes a parede ficava ótima; outras vezes, ficava torta, feita com os tijolos errados ou construída no lugar errado.
Este artigo argumenta que simplesmente gritar instruções (prompts) não é mais suficiente. Precisamos de frameworks — que são como livros de regras detalhados, plantas e sistemas de gestão — para guiar esses aprendizes de IA. O autor, Sanderson Oliveira de Macedo, analisou seis "livros de regras" populares atualmente usados na indústria para ver como eles organizam o trabalho.
Aqui está um detalhamento das descobertas do artigo usando analogias simples:
1. O Problema: De "Gritar" para "Gerenciar"
Nos velhos tempos, você falava com a IA uma frase por vez. Era como jogar um jogo de "telefone sem fio", onde a mensagem se perde. A IA esquecia o que você disse cinco minutos atrás ou inventava fatos (alucinação).
O artigo diz que estamos mudando para uma nova era onde a IA não apenas conversa; ela trabalha. Ela planeja, edita arquivos, executa testes e corrige seus próprios erros. Mas, sem um gerente, esse trabalhador autônomo pode se tornar caótico. Os "frameworks" que o artigo estuda são os gerentes que dizem à IA:
- O que construir (Especificação).
- O que ela já sabe sobre o projeto (Contexto).
- Quem está fazendo o quê (Papéis/Roles).
- Como construir (Execução).
- Como verificar se está correto (Validação).
- Se ela pode trabalhar em diferentes canteiros de obras (Portabilidade).
2. Os Seis Livros de Regras (Os Frameworks)
O autor escolheu seis "livros de regras" específicos para comparar. Pense neles como diferentes estilos de gestão:
- GitHub Spec Kit & OpenSpec: Estes são como arquitetos. Eles insistem que você escreva uma planta perfeita (uma especificação) antes que a IA assente o primeiro tijolo. Eles focam intensamente no plano e podem trabalhar com muitas ferramentas de IA diferentes.
- Método BMAD: Este é como um departamento de RH corporativo. Ele divide o trabalho em papéis específicos (Gerente de Produto, Arquiteto, Desenvolvedor, QA) e atribui à IA o papel de atuar como essas diferentes pessoas. É muito estruturado, mas pode ser pesado.
- Get Shit Done (GSD): Este é como um assistente pessoal que trabalha apenas para um chefe específico (uma ferramenta de IA específica). É ótimo para organizar a memória e o foco da IA, mas não é muito flexível se você quiser trocar de chefe.
- Spec Kitty: Este é como um canteiro de obras com cercas de segurança. Ele isola o trabalho da IA em uma área separada (um "worktree") para que ela não possa acidentalmente quebrar o edifício principal. Ele força um humano a inspecionar o trabalho antes que ele seja mesclado.
- Reversa: Este é o engenheiro reverso. Em vez de construir uma casa nova do zero, ele olha para um edifício antigo e decadente (código legado) e tenta descobrir as plantas originais para que a IA possa consertá-lo.
3. A Grande Descoberta: O Trade-off "Não Existe Almoço Grátis"
A descoberta mais importante do artigo é que nenhum livro de regras único é perfeito.
O autor criou um sistema de pontuação (uma rubrica) para avaliar esses frameworks. Aqui está a analogia:
- Alguns frameworks são como Canivetes Suíços: São leves, portáteis e funcionam em qualquer lugar, mas não possuem uma ferramenta profunda e especializada para cada tarefa. São ótimos no planejamento, mas fracos na verificação do trabalho.
- Outros frameworks são como Guindastes de Construção Pesada: São incrivelmente poderosos, possuem verificações de segurança rigorosas e processos profundos, mas são difíceis de mover e só funcionam em locais específicos.
O Trade-off: Quanto mais profundamente um framework gerencia o processo (verificando cada etapa, atribuindo papéis), mais difícil é mover esse framework para uma ferramenta de IA diferente. Você não pode ter o processo mais profundo e a facilidade de portabilidade ao mesmo tempo com as ferramentas atuais.
4. Os Perigos Ocultos (Riscos)
O artigo também alerta sobre "perigos no canteiro de obras" que esses frameworks ainda não resolveram totalmente:
- Drift (Desvio): A planta (especificação) pode dizer "tijolo vermelho", mas a IA constrói uma "parede azul" de qualquer maneira, e ninguém percebe até que seja tarde demais.
- Confiança Cega: Podemos confiar demais no trabalho "finalizado" da IA, mesmo que pareça bom, mas esteja tecnicamente quebrado por baixo.
- Extensões Frágeis: Esses frameworks frequentemente dependem de complementos feitos pela comunidade. Se a pessoa que fez o complemento parar de atualizá-lo, todo o sistema pode quebrar.
- Lock-in (Aprisionamento): Alguns frameworks estão tão ligados a uma ferramenta de IA específica que, se essa ferramenta mudar suas regras, todo o seu processo desmorona.
5. O Que Vem a Seguir? (A Agenda de Pesquisa)
O artigo conclui que estamos atualmente na fase do "Velho Oeste". Temos ferramentas legais, mas não temos dados suficientes para saber qual delas realmente funciona melhor a longo prazo.
O autor sugere que precisamos parar de apenas mostrar demonstrações legais e começar a fazer ciência real:
- Medir as etapas intermediárias: Não verifique apenas se o código final funciona; verifique se o plano da IA e a planta foram bons.
- Testar a memória: A IA está realmente lendo os arquivos certos ou está apenas adivinhando?
- Observar as equipes: Ver como as equipes humanas reais performam ao longo de meses, não apenas de dias.
Resumo
O artigo é um mapa do cenário atual das ferramentas de software de IA. Ele nos diz que, embora tenhamos passado de "conversar com a IA" para "gerenciar equipes de IA", ainda não encontramos o gerente perfeito. Temos que escolher entre ferramentas que são flexíveis e fáceis de mover, ou ferramentas que são profundas e rigorosas, mas difíceis de trocar. O futuro reside em construir melhores maneiras de medir se essas ferramentas estão realmente tornando o software melhor, e não apenas mais rápido.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.