¿Qué miden SWE-bench y los benchmarks de programación?

¿Qué es SWE-bench y cómo se puntúa?

Un benchmark de programación es una lista fija de tareas más una regla de puntuación. El modelo o el agente de programación resuelve las tareas, la regla marca cada solución como superada o no, y la puntuación es el porcentaje de las que la superan. Este artículo empieza por el benchmark del que más se habla, SWE-bench, y después lee los demás con las mismas cuatro preguntas. La estructura que rodea al modelo (el harness) la explicamos en el artículo sobre harness engineering, y las evaluaciones que puntúa un modelo juez, en el artículo sobre LLM-as-a-judge.

SWE-bench es un benchmark construido con issues reales de GitHub. Según su página, la primera versión salió en octubre de 2023 y tiene 2.294 tareas sacadas de issues y pull requests de 12 repositorios populares de Python. Cada tarea sale de un pull request que cerró un issue y que además cambió archivos de test.

La puntuación funciona así: el modelo recibe el texto del issue y el repositorio tal como estaba antes del pull request, y cambia el código. Cuando el modelo termina, se ejecutan dos grupos de tests:

• FAIL_TO_PASS: tests que fallaban antes del pull request y pasan después. Demuestran que el issue está resuelto de verdad.
• PASS_TO_PASS: tests que tienen que pasar antes y después. Demuestran que el cambio no rompió nada que ya funcionaba.

Si pasan los dos grupos, la tarea cuenta como resuelta. La puntuación es el porcentaje de tareas resueltas; en las clasificaciones aparece como «% Resolved».

Hoy SWE-bench no es un solo conjunto, sino una familia. Las cifras de la tabla las leímos el 20 de octubre de 2026 en la página de cada conjunto:

Fuente: la página de SWE-bench, el anuncio de Multilingual y la página de SWE-bench Pro de Scale AI, 20 de octubre de 2026. Los resultados del conjunto privado de Pro se publican en una clasificación aparte.

Al leer la clasificación importa un detalle más. La página de Verified dice que la clasificación pone todo tipo de sistemas de programación en la misma lista, desde bucles de agente sencillos hasta sistemas que hacen varios intentos. Para comparar modelos entre sí hay una vista aparte, «Bash Only»: allí cada modelo trabaja con el mismo agente pequeño (mini-SWE-agent) y solo con un shell de bash.

¿Por qué SWE-bench Verified ya no basta?

Verified salió con OpenAI en agosto de 2024. Según Epoch AI, sus 500 tareas se eligieron entre las 2.294 del conjunto original mediante la revisión independiente de tres expertos, para descartar las tareas con problemas.

El 3 de septiembre, Epoch volvió a revisar Verified y lo calificó de «defectuoso» (Flawed). Da tres razones:

• Los tests rechazan soluciones correctas. En una auditoría que publicó el 23 de febrero de 2026, OpenAI miró las tareas que los modelos solían no resolver. Revisó el 27,6 % de las tareas y encontró que en el 59,4 % de ellas el test rechazaba una solución que funcionaba bien. Según Epoch, eso significa que al menos el 16,4 % de todas las tareas está roto. El listón de Epoch es que menos del 20 % de las preguntas tenga un defecto así.
• Las tareas se han filtrado a los datos de entrenamiento. Verified es un conjunto fijo; todas sus tareas y todas sus soluciones son públicas. Según la auditoría de OpenAI, todos los modelos punteros que probó habían visto en el entrenamiento al menos una parte de estos problemas y de sus soluciones. La conclusión de OpenAI: el progreso en Verified ya no muestra una habilidad real de desarrollo de software, sino cuánto de este benchmark vio el modelo en el entrenamiento.
• La puntuación se puede trucar. El equipo RDI de Berkeley encontró un reward hack que consigue la puntuación máxima.

