Las puntuaciones de SWE-bench saltaron del 1,96 % al 72,7 % en menos de dos años, un aumento que los titulares han presentado como un salto de 37 veces en la capacidad de programación de la IA. El titular llama la atención, pero las cifras comparan dos exámenes distintos, no una mejora única y constante en la habilidad de ingeniería de software.
Las cifras brutas
En 2023, el SWE-bench original evaluó a agentes de IA en 2294 problemas reales de GitHub. Las tareas eran un desorden: descripciones vagas, pruebas fallidas y muchos problemas que incluso a un humano le costarían resolver. Para 2025, el mismo nombre de benchmark apareció con una puntuación del 72,7 %, pero la prueba se había reducido a un subconjunto "Verified" de solo 500 tareas que los humanos habían revisado para asegurar su claridad y capacidad de resolución.
Cómo cambió la prueba
El cambio del catálogo completo al conjunto Verified es el primer cambio, y el más visible. La colección original intentaba reflejar la realidad caótica de las contribuciones de código abierto: problemas que están incompletos, mal documentados o que son simplemente imposibles sin contexto adicional. La versión Verified, por el contrario, filtra deliberadamente ese caos. Presenta un conjunto de problemas más limpio y manejable donde las puntuaciones altas son alcanzables de forma realista.
Debido a que las dos versiones miden diferentes segmentos del espacio del problema, una comparación directa de porcentajes induce a error. La cifra del 1,96 % captura el rendimiento en un trabajo bruto y sin filtrar; la cifra del 72,7 % captura el rendimiento en una muestra seleccionada donde las probabilidades de éxito son mucho mayores.
Ingeniería dirigida
Un segundo cambio, más sutil, ocurrió en la forma en que los desarrolladores abordaron el benchmark. En 2023, nadie construía agentes específicamente para triunfar en SWE-bench; la prueba actuaba como una muestra aleatoria de los desafíos de programación del mundo. Para 2025, los equipos convirtieron el benchmark en un marcador. Construyeron estructuras de soporte, estrategias de prompting y ajustaron modelos (fine-tuned) con el objetivo explícito de obtener una buena puntuación en el conjunto Verified.
Cuando los ingenieros diseñan un sistema para pasar una prueba particular, la puntuación refleja qué tan bien se ajusta el sistema a esa prueba, no qué tan capaz es de forma general. El benchmark dejó de ser una muestra representativa del trabajo del mundo real en el momento en que fue "reparado" y se convirtió en un objetivo.
Lo que el salto significa realmente
La mejora que acapara los titulares es real en el sentido de que los agentes de programación actuales se desempeñan drásticamente mejor en las tareas Verified que en el conjunto original. Esa mejora es importante para competiciones, artículos de investigación y demostraciones de productos que dependen del mismo benchmark seleccionado.
Sin embargo, el salto no demuestra que los agentes de IA puedan ahora manejar el desorden del desarrollo de software cotidiano. El conjunto original de 2294 problemas todavía existe, y las puntuaciones en esa versión siguen siendo bajas.
Preguntas a hacerse
Cada vez que vea un cambio masivo en los resultados de un benchmark, tenga en cuenta estas tres comprobaciones:
- ¿Qué versión se está informando? ¿Original, Lite o Verified? Nombres idénticos pueden ocultar conjuntos de tareas muy diferentes.
- ¿Qué se filtró? Eliminar tareas ruidosas o imposibles eleva el techo para cualquier sistema; también elimina los desafíos mismos que importan en producción.
- ¿Se construyó el sistema para pasar esta prueba específica? Si los desarrolladores ajustaron modelos o pipelines para el benchmark, la puntuación mide la optimización, no la capacidad bruta.
Mirando hacia el futuro
Hasta que tales salvaguardas se conviertan en un estándar, la mejor medida de la utilidad de un programador de IA seguirá siendo su rendimiento en los problemas caóticos del mundo real que los desarrolladores enfrentan a diario.
Conclusión: Una puntuación más alta en un benchmark reparado y dirigido no demuestra automáticamente que los agentes de IA estén listos para el caos del código del mundo real; la verdadera prueba siguen siendo los problemas sin filtrar con los que los ingenieros lidian todos los días.
