Claude Code e Codex em conjunto: 3 padrões de trabalho

Materiais práticos sobre trabalhar com agentes e vibe coding: documentação Ailoot.

Porque é que uma só ferramenta já não chega em 2026?#

Em maio de 2026, a OpenAI entrou no território da Anthropic com o modelo GPT-5.5 no Codex CLI. Em benchmarks recentes, Codex tem uma clara vantagem nas tarefas de terminal e no modo SWE-bench Verified. A Anthropic respondeu com Opus 4.8 e Dynamic Workflows, mantendo a liderança no SWE-bench Pro (um teste concebido para impedir fugas de dados, no qual treinar um modelo com o benchmark não ajuda). A comparação direta detalhada está no guia Codex vs Claude Code—aqui, vamos diretos à combinação dos dois.

Em 2026, não há um vencedor único. Predomina um padrão—as equipas mantêm Codex para trabalho autónomo económico e Claude Code para decisões de arquitetura arriscadas.

A principal diferença que determina como dividir o trabalho:

• Claude Code é o investigador. Sustenta um diálogo longo e aprofundado, questiona pressupostos e considera várias abordagens antes de escolher uma solução. É adequado quando a ação certa não é óbvia à partida.
• Codex é o executor. Recebe uma tarefa e avança até obter resultados num sandbox. É adequado para tarefas claras que exigem um ciclo rápido de «pedir e obter».

Se tiver ambas as ferramentas, não precisa de escolher entre «pensar» e «fazer». Atribui o trabalho de acordo com o tipo de tarefa. Se ainda não decidiu qual das duas instalar primeiro, encontrará uma comparação direta no guia Codex vs Claude Code.

Padrão 1: Claude Code escreve o código, Codex revê-o#

Neste padrão, Claude Code continua a ser o editor principal. Codex só intervém ao nível do PR, através do modo na cloud (Codex é executado diretamente a partir do ChatGPT ou da GitHub App, pelo que não precisa de um segundo terminal).

Como funciona na prática:

1. Passo 1: Escreva a funcionalidade no Claude Code

   Abra o repositório no VS Code, inicie o Claude Code, mude para Plan Mode e discuta a arquitetura da funcionalidade. Obtém código preliminar, testes e migrações. Faça commit para um ramo de funcionalidade.

2. Passo 2: Crie um PR no GitHub

   Abra um pull request do ramo de funcionalidade para main. Na descrição, introduza @codex review this PR for edge cases, security issues, and test coverage gaps.

3. Passo 3: Codex faz a revisão de forma assíncrona

   No modo na cloud, Codex clona o repositório para o seu sandbox, lê o diff, executa os testes e o linter e procura vulnerabilidades. Após 5-15 minutos, deixa comentários diretamente no PR.

4. Passo 4: Faça alterações no Claude Code

   Volte ao Claude Code e dê-lhe os comentários do Codex como contexto: “Eis o que a revisão encontrou; corrija os itens 1, 3 e 5.” Claude faz as alterações e publica-as no repositório.

Este padrão funciona porque Claude e Codex foram treinados com conjuntos de dados diferentes e têm filosofias distintas. Codex deteta o que Claude não viu devido ao ponto cego do seu modelo, e vice-versa.

Riscos do padrão 1:

• Codex pode fechar um PR com aprovação e não detetar um problema de arquitetura. Reveja pessoalmente as decisões importantes.
• Custos de tokens duplicados: Claude e Codex analisam o mesmo código. Compensa em funcionalidades complexas e é caro nas pequenas.
• Codex no modo na cloud não consegue ver o seu ambiente local—variáveis de ambiente ou bases de dados locais. Se a funcionalidade lhes tocar, passe para uma execução manual.

Padrão 2: Codex prepara um rascunho, Claude Code corrige a arquitetura#

Este padrão foi utilizado no projeto descrito em 2026, quando foi necessário criar numa só noite um protótipo de funil de registo com notificações por email. Neste cenário, poderia passar uma hora a discutir a arquitetura com Claude Code. Codex produziu um rascunho funcional em 12 minutos.

Como funciona:

Funciona assim: Codex faz o trabalho pesado durante os primeiros 15 minutos e, depois, Claude eleva o resultado à qualidade de produção.

Peça a Codex que deixe tudo polido logo à primeira e ele vai bloquear perante a ambiguidade. Peça a Claude Code que seja rápido logo à primeira e começará a duvidar de tudo. Dê a cada um o trabalho para o qual foi concebido.

Riscos do padrão 2:

• Codex gera um rascunho baseado em pressupostos que podem ser difíceis de corrigir mais tarde. Se o rascunho seguir na direção errada, é mais barato descartá-lo e começar de novo do que corrigi-lo.
• Claude Code pode passar meia hora a mudar nomes de variáveis e esquecer-se do verdadeiro problema de arquitetura. Peça-lhe alterações específicas, não «arruma isto».
• O contexto perde-se entre sessões. Para Claude Code perceber o que Codex pretendia, precisa de um AGENTS.md (consulte o padrão 5) ou de um comentário detalhado no início do ficheiro.

