Vale a pena usar um agente de IA para revisar o código que o outro escreveu?

Mandar um agente revisar o que o outro escreveu virou o novo "pedir pra alguém dar uma olhada"

Só que a conta nem sempre fecha 🙂

A prática pegou por um motivo fácil de entender: se o Claude Code escreveu, ele já está meio apaixonado pelo próprio resultado, então você chama o Codex pra olhar com outro olho

A aposta faz sentido no papel

O problema aparece depois, quando chega uma lista de dez achados e você gasta a tarde provando que sete deles não eram nada

Antes de seguir, vale lembrar que a IA revisar o próprio código é uma discussão que não some só porque você trocou de agente

O que cada agente entende por "revisar"

"Revisar" não quer dizer exatamente a mesma coisa dos dois lados, e é aí que mora a diferença de resultado

O /code-review do Claude Code:

O /code-review roda no terminal e não depende do GitHub App

Ele revisa um diff ali mesmo e reporta bugs de correção mais limpezas de reuso, simplificação e eficiência

O /review hoje é alias de /code-review, ou seja, os dois caem no mesmo comando. Antes da v2.1.223 o /review era um comando separado: passada única, somente leitura, sobre um pull request do GitHub

No comando unificado de hoje o escopo padrão é outro: ele revisa os commits do branch à frente do upstream mais as mudanças não commitadas. E aceita alvo explícito: caminho de arquivo, número de PR, nome de branch ou intervalo de refs, tipo main...my-feature

Duas flags mudam o que acontece depois: --fix aplica os achados na working tree ao fim da revisão, e --comment publica os achados como comentários inline no PR

O nível de esforço vai de low, medium, high, max até ultra

Em low e medium ele reporta só os achados de maior confiança (menos falso positivo). De high a max a cobertura aumenta e podem entrar achados menos certos

Se liga nisso: sem nível digitado, ele reutiliza o último nível de low a max que você usou, mesmo de sessão anterior. Ou seja, aquele max de ontem pode estar te esperando hoje 😀

Cada achado vem com uma seção de raciocínio estendido colapsável, explicando por que aquilo foi sinalizado e como foi verificado, e cada comentário de revisão chega com 👍 e 👎 já anexados na interface do GitHub

A documentação completa está no Code Review do Claude Code

O /review do Codex CLI:

No Codex CLI a lógica é outra: você digita /review no compositor, ele abre os presets de revisão e lança um revisor dedicado

Esse revisor lê o diff selecionado e reporta achados priorizados sem tocar na working tree

São dois presets: revisar contra um branch base (ele encontra o merge base e revisa o diff do branch) ou revisar mudanças não commitadas (incluindo staged, unstaged e untracked)

Por padrão a revisão usa o modelo da sessão atual, mas dá pra definir review_model no config.toml pra sobrescrever

E tem um detalhe que muda o tom dos achados: o Codex Code Review pode usar regras customizadas do repositório declaradas no AGENTS.md, o mesmo arquivo que já guia as tarefas de código, e aponta o autor pra diretriz por trás de cada achado

Claude Code x Codex: como as duas revisões se comportam

E tem coisa que só existe de um lado

O controle de esforço (low, medium, high, max, ultra) e a publicação inline no PR com --comment são do Claude Code

As regras customizadas do repositório no AGENTS.md e o review_model fixo no config.toml são do Codex

Onde a segunda opinião pega erro de verdade e onde só gera ruído

Onde compensa:

• Diff fechado de branch: quando existe um recorte claro (o intervalo de refs no Claude Code, o preset de branch base no Codex), o revisor sabe exatamente o que é novo e o que é paisagem
• Aquilo que você mesmo escreveu no piloto automático: código aceito rápido demais é justamente o que ninguém releu
• Regras de projeto declaradas no AGENTS.md: se o outro agente nunca teve essas regras em contexto, a revisão do Codex compara contra a diretriz e ainda te mostra qual é ela
• PR grande: aqui subir o esforço pra high ou max faz sentido, porque a cobertura maior tem onde pegar

Onde vira ruído:

