O Gênio e o Contrato

Um gênio imprevisível

Kent Beck passou cinco décadas defendendo que os testes devem vir em primeiro lugar. Por isso, vale a pena observar como ele descreve os agentes de codificação de IA com os quais trabalha atualmente: um “gênio imprevisível” que realiza seus desejos, muitas vezes de maneiras literais e inesperadas. Você pede algo. E recebe. alguma coisaSe aquilo era realmente o que você precisava, é uma questão à parte.

Na mesma conversa, Beck chama o TDD de "superpotência" com esses agentes, porque eles introduzem regressões constantemente e um conjunto de testes é a maneira mais barata de detectá-las. Mas ele também deixa escapar um detalhe que deveria lhe fazer refletir: ele tem dificuldade em impedir que os agentes de excluindo os testes para que eles passem. Os testes servem tanto como defesa quanto como alvo de manipulação — esse é o problema em questão.

Uma breve explicação sobre os termos, pois uma dessas siglas é usada de forma imprecisa. TDD é a disciplina mais antiga: primeiro escreva um teste que falhe, depois escreva apenas o código necessário para que ele passe, organize o código e repita. SDD é a mais recente: documente o que você está construindo como uma especificação técnica estruturada — as formas da API, os modelos de dados e os critérios de aceitação — e trate esse documento como o contrato que o código deve cumprir. O importante é que SDD é uma prática, não um produto. Kit de especificações do GitHub é uma ferramenta que facilita a adoção e é o exemplo usado em todo o texto — mas tudo aqui se aplica a qualquer configuração de SDD. (Também não é o mesmo que orientado para a história desenvolvimento, que funciona no nível mais flexível das histórias de usuário e se relaciona com o TDD de forma diferente.)

Por que nenhum dos dois sobrevive sozinho ao gênio?

Execute o SDD isoladamente e o significado se perde: o agente forma sua própria interpretação de uma especificação ambígua e constrói algo internamente consistente que ainda assim não capta o que você pretendia, porque a prosa não pode ser executada e nada força o código a retornar às palavras. Execute o TDD isoladamente e você obterá o oposto — código que passa nos testes apresentados e nada mais, sem nenhuma especificação para dizer o que esses testes fizeram. rede de apoio social assert, então eles acabam codificando o que quer que o agente tenha decidido construir. De qualquer forma: marcas de seleção verdes, alvo errado.

O motivo para combiná-los não é que ambos sejam bons. É que A especificação e o teste são duas codificações independentes da mesma intenção. — uma legível por humanos, outra executável por máquina — e cada uma cobre o ponto cego da outra. A especificação dá ao teste uma razão de ser, para que o conjunto de testes não seja apenas um reflexo do código. O teste dá força à especificação, para que o agente não possa reinterpretar silenciosamente o texto.

Um painel de especificações à esquerda e um painel de testes à direita apontam para um agente central, enquadrando-o por dois lados.

Uma espinha dorsal, dois portões, uma borda de feedback

O diagrama abaixo mostra o formato. Uma pessoa define a intenção; Spec Kit's specify e plan Os comandos transformam isso em uma especificação e um plano; uma pessoa os revisa — como um ponto de verificação, não como algo definitivo. Três detalhes determinam se isso realmente funciona na prática.

Primeiro, analyze Executa antes de qualquer código. É uma verificação de consistência somente leitura entre especificações, planos e tarefas. O instinto é deixá-la para o final, mas o Spec Kit seu próprio guia de início rápido é explícito que a primeira passagem pertence antes implement, enquanto as lacunas ainda são baratas de corrigir. Execute novamente depois como uma revisão de desvios, se quiser — mas a passagem que suporta a carga é aquela anterior à gravação da linha pelo agente.

Segundo, uma pessoa é dona do teste de aceitação — a próxima seção explica o que isso significa. Terceiro, o agente constrói em fatias verticaisUm pequeno trecho de comportamento analisado de ponta a ponta — um único teste com falha, apenas o código necessário para aprová-lo, uma limpeza e, em seguida, a próxima etapa — em vez de gerar todo o conjunto de testes antecipadamente ou emitir centenas de linhas de uma só vez, o que produz um código aparentemente plausível que apresenta falhas que ninguém consegue localizar. E o código só é mesclado quando os testes são aprovados, o conjunto de testes foi verificado para confirmar que realmente detecta bugs e os testes confirmados não foram editados para forçar a aprovação.

Um pipeline vertical que vai da intenção humana a um ponto de fusão, com a análise como um ponto de pré-código, um teste de aceitação somente leitura de responsabilidade humana, um loop de código de fatiamento vertical e uma aresta de feedback do loop de volta para a especificação.

Quem vigia os guarda-corpos?

