Três formas de instruir um agente de programação: spec, modelo de produto ou revisão com olhos novos

Um agente de programação que entrega a coisa errada geralmente entendeu o pedido e não entendeu o produto. A pergunta interessante no fim de 2026 não é mais qual agente usar, mas como instruí-lo, e surgiram três respostas distintas. Elas divergem em um ponto: o que você registra por escrito e por quanto tempo isso vive.

Guiada por spec: um documento por mudança

A abordagem mais adotada escreve uma spec para cada funcionalidade, depois um plano e uma lista de tarefas, e faz o agente construir com base neles. O Spec Kit (4,3) é a versão do GitHub, com cerca de 143.000 estrelas e uma etapa de convergência que confere a implementação com os documentos; ele é compatível com mais de 40 agentes nomeados. O BMAD-METHOD (3,8) cobre terreno parecido com um elenco de personas. O ponto forte é que o contrato vive no git e passa por pull requests como código. O custo é o tempo de leitura: o teste publicado pela Scott Logic estimou a revisão humana em cerca de duas a três horas e meia por funcionalidade, e é por isso que as duas ferramentas oferecem caminhos mais leves para correções pequenas.

Guiada pelo produto: um modelo permanente

Uma escola mais nova argumenta que uma spec descreve a mudança, não o produto, e assim o produto vive sendo reconstruído do zero. O pdd-kit (3,7) mantém um único modelo de produto versionado no git, com entidades, jornadas, regras de negócio e variações, que todo agente lê em vez de adivinhar, com uma etapa de verificação que confere o código com ele. É uma ideia mais afiada que uma pasta de specs, mas ainda é cedo: cerca de 97 estrelas e um único mantenedor, e um modelo que fica para trás em relação ao código engana mais os agentes do que modelo nenhum. Ele compensa em produtos com complexidade de domínio real, e não em um app CRUD.

Revisão primeiro: deixe olhos novos acharem os buracos

A terceira abordagem aceita que o agente que redige vai deixar passar seus próprios pontos cegos e traz um revisor que nunca viu a conversa. O Elephant-Goldfish Model (4,2), um plugin de código aberto do Google, redige um design com um agente de contexto profundo (o Elephant) e depois o entrega a subagentes sem contexto (os Goldfish) que leem só o documento e as fontes citadas. Como não podem se apoiar no chat que produziu o design, eles trazem à tona as premissas não ditas. O método é bem argumentado e já tem cerca de 6.500 estrelas; o porém é que ele precisa de um harness capaz de criar subagentes novos, e ele para em vez de fingir uma revisão quando não consegue.

Onde entram os pacotes de fluxo de trabalho

Ao lado disso ficam instaladores de fluxo de trabalho gerais como o Superpowers (4,7), que dão ao agente hábitos de planejamento e autoverificação sem impor um formato de spec. Eles se combinam com qualquer um dos três estilos de instrução em vez de competir com eles, e são o ponto de partida que exige menos esforço.

Qual usar

Para uma correção de uma linha, nada disso: o git, os testes e um prompt curto que nomeia os arquivos vencem. Para uma funcionalidade que exige decisões de design antes do código, a revisão primeiro pega mais bugs reais com menos escrita, desde que o seu agente aceite subagentes. Para uma mudança regulada que um auditor vai ler depois, o rastro documental da abordagem por spec é justamente o objetivo. E para um produto complexo em que os agentes vivem reinventando as mesmas regras, um modelo de produto compensa a manutenção, se, e somente se, alguém o mantiver atualizado.