Por que peço aos meus agentes de código para questionarem o próprio trabalho

Eu sempre questiono o que os agentes me entregam. Se aparece uma abstração nova no diff, quero entender por que ela precisa existir. Quando a resposta diz que um problema foi resolvido, quero saber o que foi verificado para chegar àquela conclusão.

Também espero que esse cuidado alcance os meus pedidos. Posso sugerir uma implementação que parece boa antes de olhar o código, mas deixa de fazer sentido depois. Prefiro que o agente aponte isso a seguir a sugestão sem questionar.

Uma das coisas que fiz foi levar essa cobrança para as instruções globais do agente. A intenção era que ele revisasse as próprias decisões durante o trabalho, sem depender de uma pergunta minha no final.

Por aqui, tem funcionado. Mas vale explicar o que estou tentando conseguir com isso e onde estão os limites.

O trecho que coloquei nas instruções

O prompt é este:

Questione suas próprias premissas, plano e ações durante toda a execução. Verifique se cada mudança contribui para o objetivo real do usuário, quais efeitos colaterais e custos introduz e se existe uma solução mais simples.

Ajuste o plano quando novas evidências invalidarem a abordagem. Antes de concluir, valide o resultado em relação ao objetivo do usuário; apenas completar os passos planejados não demonstra sucesso.

A última frase resume bem a minha preocupação.

Imagine uma tarefa para corrigir a ordenação de uma listagem. O agente começa propondo alterações no backend, um serviço novo e uma reorganização no frontend. Durante a investigação, encontra uma segunda ordenação no componente, sobrescrevendo o resultado recebido da API.

Nesse exemplo, espero que ele reavalie o que ainda precisa ser feito. Talvez aquela estrutura nova tenha perdido a razão de existir. Seguir até o fim com ela só porque estava no plano inicial acrescentaria trabalho sem ajudar na correção.

É esse tipo de decisão que quero incentivar. Não preciso que o agente transforme cada tarefa em um debate, nem que invente objeções para demonstrar senso crítico.

Quanto ao arquivo, o caminho depende da ferramenta. No Codex, a configuração global padrão fica em ~/.codex/AGENTS.md; no Claude Code, em ~/.claude/CLAUDE.md. Portanto, ~/AGENTS.md não é um endereço universal. É preciso configurar o mecanismo que o seu harness realmente carrega. Essas instruções orientam o comportamento, mas não garantem obediência nem resultados idênticos entre projetos. (OpenAI Developers)

Questionar não basta para corrigir

Aqui existe uma ressalva importante: pedir ao modelo que revise uma resposta não garante que a próxima será melhor.

O trabalho Self-Refine, de 2023, encontrou ganhos usando ciclos estruturados de geração, feedback e revisão pelo próprio modelo. Já um estudo apresentado na ICLR 2024 encontrou dificuldades e, em alguns casos, piora quando os modelos tentavam corrigir o próprio raciocínio sem feedback externo. São resultados de métodos, tarefas e modelos específicos, não uma validação desse trecho no meu arquivo de instruções. (arXiv)

Isso muda o que eu considero uma revisão útil. Um agente dizer “reavaliei e está correto” ainda não me mostra como chegou àquela conclusão.

Voltando ao exemplo da listagem: ele pode executar o cenário que apresentava o erro, conferir o resultado e verificar se a correção preserva os outros critérios de ordenação. Em um teste de regressão, quero que o comportamento esperado venha do requisito, não apenas reproduza o que a implementação recém-escrita passou a fazer.

A documentação de engenharia da Anthropic recomenda justamente que agentes usem resultados do ambiente, como execução de código e respostas de ferramentas, para avaliar o próprio progresso. Também recomenda condições de parada para manter esses ciclos sob controle. (Anthropic)

Por isso, leio “questione suas próprias premissas” como um pedido para procurar evidências que sustentem ou contrariem uma decisão. Uma nova explicação, sozinha, não resolve essa dúvida.

Essa cobrança também tem custo

A expressão “durante toda a execução” merece cuidado. Minha intenção é manter esse critério presente, especialmente quando surgir informação nova ou uma decisão tiver impacto relevante. Não espero uma auditoria completa depois de cada linha alterada.

Se a instrução provocar verificações redundantes e reconsiderações sem motivo, haverá mais trabalho sem benefício correspondente. Um ajuste de texto não precisa receber o mesmo tratamento de uma alteração em uma regra de negócio.

Também não dá para reduzir essa discussão ao tamanho da janela de contexto. A Anthropic descreve perda de precisão conforme o contexto cresce e ressalta que janelas maiores continuam sujeitas a informação irrelevante e contexto poluído. Caber na janela não significa que todo o conteúdo será aproveitado igualmente bem. (Anthropic)

Há ainda um contraponto diretamente relacionado a arquivos de instruções. O estudo Evaluating AGENTS.md, publicado em fevereiro de 2026, encontrou resultados mistos: arquivos gerados por LLM tenderam a reduzir o sucesso nas tarefas avaliadas, enquanto os escritos por desenvolvedores trouxeram ganhos modestos. Ambos aumentaram o custo de execução. O trabalho avaliou instruções de repositório, não esse meu prompt global, mas reforça o cuidado com exigências adicionais que parecem úteis e acabam complicando a tarefa. (arXiv)

Minha leitura é que a própria instrução precisa entrar no review. Se eu cobro que cada mudança no código justifique sua existência, faz sentido cobrar o mesmo de cada regra que adiciono ao agente.

O que considero um bom resultado

Na minha experiência, esse trecho tem ajudado. Isso não permite atribuir todo bom resultado a ele: o modelo usado, o contexto disponível, a clareza do pedido e as ferramentas também fazem parte do fluxo.

Para avaliar melhor a instrução, eu compararia tarefas semelhantes com e sem ela, mantendo o modelo e as condições tão próximos quanto possível. Observaria principalmente o retrabalho necessário e as verificações realizadas, junto do tempo e do consumo. Uma resposta final mais convincente não seria suficiente para considerar a mudança um sucesso.

Continuo achando válido pedir que o agente questione o próprio trabalho. Só não quero confundir autocrítica com uma obrigação de encontrar defeitos, nem dar a ele liberdade para inventar um objetivo diferente do que foi pedido.

Quero que ele reconheça quando uma descoberta muda o diagnóstico, abandone alterações que perderam a necessidade e mostre o que conseguiu validar. Quando não conseguir verificar alguma coisa, prefiro que diga isso.

E, quando vier o “pronto”, eu ainda vou abrir o diff.