• Nível alto em mudança trivial: você pediu cobertura ampla num diff de três linhas, então ele vai te entregar achados menos certos e você vai investigar cada um
• Revisão sem alvo explícito: o escopo padrão do /code-review pega commits do branch à frente do upstream mais o não commitado, e às vezes isso é muito mais do que você queria discutir agora
• Achado de estilo que já é decisão do projeto: se a escolha foi consciente e não está escrita em lugar nenhum, o revisor vai insistir nela toda vez

O trade-off é literalmente esse: low e medium te dão menos coisa e mais confiança, high e max te dão mais coisa e mais dúvida

Não existe nível "melhor", existe nível certo pro tamanho do que você mudou

Como pedir a revisão sem receber uma reescrita inteira

Se o seu problema ainda é o passo anterior, revisar o código antes de commitar tem um post só sobre isso

Aqui a ideia é outra: manter a revisão como revisão

1. Feche o alvo em vez de aceitar o escopo padrão

/code-review main...my-feature

O erro comum deste passo: rodar sem alvo e depois reclamar que ele comentou arquivo que você nem tocou hoje

2. Escolha o nível de esforço na mão

/code-review low

O erro comum deste passo: não digitar nada e esquecer que ele reutiliza o último nível de low a max usado, mesmo de sessão anterior

3. Deixe a revisão em modo de leitura

Não passe --fix na primeira rodada: essa flag aplica os achados na working tree depois da revisão

Quando o destino é o PR, o caminho é --comment, que publica os achados como comentários inline

/code-review --comment 1234

O erro comum deste passo (o clássico): aceitar --fix de primeira e perder a fronteira entre revisar e reescrever

4. No Codex, escolha o preset certo e, se quiser, fixe o revisor

Branch base pra diff fechado, não commitadas pra o que ainda está solto na máquina

review_model = "<o modelo que você quer só no revisor>"

O erro comum deste passo: usar o preset de não commitadas achando que ele vai olhar o branch inteiro

5. Rode o Codex de dentro do Claude Code, se preferir não trocar de terminal

Existe um plugin publicado na conta oficial da OpenAI, o openai/codex-plugin-cc, descrito como "Use Codex from Claude Code to review code or delegate tasks"

/plugin marketplace add openai/codex-plugin-cc
/plugin install <nome-do-plugin>@<marketplace>
/codex:setup
/codex:review

O /codex:review roda uma revisão normal do Codex sobre o trabalho atual, com a mesma qualidade de rodar /review dentro do Codex

O /codex:setup te diz se o Codex está pronto e, se estiver faltando e houver npm disponível, pode oferecer instalar

O plugin ainda traz /codex:rescue, /codex:transfer, /codex:status, /codex:result e /codex:cancel pra delegar trabalho, transferir sessões e gerenciar jobs em background. O /codex:transfer cria uma thread persistente do Codex a partir da sessão atual e imprime um comando codex resume, ótimo pra quando você começou a depuração no Claude Code e quer seguir com o mesmo contexto do outro lado

O erro comum deste passo: esquecer que o plugin usa a autenticação local do Codex CLI. Quem já está logado segue funcionando, quem nunca usou precisa entrar no Codex com conta ChatGPT ou com API key

E só pra fechar o mapa: depois de adicionar o marketplace, a instalação é /plugin install <nome-do-plugin>@<marketplace>, e o Claude Code copia cada plugin instalado pro cache local versionado em ~/.claude/plugins/cache. Dá pra abreviar /plugin marketplace como /plugin market e remove como rm

O que a prática mostrou sobre confiar em achado de agente

Eu não coloquei o /code-review e o /review um contra o outro pra medir quem pega mais bug, então não vou te dar número de eficácia aqui

O que eu tenho pra contar é de um vizinho muito próximo desse problema

No vídeo abaixo eu mostro uma ferramenta que varre o projeto atrás de código morto, duplicado e esquecido

Quando testei, rodei ela num projeto de teste pequeno e mesmo assim apareceram exports não utilizados, dependências não utilizadas, trechos duplicados e funções com alta complexidade

Usei primeiro o modo de resumo, pra ver o panorama antes de mexer em qualquer arquivo

