Dan Luu não perguntou de forma abstrata se agentes de IA testam o próprio código. Ele rodou o experimento: 80 execuções do Codex (GPT-5.6 Sol) em duas configurações de esforço — medium e xhigh — implementando compressão Zstd em Rust do zero, mais outras 40 rodadas por condição num protocolo IMAP em paralelo. É esse tipo de número que falta na maioria dos resumos sobre o estudo, e é o que muda a leitura do resultado.
Onde os agentes erram, especificamente
Um dos bugs mais reveladores: na implementação do Zstd, o agente frequentemente deixava de reverter a ordem do bitstream entre encode e decode. Sozinho, isso quebraria qualquer teste — só que os testes que o próprio agente escrevia eram, em boa parte, palindrômicos. Um teste com entrada e saída simétrica não expõe erro de ordem, porque a ordem “errada” ainda bate com a esperada. O agente não estava testando mal por preguiça; estava testando de um jeito que estruturalmente não conseguia pegar aquele tipo de bug.
No protocolo IMAP, o quadro foi parecido: segundo Luu, apenas uma única execução em 40 rodadas (na condição medium) atingiu pontuação perfeita no critério “não cometer nenhum erro”.
O que aconteceu quando ele pediu técnicas específicas
Luu testou 26 técnicas e ferramentas de verificação diferentes — de TDD e fuzzing a métodos formais como ACL2, Alloy e Lean 4. O resultado central do estudo está numa frase do próprio autor: pedir explicitamente pra um agente usar uma técnica específica de teste não muda o resultado tanto quanto ele esperava. Os agentes escreviam testes no framework certo, sintaticamente corretos, mas sem capturar o valor real da técnica.
Com TDD isso ficou nítido: o agente gerava mais testes quando instruído a seguir TDD, só que de qualidade pior — com mais tendência a não cobrir os casos difíceis, exatamente os que importam. Com fuzzing, de 160 rodadas no total, só 10 geraram entradas aleatórias estruturadas de forma efetiva o bastante pra achar bugs reais. E quando o agente usava ferramentas de verificação formal como Verus ou Alloy, a tendência era provar propriedades abstratas que não tinham relação direta com o código sendo verificado — cumpria a forma, não a função.
O skill próprio do autor também não resolveu do jeito esperado
Luu construiu um skill customizado de teste (chamado Hegel no artigo) e testou se ele melhorava o comportamento dos agentes. Foi usado em 157 das 160 rodadas disponíveis, teve o melhor resultado geral entre as abordagens testadas, mas custou entre 26% (esforço medium) e 41% (esforço xhigh) a mais em tokens. E o próprio autor é direto sobre a limitação: o skill não funcionou exatamente como pretendido — a ideia era que o agente usasse contexto fresco e independente pra revisar o próprio código, mas isso raramente aconteceu na prática.
A leitura que fica
O ponto que Luu deixa claro é que o problema não é falta de conhecimento — os modelos claramente sabem escrever sintaxe de teste em qualquer framework pedido. O que falta é o julgamento de quando e como aplicar aquilo de um jeito que realmente cobre o caso que importa. Instrução explícita (“use TDD”, “use fuzzing”) melhora pouco isso, porque o agente segue a forma da instrução sem necessariamente entender o motivo por trás dela.
Pra quem usa agentes de código no dia a dia, a implicação prática é direta: revisar o que o agente testou é tão necessário quanto revisar o código em si — às vezes mais, porque um teste que parece cobrir o caso (como os palindrômicos do exemplo do Zstd) pode estar mascarando exatamente o bug que deveria pegar.
