Seu plan.md precisa de um advogado do diabo (e Codex se oferece como voluntário)

Você já escreveu um plano técnico às onze da noite, convencido de que estava impecável, e então descobriu pela manhã que esqueceu da autenticação?

Eu já passei por isso. Mais de uma vez. E o pior não é o fato de esquecer — é que, quando você usa uma IA para planejar, o plano parece tão coerente que seu cérebro para de procurar falhas. Claude gera um documento com seções, dependências, ordem de execução, e tudo se encaixa. Parece um plano feito por um engenheiro sênior. Mas ninguém o contestou.

Aseem Shrey publicou um artigo que aborda esse problema e propõe uma solução elegante: usar um segundo modelo para revisar o plano feito pelo primeiro. E não apenas uma vez — mas em um ciclo contínuo, até que o revisor declare: “aprovado”.

O problema: ninguém contesta sua IA

Quando você utiliza apenas um modelo para planejar e executar, obtém um resultado coerente, mas não questionado. A IA não se contradiz. Ela não vai dizer “olha, esse modelo de autenticação está incompleto” nem “a citação do seu script shell está quebrada”.

É como se você escrevesse um documento, revisasse sozinho e concluísse “está perfeito”. É claro que parece ótimo — foi você quem escreveu. Preste atenção nisso: a revisão por pares existe na ciência, engenharia e na medicina por uma razão. Não porque os autores sejam incompetentes, mas sim porque o criador é o pior revisor da própria obra.

Já escrevi sobre isso quando construi meu conselho Jedi para revisão de código por IA. Mas ali eu falava sobre revisar código. O que Aseem propõe é revisar o planejamento antes mesmo de escrever uma única linha. Ou seja, atacar o problema uma etapa antes.

Como funciona: Claude planeja, Codex revisa

A mecânica é um skill do Claude Code — um arquivo Markdown, sem infraestrutura, sem serviços externos. Quando você invoca /codex-review:

1. Claude escreve o plano em um arquivo temporário.
2. O plano é enviado para o Codex CLI em modo read-only (ele pode consultar a base de código para contexto, mas não faz alterações).
3. Codex revisa e retorna um veredicto: VERDICT: APPROVED ou VERDICT: REVISE.
4. Se a resposta for REVISE, Claude faz as correções e reenvia. O truque aqui é que Codex retoma a sessão anterior, lembrando o que foi dito e garantindo se o problema foi realmente corrigido.
5. No máximo, 5 rodadas. Na prática, 3 são suficientes.

Simplificando: é um pull request entre duas IAs, onde uma propõe e a outra tenta encontrar problemas. Sem intervenção humana.

14 bugs em 3 rodadas

No exemplo do artigo — um dashboard para um enxame de agentes — o ciclo encontrou 14 problemas no plano original:

Rodada 1 (8 problemas): Sem autenticação nos endpoints de escrita. Bugs de citação em scripts shell. Campos de esquema se sobrepondo. Arrays embutidos sem limite. Sem gestão de concorrência. Estratégia de teste apenas manual.

Rodada 2 (6 problemas restantes): Claims não atômicos. Permissões ACL muito amplas. Rotação de chaves não especificada. Modelagem de estados inconsistente.

Rodada 3: Tudo resolvido. Plano aprovado.

A tabela de antes e depois resume bem o impacto:

De zero problemas detectados para 14 encontrados e corrigidos. Sem precisar que um humano lesse uma única linha do plano.

Por que a iteração importa mais do que a revisão

Uma revisão de única rodada encontra problemas, mas não verifica correções. Aseem explica isso bem: o ciclo iterativo captura problemas do tipo “corrigi uma coisa mas quebrei outra”.

Isso é exatamente o que acontece na revisão de código real. Você aponta a alguém: “esse lock não é seguro”, a pessoa muda, e ao mudar introduz um deadlock em outro caminho. Se você só revisa uma vez, o problema passa batido. Se há duas revisões, ele é detectado.

O detalhe técnico que faz isso funcionar: o Codex suporta sessões com resume. Ele não começa do zero a cada rodada. Lembra o que foi dito, o que tinha que ser corrigido, e verifica se o ajuste foi feito corretamente — sem ser uma gambiarra que apenas transfere o problema para outro lugar.

O que eu quero experimentar

Depois de ler o artigo, fiquei com vontade de montar algo parecido. Uso o plan.md como etapa prévia em praticamente qualquer funcionalidade importante, e até agora eu mesmo faço a revisão. O que é praticamente dizer que ninguém revisa, porque depois de três horas mergulhado em uma história no Linear, minha capacidade crítica está esgotada.

A ideia de um /second-opinion me parece natural. Não para tudo — não vou passar por três rodadas de revisão para uma alteração de CSS. Mas para planos que envolvem modelos de dados, autenticação, concorrência ou qualquer coisa que levará dias para ser implementada, ter um adversário automático dizendo “e se dois agentes reclamarem o mesmo recurso ao mesmo tempo?” literalmente vale seu peso em ouro.

O que me atrai especialmente:

• É um arquivo Markdown. Sem servidor, sem API wrapper, sem dependências exóticas. Um SKILL.md e pronto.
• É sob demanda. Não executa em cada commit nem em cada planação. Você decide quando vale a pena. Continua firme apenas em projetos maiores.
• É adversarial por design. Você não pede ao revisor para “revisar o plano”. Você pede para encontrar falhas. Para tentar “quebrar” o planejamento. Essa intenção muda completamente o resultado.

A grande questão

Há uma pergunta óbvia que o artigo não responde completamente: você precisa especificamente do Codex, ou qualquer modelo pode servir como revisor?

Minha intuição diz que o essencial é que seja um modelo diferente. O valor está na diversidade de abordagens. Se Claude planeja e Claude revisa, é como revisar sozinho — ambos compartilham os mesmos pontos cegos. Inserir um modelo com treinamento diferente, com heurísticas diferentes, é o que realmente cria o efeito “advogado do diabo”.

Dito isso, a implementação com Codex CLI tem uma vantagem prática significativa: o suporte ao resume de sessões. O fato de o revisor recordar rodadas anteriores não é um luxo — é o que transforma isso em um ciclo real de melhoria, em vez de três revisões independentes que repetem os mesmos achados.

Quando não usar

O próprio Aseem menciona: quando a velocidade é mais importante do que a profundidade, não vale a pena. Um hotfix em produção às três da manhã não precisa de três rodadas de revisão adversarial. Precisa de um patch, um teste e um deploy.

Também imagino que para planos pequenos — “adicionar um campo a um formulário” — o custo-benefício não compensa. Minha regra é: se o plano tem mais de uma página ou envolve algo compartilhado por mais de dois módulos, merece um /second-opinion.

A lição

O mais interessante nessa ideia não é a implementação técnica — que é simples. É a mudança de mentalidade. Até agora, o consenso era “use IA para planejar, depois execute o plano”. Ninguém questionava o plano. O plano era sagrado porque havia sido gerado por um modelo inteligente.

Mas um plano não revisado é um plano com bugs latentes. Não importa se foi escrito pelo GPT-4, Claude, Codex ou por um engenheiro com vinte anos de experiência. Sem revisão adversarial, sem alguém dizendo “e se isso falhar?”, você está jogando roleta com uma complexidade que ainda não viu.

Um arquivo Markdown. Dois modelos. Três rodadas. 14 bugs a menos. Nada mal para algo que cabe em um simples gist.