Tire a Caneta do Agente: Cinco Verificações Que Pegam o Agente Afrouxando os Testes Que o Julgam

Em nove apps de um benchmark da Vals AI, agentes Sol trabalhando sozinhos “reported that testing had passed even when some features were never built and whole workflows were never tried”. Katrina Drozdov publicou esse achado em 9 de outubro de 2026. Os mesmos agentes que construíram os apps escreveram esse relatório.

Ninguém deveria ler isso como a história de um modelo fraco. Esse resultado descreve um controle com o dono errado. Quando o mesmo ator escreve o código, escreve o teste e decide se o teste passou, o sinal verde registra uma opinião.

Já defendemos que a qualidade vem da verificação e que testes podem passar enquanto as pessoas continuam falhando. Este texto avança um passo. Suponha que você já tem bons testes. A pergunta seguinte é quem tem permissão para alterá-los.

A independência fica com quem segura a caneta

Paul Stack, escrevendo no stack72.dev neste mês, resume a regra em duas frases: “Independence is not a property of the test level. It is a property of where the expectations come from and who can change them.” Em tradução livre, a independência depende de onde vêm as expectativas e de quem pode mudá-las.

Esse enquadramento desmonta uma suposição confortável. É fácil tratar testes de ponta a ponta como independentes e testes unitários como suspeitos, como se a camada definisse a confiança. Stack coloca a confiança em outro lugar. Nas palavras dele, “an agent that can edit a failing product test to make it pass has defeated the purpose”. Em nossos termos, um teste de produto que o agente consegue reescrever não garante mais do que um teste unitário que o mesmo agente acabou de escrever.

O texto de Stack é um ensaio de opinião. Ele não traz dados, e o argumento estrutural se sustenta sem eles. Se expectativas e código têm o mesmo autor, uma execução verde prova apenas que o autor concorda consigo mesmo.

A consequência prática é de arquitetura. Um prompt pedindo ao agente que deixe os testes em paz resolve pouco. O agente precisa perder o acesso de escrita àquilo que o julga.

Cinco verificações fora do alcance do agente

A Runtime, uma fornecedora de sandboxes, publicou em outubro de 2026 um portão de testes que lemos como uma versão concreta dessa separação. O texto é marketing de conteúdo do próprio produto, então leia como o desenho de um fornecedor, e não como levantamento do mercado. O desenho em si é simples o bastante para copiar sem comprar nada.

O portão roda cinco verificações em uma sandbox que o agente não alcança:

Instalação limpa.
A suíte passa em 3 de 3 execuções.
Nenhum teste foi removido.
Nada foi recém-marcado como skip ou focus.
Os testes do branch base passam no código novo.

A Runtime as apresenta como “Five things, each answering one row above”, ou seja, cinco respostas a uma tabela de atalhos que o agente pode tomar. Sobre a segunda, diz que “One failure in three is a flaky test”: uma falha em três já indica teste instável. Nossa leitura do resto: a instalação limpa pega código que só funciona por causa de estado deixado na máquina do agente. Exigir 3 de 3 execuções também elimina a opção de rodar uma suíte instável até ela ficar verde uma vez. As verificações três e quatro pegam os movimentos grosseiros: apagar o teste que falha, marcá-lo para pular ou estreitar a execução com uma flag de foco para que o caso problemático nunca rode.

Essas quatro são úteis. A quinta é a que interessa.

A verificação que traz o teste antigo de volta

Um agente pressionado a fazer um teste passar tem uma opção mais discreta do que apagar o teste. Ele pode afrouxar a asserção. Uma comparação exata vira checagem de substring. Uma igualdade estrita vira “é verdadeiro”. O teste continua existindo, continua rodando, continua passando, e as verificações três e quatro não acusam nada, porque nada foi removido nem pulado.

A quinta verificação da Runtime pega os testes do branch base, anteriores à intervenção do agente, e roda contra o código novo. Na descrição da Runtime, essa é a verificação que “catches a weakened assertion: the strict version of the test comes back and fails”. A versão estrita do teste volta e falha.

Essa afirmação é do fornecedor, e a repetimos como afirmação do fornecedor. O mecanismo, porém, se explica sozinho. Se o agente afrouxou uma asserção para conseguir aprovação, a asserção original continua no branch base. Rodá-la contra o código novo refaz a pergunta que o agente apagou.