Depois rodei a correção em modo de simulação, pra ler exatamente o que seria removido antes de aplicar de fato, e pedi a mesma saída em JSON pra enxergar tipo do ajuste, caminho, linha e nome do recurso

Aí veio a parte interessante: apliquei a correção de verdade, rodei de novo e ainda sobrou código morto e duplicação

Ela é conservadora e deixa parado o que julga precisar de olhar humano

E o resumo diz que o problema existe, mas não diz onde: pra localizar cada caso eu precisei rodar os comandos específicos de código morto e de duplicados

Esse é o paralelo com a revisão cruzada

Ferramenta determinística já assume a fronteira: "isso aqui eu não apago, decide você"

Revisor por IA não tem essa fronteira desenhada, e é exatamente pra isso que existem os níveis low e medium (poucos achados, alta confiança) contra high e max (mais cobertura, mais incerteza)

Nos dois casos o gargalo é o mesmo: a triagem humana

Cada falso positivo custa o seu tempo, não o do agente

Tome cuidado com a correção automática às cegas: uma dependência apontada como não usada pode ter sido desativada de propósito e voltar a ser usada depois, então o processo tem que ser milimétrico

O dono do projeto precisa ter ciência do que está sendo apagado, e o cuidado cresce quando o projeto não é só seu

O fluxo que eu recomendo é esse: roda a análise, olha o que sobrou e usa uma IA de programação pra julgar caso a caso, principalmente se você não tem experiência com a linguagem ou com a stack do projeto

Porque no vibe coding a IA cria funcionalidade mais rápido do que qualquer pessoa consegue revisar, e a janela de contexto limitada faz ela esquecer o que já existe e duplicar código

Muita gente que usa vibe coding não vem de programação, então "revisa o código gerado" deixa de ser uma opção manual realista

E esse acúmulo de código morto e duplicado é lixo que só penaliza o projeto com o tempo, virando bola de neve e podendo gerar bug

Detalhe pessoal: eu vinha testando bastante o Codex e gostando dos resultados, e na minha percepção o limite de uso entrega bastante pelo que se paga, diferente da situação atual do concorrente

O que não me faz aceitar achado dele sem ler, beleza? 😛

Veredito: quando a revisão cruzada compensa

Pra quem trabalha sozinho em branch curto: compensa como leitura, não como correção. Alvo fechado, nível baixo, --fix fora. Você quer saber se passou bug de correção, não quer um refactor de brinde

Pra quem abre PR em time: aí a coisa muda de figura. --comment põe os achados inline no PR, o raciocínio estendido colapsável explica por que aquilo foi sinalizado e como foi verificado, e o 👍 👎 de um clique deixa o time marcar o que prestou. Do lado do Codex, as regras no AGENTS.md fazem o revisor apontar a diretriz do projeto em vez de opinar solto

Sobre disponibilidade: o Code Review automático via GitHub App está em research preview e disponível pra assinaturas Team e Enterprise, e não está disponível pra organizações com Zero Data Retention habilitado. Nos demais planos a alternativa é revisar o diff localmente com /code-review

Se for instalar o GitHub App, saiba o que ele pede: Contents (leitura e escrita), Issues (leitura e escrita) e Pull requests (leitura e escrita)

Sobre o ultra: /code-review ultra dispara uma revisão multiagente na nuvem. Pra usuários Pro e Max são três ultrareviews gratuitos como cota única por conta, que não se renova. Depois disso a revisão custa tipicamente de US$ 5 a US$ 25 em créditos de uso, conforme o tamanho da mudança, e a conta ou organização precisa ter créditos de uso habilitados

Ou seja: ultra não é o seu comando de todo dia, é o que você guarda pra mudança grande de verdade

Conclusão

A regra prática cabe em uma linha: revisão com alvo fechado e sem escrita

Alvo fechado porque escopo padrão varre mais do que você quer discutir agora, e sem escrita porque o momento de revisar não é o momento de aplicar

O próximo passo é bem concreto: antes de subir o próximo PR, roda uma revisão de leitura no diff atual em nível baixo

Se os achados justificarem, aí sim você escala o esforço

Se não justificarem, você economizou uma tarde de investigação e seguiu a vida 🙂

até o próximo post!