O spec driven development resolveu o problema de agentes que escrevem código sem saber o que deveriam estar construindo. O agente recebe uma especificação com requisitos, restrições, critérios de aceitação e um plano de implementação, e produz código que cumpre o contrato descrito na spec. Nas implementações que tenho acompanhado em pipelines com múltiplos agentes, a questão que fica em aberto é como saber se a spec descreve o comportamento correto antes que o agente comece a implementar. Nenhum artefato do fluxo convencional confirma que as premissas da spec estão certas, que as restrições são suficientes ou que os critérios de aceitação cobrem os caminhos de falha reais do sistema.
Os critérios de validação devem vir antes da spec de implementação. A inversão é a mesma do TDD clássico: o teste define o resultado esperado e a implementação existe pra satisfazê-lo. No spec driven development, o artefato intermediário entre a intenção e o código é a spec, o que significa que os testes precisam validar não apenas o código, mas a própria spec. Testes convencionais executados depois da implementação capturam erros de execução, entretanto ignoram erros de especificação. Se o agente implementa corretamente uma spec que descreve as condições erradas, o teste passa e o sistema falha. Só que agora com a falsa certeza de que foi "testado".
A Anthropic publicou no blog de engenharia uma abordagem pra evals de agentes que parte de uma premissa prática: uma boa tarefa de avaliação é aquela em que dois especialistas de domínio chegariam independentemente ao mesmo veredito de aprovação ou reprovação. A definição descreve, no fundo, um critério de conduta observável com consenso verificável, e me parece igualmente aplicável a evals de spec. Traduzida pra specs, a regra seria algo como: cada critério de aceitação deve ser formulado de forma que dois engenheiros, lendo a spec sem contexto adicional, concordem sobre se determinado resultado atende ou não. Critérios de aceitação que dependem de uma interpretação que não está claramente definida na spec geram divergência entre a leitura do agente e a do eval, produzindo um sistema que parece testado enquanto carrega ambiguidades não resolvidas.
Simplesmente dizer ao agente pra testar não basta. É preciso dar a ele um mapa explícito de quais condições validar e contra quais critérios. O TDAD (Test-Driven Agentic Development), publicado no arXiv e submetido ao Benchmark & Dataset Track do ACM AIWare 2026 (conferência da ACM sobre software e IA, realizada junto com a FSE), demonstrou isso. O TDAD faz uma análise de impacto pré-mudança: cruza o grafo de dependências entre código e testes pra que o agente saiba quais verificações rodar antes de submeter um patch. No SWE-bench Verified a taxa de regressão caiu 70% (de 6,08% pra 1,82%). O dado mais interessante é o controle, creio. Quando os pesquisadores adicionaram instruções genéricas de TDD ao prompt sem indicar quais testes rodar, a mesma taxa subiu pra 9,94%, acima do baseline sem nenhuma instrução. Ou seja: fornecer uma orientação vaga produziu mais regressões do que não fornecer nenhuma orientação.
Esse mapa serve como uma spec de validação aplicada a testes que já existem: identifica quais deles podem ser quebrados por um patch. O fluxo que tenho sugerido em projetos de SaaS com agentes de codificação leva a ideia adiante e inverte a ordem convencional: o primeiro artefato é um conjunto de evals que descrevem as saídas esperadas do sistema, as condições de contorno e os modos de falha conhecidos. A spec de implementação é escrita contra esses evals e o agente implementa pra cumprir a spec. Se o código falha em um eval, a primeira investigação é sobre a spec, até porque as falhas de premissa em sistemas agênticos são frequentes e caras.
O Kiro (o IDE da AWS) e o GitHub Spec Kit representam o estado atual da prática de SDD. O Kiro já converte propriedades da spec em testes executáveis via property-based testing, como descrevi no post sobre specs executáveis. Nos dois casos, porém, os testes derivam da spec. Quando a spec contém uma premissa errada, o teste herdado termina por validá-la, ao invés de contestá-la. A lacuna que canso de apontar é de ordem e não de ferramental: falta um eval que rode antes da spec pra confirmar que as premissas estão corretas antes de virarem testes.
Fechar essa lacuna exige tratar o eval como o primeiro artefato do ciclo, e não como subproduto da spec. Specs escritas em função de evals que já existem herdam a precisão dos critérios, sem a ambiguidade que vem de requisitos formulados sem uma restrição clara de verificabilidade. Mas pra escrever evals antes da spec o time precisa saber o que esperar do sistema antes de saber como implementá-lo. Já vi essa inversão incomodar times acostumados a descobrir o escopo durante o desenvolvimento, mas isso nem é novidade. Falhas de premissa que aparecem antes da primeira linha de código custam minutos. As outras custam sprints. Ou empregos.