Durante o último ano medimos a corrida entre agentes de codificação quase exclusivamente com uma pergunta:
Qual modelo é melhor?
Depois vieram os benchmarks.
Luego as comparações de preço.
Mais tarde começamos a olhar velocidade, contexto, uso de ferramentas e capacidade para resolver tarefas reais.
Agora apareceu outra métrica.
E, curiosamente, pode ser uma das mais interessantes até agora.
Uma análise recente sobre repositórios públicos mostra que Codex CLI aparece referenciado em mais repositórios que Claude Code. Atrás aparecem Copilot Agent, Gemini CLI e Cursor.
A reação imediata é óbvia:
“Então Codex ganhou.”
Mas essa conclusão provavelmente seja incorreta.
Porque essa métrica não está medindo o melhor agente.
Está medindo algo muito mais sutil.
Visibilidade não é o mesmo que uso
Primeiro convém entender o que significa realmente “aparecer em um repositório”.
Não implica necessariamente que um desenvolvedor use Codex todos os dias.
O que significa é que, de alguma forma, Codex ficou registrado dentro do projeto.
Pode ser mediante:
AGENTS.md- scripts
- workflows
- documentação
- configurações
- exemplos
- arquivos de bootstrap
Ou seja, deixa evidência pública.
E isso é muito distinto de medir usuários ativos.
Claude Code, por exemplo, pode ter muito uso em projetos privados que nunca publicam sua configuração.
OpenCode pode viver completamente fora do repositório.
Cursor pode ser usado todos os dias sem deixar praticamente nenhuma marca.
A métrica mede presença observável.
Não uso invisível.
E ambas as coisas contam histórias diferentes.
Codex tem uma vantagem natural
Há outro detalhe.
OpenAI vem empurrando Codex como parte de um ecossistema muito mais amplo.
ChatGPT.
A API.
O CLI.
Integrações.
Documentação.
Exemplos oficiais.
Quando milhares de desenvolvedores copiam exemplos diretamente da documentação, esses arquivos terminam aparecendo no GitHub.
Isso aumenta enormemente a visibilidade pública.
Não necessariamente o uso intensivo.
Mas sim a superfície observável.
Claude Code joga outro jogo
Claude Code, em troca, parece ter evoluído para outro tipo de adoção.
Sua comunidade investe muito tempo em construir:
- Skills.
- Hooks.
- Plugins.
- MCP.
- Subagentes.
- Workflows.
- Memória.
Grande parte desse valor vive fora do repositório público.
Ou dentro de infraestrutura privada dos times.
Isso significa que comparar unicamente “quantidade de repositórios” provavelmente subestime parte importante de seu ecossistema.
É parecido com medir Kubernetes contando unicamente os arquivos YAML públicos.
Você obteria um sinal útil.
Mas incompleto.
O verdadeiro dado interessante
O realmente importante não é quem está em primeiro.
É que pela primeira vez começamos a ter métricas distintas dos benchmarks.
Durante muito tempo a conversa foi:
- SWE-bench
- HumanEval
- LiveCodeBench
Todas tentavam responder uma pergunta:
“Qual modelo programa melhor?”
Agora aparecem perguntas novas.
Quantos projetos o adotam?
Quanto código permanece?
Quanto custa operá-lo?
Quantos workflows dependem dele?
Quantos plugins existem?
Quantas skills a comunidade compartilha?
Quantos MCP Servers ele suporta?
Estamos começando a medir ecossistemas.
Não unicamente modelos.
A nova competição
Isso muda completamente a leitura do mercado.
Porque um agente bem-sucedido precisa de muito mais que um bom LLM.
Precisa de:
- ferramentas,
- memória,
- observabilidade,
- documentação,
- comunidade,
- exemplos,
- integrações,
- extensões.
É exatamente o que aconteceu com IDEs.
Visual Studio Code não ganhou unicamente porque editasse melhor texto.
Ganhou porque construiu o ecossistema mais forte.
Os agentes de codificação parecem se dirigir para o mesmo destino.
O que um Engineering Manager deveria olhar?
Se amanhã seu time avaliar um agente, provavelmente conveça olhar muito mais que benchmarks.
Perguntas como essas começam a ser igualmente importantes:
- Quão fácil é integrá-lo?
- Qual comunidade ele tem?
- Quantos exemplos existem?
- Há Skills reutilizáveis?
- Há servidores MCP maduros?
- Quão portável é o workflow?
- Quão fácil será mudar de modelo dentro de um ano?
A última pergunta provavelmente seja a mais importante de todas.
Porque os modelos mudam.
O harness permanece.
A métrica que ainda falta
Há uma estatística que ainda ninguém publica de forma consistente.
E provavelmente seja a mais valiosa.
Não quantos repositórios mencionam um agente.
Senão:
Quantas horas reais de engenharia ele produz?
Porque um agente instalado não necessariamente é um agente usado.
E um agente usado não necessariamente gera valor.
Em algum momento começaremos a medir:
- tarefas completadas,
- tempo economizado,
- custo por workflow,
- porcentagem de código aceito,
- retrabajo,
- satisfação do desenvolvedor.
Esse dia a conversa mudará outra vez.
O mercado começa a amadurecer
O interessante desse ranking não é que Codex apareça em primeiro.
É que, pela primeira vez, a discussão começa a sair dos benchmarks.
Estamos entrando em uma etapa onde importa tanto o ecossistema quanto o modelo.
Onde as métricas de adoção começam a conviver com as métricas de desempenho.
E onde a pergunta deixa de ser:
“Qual agente escreve melhor código?”
Para se transformar em algo muito mais útil:
“Qual agente consegue se tornar parte permanente da stack de engenharia?”
Essa provavelmente seja a competição que realmente definirá os próximos anos.
Por Grego — yoDEV
codex claudecode aiagents developertools #PlatformEngineering aiengineering #EngineeringManagement llmops #SoftwareEngineering opensource