Claude Code ou Codex: rodei a mesma tarefa nos dois

Rodar a mesma tarefa no Claude Code e no Codex quase nunca dá um certo e um errado. Dá duas respostas que passam nos testes uma da outra e ainda assim se comportam diferente num caso que ninguém testou. Eu medi isso numa tarefa pequena e bem especificada, e o que separou os dois não foi velocidade nem correção, foi uma decisão de projeto que nenhum deles me perguntou.

Que tarefa eu rodei nos dois, e por que essa?

Escolhi uma função pequena o bastante para caber numa leitura e específica o bastante para ter resposta certa. Ela agrupa eventos com carimbo de tempo em janelas de N minutos, com as bordas alinhadas ao relógio. Junto vinha uma suíte de testes cobrindo lista vazia, evento único, dois eventos na mesma janela, dois em janelas diferentes, entrada fora de ordem e parâmetro inválido.

O texto da tarefa foi idêntico para os dois, palavra por palavra, cada um numa pasta vazia. Os dois rodaram pelo terminal em modo não interativo, sem eu responder nada no meio. O Codex foi por codex exec com escrita liberada, o Claude Code por claude -p com edição aceita, e eu cronometrei do enter até o processo devolver o controle.

Tarefa desse tamanho é de propósito. Pedir um SaaS inteiro e comparar o resultado não mede ferramenta, mede sorte: em escopo grande cada um inventa uma arquitetura e você acaba comparando gosto. Com uma função de vinte e poucas linhas e um contrato escrito, diferença que aparecer é diferença de verdade.

Quanto tempo cada um levou, e quanto código cada um escreveu?

Estes são os números da rodada. É uma execução só, então trate como amostra e não como veredito:

A diferença de tempo é real, mas eu não construiria muita coisa em cima dela. Ela varia com carga do serviço, tamanho do contexto e sorte. O que me chamou atenção foi a outra coluna: com a mesma instrução, o Claude Code escreveu mais que o dobro de linha de teste, e o Codex entregou a implementação mais enxuta.

Os dois acertaram a tarefa?

Acertaram, e eu conferi do jeito que dá para conferir sem opinião no meio. Instalei o pytest e rodei a suíte de cada um contra o código dele. Depois cruzei: a suíte do Codex contra a implementação do Claude Code, e a do Claude Code contra a do Codex. Passou tudo, nos quatro sentidos.

Vale registrar uma coisa que os dois fizeram igual e que eu gostei. Nenhum deles conseguiu rodar os próprios testes ali, o Codex porque o pytest não estava instalado e o Claude Code porque a execução foi bloqueada por permissão. Os dois disseram isso na resposta final, em vez de afirmar que estava tudo verde. Agente que entrega e avisa o que não verificou vale mais que agente com confiança de vendedor.

Onde eles discordam sem ninguém perceber?

Aqui está a parte que me fez escrever o artigo. Os dois tinham que alinhar a janela ao relógio. O Codex ancorou o cálculo no epoch, contando os blocos a partir de 1º de janeiro de 1970, e o Claude Code ancorou na meia-noite do dia do próprio evento. Nenhum me perguntou qual eu queria, e nenhum estava desobedecendo, porque o enunciado não resolvia esse ponto.

Enquanto o tamanho da janela divide o dia inteiro, as duas âncoras dão o mesmo resultado, e é por isso que ninguém percebe. Os valores 15, 60 e 90 cabem certinho em 1440 minutos, então os dois produzem as mesmas bordas e todo teste passa. Peguei dois eventos, às 10:03 e às 10:09, e mudei só o tamanho da janela:

Com 13 minutos um deles devolve duas janelas e o outro devolve uma. Isso não é estilo, é resposta diferente para a mesma pergunta. Se esse número saísse num relatório de produto, ninguém ia abrir o código, ia olhar o gráfico e acreditar.

E as duas suítes continuam verdes. Nenhum dos dois escreveu um caso com janela que não divide o dia, e cada um testou exatamente a interpretação que ele mesmo tinha adotado.

De quem é a culpa, do agente ou de quem pediu?

É minha, e falo isso sem drama. O enunciado dizia “alinhadas ao relógio” e dava exemplo com 15 minutos, que é justo o caso onde as duas leituras coincidem. Ou seja, eu escrevi um contrato com um buraco e escolhi o exemplo que esconde o buraco. Os dois agentes fizeram o que dava: preencheram a lacuna com um padrão razoável e seguiram.