Los fabricantes de modelos actuaron en consecuencia. Según el artículo de Cursor, OpenAI dejó por completo de publicar resultados en Verified al ver que los modelos punteros podían reproducir de memoria las soluciones de referencia. La ficha de sistema de Opus 5 de Anthropic, del 24 de julio, todavía publicaba Verified: 96,0 %, la media de cinco intentos. En la ficha de Opus 5.5, del 22 de septiembre, Verified ya no está; solo aparecen Pro, Multilingual y Multimodal. En el anuncio de ese mismo modelo, Anthropic escribe además que, a este nivel de capacidad, las diferencias en los benchmarks indican con menos fiabilidad las diferencias en el uso real.

Un benchmark en el que todos rozan el techo ya no puede distinguir entre modelos. Quienes construyen benchmarks también lo ven. Aider sustituyó su antiguo benchmark de edición por un conjunto más difícil cuando las puntuaciones pasaron del 80 %. Terminal-Bench 4.0 consideró «saturadas» las tareas que todos los modelos más nuevos resolvían en 5 de 5 intentos y las sacó del conjunto. La página de DeepSWE también dice que los modelos de cabeza se apiñan en una franja estrecha de puntuaciones y que los intervalos de confianza de configuraciones vecinas a menudo se solapan.

Esa misma semana, Epoch dio el mismo veredicto sobre otros dos benchmarks de programación. Califica un benchmark de «defectuoso» cuando los defectos pueden afectar al 20 % de la puntuación o más:

Fuente: las revisiones de Epoch AI. En Verified, Epoch se basa en la auditoría de OpenAI. Las tareas de Terminal-Bench vienen de la comunidad; Epoch contó los problemas notificados públicamente en su repositorio. En BFCL tomó una muestra al azar de 5.088 elementos.

Así se ve un defecto, con un ejemplo de BFCL. En la tarea «What is the current time in Sydney, Australia?», el modelo recibe una función llamada get_local_time(location). La clave de respuestas marca la tarea como «irrelevante». Solo saca la puntuación máxima un modelo que no llama a ninguna función; un modelo que llama bien a la función saca cero.

¿Qué miden los demás benchmarks de programación?

SWE-bench mira un único tipo de trabajo: un patch que cierra un issue en un repositorio. Lo que se espera de un agente de programación es más amplio, así que cada benchmark mide una parte distinta. Los datos de la tabla los leímos el 20 de octubre de 2026 en la página de cada benchmark:

Fuente: la página o el anuncio de cada benchmark, 20 de octubre de 2026. «Su página no lo dice»: en la página que leímos ese día no encontramos ninguna frase que lo diga. Las valoraciones de Cognition y de Cursor salen de los artículos en los que presentan sus propios benchmarks.

Tampoco todas las clasificaciones están igual de al día. La clasificación de Aider se actualizó por última vez el 20 de noviembre de 2025, la de BFCL el 12 de abril de 2026. La versión más reciente del repositorio de LiveCodeBench (release_v6) abarca 1.055 problemas publicados entre mayo de 2023 y abril de 2025. Si un modelo no aparece en una clasificación así, puede ser que la clasificación sea antigua, no que el modelo sea malo.

El nombre más antiguo que no está en la lista es HumanEval: un conjunto que OpenAI publicó en 2021 y que pide a los modelos escribir código a partir de un docstring. Su repositorio está marcado hoy como «Deprecated and unmaintained». El equipo de LiveCodeBench también encontró que algunos modelos a los que les va bien en HumanEval podrían estar sobreajustados a ese conjunto.

Las herramientas de revisión de código también tienen benchmarks. GitHub publicó ReviewBench el 5 de octubre; allí un modelo juez decide si un comentario es un hallazgo correcto, y GitHub publicó también el prompt del juez. Cómo leer un benchmark que puntúa un modelo juez lo explicamos en el artículo sobre LLM-as-a-judge.

¿El código que pasa los tests llega al merge?

La puntuación de SWE-bench sale de un evaluador automático: si los tests pasan, la tarea cuenta como resuelta. En un estudio publicado el 10 de marzo de 2026, METR midió hasta qué punto esa cifra coincide con la revisión de un mantenedor de verdad. 4 mantenedores activos de 3 repositorios de Verified (scikit-learn, Sphinx, pytest) leyeron en total 296 PR escritos por IA como en una revisión real y decidieron si harían merge de cada uno. No sabían quién había escrito el PR.

