Claude Code, Codex e Gemini no mesmo time: quem faz o quê

A pergunta que mais recebemos sobre agentes de codificação é qual deles é o melhor. É a pergunta errada, e ela custa caro: leva o time a escolher uma ferramenta, adotar em tudo, bater na limitação dela em três semanas e concluir que a categoria inteira não funciona. Na Codemix, Claude Code, Codex e Gemini rodam no mesmo projeto, com funções diferentes e critérios claros de quando cada um entra. Este artigo é a régua que usamos para decidir.

A pergunta certa

A pergunta certa não é “qual é o melhor”, é “qual deles resolve este tipo de tarefa com menos revisão humana”. A diferença entre as duas é o que separa um time que usa agentes de um time que testou agentes. Comparar por nota de benchmark leva a escolher pela média de tarefas que você não faz.

Na prática, três variáveis decidem quase tudo. O tamanho do contexto necessário, ou seja, quanto o agente precisa ler antes de escrever a primeira linha. O grau de fechamento da tarefa, ou seja, se existe critério objetivo de pronto. E o custo do erro, ou seja, se uma decisão errada é revertida com um comando ou se ela chega ao cliente.

O que é um agente de codificação

Um agente de codificação é um programa que recebe um objetivo em linguagem natural, lê o código do projeto, decide sozinho quais arquivos abrir, escreve alterações, roda testes e comandos, e itera até considerar a tarefa concluída. A diferença para um autocompletar de editor é o ciclo fechado: o agente age, observa o resultado da própria ação e corrige.

Isso muda a natureza do trabalho de quem programa. O tempo deixa de ser gasto escrevendo e passa a ser gasto especificando e revisando. Um time que não se organiza para revisar mais rápido do que antes não colhe ganho nenhum, porque o gargalo apenas muda de lugar.

Vale registrar o limite comum aos três. Nenhum deles entende o negócio. Todos escrevem código plausível para o objetivo declarado, e código plausível para o objetivo errado é o defeito mais caro que existe, porque passa em todos os testes automáticos.

Os três lado a lado

A tabela abaixo é uma leitura de uso, não uma medição de laboratório. Ela reflete o que observamos operando os três nos mesmos projetos, com os mesmos revisores, ao longo de 2026.

Critério	Claude Code	Codex	Gemini
Fabricante	Anthropic	OpenAI	Google
Casa natural	Terminal, sobre o repositório	Terminal e nuvem, tarefa delegada	Terminal e ecossistema Google
Ponto mais forte	Trabalho longo em código existente	Muitas tarefas fechadas em paralelo	Volume de contexto para leitura
Tipo de tarefa ideal	Refatoração, correção com causa a investigar	Lote de mudanças pequenas e independentes	Análise de sistema inteiro antes de decidir
Personalização do fluxo	Alta, com regras e ferramentas do projeto	Média, orientada a tarefa	Média, forte quando o dado já é Google
Onde costuma tropeçar	Tarefa vaga sem critério de pronto	Mudança que exige contexto amplo do sistema	Edição fina em repositório grande e antigo
Revisão humana	Obrigatória	Obrigatória	Obrigatória

Claude Code: onde ele ganha

Claude Code é o agente da Anthropic que roda no terminal, dentro da pasta do projeto, com acesso aos arquivos reais. É o que usamos como padrão em repositório de produção. O motivo não é qualidade de código isolada: é que ele se encaixa melhor na disciplina de trabalho que um sistema em produção exige.

Três características sustentam essa escolha. A primeira é o arquivo de instruções do projeto, versionado junto com o código, onde ficam as regras da casa: convenção de nome, o que nunca mexer, como rodar teste, qual banco é qual. Toda sessão começa com essas regras carregadas, e elas evoluem por revisão como qualquer outro arquivo.

A segunda é o controle de permissão por ação. Dá para definir o que roda sem perguntar, o que pede confirmação e o que é proibido. Num projeto que toca banco de cliente, essa granularidade é a diferença entre delegar e torcer.

