Los benchmarks de IA para programar que sí importan en 2026
DominicodeHace tres días salió Claude Opus 5.5. Antes de que terminara el día tenía cinco mensajes distintos preguntándome lo mismo: ¿es el mejor para programar ahora?
Mi respuesta debería haber sido fácil. No lo fue.
El problema no es falta de datos. La mayoría de los benchmarks de IA para programar que circulan hoy no miden lo que dicen medir. Hace unas semanas expliqué por qué el 96% de SWE-bench Verified es ruido — contaminación de datos, tests rotos, un puñado de repos repetidos hasta el cansancio. Si no lo leíste, el resumen cabe en una frase: ese número no predice si el modelo te sirve a ti.
Eso deja una pregunta sin responder, y me la hicieron cinco veces esta semana: vale, ¿pero entonces qué SÍ miro? No es solo "el coste por tarea" — de eso ya hablé aparte. Es más concreto que eso.
En corto: los benchmarks de IA para programar que importan en 2026 son los que resisten la contaminación con datasets privados o rotativos, miden tareas multi-paso sobre entornos reales — no snippets sueltos — y reportan tasa de éxito junto al coste por tarea. Terminal-Bench, el subset privado de SWE-bench Pro, el time-horizon de METR y las arenas con voto humano cumplen esas condiciones mejor que cualquier leaderboard de un solo número. Pero la señal más fiable no la publica ningún laboratorio: es el eval que montas tú mismo sobre tickets ya cerrados de tu propio repo.
¿Qué es un benchmark de IA para programar?
Un benchmark de IA para programar es un conjunto fijo de tareas de código con un criterio de éxito objetivo — tests que pasan, un PR que mergea sin romper nada — que se usa para comparar modelos o herramientas de forma reproducible.
Esa definición esconde la trampa: "reproducible" no significa "representativo". Puedes sacar un resultado perfecto en 500 tareas de Django y que eso no prediga nada sobre tu backend en Go o tu monorepo de TypeScript.
Los benchmarks fallan por tres motivos: el dataset se filtra al entrenamiento de la siguiente generación de modelos, las tareas son demasiado pequeñas para parecerse a trabajo real, y casi ninguno reporta el coste de llegar al resultado. Arreglar esos tres puntos separa un benchmark útil de uno decorativo.
Las señales que sí predicen algo en 2026
Datasets que se resisten a la contaminación
SWE-bench Pro nació para resolver el problema de memorización. Su subset público usa código con licencia copyleft (GPL) precisamente porque esa licencia "viral" hace improbable que entre en datasets de entrenamiento — pero sigue siendo código técnicamente indexable.
La parte que sí es genuinamente invisible para cualquier modelo es el subset privado, hecho con codebases 100% propietarios de 18 startups que nunca salieron de la infraestructura interna de Scale. Ahí es donde cae el rendimiento en serio: Claude Opus 4.1 pasa de 22,7% a 17,8% de resolución, y GPT-5 de 23,1% a 14,9%, según los datos publicados por Scale AI. Esa caída — y no el número público — es la que te dice cuánto del "96%" original era memoria y cuánto era capacidad real.
Evals multi-paso sobre entornos reales: Terminal-Bench
Terminal-Bench no pide generar una función: pide operar una terminal completa — instalar dependencias, compilar en varios lenguajes, depurar un fallo del sistema y verificar que el resultado final funciona de punta a punta. Se parece mucho más a un día de trabajo real que resolver un issue de una línea.
En la versión 4.0, GPT-6 Astra lidera con 58,2%, Claude Fable 5.1 queda a 0,3 puntos con 57,9%, y GLM-5.3 se queda en 41,8% — cifras del leaderboard de septiembre de 2026. Lo interesante no es quién gana: según los mismos datos, Opus 5.5 iguala a GPT-6 Astra por cerca del 40% del coste por tarea — el mismo argumento de coste que desarrollé en el post sobre agentic systems. Medir tareas de terminal completas es más honesto que medir un parche aislado, porque obliga al modelo a manejar el mismo desorden que un desarrollador maneja todos los días.
El eval con feedback real: Aider Polyglot
Aider Polyglot evalúa 225 ejercicios de Exercism en seis lenguajes con dos intentos: en el segundo, el modelo recibe el error real de los tests que falló en el primero. Mide algo que casi ningún benchmark mide — si el modelo sabe iterar con feedback, que es como trabajas tú con un agente en el día a día.
GPT-5 lidera con 0,880 sobre casi 60 modelos evaluados. Lo que vale la pena mirar no es el primer puesto, sino la distancia entre el primer y el segundo intento: ahí ves si un modelo corrige su error o lo repite.
La curva, no la foto: el time-horizon de METR
METR no compara modelos entre sí: mide la duración de tarea (en tiempo humano) que un modelo resuelve con 50% de éxito, y sigue esa cifra en el tiempo. Según su modelo, en 2024-2025 esa duración se dobló cada 4 meses, frente al ritmo de 7 meses que se mantuvo entre 2019 y 2025.
Este benchmark no te dice qué herramienta elegir hoy — te dice si conviene re-evaluar tu stack cada trimestre o si puedes esperar tranquilo. Es la única señal de esta lista pensada para planear, no para decidir ya.
Arena Elo con voto humano
WebDev Arena y Copilot Arena hacen algo que ningún leaderboard automático hace: ponen a dos modelos a resolver la misma tarea y dejan que un desarrollador real vote a ciegas cuál prefiere. WebDev Arena acumula más de 80.000 votos con un modelo Bradley-Terry, el mismo sistema detrás del Elo de ajedrez.
La ventaja: ningún laboratorio puede optimizar tan fácil para "gustarle más a un humano a ciegas" como puede optimizar para un test set conocido. La desventaja, en la siguiente sección.
Tu propio eval sobre tickets cerrados
Esta es la señal que ningún leaderboard público te va a dar, y es la más fiable de todas.
En el hilo de Hacker News sobre Real-SWE — un benchmark construido sobre código privado de empresas reales — el dato que más se repite es este: el modelo que lidera SWE-bench Verified con más del 90% de resolución cae por debajo del 40% cuando el código es privado y nunca lo vio en entrenamiento.
Lo mismo aparece en el hilo sobre el benchmark que corrió Databricks contra su propio monorepo de millones de líneas: los agentes que brillan en demos cortas se atascan en cuanto el contexto supera lo que cualquier dataset público simula.
La conclusión no es "desconfía de todo": tu repo es, literalmente, el benchmark más resistente a la contaminación que existe, porque nadie más lo tiene. Así lo montas:
- Saca 15-20 tickets ya cerrados de los últimos tres meses, con PR mergeado y tests en verde.
- Convierte el criterio de aceptación de cada ticket en un test o script de verificación automática — esto es, literalmente, revisar por contrato antes de aceptar código de un agente.
- Corre el modelo o herramienta candidata contra cada ticket sin que vea la solución original.
- Mide tres números por tarea: ¿pasó?, cuánto tardó, cuánto costó en tokens o en API.
- Repite el mismo set cada vez que cambies de modelo — así tu decisión no depende de lo que un laboratorio decida publicar esa semana.
Comparativa: qué benchmark mirar y qué esconde cada uno
| Benchmark | Qué mide | Fiabilidad en 2026 | Limitación principal |
|---|---|---|---|
| HumanEval / MBPP | Función aislada, sin contexto de repo | Baja | Contaminado desde 2022; no mide integración real |
| SWE-bench Verified (público) | Issue → PR en repos Python populares | Baja | Saturado y con memorización parcial (detalle aquí) |
| SWE-bench Pro (subset privado) | Issue → PR en codebases propietarios | Alta | Cobertura limitada de lenguajes; caro de mantener |
| Terminal-Bench 4.0 | Tareas multi-paso en shell real | Alta para infra/DevOps | Sesgado a tareas de sistema, no a feature work de producto |
| Aider Polyglot | Edición con feedback de tests, 6 lenguajes | Media-alta | Ejercicios acotados, no multi-archivo grande |
| METR time-horizon | Duración de tarea resuelta al 50% | Alta para tendencia | No dice qué herramienta usar hoy |
| Arena Elo (WebDev/Copilot) | Preferencia humana ciega | Media | Premia lo que "se ve bien", no lo más mantenible |
| Tu propio eval (tickets cerrados) | Tareas reales de tu repo | Máxima | Cuesta montarlo; no compara entre empresas |
Cuándo NO fiarte de un benchmark
Cuando no reporta coste ni latencia junto al éxito. Un benchmark que solo enseña "resolución" es publicidad, no medida — un modelo puede ganar en tasa de éxito y perder si triplica el gasto para llegar ahí. Más sobre esto aquí.
Cuando el dataset lleva más de medio año circulando en abierto. SWE-bench Verified subió de 74,9% a 80,9% en seis meses sin que la capacidad real de los modelos diera ese salto — eso es saturación, no progreso.
Cuando el ranking lo publica el mismo laboratorio que compite en él. Nadie audita sus propios deberes con objetividad — por eso el subset privado de SWE-bench Pro, sobre código que los labs no han visto, vale más que cualquier leaderboard propio.
Cuando el dominio del benchmark no es el tuyo. Terminal-Bench mide shell, compilación y DevOps — no te dice si un modelo escribe buenos componentes de UI o una migración de base de datos limpia. Adapta la pregunta al benchmark, no al revés.
Qué hacer con esto hoy
La próxima vez que un modelo salga con un número enorme en portada, no preguntes cuánto sacó — pregunta en qué dataset, público o privado, y con qué coste llegó ahí. Si no puedes responder las tres, el número no sirve para decidir nada.
Móntate el set de 15-20 tickets esta semana, no cuando salga el siguiente modelo. Es el mismo criterio de escribir la especificación antes de generar código que enseño en Construye con IA, y la plantilla de eval la comparto en Dominicode Labs.
Preguntas frecuentes
¿Qué benchmark debo mirar si solo tengo tiempo para uno?
Ninguno público. Monta tu propio set de 15-20 tickets cerrados de tu repo — toma una tarde y te dice más que cualquier leaderboard general. Si quieres una referencia externa, Terminal-Bench es hoy la más honesta porque exige resolver tareas completas, no un fragmento aislado.
¿Terminal-Bench sirve para evaluar modelos para desarrollo frontend?
No directamente. Terminal-Bench mide tareas de shell, compilación y DevOps — un modelo puede sacar 58% ahí y ser mediocre escribiendo componentes de interfaz. Úsalo como señal de capacidad general para seguir instrucciones en varios pasos, no como predictor de calidad en frontend.
¿SWE-bench Pro ya resolvió el problema de la contaminación?
Solo en su subset privado. La parte pública usa código con licencia GPL precisamente para dificultar que entre en datasets de entrenamiento, pero sigue siendo código técnicamente indexable — no tan hermético como el subset privado, hecho con codebases 100% propietarios que Scale nunca publicó. La caída de hasta ocho puntos que reporta Scale AI al pasar a código privado es la prueba de cuánta capacidad real hay detrás del número público.
¿Cómo monto mi propio eval sin gastar semanas en ello?
Con 15 tickets cerrados es suficiente para empezar. No necesitas infraestructura nueva: conviertes el criterio de aceptación de cada ticket en un test automático, corres el candidato contra esos 15 casos y mides éxito, tiempo y coste. Es el proceso que detallo en el ebook gratuito "Revisión por Contrato".
¿Vale la pena perseguir el ranking cada vez que sale un modelo nuevo?
No. El time-horizon de METR muestra que la capacidad sube de forma predecible — perseguir cada lanzamiento individual es ruido. Lo que vale la pena es correr tu propio set cada vez que cambies de modelo en producción, no cada vez que sale un post nuevo de benchmarks.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.