El resultado: los mantenedores no habrían hecho merge de cerca de la mitad de los PR que pasaban los tests. Como la decisión de un mantenedor puede variar de una persona a otra, METR también hizo que los mismos mantenedores leyeran PR humanos que sí habían llegado al merge en el repositorio; aprobaron cerca del 68 % de ellos. Con las puntuaciones escaladas a esa base, el evaluador automático queda de media 24,2 puntos por encima de la decisión de los mantenedores. Sin escalar, la diferencia es de 34,9 puntos.

Los mantenedores rechazaron por tres tipos de motivos: el cambio no resuelve de verdad el problema, toca código ajeno y lo rompe, o el código no cumple el estándar del repositorio. METR también expone sus límites con claridad: los agentes no tuvieron ocasión de corregir su trabajo a partir de comentarios, y el estudio miró una parte de un solo benchmark y un solo agente. Así que el resultado no dice que los modelos no puedan hacerlo. Lo que dice es esto: leída sola, una puntuación hace que un agente parezca más útil de lo que es.

FrontierCode es un benchmark que mete estas preguntas en la puntuación. Cognition preparó 150 tareas con los mantenedores de 36 repositorios de código abierto; en cada repositorio, los mantenedores fijaron los criterios para que un cambio se considere listo para merge. Además de los tests unitarios hay un control del alcance: ¿el cambio toca solo los archivos permitidos?, ¿el diff supera un tamaño determinado? Los tests que escribe el agente también se ejecutan sobre el código antiguo, el que está roto; un test que ahí no falla no comprueba nada.

El propio informe de Anthropic muestra el efecto de la penalización por alcance. Según la ficha de sistema de Opus 5, en niveles de effort por encima de high el modelo hizo más cambios de los que pedía la tarea, y su puntuación en FrontierCode bajó. Al añadir al prompt una instrucción breve que le pedía no salirse del alcance de la tarea, la puntuación se recuperó en la mayoría de esas tareas. Es un resultado que el fabricante publica para Opus 5; la ficha no dice cuántos puntos se recuperaron.

Justo en esa brecha trabaja la revisión de código: el test demuestra que el cambio da el comportamiento pedido; la revisión pregunta si ese cambio tiene su sitio ahí. En diffox hacen esa pregunta agentes especializados. Uno compara las líneas cambiadas, regla por regla, con las reglas del archivo de reglas del repositorio (AGENTS.md, CLAUDE.md); una regla que no está escrita en el archivo no cuenta. Otro busca un test que no comprueba lo que dice su nombre, o una aserción que nunca puede fallar; un test que falta, en cambio, no es un hallazgo para él. Cómo saber si un test comprueba de verdad algo lo explicamos en el artículo sobre cómo revisar código generado por IA.

¿Cómo se lee la puntuación de un benchmark?

Cuando te encuentres con una puntuación, hazte estas seis preguntas. Si dos puntuaciones difieren en una sola de ellas, ya no miden lo mismo:

