Escritura

Ficha de validez: SWE-bench Verified

Para qué sirve esta ficha. Cada vez que un laboratorio anuncia que su modelo obtiene 78% en SWE-bench Verified, el número se reporta, se compara y se presume como si viniera de una prueba estandarizada, y hasta cierto punto lo es, pues tiene reactivos, una regla de calificación y un puntaje total. Lo que casi nunca trae consigo es aquello que a cualquier prueba estandarizada le exigiríamos, un argumento de validez. En esta ficha intento armar ese argumento con las herramientas de siempre de la psicometría, los Standards for Educational and Psychological Testing (AERA, APA y NCME, 2014) y el enfoque argumentativo de Kane (2006, 2013), quien, como nos lo dice desde hace décadas, insiste en que lo que se valida son las interpretaciones y los usos que hacemos de los puntajes. Por eso, más que preguntarme si el benchmark es válido, me pregunto qué interpretaciones y qué usos de su puntaje respalda la evidencia, y cuáles no.

1. Ficha técnica

Campo	Descripción
Instrumento	SWE-bench Verified: subconjunto de 500 reactivos del conjunto de prueba de SWE-bench (2,294 tareas).
Creadores	SWE-bench: Jimenez, Yang, Wettig, Yao, Pei, Press y Narasimhan (Princeton; ICLR 2024). Verified: equipo de Preparedness de OpenAI en colaboración con los autores de SWE-bench (13 de agosto de 2024).
Construcción de Verified	93 desarrolladores con experiencia en Python anotaron 1,699 tareas muestreadas al azar del conjunto de prueba. Cada tarea la etiquetaron tres anotadores, en escalas de 0 a 3, según si el issue estaba subespecificado, si las pruebas rechazaban soluciones válidas y si había otros problemas graves. Se descartaron las tareas con etiqueta grave y del remanente se tomaron 500 (OpenAI, 2024).1
Reactivos	500 reactivos de 12 repositorios de Python de código abierto, con issues creados entre 2013 y 2023. Cada reactivo es una tarea: un issue real con sus pruebas.
Formato de respuesta	Respuesta construida de desempeño. El sistema recibe el texto de un issue de GitHub y el repositorio en el commit base, y debe producir un parche (diff). Hoy es casi siempre un agente que explora, ejecuta y edita el código en un contenedor.
Puntuación del reactivo	Dicotómica. El reactivo cuenta como resuelto si, tras aplicar el parche, pasan todas las pruebas FAIL_TO_PASS (fallaban antes del parche de referencia y pasan después) y todas las PASS_TO_PASS (pruebas de regresión). Se ejecuta en Docker desde junio de 2024.
Puntaje del test	Porcentaje de reactivos resueltos (“% resolved”), con denominador de 500.
Quién reporta	(a) Los laboratorios, autorreportando en anuncios y system cards con su propio andamiaje (scaffold), presupuesto de cómputo y a veces varios intentos. (b) El leaderboard oficial (swebench.com), alimentado por envíos al repositorio SWE-bench/experiments; desde el 18 de noviembre de 2025, en Verified y en Multilingual, solo acepta envíos de equipos académicos o de instituciones de investigación con métodos abiertos y una publicación (preprint o informe técnico). (c) El leaderboard “bash-only”, que usa un andamiaje mínimo común (mini-SWE-agent). (d) Terceros como Epoch AI, que evalúa sobre 484 reactivos tras excluir 16 que no corren de forma fiable en su infraestructura (Epoch AI, s. f.).
Licencia	El código del harness es MIT. La licencia declarada del dataset en Hugging Face no pudo verificarse desde este entorno. Los reactivos incluyen texto de issues y parches derivados de repositorios con licencias propias, en su mayoría permisivas (ver nota en §8).
Estado (oct. 2026)	OpenAI dejó de reportarlo en febrero de 2026 por saturación, contaminación y pruebas defectuosas (OpenAI, 2026a). Los mantenedores lo siguen manteniendo: corrigieron fugas del historial de git en 2025 y 2026 y una vulnerabilidad de calificación en agosto de 2026, cuya corrección todavía puede burlarse según un reporte de septiembre.

Composición del contenido

La tabla se calculó con los metadatos de los 500 reactivos en el repositorio público SWE-bench/swe-bench-tasks (commit 3d07b464, agosto de 2026). Las etiquetas de dificultad son las estimaciones de tiempo de resolución que anotó OpenAI.

