O Juiz Cego: Pontuando Claude Code vs Codex em 36 Duelos

Thomas Ricouard (@Dimillian) resumiu melhor do que qualquer benchmark: “Claude Code é como um refactoring bem mediano que eu sei que ele consegue executar. Codex é uma arquitetura de ponta. Ainda não tenho certeza se ele consegue fazer isso sem quebrar tudo.”¹

Parei de especular e comecei a medir. Construí um sistema que coloca Claude Code contra Codex CLI na mesma tarefa, rotula as saídas aleatoriamente como Alpha e Beta, e pontua ambos os planos às cegas em cinco dimensões antes de revelar qual agente escreveu qual. Trinta e seis duelos depois, o placar diz que Claude venceu 8 de 12 duelos decididos. Mas o placar não é o ponto. O ponto é o que o juiz cego produz após a pontuação: uma síntese que combina os elementos mais fortes de ambos os planos em algo melhor do que qualquer um dos competidores entregou sozinho.

TL;DR

Trinta e seis duelos. Avaliação às cegas em cinco dimensões (Correção, Completude, Simplicidade, Decomposição, Acionabilidade). Claude Code venceu 8, Codex CLI venceu 3, um indeciso, em 13 duelos com manifestos de julgamento estruturados (12 com um vencedor declarado). O verdadeiro resultado não é um vencedor. É a etapa de síntese que seleciona os melhores elementos de ambos os planos e produz um briefing de implementação mais forte do que qualquer agente sozinho. O post complementar Pensando com Dez Cérebros aborda deliberação colaborativa.¹² O juiz cego aborda avaliação competitiva. A metodologia importa mais do que o placar.

Por Que Comparação É Difícil

Todo mundo está comparando agentes de codificação com IA agora. Ninguém concorda sobre os resultados.

O problema é estrutural. Comparações de modelos se degradam ao longo de três eixos: vibes (você testou uma tarefa em cada e foi com o instinto), viés de recência (o último sucesso sobrescreve todas as falhas anteriores) e pontos fortes específicos por tarefa (o modelo que vence no seu refactoring perde na sua revisão de segurança). Essas não são observações ruins. São experimentos ruins.

Alex Finn (@AlexFinn) usa um fluxo de validação dupla onde dois modelos verificam a saída um do outro.² A abordagem de dupla verificação captura erros que qualquer modelo sozinho deixaria passar. O insight é válido: avaliação independente revela discordâncias, e discordâncias são onde os bugs se escondem.

@doodlestein roda mais de 10 agentes simultaneamente — Claude, Codex e Gemini — usando prompts padronizados que ele chama de “idea wizards” para atacar o mesmo problema de diferentes ângulos.³ Um planejador que se destaca em decomposição pode deixar passar um bug de correção que um agente mais detalhista captura imediatamente.

Ambos os fluxos melhoram em relação à avaliação de modelo único. Nenhum elimina a maior ameaça: viés de confirmação. Se você sabe qual modelo escreveu qual plano, vai pontuar o modelo em que confia mais generosamente. Sempre. Não porque você é descuidado, mas porque o viés opera abaixo da consciência. A peça que falta é o mascaramento. Se o avaliador não sabe qual agente produziu qual saída, o viés de confirmação não tem a que se agarrar.

O Protocolo de Avaliação Cega

O sistema /duel funciona em cinco fases:

1. Execução paralela. Ambos os agentes recebem o mesmo prompt de tarefa e contexto do projeto. Claude Code roda em um processo, Codex CLI em outro. Nenhum vê a saída do outro.
2. Rotulagem aleatória. Um sorteio atribui um agente a “Alpha” e o outro a “Beta.” O sistema grava o mapeamento em agent-mapping.json e o sela. Nem o juiz nem eu vemos o mapeamento até após a pontuação.
3. Pontuação cega. Um agente juiz lê ambos os planos e pontua cada um em cinco dimensões, 0-4 por dimensão, máximo de 20 pontos no total. O juiz vê apenas “plano Alpha” e “plano Beta.”
4. Recomendação de vencedor. O juiz declara um vencedor (ou indeciso) com um nível de confiança e justificativa escrita.
5. Síntese. O juiz combina os elementos mais fortes de ambos os planos em um briefing de implementação refinado. A síntese é a saída real.