1. ¿Qué conjunto o subconjunto? «SWE-bench» a secas no dice nada: Verified, el conjunto público de Pro y un subconjunto que eligió una empresa son cifras distintas. La documentación de Anthropic dice que las puntuaciones en el subconjunto de 482 problemas que eligió de Pro no se pueden comparar con la clasificación pública. Tampoco se pueden comparar con los resultados de Pro de la ficha de sistema de la misma empresa, porque estos se midieron en otro conjunto de problemas y con max effort.
2. ¿Dentro de qué agente? Una puntuación no es del modelo, sino de la pareja que forman el modelo y el agente que lo ejecuta. Según Epoch, los resultados en Verified dependen mucho del agente usado; en la clasificación de Terminal-Bench, cada fila es un modelo y un agente. Incluso en el mismo benchmark puede cambiar la configuración: Epoch señaló que en Terminal-Bench las entradas de Codex reintentan las negativas por seguridad, mientras que la configuración por defecto no lo hace. Artificial Analysis también escribe que sus resultados corresponden a configuraciones concretas y no a nombres de producto, y que el modelo, los ajustes y la forma de ejecutarlo pueden cambiar mucho el resultado. Epoch cuenta además una mala gestión del contexto por parte del agente como un problema de montaje que baja la puntuación; qué hacen los agentes de programación cuando se llena el contexto lo explicamos en el artículo sobre el auto-compact.
3. ¿En qué nivel de effort? Las clasificaciones suelen mostrar un modelo en el nivel en el que mejor rinde. Los resultados del anuncio de Opus 5.5 de Anthropic se midieron con max effort salvo que se indique otra cosa; la fila de Terminal-Bench está en el nivel que dio a cada modelo su mejor puntuación. FrontierCode también ejecuta cada modelo 5 veces en cada nivel de effort y publica el mejor nivel. Si usas la herramienta en su nivel por defecto, puede que no veas el resultado de la tabla.
4. ¿Cuántas ejecuciones y cuánta incertidumbre? La misma configuración puede dar puntuaciones distintas en dos ejecuciones. La clasificación de Terminal-Bench muestra la media de 5 ejecuciones con un intervalo de confianza del 95 %; Epoch recomienda al menos 5 ejecuciones por modelo para las barras de error. Una diferencia que no supera el ruido no es una diferencia; el ruido entre dos ejecuciones en nuestras propias mediciones lo explicamos en el artículo sobre LLM-as-a-judge.
5. ¿Quién midió? La tabla de un fabricante de modelos se mide en las condiciones que él eligió. Las mediciones independientes intentan ejecutar cada modelo con las mismas reglas: DeepSWE ejecuta todos los modelos con el mismo agente pequeño. En los dos casos, mira los detalles: Artificial Analysis deja que otro modelo termine cuando un modelo se niega a hacer una tarea, y también cuenta ese intento; Anthropic, por su parte, escribe que cuando intervinieron sus salvaguardas de seguridad, otros modelos completaron parte de las tareas de Opus 5.5.
6. ¿El conjunto está saturado, filtrado o al día? Un conjunto en el que todos rozan el techo no distingue entre modelos; un conjunto con las tareas y las soluciones a la vista puede estar midiendo también la memoria. Mira la fecha de publicación de las tareas (LiveCodeBench la guarda para cada problema), pregunta si el conjunto tiene una parte cerrada y comprueba cuándo se actualizó la clasificación por última vez.

En el documento de Anthropic sobre coste e inteligencia hay un ejemplo que muestra el efecto del effort en el mismo modelo y las mismas tareas. Lo único que cambia es el nivel de effort:

En el mismo modelo, cambiando solo el effort, la puntuación se mueve 9,3 puntos, y el coste por tarea sube de $0,11 a $0,74. En una tabla que compara dos modelos, mira primero en qué nivel se midió cada uno: si uno se midió en max y el otro en su nivel por defecto, la diferencia puede venir del ajuste y no del modelo.

¿Qué benchmark mirar para cada trabajo?

Elegir un benchmark es elegir qué quieres del agente. La tabla de abajo empareja trabajos habituales con el benchmark que más se les acerca:

Fuente: las tablas de este artículo y la página de cada benchmark, 20 de octubre de 2026.

Ninguno sustituye al trabajo en tu propio repositorio. La documentación de Anthropic también recomienda probar el ajuste de effort con tu propia carga de trabajo. La medición más fiable es ejecutar varias veces unas cuantas tareas reales de tu propio repositorio, con el mismo agente y en el mismo nivel de effort.

Ninguno mide tampoco si se debería hacer merge de un cambio. FrontierCode es el que más se acerca, pero también allí deciden unos criterios que los mantenedores escribieron de antemano. En tu repositorio, esa decisión la toma la revisión.

Preguntas frecuentes

¿Qué es SWE-bench?

SWE-bench es un benchmark que mide si los modelos de IA y los agentes de programación son capaces de resolver issues reales de GitHub. El modelo recibe el texto del issue y el repositorio tal como estaba en ese momento, y cambia el código. Si el cambio pasa los tests FAIL_TO_PASS, que demuestran que el issue está resuelto, y los tests PASS_TO_PASS, que demuestran que no se rompió nada, la tarea cuenta como resuelta. La primera versión tiene 2.294 tareas de 12 repositorios de Python; tiene subconjuntos y conjuntos hermanos como Verified, Pro y Multilingual.