Padrão 3: Codex para a infraestrutura, Claude Code para a lógica de negócio#

A ideia é simples: diferentes partes de uma base de código exigem formas de trabalhar diferentes.

Este padrão complementa a abordagem de executar várias instâncias do Claude Code em paralelo—nesse caso, o mesmo modelo trata de diferentes tarefas através de git worktrees; aqui, dois agentes diferentes dividem as áreas de responsabilidade.

Camada de infraestrutura (Codex):

• GitHub Actions: adicionar um novo job, ajustar o caching, acelerar o CI.
• Testes: escrever uma suite de testes de integração após uma refatorização.
• Migrações Prisma: gerar uma migração e verificar se pode ser revertida.
• Configurações de Docker / Coolify: adicionar variáveis de ambiente, atualizar a verificação de estado.
• Tarefas cron: escrever um conjunto de handlers cron.

Codex destaca-se aqui porque as tarefas de infraestrutura envolvem frequentemente muitos ficheiros pequenos com código boilerplate. Codex não fica preso à ideia de que «precisa de pensar melhor no assunto»; leva o trabalho até ao fim.

Lógica de negócio (Claude Code):

• Funil de registo: o que mostrar ao utilizador em cada etapa.
• Cálculo de preços com descontos, pagamentos em prestações e códigos promocionais de oferta.
• Fluxos de trabalho de notificações automáticas: que acionadores e condições.
• Integrações com APIs externas: tratamento de erros, novas tentativas, caching.
• Modelos financeiros: cálculos de economia unitária e previsões de receitas.

Claude Code destaca-se aqui porque estas tarefas exigem diálogo prolongado com pensamento de produto. Sem discutir cenários, acaba com uma solução técnica que não tem em conta os problemas reais dos utilizadores.

Como o trabalho é dividido no repositório:

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

Não é uma regra rígida. Pode haver sobreposição—por exemplo, Claude Code pode editar uma GitHub Action se esta tiver significado para o produto (enviar uma notificação após a publicação). Mas 80% das tarefas encaixam bem nesta divisão.

Como sincronizar CLAUDE.md e AGENTS.md?#

Na experiência descrita de utilização paralela do Claude Code e do Codex, surgiu um problema inesperado. Claude Code seguia as regras de CLAUDE.md («não mexas nas migrações sem confirmação»). Codex não conseguia ver estas regras e executou migrações sem hesitar num ambiente de trabalho. Depois da terceira base de dados danificada, tornou-se necessário perceber como manter ambos os ficheiros corretamente sincronizados.

Ambos os ficheiros podem conter contexto do projeto, preferências de conversa, comandos de teste, exclusões de pastas e normas de commit. Reutilize as regras aplicáveis às duas ferramentas e mantenha separados os comandos e a configuração específicos de cada uma. Por exemplo, proibir alterações às migrações pertence às duas instruções se a regra se aplicar a ambos os agentes.

O que é igual nos dois ficheiros:

• Stack: que frameworks, base de dados e ORM são utilizados.
• Descrição do projeto: o que é, para quem se destina e quais são as suas principais entidades.
• Proibições: que pastas não devem ser alteradas e que comandos não devem ser executados.

O que é diferente:

• Hooks, camadas de definições e configuração MCP específicos do Claude Code pertencem aos respetivos ficheiros de configuração. O CLAUDE.md pode referir essas convenções em prosa; copiá-la não a transforma em configuração portável.
• AGENTS.md é uma norma aberta. É lido por Codex, Cursor, Aider, Continue, Cline e Factory Droid—mais de 25 agentes. O guia separado aborda o formato AGENTS.md com mais detalhe. As configurações MCP do Codex são guardadas em ~/.codex/config.toml (TOML, não JSON como no Claude).

