Claude Code ou Codex, afinal? A solução realista pra usar os dois sem acidente

“E aí, no fim das contas, qual eu devo usar?”

Claude Code e Codex, da OpenAI. Quanto mais a pessoa mexeu nos dois, mais ela trava nessa pergunta. Eu também, no começo, achava que “tinha que escolher um”.

Mas depois de meio ano usando, a resposta veio meio sem graça. Não é “um ou outro”. É usar os dois. Só que dividindo qual trabalho cada um faz. É só isso.

O problema não é “qual é mais esperto”. É como não comparar qual é mais nobre, faca ou tesoura. Pra legume, faca; pra papel, tesoura. Toda ferramenta tem uma forma em que é boa, e, se você erra, corta o dedo. Hoje é o papo de “qual trabalho entregar pra cada um” e de como dispor os dois rodando ao mesmo tempo sem acidente.

Não vou apelar. Não vou cravar um “este é superior”. Vou alinhar, com honestidade, as minas que eu pisei de fato tocando este site.

Primeiro, a diferença de personalidade dos dois

Deixando a comparação de inteligência de lado, vamos falar de personalidade.

O Claude Code é o parceiro que arruma do seu lado o quarto bagunçado que está ali na sua frente. Ele abre o seu repositório, lê as regras que você escreveu no CLAUDE.md e vai consertando de forma dialogada, conectando o contexto: “se vou mexer aqui, já mexo ali também”. É bom de captar a situação do código que já existe. Por isso é forte em refatorar projeto existente e em ajustes finos no local.

O Codex chega mais perto do fornecedor que está noutra sala e toca sozinho o trabalho que você encomendou. Combina com o estilo de delegação: você joga uma tarefa e ela roda do lado da nuvem, ou ela manda um Pull Request pra entrar na revisão. A OpenAI também descreve o Codex como um parceiro a quem você pode delegar o trabalho de código (OpenAI: Introducing Codex). Soltar a mão e delegar é o forte dele.

Em resumo grosseiro: o Claude Code é “ao seu lado, junto”; o Codex é “você deixa lá e espera”. Guarde essa diferença de temperatura e a escolha de quando usar cada um entra fácil.

Só que os nomes de modelo, os preços e a linha do que cada um faz, que escrevi aqui, mudam bem rápido. Os dois atualizam num ritmo veloz. Então os fortes e fracos finais e o preço, confira sempre o mais novo no oficial (documentação da OpenAI e documentação do Claude Code). Pense neste artigo como “um mapa de raciocínio”.

Qual trabalho entregar pra cada um?

Só com o mapa fica difícil de usar, então deixo a minha divisão de verdade. É a minha sensação no momento, não a verdade absoluta.

O que você quer fazer	Responsável principal	Por quê
Refatoração emaranhada de repositório existente	Claude Code	Lê o contexto ao redor e evita acidente de arrastar coisa junto
Desenho e ajuste em diálogo no local	Claude Code	O vai e volta do “ah, então faz assim” é rápido
Delegar tarefa independente bem recortável	Codex	Você joga e já passa pra outro trabalho
Criar PR e pôr na revisão	Codex	Encaixa no fluxo de delegação + revisão
Respeitar regra específica do projeto	Claude Code	Fácil de fazer valer lendo o CLAUDE.md
Tocar várias tarefas em paralelo	Os dois	Diálogo num, delegação no outro, e você não trava

O ponto é a última linha. Não é “um ou outro”, é divisão de papéis. Eu acabei aterrissando no duas-mãos: aprofundo o desenho com o Claude Code na frente da tela, e os trabalhos braçais que dá pra recortar eu jogo pro Codex tocar na outra sala.

E aqui está o âmago. Use qual usar, a ideia do dispositivo de segurança é a mesma. Em vez de escolher a IA mais esperta, montar primeiro um jeito de dispor onde você cai sem se machucar. Isso eu chamo de “harness = o andaime, o cabo de vida da IA”. Quem quiser entender desde o conceito, vá no guia completo de harness engineering.

O andaime fica mais fácil de organizar se você pensar em 4 camadas. Não é difícil.

o seu pedido
  ↓
IA (Claude Code / Codex)
  ↓
[1] camada de permissão  o que deixar fazer e o que barrar
[2] camada de roteiro    em que ordem fazer
[3] camada de verificação  com o que conferir o "OK" no fim
[4] camada de recuperação  como reverter se falhar
  ↓
