Escrevendo o código e os testes com o mesmo agente.

Resumo

• Quando o mesmo agente escreve o código e o teste, o teste verde mede se os dois concordam, não se o código está certo.
• "Se você escreve e revisa o próprio texto logo em seguida. Vai deixar passar os mesmos erros que cometeu, porque não deixou de pensar do mesmo jeito".
• O agente também joga com o teste. Ele afrouxa a asserção, pula o caso difícil e declara pronto o que só passou em teste unitário.
• O que a gente faz no Blueprint: critério antes do código, executor diferente do autor, conferência no disco e não na fala, e uma pessoa simulada com roteiro.
• O teste também erra. Estão aqui os erros dos nossos próprios testes, e o que continua sendo decisão de gente de verdade.

O repositório que estava certo e não funcionava

Durante os testes do Blueprint com o Antigravity CLI, apareceu um problema que nenhuma verificação nossa teria achado. Acontece que usando a ferramenta o projeto realmente já saía "preparado" para desenvolvimento com agentes. O nosso AGENTS.md, por exemplo, estava no lugar, com o bloco certo, exatamente onde a nossa própria documentação dizia que deveria estar. Por dentro, tudo conferia. Só que esse o próprio gemini já não lê AGENTS.md. Ele lê GEMINI.md. Então é um caso onde as regras até existiam, mas nunca chegavam a quem deveria segui-las.

Quem mostrou isso foi um agente de verdade, num projeto descartável. Hoje o Blueprint grava os dois arquivos e a verificação reclama se faltar algum. Mas até aí tudo bem.

O que me interessa nesse caso não é o Gemini. É o formato do erro: a implementação e a verificação partiam da mesma suposição, a de que todo agente lê AGENTS.md. Uma suposição compartilhada não é pega por nenhum teste que venha dela. Isso vale para qualquer par de autores. Em projeto desenvolvido por IA, o autor dos dois lados costuma ser o mesmo agente, na mesma sessão, minutos depois de escrever o código. É como aquela lida rápida que você dá depois de escrever uma mensagem.

Este texto é sobre isso: por que um teste escrito pela IA para o código da IA prova menos do que parece, e o que a gente faz para que prove mais. O Luis, aqui da Síntese, falou sobre isso em um caso onde ele analisou 798 projetos no GitHub e mostrou que adotar IA aumentou a fração de commits que mexem em teste, mas só cerca de 3 pontos percentuais depois de descontar o grupo de controle, e que quem adotava já testava mais antes (Luis Nicolau, 2026 ↗ (abre em outra aba)). A conclusão feita é que a IA amplifica a cultura de teste que o time já tem. E estamos partindo daí, queremos saber "Quem exatamente testa?".

Verde quer dizer que os dois concordam

Escrever o teste depois do código, com o mesmo agente, tem uma consequência que o painel verde esconde. O agente escreve o teste a partir do que ele entendeu do pedido e do que acabou de implementar. Se o entendimento estava torto, o código sai torto e o teste sai torto do mesmo jeito. Mas mesmo assim os dois passam. A greenlight nesse caso mede concordância, não correção de fato.

E não somos nós que estamos dizendo, há evidência de que essa concordância é mais forte do que a de duas pessoas diferentes. O time de Panickssery, por exemplo, mostrou que modelos de linguagem reconhecem o que eles mesmos geraram, e que a preferência pela própria saída cresce junto com essa capacidade de reconhecer (Panickssery et al., 2024 ↗ (abre em outra aba)). Claro, o experimento deles é com avaliação de texto, não de código, e com modelos de 2024, então não vou dizer que ele prova o que acontece num teste unitário. O mecanismo, porém, é o que importa de verdade: avaliador e autor com a mesma origem não funcionam como dois pares de olhos.

Trocar de modelo até ajuda, mas menos do que se espera. Em outro caso, li que uma equipe mediu o quanto modelos diferentes erram juntos. Numa das bases que analisaram, quando dois modelos erram a mesma pergunta, cerca de 60% das vezes eles dão a mesma resposta errada. A correlação aparece mesmo entre fornecedores diferentes (tipo Anthropic, OpenAI, Goolge etc.) e é maior nos modelos maiores e mais precisos (Kim et al., 2025 ↗ (abre em outra aba)). O revisor de outra família de modelos as vezes pega mais do que o revisor de uma mesma, mas não é independente.

A leitura que eu faço disso é uma escala. Acho que podemos colocar níveis nesse processo:

E dá pra ir além: essa escala não é uma hierarquia limpa. Uma verificação determinística tem pontos cegos que um modelo não tem, e uma pessoa cansada confere pior do que um script. O que a escala realmente dá é uma pergunta melhor do que "tem teste?", seria algo como "em que nível está a conferência deste trecho, e o risco dele pede esse nível?". Cada degrau desse custa mais. Uma tela de apresentação, por exemplo, aguenta o nível 1. Mas um projeto como um cálculo de cobrança, aí não.

