Coding agents: cómo leer benchmarks sin caer en el hype

TL;DR: Las comparativas virales de coding agents (Claude Code, Codex, Cursor) sirven para decidir solo si entiendes cómo se construyen. En esta guía vas a aprender 5 señales para distinguir un benchmark reproducible de una opinión viral, y un mini-protocolo de 10 tareas para evaluar agentes con tu propio repositorio antes de migrar de herramienta.

El problema: opiniones virales disfrazadas de datos

Cada semana aparece un hilo nuevo en Reddit, Hacker News o X afirmando que un coding agent "destroza" al otro. La mayoría son anécdotas con dos o tres tareas resueltas en directo, sin repositorio público ni criterios de evaluación claros. El problema es que esas opiniones circulan más rápido que los benchmarks serios y terminan moldeando decisiones técnicas.

En mi experiencia migrando flujos de Java a Python con asistencia de IA, el agente que "gana" depende del tipo de tarea, del tamaño del repo y de tu propio setup. Un benchmark genérico no captura nada de eso. Y aun así, mucha gente cambia de herramienta cada vez que un post viral lo convence.

Por qué importa: cambiar de coding agent tiene coste real. Reconfigurar memoria, MCPs, skills y permisos lleva días. Si decides basándote en un titular, vas a pagar ese coste para descubrir que tu flujo va peor.

¿Qué es un benchmark reproducible de coding agents?

Un benchmark reproducible de coding agents es una evaluación donde los repositorios, las tareas y los criterios de éxito son públicos, de modo que otro desarrollador puede repetir el experimento y obtener resultados comparables. La diferencia con una opinión es la trazabilidad.

Tres elementos lo definen:

• Repos reales: open source, con commits y tests previos.
• Tareas concretas: bug fix, refactor, feature, migración, cada una con criterios de aceptación.
• Métricas explícitas: tasa de tests que pasan, líneas modificadas, número de iteraciones y coste en tokens.

Si falta alguno de los tres, lo que tienes es una review subjetiva, no un benchmark. SWE-bench Verified, por ejemplo, cumple los tres y por eso aparece en la documentación oficial de varios proveedores.

5 señales para distinguir un benchmark serio

1. ¿Hay repositorios públicos enlazados?

Si la comparativa no enlaza al menos un repo open source con su commit SHA o tag, el benchmark no es reproducible. "Tarea de mi proyecto privado" significa que tienes que confiar a ciegas en el autor. Buenos benchmarks usan repos como django/django, pallets/flask o microsoft/typescript, congelados en un commit específico.

2. ¿Cuántas tareas se evaluaron?

Tres tareas no son una muestra. Cinco tampoco. Para que un patrón sea creíble necesitas mínimo 20-30 tareas variadas. Cuando ves "probé los 2 agentes con 4 tareas y X ganó", tradúcelo a "este autor tuvo un buen día con X". El ruido domina cualquier conclusión por debajo de 20 muestras.

3. ¿Las tareas tienen criterios de aceptación?

"El agente arregló el bug" no es un criterio, es una opinión. Un criterio real es: el test test_user_creation pasa, no hay regresiones en la suite completa, y los tipos compilan sin errores. Si el benchmark no define cómo se decide quién acierta, no decide nada.

4. ¿Se reportan los fallos, no solo los éxitos?

Un benchmark honesto incluye alucinaciones, loops, ediciones rotas y casos donde el agente borra archivos por error. Si solo ves victorias, estás leyendo marketing disfrazado. La proporción de fallos por categoría es donde aparece la información útil para tu día a día.

5. ¿Hay control de variables?

Mismo modelo subyacente, misma versión del cliente, mismo contexto inicial, misma configuración de tools y MCPs. Si un agente corre con 5 MCPs cargados y otro con ninguno, no comparas agentes, comparas setups. Como ya conté en mi post sobre los 18.000 tokens ocultos de los MCPs en Claude Code, el contexto se infla rápido y altera resultados.

Tabla rápida: benchmark serio vs opinión viral

Criterio	Benchmark serio	Opinión viral
Repos	Públicos con SHA fijo	"Mi proyecto" o no especificado
Tareas	20-30+	2-5
Criterios	Tests, regresiones, tipos	"Funciona"
Fallos	Reportados por categoría	Solo éxitos
Setup	Documentado e idéntico	Ad hoc

Mini-protocolo: evaluar coding agents en tu repo

Antes de migrar de Claude Code a otro agente, mide en tu propio repo. Este protocolo cabe en una tarde:

