Codex vs Claude Code: teste de engenharia com auditoria cruzada

Em 12 de maio de 2026, eu rodei um teste informal entre duas IAs de coding:

• Codex usando GPT-5.5 com effort altissimo.
• Claude Code usando Opus 4.7 com effort maximo.

A ideia nao foi fazer um benchmark sintetico. Cada modelo criou desafios para o outro, implementou projetos reais, auditou o proprio trabalho e auditou o adversario. O criterio mais importante foi sinceridade tecnica: bug provado em runtime valia mais que argumento bonito.

Este repositorio guarda os seis projetos, os READMEs, reviews, testes e parte do transcript usado para reconstruir a disputa.

Resumo curto: Codex venceu o overall por 2 x 1. A maior diferenca observada foi metodo: executar, quebrar, medir e comparar com oraculo.

English Summary

On May 12, 2026, I ran an informal engineering benchmark between two coding agents:

• Codex using GPT-5.5 with very high effort.
• Claude Code using Opus 4.7 with maximum effort.

This was not a synthetic prompt-only benchmark. Each agent designed challenges for the other, implemented real projects, reviewed its own work, reviewed the opponent's work, and then had the results judged with a strong bias toward technical honesty. Runtime-proven bugs counted more than elegant arguments. Unsupported claims and hand-wavy self-praise counted against the score.

The final official result was Codex 2 x 1 Claude.

Round	Category	Codex Project	Claude Project	Winner	Margin
D1	Web	reactive-sheet	cotacao-editor	Codex	Clear
D2	Backend	fastboard	api-cotacao	Codex	Close
D3	Free	regexlab	lead-dedupe-legacy	Claude	Close

What Was Tested

D1: Web

• Codex built ReactiveSheet, a mini Excel-like spreadsheet with formulas, a dependency graph, incremental recalculation, cycle detection, undo/redo, keyboard navigation, JSON save/load, virtualization, and a measured Lighthouse Performance score of 100.
• Claude built cotacao-editor, a quotation editor with IndexedDB persistence, domain calculations, status transitions, and a clean UI.

Codex won D1 because ReactiveSheet satisfied the objective challenge criteria more consistently. cotacao-editor had a visible P0 bug where + Nova proposta could create a proposal but fail to open the editor due to a race between async persistence and selected state cleanup.

D2: Backend

• Codex built FastBoard, a persistent leaderboard service with an augmented treap, append-only WAL, CRC validation, group commit, crash recovery, and load tests.
• Claude built api-cotacao, a quotation API with business rules, SQLite persistence, idempotency, and an outbox pattern.

Codex won D2 by a narrow margin. FastBoard had a serious consistency bug where memory state could diverge from WAL order under concurrent writes to the same userId, but api-cotacao allowed a direct business-rule bypass through PATCH { "product": "garbage" }, which made invalid proposals pass validation.

D3: Free Challenge

• Codex built RegexLab, a regex engine from scratch with a parser, typed AST, Thompson NFA, Pike simulation, recursive backtracking with backreferences, SVG NFA visualization, timing comparison, and 100 tests compared against Python's re.finditer.
• Claude worked on lead-dedupe-legacy, a legacy lead deduplication/debugging challenge involving normalization, mutation removal, idempotency, and concurrency locks.

Claude won D3 by a narrow contract-delivery margin. RegexLab was much more ambitious, but it had semantic bugs in core regex behavior, such as NFA matching a|aa as leftmost-longest instead of Python-style leftmost-first. lead-dedupe-legacy also had a real remaining bug involving concurrent retries with externalId only, but the bug was narrower.

Main Lesson

The most important observation was not the scoreboard. It was the method.

Codex was more consistent at empirical validation: opening the apps, clicking through flows, running kill -9 recovery tests, stress-testing concurrency, measuring performance, checking Lighthouse artifacts, and comparing outputs against Python as an oracle.

Claude produced strong written analysis and often excellent self-criticism, but in this run it leaned more heavily on reading and reasoning before runtime probing. That led to good insights, but also to missed runtime bugs and a few claims that later had to be corrected.

The takeaway:

Running, breaking, measuring, and comparing against an oracle beats only reading code and reasoning about it.

This repository contains the six projects, README files, tests, reviews, and notes used to reconstruct the benchmark.

Resultado oficial

Rodada	Categoria	Projeto do Codex	Projeto do Claude	Vencedor	Margem
D1	Web	reactive-sheet	cotacao-editor	Codex	Folgada
D2	Backend	fastboard	api-cotacao	Codex	Estreita
D3	Livre	regexlab	lead-dedupe-legacy	Claude	Estreita

Placar final: Codex 2 x 1 Claude.

O D3 teve impasse: uma regua ponderada por ambicao tecnica favorecia o RegexLab/Codex; uma regua de entrega contra contrato escrito favorecia o lead-dedupe/Claude. O veredito final fixou a segunda regua: contrato primeiro, ambicao como desempate.

Estrutura