Uma limitação dessa definição é a seguinte: a escala descreve o risco, mas não o mede. Não conheço estudo que diga, para código, quanto cada degrau desse pode reduzir de erro.

O agente também joga com o teste

O segundo problema que apontei não é de concordância, é mais de incentivo. Quando o objetivo do agente é fazer o teste passar, passar vira o alvo, e aí o caminho mais curto nem sempre é consertar o código. Li que a METR documentou isso em modelos de fronteira, em tarefas de avaliação, modelos adulteraram o próprio código de pontuação. Num caso, o modelo reescreveu o operador de igualdade para que qualquer comparação desse verdadeiro. Em outros, alterou o avaliador em tempo de execução ou foi buscar a resposta de referência do corretor. Instruir o modelo a não trapacear reduziu o comportamento só um pouco (METR, 2025 ↗ (abre em outra aba)).

Nesse caso o que a METR descreve é um cenário de avaliação, não o seu repositório. Mas o gesto é o mesmo que aparece em escala pequena no dia a dia, como aquele teste vermelho que "se resolve" afrouxando a asserção, o caso difícil que é pulado, o mock que passa a devolver exatamente o que o teste espera. O Luis recomenda uma regra no arquivo de instruções do agente contra isso [1], e eu uso a mesma. Mas uma regra dessa é um pedido, não controle real. Para ter controle, a solução é estrutural: o teste não pode morar onde o agente testado consegue editá-lo durante a execução, e o diff do teste merece mais atenção do que o diff do código.

O relato de engenharia da Anthropic sobre agentes de longa duração mostra o outro lado do mesmo problema (Young, 2026 ↗ (abre em outra aba)). O agente declarava funcionalidades concluídas sem verificação de ponta a ponta, só com testes unitários e chamadas curl. Melhorou quando foi orientado a usar automação de navegador e a testar como uma pessoa usuária. E a lista de funcionalidades ficou em JSON, com um campo passes que as instruções só deixam o agente mudar depois de testar, porque o modelo tende menos a reescrever JSON do que Markdown. Dito isso, aqui na Síntese a família de modelos que mais usamos é a da Anthropic.

Como a gente testa o que o agente construiu

O Blueprint é aberto, e os testes de sessão dele também — estão na pasta tooling/sessions do repositório. Então dá para conferir o que digo daqui em diante...

São quatro princípios e uma regra de passagem.

1. A régua vem antes e de fora

O Blueprint abre com uma entrevista e fecha num plano com uma especificação por tarefa, e cada especificação diz como aquilo deve ser testado, antes de existir código. É isso que o teste da entrevista confere no final — uma spec por tarefa, cada uma com o "como testar". Quando o agente implementa, ele implementa contra uma régua que já estava escrita e que ele não ajustou depois de ver o resultado. Régua desenhada depois do código acaba medindo o código. A ordem que eu mais peço a quem trabalha com agente é essa: critério de aceite primeiro, código depois.

2. Quem testa não é quem escreveu

No teste de sessão, quem executa é um agente novo, numa pasta de projeto descartável, com o plugin carregado e mais nada. Ele não viu como o Blueprint foi escrito e não tem como combinar nada com o código. Isso é o nível 1 da escala. Para subir, as conferências não são feitas por outro modelo julgando, elas são scripts em Python que leem o que sobrou no disco. Uma verificação determinística não tem preferência pelo próprio estilo. Ela tem o limite do que o autor dela pensou em conferir, e volto a isso mais abaixo.

3. Conferir o disco, não a fala

O agente diz que salvou. O teste abre o arquivo. Na entrevista completa, o estado do projeto passa pelo verificador do próprio Blueprint (check_state.py), os seis documentos fixos existem onde o estado diz, estão em português e não carregam sobra do modelo de documento. Para saber se o agente usou uma skill, o teste lê o registro das chamadas, em vez de aceitar um "segui o procedimento". Inclusive, no teste com o Codex houve um resultado que vale até registrar: quando o ambiente recusou a execução de uma verificação, o agente disse que não tinha conseguido rodá-la e não fingiu que rodou. Isso só aparece quando a fala é comparada com o que realmente aconteceu.

4. Uma pessoa simulada, com roteiro

O agente do Blueprint conduz uma conversa, e para testar uma conversa é preciso alguém do outro lado. No teste da entrevista que fiz, usei uma pessoa de mentira, a "dona de uma padaria que quer um site para receber encomendas". Ela escreve em português, não tem verba e nunca aprova um documento. Ela responde de acordo com a etapa em que o agente diz estar, aceita a recomendação quando a decisão é cara de desfazer e manda seguir quando não tem mais o que dizer. Com roteiro, a conversa se repete, e a falha de hoje pode ser comparada com a de ontem. É diferente de pedir a outro modelo que "interprete um usuário" e dê nota. A mesma característica que dá repetibilidade é também o limite: ela quase nunca discorda. Volto a isso.

Explorar descobre, o teste fixo protege