Dimensión	Distribución
Repositorio	django 231 (46.2%) · sympy 75 (15.0%) · sphinx 44 (8.8%) · matplotlib 34 (6.8%) · scikit-learn 32 (6.4%) · xarray 22 (4.4%) · astropy 22 (4.4%) · pytest 19 (3.8%) · pylint 10 (2.0%) · requests 8 (1.6%) · seaborn 2 (0.4%) · flask 1 (0.2%)
Lenguaje	Python 100%
Año del issue	78.8% entre 2019 y 2022; el más reciente es de 2023
Dificultad anotada	< 15 min: 194 (38.8%) · 15 min–1 h: 261 (52.2%) · 1–4 h: 42 (8.4%) · > 4 h: 3 (0.6%)
Tamaño del parche de referencia	85.8% modifica un solo archivo; mediana ≈ 6 líneas añadidas o eliminadas (conteo propio, aproximado)
Pruebas FAIL_TO_PASS por reactivo	Mediana = 1; en 345 reactivos (69%) la resolución depende de una sola prueba

2. Interpretación y uso propuestos

Lo que se afirma

Los creadores de SWE-bench proponen una interpretación acotada: el puntaje mide la capacidad de “resolver issues reales de GitHub” en repositorios de Python, con la resolución operacionalizada por pruebas. Verified añade una afirmación de calidad de los reactivos: los 500 reactivos serían resolubles y estarían calificados con justicia.

En la práctica circula una interpretación mucho más amplia. Cuando un laboratorio anuncia que “el modelo X resuelve el 80% de SWE-bench Verified”, el enunciado se lee como “X es (casi) un ingeniero de software competente” o “X es el mejor modelo para programar”. Los usos reales del puntaje son:

1. Marketing y posicionamiento: comparaciones entre laboratorios en lanzamientos y system cards.
2. Ordenamientos en leaderboards públicos y agregadores.
3. Selección de modelos por empresas y desarrolladores (“¿qué modelo integro en mi herramienta?”).
4. Seguimiento de capacidades en marcos de seguridad y en análisis de tendencias, donde el puntaje se usa como indicador de autonomía en ingeniería de software.

Según el Estándar 1.3, cuando una interpretación común no ha sido evaluada o contradice la evidencia, eso debe decirse explícitamente y advertirse a los usuarios. Buena parte de esta ficha se ocupa de esa brecha.

La cadena inferencial (Kane)

Inferencia	Paso	Supuestos que requiere
Puntuación (scoring)	Del desempeño observado (parche + ejecución) a la calificación 0/1 por reactivo	Las pruebas separan parches correctos de incorrectos (sin falsos positivos ni falsos negativos sistemáticos). El entorno es reproducible. El sistema no puede obtener la respuesta por vías ajenas a la tarea (historial de git, internet, manipulación del calificador).
Generalización	Del puntaje en estos 500 reactivos, con esta configuración, al puntaje esperado en el universo de tareas y condiciones equivalentes	Los 500 reactivos son una muestra representativa del universo definido. El error de muestreo de reactivos y la variabilidad entre corridas son pequeños frente a las diferencias que se interpretan. La configuración (andamiaje, intentos, presupuesto) está especificada y es constante.
Extrapolación	Del universo de tareas tipo SWE-bench al dominio objetivo: “ingeniería de software real”	El universo de tareas cubre lo esencial del dominio (sin subrepresentación del constructo). El desempeño no depende de factores que no operan en el dominio, como memorización de repositorios públicos o pruebas visibles. El puntaje se relaciona con criterios externos (otras tareas, aceptación por mantenedores, productividad).
Decisión / uso	Del nivel estimado a decisiones: “X es mejor que Y”, “X está listo para trabajo autónomo”, “invertir en X”	Las diferencias entre sistemas superan la incertidumbre de medición. El orden se mantiene bajo condiciones de uso realistas. Las consecuencias del uso (optimización contra el benchmark) no degradan el significado del puntaje.

3. Evidencias por fuente (Standards, cap. 1)

3.1 Contenido

A favor. Los reactivos no son ejercicios sintéticos: provienen de issues reales y de los pull requests que los resolvieron, en bases de código grandes y maduras. Eso le da a SWE-bench una autenticidad que los benchmarks de funciones aisladas (tipo HumanEval) no tienen (Jimenez et al., 2024). La revisión humana de Verified atacó dos defectos de contenido del conjunto original: enunciados subespecificados y pruebas que exigían detalles ajenos al issue (OpenAI, 2024).

Limitaciones del muestreo.