Pasta	Autor da entrega	Desafio veio de	Tipo
reactive-sheet	Codex	Claude	Mini-Excel web com formulas, grafo reativo e virtualizacao
fastboard	Codex	Claude	Leaderboard persistente com WAL, treap e benchmark
regexlab	Codex	Claude	Engine de regex do zero + visualizador NFA
cotacao-editor	Claude	Codex	Editor web de propostas/cotacao
api-cotacao	Claude	Codex	API de propostas com regras, outbox e idempotencia
lead-dedupe-legacy	Claude	Codex	Debug/refactor de deduplicacao de leads legado

Metodologia

1. Cada IA propos tres desafios: web, backend e livre.
2. Cada IA resolveu os desafios recebidos dentro de Desenvolvimento/Testes.
3. As entregas foram avaliadas por:
   • testes automatizados;
   • build/typecheck;
   • execucao real em browser ou servidor local quando aplicavel;
   • probes adversariais;
   • auditoria cruzada;
   • autoavaliacao;
   • julgamento humano final.
4. A pontuacao valorizou:
   • bug reproduzido em runtime;
   • aderencia ao contrato escrito;
   • cobertura de testes;
   • honestidade da review;
   • capacidade de corrigir a propria avaliacao.

Isto nao e benchmark cientifico. E um estudo de caso pratico, com seis entregas reais e revisao aberta.

Linha do tempo resumida

Horario	Evento
19:49	Claude terminou o desafio web do Codex (cotacao-editor) em 7m58s. UI boa, mas com P0 no fluxo de nova proposta.
20:03	Codex terminou o desafio web do Claude (reactive-sheet) em 16m19s. Mais lento, mas com testes, Lighthouse e criterios atendidos.
20:55	D1 fechado: Codex vencedor por consenso.
21:15	D2 fechado: Codex vencedor por consenso, apesar de P0 no FastBoard, porque api-cotacao tinha bypass direto de regra de negocio.
21:33	D3 fechado apos flip-flop: Claude vencedor por contrato escrito.

Rodada 1: Web

Codex: ReactiveSheet

Projeto: reactive-sheet

O que entregou:

• Grid 100 x 1.000 com virtualizacao de linhas.
• Parser de formulas, AST e grafo de dependencias.
• Recalculo incremental por dependentes.
• Ciclos como #CYCLE!.
• Undo/redo, copy/paste basico, navegacao por teclado.
• Save/load JSON.
• Lighthouse Performance 100 medido em report local.

Achados importantes:

• Copy relativo na borda fazia clamp e podia criar auto-ciclo.
• load() aceitava celulas fora da grade.
• JSON invalido nao tinha tratamento.
• <input> dentro de <button> no grid era HTML invalido.
• O usuario achou um bug relevante: o benchmark de 10k formulas escrevia na planilha real com history: false, entao o undo nao voltava ao estado anterior.

Claude: cotacao-editor

Projeto: cotacao-editor

O que entregou:

• UI simples e agradavel.
• Dominio separado para calculos e status.
• Persistencia via IndexedDB.
• Testes de dominio.

Achados importantes:

• P0: + Nova proposta podia criar no IndexedDB, mas nao abrir o editor por race entre upsert() sem await, setSelectedId() e efeito que limpava selecao.
• StrictMode podia duplicar seed em dev.
• Campos monetarios/numericos tinham validacao ruim.
• Trocar de proposta descartava alteracoes dirty sem aviso.
• Testes cobriam dominio, mas nao o fluxo principal da UI.

Veredito D1

Codex venceu. O ReactiveSheet tinha bugs, mas cumpria melhor os criterios objetivos do desafio. O cotacao-editor tinha um P0 perceptivel no fluxo principal.

Rodada 2: Backend

Codex: FastBoard

Projeto: fastboard

O que entregou:

• API HTTP de leaderboard.
• Treap ordenada por score desc, timestamp asc e userId.
• WAL append-only com CRC.
• Group commit para amortizar fsync.
• Recovery apos kill -9.
• Harness de load com percentis.

Achados importantes:

• P0: estado em memoria podia divergir do WAL sob writes concorrentes no mesmo userId.
  • Repro: 2.000 POSTs concorrentes para o mesmo usuario.
  • Antes do restart: score 1996.
  • Depois do replay do WAL: score 2000.
• O restart harness validava apenas existencia do usuario, nao score/timestamp final.
• A arquitetura in-memory nao sustentava o teto teorico de 1.000 jogos x 1M usuarios por jogo em menos de 2GB.
• Reads criavam jogos fantasmas.
• Recovery truncava cauda parcial, mas CRC mismatch derrubava startup.

Claude: api-cotacao

Projeto: api-cotacao

O que entregou:

• API Fastify com SQLite.
• Motor de regras.
• Outbox transacional.
• Idempotencia no submit.
• Testes unitarios e e2e.

Achados importantes:

• P1 alto: PATCH { product: "garbage" } burlava o motor de regras.
  • REQUIRED_DOCUMENTS["garbage"] e COMMISSION_LIMITS["garbage"] viravam undefined.
  • Uma proposta sem docs e com comissao absurda podia ser submetida.
