Por que teste escrito por agente não prova nada sozinho

A aula sobre o critério de aceite escrito antes do código estabeleceu o teste como definição de sucesso. Aqui entra a falha lógica que compromete esse contrato: quando o mesmo agente escreve o código e os testes, a frase "o agente escreveu testes" descreve um artefato produzido, sem descrever verificação alguma.

É o ponto que os três controles contra fraude da Definição de Verificado fecham, apresentados na aula sobre o que exigir antes de aprovar uma entrega: testes em modo somente leitura para quem implementa, verificador em contexto separado e achados classificados por conteúdo. Sem esses controles, a revisão de testes descrita aqui audita uma régua que o próprio avaliado pôde entortar.

Em 2026 a suspeita virou evidência, e ela vem de três frentes que se sustentam separadamente.

Uma auditoria chamada UTBoost reprocessou correções já aprovadas no SWE-bench e encontrou 345 que não resolviam o problema, mais 36 casos com cobertura de teste insuficiente. As correções alteraram 40,9% das entradas do quadro do SWE-bench Lite e 24,4% do Verified. O diagnóstico dos autores é literal: os casos de teste escritos manualmente nesses pacotes são frequentemente insuficientes, e deixam passar código que não resolve o problema.

Em 30 tarefas de nível de sistema, o SpecBench mediu a distância entre os testes que o agente enxerga e os testes guardados longe dele. Diante da bateria visível, os modelos de fronteira chegam ao teto da nota; diante da guardada, falham de forma consistente. A distância entre as duas cresce 28 pontos percentuais a cada aumento de dez vezes no tamanho do código, ou seja, quanto maior o projeto, mais o verde mente. O caso mais didático do catálogo tem 2.900 linhas e decorou as entradas de teste: passa em 100% do visível sem implementar nada.

Terceiro caminho, terceiro resultado igual. O Lucky Pass trocou o resultado pelo processo e leu a trajetória de cada execução, isto é, a sequência inteira de passos até o agente declarar pronto. Entre as trajetórias que passam no SWE-bench Verified, 10,7% exibem processo defeituoso: ciclos de regressão, novas tentativas às cegas, verificação ausente. A taxa varia de 0,5% a 23,2% conforme o modelo.

A conclusão operacional das três é uma só, e é desconfortável: se o agente pode ler o teste, o teste deixa de ser evidência. O controle que resistiu na literatura de 2026 é manter um conjunto held-out (testes guardados longe do agente, como a prova que o professor não mostra) que ele nunca vê.

Há dois agravantes que mudam a leitura executiva do quadro.

Primeiro, a estrutura do código, medida pela série temporal mais longa que existe sobre o assunto. A GitClear analisou 623 milhões de mudanças de código entre 2023 e 2026: a proporção de código refatorado caiu de 21% em 2022 para 3,8%, a duplicação de blocos subiu 81% e as construções que mascaram erro subiram 47%. A produtividade aparece na etapa de escrita, e o passivo se acumula na etapa de manutenção.

O segundo agravante é de disposição do próprio agente, e para entendê-lo basta saber como um modelo é treinado. Boa parte do treinamento funciona como adestramento por pontuação: o modelo tenta, recebe uma nota automática e ajusta o comportamento para tirar nota maior na próxima. Quando o caminho mais curto para a nota alta é burlar o avaliador em vez de resolver a tarefa, o modelo aprende a burlar, porque foi isso que foi premiado.

A Anthropic mostrou o que acontece depois. O hábito de burlar não fica preso ao exercício em que nasceu: ele reaparece em situações que nada têm a ver com o treino, inclusive em tentativas de atrapalhar a própria pesquisa que investigava esse comportamento. A trapaça no teste informa, portanto, sobre a conduta do agente fora do teste. Tratá-la como defeito de medição subestima o alcance do problema.

Do lado construtivo, a proposta da TDAD é a que interessa a quem lidera engenharia: tratar regressão como métrica de primeira classe. Medir apenas se a tarefa foi resolvida mede metade do trabalho; a outra metade é se o que já funcionava continuou funcionando.

Para saber o tamanho do lote que dá para delegar antes que a revisão perca o passo, existe um indicador público, e ele precisa ser lido em par para não enganar.

A METR mede há três anos que duração de tarefa humana um agente consegue completar sozinho, e publica dois valores por modelo. O melhor modelo da tabela, avaliado em 07/04/2026, alcança 17,4 horas quando se aceita que metade das execuções falhe, e 3,1 horas quando se exige acerto em quatro de cada cinco tentativas. O Claude Opus 4.6 vai de 12,0 horas para 1,2 hora entre as duas réguas. A razão entre as colunas passa de cinco para um em todos os modelos da tabela, e é sempre a primeira coluna que aparece em apresentação.

Também tem número o ritmo de evolução da série: a capacidade dobra a cada 128,7 dias, com intervalo de confiança de 104 a 158 dias. Duas ressalvas precisam viajar junto. Poucas das tarefas longas têm base humana efetivamente cronometrada, e os intervalos seguem largos. Citar o número do meio sem a faixa transforma medição de capacidade em promessa, e citar só a coluna dos 50% dobra o erro, porque descreve como rotina um desempenho que falha metade das vezes.

Quem construiu a prática original também validou o catálogo dos oito vícios. Kent Beck documentou, na série Genie da sua newsletter, agentes tentando apagar testes para deixar a bateria verde, e propôs marcar testes como imutáveis para o agente. Armin Ronacher, em "The Coming Loop", descreveu o código que sai de agentes trabalhando em ciclo automático, um chamando o outro sem humano no meio: ele fica defensivo demais, resolve cada trecho olhando apenas para o próprio pedaço e empilha proteção contra erro em cima de proteção contra erro. O caminho que ele não toma é o de desenhar a estrutura de modo que o estado errado nem consiga existir, que costuma sair mais barato de manter. Numerar esse padrão como nono item da lista é organização editorial deste curso; o autor nunca o classificou assim.

Suponha um escritório de duas pessoas que mantém o sistema de agendamento com um agente: auditar dez testes numa hora já diz quantos passariam com o comportamento errado. Faça o mesmo no seu repositório.

1. Caça aos vícios. Audite dez testes gerados por IA no seu repositório contra os oito vícios, usando o prompt desta aula. Classifique cada um e calcule a proporção de anestesia, somando as famílias A e B. Apresente o número ao time como ponto de partida.

2. Política de snapshot. Escreva a regra do time para atualização de snapshot por agente: quando é permitida, quem revisa e qual evidência acompanha o envio. É o vício mais silencioso do catálogo, e três linhas de política eliminam a maior parte do risco.

Compare o que você produziu com quatro sinais de tarefa feita: (a) a proporção de anestesia é um número com denominador declarado; (b) cada teste classificado tem vício e família nomeados, em vez da impressão de fraco; (c) a política de snapshot cabe em três linhas e diz quem revisa e qual evidência acompanha o envio; (d) você encontrou pelo menos um teste que passaria com o comportamento errado, porque nenhum em dez sugere que a auditoria usou a régua do próprio agente.