Codex piorando não é magia: reduza erros e depois reinicie o contexto

Primeiro, a versão curta:

1. Adicione DO NOT send optional commentary ao seu AGENTS.md, globalmente ou no nível do projeto. Isso pode reduzir a chance de o Codex “piorar”.
2. A IA é instável, mas criativa, muito parecida com pessoas. Ela consegue resolver problemas que software puramente determinístico não resolve. Nosso trabalho é encontrar o equilíbrio entre os dois.
3. Quando você encontrar uma falha estranha, pense uma camada mais fundo. Muitas vezes há uma mitigação prática escondida na forma do problema.

---

Quando as pessoas sentem que o Codex está “piorando”, não acho que isso signifique necessariamente que o provedor enfraqueceu o modelo de propósito. Uma explicação mais útil é que, em certo momento, em certa versão ou dentro de certo contexto, a probabilidade de erros subiu. IA não é estável como software tradicional, em que a mesma lógica produz de forma confiável o mesmo resultado. Cada passo é gerado a partir de um contexto com alguma aleatoriedade. Quando tudo vai bem, isso parece colaboração. Quando dá errado, o contexto vira um amplificador: uma explicação ruim, uma chamada de ferramenta falsa ou uma suposição não verificada podem entrar no contexto e afetar o próximo julgamento.

Então, quando a IA comete um erro ocasional, o maior problema não é a resposta defeituosa em si. O problema é que essa resposta vira material para respostas futuras. Se você continuar perguntando, o modelo pode tratar o erro anterior como fato. Se pedir para corrigir, ele pode continuar remendando em torno da premissa errada. Se adicionar mais contexto, ele pode encontrar mais ruído para costurar em uma nova explicação. É isso que muita gente sente como “piorar”, ou como ficar preso em um loop.

DO NOT send optional commentary

Hoje vi uma publicação no X dizendo que adicionar DO NOT send optional commentary ao AGENTS.md pode melhorar muito a degradação do Codex 5.5.

Fui atrás da origem e encontrei a discussão original no Linux.do. No ambiente de teste do autor, a precisão melhorou de forma visível, mas o autor também enfatizou repetidamente que isso apenas mitiga o problema. Não o elimina.

Acho que essa observação combina com minha própria hipótese. A frase não é uma mágica. Ela funciona porque reduz a saída opcional do modelo. Quando o Codex trabalha, ele frequentemente adiciona explicações intermediárias, notas de progresso, palpites e resumos ao redor da tarefa real. Em condições normais, essas palavras ajudam na comunicação. Mas quando o modelo está em um estado ruim, essas palavras “opcionais” podem virar contaminação: ele pode tirar conclusões cedo demais, descrever passos que não aconteceram, ou misturar chamadas de ferramenta com linguagem natural.

Falar menos não torna o modelo mais inteligente. Mas, com menos contexto irrelevante, há menos chances de o modelo se desviar por conta própria.

Isso não é apenas um problema do Codex

Já encontrei o mesmo tipo de problema com o Claude. O modelo imprimiu um texto que parecia uma invocação de ferramenta em vez de continuar normalmente o fluxo de prévia. Depois, o mesmo problema continuou aparecendo naquela conversa. Assim que mudei para outra conversa, o problema desapareceu de repente. Esse tipo de comportamento sugere que a questão não está apenas dentro de um modelo. Ela também pode acontecer na cadeia de ferramentas do agente: modelo, prompt do sistema, protocolo de ferramentas, janela de contexto e estado atual do serviço precisam estar alinhados. Se qualquer parte treme, a saída pode ficar instável.

Quando esse sinal aparece, continuar pedindo correções dentro da mesma conversa muitas vezes não é recuperação. Pode aumentar a contaminação, porque o modelo já escreveu no contexto um relato de “o que acabou de acontecer”, mesmo que esse relato esteja errado.

Duas direções: prevenção e corte de perdas

A primeira direção é reduzir a probabilidade de erro. Coloque regras de projeto no AGENTS.md. Faça o agente ler o código antes de editar. Reduza comentários desnecessários. Divida tarefas grandes em objetivos menores. Peça que ele rode testes e relate os resultados de verificação. Exija que hipóteses importantes sejam checadas primeiro. Nenhuma dessas práticas torna a IA perfeitamente confiável. Elas reduzem o espaço que o modelo tem para improvisar em áreas incertas.

A segunda direção é cortar perdas cedo. Se ele continua corrigindo o mesmo bug, escreve explicações cada vez mais longas enquanto o código não melhora, quebra o formato de saída esperado, imprime chamadas de ferramenta como texto ou ignora restrições que você acabou de dar, não tente resgatar o mesmo fio indefinidamente. Normalmente, o melhor movimento é começar uma nova conversa e fornecer um resumo limpo e comprimido: objetivo, erro atual, arquivos-chave e fatos já verificados.

Essa também é uma das forças dos agentes: eles salvam produtos de trabalho no disco, então você pode usar várias conversas para concluir uma única tarefa.

Trate isso como higiene de engenharia. Quando o contexto está sujo, limpe o contexto. Quando a tarefa é grande demais, divida. Quando a saída começa a contaminar a si mesma, corte a cadeia.

Conclusão

A degradação do Codex não é magia, e uma linha de prompt não resolve tudo. Ela é melhor entendida como um problema de probabilidade somado a um problema de contexto: às vezes os erros ficam mais prováveis, e quando um erro entra no contexto, os erros seguintes também ficam mais prováveis.

Vale a pena testar DO NOT send optional commentary, porque o custo é baixo e a troca é clara: você recebe menos notas intermediárias. Mas o hábito mais amplo importa mais. Reduza ruído quando puder, verifique quando puder e, quando a conversa começar a entrar em loop, não lute contra o loop. Leve o trabalho para uma conversa limpa e continue a partir dali.

Se você tiver práticas melhores, gostaria de conhecê-las. Se tiver dúvidas sobre uso de agentes de IA ou vibe coding, deixe um comentário para discutirmos.