A terceira é a capacidade de manter uma linha de trabalho longa sem perder o fio. Investigar um defeito que passa por quatro camadas, entender por que passa, corrigir e provar que corrigiu é uma tarefa que exige lembrar o que já foi descartado. É aí que a diferença aparece mais.

Codex: onde ele ganha

Codex, da OpenAI, rende mais quando o trabalho pode ser quebrado em tarefas fechadas e independentes. O padrão de uso que funciona é delegar um lote: dez ajustes pequenos, cada um com descrição do resultado esperado, e revisar as dez entregas depois. Ele é bom nesse formato de fila.

Casos em que ele entra primeiro no nosso fluxo: cobertura de teste em módulo que ninguém testou, migração mecânica de biblioteca com mudança repetitiva em muitos arquivos, padronização de formato, e conversão de um conjunto de rotinas de um padrão para outro. São tarefas com muita repetição e critério objetivo.

Onde ele costuma custar mais do que rende: mudança que depende de entender uma regra de negócio espalhada por cinco arquivos sem documentação. A tarefa parece pequena e não é, e o resultado passa no teste sem estar certo.

Gemini: onde ele ganha

Gemini entra quando o problema, antes de ser de código, é de leitura. Janela de contexto grande resolve uma classe específica de tarefa: entender um sistema inteiro que ninguém documentou, comparar um manual de integração longo com o que o código realmente faz, ou varrer horas de log procurando o padrão que antecede a falha.

Também é a escolha natural quando o dado já mora no ecossistema Google. Planilha, documento e serviços de nuvem da própria casa reduzem o atrito de acesso, e reduzir atrito de acesso é metade do trabalho de integração.

O uso mais comum na Codemix é o de reconhecimento: Gemini lê tudo e produz o mapa, o mapa vira especificação, e a especificação vai para outro agente executar. Separar leitura de escrita melhora o resultado dos dois lados.

Quem lê o sistema não precisa ser quem escreve a correção. Separar as duas etapas é o ajuste mais barato que já fizemos no nosso próprio processo.

Como dividimos o trabalho

A divisão abaixo não é doutrina, é o fluxo que sobrou depois de um ano ajustando. Ela existe para eliminar a discussão sobre qual ferramenta usar em cada momento, que é uma discussão que consome tempo e não produz software.

1. Reconhecimento. Gemini lê o repositório, a documentação existente e os logs, e devolve um mapa do sistema com pontos de risco. Nada é alterado nesta etapa.
2. Especificação. Uma pessoa transforma o mapa em tarefas com critério de aceite. É a etapa que não delegamos, e é a que mais determina o resultado.
3. Lote mecânico. Codex recebe as tarefas repetitivas e independentes, em paralelo, cada uma com o teste que prova que ficou pronta.
4. Trabalho estrutural. Claude Code recebe o que exige investigação, decisão de desenho e mudança que atravessa camadas, sempre com as regras do projeto carregadas.
5. Revisão cruzada. Um agente diferente do que escreveu revisa a mudança antes da pessoa. Ele não aprova nada, só levanta pontos, e reduz o tempo da revisão humana.
6. Aprovação humana. Ninguém publica sem revisão de gente. Vale para as três ferramentas, sem exceção e sem atalho para pressa.

Um detalhe importante: o passo 5 funciona melhor com um agente de fabricante diferente do que escreveu. Modelos da mesma família tendem a concordar com as próprias escolhas, e uma revisão que concorda com tudo não é revisão.

Quanto custa manter três

Manter três assinaturas parece desperdício até você comparar com o custo de uma escolha errada travando o time. O gasto com ferramenta é pequeno diante do custo de hora de desenvolvimento, e a diferença de produtividade entre a ferramenta certa e a errada para uma tarefa específica é grande.

O custo que ninguém contabiliza é outro: o de manter três formas diferentes de trabalhar na cabeça do time. Isso se resolve com o fluxo escrito, como o da seção anterior, e com um só arquivo de regras por projeto, lido pelas três ferramentas. Sem isso, a variedade vira confusão.

