SWE-bench: qué mide y cómo leer los benchmarks de IA para programar

Si has seguido algún lanzamiento de un modelo o un agente de programación en los últimos dos años, habrás visto una cifra acompañando al anuncio: «X% en SWE-bench Verified». Se ha convertido en la métrica de referencia del sector, la que aparece en las tablas comparativas y la que muchos responsables técnicos usan como atajo para decidir. El problema es que en 2026 esa cifra significa bastante menos de lo que parece. Entender cómo funciona SWE-bench, y sus límites, ahorra decisiones equivocadas.

¿Qué es SWE-bench?

SWE-bench es un benchmark creado en la Universidad de Princeton que evalúa a los modelos con problemas reales de GitHub. A cada sistema se le entrega un repositorio de código y la descripción de una incidencia (un issue), y debe generar un parche que la resuelva. No se trata de escribir una función aislada, sino de navegar un proyecto real, entender el problema y modificar los ficheros adecuados.

La tarea se da por resuelta si, al aplicar el parche, pasan las pruebas que la incidencia exige. Esas pruebas proceden del propio repositorio: las que el arreglo original hizo pasar y las que ya funcionaban y no deben romperse. La evaluación se ejecuta en contenedores Docker desde 2024, lo que permite que cualquiera la reproduzca. El porcentaje que se publica es simplemente la proporción de tareas resueltas.

¿Qué versiones de SWE-bench existen?

• SWE-bench (completo): el conjunto original de problemas extraídos de repositorios Python populares.
• SWE-bench Lite: un subconjunto más barato de ejecutar, pensado para empezar.
• SWE-bench Verified: 500 problemas que ingenieros confirmaron como resolubles. Ha sido durante mucho tiempo la cifra estrella.
• SWE-bench Multimodal: añadido en enero de 2025, con problemas que incluyen elementos visuales.
• SWE-bench Multilingual: problemas en otros lenguajes además de Python.

La web oficial incluye además un filtro «Bash Only» en su clasificación, que compara modelos usando un agente mínimo que solo dispone de la terminal. Es relevante porque aísla mejor la capacidad del modelo de la calidad del agente que lo envuelve.

¿Por qué SWE-bench Verified ya no es fiable?

Por dos razones: tareas defectuosas y contaminación. El 23 de febrero de 2026, OpenAI anunció que dejaba de publicar resultados en Verified. Su auditoría revisó el 27,6% de las tareas (las que sus modelos fallaban repetidamente) y concluyó que el 59,4% tenía pruebas defectuosas que rechazaban soluciones funcionalmente correctas. Por ejemplo, pruebas que exigían nombres de función que el enunciado no mencionaba.

Epoch AI, que analiza benchmarks de forma independiente, publicó el 3 de septiembre una revisión que califica Verified como defectuoso. Sus cálculos sitúan en al menos un 16,4% la proporción de tareas rotas del total, por encima de su umbral de aceptación. Y añade el problema de fondo: tanto las tareas como sus soluciones son públicas, así que hay que asumir que los modelos actuales las han visto durante el entrenamiento. Una mejora en la puntuación puede reflejar memoria más que capacidad.

Epoch recuerda también algo que ya había señalado antes: los resultados dependen mucho del scaffold, es decir, del agente y las herramientas con que se ejecuta el modelo. El mismo modelo puede sacar cifras muy distintas según quién lo evalúe y cómo.

Lee también: Claude Opus 5.5: Anthropic abarata su modelo estrella para programar

¿Qué es SWE-Bench Pro y es mejor?

SWE-Bench Pro, de Scale AI, nació para corregir parte de esos problemas. Tiene 1.865 tareas de 41 repositorios, más largas y variadas, divididas en tres grupos: 731 públicas procedentes de proyectos con licencias copyleft, 276 de 18 bases de código privadas de startups (con clasificación aparte) y 858 que se reservan sin publicar. La idea es dificultar la contaminación y cubrir más lenguajes, como Go, JavaScript y TypeScript.

A principios de octubre de 2026, la clasificación pública muestra en cabeza a Muse Spark 1.1 (61,5%) y GPT-5.4 en modo de esfuerzo máximo (59,1%); más abajo aparecen Claude Opus 4.6 con razonamiento (51,9%) y Gemini 3.1 Pro (46,1%). Fíjate en dos detalles que sirven de lección: cada cifra va acompañada de un intervalo de confianza de entre 3 y 3,6 puntos arriba o abajo, y la página no indica fecha de actualización ni incluye algunos de los modelos más recientes del mercado.

Tampoco Pro está libre de dudas. En julio, OpenAI publicó un análisis en el que estima que alrededor del 30% de sus tareas presenta defectos. Ningún benchmark público de programación es hoy una medida limpia.

¿Cómo leer una cifra de SWE-bench sin que te engañen?

Antes de dar valor a un porcentaje, hazte estas preguntas:

1. ¿Qué variante? Verified, Pro, Lite o Multilingual no son comparables entre sí.
2. ¿Quién lo ha medido? Las cifras del fabricante en su anuncio no equivalen a una evaluación independiente con el mismo arnés para todos.
3. ¿Con qué agente? Un modelo dentro del agente propio del fabricante, con herramientas a medida, no es comparable con otro ejecutado en un agente mínimo.
4. ¿Cuántos intentos? Resolver en el primer intento no es lo mismo que elegir el mejor de varios.
5. ¿Cuál es el margen de error? Con intervalos de ±3 puntos, una diferencia de dos puntos entre modelos es ruido.
6. ¿Cuánto cuesta? Un 2% más de acierto con el triple de coste por tarea rara vez compensa en un equipo pequeño.

Un ejemplo práctico: la ficha de Devstral Small 2 en Ollama recoge un 65,8% en Verified y un 32% en Terminal Bench, otro benchmark que mide tareas en terminal. Son datos útiles para situar el modelo, pero vienen del fabricante y de un benchmark cuestionado, así que sirven para preseleccionar, no para decidir.

¿Puedo ejecutar SWE-bench yo mismo?

Sí. El arnés oficial es de código abierto y funciona con Docker. Tras clonar el repositorio e instalarlo, se evalúa un fichero de predicciones (un JSONL con el identificador de cada tarea y el parche generado) así:

python -m swebench.harness.run_evaluation \
    --dataset_name princeton-nlp/SWE-bench_Lite \
    --predictions_path predicciones.jsonl \
    --max_workers 8 \
    --run_id prueba_equipo

El resultado incluye el número de tareas resueltas y registros por tarea. Necesita bastante disco; la documentación sugiere reducir --max_workers o usar --cache_level=base si te quedas corto.

La alternativa que sí sirve: tu propio benchmark

Para una agencia o una pyme, la evaluación más fiable es la que se hace con su propio código. Una receta sencilla:

• Elige entre 20 y 30 incidencias ya cerradas de tus repositorios, con su commit de solución y, si es posible, pruebas asociadas.
• Vuelve al commit anterior al arreglo y pide a cada herramienta o modelo que lo resuelva con el mismo enunciado.
• Mide si pasan las pruebas, cuánto tarda, cuánto cuesta y cuántas intervenciones humanas necesita.
• Repite cada trimestre: los modelos cambian cada pocas semanas.

Esta idea, construir tareas a partir de cambios recientes de tus propios repositorios, es también la dirección que siguen varias investigaciones publicadas este verano para esquivar la contaminación. No es tan vistoso como un titular con un 70%, pero responde a la única pregunta que importa: qué herramienta resuelve mejor los problemas de tu equipo.