As cinco dimensões de pontuação:

A decisão de design chave: a síntese não é uma mistura 50/50. Ela pondera fortemente a estratégia central do vencedor enquanto seleciona insights genuínos do perdedor. Tentativas iniciais de síntese com peso igual produziram planos incoerentes que herdaram as piores propriedades de ambos. A síntese ponderada produz planos estruturalmente sólidos (do vencedor) e completamente fortalecidos (dos casos extremos válidos do perdedor).

Estudo de Caso: O Duelo de Remediação de Segurança

Em fevereiro de 2026, uma auditoria de segurança com três agentes encontrou 7 achados CRÍTICOS e 7 ALTOS no ResumeGeni, uma aplicação FastAPI com autenticação Supabase e pagamentos Stripe.⁴ Eu já havia enviado duas correções triviais. Nove permaneciam. Executei um duelo para gerar o plano de remediação.

Ambos os agentes receberam o mesmo briefing: a lista de achados com caminhos de arquivo e números de linha, o contexto da arquitetura, a restrição de que um padrão de correção comprovado já existia em um arquivo, e o requisito de produzir um plano de implantação faseado.

Plano do Alpha: 11 stories para 9 achados, organizados em três ondas de implantação. Uma story de baseline de testes (SEC-01) bloqueava todo o trabalho subsequente. Gates de implantação com métricas específicas: taxa de sucesso de autenticação, monitoramento de 5xx, contagem de rejeição de webhooks. Discussão detalhada de alternativas rejeitadas. Stories usavam uma estrutura O quê/Por quê/Sucesso com intervalos de linhas.

Plano do Beta: Mapeamento direto 1:1 de achados para stories. Três ondas de implantação: Críticos como uma unidade única, Alta prioridade como implantáveis independentemente, Limpeza. Investigação antes da correção para o achado de middleware. Números de linha específicos, nomes de funções, caminhos de import e comandos curl para verificação por story.

A diferença de correção contou a história. Beta identificou duas coisas que Alpha perdeu completamente.

Primeiro: o achado de middleware (C3) sinalizou get_user(jwt=...) como um vetor de contaminação de sessão. Beta identificou corretamente que get_user() é uma chamada de verificação stateless. gotrue-py só chama _save_session() em verify_otp e exchange_code_for_session, não em get_user. Alpha tratou como se definitivamente precisasse da mesma correção dos outros dois routers, o que adicionaria overhead desnecessário por requisição em toda requisição autenticada. Beta disse: investigue primeiro, corrija apenas se confirmado.

Segundo: os routers de magic link e passkeys usam tanto admin.generate_link() (que requer o singleton SERVICE_KEY) quanto verify_otp() (que precisa de um cliente novo por requisição). O plano do Alpha aplicou o padrão de cliente novo uniformemente. Um implementador seguindo esse plano quebraria operações de admin. Beta explicitamente indicou a separação: cliente novo para verify_otp, singleton compartilhado para admin.generate_link().

As pontuações:

Alpha era Codex. Beta era Claude. Alta confiança.⁴

A síntese combinou a precisão técnica do Beta com o rigor operacional do Alpha. Aqui está uma story da saída de síntese, mostrando como ela fundiu ambos os planos:

Story 1.1 (C1 — Singleton Compartilhado de Magic Link): Em magic_link.py, adicionar _create_auth_client(). Usar cliente anônimo novo APENAS para verify_otp (linha 224). Manter singleton compartilhado para admin.generate_link() (linha 213) que precisa do SERVICE_KEY.

