Mandar o agente usar TDD não é controle. Dan Luu rodou 4.800 vezes para mostrar isso.

Dan Luu deu a um agente de código a mesma tarefa sob trinta instruções de teste diferentes: use TDD, faça fuzzing, escreva um modelo em TLA+, carregue esta skill do fornecedor, não cometa erros. Cada condição rodou 80 vezes em dois níveis de esforço (medium e xhigh) no codex com GPT-5.6 Sol, o que dá cerca de 4.800 execuções. A métrica era seca: a fração de execuções que passou em 100% de uma suíte oculta de 37 testes para uma implementação de Zstd em Rust. O resumo dele sobre o gráfico: “nothing really wildly outperforms. However, Default (no additional instructions) does well above average.”

Essa frase deveria reorganizar a forma como você enxerga o parágrafo de testes do seu AGENTS.md. Nomear uma técnica no prompt não superou o silêncio. Em pelo menos uma condição custou mais e pontuou um pouco abaixo.

Cobrimos o experimento de agosto de Luu, com regex, no texto sobre auditoria por holdout: um conjunto de testes oculto como o controle que o agente não consegue burlar. O experimento de setembro usa o mesmo tipo de holdout e faz outra pergunta. Dado um holdout, o vocabulário do prompt move o número? Em trinta condições, a resposta foi quase sempre negativa.

A instrução que não fez nada

Comece pelo resultado nulo mais limpo. Uma condição mandava o agente “não cometer erros”. A leitura de Luu: “At every level at which I looked at the results, they were indistinguishable from random draws of Default.” Em todos os níveis que ele examinou, nada se moveu. A instrução foi consumida e produziu nada mensurável.

Essa é a linha de base para todo o resto do estudo. Uma linha de prompt pode estar presente, ser obedecida na transcrição e continuar inerte no resultado. Quando alguém mostra a seção de testes de uma configuração de agente e diz “a gente manda ele fazer X”, o ônus é dessa pessoa: mostrar que X moveu um número contra um holdout. Presença no prompt ainda precisa virar evidência de efeito.

TDD: obedecido, e pior

A condição de TDD é a que mais vejo em configurações de agentes. Luu previu que ela iria abaixo da média, e foi: “TDD didn’t do well, as predicted.” A parte interessante é que os agentes obedeceram. Os agentes de TDD “had one or more failing tests in 67 of 160 cases before doing substantial (non-stub) implementation, vs. 0 of 160 for the Default condition”. Também “produced twice as many tests”.

A instrução, portanto, mudou o comportamento, de forma visível, na direção pedida. Testes vermelhos primeiro, mais testes no total. E a taxa de aprovação no holdout não melhorou. O dobro de testes, escritos pelo mesmo modelo que escreveu o código, a partir da mesma leitura da especificação, compra o dobro de confirmação daquilo em que o modelo já acreditava. A suíte oculta mediu algo que os testes do próprio modelo eram incapazes de ver.

Essa é a distinção que importa para quem responde pela qualidade de agentes. Uma técnica descreve como um humano organiza a própria atenção. TDD funciona para uma pessoa porque o teste que falha força um compromisso com um comportamento antes que a implementação tome conta. O agente tem outros modos de falha, e o ritual compra uma proteção diferente. O que o agente precisa é de uma verificação que ele mesmo não escreveu.

Métodos formais: encenados, sem uso

A condição de TLA+ é o caso mais nítido de ritual sem efeito. Luu esperava que métodos formais ficassem abaixo, e ficaram, “but not for the reason I expected. Agents failed to use them remotely effectively, so of course they couldn’t outperform.” Os números: “159/160 agents created some kind of TLA+ model”, e “I didn’t find an instance of a TLA+ issue resulting in an actual change in the Rust code.”

Quase toda execução produziu o artefato que a instrução pedia. Zero execuções, até onde o autor conseguiu encontrar, deixaram o artefato mudar o código. O modelo era decoração. Quem auditasse essas transcrições perguntando “o agente escreveu uma especificação em TLA+?” teria marcado 159 de 160 como conformes. Conformidade com a técnica e benefício da técnica são medições diferentes, e só o holdout enxerga a segunda.

Fuzzing mostra a mesma forma pelo lado oposto. Os agentes geraram entradas estruturadas aleatórias em “10 out of 160 cases”, e nesses casos “this found real bugs half the time”. A técnica funciona quando aplicada. Entradas estruturadas aleatórias apareceram em dez execuções de 160. Dez execuções em 160 é a cara de uma instrução quando o harness não a impõe.

As skills do próprio fornecedor pioraram o resultado

Aqui o estudo deixa de ser curiosidade acadêmica e passa a descrever uma decisão de compra. Luu rodou as skills de teste que o próprio codex recomendou. “The testing-related skills codex recommended we try underperformed, although our quick custom skill did ok.”

A skill Hegel (34 mil caracteres mais uma referência de 45 mil, “more than 20k tokens”) produziu correção um pouco pior a um custo “much higher (26% higher on medium and 41% on xhigh)”. A skill da Trail of Bits tinha um problema mais básico: “only 108 out of 160 runs actually opened the skill to read it.” Cerca de um terço das execuções nunca leu a skill.

