Durante el último año medimos la carrera entre coding agents casi exclusivamente con una pregunta:
¿Cuál modelo es mejor?
Después llegaron los benchmarks.
Luego las comparaciones de precio.
Más tarde empezamos a mirar velocidad, contexto, uso de herramientas y capacidad para resolver tareas reales.
Ahora apareció otra métrica.
Y, curiosamente, puede ser una de las más interesantes hasta ahora.
Un análisis reciente sobre repositorios públicos muestra que Codex CLI aparece referenciado en más repositorios que Claude Code. Detrás aparecen Copilot Agent, Gemini CLI y Cursor.
La reacción inmediata es obvia:
“Entonces Codex ganó.”
Pero esa conclusión probablemente sea incorrecta.
Porque esta métrica no está midiendo el mejor agente.
Está midiendo algo mucho más sutil.
Visibilidad no es lo mismo que uso
Primero conviene entender qué significa realmente “aparecer en un repositorio”.
No implica necesariamente que un desarrollador use Codex todos los días.
Lo que significa es que, de alguna forma, Codex quedó registrado dentro del proyecto.
Puede ser mediante:
AGENTS.md- scripts
- workflows
- documentación
- configuraciones
- ejemplos
- archivos de bootstrap
Es decir, deja evidencia pública.
Y eso es muy distinto de medir usuarios activos.
Claude Code, por ejemplo, puede tener muchísimo uso en proyectos privados que nunca publican su configuración.
OpenCode puede vivir completamente fuera del repositorio.
Cursor puede usarse todos los días sin dejar prácticamente ninguna huella.
La métrica mide presencia observable.
No uso invisible.
Y ambas cosas cuentan historias diferentes.
Codex tiene una ventaja natural
Hay otro detalle.
OpenAI viene empujando Codex como parte de un ecosistema mucho más amplio.
ChatGPT.
La API.
El CLI.
Integraciones.
Documentación.
Ejemplos oficiales.
Cuando miles de desarrolladores copian ejemplos directamente desde la documentación, esos archivos terminan apareciendo en GitHub.
Eso aumenta enormemente la visibilidad pública.
No necesariamente el uso intensivo.
Pero sí la superficie observable.
Claude Code juega otro partido
Claude Code, en cambio, parece haber evolucionado hacia otro tipo de adopción.
Su comunidad invierte muchísimo tiempo en construir:
- Skills.
- Hooks.
- Plugins.
- MCP.
- Subagentes.
- Workflows.
- Memoria.
Gran parte de ese valor vive fuera del repositorio público.
O dentro de infraestructura privada de los equipos.
Eso significa que comparar únicamente “cantidad de repositorios” probablemente subestime parte importante de su ecosistema.
Es parecido a medir Kubernetes contando únicamente los archivos YAML públicos.
Obtendrías una señal útil.
Pero incompleta.
El verdadero dato interesante
Lo realmente importante no es quién está primero.
Es que por primera vez empezamos a tener métricas distintas de los benchmarks.
Durante mucho tiempo la conversación fue:
- SWE-bench
- HumanEval
- LiveCodeBench
Todas intentaban responder una pregunta:
“¿Qué modelo programa mejor?”
Ahora aparecen preguntas nuevas.
¿Cuántos proyectos lo adoptan?
¿Cuánto código permanece?
¿Cuánto cuesta operarlo?
¿Cuántos workflows dependen de él?
¿Cuántos plugins existen?
¿Cuántas skills comparte la comunidad?
¿Cuántos MCP Servers soporta?
Estamos empezando a medir ecosistemas.
No únicamente modelos.
La nueva competencia
Eso cambia completamente la lectura del mercado.
Porque un agente exitoso necesita mucho más que un buen LLM.
Necesita:
- herramientas,
- memoria,
- observabilidad,
- documentación,
- comunidad,
- ejemplos,
- integraciones,
- extensiones.
Es exactamente lo mismo que ocurrió con IDEs.
Visual Studio Code no ganó únicamente porque editara mejor texto.
Ganó porque construyó el ecosistema más fuerte.
Los coding agents parecen dirigirse hacia el mismo destino.
¿Qué debería mirar un Engineering Manager?
Si mañana tu equipo evalúa un agente, probablemente convenga mirar mucho más que benchmarks.
Preguntas como estas empiezan a ser igual de importantes:
- ¿Qué tan fácil es integrarlo?
- ¿Qué comunidad tiene?
- ¿Cuántos ejemplos existen?
- ¿Hay Skills reutilizables?
- ¿Hay servidores MCP maduros?
- ¿Qué tan portable es el workflow?
- ¿Qué tan fácil será cambiar de modelo dentro de un año?
La última pregunta probablemente sea la más importante de todas.
Porque los modelos cambian.
El harness permanece.
La métrica que todavía falta
Hay una estadística que todavía nadie publica de forma consistente.
Y probablemente sea la más valiosa.
No cuántos repositorios mencionan un agente.
Sino:
¿Cuántas horas reales de ingeniería produce?
Porque un agente instalado no necesariamente es un agente usado.
Y un agente usado no necesariamente genera valor.
En algún momento empezaremos a medir:
- tareas completadas,
- tiempo ahorrado,
- costo por workflow,
- porcentaje de código aceptado,
- retrabajo,
- satisfacción del desarrollador.
Ese día la conversación cambiará otra vez.
El mercado empieza a madurar
Lo interesante de este ranking no es que Codex aparezca primero.
Es que, por primera vez, la discusión empieza a salir de los benchmarks.
Estamos entrando en una etapa donde importa tanto el ecosistema como el modelo.
Donde las métricas de adopción empiezan a convivir con las métricas de rendimiento.
Y donde la pregunta deja de ser:
“¿Cuál agente escribe mejor código?”
Para transformarse en algo mucho más útil:
”¿Cuál agente logra convertirse en parte permanente del stack de ingeniería?”
Esa probablemente sea la competencia que realmente definirá los próximos años.
Por Grego — yoDEV
codex claudecode aiagents developertools #PlatformEngineering aiengineering #EngineeringManagement llmops #SoftwareEngineering opensource