Essa story herda os números de linha precisos do Beta e a separação crítica entre cliente admin/anon, envolvida em uma estrutura que se encaixa na sequência de implantação em três ondas do Alpha. A síntese completa manteve a abordagem de investigação primeiro do Beta para C3, os comandos curl de verificação específicos do Beta, os gates de implantação do Alpha (monitoramento de taxa de sucesso de autenticação, rastreamento de 5xx) e a estratégia de testes de regressão do Alpha (suite E2E Playwright de auth após a Onda 1, webhook de teste Stripe após a Onda 2). O resultado: um plano de 3 ondas com 12 stories, executável em um dia, com guardrails operacionais que nenhum plano sozinho fornecia.

O Placar (e Por Que Ele Engana)

Ao longo de 36 duelos, 13 produziram manifestos de julgamento estruturados. Um manifesto declarou indeciso, deixando 12 com um vencedor claro:

Claude: 8. Codex: 3. Indeciso: 1.¹¹

Não trate o placar como um benchmark de modelos. Não é.

As vitórias de Claude se concentram em tarefas de revisão, verificação e segurança: 7 de 8 vitórias são de alta confiança em tarefas envolvendo revisão de código, análise de segurança ou avaliação técnica. A única vitória de alta confiança do Codex veio em uma tarefa de revisão de código onde sua minuciosidade procedimental e cadeias de dependência explícitas superaram a abordagem menos estruturada de Claude. As outras duas vitórias foram de baixa confiança. O padrão: Claude produz planos mais acionáveis e tecnicamente precisos. Codex produz processos operacionais mais fortes e cobertura teórica mais ampla.

Ricouard estava certo. Qualidade de planejamento versus confiabilidade de execução é um eixo real.¹ Mas o placar reflete meu mix de tarefas (pesado em revisão de segurança e arquitetura), não algum ranking objetivo de modelos. Alguém executando duelos em desenvolvimento greenfield ou automação de infraestrutura provavelmente veria resultados diferentes. A análise de Nathan Lambert sobre a era pós-benchmark faz o mesmo ponto: benchmarks tradicionais não transmitem mais sinal significativo quando as margens finas entre Opus 4.6 e Codex 5.3 dependem do formato da tarefa e da metodologia de avaliação.¹⁰

O placar conta sobre meu fluxo de trabalho. Não diz qual modelo é “melhor.”

A Síntese É o Produto

O plano vencedor não é o ponto. A síntese é.

Cada duelo produz três artefatos: Plano Alpha, Plano Beta e a Síntese. A síntese segue uma estrutura consistente: adotar a estratégia central do vencedor, incorporar os casos extremos válidos do perdedor, remover escopo desnecessário de ambos. Não é diplomática. Não divide a diferença. Faz escolhas explícitas sobre quais elementos manter e quais descartar, com justificativa escrita para cada um.

No duelo de expansão de corpus de vagas, o plano de Claude ativou a infraestrutura existente primeiro (scripts de seed para 8.780 boards conhecidos que o sistema ainda não estava consultando), depois expandiu para novas plataformas ATS, depois construiu sistemas de descoberta.⁶ O plano do Codex começou com uma auditoria de codebase e especificação de instrumentação antes de ingerir uma única vaga. Claude venceu em simplicidade e acionabilidade. Mas Codex identificou algo que Claude não percebeu: a necessidade de uma máquina de estados de ciclo de vida de boards (ativo/falhando/quarentena). Codex também sinalizou uma auditoria de regressão de deduplicação para evitar que a expansão de volume mascarasse uma explosão de duplicatas. A síntese manteve o sequenciamento ativar-primeiro de Claude e incorporou a observabilidade e o rastreamento de ciclo de vida do Codex como Fase 1.5, após a semeadura inicial entregar resultados mensuráveis. O mesmo padrão apareceu no duelo de sistema de ingestão de vagas, onde o plano de Claude reutilizou o APScheduler existente e as tabelas de registro enquanto Codex propôs um schema de proveniência de duas tabelas mais robusto. A síntese adotou a arquitetura pragmática de Claude e selecionou a melhoria de hash de dedup do Codex.⁷

No duelo de revisão de ATS, Claude encontrou crashes P0 em tempo de execução (incompatibilidades de assinatura de método no scheduler que silenciosamente quebrariam o rastreamento de vagas) que Codex perdeu completamente.⁵ Codex encontrou prevenção de sobreposição de scheduler e vetores de abuso de endpoints admin que Claude não sinalizou. A síntese começou com as correções P0 de Claude e complementou com o fortalecimento operacional do Codex.