¿Qué diferencia hay entre SWE-bench Verified y SWE-bench Pro?

Verified es un subconjunto de 500 tareas del conjunto original revisado por personas; sus tareas y sus soluciones son públicas. Pro es el conjunto más difícil de Scale AI, con 1.865 tareas de 41 repositorios: las soluciones tienen de media 107,4 líneas y 4,1 archivos. Las tareas de Pro salen de repositorios con licencia copyleft y de código cerrado de empresas, y los resultados de una parte nunca se publican. Epoch AI calificó Verified de defectuoso en septiembre de 2026; la última ficha de modelo de Anthropic también publica Pro en lugar de Verified.

¿Qué porcentaje en SWE-bench se considera bueno?

No hay un umbral único. Una puntuación depende del conjunto, del agente y del nivel de effort a los que pertenece: en el subconjunto propio de Anthropic, el mismo modelo se mueve 9,3 puntos solo con el nivel de effort, y Anthropic escribe que esas puntuaciones no se pueden comparar con la clasificación pública. Compara dos puntuaciones solo si se midieron en el mismo conjunto, con el mismo agente y con ajustes parecidos; no mires una cifra aislada, sino su distancia con otros modelos medidos en las mismas condiciones.

¿Qué mide Terminal-Bench?

Terminal-Bench mide si un agente puede completar tareas de principio a fin en la terminal: tareas de software, ciencia, ML, operaciones, seguridad, hardware y multimedia. Cada tarea tiene su propio verificador. Con la versión 4.0 pasó a ser un benchmark que se actualiza de forma continua; saca del conjunto las tareas saturadas, las tareas rechazadas y las tareas cuya solución se ha hecho pública. La clasificación muestra, para cada pareja de modelo y agente, la media de 5 ejecuciones con un intervalo de confianza del 95 %. El 4 de septiembre, Epoch AI registró un fallo de puntuación señalado públicamente en 30 de las 66 tareas.

¿Qué diferencia hay entre LiveCodeBench y SWE-bench?

LiveCodeBench usa problemas sacados de concursos de LeetCode, AtCoder y Codeforces para ver la capacidad de un modelo de escribir código, reparar su propio código, ejecutar código y predecir la salida de un test; una tarea es un solo problema. SWE-bench, en cambio, pide un cambio que cierre un issue real en un repositorio. Como LiveCodeBench marca cada problema con su fecha de publicación, puedes medir un modelo con problemas publicados después de su fecha de corte de entrenamiento; así el modelo no puede haber visto la solución en el entrenamiento.

¿Hasta qué punto es fiable la puntuación de un benchmark?

Una puntuación responde a la pregunta estrecha que hace el benchmark. Antes de fiarte, comprueba seis cosas: qué conjunto, qué agente, qué nivel de effort, cuántas ejecuciones y qué intervalo de confianza, quién midió y si el conjunto está saturado o filtrado. Por eso importan las auditorías independientes: en septiembre de 2026, Epoch AI calificó de defectuosos SWE-bench Verified, Terminal-Bench 4.0 y BFCL v4; METR midió que cerca de la mitad de los PR de SWE-bench que pasan los tests no superarían la revisión de los mantenedores.

¿Con qué benchmark se mide diffox?

diffox es una herramienta de revisión de código con IA; por eso no se mide con benchmarks de programación, sino con benchmarks de revisión de código. Ejecutamos nosotros mismos el benchmark de código abierto de revisión de código de Martian y publicamos el resultado con su evidencia: cada revisión es un pull request público, la puntuación la hizo el propio código del benchmark y puedes reconstruir la tabla en tu propia máquina con los comandos del repositorio de evidencia. Ese artículo dice también de cuántas ejecuciones sale cada fila: la ejecución pública la hicimos con el ajuste de sensibilidad Alta de entonces, y las filas Media y Baja son la media de varias ejecuciones internas.