Fala galera,
Tudo beleza?
Bom, acho que não é novidade para ninguém que IA no desenvolvimento de software já passou daquela fase de simplesmente completar uma linha de código ou criar um método pra gente.
Hoje temos ferramentas que conseguem analisar projetos, criar arquivos, escrever testes, ajudar em refatorações e até participar de tarefas bem maiores dentro de uma Solution. Sendo nosso Copiloto, NUNCA O PILOTO (sim no futuro esse vai aparecer tbm)
E claro... junto com isso começaram as comparações. Nesse artigo vou comparar 2 que gosto muito de usar no dia a dia, sim eu uso gemini e copilot. Mas tudo ao seu tempo, comparar diversos serviços diferentes sem usar bastante nunca foi meu foco então prefiro falar de algo que eu to usando mesmo, por isso demorei tanto pra escrever.
Codex ou Claude Code? Qual é melhor para trabalhar com .NET?
Nas minhas experiências (sim na EU, EU USANDO, EUUUUUU.. digo isso porque é normal você falar, mas eu uso como... eu to falando EUUUUU. como ponto de partida para quem principalmente ta querendo entender dos dois e usa pouco ou nunca usou) utilizando os dois, principalmente dentro do ecossistema .NET, percebi que a resposta não é tão simples.
E antes que isso vire uma guerra de torcida organizada ( ou do seu politico de estimação) nos comentários: não acho que exista um vencedor absoluto aqui. Não , não tem....
Na verdade, eles possuem formas diferentes de trabalhar e, dependendo do problema que estou tentando resolver, acabo preferindo um ou outro.
Então bora bater um papo sobre isso?
Primeiro: eles trabalham de formas bem diferentes
Uma das primeiras coisas que percebi utilizando as duas ferramentas no contexto de dev é que, apesar de ambas terem o mesmo objetivo — ajudar no desenvolvimento — a forma como chegam até a solução me parece diferente.
Codex
No meu uso, o Codex me passa uma sensação muito mais de controle sobre o que está acontecendo.
Você consegue trabalhar de uma forma mais estruturada, analisar o que será alterado e ir conduzindo a implementação.
Principalmente quando estou mexendo em código que já existe e quero fazer uma alteração específica, isso é algo que gosto bastante.
Sabe aquele:
"Mexe aqui, mas pelo amor de Deus não caga, digo, resolve mudar outras 35 coisas que eu não pedi."
Então...
Em projetos maiores ou legados isso faz bastante diferença.
O ecossistema .NET tem suas particularidades. Temos tipagem forte, Dependency Injection, vários projetos dentro da mesma Solution, NuGet, .csproj, configurações, interfaces e uma infinidade de dependências entre classes.
Então ter controle sobre o que está sendo alterado é importante.
Claude Code
Já o Claude Code me passa uma experiência bem mais agêntica.
Ahhh mas voce pode criar um agente que... sim sim, "craro,craro". Calma , vai lendo.
Ele trabalha muito através do terminal e a sensação é menos de "me ajuda a escrever esse código" e mais de:
"Esse é o problema. Investigue e veja o que precisa ser feito."
Ele pode navegar pelos arquivos, analisar dependências, executar comandos e seguir o problema por diferentes partes da aplicação.
Para tarefas maiores isso é muito interessante.
Claro que dar acesso ao terminal para uma IA sair mexendo no seu projeto parece o primeiro episódio de alguma série que termina com a criação da Skynet...
Mas com as devidas permissões e revisão, funciona muito bem. Bem mesmo!!!!!
Vamos colocar isso em alguns cenários .NET?
Porque comparação de ferramenta sem colocar um problema real no meio acaba virando aquela clássica discussão de:
"A minha é melhor porque eu gosto mais."
Então vamos para alguns cenários onde senti diferenças entre os dois.
1 - Criando APIs e aquele bom e velho arroz com feijão
Quem trabalha com ASP.NET Core sabe como é.
Controller.
DTO.
Interface.
Service.
Mapping.
Configuração.
Mais um DTO.
Mais outro DTO porque o primeiro DTO não era exatamente o DTO que precisávamos...
Nesse tipo de cenário o Codex funciona muito bem.
Quando o objetivo está claro, ele consegue gerar código C# bastante organizado, trabalhando bem com coisas como:
- Controllers
- DTOs
- Records
- Nullable Reference Types
- Services
- Interfaces
- Mapeamentos com AutoMapper ou Mapster
Para tarefas bem definidas eu gosto bastante da previsibilidade.
E o Claude Code?
Aqui aparece uma diferença interessante.
O Claude Code tende a olhar um pouco além do arquivo que você está trabalhando.
Por exemplo, durante a criação de uma API ele pode analisar o .csproj, perceber dependências necessárias e trabalhar também na estrutura que envolve aquela implementação.
Ou seja:
O Codex muitas vezes resolve muito bem a implementação.
O Claude Code tende a investigar também o ambiente onde aquela implementação precisa funcionar.
E dependendo do que você está fazendo isso economiza bastante trabalho.
2 - Refatoração e Dependency Injection
Aqui começamos a entrar em um cenário que acho mais interessante para comparar os dois.
Imagine que temos um serviço registrado como:
Transient
Mas depois de analisar a aplicação percebemos que ele deveria ser:
Scoped
Parece uma alteração simples.
E muitas vezes é.
Até você descobrir que aquele serviço é utilizado por outras cinco classes, que possuem outras dependências e que alguém resolveu criar uma dependência meio estranha no projeto três anos atrás.
Quem nunca?
Codex
Se eu isolar o problema e deixar claro o que quero modificar, o Codex costuma ser muito preciso.
Para refatorar métodos, simplificar código, melhorar LINQ ou reorganizar uma classe específica, gosto bastante do resultado.
Ele funciona quase como aquele trabalho cirúrgico:
"É aqui que precisamos mexer."
Claude Code
O Claude Code normalmente tenta entender o impacto da alteração.
Então ele pode procurar o registro no Program.cs, identificar onde aquela interface está sendo utilizada, encontrar os construtores envolvidos e trabalhar nas outras classes afetadas.
Ou seja, quando a alteração começa a atravessar vários arquivos da Solution, o comportamento agêntico começa a fazer bastante diferença.
E isso não significa que devemos simplesmente mandar:
"Vai lá e muda tudo."
e depois tomar um café.
Revise seu código. Sempre.
Já falei bastante sobre isso quando discutimos código produzido por IA: produtividade não elimina responsabilidade técnica.
3 - Bugs e testes unitários
Aqui provavelmente foi onde mais percebi a diferença de abordagem.
Se eu tenho uma regra bem definida e quero criar testes com xUnit ou NUnit, o Codex funciona muito bem.
Principalmente quando consigo informar claramente:
- Entrada
- Resultado esperado
- Cenários de erro
- Casos de borda
Ele consegue gerar rapidamente uma boa base de testes.
Agora vamos para aquele bug divertido...
Você roda:
dotnet test
E aparece aquele maravilhoso stack trace gigantesco que faz você questionar algumas decisões que tomou na carreira.
Nesse cenário o Claude Code fica muito interessante porque o fluxo pode ser mais completo.
Ele consegue trabalhar em uma sequência parecida com:
dotnet test
↓
Teste falhou.
↓
Analisa o stack trace.
↓
Procura o código relacionado.
↓
Aplica uma alteração.
↓
Executa os testes novamente.
Essa capacidade de investigar o problema em ciclos é provavelmente uma das características que mais gosto no modelo de trabalho agêntico.
Não é apenas gerar código.
É participar do processo de descobrir por que aquele código não está funcionando.
Comparando os dois
Claro que isso aqui não é benchmark científico e muito menos uma verdade universal.É A MINHA OPNIÃO COM BASE NO MEU USO.
É a percepção que tive utilizando as ferramentas dentro de cenários .NET.
| Cenário | Codex | Claude Code |
|---|---|---|
| Código C# bem definido | Excelente | Excelente |
Trabalho com .csproj / NuGet |
Bom, principalmente quando direcionado | Muito bom pelo fluxo integrado com CLI |
| Refatoração em vários arquivos | Mais controlada | Muito natural pelo comportamento agêntico |
| Precisão em alterações pontuais | Excelente | Muito boa |
| Debugging investigativo | Muito bom | Excelente |
| Curva de aprendizado | Mais simples | Exige entender melhor permissões e fluxo pelo terminal |
| Forma de trabalhar | Mais direta e controlada | Mais autônoma e investigativa |
E essa última linha talvez seja a principal diferença.
Controle x autonomia.
Pelo menos foi assim que senti trabalhando com os dois.
Tá, mas qual eu escolheria?
A resposta que todo arquiteto adora dar:
Depende. (abraço André Secco)
Hahahaha.
Mas nesse caso depende mesmo.
Eu usaria o Codex quando...
Estou trabalhando em uma base de código grande ou legada e quero ter bastante controle sobre as alterações.
Principalmente naquela Solution que existe há 10 anos, possui 47 projetos e todo mundo tem medo de mexer naquela classe que "sempre funcionou".
Você sabe qual é.
Também gosto bastante quando preciso trabalhar em:
- Algoritmos
- Métodos isolados
- Refatorações específicas
- Boilerplate
- APIs
- Regras de negócio bem definidas
Nesses casos, ser mais direto pode ser exatamente o que precisamos.
Eu usaria o Claude Code quando...
Preciso investigar um problema que atravessa diferentes partes do projeto.
Por exemplo:
- Bugs envolvendo vários projetos da Solution
- Alterações em Dependency Injection
- Criação de estruturas completas
- Execução de testes
- Build
- Migrações
- Análise de dependências
Também acho bastante interessante em projetos greenfield.
Quando você está começando um microsserviço ou uma aplicação nova, ter um agente capaz de ajudar também com o ambiente, estrutura e CLI pode economizar bastante tempo.
Então Codex ou Claude Code?
Os dois.
Eu sei, resposta fácil.
Mas foi realmente a conclusão que cheguei.
Não vejo muito sentido em transformar ferramentas de IA em escolha religiosa.
"Eu sou Team Codex."
"Eu sou Team Claude."
Calma galera...
São ferramentas.
E ferramentas diferentes podem resolver problemas diferentes.
Para mim, o Codex funciona muito bem como uma ferramenta precisa e controlada, principalmente quando sei exatamente onde quero mexer.
Já o Claude Code se destaca quando quero uma abordagem mais investigativa, principalmente quando o problema está espalhado por diferentes arquivos ou projetos.
Um trabalha muito bem comigo quando digo:
"Quero alterar isso aqui."
O outro funciona muito bem quando digo:
"Tenho esse problema. Vamos descobrir onde está?"
E acho que essa diferença resume bastante minha experiência.
IA não elimina o desenvolvedor da equação
E claro que não poderia terminar esse artigo sem falar disso. Novamente sempre reforço que a i.a. é nosso Copiloto não o piloto.
Independente de utilizar Codex, Claude Code ou qualquer outra ferramenta que aparecer amanhã, existe uma coisa que não mudou:
Você continua sendo responsável pelo código.
Não importa se a IA criou um método.
Não importa se ela alterou 15 arquivos.
Não importa se ela rodou todos os testes e apareceu aquele maravilhoso verdinho dizendo que está tudo certo.
Revise.
Entenda.
Teste.
Questione.
Porque a melhor utilização dessas ferramentas, pelo menos na minha opinião, não é substituir o desenvolvedor.
É aumentar a capacidade dele.
Uma IA com um bom desenvolvedor pode aumentar muito a produtividade.
Uma IA executando qualquer coisa sem revisão só consegue produzir problema mais rápido.
No fim, Codex e Claude Code são duas excelentes ferramentas e pretendo continuar utilizando as duas de acordo com o problema que preciso resolver.
E provavelmente mês que vem aparece outra e teremos que fazer essa discussão toda novamente. Ate porque ainda quero falar do Gemini e do Copilot.
Espero ter ajudado!
Aquele abraço!
Top comments (0)