Um padrão comum em 2026 é uma fonte canónica de regras na pasta /context/ do monorepo, a partir da qual um script de sincronização gera CLAUDE.md, .cursor/rules/*.mdc e AGENTS.md. Os ficheiros específicos de cada ferramenta são marcados como só de leitura; apenas a fonte é editada.

Execute o script de sincronização através de um hook pre-commit ou de uma GitHub Action. Se forem feitas alterações diretamente a CLAUDE.md, o CI falha. Isto evita que as regras das ferramentas divirjam.

Outra opção é o Codex Plugin para Claude Code oficial (anunciado em 30 de março de 2026, versão 1.0.4). Acrescenta os comandos /codex:review, /codex:adversarial-review e /codex:rescue ao Claude Code. Codex é executado como sub-agente, usando o seu próprio ~/.codex/config.toml e AGENTS.md. Isto elimina a necessidade de um segundo terminal, mas AGENTS.md continua a ser necessário.

Quanto custa manter ambos e onde se poupa?#

Estes são os valores de junho de 2026 (dados das páginas oficiais de subscrição da Anthropic e da OpenAI e página oficial do Codex):

Combinação funcional mínima: Claude Pro ($20) + ChatGPT Plus ($20) = $40/mês. É suficiente para projetos individuais com algumas sessões por dia.

Uma combinação real para quem faz vibe coding ativamente: Claude Max 5x ($100) + ChatGPT Plus ($20) = $120/mês. Na experiência descrita, esta combinação foi utilizada nos últimos 2 meses: nesse período, três projetos entraram em produção e os limites do Claude nunca foram atingidos.

Uma combinação para uma equipa: Claude Max 20x ($200) + Codex Pro ($200) = $400/mês. Faz sentido quando há um fluxo constante de revisões de PR e tarefas na cloud em paralelo com o trabalho local.

De onde vêm as poupanças:

• Menos tempo por funcionalidade. Medição do autor: em 12 funcionalidades entre maio e junho, o tempo entre «surgiu uma ideia» e «em produção» baixou de 4 horas (apenas Claude Code) para 2,5 horas (a combinação). Medido nas tarefas do autor; no seu caso, os valores serão diferentes.
• Menos defeitos. Segundo as observações descritas, as revisões de PR do Codex detetam 2-3 problemas em cada 10 que Claude não deteta. Cada problema deste tipo em produção significa uma ou duas horas de correção, além de possíveis interrupções do serviço.
• Paralelismo. Codex trabalha na funcionalidade A no modo na cloud enquanto o utilizador trabalha com Claude na funcionalidade B. Isto duplica a capacidade de execução.

Não compensa se escrever 1-2 funcionalidades por semana. Nesse caso, basta Claude Code Pro.

Quando não precisa de uma segunda ferramenta?#

A combinação não é para toda a gente. Muitas vezes, só acrescenta ruído. Eis quatro situações em que não precisa de uma segunda ferramenta:

1. Projeto individual no início. Se tem uma ideia e está apenas a testá-la, um Claude Code + Plan Mode será suficiente durante um mês. Acrescente a combinação quando surgir um entrave à velocidade.

2. Orçamento fixo. Se o limite é $20/mês, subscreva Claude Pro e não se preocupe com isso. Claude sozinho cobre 80% das tarefas de quem faz vibe coding.

3. Arquitetura simples. Um site com um formulário, um bot com alguns cenários, um script que encapsula uma API—dividir por camadas não acrescenta nada aqui. Um Claude Code consegue tratar do assunto.

4. Já está tudo a funcionar. Se já utiliza Claude Code e, no último mês, não teve uma única tarefa em que ele tenha bloqueado ou falhado, não tente corrigir o que funciona. Acrescente Codex quando a necessidade se tornar óbvia.

E, pelo contrário—sinais claros de que chegou o momento de introduzir uma segunda ferramenta:

• Claude Code tornou-se um ponto de bloqueio: está à espera dele em vez de trabalhar.
• Surgiu muito trabalho de infraestrutura repetitivo (migrações, CI, testes) que não gosta de fazer com Claude.
• Diferentes pessoas da equipa já utilizam ferramentas diferentes—é necessária uma linguagem comum.
• Os benchmarks mostram que Codex trata mais rapidamente do seu tipo de tarefas (por exemplo, operações de terminal).

Como configurar a combinação numa noite#

Um plano concreto para a primeira noite:

1. Passo 1: Instale Codex CLI

   No terminal: npm install -g @openai/codex. Inicie sessão com codex login—abre-se um browser e inicia sessão com a sua conta ChatGPT. Codex deteta a sua subscrição (Plus / Pro) e utiliza os respetivos limites.

2. Passo 2: Escreva AGENTS.md como documento operacional

   Reveja CLAUDE.md e reutilize em AGENTS.md as regras aplicáveis às duas ferramentas: testes e lint, formato de commit, pastas proibidas e descrição da stack. As preferências de conversa também podem ser partilhadas. Adapte referências a comandos específicos e mantenha hooks executáveis e definições MCP na configuração própria de cada ferramenta; copiar Markdown não os configura.

3. Passo 3: Escolha um padrão para o seu projeto

   Se programa sozinho e tem CI, utilize o padrão 1 (Claude escreve, Codex revê). Se é um projeto novo e precisa de rapidez, utilize o padrão 2 (Codex prepara um rascunho, Claude aperfeiçoa-o). Se é um projeto estabelecido com uma camada de infraestrutura, utilize o padrão 3 (divisão por camadas).

4. Passo 4: Experimente durante uma semana

   Trabalhe com o padrão escolhido em 5-7 funcionalidades. Registe o tempo. Anote qual das ferramentas tratou melhor de cada uma. Ao fim de uma semana, terá um perfil real da sua utilização.

5. Passo 5: Configure a sincronização das regras

   Acrescente um script scripts/sync-agent-rules.sh (consulte a secção sobre sincronização). Ligue-o como hook pre-commit ou através de uma GitHub Action. Depois disso, as regras serão propagadas automaticamente para ambos os ficheiros.

Esta combinação não é magia. São simplesmente duas mentes em vez de uma, cada uma a compensar os pontos fracos da outra. O importante é não ficar preso a debater «Claude ou Codex» quando a resposta certa há muito que é «Claude e Codex—para diferentes tipos de tarefas».

Materiais práticos sobre trabalhar com agentes: documentação Ailoot.

Mais materiais e ferramentas: Ailoot.