Duas IAs Revisando Seu Código São Melhor Que Uma — Claude + Codex Peer Review
Há um problema bem conhecido no desenvolvimento de software: a mesma pessoa que escreveu o código geralmente é a pior pessoa para revisá-lo. Você fica cego para seus próprios pressupostos. Lê o que quis escrever, não o que realmente escreveu.
O mesmo se aplica à IA.
Claude escreve algo, Claude revisa, e Claude tem exatamente as mesmas probabilidades de passar despercebido pelo mesmo tipo de erro. A solução — em equipes de engenharia humanas e cada vez mais em fluxos de trabalho com IA — é trazer uma segunda perspectiva.
Essa segunda perspectiva agora é Codex.
A lógica por trás da revisão por pares de IA
A ideia é direta: depois que Claude termina de implementar algo, você não aceita o output imediatamente. Você envia um segundo modelo — neste caso Codex do OpenAI — para revisar independentemente o trabalho, criticá-lo e trazer à tona qualquer coisa que possa ter sido negligenciada.
Modelos diferentes, treinados em dados diferentes, com arquiteturas diferentes, detectam coisas diferentes. Claude pode ser excelente em raciocínio arquitetônico e passar despercebido por um problema sutil de concorrência que Codex marca. O inverso também é igualmente verdadeiro. Que se revisem mutuamente é uma forma prática de se aproximar da correção sem esperar um ciclo completo de revisão humana.
A premissa não é que um seja melhor que o outro. É que a divergência entre modelos é um sinal de valor.
Duas implementações que vale a pena conhecer
hamelsmu/claude-review-loop — A opção prática para o dia a dia
Esta é provavelmente a implementação mais útil para uso cotidiano. Instale como plugin do Claude Code e obtenha um novo comando /review-loop. O que acontece internamente:
- Você descreve uma tarefa. Claude a implementa.
- Quando Claude termina, um Stop hook intercepta a saída — antes de qualquer mudança chegar ao seu codebase.
- Codex inicia (até 4 sub-agentes em paralelo, dependendo do tipo de projeto) e revisa independentemente o que Claude escreveu.
- A revisão é consolidada e escrita em
reviews/review-<id>.md. - Claude recebe o feedback e deve resolvê-lo antes de poder assinar o trabalho.
Cada tarefa recebe uma segunda opinião independente antes de você aceitar qualquer mudança. O ciclo de revisão ocorre automaticamente — você não precisa disparar manualmente.
claude plugin marketplace add hamelsmu/claude-review-loop
claude plugin install review-loop@hamel-review
Depois em qualquer sessão do Claude Code:
/review-loop
alecnielsen/adversarial-review — O debate estruturado
Esta implementação adota uma abordagem mais rigorosa. Executa quatro fases:
- Revisão independente — Claude e Codex revisam o código separadamente.
- Revisão cruzada — cada modelo lê e critica os achados do outro.
- Meta-revisão — cada um responde à crítica recebida.
- Síntese — Claude avalia todos os artefatos do debate, decide quais problemas são válidos e implementa correções com confiança alta ou média.
Depois o loop se repete até que ambos os agentes reportem que não há problemas restantes.
É mais exaustivo e mais custoso em tokens que o review loop. Vale a pena para decisões de arquitetura e código sensível à segurança. Provavelmente excessivo para um endpoint CRUD padrão.
O mecanismo de escalação
Ambas as implementações — e o plugin Agent-Peer-Review do Composio — compartilham uma característica particularmente útil: quando Claude e Codex genuinamente discordam, o workflow não simplesmente escolhe um lado.
Escala.
O desacordo é enviado para Perplexity ou busca na web para arbitragem externa — trazendo documentação atualizada, melhores práticas conhecidas ou conhecimento da comunidade para resolver o conflito. O resultado é uma resposta com fonte, não a posição de qualquer modelo que acabou sendo mais confiante.
Este é o detalhe que torna tudo praticamente útil. O output de IA confiante mas incorreto é um dos principais modos de falha no desenvolvimento assistido por IA. Incluir uma camada de “esses dois discordam, vamos buscar” captura uma porção significativa desses casos.
Para que usar (e para que não)
Este não é o fluxo correto para cada tarefa. Algumas diretrizes práticas:
Use para lógica complexa e código sensível à segurança. Fluxos de autenticação, processamento de pagamentos, qualquer coisa onde um bug sutil tem consequências reais. O ciclo de revisão extra vale o tempo investido.
Pule para boilerplate. Uma migração de dados simples ou um scaffold não precisam de revisão adversarial. Você gastará mais tokens do que o risco justifica.
Use como benchmark. Execute ambos os modelos contra o mesmo problema antes de uma decisão arquitetônica importante. Onde concordam, você tem alta confiança. Onde diferem, você tem um sinal interessante que vale a pena investigar.
O tradeoff honesto
Você está duplicando (ou mais) seu uso de tokens e adicionando latência a cada tarefa. Isso é real.
Mas se você já está no Claude Code fazendo trabalho com consequências, a alternativa é enviar código que uma IA revisou uma vez e chamá-lo de pronto. Para qualquer coisa onde a correção realmente importa, o custo de uma segunda opinião geralmente é menor que o custo do bug que previne.
A revisão por pares de duas IAs não é uma bala de prata. É uma melhoria estrutural em um fluxo de trabalho que de outra forma seria inerentemente unilateral.
Links
- claude-review-loop: github.com/hamelsmu/claude-review-loop
- adversarial-review: github.com/alecnielsen/adversarial-review
- Composio Agent-Peer-Review: github.com/composio/awesome-claude-plugins