O diagnóstico de Luu: “the skills seemed written like they’re human tutorial instructions, in that the goal of the skill seems to be to explain how to do something.” O autor da Hegel, David R. MacIver, acrescenta no apêndice uma frase que vale guardar: “agents suck at writing agent skills and also everyone (including us) uses an agent to write their skills.”

Argumentamos no texto sobre contexto passivo que um arquivo AGENTS.md vence uma biblioteca de skills em avaliações. Este experimento testa essa afirmação diretamente sobre um conjunto de skills recomendado pelo fornecedor, e a afirmação se sustentou. Uma skill escrita como tutorial é um imposto de 20 mil tokens que ensina ao modelo algo que ele já sabe ou que ele é incapaz de aplicar só de ler. O argumento sobre apodrecimento de skills cobre o que acontece com esse imposto ao longo do tempo. Este estudo mostra o imposto no primeiro dia.

As cinco linhas que funcionaram

A condição de maior pontuação foi a skill do próprio Luu, com cinco linhas. Ele tem o cuidado de chamá-la de “a first draft for a skill to iterate on” que “would need more than the 2 minutes I spent on it to be actually useful”. Aceite a ressalva como ele a escreveu. Aceite também a explicação de por que cinco linhas venceram cerca de 80 mil caracteres: “our skill is designed to nudge away from their default behavior towards more productive behaviors whereas the other skills seem more like tutorials.”

Direcionar versus ensinar. Um tutorial presume que o leitor carece de conhecimento. Uma instrução de direcionamento presume que o leitor tem o conhecimento e um padrão apontado para o lado errado, e nomeia a alternativa. O modelo já sabe o que é a técnica. O que falta é o impulso de aplicá-la nesta tarefa. Cinco linhas conseguem fornecer o impulso. Dezenas de milhares de caracteres explicando a técnica não conseguem, e no caso de uma das skills um terço das execuções nunca abriu o arquivo.

As ressalvas ficam aqui. Um modelo, um harness de um fornecedor, uma tarefa principal com suíte de 37 testes. Uma segunda tarefa, a implementação de uma RFC de IMAP com 40 execuções por condição, produziu resultados que “weren’t materially different”. O autor alerta explicitamente contra ler demais na ordenação das condições no gráfico, e a página imprime nenhum percentual por condição em texto. O achado que sobrevive às ressalvas é o nulo: em trinta formas de nomear uma técnica, nada “wildly outperforms”, na expressão do autor, e a linha de base sem instrução ficou bem acima da média.

A cara de um controle

Se nomear a técnica não funciona como controle, o estudo também mostra o que funciona. Duas coisas moveram o número ou expuseram as falhas, e nenhuma delas mora no vocabulário do prompt.

A primeira é a suíte oculta. Todo resultado acima existe só porque 37 testes que o agente nunca viu pontuaram as execuções. Sem eles, a condição de TDD parece a mais diligente (dobro de testes, vermelho antes de verde) e a condição de TLA+ parece a mais rigorosa. O holdout é o que separa a técnica encenada da técnica eficaz. Já escrevemos sobre o que agentes fazem com um sinal de verificação que conseguem ver. O corolário aqui é mais brando e mais comum: um agente dispensa burlar um teste visível para ser enganado por um teste que ele mesmo escreveu.

A segunda é comportamento imposto. Fuzzing achou bugs reais metade das vezes em que foi aplicado, e foi aplicado em dez execuções de 160. O prompt pediu. O harness não conferiu. A distância entre “o prompt diz para fazer fuzzing” e “a execução falha se não existir alvo de fuzzing” é a distância entre um pedido e um controle. A skill de cinco linhas de Luu é uma versão fraca disso: ela não impôs, direcionou, e ainda assim superou tudo o que explicava.

Faça isso agora

Abra a configuração de agente de um repositório e encontre a seção de testes. Para cada técnica nomeada ali, responda duas perguntas. Existe uma suíte de aceitação oculta, de propriedade de um humano, que o agente nunca lê, contra a qual o efeito dessa técnica foi medido? Existe uma verificação no harness que derruba a execução quando a técnica é pulada? Uma linha com dois “não” é uma linha de “não cometa erros”. Custa tokens e produz nada que você consiga ver.

Depois reescreva a seção no formato que venceu. Apague as explicações sobre o que a técnica é. Mantenha só as frases que nomeiam um padrão do modelo e o apontam para outro lugar. Se o resultado tiver menos de dez linhas, isso é coerente com a condição de maior pontuação deste estudo. Meça contra o holdout antes de acreditar, do mesmo jeito que Luu fez.

---

Fontes

• Dan Luu. “How well do agents use test and verification techniques?.” Setembro de 2026.

A Victorino ajuda times de engenharia a trocar vocabulário de prompt por suítes de aceitação ocultas e verificações impostas pelo harness, que o agente não consegue encenar: contato@victorino.com.br | www.victorino.com.br