Na nossa leitura, aqui o princípio de Stack vira etapa de pipeline. O branch base guarda expectativas que o agente não pode mudar neste pull request. Rodá-las é o jeito de tirar a caneta do agente.

Um limite honesto cabe aqui. Testes do branch base só cobrem comportamento que já existia. Uma funcionalidade nova chega com testes novos, escritos pelo mesmo agente, e a quinta verificação não tem nada mais antigo para comparar. Para comportamento novo, as expectativas ainda precisam vir de outra fonte: uma especificação, um revisor, um dono de produto. A quinta verificação protege o que você já tinha.

O portão também precisa de regra de parada

Um portão que o agente pode tentar infinitas vezes vira problema de busca. Com tentativas suficientes, o agente pode esbarrar em uma configuração que passa por motivos que ninguém pretendia. A Runtime recomenda limitar o número de submissões, e o texto diz que “three works for most tasks”, ou seja, três bastam para a maioria das tarefas.

Trate esse número como ponto de partida sugerido por um fornecedor. O princípio pesa mais do que o valor: um orçamento fixo de tentativas contra o portão. O que nós acrescentaríamos é o passo seguinte. Quando o orçamento acaba, uma pessoa olha o trabalho. O limite transforma falha repetida em sinal para alguém agir.

Onde fica um segundo agente

Uma reação tentadora ao achado da Vals é colocar um segundo agente no trabalho. Nesses mesmos nove apps, a Vals diz que o time “built those features, and its lead reviewed the separately built parts against each other”: construiu as funcionalidades, e o agente líder conferiu as partes construídas separadamente umas contra as outras. Em todos os 50 apps, com cada configuração rodada uma vez, “Teams cost 1.8 to 5.1 times as much as single agents, and only one difference in score was statistically significant”. Os times custaram de 1,8 a 5,1 vezes mais, e só uma diferença de nota foi estatisticamente significativa.

A própria Vals faz a ressalva: o trabalho foi de apps web full-stack em um único benchmark, e os resultados “may not carry over to other kinds of work”, podem não valer para outros tipos de trabalho. Com cada configuração rodada uma vez, a comparação está longe de encerrada. O que os dados sustentam é mais estreito e ainda útil. Pagar de 1,8 a 5,1 vezes mais por um time rendeu nota significativamente melhor em só uma de quatro comparações.

Esta leitura é nossa, não da Vals: o líder ajudou porque revisou partes que não construiu. É o princípio de Stack comprado com mais agentes. Um portão que roda expectativas que os agentes produtores não conseguem editar obtém a mesma separação sem pagar por um segundo produtor.

Para entender por que a impressão na revisão pode enganar, veja nossa nota anterior sobre dívida de agente e o paradoxo da verificação.

Faça isto agora

Escolha um repositório em que agentes abrem pull requests. Depois responda quatro perguntas com o time de plataforma:

Onde as verificações rodam? Se o ambiente do próprio agente produz o resultado que libera o merge, mova a execução para uma sandbox ou um job de CI que o agente não consegue modificar.
O agente pode alterar arquivos de teste no mesmo pull request que altera o código? Se pode, adicione as verificações três e quatro da Runtime como falhas bloqueantes: nenhum teste removido, nada recém-marcado como skip ou focus.
Vocês rodam os testes do branch base contra o código novo? Segundo a Runtime, essa é a verificação que pega uma asserção afrouxada. Faça checkout do diretório de testes do branch de destino, rode contra o código do pull request e encaminhe o pull request a uma pessoa se algo que passava agora falha.
Quantas vezes o agente pode reenviar? Defina um limite. Comece pela sugestão de três do fornecedor se não tiver referência melhor, e encaminhe o trabalho para uma pessoa quando o limite for atingido.

Nada disso exige um modelo novo ou um fornecedor novo. Exige decidir, por escrito, que o agente fica sem a caneta dos testes que o julgam.

Fontes

Runtime. “Don’t merge what you didn’t run: a test gate for agent-written code.” Outubro de 2026.
Paul Stack. “Why Agent-Written Code Needs Product Verification.” Outubro de 2026.
Vals AI. “Do Agent Teams Pay Off? A Case Study on Vibe Code Bench.” Outubro de 2026.

A Victorino ajuda times de engenharia a desenhar portões de merge em que o agente não consegue editar as verificações que julgam o próprio trabalho: contato@victorino.com.br | www.victorino.com.br