• Submits concorrentes com chaves diferentes emitiam varios proposal.submitted.
• Idempotency replay gravava request_hash, mas nao comparava.
• POST {} retornava 500 com mensagem SQL interna.
• Paginacao invalida podia retornar 500 ou bypassar limite.

Veredito D2

Codex venceu por margem estreita. O FastBoard tinha um P0 serio de consistencia, mas o api-cotacao permitia bypass direto de regra de negocio por uma chamada comum de PATCH.

Rodada 3: Livre

Codex: RegexLab

Projeto: regexlab

O que entregou:

• Parser de regex.
• AST tipado.
• Thompson NFA.
• Simulacao Pike.
• Backtracking recursivo com backrefs.
• UI web com grafo NFA em SVG.
• Tabela de matches e grupos.
• Comparativo de tempo NFA vs backtracking.
• Suite com 100 patterns comparados contra re.finditer do Python.

Achados importantes:

• P1: NFA fazia leftmost-longest em alternancia com prefixo.
  • a|aa em aa
  • Python: a, a
  • NFA: aa
• P1: ^ dentro de uma alternativa fazia a busca parar cedo demais.
  • x|^y em y_x
  • Python: y, x
  • RegexLab: y
• P2: $ nao casa antes de newline final como Python faz.
• O teste patologico usava timeout de 80ms na suite, nao o criterio literal de 5s.
• A suite de 100 casos parecia ampla, mas deixava passar decisoes semanticas basicas.

Claude: lead-dedupe-legacy

Projeto: lead-dedupe-legacy

O que entregou:

• Fix em normalizacao de email.
• Canonizacao de telefone BR.
• Remocao de mutacao escondida no input.
• Idempotencia basica de tarefa por externalId.
• LockMap por email/telefone para concorrencia.
• 7 testes novos alem dos 7 originais.

Achado importante:

• P1: retries concorrentes com mesmo externalId, mas sem email/telefone, nao compartilhavam lock.
  • Prova: 3 chamadas paralelas com externalId: "same-ext" criavam 3 contatos, 3 tasks e 6 eventos.
  • Fix sugerido: incluir externalId:${normalizedLead.externalId} nas lock keys.

Veredito D3

Claude venceu por margem estreita. RegexLab era muito mais ambicioso, mas errava semantica basica do subset obrigatorio. O bug do lead-dedupe tambem era serio, mas mais estreito.

Trechos marcantes

"Sinceridade so vale se for tecnicamente precisa."

"A licao: o estilo do Codex (rodar, quebrar, medir) e objetivamente mais eficaz que o meu."

"Codex me bateu de novo no metodo: ele testou a|aa - caso minimalista, obvio em retrospecto, devastador na correcao."

"Bug que tem output medido pesa mais que risco bonito em texto."

"Boa disputa. Codex foi melhor. Decisao sua o que fazer com isso."

"Empirismo > leitura. Calibre estavel > calibre elastico. Bancar posicao tecnica > flutuar com argumento bem-formado."

O flip-flop do D3

O D3 foi a parte mais interessante da disputa.

Primeiro, a discussao parecia favorecer o RegexLab porque ele era tecnicamente muito mais denso. Depois, a regua mudou para score puro: lead-dedupe ficou em torno de 7/10, RegexLab em 6,5-7/10. Entao veio a pergunta principal: devemos premiar ambicao entregue ou contrato escrito?

A decisao final foi:

Contrato escrito primeiro; ambicao tecnica como desempate, nao como absolvicao.

Por essa regua, D3 ficou com Claude.

Comandos uteis

ReactiveSheet

cd reactive-sheet
npm test
npm run build

FastBoard

cd fastboard
go test ./...
go build -o bin/fastboard ./cmd/fastboard
go build -o bin/fbload ./cmd/fbload

RegexLab

cd regexlab
npm test
npm run build

cotacao-editor

cd cotacao-editor
npm test
npm run build

api-cotacao

cd api-cotacao
npm rebuild better-sqlite3 --build-from-source
npm test
npm run typecheck

lead-dedupe-legacy

cd lead-dedupe-legacy
npm test

Fontes e artefatos

• Review do Claude sobre lead-dedupe-legacy:
  • lead-dedupe-legacy/CLAUDE_REVIEW.md
• Prompt do desafio lead-dedupe-legacy:
  • lead-dedupe-legacy/PROMPT_FOR_CLAUDE.md
• READMEs dos projetos:
  • reactive-sheet/README.md
  • fastboard/README.md
  • regexlab/README.md
  • cotacao-editor/README.md
  • api-cotacao/README.md
  • lead-dedupe-legacy/README.md

Conclusao

O resultado formal foi Codex 2 x 1 Claude. Mas o achado mais importante nao foi o placar.

O padrao que apareceu em todas as rodadas foi:

• quem executa acha mais bug;
• quem mede erra menos na severidade;
• quem aceita correcao chega mais perto da verdade;
• testes pequenos e adversariais batem listas bonitas de risco teorico.

No fim, a IA mais confiavel nao foi a que soou mais confiante. Foi a que transformou duvida em teste executavel.