Há também um custo de contexto que só aparece depois de algumas semanas. Cada ferramenta guarda o histórico da própria sessão, e esse histórico não atravessa de uma para outra. Quando uma tarefa passa por duas ferramentas, o que precisa ser preservado tem que estar escrito em algum lugar do repositório, e não na memória da conversa. Times que não percebem isso repetem a mesma explicação três vezes por semana e concluem, erradamente, que os agentes esquecem tudo.

A camada que evita o lock-in

A preocupação legítima de quem adota três ferramentas é ficar preso a alguma delas. A resposta é arquitetural: o que é seu fica no seu repositório, em formato aberto, e a ferramenta é apenas o motor que lê aquilo. Quatro coisas precisam viver do seu lado.

• As regras do projeto, em arquivo de texto versionado, não em configuração de conta do fornecedor.
• As ferramentas que o agente pode chamar, expostas por um protocolo aberto, para que qualquer agente consiga usá-las.
• Os testes que definem pronto, porque são eles que dizem se a entrega serve, independentemente de quem escreveu.
• O registro do que foi feito, no histórico do repositório e na trilha de auditoria do sistema, nunca só no histórico de conversa da ferramenta.

Com essas quatro coisas do seu lado, trocar de agente é uma decisão de terça-feira. Sem elas, é um projeto de migração. A diferença não está no fornecedor escolhido, está em onde o conhecimento do projeto foi guardado.

O que não delegamos a nenhum

Existe uma lista curta de decisões que continuam sendo de gente, e ela não muda conforme o modelo melhora. Não é desconfiança da ferramenta: é que essas decisões dependem de contexto que não está no repositório.

• Definir o que é sucesso. O critério de aceite é o insumo, não a saída.
• Escolher a arquitetura. Um agente escreve muito bem dentro de uma decisão de desenho e não tem como saber o que a empresa vai precisar em dois anos.
• Aprovar mudança que toca dado pessoal. Aqui existe responsabilidade legal, e responsabilidade legal tem nome de pessoa.
• Decidir o que apagar. Remoção definitiva de dado ou de arquivo pede confirmação humana, sempre.
• Publicar em produção. A porta final é humana, mesmo quando todo o resto foi automático.

O arquivo de regras: o que colocar dentro

O arquivo de regras do projeto é um texto curto, versionado junto com o código, que todo agente lê antes de começar. Ele responde o que um desenvolvedor novo perguntaria no primeiro dia. Quando está bem escrito, corta a maior parte do retrabalho, porque o agente para de reinventar convenção que a casa já tem.

O erro mais frequente é escrever um manual de vinte páginas que ninguém mantém. O arquivo útil tem uma página e responde seis perguntas.

1. O que este projeto é. Duas frases sobre o que o sistema faz e para quem. Sem isso, o agente escolhe padrões de um domínio que não é o seu.
2. Como rodar e como testar. Os comandos exatos, incluindo o que precisa estar no ar. É a informação que mais economiza tentativa e erro.
3. Convenções que já existem. Padrão de nome, organização de pasta, estilo de mensagem de alteração. Uma linha cada, com exemplo.
4. O que nunca alterar. Arquivo gerado, migração já publicada, contrato de integração acordado com terceiro. Lista curta e explícita.
5. Qual ambiente é qual. Nome de banco, endereço de serviço e como distinguir produção de teste em um relance. Evita o pior tipo de acidente.
6. Onde ficam os segredos. E, principalmente, que eles nunca entram no código nem no texto da instrução.

Uma prática que rende: sempre que uma revisão humana apontar o mesmo problema pela segunda vez, a correção vai para o arquivo de regras em vez de virar comentário no pedido de alteração. Em poucas semanas o arquivo passa a conter exatamente o conhecimento que o time repetia de boca.

Três padrões de instrução que funcionam nos três

A forma da instrução muda mais o resultado do que a escolha da ferramenta. Estes três padrões funcionam igualmente bem em Claude Code, Codex e Gemini, e podem ser adotados hoje sem mudar nada da infraestrutura.

Primeiro, o critério de pronto antes da tarefa. Em vez de pedir “melhore o desempenho da listagem”, escreva “a listagem de pedidos precisa responder em menos de 400 milissegundos com 50 mil registros, medido pelo teste que já existe”. A segunda versão pode ser verificada por uma máquina, e o que pode ser verificado pode ser iterado sem você.