É fácil imaginar isso como um fluxo organizado de “especificação → teste → código” e parar por aí. A verdadeira engenharia está nos modos de falha — e todos eles se reduzem a uma pergunta: se o agente escreve a especificação, escreve os testes, e Quem escreve o código, afinal, o que está sendo verificado?

Quem decide o que significa "correto"?

Se um único modelo escrever os três — a especificação, os testes e o código — todos compartilharão o mesmo ponto cego. Uma única interpretação errônea da intenção resultará em uma especificação que codifica essa interpretação errônea, testes que a reforçam e um código que os passa. Tudo parece verde; tudo está errado. As duas codificações “independentes” só permanecem independentes se Uma pessoa possui pelo menos uma delas — algo que o agente não pode alterar discretamente.

O melhor artefato para se atribuir a uma pessoa é o teste de aceitação — o teste que afirma: “esta funcionalidade está concluída e se comporta corretamente”. Uma especificação escrita em prosa pode ser seguida à risca, mas ainda assim violada em sua essência; um teste é uma afirmação concreta, de aprovação ou reprovação. Ser o responsável não significa que uma pessoa redija à mão cada afirmação — o agente pode elaborar os testes. Significa que uma pessoa os revisa, aprova o que eles afirmam e se responsabiliza por eles. antes que se tornem o padrão pelo qual o código é avaliado, em vez de permitir que o mesmo agente gere e combine silenciosamente os seus próprios. Em termos de teste, o teste de aceitação é o seu oráculo: o elemento que decide se o código está correto. Como outros que trabalham nisso já descobriram, Os testes controlados por humanos são a última linha de defesa. — porque sob pressão, o instinto do agente é excluir um teste com falha em vez de corrigir o código. Se o agente puder editar o oráculo, não haverá oráculo.

Green é um proxy, e proxies são manipulados.

A frase “O agente não pode prosseguir até que o teste seja aprovado” soa como uma garantia. Mas não é. Existem muitas maneiras de fazer um teste passar sem, de fato, satisfazer a intenção: enfraquecer o que ele verifica, ignorá-lo, substituir o componente real por um stub, codificar a resposta esperada diretamente no código, suprimir o erro — ou simplesmente reescrever o teste. O problema é o clássico: no momento em que “fazer os testes passarem” se torna o objetivo, passar nos testes deixa de ser um sinal confiável de que algo funciona.

Isso não é hipotético. O Aider — um agente de codificação de linha de comando popular e uma escolha razoável para o ciclo de compilação — irá, por design, [fazer isso]. Os testes de edição que ele considera incorretos estão errados. Em vez de forçar o código a se adaptar a eles. Isso é realmente útil quando uma pessoa está dirigindo; é uma falha quando o agente está rodando sozinho. Então, como impedir que o agente burle o sistema? Duas defesas fazem a maior parte do trabalho — e uma contagem bruta de aprovações/reprovações não é nenhuma delas.

O que os testes não conseguem dizer

Os testes unitários respondem a uma pergunta específica: esta função faz o que eu disse, isoladamente? Eles não dizem nada sobre desempenho, segurança, acessibilidade ou — o mais importante — se a sistema. funciona de verdade para um usuário real. Essa última lacuna é exatamente onde o código gerado por IA falha: o agente acerta uma unidade isolada e silenciosamente quebra toda a jornada de ponta a ponta que passa por ela. Portanto, trate Testes de ponta a ponta e de integração como prioridade máxima, não como uma reflexão tardia. — a camada que controla a aplicação real da mesma forma que um usuário faria e detecta o que os testes unitários não conseguem ver. Ferramentas como Dramaturgo MCP Permita até mesmo que o agente execute um navegador real e verifique seu próprio trabalho em relação a esse percurso, em vez de fazer suposições. Para requisitos que não podem ser testados de forma alguma, torne-os um ponto de controle explícito em seu pipeline de compilação — uma expectativa não é um controle.

Refatorar não é opcional.

O ciclo TDD tem três etapas, não duas: escrever um teste que falha (vermelho), fazê-lo passar (verde) e, em seguida, limpar o código que você acabou de escrever (refatorar). Se deixado sozinho, o agente tende a pular essa terceira etapa e lançar o produto assim que o teste passa. Mas a refatoração é onde a qualidade do código é mantida — e ignorá-la com um agente rápido e incansável é exatamente o que gera a bagunça que todo o processo visa evitar. Mantenha a refatoração no ciclo e observe um sinal de complexidade ou de geração excessiva de código para identificar a parte do código que o agente construiu em excesso.

A especificação está viva, não congelada.

Existe uma tensão real entre os dois métodos. O SDD exige que a especificação seja definida antes da escrita do código — esse é o objetivo principal de se ter um contrato. O TDD, por outro lado, é em parte uma forma de descobrindo O projeto: muitas vezes, você descobre que um requisito estava errado ou que uma interface era inadequada justamente ao escrever o teste. Então, o que acontece na primeira vez que um teste revela que a própria especificação estava incompleta?