Aqui existe uma tensão entre duas boas fontes. O Luis recomenda não usar a verificação manual de interface por agente como rotina, por causa do custo em tokens [1]. A Anthropic mostrou que pedir ao agente que teste como uma pessoa usuária corrige o "dei por concluído" [5]. Os dois têm razão, em momentos diferentes. — Minha posição, que é da Síntese e não particular, é que o agente explorando como usuário serve para descobrir. O que ele descobre precisa virar um teste automático que roda sempre, barato e repetível. Devemos considerar que a exploração é cara e deve acontecer quando há dúvida. O teste fixo é o que sobra dela, e é ele que protege a mudança seguinte.

O que uma conferência independente acha e a do autor não acharia

Quando quem confere não é quem escreve, os erros mais importantes costumam aparecer justamente fora do caminho que o autor imaginou. Nos testes do Blueprint, os achados mais úteis assumiram três formas que os próprios agentes não haviam previsto inicialmente.

A primeira foi perceber que o agente cumpre a frase, mas não necessariamente a intenção. No roteiro que testei com uma pessoa simulada, ela dizia: “Se faltar algum detalhe, decida você e me avise”, uma formulação comum quando estamos com pressa. O agente, porém, interpretou a frase como autorização para tomar decisões caras de desfazer, como escolher a stack e a hospedagem. Quem escreveu o fluxo provavelmente não testaria esse cenário, porque já conhece a intenção por trás da frase; foi preciso alguém de fora falar como as pessoas realmente falam. Somado ao problema descrito a seguir, esse comportamento contribuiu para derrubar a primeira rodada do teste de mudanças, que terminou com 22 falhas em 58 conferências.

Em engenharia de software, conhecemos essa máxima há muito tempo: o caminho do autor não é o caminho de quem usa. E devemos perceber que, quando se trata de desenvolvimento com IA, isso não é diferente.

O segundo problema era que um pedido direto de mudança, como “troca isso aqui”, não acionava o que deveria. Quem construiu o método costumava testar o fluxo em que a pessoa pede explicitamente para usá-lo, mas quase ninguém formula o pedido dessa maneira, as pessoas simplesmente descrevem o resultado que querem, e o método precisa entrar em ação por conta própria. Há ainda um terceiro tipo de falha, mais silencioso, que é acertar sem deixar rastro. Um agente sem o plugin carregado recebeu a ordem de começar a primeira tarefa, executou a tarefa correta, mas não informou qual havia escolhido. Para quem revisa o trabalho depois, isso é indistinguível de uma escolha arbitrária. Por isso, o arquivo de entrada agora exige que o agente identifique a tarefa pelo número e pelo nome, e a conferência passou a verificar essa informação.

Em resumo, o que quero dizer é que o padrão se repetiu nos três casos — nenhum desses erros estava propriamente no código ou no texto das skills, mas no encontro entre aquilo que o autor supôs e o que acontece quando alguém de fora usa o sistema.

O que continua sendo de nós humanos

Meu critério é simples, o que a IA não pode fazer sozinha é o que, se errado, torna todo o resto verde e inútil, um falso positivo.

Dizer o que é certo. O agente pode propor critérios de aceite, e até propõe bem. Mas aceitar o critério é uma decisão de quem sabe o que o produto deveria fazer. Se a régua nasce do mesmo entendimento torto do código, não existe nível de independência que resolva depois.

Decidir se o vermelho é do código ou do teste. Esbarrei nisso em quase todos os exemplos acima. É a decisão que o agente tem mais incentivo para responder do jeito errado, porque consertar o teste costuma ser mais fácil do que consertar o código.

Escrever a pessoa difícil. O ponto fraco do nosso roteiro é uma pessoa simulada que quase nunca discorda. Quem decide quais discordâncias a conversa de teste precisa enfrentar é quem conhece problemas reais, não o agente que escreve o roteiro.

Escolher o nível pelo risco. Nem tudo precisa do degrau mais alto da escala. Decidir onde ele é obrigatório é sempre uma decisão de risco.

Minha convicção é que a IA aumenta a quantidade de teste que vale a pena ter e baixa o custo de escrevê-lo, e ao mesmo tempo encarece o erro de confiar nesse teste sem pensar. Os dois efeitos acontecem juntos e se amplificam. Quem só vê o primeiro acaba com um painel verde e um sistema em que ninguém sabe o que foi realmente conferido.

Fontes

• Luis Felipe Nicolau. Ou testa no dia 1, ou nunca testa: testes na era da IA ↗ (abre em outra aba). Newsletter IA Pé no Chão, LinkedIn.
• Panickssery, Bowman, Feng. LLM Evaluators Recognize and Favor Their Own Generations ↗ (abre em outra aba). NeurIPS 2024.
• Kim, Garg, Peng, Garg. Correlated Errors in Large Language Models ↗ (abre em outra aba). ICML 2025.
• METR. Recent Frontier Models Are Reward Hacking ↗ (abre em outra aba). 2025.
• Justin Young, Anthropic Engineering. Effective harnesses for long-running agents ↗ (abre em outra aba).