1. Elige 10 tareas reales de los últimos 30 días: 4 bug fixes, 3 features, 2 refactors, 1 migración pequeña.
2. Documenta criterios de aceptación antes de ejecutar nada (tests que deben pasar, archivos que no deben tocarse).
3. Define el setup base: mismos MCPs, mismas skills, mismo CLAUDE.md o equivalente. Si comparas con Cursor o Codex, replica el contexto lo mejor posible.
4. Ejecuta cada tarea con cada agente y anota: tests que pasan, iteraciones necesarias, tokens consumidos, tiempo total.
5. Registra los fallos con detalle: alucinó un paquete, editó archivo equivocado, entró en loop, abandonó.

Una hoja de cálculo basta. Vas a descubrir que el agente "mejor" cambia según el tipo de tarea: uno destaca en refactors largos, otro en bug fixes localizados. Esa es información útil, no un titular.

Aplicación práctica: cuándo conviene mirar benchmarks externos

No siempre tiene sentido evaluar tú mismo. Los benchmarks externos son útiles cuando:

• Vas a cambiar de modelo base (por ejemplo, de Sonnet a Opus). Aquí el post sobre Claude Opus 4.7 en tu flujo diario da contexto sobre qué cambia de verdad.
• Estás eligiendo entre dos productos completamente nuevos para ti.
• Necesitas justificar una decisión técnica ante tu equipo y un benchmark público pesa más que tu palabra.

En cambio, si ya usas Claude Code y dudas si pasarte a Codex o seguir con tu setup actual, el protocolo de las 10 tareas te da una respuesta más fiable que cualquier comparativa pública.

En Producción

Tres consideraciones críticas al mover este análisis a tu trabajo diario:

Coste por tarea, no por millón de tokens. Los benchmarks suelen reportar coste agregado, pero lo que importa es cuánto cuesta resolver una feature media en tu repo. En mi caso, ronda los 0,40-1,20€ por tarea según complejidad, con un presupuesto mensual de 30-40€ en APIs entre Anthropic y OpenAI.

Estabilidad entre versiones. Un benchmark de la semana pasada puede no aplicar hoy si el modelo cambió. La comunidad lleva semanas comentando comportamientos cambiantes en versiones recientes de Opus. Si dependes de un agente para producción, separa instrucciones, tests y verificación para no quedarte ciego ante cambios aguas arriba.

Aislamiento de contexto. Cuanto más MCPs, más skills y más memoria cargues, más difícil es comparar limpio. Si quieres ahorrar contexto antes de medir, vale la pena revisar el setup mínimo de memoria, MCPs y mapa de repo.

Errores comunes y depuración

• Error: el benchmark dice X gana, pero a ti te va peor → Causa: el repo del benchmark no se parece al tuyo (lenguaje, tamaño, tests). Solución: corre el protocolo de 10 tareas en tu repo antes de migrar.
• Error: dos agentes parecen empatados → Causa: muestra demasiado pequeña. Solución: amplía a 30+ tareas o segmenta por tipo (bug fix, feature, refactor).
• Error: el agente fallaba con tareas que antes resolvía → Causa: cambio de versión del modelo o del cliente. Solución: registra versión exacta en cada test y repite la batería tras updates importantes.
• Error: tokens disparados sin mejora de calidad → Causa: contexto inflado por MCPs o skills cargadas sin necesidad. Solución: aplica los principios de control de coste y calidad con /effort y Auto Mode.

Preguntas frecuentes

¿SWE-bench Verified es suficiente para decidir entre Claude Code, Codex y Cursor?

No por sí solo. SWE-bench Verified mide capacidad del modelo en tareas reales de Python, pero no captura la calidad del harness (memoria, tools, MCPs, skills) que diferencia a Claude Code, Codex o Cursor. Úsalo como punto de partida, no como veredicto.

¿Cuánto tarda el protocolo de 10 tareas?

Entre 3 y 6 horas si las tareas ya están identificadas y los criterios de aceptación claros. Lo más costoso es preparar las tareas, no ejecutarlas. Una vez tienes la batería, repetirla con un nuevo agente lleva una hora.

¿Tiene sentido comparar Claude Code con Cursor si tienen UX distintas?

Sí, mientras controles el setup. Cursor integra el agente en el IDE y Claude Code vive en terminal, pero ambos resuelven la misma clase de tareas. Lo importante es fijar el modelo base, los tools disponibles y el contexto inicial. Si lo haces bien, mides al agente, no al envoltorio.

Cierre

Hemos visto cómo distinguir un benchmark reproducible de una opinión viral con cinco señales (repos públicos, número de tareas, criterios de aceptación, reporte de fallos y control de variables) y cómo construir un protocolo de 10 tareas para evaluar coding agents en tu propio repositorio. La clave no es elegir el agente que gana en Twitter, sino el que gana en el código que tú mantienes cada día.

Antes de migrar de herramienta, mide tu flujo real. Una tarde de evaluación honesta vale más que diez hilos virales. ¿Has montado tu propia batería de tareas para comparar coding agents? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el próximo post toca cómo construir esa batería de evaluación con tareas reales sin perder tres días en preparación.