A resposta é tratar a especificação como um documento vivo, não como uma aprovação única. Quando um requisito muda — ou um teste expõe uma falha — você não corrige o teste para corresponder ao código; primeiro você atualiza a especificação (uma pequena alteração revisada), atualiza os testes para que correspondam, observa-os falhar e deixa o agente fazê-los passar. É o mesmo ciclo vermelho-verde, aplicado tanto à especificação quanto ao código — e há uma regra que você não pode quebrar: As alterações no fluxo seguem a especificação → teste → código, e nunca o contrário. Mantenha essa linha de raciocínio e a mudança de requisitos deixará de ser o ponto fraco dessa abordagem e passará a ser o ponto forte dela.

O portão está inserido no ambiente.

A principal escolha de design é onde a disciplina resideÉ tentador atribuir isso a uma propriedade de uma ferramenta específica — esta planeja, aquela programa. Não faça isso. Coloque o ponto de controle no ambiente — seu sistema de controle de versão e CI — em vez de em um agente único. Uma vez instalado, o agente de codificação torna-se uma peça substituível em vez de algo em que você confia.

Sua ferramenta SDD é responsável pela estrutura de planejamento. Com o kit de especificações que é constitution → specify → clarify → plan → tasks → analyze → implementColoque as regras do TDD em seu arquivo de constituiçãoEscreva um teste que falhe antes da implementação; nunca marque uma tarefa como concluída enquanto os testes falharem; nunca modifique um teste já confirmado apenas para que ele passe. Cada comando herda essas regras, portanto, você não depende da capacidade do agente de se lembrar delas durante uma longa sessão.

O gate é um gancho de pré-commit e uma verificação de CI, não um prompt. Os testes são aprovados, as mutações são detectadas, os testes confirmados permanecem intactos — tudo isso é garantido pelo ambiente, portanto, a consistência se mantém independentemente de o código ter vindo do Spec Kit. implement, de Aider, ou qualquer outra coisa.

O executor é plugável. A região natal de Aider --auto-test O loop proporciona um ciclo de alteração mais preciso do que um comando em lote e roteia modelos por custo — um modelo robusto para especificação e planejamento, e um mais econômico para o loop de alta frequência, com cache ativado. Use-o ou não. A metodologia é o fator determinante.

Adeque a cerimônia ao risco.

Um processo que não pode ser reduzido acaba sendo abandonado. Uma cerimônia completa — constituição do projeto, especificação, plano, detalhamento de tarefas, além de testes de mutação — é um exagero para a correção de um bug de uma linha. Portanto, crie duas vias, uma divisão que Documentação própria da Spec Kit recomenda.

Vale a pena o custo adicional?

Nada disso é gratuito. Você está pagando por mais chamadas de modelo, mais execuções de teste e mais idas e vindas do que simplesmente deixar um agente escrever o código em uma única passagem, então é justo perguntar se o custo extra se justifica. A maneira de manter tudo sob controle é investir onde realmente importa: um modelo robusto na especificação e no planejamento, um modelo mais barato e rápido no loop de compilação de alta frequência; executar as verificações dispendiosas, como testes de mutação, apenas na mesclagem, não em cada iteração; e manter as fatias pequenas para que cada loop permaneça barato. Mas a verdadeira questão é com o que você está comparando. A linha de base não é um engenheiro sênior digitando código impecável — é um agente não supervisionado entregando código plausível e com falhas, que você então depura por horas. Em comparação com isso, a sobrecarga é o que lhe garante um resultado em que você pode realmente confiar.

Quando não fazer isso

E às vezes a resposta é que simplesmente não vale a pena. Ignore todo o processo para protótipos descartáveis ​​e spikes, onde o objetivo é aprender rápido e descartar. Ignore também para mudanças realmente triviais, onde configurar o gate custa mais do que corrigir o bug. E seja honesto sobre os domínios onde você não consegue escrever um teste significativo a baixo custo — nesses casos, o oráculo é vazio e as garantias são pura ilusão. Den Delimarsky observa Com base na experiência prática com o Spec Kit, as especificações não são a solução para todos os problemas. Nomear essas limitações não é uma forma de se proteger — é o que diferencia uma metodologia de uma mera propaganda.

A barra acaba de subir.

O que sobrevive à automação não é digitar código. É saber o que se deseja, expressá-lo com precisão suficiente para que um gênio da lâmpada literal não o interprete mal e ser capaz de verificar se você entendeu. SDD é como você diz isso. TDD é como você verifica.

O agente excluirá alegremente seus testes para que o alerta vermelho desapareça. Portanto, a especificação, o conjunto de testes e o julgamento por trás de ambos não são mera formalidade em torno do trabalho real. Com um agente envolvido, eles estão localizadas o trabalho de verdade.