Segundo, o contexto negativo. Dizer o que não fazer economiza mais tempo do que dizer o que fazer. “Não altere o contrato de saída da rota” e “não instale biblioteca nova” evitam as duas classes de entrega que mais voltam na revisão.

Terceiro, a tarefa de investigação separada da tarefa de mudança. Peça primeiro o diagnóstico, sem permissão de escrita, leia o diagnóstico, e só então autorize a correção. Esse par de etapas custa cinco minutos a mais e evita a correção confiante do sintoma errado, que é o defeito mais caro de revisar.

Como saber se está valendo

Linha de código escrita por agente é a métrica errada, porque mais código costuma ser pior, não melhor. As perguntas que respondem se o investimento vale são outras, e todas podem ser medidas com o que o repositório já registra.

O que medir	De onde tirar	O que indica
Tempo entre início e publicação	Histórico do repositório	Se o gargalo saiu de escrever e foi para revisar
Rodadas de revisão por mudança	Comentários no pedido de alteração	Qualidade real da primeira entrega
Taxa de reversão	Reversões no histórico	Se está entrando defeito que os testes não pegam
Cobertura de teste	Relatório de cobertura	Se o lote mecânico está rendendo
Tempo de revisão humana	Marcação de tempo do time	Se o novo gargalo está sendo tratado

Se a taxa de reversão sobe enquanto o tempo até publicar cai, o time está trocando qualidade por velocidade sem ter decidido isso. É o sinal mais comum de que a revisão foi afrouxada, e é o único indicador desta lista que merece uma reunião no mesmo dia.

Perguntas frequentes

Preciso mesmo de três ferramentas?

Não para começar. Um time pequeno começa com uma, aprende a escrever critério de aceite e o arquivo de regras do projeto, e só adota a segunda quando bater numa limitação concreta e nomeada. Adotar três de uma vez sem processo escrito só multiplica a confusão.

Qual escolher se for só uma?

Se o trabalho é sobre código que já existe, escolha o agente que roda no terminal sobre o repositório real e permite regras versionadas do projeto. É o formato que se encaixa em revisão e permissão, e revisão e permissão é o que decide se o agente chega à produção.

Agente de codificação substitui desenvolvedor?

Muda o que o desenvolvedor faz. O tempo migra de escrever para especificar, revisar e decidir arquitetura. Times que tratam a mudança como corte de pessoas costumam perder justamente a capacidade de revisar, que é o que passa a limitar a velocidade.

Como impedir que o agente vaze código do cliente?

Com três medidas combinadas: contrato que define o tratamento de dado do fornecedor, segredo fora do repositório e fora do prompt, e permissão mínima na credencial que o agente usa. A terceira é a que mais gente esquece e a que mais protege.

Vale usar agente em sistema legado?

Vale, e costuma render mais do que em projeto novo, porque a maior dor do legado é ninguém saber como ele funciona. A etapa de reconhecimento, em que o agente lê tudo e produz o mapa, entrega valor antes de qualquer linha ser alterada.

E quando o modelo que usamos for descontinuado?

Por isso o conhecimento do projeto fica em arquivo do seu repositório e as ferramentas ficam atrás de um protocolo aberto. Com essa separação, trocar o motor é configuração. Sem ela, é reescrita, e aí a descontinuação vira um projeto.

Qual é o primeiro passo para um time que nunca usou?

Escrever o arquivo de regras do projeto antes de instalar qualquer coisa. Convenções, o que nunca mexer, como rodar teste, qual ambiente é qual. Uma tarde de trabalho que melhora o resultado de qualquer ferramenta escolhida depois.

Próximo passo

Se o seu time está na dúvida entre ferramentas, pule a comparação e escreva primeiro o critério de aceite de três tarefas reais da semana. Com esses três critérios na mão, a escolha se resolve sozinha, porque fica claro qual tipo de tarefa domina o seu dia.

Continuando pelo blog: Agente ou automação, a pergunta que economiza meio projeto trata da decisão anterior a esta, e Legado sem API mostra o que fazer quando o sistema a integrar não coopera.