Mandar o Claude codar e o Codex criticar — um padrão prático para dividir dois agentes no mesmo repositório

Ultimamente, aumentou bastante no X e no Discord a quantidade de posts dizendo que “usam Claude Code e Codex juntos”, e como todo mundo falava bem, passei cerca de um mês instalando e rodando as duas ferramentas no mesmo repositório para ver se isso realmente fazia sentido. Quando fui tentar adotar de fato, percebi que havia uma tonelada de pontos de decisão: por onde começar o setup, como dividir o trabalho entre as duas ferramentas sem gerar conflito, se AGENTS.md e CLAUDE.md poderiam ser preenchidos com o mesmo conteúdo ou não. Então organizei isso em um currículo de 8 capítulos para ajudar quem ainda não conseguiu começar por estar com as mesmas dúvidas a reduzir tentativa e erro.

O workflow com dois agentes é simples. Se você pede para o mesmo modelo escrever o código e revisar o próprio código, ele tende a aceitar como válidas as mesmas premissas que usou ao implementar, e assim deixa passar lacunas. A estrutura, portanto, é colocar outro modelo ao lado como revisor advisory (sem bloqueio). O Claude Code fica como autor principal, e o Codex como revisor advisory. A questão central não é qual dos dois é mais inteligente, e sim o fato de serem modelos diferentes. No momento em que um passa a funcionar como gate do outro, o workflow se quebra, então a regra mais importante é nunca transformar o advisory em bloqueio.

Contexto — mudanças que revi ao organizar isso

• Pergunta antiga: “qual ferramenta de AI coding é a melhor?”
• Pergunta atual: “como dividir o trabalho entre duas ou mais ferramentas?” e “como cobrir os pontos cegos de uma ferramenta com outra?”
• Com os slash commands e subagentes do Claude Code, a separação entre review/exec no Codex e arquivos de contexto como AGENTS.md, este é o primeiro momento em que embutir uma estrutura dupla no workflow se tornou uma opção realmente prática

Pontos centrais do padrão de estrutura dupla (o que mais chamou atenção após um mês usando)

• advisory nunca é bloqueio — mesmo que o Codex identifique algo CRITICAL, o push continua passando. Se isso virar bloqueio uma única vez, uma queda do modelo já basta para parar todo o trabalho; e com um único falso positivo, o usuário começa a contornar o hook inteiro com --no-verify
• CLAUDE.md / AGENTS.md não devem ter o mesmo conteúdo — para o autor, “como construir”; para o revisor, “o que deve ser questionado”. Se mais de 80% do conteúdo se sobrepõe, é um sinal de que a divisão de responsabilidades na prática não existe
• codex review --base vs codex exec devem ser separados por caso de uso — review lê o git diretamente e é mais limpo, mas em PRs grandes os tokens explodem; em exec, você injeta o diff diretamente no prompt e consegue controlar melhor o custo. Um padrão é migrar para exec quando a mudança passa de 100 arquivos
• linha de defesa em duas etapas para segredos no pre-push hook — padrões de arquivo (.env, *.pem, secrets/) abortam o push; regex inline (sk-, ghp_, AKIA…) geram apenas aviso. O “never block” do advisory é uma regra para saída do modelo; já o push de arquivos secretos é um incidente de segurança diferente, então bloquear é a escolha correta
• absorver tudo com um único wrapper de graceful degradation — envelope JSON por padrão + --raw em Markdown, timeout nativo em bash, sempre exit 0. Quem chama só precisa desviar pelo status

O que mudou depois de usar por um mês

• aumentou a quantidade de bugs encontrados pouco antes do merge. Em vários casos, justamente onde o Claude estava confiante de que “ficou bem feito”, o Codex apontou race conditions e verificações de null ausentes
• quase desapareceu aquela situação de abrir o PR de novo no dia seguinte e pensar “ué, por que eu fiz isso assim?”. Como outra perspectiva já entrou uma vez, o custo de revisão de regressão cai
• a fadiga do self-review, de ficar olhando o próprio código, diminuiu de forma perceptível. O efeito é parecido com adicionar mais um revisor humano
• em mudanças difíceis de reverter, como SQL de migração e fluxo de pagamento, o maior impacto psicológico é saber que outro modelo analisou aquilo mais uma vez antes

