- Um engenheiro sênior com 14 anos de experiência comparou, na prática, Claude Code (Opus 4.6) e Codex (GPT-5.4) em um projeto Python/TypeScript com 80 mil linhas de código
- Claude Code é rápido e interativo, mas exige gestão ativa, pois tende a ignorar instruções, deixar tarefas incompletas e adicionar funções indiscriminadamente em arquivos existentes
- Codex é 3 a 4 vezes mais lento, mas mais cuidadoso e sistemático ao escrever código, refatorando por conta própria e seguindo rigorosamente o arquivo de instruções (
AGENTS.md) - A avaliação é que Claude Code é mais adequado para prototipagem rápida, enquanto Codex se encaixa melhor em desenvolvimento de software de nível enterprise
- Em conclusão, ambos compartilham o mesmo ponto em comum: sem capacidade de engenharia de software, é difícil obter bons resultados
Contexto do autor e ambiente de desenvolvimento
- Engenheiro de nível Principal/Staff Eng Manager, com 14 anos de atuação nas MAG7 (as 7 big techs dos EUA) e em outra grande empresa de tecnologia
- Forte experiência em desenvolvimento em nível de plataforma e ampla vivência com sistemas distribuídos
- O projeto é uma base de código Python/TypeScript com 80 mil linhas, estruturada como uma extensão do VSCode, com cerca de 2.800 testes
- Aplicação de análise de dados em que o usuário faz upload de arquivos PDF/CSV/XML, que são parseados e normalizados em um modelo de dados estruturado baseado em Postgres
- Conexão via WebSocket com um provedor de dados em tempo real no backend, transmitindo dados atuais para o modelo
- No servidor, as análises baseadas no fluxo de dados são atualizadas e enviadas para a UI web via SSE (Server-Sent Events)
- Desenvolvimento baseado em arquitetura sistemática, não em vibe coding
Fluxo de trabalho comum dos agentes
- Primeiro, começa-se no modo Plan com prompts de escopo bem definido, usando a skill plan-review para executar 8 subagentes (arquitetura, padrões de código, design de UI, performance etc.)
- Cada subagente possui prompts específicos, junto com documentos de referência gerados em sessões anteriores de pesquisa (por exemplo,
postgres_performance.md,python_threading.md,software_architecture.md)- O prompt do especialista em revisão de arquitetura é configurado para revisar com referências a conceitos como SOLID, DRY, KISS, YAGNI
- Depois de escrever o código, faz-se um commit por etapa do plano, revisa-se cada commit com a skill code-review (reaproveitando os subagentes do plano) e o feedback é verificado e ajustado manualmente
- O CLAUDE.md tem cerca de 100 linhas, incluindo TDD, fluxo de trabalho com Git, principais convenções de DevEx, comandos Docker e instruções de uso das ferramentas do projeto
Experiência com Claude Code (Opus 4.6)
- Passa a sensação de um engenheiro correndo contra o prazo, com tendência a focar apenas em implementar funcionalidades por meio de hacks, patches e excesso de funções helper, em vez de reavaliar a arquitetura central
- É interativo, mas justamente por isso exige mais acompanhamento (babysitting)
- Produz código funcional rapidamente, mas não pensa o suficiente antes de agir
- Mesmo com gestão manual agressiva do contexto (o autor considera 1M de contexto uma armadilha para iniciantes e acha que deve ser mantido em menos de 1/4), quase toda sessão inclui algum caso em que ele ignora descaradamente o
CLAUDE.md - Às vezes deixa tarefas pela metade
- Ex.: ao migrar padrões assíncronos em 8 suítes de teste, tratou a maioria, mas deixou algumas no padrão antigo
- Quase não cria arquivos novos para novas funcionalidades e tende a seguir adicionando funções em arquivos já existentes
- Isso entra em conflito com a preferência por princípios fortes de OO e por manter arquivos com menos de 600 linhas
- Quando testes quebram, tende a corrigir por conta própria sem prompt, então foi necessário adicionar muitas instruções do tipo: “se os testes quebrarem, pare e me pergunte”
- 95% dos testes que escreve são úteis, mas 5% fixam comportamentos errados, e isso se acumula com o tempo
Experiência com Codex (GPT-5.4)
- Passa a sensação de um engenheiro sênior júnior de 5 a 6 anos de experiência, que para sozinho e retrabalha o código para deixá-lo mais limpo, mesmo sem instruções separadas
- É 3 a 4 vezes mais lento que Claude (na mesma tarefa)
- Trabalha de forma mais cuidadosa e intencional e, ao contrário do Claude, não expande uma “god class”, refatorando o código automaticamente de forma mais enxuta
- Reavalia as próprias suposições durante a execução e retrabalha no meio do processo para organizar melhor
- Às vezes realiza por conta própria tarefas de valor agregado inesperadas
- O autor diz nunca ter visto o Codex ignorar o
AGENTS.md; mesmo tentando sobrescrever instruções durante a sessão, ele não permite - Como já demonstrou capacidade suficiente, é possível iniciar uma tarefa e revisar apenas ao final, sem necessidade de monitoramento em tempo real
Comparação geral
- O limite de uso do Codex Pro x5 fica em nível parecido com o Claude x20
- O Codex é visivelmente mais lento e menos interativo, mas mais cuidadoso; o Claude é rápido e interativo, mas exige acompanhamento (babysitting)
- Em uma única sessão, Claude consegue lidar com mais volume de trabalho, mas a qualidade do trabalho do Codex é superior
- Claude permite prototipagem e construção extremamente rápidas, mas precisa de refatoração guiada a cada poucos dias
- O Codex também exige refatoração à medida que o app cresce, mas em um nível de “está na hora de refatorar porque o app cresceu”, e não de “que problema precisa ser arrumado agora?”
- Para vibe coding em projetos de baixa a média complexidade, Claude conclui mais rápido
- Para construir software enterprise, o Codex é mais adequado
- Ambos são úteis, mas Claude precisa de um operador mais experiente e mais focado do que o Codex
- Sem conhecimento de engenharia de software, ambos geram resultados ruins
📋 Principais pontos dos comentários no Reddit
Estratégia de uso combinado das duas ferramentas (o ponto mais citado)
- O padrão mais popular é um fluxo de validação cruzada: rascunho/trabalho rápido com Claude → code review com Codex
- “Peça para o Codex revisar o código escrito pelo Claude, e faça o contrário também” — é extremamente raro que os dois modelos alucinem da mesma forma
- Alguns usuários também usam uma estratégia de baton-pass para passar do Claude ao Codex quando os tokens do Claude acabam
- A estrutura salva o estado em
save-state.mdenext-task.md, para que o Codex continue dali; a qualidade do handoff melhora a cada transição
- A estrutura salva o estado em
- Há também casos de uso do Codex CLI empacotado como servidor MCP, automatizando a colaboração com o Codex dentro do Claude Code
- Após o trabalho do Claude, o Codex devolve sugestões e o Claude as implementa, o que melhora drasticamente a qualidade do código
- Também funciona passar o dia todo trabalhando com Codex, fazer o polimento final com Claude e depois voltar ao Codex
Concordância com as vantagens do Codex
- Já há usuários trocando o Claude Code do plano 20x (US$ 200) para o 5x (US$ 100) e usando em paralelo o plano Codex de US$ 100
- Não se percebe uma diferença de qualidade grave entre GPT-5.4 e Opus 4.6; dependendo do problema, fica em 50:50
- “É só deixar rodando, tomar um café e voltar que terminou” — em termos de execução autônoma (fire-and-forget), o Codex leva vantagem sobre o Opus
- O Codex segue as instruções de
AGENTS.mdcom tanto rigor que chega a recusá-las, a menos que se peça explicitamente para sobrescrever - Há relatos de resultados melhores após migrar para um processo puramente com Codex: plano + implementação + revisão com outra instância do próprio Codex
Desvantagens do Codex
- O maior incômodo é o estilo de comunicação robótico
- Em vez de escrever os valores
[0.1, 0.3, 0.5, 0.7, 0.9]de um dict Python em uma linha, ele pode colocar um valor por linha - Há quem especule que o treino com RL tenha recompensado algo como “quanto mais bullet points, melhor”
- Mesmo ajustando as configurações de comunicação, ele oscila entre extremos (resposta curta demais vs. longa demais), sendo difícil achar um meio-termo
- Em vez de escrever os valores
- Tendência a rebater o usuário o tempo todo — mesmo quando um desenvolvedor com mais de 10 anos de carreira dá instruções claras, continua contestando, sem necessariamente propor uma alternativa melhor
- O problema de conversas que se estendem sem fim — perde foco na tarefa e fica disperso
- Ao implementar funcionalidades grandes, às vezes deixa passar muitas coisas e não entende direito a base de código existente
- Ex.: existe um formatter, mas ele cria outro do zero, ou insere strings hardcoded na ViewModel
- Em recursos, ainda fica atrás do Claude Code em hooks, suporte a MCP, plugins etc., então a migração pode parecer um retrocesso
Concordância com os problemas crônicos do Claude Code
- Há amplo consenso sobre o padrão de o Claude ignorar instruções do usuário e agir como quer
- “O Claude tenta executar aquilo que imagina que você quer” — a confiabilidade no cumprimento de instruções é baixa
- Casos observados em que ele hardcoda 100 objetos em uma lista e diz que deu certo, chegando até a contornar hooks criados para evitar isso
- Nos últimos meses, piorou a tendência do Claude de não encontrar o problema real em código complexo
- Em vez da causa raiz, ele corrige apenas os sintomas e ainda afirma com confiança que “encontrou o problema”
- Às vezes o Codex também é induzido ao erro pela análise confiante (mas incorreta) do Claude
- Alguns usuários chegaram a cancelar a assinatura por causa da velocidade com que o Claude consome créditos — mal dá tempo de aprender a usá-lo
Opinião contrária: Claude ainda estaria à frente
- Há experiências em que o Opus 4.6 mostra mais cuidado e raciocínio mais profundo, com qualidade analítica superior ao GPT-5.4 na fase de design/arquitetura
- Em algumas revisões, o Opus encontra problemas adicionais que o GPT-5.4 não detecta
- Mas isso pode ter relação com rumores recentes de que os modelos Claude foram ajustados para “usar menos esforço”
- Quando se exige Clean Architecture, o Claude também cria novos arquivos ativamente, sem gerar o problema de god class
- Se ambos seguirem a arquitetura, a qualidade do código fica quase equivalente; a diferença aparece mais em velocidade e facilidade de uso
- Com um fluxo de trabalho sistemático (plan mode + skills customizadas + feedback de coderabbit/sonarqube), ainda é possível produzir bom código mesmo nos períodos em que outros reclamam e sem bater no limite de uso
Outras observações interessantes
- “É impressionante como a equipe da Anthropic consegue lançar tantos recursos, considerando que 100% do código é escrito pelo Claude” (sarcasmo)
- “Codar com Codex → revisar no Claude → colocar o Gemini também na revisão” — estratégia de revisão cruzada com 3 modelos; em alguns casos, o Sonnet encontra coisas que o Opus deixou passar
- Há expectativa de que Mythos (modelo de próxima geração) reduza esse tipo de necessidade de gerenciamento
18 comentários
Qualquer um dos dois precisa de HITL. (Pelo menos até hoje)
Por favor, sem esse papo de Ralph Loop ou coisa do tipo.
Estou usando só o Codex, e bate exatamente com o que eu senti.
Também combina com o meu jeito, então estou usando bem.
Eu estava pensando em migrar para o Claude quando acabasse o ChatGPT no KakaoTalk,
mas de alguma forma tenho a sensação de que os pontos fracos do Claude não combinariam com o meu perfil..
Será que há diferença nas linguagens principais usadas pelos usuários de Claude e de Codex?
> Tendência a ficar rebatendo o usuário o tempo todo — mesmo quando um desenvolvedor com mais de 10 anos de carreira dá instruções claras, continua contestando e, no fim, nem consegue apresentar uma boa alternativa por conta própria
kkk
Acho que também pode haver diferença na forma de usar. Dependendo do perfil do desenvolvedor, a maneira de lidar com isso e as preferências variam. Depois de usar bastante, a pessoa se acostuma com o fluxo de trabalho com um modelo específico, então outro modelo pode parecer estranho.
Acho que não há motivo para insistir em um modelo específico~
Isso não depende do domínio em que é aplicado?
No caso do
rhwpem que estou trabalhando agora, quando é preciso lidar com diferenças de renderização de 1 mm, se eu usar o Codex ele estraga tudo. Até agora, para tarefas de alta dificuldade o Claude Code ainda está à frente, mas, na minha percepção, para desenvolvimento de web apps em que basta ter um workflow e um framework que deem conta de um certo nível de processamento conforme o procedimento, usar o Codex faz melhor para a saúde mental.Estou usando muito bem. No Mac, a velocidade de carregamento também é mais rápida do que a do Viewer, é o melhor!
Muito obrigado(a), de forma avassaladora.
Oooh, estou usando bem. Obrigado por este excelente projeto.
Vou usar bem o rhwp.
Concordo que o Codex é bem minucioso. Recomendo programar com o Claude e fazer a revisão com o Codex. Leva bastante tempo, mas se você deixar rodando antes de ir ao banheiro ou antes de uma reunião, a taxa de conclusão também fica mais alta.
Eu também faço assim. Em mais detalhes, deixei o Claude de US$ 100 e o Codex de US$ 200, e transformei em uma habilidade para ficar rodando continuamente neste fluxo: planejamento com Claude Code Opus -> implementação com Sonnet -> revisão com Codex -> validação da revisão com Opus -> implementação novamente com Sonnet -> revisão com Codex (e assim por diante). Estou satisfeito com isso.
Eu também uso assim. Só que, em vez de fixar cada função em um único modelo, vou atribuindo primeiro ao modelo mais poderoso que ainda tem a cota mais folgada.
Eu usei os dois e achei justamente o contrário, então talvez não seja bem assim.
Quando eu usei, o Codex frequentemente ignorava as instruções.
Também parece que isso pode ter mudado recentemente, já que a Anthropic reduziu o desempenho do 4.6 Opus.
Não é o contrário? O sênior está aquém do esperado.
O problema crônico do Claude Codeentão você provavelmente ainda não passou por isso. No Reddit também vira confusão o tempo todo.Para mim, o codex foi uma experiência melhor.