Quando a IA diz "está pronto", o mecanismo que não acredita nela

Trabalhando com agentes de IA para programação, existe uma frase que mais me engana. "Está tudo pronto."

O agente diz isso com facilidade demais. Sem ter rodado o teste de verdade, diz "o teste deve passar", e sem ter reproduzido o bug, diz "corrigi a causa". Quando você lê o código, parece plausível. Mas quando você roda o comando de fato, metade das vezes não está pronto. Depois de passar muito tempo com isso, cheguei a uma conclusão. O problema não é a IA mentir, e sim o fato de eu, uma pessoa, estar julgando a cada vez se devia acreditar naquela palavra ou não.

Não é uma questão de confiança, e sim de prova

Trabalhando sozinho, escrevo quase todo o código junto com a IA. E aí, dezenas de vezes por dia, decido "posso aceitar essa mudança?". No começo, eu lia o relatório do agente a cada vez e, quando desconfiava, rodava o comando eu mesmo para conferir. O problema desse método é que a conferência depende de mim. Num dia cansado, num dia corrido, no dia em que faço a décima tarefa parecida, eu deixo passar com um "se disse que está pronto, deve estar". E é justamente no que deixo passar assim que o acidente acontece.

Por isso, mudei de direção. Em vez de eu desconfiar toda vez, fiz o sistema exigir evidências. Cravei no harness um portão que impede o agente de encerrar a rodada apenas dizendo "terminei". A conclusão deixou de ser uma declaração e virou uma verificação que precisa ser aprovada.

A raiz dessa ideia é simples. Quanto mais barato a IA cospe código, mais o gargalo se desloca da produção para a verificação. Quando o custo de produzir código se aproxima de zero, "confiar que aquilo está certo" passa a ser, relativamente, o trabalho mais caro. Se é assim, esse trabalho caro não deveria ficar à mercê do humor pontual de uma pessoa, e sim virar um procedimento imposto automaticamente.

O hook que bloqueia o encerramento

Concretamente, uso um hook que se intromete no momento do encerramento. Quando o agente declara que terminou a tarefa e tenta encerrar a rodada, uma verificação roda logo antes disso. O que a verificação exige é uma coisa só. "Mostre a evidência de que terminou."

Sem evidência, o encerramento é recusado. O agente é mandado de volta. Junto com a mensagem "você não provou a conclusão, então continue". Aí, só então, o agente roda o teste, executa o comando e cola a saída. O engraçado é que, nesse processo, metade das vezes ele mesmo diz "ah, ainda não terminei" e vai de fato concluir o que faltava. Quando disse que estava pronto, não estava pronto de verdade.

O ponto central é que esse portão é uma máquina, não uma pessoa. Esteja eu cansado ou apressado, o portão é igualmente rigoroso. Minha disciplina oscila, mas a disciplina do hook não oscila. Transformei a verificação em infraestrutura, não em hábito.

O que conta como evidência

Então, o que aceito como "evidência"? Uso quatro tipos.

1. Saída de comando. Se o teste passou, tem que existir a saída real do executor de testes. Não um "vai passar", e sim o log do que passou. Se o build rodou, o log do build; se o lint está limpo, a saída do lint.
2. diff. O que foi mudado tem que aparecer no diff. Não um "corrigi essa função" falado, e sim as linhas alteradas tal como estão. É aqui que se filtra se o escopo da mudança bate com o relatório.
3. Reprodução. Se um bug foi corrigido, tem que haver, em par, a evidência de que ele realmente se reproduzia antes da correção e a evidência de que ele sumiu depois. Sem o before/after, o "corrigi" não passa de um palpite.
4. Verificação cruzada. Mudanças importantes eu mando outro modelo revisar. O que o Claude escreveu, o Codex revisa, e um aponta o ponto cego do outro. Isso pega muito mais do que um modelo julgando o próprio trabalho sozinho.

O que esses quatro têm em comum é que todos são fatos reproduzíveis. Não opinião, e sim saída que dá para colar. É aqui que está a razão de a IA não poder ser o juiz final. Definir o critério de "bom" e julgar qual saída satisfaz esse critério acaba ficando por conta da pessoa. Só que, em vez de fazer esse julgamento à mão toda vez, o procedimento de julgamento é solidificado em código.

Por que isso também é bom para a pessoa

Depois de erguer o portão, houve um efeito que eu não esperava. Não foi só o agente que ganhou disciplina - eu também fiquei mais aliviado.

Antes, meu trabalho era ler o relatório e desconfiar "isso está pronto mesmo?". Agora, quem faz esse trabalho é o hook. O material que chega até mim já vem com a evidência anexada. Eu reviso a evidência, não checo antes se existe evidência. É como se a linha de partida do julgamento tivesse avançado uma casa.

E isso também é um registro que deixo para o eu do futuro. Fica gravado, junto com a saída de comando daquele momento, por que uma mudança é segura. Um mês depois, quando bate o "por que fiz assim mesmo?", a justificativa está anexada ao lado do commit.

O único músculo novo a desenvolver

Fala-se de uma porção de habilidades sobre como trabalhar com IA, mas o que mais ficou para mim foi isto. Não dependa de você mesmo para a verificação - delegue-a ao sistema.

A técnica de escrever bons prompts envelhece quando o modelo muda. O truque que funcionava ontem não funciona no modelo novo. Mas a disciplina de "só reconhecer a conclusão por evidências" é uma camada acima do modelo, então não envelhece. Não importa qual modelo você use, nem por quantas gerações o modelo mude, o portão que exige evidências continua útil. Pelo contrário, quanto mais esperto o modelo fica, mais plausivelmente ele erra, e por isso o valor do portão sobe.

A IA aliviou o fardo de escrever código. Em troca, o trabalho que ela deixou para nós é o de julgar "posso confiar nisso?". Se você tentar fazer esse julgamento toda vez pela força de vontade de uma pessoa, você se esgota e as coisas vazam. Em vez disso, se você deixar a máquina exigir evidências, um portão que não se cansa fica lá, rigoroso, no seu lugar. Quanto mais alguém puser a IA para trabalhar, mais o que precisa de esmero não é "como mando fazer", e sim "como verifico a palavra de que está tudo pronto".