Spec driven development: quem confere no fim?

Clonei o repositório do Spec Kit da GitHub e contei a prosa dos nove comandos que ele instala, separando cada um por uma pergunta só: essa instrução é lida antes ou depois de o código existir? A conta demorou menos do que escrever este parágrafo, e a assimetria saiu mais limpa do que eu esperava encontrar em qualquer coisa do mundo real.

São 13.647 palavras de instrução antes de haver uma linha de código, contra 1.764 depois. Em passos numerados, a distância é a mesma: 830 antes e 67 depois.

Comando	Quando roda	Palavras	Passos
constitution	antes	1.386	69
specify	antes	2.436	152
clarify	antes	2.658	165
plan	antes	1.065	59
tasks	antes	1.594	103
analyze	antes	1.546	81
checklist	antes	2.962	201
implement	escrevendo	1.671	114
converge	depois	1.764	67

A contagem é simples de repetir e vale conferir: os prompts moram em templates/commands/ no repositório github/spec-kit, um arquivo markdown por comando, e o que eu contei foi palavra de corpo depois do frontmatter mais linha que começa com número ou marcador. A classificação de cada comando não é minha opinião — está escrita no próprio prompt, e volto nisso mais adiante.

O Spec Kit é o melhor caso, e ainda assim é sete por um

O spec driven development tem hoje pelo menos duas linhagens grandes, e a do Spec Kit é a que leva mais a sério a pergunta do título, porque ela é a única que instala um comando cuja função é conferir o código entregue contra a especificação.

A outra linhagem nasceu do RPI, sigla de research, plan e implement, que saiu da HumanLayer em 2024 e foi adotada por ferramentas como o Goose. Em 2026 o próprio autor aposentou o método e publicou a sucessora, CRISPY, com sete etapas: questions, research, design, structure, plan, work, pull request. Em paralelo, outro autor publicou a QRSPI, com cinco.

Nenhuma das duas sucessoras tem etapa de conferência, e isso não é leitura minha nas entrelinhas: a documentação do CRISPY não descreve estágio dedicado de verificação, e a da QRSPI diz que foca em melhorias a montante em vez de validação a jusante.

As cinco etapas novas do RPI ficaram todas antes do código

Repare no que foi acrescentado quando o RPI cresceu. Questions, design e structure na versão da HumanLayer; questioning e structure na outra. Cinco etapas novas em dois anos, e todas elas acontecem antes de existir uma linha de código, o que faz sentido, porque os problemas que elas resolvem também acontecem antes.

A HumanLayer documentou esses problemas com uma franqueza que é rara e que vale registrar: a pesquisa misturava objetivo com detalhe de implementação e perdia objetividade, os passos de alinhamento eram pulados de forma probabilística, e os engenheiros acabavam revisando planos de mil linhas que divergiam com frequência da implementação que saía do outro lado. Eles também contam que passaram seis meses sem ler o código gerado e tiveram que arrancar e refazer partes grandes do sistema.

O orçamento de instruções é finito, e a HumanLayer mediu

A parte que amarra tudo é uma medição que a própria HumanLayer publicou: modelos de fronteira seguem com confiabilidade entre 150 e 200 instruções, e só o prompt de planejamento do RPI tinha 85, de modo que somando o prompt de sistema e a definição das ferramentas os times estouravam o orçamento antes de começar, e em metade das vezes o modelo pulava direto para escrever o plano completo, sem a conversa de alinhamento que era o ponto inteiro da etapa.

Coloque as duas medições lado a lado e sai uma conclusão desconfortável. Toda etapa acrescentada antes do código disputa o mesmo orçamento finito, de modo que consertar uma falha de montante acrescentando etapa de montante gasta justamente o orçamento de que a etapa pulada precisava. O RPI estourava o limite com três fases. A resposta foi publicar uma versão com sete.

Não é que o remédio esteja errado; é que ele é servido no mesmo copo que já estava cheio.

O que a GitHub documenta e quase ninguém cita

Voltando à classificação dos nove comandos, que eu disse que não era opinião minha. O prompt do converge diz que ele precisa rodar somente depois do implement. E o do checklist, que é o maior de todos com 2.962 palavras, avisa em negrito o que ele não faz:

❌ NOT checking if code/implementation matches the spec

E explica, com uma imagem que eu acho ótima: se a sua especificação é código escrito em inglês, o checklist é a suíte de testes unitários dela, e você está testando se os requisitos estão bem escritos, completos e sem ambiguidade, e não se a implementação funciona.

A ferramenta separa as duas coisas com todas as letras. A conversa pública sobre o método, que mede custo de cerimônia e discute quantidade de arquivo, quase nunca separa.

Por que a convergência é a etapa mais barata

A convergência, que é o nome que o Spec Kit dá a conferir o código entregue contra a especificação e que a Microsoft chama de validate no ciclo dela, tem uma propriedade que nenhuma etapa de montante tem: ela roda depois, em contexto novo, com o código já escrito na frente.

Ela não disputa o orçamento de instruções do planejamento, porque não está na mesma janela. Não precisa antecipar o que vai dar errado, porque o que deu errado já está no disco. E o artefato contra o qual ela compara não é uma previsão, é um arquivo.

Pelas 1.764 palavras que ela custa no Spec Kit, é a etapa mais barata do método inteiro, e é justamente a que as duas metodologias mais discutidas do campo não têm.

O que dá para medir no seu próprio processo

A pergunta que essa contagem deixa é fácil de repetir em qualquer ferramenta, inclusive nas caseiras. Pegue o seu processo, liste as etapas, e separe cada uma pela mesma pergunta: ela é lida antes ou depois de o código existir? Depois some a prosa dos dois lados.

Se a razão for parecida com sete por um, você está na média do campo. Se não houver nada do lado de depois, você tem um método que escreve promessa e nunca cobra, e a diferença entre os dois aparece exatamente no dia em que a especificação estiver errada.

Fontes

Os números deste texto vêm daqui, e os dois primeiros dão para conferir em minutos:

• A contagem dos prompts é minha, feita em 11/09/2026 sobre github/spec-kit, diretório templates/commands/.
• O limite de 150 a 200 instruções, os modos de falha do RPI e a passagem para CRISPY: HumanLayer, via ZenML.
• A evolução paralela para QRSPI: betterquestions.ai.
• O ciclo de sete passos da Microsoft, terminando em validate: developer.microsoft.com.
• Sanderson Oliveira de Macedo. From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents. arXiv:2606.04967 — compara sete frameworks e encontra divergência em processo com convergência em critérios de aceite, cenários de teste e contexto.