Essa é a diferença prática entre trabalhar com IA e trabalhar sozinho. Quando você escreve na mão, a lacuna aparece na hora em que você precisa digitar a linha e não sabe o que digitar. Quando o agente escreve, ela é preenchida em silêncio, e você descobre meses depois com o número errado na tela. No meu processo o antídoto não é revisar mais linha, é escrever a especificação antes e incluir de propósito o caso feio, o valor que não divide bonito.

O que isso muda no jeito de usar os dois?

Mudou três coisas aqui, e nenhuma delas é trocar de ferramenta.

A primeira é colocar o caso hostil dentro do próprio enunciado. Em vez de dizer “janelas de N minutos alinhadas ao relógio”, eu digo qual é a âncora e dou um exemplo com um N que não divide o dia. Custa uma linha e elimina a classe inteira de divergência.

A segunda é rodar a mesma tarefa nos dois quando ela é de fundação, aquele pedaço que todo o resto vai usar. Não é para escolher o melhor código, é para usar a discordância como detector. Se os dois convergem, o contrato estava fechado; se divergem, você achou um buraco na sua especificação antes de ele virar bug.

A terceira é pedir que o agente escreva o teste da decisão que ele mesmo tomou. Quando ele resolve uma ambiguidade sozinho, aquilo vira código sem virar teste, e o teste é o único lugar onde a decisão fica visível para quem abrir o arquivo depois.

Qual dos dois eu uso, afinal?

Uso os dois todo dia, e para mim a divisão está mais no formato da tarefa do que em qualidade. O Codex costuma levar vantagem quando o trabalho é fechado e mecânico, tipo refatorar um módulo inteiro para outro padrão. Ele tende a entregar código mais curto, com menos cerimônia em volta.

O Claude Code leva vantagem quando a tarefa tem contexto espalhado e depende de entender o projeto antes de escrever. Nessa rodada ele também gastou bem mais linha em teste, que geralmente é o que eu quero em código que vai ficar. Isso varia para cada um e depende do tipo de projeto que você toca, então o ideal é rodar uma tarefa sua nos dois em vez de acreditar em comparação alheia, inclusive nesta.

Se você ainda não tem os dois, dá para começar sem gastar. Eu escrevi separado o que dá para fazer com o Claude Code de graça e o que muda quando o limite acaba.

Dá para usar os dois no mesmo projeto sem virar bagunça?

Dá, e é o que eu faço, com uma regra só: um escreve, o outro revisa, e nunca os dois no mesmo arquivo ao mesmo tempo. O que gera conflito não é o modelo, é duas cabeças mexendo na mesma linha, igualzinho a dois desenvolvedores humanos sem combinar nada.

Na revisão cruzada o ganho é parecido com o que apareceu nesta medição. Quem revisa não carrega as suposições de quem escreveu, então ele bate justo nos pontos onde o outro decidiu sozinho. O detalhe que muda tudo é dar ao revisor o mesmo enunciado que o escritor recebeu, senão ele revisa o código contra a imaginação dele e reclama do que ninguém pediu.

O que perguntam sobre rodar a mesma tarefa nos dois?

Vale a pena pagar os dois? Para mim vale, porque a revisão cruzada pega uma classe de erro que nenhum deles pega sozinho. Se o seu volume é pequeno, começar por um só e usar bem já resolve a maior parte.

Um deles escreve código melhor? Nesta tarefa os dois passaram em tudo, então não dá para dizer que um escreve melhor. Dá para dizer que um escreveu mais curto e o outro escreveu mais teste. Em tarefa maior a comparação muda de natureza, porque entra arquitetura, e aí vira gosto de projeto.

Dá para automatizar essa comparação? Dá, e é barato: mesma tarefa, duas pastas, roda a suíte de cada um contra a implementação do outro. Quando as duas passam nos dois sentidos, você tem boa evidência de que o contrato ficou fechado. Quando uma falha, ela mostra exatamente onde os dois entenderam coisas diferentes.

Se quiser reproduzir, a tarefa é a mesma descrita no começo. Rode com um N que divida o dia e depois com 13, que é onde a diferença aparece.