arquivos / shell / serviço externo / deploy

Se faltar uma dessas quatro, seja no Claude Code, seja no Codex, você cai mais ou menos no mesmo lugar.

Onde o “uso combinado” faz diferença (3 casos)

1. Desenho no Claude Code, produção em série no Codex

Trabalho que precisa de “vai e volta”, como o desenho de dados de uma feature nova, eu aprofundo com o Claude Code na frente da tela. Depois de decidido, o braçal “mais 8 arquivos no mesmo formato” eu recorto e jogo pro Codex. O tempo de usar a cabeça e o tempo de só esperar se separaram direitinho.

2. Corpo no Claude Code, revisão no Codex

Tem hora que você quer que outro olho veja o código que escreveu com o Claude Code, né? Aí você roda a revisão de PR no Codex. Comparado a a mesma IA escrever e revisar, o ponto de vista desloca e os apontamentos aumentam. Como “primeira peneira” antes da revisão humana, não é nada mau.

3. A operação perigosa, em ambos, o humano é quem aperta no fim

Esta é a mais importante. Deploy, atualização de banco de produção, envio de e-mail, git push, npm publish. Só esse tipo de “operação sem volta”, seja no Claude Code, seja no Codex, deixe num desenho em que, no fim, o humano aperta o botão. Gerar e rascunhar pode ser automático. Mas a operação que sai pra fora, barre. Se você forçar isso pelo lado do andaime, não tem acidente de madrugada.

A linha das permissões, se você guardar num arquivo assim, não fica na dúvida. No Claude Code dá pra escrever em .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

O truque é não escrever a proibição no “acho que isso parece perigoso”. rm -rf, git reset --hard, leitura de .env, coisas de deploy de produção. Escreva com o nome concreto do comando. O jeito detalhado de montar começa em Claude Code settings. A prática de Approval / Sandbox eu reuni no guia de configuração de Approval / Sandbox.

Do lado do Codex existe a mesma ideia. Com sandbox (área de trabalho isolada) e approval (aprovação), você separa “até aqui pode sozinho, daqui em diante pergunta pro humano”. O nome da configuração muda, mas o que você quer fazer é o mesmo. Uma vez que você incorpora a forma de pensar do harness, mesmo trocando de ferramenta, dá pra aplicar.

3 vacilos que eu mesmo cometi

Vou ser honesto. No começo, o uso combinado deu bastante acidente.

Primeiro. Deleguei o mesmo trabalho pros dois e virou uma guerra de reescrita. Joguei pro Codex um “conserta aqui” num arquivo que eu estava consertando no Claude Code. Óbvio: a mudança de um sobrescreveu a do outro e eu não sabia mais qual estava certo. Hoje eu separo o alcance: “este arquivo agora é do lado do Claude Code”. Não usar a mesma tábua de corte ao mesmo tempo, em dois. É óbvio, eu sei.

Segundo. A tarefa que entreguei ao Codex era vaga demais. Pedido dependente de contexto, tipo “conserta aí, do jeito que ficar bom”, jogado pro lado da delegação não dá em nada bom. Delegação é encomenda, então a regra de ouro era despedaçar até virar uma forma que se resolve sozinha, e só então entregar. Já o trabalho que precisa de contexto, em vez de forçar a delegação, eu toco em diálogo com o Claude Code. A forma do pedido é que decide a escolha da ferramenta.