O padrão ao longo dos 36 duelos: o modelo juiz consistentemente produz sínteses mais fortes do que o plano de qualquer competidor. O juiz não é mais inteligente. A estrutura adversarial força cobertura completa.⁹ Cada agente identifica riscos e casos extremos independentemente. O juiz vê todos eles. A síntese herda a união dos insights de ambos os agentes menos seus pontos cegos individuais.

O padrão se conecta a uma descoberta mais ampla da deliberação multi-agente: independência é o mecanismo. Dez agentes de deliberação avaliando uma decisão de diferentes perspectivas capturam vieses que qualquer agente único deixaria passar. Dois agentes em duelo atacando a mesma tarefa de diferentes arquiteturas capturam lacunas de implementação que qualquer agente sozinho colocaria em produção. A etapa de síntese é a mesma em ambos os sistemas: combinar avaliações independentes em um único artefato que se beneficia de todas as perspectivas.

Eu documento a camada de orquestração que suporta ambos os sistemas separadamente. O que importa aqui é que duelos e deliberação servem funções complementares. Deliberação responde “devemos construir isso?” Duelos respondem “qual é a maneira mais forte de construir isso?”

Quando Duelar vs. Quando Deliberar

Ambos os sistemas usam avaliação independente e síntese. Eles servem tipos de decisão diferentes.

Meu padrão: deliberar o design, duelar o plano de implementação, executar a síntese.

Uma decisão de remediação de segurança passa primeiro pela deliberação (“Esta é a priorização correta? Estamos perdendo problemas sistêmicos?”), depois pelo duelo (“Qual é o plano faseado mais forte para executar essas correções?”), depois pela execução a partir da síntese do juiz. O sistema de deliberação e o sistema de duelos compartilham infraestrutura, mas servem propósitos distintos no pipeline de decisão.

O Que Eu Errei

Os primeiros duelos não tinham rotulagem cega. Eu lia ambos os planos sabendo qual modelo escreveu qual. O viés de confirmação era real e mensurável: eu consistentemente pontuava Claude mais alto em Acionabilidade antes do mascaramento, e depois vi a diferença diminuir (embora não desaparecer) após introduzir a atribuição aleatória Alpha/Beta. O protocolo de mascaramento não é opcional.

Comecei com três dimensões de pontuação (Correção, Completude, Acionabilidade). Dois duelos depois, percebi que estava conflando estrutura do plano com conteúdo do plano. Adicionar Simplicidade (isso é sobre-engenharia?) e Decomposição (os passos estão bem ordenados?) separou essas preocupações e produziu pontuações mais úteis.

As primeiras tentativas de síntese misturaram ambos os planos igualmente. Os resultados eram incoerentes: a estratégia de testes do Alpha enxertada na sequência de implantação do Beta, com nenhuma das premissas de nenhum plano se sustentando. A síntese ponderada, onde o juiz explicitamente adota o framework do vencedor e incorpora seletivamente os insights do perdedor, foi a virada.

N=36 no meu mix de tarefas não é um benchmark de modelos. É uma avaliação de ferramenta de fluxo de trabalho. O sistema de duelos me diz qual agente produziu o plano mais forte para minha tarefa específica na minha base de código específica. Extrapolar para “Claude é melhor que Codex” seria o mesmo raciocínio baseado em vibes que o sistema existe para eliminar.

Eu uso Claude para julgar duelos entre Claude e Codex. Reconheço o conflito.⁸ A mitigação é estrutural: rotulagem cega, dimensões estruturadas, e o fato de que Codex venceu 3 duelos e chegou perto em vários outros. Um teste mais robusto executaria os mesmos duelos através de um juiz não-Claude (Gemini ou GPT) e compararia distribuições de pontuação. Ainda não fiz isso. Até que eu faça, a divisão 8-3 deve carregar um asterisco: o juiz e um dos competidores compartilham uma família de modelos.

Referências