Estudo testa se agentes de código usam técnicas de teste de verdade

O experimento

O autor reaproveita uma avaliação anterior de implementação do Zstd em Rust para testar se instruções simples sobre técnicas de teste melhoram a correção do código escrito por agentes. Foram testadas 26 condições de prompt (de TDD, fuzzing e testes baseados em propriedades a métodos formais como Verus, Lean 4, Alloy, TLA+, Spin, Creusot, SMT solvers com Z3, cvc5 e Yices) e 4 skills de teste: a skill oficial do Hegel, a skill de testes Rust do ECC (coleção com 250 mil estrelas no GitHub), a skill de testes de propriedade da Trail of Bits e uma skill própria do autor. Os experimentos usaram Codex com GPT-5.6 Sol, em esforços medium e xhigh, com média de 80 execuções por condição, medindo custo e fração de execuções que passaram em 100% dos testes ocultos.

O autor registrou previsões antes: TDD teria desempenho inferior (55% de confiança), métodos formais não superariam (52%), a instrução "Make no mistakes" não superaria a ausência de instruções (95%), e as skills testadas não superariam (confiança entre 55% e 65%).

Resultados gerais

Nenhuma condição superou de forma marcante o restante, e o Default (sem instruções adicionais) ficou acima da média. Em xhigh, condições relacionadas a fuzzing e testes baseados em propriedades ficaram um pouco à frente dos métodos formais, com quadro mais misto em medium. As skills recomendadas pelo próprio Codex tiveram desempenho inferior, enquanto a skill customizada rápida do autor foi razoável. TDD teve desempenho ruim, como previsto.

Ao inspecionar o que os agentes fizeram, o diagnóstico central é que eles não sabem usar bem essas ferramentas e técnicas. Em geral, escrevem os testes que já escreveriam dentro de um framework diferente, ou usam a técnica de forma superficial sem extrair seu valor: nos métodos formais, provam propriedades irrelevantes; nos testes de propriedade, usam entradas aleatórias que atingem caminhos de rejeição de entrada inválida ou verificam propriedades triviais. Em xhigh, os agentes conseguem fazer seus próprios testes passarem, mas escrevem testes ruins. Resultados no eval do IMAP RFC e em outras RFCs não diferiram materialmente.

Condições específicas

• Verus: os agentes não provaram que o código corresponde às especificações, fizeram provas abstratas e por vezes vaciosas (efetivamente A => A), e a correção veio dos testes tradicionais em Rust.
• Alloy: segundo pior resultado; os agentes dependeram de testes padrão e, em um caso, um contraexemplo baseado em overflow de 8 bits que não podia ocorrer só tornou o código mais complexo.
• Teste diferencial: terceiro pior resultado; nenhum agente criou duas implementações completas e independentes, e quando a técnica poderia pegar um bug, os agentes escreveram a mesma coisa duas vezes, replicando o mesmo bug.
• Lean 4: provas aritméticas que não atingiram as áreas propensas a bugs, com forte dependência dos testes padrão.
• QuickCheck: 63 de 160 execuções verificaram apenas uma propriedade; testes simples e entradas aleatórias pouco úteis.
• TDD: dobrou a quantidade de testes e tornou o fluxo mais iterativo, mas os agentes escreveram mais testes que não cobriam casos difíceis (por exemplo, deixando os quatro streams idênticos) e, em alguns casos, codificaram comportamento incorreto nos testes.
• Skill do Hegel: pior correção e custo 26% maior em medium e 41% em xhigh, em parte pelo tamanho (mais de 20 mil tokens relidos várias vezes) e por trabalho extra que não aumentou a correção.
• ECC: a pontuação bruta quase igualou o Default, mas os casos em que a skill foi realmente lida tiveram resultado abaixo da média, com muitos testes pequenos e pouco significativos; o autor atribui o aparente bom resultado ao acaso.
• Fuzzing: na rara ocasião (10 de 160 casos) em que geraram entradas estruturadas aleatórias, metade encontrou bugs reais, sugerindo que os agentes sabem fazer melhor quando empurrados.
• SMT solvers: usados como calculadora; agentes provaram propriedades sobre uma computação e mesmo assim escreveram o código errado.
• TLA+: acima da média, mas a modelagem mais sofisticada não se correlacionou claramente com melhor correção.

Conclusões e hipóteses

O autor questiona por que laboratórios de IA não criaram ambientes de RL para treinar agentes a testar bem, dado que agentes se saem bem em problemas de otimização com runtime limitado, que se prestam a esse tipo de treinamento. Ele levanta hipóteses: conhecimento de técnicas de teste eficazes pode não ser difundido o suficiente, ou o problema é mais difícil de empacotar do que parece. Como os falhas são idiossincráticas, sem padrão claro entre as condições, ele adverte contra conclusões fortes a partir da ordenação dos resultados.