Estrutura do currículo (8 capítulos, 5 partes)

• Parte 1: forma de pensar no uso conjunto de dois agentes · 1 capítulo — pontos cegos de um agente único, critérios para justificar o custo
• Parte 2: ambiente e contexto · 2 capítulos — setup base com VSCode + Claude Code + Codex CLI, divisão entre AGENTS.md e CLAUDE.md
• Parte 3: padrões de automação de review · 3 capítulos — script wrapper advisory, pipeline multifase com slash commands, automação com pre-push hook
• Parte 4: guia operacional · 1 capítulo — árvore de decisão de ferramenta por tipo de trabalho, guia de custo/modelo, seção Security & Privacy
• Parte 5: boilerplate · 1 capítulo — um pacote de templates de wrapper, hook e CLAUDE.md/AGENTS.md pronto para instalar no próprio repositório

O que pensei ao organizar tudo isso

• o verdadeiro valor da estrutura dupla está no fato de que “as duas ferramentas não viram gate uma da outra”. Se você permite bloqueio uma única vez, uma queda de um dos lados paralisa o trabalho; e com um único falso positivo, o usuário começa a ignorar o hook inteiro, tornando o próprio hook inútil
• quanto mais rápidas as ferramentas de AI ficam, mais parece que a variável decisiva deixa de ser “qual ferramenta usar” e passa a ser “como sobrepor e cobrir os pontos cegos de várias ferramentas”. É a mesma lógica de pedir code review humano para mais de uma pessoa
• estou compartilhando porque pode ser útil para quem trabalha com ferramentas de AI coding e não se sente totalmente seguro revisando o próprio código sozinho, ou para quem vem adiando a decisão de instalar Claude Code e Codex juntos. Se houver partes que entendi ou organizei errado, avisem nos comentários que eu corrijo.

[ku9cu]

Ouvi dizer que há pessoas que fazem assim, mas fico curioso sobre como seria na prática.
Se o desenvolvedor chama cada um diretamente quando precisa, sem agrupar as duas ferramentas como agentes separados,
ou se configuram para que o Codex faça a revisão automaticamente ao usar Git Hook.

[neostom432]

Nós acabamos nos estabelecendo no uso dos dois.

Colocamos uma fase de revisão cruzada com o Codex dentro do fluxo de slash command (no /ship, algo como planejamento → implementação → validação → revisão do Codex → relatório) e, ao mesmo tempo, também aplicamos a mesma revisão no pre-push hook. Se deixar só o slash command, na correria a pessoa simplesmente faz o push e a revisão acaba sendo pulada; se deixar só o hook, o resultado só aparece imediatamente antes do push, tarde demais.

Em ambos os caminhos, em vez de chamar o Codex CLI diretamente, os dois lados invocam da mesma forma um único script bash encapsulado (codex-review.sh). Esse script centraliza timeout, verificação de autenticação, checagem de secrets e formato de saída, então tanto no slash command quanto no hook o lado que chama fica mais limpo.

O ponto principal é que nunca bloqueamos com base no resultado da revisão do Codex. Mesmo que a CLI caia ou apareça um CRITICAL, o push continua passando e só exibimos o resultado. Se isso virar bloqueio uma única vez, quando o Codex marcar por engano um código que na prática não tem problema, o usuário vai recorrer à opção de contornar o hook para conseguir fazer push (git push --no-verify), e, quando isso vira hábito, é praticamente o mesmo que ter um hook configurado que nunca roda. Por isso, as verificações que realmente precisam bloquear (lint, tipos, testes, push de arquivos com secrets) ficam separadas em outros gates, e a opinião do modelo fica só como referência.

Os trechos do script, do slash command e do corpo do hook estão incluídos integralmente nos capítulos 4 a 6 do track, então talvez valha a pena consultar.