• Concentración en un repositorio. Casi la mitad de los reactivos (46.2%) son de django y 61% salen de solo dos repositorios (django y sympy). Si se piensa en testlets, el test es en gran parte una prueba de “conocer django”.
• Un solo lenguaje y un solo tipo de ecosistema. Todo es Python y todo son bibliotecas o frameworks científicos y web de código abierto, muy populares y muy presentes en datos de entrenamiento. No hay front-end, sistemas, móviles, código propietario ni monorepos industriales.
• Tareas pequeñas. 91% de los reactivos tienen una dificultad anotada menor a una hora. El 85.8% de los parches de referencia toca un solo archivo, con una mediana de unas 6 líneas modificadas. El constructo efectivo es “localizar y corregir un defecto acotado”, no “desarrollar software”.
• Selección por testabilidad. Un reactivo solo entra si existe una prueba que falla antes y pasa después del parche de referencia (Jimenez et al., 2024). Quedan fuera de construcción el diseño, la refactorización sin cambio de comportamiento observable, la documentación, el rendimiento y cualquier trabajo cuyo éxito no se reduzca a una prueba unitaria.
• Filtro de Verified. Al eliminar tareas ambiguas o mal probadas se mejora la calidad, pero también se desplaza el universo hacia tareas limpias, bien especificadas y verificables. Esas no son las condiciones típicas del trabajo real, donde aclarar el requerimiento es parte de la tarea.

3.2 Procesos de respuesta

Esta es la fuente donde el argumento es más frágil. Interpretar el puntaje como capacidad de resolución supone que el sistema llega a la respuesta razonando sobre el código y el issue. Hay al menos cinco rutas alternativas documentadas:

1. Solución filtrada en el enunciado. En el SWE-bench original, Aleithan et al. (2024) encontraron que el 32.67% de los parches exitosos de SWE-Agent + GPT-4 correspondían a casos donde la solución ya venía en el issue o en sus comentarios (“solution leakage”). La cifra corresponde al conjunto completo y a un solo par agente-modelo, aunque los autores señalan que los mismos problemas existen en Lite y en Verified. Aun así, la anotación de Verified no filtraba explícitamente este caso: un issue que contiene la solución está, por definición, bien especificado.
2. Fuga por el historial de git. En septiembre de 2025 se documentó que las imágenes de evaluación conservaban commits, ramas y etiquetas posteriores al commit base. Algunos agentes ejecutaban git log --all o git log --grep y encontraban el parche de referencia (issue #465 del repositorio SWE-bench). Los mantenedores estimaron que el fenómeno afectaba a pocas trayectorias (unas 5 de 10,000 en una búsqueda preliminar). Para un envío concreto estimaron un impacto de 1.2 puntos porcentuales. La corrección se publicó en septiembre de 2025 (PR #471), pero el registro de cambios de swe-bench-tasks indica que la poda de etiquetas futuras no funcionaba del todo y se reforzó el 13 de agosto de 2026. Los puntajes anteriores a esas fechas se obtuvieron, por tanto, en condiciones de aplicación distintas.
3. Memorización y contaminación. Liang et al. (2026) mostraron que modelos de frontera identifican el archivo con el defecto solo a partir del texto del issue, sin ver el repositorio, con hasta 76% de exactitud en SWE-bench Verified. En repositorios fuera de SWE-bench esa cifra baja a 53%, y la coincidencia literal al reproducir funciones es mayor en SWE-bench que en otros benchmarks. En su auditoría de 2026, OpenAI reportó que todos los modelos de frontera que probó (GPT-5.2, Claude Opus 4.5 y Gemini 3 Flash Preview) podían reproducir, en algunos reactivos, el parche original o detalles textuales del enunciado (OpenAI, 2026a). Los reactivos son de 2013–2023 y de repositorios públicos muy populares, así que la exposición previa es casi segura.
4. Manipulación del calificador. Antes de la versión 5.0.0 del harness (17 de agosto de 2026), la calificación leía la salida estándar de las pruebas línea por línea y no verificaba el código de salida. Un parche podía, en principio, imprimir líneas PASSED falsas y ser calificado como resuelto; la 5.0.0 lo corrigió (PR #620). En septiembre de 2026 se reportó que la protección nueva todavía puede burlarse con un marcador falso de código de salida (issue #667, abierto al cierre de esta ficha). No hay evidencia de que esto ocurriera en envíos reales, pero muestra que la regla de puntuación suponía un examinado cooperativo.
5. Dependencia del andamiaje y del presupuesto. El “examinado” no es un modelo sino un sistema. En el repositorio oficial de envíos, el mismo modelo (Claude Sonnet 4, versión de mayo de 2025), con un solo intento, obtiene entre 57.0% y 74.8% según el andamiaje: mini-SWE-agent 64.8%, SWE-agent 66.6%, OpenHands 70.4% y otros sistemas comerciales hasta 74.8%. Muchos envíos declaran “2+” intentos con selección del mejor parche. Incluso con el andamiaje mínimo común, el puntaje del mismo modelo cambia con la versión del andamiaje y con el nivel de razonamiento configurado: GPT-5 mini obtiene 59.8% con mini-SWE-agent v1.7 y 56.2% con v2.0; GPT-5.2, con la misma versión del andamiaje (v1.17.2), 69.0% con el razonamiento por defecto y 71.8% en modo “high” (cálculos propios a partir de SWE-bench/experiments, commit 40f164d).

3.3 Estructura interna

Los análisis de estructura interna de benchmarks de IA son raros, porque los laboratorios reportan un porcentaje y no la matriz de respuestas. SWE-bench es una excepción afortunada: el repositorio SWE-bench/experiments publica, para cada envío, qué reactivos resolvió. Eso permite tratar los datos como una matriz sistemas × reactivos y aplicarle teoría clásica de los tests y TRI. En la entrada compañera, Análisis TRI de SWE-bench Verified, se estima este tipo de evidencia:

• Dificultad de cada reactivo (proporción de sistemas que lo resuelven; parámetro b) y su relación con el repositorio.
• Discriminación (correlación punto-biserial; parámetro a). Los reactivos con discriminación nula o negativa son candidatos a reactivos defectuosos, por ejemplo con pruebas que rechazan soluciones correctas.
• Reactivos que nadie resuelve y reactivos que todos resuelven. No aportan información para ordenar sistemas. Su proporción indica cuánto del test sigue siendo útil en la frontera.
• Función de información del test, que muestra en qué rango de habilidad el test mide con precisión y si conserva información donde hoy están los mejores sistemas.
• Dimensionalidad y dependencia local, por ejemplo si los reactivos de django se comportan como un testlet o un factor específico.

Hay una advertencia previa a cualquier resultado. Los “examinados” no son una muestra aleatoria de una población: son sistemas de 2024–2026, muchos con el mismo modelo base, y la calibración depende de esa población.

Resultados. Con 173 envíos y los 500 reactivos (SWE-bench/experiments, commit 40f164d):

• Unidimensionalidad aproximada. En la matriz tetracórica, el primer autovalor es 5 veces el segundo (λ1/λ2 = 5.07). El segundo componente es un artefacto de herradura, no un factor sustantivo, y no hay dependencia local apreciable por repositorio (Q3 medio ≈ 0). Sumar los reactivos para obtener un puntaje total es defendible para esta población de sistemas.
• Consistencia interna alta pero engañosa. KR-20 = .994. Ese valor se explica sobre todo por la heterogeneidad de los examinados (del 0% al 79% de resolución), no por la precisión en la frontera.
• Pérdida de información en la frontera. La función de información de Rasch alcanza su máximo en θ ≈ −0.8. En el mejor sistema queda en 49% de ese máximo, y el 91% de los envíos desde 2025 está por encima del punto de máxima información. Entre los 20 mejores sistemas, solo 210 de los 500 reactivos (42%) varían: 254 los resuelven todos y 36 ninguno.
• Reactivos que no discriminan. 26 reactivos (5.2%) no los ha resuelto ningún sistema. Además, 59 reactivos tienen correlación reactivo-total corregida menor que .20 y 7 la tienen negativa. 16 reactivos acumulan al menos dos banderas de mal funcionamiento, lo que coincide con lo que reportan las auditorías de pruebas defectuosas (§4), y en cinco de ellos la causa resultó estar en el entorno de evaluación (§4).
• Los reactivos no son intercambiables. El 2PL ajusta mucho mejor que Rasch (ΔBIC = 1124). Aun así, el 2PL por máxima verosimilitud no converge con N = 173, de modo que las pendientes solo son interpretables con una previa. El “% resuelto” del leaderboard pondera igual reactivos muy y poco discriminantes.

En conjunto, la estructura interna respalda la interpretación de un atributo general que ordena bien a sistemas muy distintos, pero no la de diferencias finas en la frontera, que es justo el uso dominante del puntaje.

3.4 Relaciones con otras variables

Convergencia con capacidad general. El Epoch Capabilities Index ajusta un modelo de tipo TRI sobre decenas de benchmarks para ubicar modelos y benchmarks en una escala común, y SWE-bench Verified forma parte de ese conjunto (Ho et al., 2025). Que encaje en un modelo esencialmente unidimensional apoya la convergencia con una capacidad general. También abre una pregunta de validez discriminante: ¿cuánto del puntaje es específico de ingeniería de software y cuánto es habilidad general del modelo?

Criterios externos de tareas similares. La evidencia disponible apunta sobre todo a diferencias de nivel, no a correlaciones de orden:

Criterio externo	Hallazgo	Fuente
SWE-bench-Live: issues posteriores a 2024, 93 repositorios	El mismo sistema (OpenHands + Claude 3.7 Sonnet) resuelve 19.25% en Live y 43.20% en Verified con protocolo idéntico	Zhang et al. (2025)
SWE-bench Pro: 41 repositorios, incluye conjuntos reservados y comerciales	Al lanzamiento (sept. 2025), los mejores modelos rondaban 23% en el conjunto público, frente a más de 70% en Verified	Deng et al. (2025)
SWE-bench Multilingual: 300 tareas, 9 lenguajes, 42 repositorios	Existe para probar la generalización a otros lenguajes. No se verificó aquí una comparación sistemática con Verified	Yang et al. (2025)
SWE-Lancer: más de 1,400 tareas de Upwork valuadas en 1 millón de USD	Los modelos de frontera no resuelven la mayoría de las tareas, incluidas las de implementación de funcionalidades	Miserendino et al. (2025)
Aceptación por mantenedores (METR)	Cuatro mantenedores de tres repositorios de Verified (scikit-learn, Sphinx y pytest) revisaron 296 parches de agentes que pasaban las pruebas. Aun después de ajustar por el ruido en las decisiones de los mantenedores, aproximadamente la mitad no se habría integrado, y la tasa de aceptación quedó, en promedio, unos 24 puntos porcentuales por debajo del calificador automático. El ajuste toma como referencia 47 parches humanos originales, de los que solo 68% fueron reaprobados en la misma revisión ciega	METR (2026)

Lectura. El puntaje de Verified sobreestima el nivel de desempeño frente a tareas más nuevas, más diversas o juzgadas con criterios de calidad humanos. La caída es compatible con contaminación y con subrepresentación del constructo. No encontré un estudio publicado que reporte la correlación de rangos entre Verified y estos criterios sobre un conjunto amplio de sistemas comunes, así que esa evidencia queda pendiente.

3.5 Consecuencias

• Goodhart y sobreajuste. Durante 2025 el benchmark se convirtió en la cifra de referencia de los lanzamientos de modelos de código, y laboratorios y empresas de herramientas compitieron por él con andamiajes especializados, múltiples intentos y selección de parches, como muestran los envíos al leaderboard. OpenAI señaló que el estado del arte apenas pasó de 74.9% a 80.9% en seis meses. Planteó entonces si los fallos restantes reflejan limitaciones de los modelos o propiedades del propio dataset (OpenAI, 2026a).
• Saturación con techo artificial. OpenAI auditó los 138 reactivos (27.6%) que o3 no resolvía de forma consistente en 64 corridas, con al menos seis ingenieros por caso. Al menos el 59.4% (82 reactivos) tenía pruebas que rechazan soluciones funcionalmente correctas: 35.5% por pruebas demasiado estrechas, que exigen detalles de implementación no pedidos, 18.8% por pruebas demasiado amplias, que verifican funcionalidad ajena al issue, y 5.1% por otros problemas (OpenAI, 2026a). En términos psicométricos, el extremo superior de la escala está dominado por reactivos que miden coincidencia con la solución de referencia, no capacidad.
• Retiro y reacción institucional. OpenAI dejó de reportar Verified en febrero de 2026 y recomendó SWE-bench Pro. En julio de 2026 publicó una auditoría similar de Pro que estima que alrededor de 30% de sus 731 tareas públicas tiene defectos graves (27.4% según su revisión automática y 34.1% según la humana), y retiró esa recomendación (OpenAI, 2026b). Los mantenedores de SWE-bench, por su parte, restringieron los envíos a Verified y Multilingual a equipos académicos y de investigación para que el benchmark no funcione como “plataforma de validación de productos” (SWE-bench/experiments, nota del 18 de noviembre de 2025).
• Consecuencias positivas. El benchmark impulsó el desarrollo de agentes de código abiertos (SWE-agent, OpenHands, mini-SWE-agent) y una cultura de publicar trayectorias y logs. Esa transparencia es justamente la que hizo posible detectar sus defectos.

4. Amenazas a la validez

Se usan las dos categorías de Messick (1989), retomadas por los Standards.

Subrepresentación del constructo

Si el constructo declarado es “capacidad de ingeniería de software”, el test deja fuera:

• Lenguajes y ecosistemas distintos de Python y de bibliotecas de código abierto populares.
• Tareas de mayor alcance: funcionalidades nuevas, cambios en varios archivos o módulos, migraciones y refactorizaciones. 91% de los reactivos piden tareas de menos de una hora.
• Clarificación de requerimientos. Verified eliminó precisamente las tareas ambiguas.
• Calidad no funcional: legibilidad, mantenibilidad, estilo del proyecto y seguridad. Es uno de los tres motivos de rechazo que distingue METR (2026), junto con fallas de la funcionalidad central y daños a otro código.
• Escritura de pruebas propias. Las pruebas de evaluación están ocultas y el éxito se define por ellas.
• Interacción: revisión de código, iteración con retroalimentación humana, trabajo de largo horizonte.

Varianza irrelevante al constructo

Fuente	Dirección	Evidencia
Pruebas insuficientes que aceptan parches incorrectos	Infla	En SWE-bench Lite y Verified en conjunto, UTBoost encontró 36 tareas con pruebas insuficientes y 345 parches erróneos calificados como correctos. En Verified, las correcciones afectan al 24.4% de las entradas del leaderboard, con 11 cambios de posición (Yu et al., 2025). Wang et al. (2026) estiman que 7.8% de los parches “correctos” fallan la suite completa de los desarrolladores, que 29.6% se comporta distinto del parche de referencia y que, en conjunto, las tasas reportadas se inflan unos 6.2 puntos porcentuales.
Pruebas demasiado estrechas o amplias que rechazan soluciones correctas	Subestima y comprime el extremo superior	Al menos 59.4% de los 138 reactivos auditados (OpenAI, 2026a).
Memorización y contaminación	Infla, de forma diferencial según los datos de entrenamiento de cada modelo	Liang et al. (2026); OpenAI (2026a).
Fuga por historial de git o por el enunciado	Infla	Issue #465; Aleithan et al. (2024).
Andamiaje, número de intentos y presupuesto de cómputo	Varía por sistema	Rango de 57.0% a 74.8% para un mismo modelo (§3.2).
Fallos de infraestructura y deriva del entorno	Deflacta, de forma desigual entre envíos	En los registros públicos de evaluación, los reactivos de pylint fallan cuando el contenedor tiene menos de dos núcleos, porque pylint omite pruebas y el arnés cuenta la omisión como fallo: pylint-7277, con un parche que pasa la prueba pedida, lo resuelven 94 de 95 envíos evaluados con dos o más núcleos y 0 de 50 con menos. Cuatro reactivos de requests dependen de que httpbin.org responda, y en 76 de 157 envíos con registros legibles respondió con errores del servidor. Casi todas las corridas de mini-SWE-agent se evaluaron con menos de dos núcleos (36 de 37). Son seis reactivos, hasta 1.2 pp por envío (análisis propio; detalle en la entrada TRI). La actualización de tzdata rompió pruebas de matplotlib (swe-bench-tasks, CHANGELOG). Epoch AI excluye 16 reactivos que no corren de forma fiable en su infraestructura (Epoch AI, s. f.).
Concentración en django	Sesgo hacia sistemas con más exposición a ese repositorio	46.2% de los reactivos.

Precisión. Con n = 500 y p ≈ 0.75, el error estándar binomial del porcentaje es de unos 1.9 puntos (IC 95% ≈ ±3.8 pp), sin contar la variabilidad entre corridas de agentes estocásticos. Las comparaciones pareadas sobre los mismos reactivos son más precisas, pero casi nunca se reportan. Bean et al. (2025) encontraron que solo 16% de 445 benchmarks de LLM usan pruebas estadísticas al comparar modelos. BetterBench (Reuel et al., 2024) reporta lo mismo de forma más general: la mayoría de los benchmarks evaluados no informa la significancia estadística de sus resultados. Las diferencias de 1–2 puntos que separan a los primeros lugares no son interpretables sin ese análisis.

5. Alcance y generalizabilidad

El examinado es un sistema. El puntaje corresponde a la terna (modelo, andamiaje, presupuesto/protocolo): herramientas disponibles, número de intentos, selección de parches, límites de pasos y de tokens, nivel de razonamiento, versión del harness y fecha de evaluación. Un puntaje de laboratorio con andamiaje propio y un puntaje “bash-only” del mismo modelo no son formas paralelas del mismo test.

Se puede generalizar, con cautela, a:

• Issues de corrección de defectos acotados en bibliotecas de Python de código abierto similares a las 12 de origen, bajo una configuración de agente equivalente y con pruebas automatizadas como criterio.
• Comparaciones gruesas entre sistemas de generaciones distintas (por ejemplo, 2024 frente a 2026) evaluados con el mismo protocolo.

No se puede generalizar a:

• Otros lenguajes, ecosistemas o código propietario. Multilingual, Pro y Live muestran caídas importantes.
• Tareas de desarrollo de funcionalidades, diseño o trabajo de varias horas o días.
• “Calidad integrable” según criterios de mantenedores humanos.
• Issues posteriores a la fecha de corte de entrenamiento del modelo, ni repositorios no expuestos públicamente.
• El mismo modelo con otro andamiaje o presupuesto.
• Productividad de equipos humanos que usan el sistema.

6. Qué sí y qué no se puede concluir

Sí:

• Que el sistema, con esa configuración y esa versión del harness, produjo parches que pasan las pruebas de N de los 500 reactivos.
• Que hubo progreso real y grande en agentes de código entre 2024 y 2026: de alrededor de 33% (GPT-4o, OpenAI, 2024) a alrededor de 80% en el mismo test.
• Que un sistema con 70% probablemente supera a uno con 40% en tareas de corrección acotada en Python, bajo protocolos comparables.

No:

• Que el modelo “resuelve el N% de los problemas de ingeniería de software”.
• Que el sistema A es mejor que B cuando la diferencia es de unos pocos puntos, cuando usan andamiajes o intentos distintos, o sin intervalos de confianza.
• Que el N% de los parches sería aceptado por un mantenedor. METR (2026) sugiere que alrededor de la mitad no lo sería.
• Que el modelo rendirá igual en tu código, en otro lenguaje o en tareas nuevas.
• Que los puntajes por encima de ~80% reflejan capacidad y no memorización o coincidencia con la solución de referencia.
• Comparar puntajes obtenidos antes y después de las correcciones del harness (2024, 2025, 2026) como si estuvieran en la misma escala.

7. Veredicto por inferencia

Síntesis. SWE-bench Verified fue, en 2024, una mejora clara de la calidad de los reactivos frente al SWE-bench original, y a mi parecer sigue siendo un instrumento valioso para la investigación, pues publica su matriz de respuestas, sus trayectorias y su harness, y es precisamente esa transparencia la que permitió encontrarle los defectos que aquí describo. Sin embargo, como indicador de la capacidad de ingeniería de software para comparar modelos de frontera en octubre de 2026, considero que el argumento de validez no se sostiene, pues la escala está saturada, está contaminada y está comprimida en su extremo superior por reactivos defectuosos. La interpretación que me parece defendible es mucho más estrecha que la que circula en los anuncios, algo así como «el desempeño de un sistema específico, con una configuración específica, al corregir defectos acotados en un conjunto conocido de bibliotecas de Python, calificado por pruebas unitarias». Quizá la pregunta que queda, y que nos corresponde plantearnos a quienes construimos y usamos estas pruebas, es qué tendría que tener un benchmark de ingeniería de software para que su puntaje signifique lo mismo dentro de un año, cuando los modelos ya lo hayan visto.

8. Referencias

Aleithan, R., Xue, H., Mohajer, M. M., Nnorom, E., Uddin, G., & Wang, S. (2024). SWE-Bench+: Enhanced coding benchmark for LLMs [Preprint]. arXiv. https://arxiv.org/abs/2410.06992

American Educational Research Association, American Psychological Association, & National Council on Measurement in Education. (2014). Standards for educational and psychological testing. American Educational Research Association.

Bean, A. M., et al. (2025). Measuring what matters: Construct validity in large language model benchmarks. En Advances in Neural Information Processing Systems 38 (Datasets and Benchmarks Track). https://arxiv.org/abs/2511.04703

Deng, X., Da, J., et al. (2025). SWE-Bench Pro: Can AI agents solve long-horizon software engineering tasks? [Preprint]. arXiv. https://arxiv.org/abs/2509.16941

Epoch AI. (s. f.). SWE-bench Verified [Página del benchmark]. Consultado el 27 de octubre de 2026. https://epoch.ai/benchmarks/swe-bench-verified

Ho, A., Denain, J.-S., Atanasov, D., Albanie, S., & Shah, R. (2025). A Rosetta Stone for AI benchmarks [Preprint]. arXiv. https://arxiv.org/abs/2512.00193

Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., & Narasimhan, K. R. (2024). SWE-bench: Can language models resolve real-world GitHub issues? En The Twelfth International Conference on Learning Representations. https://openreview.net/forum?id=VTF8yNQM66

Kane, M. T. (2006). Validation. En R. L. Brennan (Ed.), Educational measurement (4a ed., pp. 17–64). American Council on Education/Praeger.

Kane, M. T. (2013). Validating the interpretations and uses of test scores. Journal of Educational Measurement, 50(1), 1–73. https://doi.org/10.1111/jedm.12000

Liang, S., Garg, S., & Zilouchian Moghaddam, R. (2026). The SWE-Bench illusion: When state-of-the-art LLMs remember instead of reason. En Proceedings of the 48th IEEE/ACM International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP 2026). https://arxiv.org/abs/2506.12286

Messick, S. (1989). Validity. En R. L. Linn (Ed.), Educational measurement (3a ed., pp. 13–103). American Council on Education/Macmillan.

METR. (2026, 10 de marzo). Many SWE-bench-passing PRs would not be merged into main. https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/

Miserendino, S., Wang, M., Patwardhan, T., & Heidecke, J. (2025). SWE-Lancer: Can frontier LLMs earn $1 million from real-world freelance software engineering? En Proceedings of the 42nd International Conference on Machine Learning (PMLR, Vol. 267). https://proceedings.mlr.press/v267/miserendino25a.html

OpenAI. (2024, 13 de agosto). Introducing SWE-bench Verified. https://openai.com/index/introducing-swe-bench-verified/

OpenAI. (2026a, 23 de febrero). Why SWE-bench Verified no longer measures frontier coding capabilities. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/

OpenAI. (2026b, 8 de julio). Separating signal from noise in coding evaluations. https://openai.com/index/separating-signal-from-noise-coding-evaluations

Reuel, A., Hardy, A., Smith, C., Lamparth, M., Hardy, M., & Kochenderfer, M. J. (2024). BetterBench: Assessing AI benchmarks, uncovering issues, and establishing best practices. En Advances in Neural Information Processing Systems 37 (Datasets and Benchmarks Track). https://arxiv.org/abs/2411.12990

SWE-bench. (2025a). Repo state loopholes during agentic evaluation (Issue #465) [Discusión en GitHub]. https://github.com/SWE-bench/SWE-bench/issues/465

SWE-bench. (2025b). Fix git log leakage in environment images (Pull request #471) [Código fuente]. https://github.com/SWE-bench/SWE-bench/pull/471

SWE-bench. (2026a). fix(grading): detect stdout spoofing via test exit code (Pull request #620) [Código fuente]. https://github.com/SWE-bench/SWE-bench/pull/620

SWE-bench. (2026b). swe-bench-tasks (Versión 3d07b464) [Conjunto de datos y código fuente]. https://github.com/SWE-bench/swe-bench-tasks

SWE-bench. (2026c). experiments (Versión 40f164d) [Conjunto de datos]. https://github.com/SWE-bench/experiments

SWE-bench. (2026d). Exit-code spoof guard (#620) reads the first “>>>>> Test Exit Code:” marker in the log… (Issue #667) [Discusión en GitHub]. https://github.com/SWE-bench/SWE-bench/issues/667

Wang, Y., Pradel, M., & Liu, Z. (2026). Are “solved issues” in SWE-bench really solved correctly? An empirical study. En Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE 2026). https://arxiv.org/abs/2503.15223

Yang, J., Lieret, K., Jimenez, C. E., Wettig, A., Khandpur, K., Zhang, Y., Hui, B., Press, O., Schmidt, L., & Yang, D. (2025). SWE-smith: Scaling data for software engineering agents [Preprint]. arXiv. https://arxiv.org/abs/2504.21798

Yu, B., Zhu, Y., He, P., & Kang, D. (2025). UTBoost: Rigorous evaluation of coding agents on SWE-Bench. En Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) (pp. 3762–3774). Association for Computational Linguistics. https://doi.org/10.18653/v1/2025.acl-long.189

Zhang, L., et al. (2025). SWE-bench goes live! [Preprint]. arXiv. https://arxiv.org/abs/2505.23419

Nota sobre licencias. El código de SWE-bench se distribuye bajo licencia MIT. No pude confirmar desde este entorno la licencia declarada en la ficha del dataset en Hugging Face. Los reactivos contienen texto de issues (contenido de usuarios de GitHub) y parches de 12 proyectos con licencias propias, en su mayoría permisivas (BSD, MIT, Apache) y al menos una copyleft (pylint, GPL). Por eso esta ficha describe los reactivos solo de forma agregada y no reproduce su contenido.