Terceiro. Toquei no “eu confiro depois” e, no dia corrido, isso quebrou. Já passou de a URL pública ficar em 404, de a tag de anúncio sumir, e seguir adiante sem eu perceber. A conferência no olho, quando o dia é corrido, você pula sem falta. Por isso, a conferência que a máquina entende, deixe a máquina fazer. Por exemplo, passei a bater se a página publicada está viva com um scriptzinho assim.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Uso: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`A página retornou ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`Faltando ${name} em ${url}`);
  }
}

console.log(`OK: ${url}`);

Não é uma verificação perfeita. Mas acidente bobo do tipo “achei que tinha publicado e estava 404”, “a tag importante tinha sumido”, isso aí ela barra. Como a IA tende a olhar só a última linha do log de erro e consertar a coisa errada, decidir antes, em código, o que conta como OK faz diferença.

Se for começar, comece por aqui

Não saia montando de cara o duas-mãos 100% automático. Tem uma ordem.

Primeiro, divida uma tarefa de hoje no lado que exige a cabeça e no lado que dá pra esperar. A parte que precisa de juízo, em diálogo com o Claude Code. O braçal que deu pra recortar, delegado ao Codex. Só isso e a velocidade que você sente já muda.

Depois, derrube toda operação perigosa pro “pergunta pro humano (ask)”. Deploy, push, envio, banco de produção: no começo, espera por aprovação sem conversa. Só promova pra automático, depois, o que você descobriu ser seguro. Alargar fica pra depois. No começo, estreito.

E por fim, ter um molde de pedido pronto pra entregar evita que você varie a cada vez. Este é o meu template pra delegar ao Codex. É só copiar e preencher.

# Tarefa (numa unidade que se resolve sozinha)
<ex.: adicionar testes unitários às funções de formatação de data em src/utils/>

# Alcance permitido
- tocar: <ex.: só src/utils/date.ts e tests/date.test.ts>
- não tocar: <ex.: qualquer outro arquivo. não ler config nem .env>

# Condição de conclusão (é com isto que se conta como OK)
- npm run test passa por inteiro
- não mudar a assinatura das funções existentes
- manter o diff mínimo fora dos arquivos novos

# O que não pode fazer
- não dar git push (vai até apresentar o PR/diff)
- não adicionar pacote de dependência por conta própria
- nenhuma operação de produção, deploy ou envio

O pulo do gato é deixar por escrito “o alcance que não se toca” e “o que não pode fazer”. A IA do lado da delegação, querendo ser prestativa, às vezes vai tocar em lugar a mais, então cerque desde o começo. Isso também serve de defesa contra o acidente de confundir instrução de documento externo com ordem de trabalho (Prompt Injection). Como evitar esse tipo de pedido perigoso eu detalhei em checklist prático pra evitar prompts perigosos.

O que aconteceu quando testei na prática

Esta é a conclusão de meio ano usando os dois combinados pra tocar este site.

O que teve maior efeito foi, surpreendentemente, menos a “regra de proibição” e mais a “fronteira deixada no ask”. Rascunho e tradução de artigo, ideação de refatoração — automatizar no Claude Code ou no Codex dificilmente dá problema. Mas deploy, git push, envio de e-mail e atualização da URL de produção, só esses, deixe a confirmação humana. Só de cravar isso, o número de sustos despencou.

Em compensação, um fracasso claro foi o método de enfiar todo o passo a passo num prompt longo. Quando fiquei ganancioso querendo fazer tudo de uma vez, a sessão ficou pesada e travava no meio com facilidade. Instrução curta, e as regras de execução jogadas pro lado do andaime (settings ou linha de aprovação). Esse caminho tem reprodutibilidade muito maior.

E a sensação do quando-usar-cada-um. Largar o “escolher um” foi o que mais funcionou. Como ter faca e tesoura nas duas mãos, tocar o Claude Code do lado e o Codex na outra sala ao mesmo tempo. A sensação de o trabalho andar o dobro com um cérebro só, uma vez que você prova, não tem volta. Mas, repetindo, os fortes, o preço e os modelos dos dois atualizam rápido, então, antes de investir pra valer, confira o mais novo no oficial.

Resumo

Minha resposta pra “Claude Code ou Codex?” é: “Os dois. Só que dividindo qual trabalho delegar e qual operação barrar.”

• Pra consertar lado a lado, Claude Code; pra deixar e esperar, Codex.
• Trabalho que precisa de contexto, em diálogo; trabalho recortável, delegado.
• Use qual usar, a ideia do dispositivo de segurança (permissão, roteiro, verificação, recuperação) é a mesma.
• A operação perigosa (deploy, envio, banco de produção), no fim, o humano aperta.

Troque o tempo que você gasta em dúvida na escolha da ferramenta pelo tempo de montar um andaime. A qualidade do trabalho se decide menos por qual IA é mais esperta e mais pelo jeito de dispor que está do lado de fora dela.

Se você quer organizar junto o desenho de permissões, o CI e as regras de operação do time, reuni templates prontos pra usar na lista de materiais. E quando quiser que eu acompanhe ajustando ao seu próprio repositório, vá por treinamento e consultoria.