SWE-Bench Verified: qué mide realmente un resultado y por qué no basta para elegir un agente de código

Qué pregunta responde SWE-Bench Verified y cuál no responde

SWE-Bench es una evaluación basada en incidencias históricas de GitHub y sus cambios correctivos asociados. Su subconjunto Verified contiene 500 instancias revisadas por personas para mejorar la fiabilidad de la evaluación. En términos prácticos, plantea una pregunta acotada: dado el contexto suministrado para una incidencia de un repositorio concreto, ¿puede un sistema proponer un parche que pase las pruebas definidas para esa tarea dentro de un entorno reproducido?

La respuesta es valiosa porque conecta generación de código con un resultado ejecutable, no solo con una preferencia humana o una coincidencia textual con una solución esperada. Un agente debe navegar una base de código, interpretar una descripción, editar archivos y generar una modificación compatible con las pruebas del entorno. Sin embargo, la métrica resume ese proceso en una proporción de tareas que cumplen un criterio binario de resolución.

No responde, por sí sola, si un agente puede operar con autonomía responsable en un repositorio real. No establece que sepa priorizar una cola de incidencias, pedir aclaraciones sobre requisitos ambiguos, decidir que no debe modificar código, revisar una contribución de terceros, gestionar secretos, coordinar un despliegue, responder a una alerta operativa ni asumir la responsabilidad de una regresión. Esas actividades dependen de personas, políticas, sistemas y contextos que no quedan representados de forma completa por una instancia cerrada.

Por ello, una puntuación debe leerse como evidencia sobre una capacidad evaluada en un protocolo determinado, no como una clasificación general de herramientas de ingeniería. En las secciones de Benchmarks, Comparar y Descubrir puede ser razonable usarla como una señal entre varias, siempre que se conserven sus condiciones de obtención y no se transforme una cifra aislada en una promesa de resultados operativos.

Anatomía de una tarea: de una incidencia histórica a un parche evaluado

La construcción original de SWE-Bench parte de problemas resueltos en GitHub de 12 repositorios Python de código abierto y los relaciona con la solicitud de cambio correspondiente. Una instancia reúne, como mínimo conceptual, la incidencia, el estado histórico del repositorio sobre el que se trabajará y el cambio de referencia del proyecto. El benchmark convierte ese material histórico en una tarea que un sistema puede intentar resolver mediante una edición de código.

Conviene distinguir el cambio de referencia de la condición de victoria. El objetivo no es necesariamente reproducir literalmente el parche humano original carácter por carácter. Un parche alternativo puede ser aceptable si, al aplicarse sobre el entorno de la instancia, satisface las pruebas de corrección previstas y no rompe las pruebas de preservación. Esta distinción importa porque evita tratar el benchmark como un ejercicio de recuperación exacta de una respuesta.

Verified añade una capa de filtrado humano sobre instancias de SWE-Bench. La documentación del proyecto describe el conjunto como un subconjunto de 500 instancias validado por personas. La selección busca retirar casos cuya evaluación no sea suficientemente fiable; aun así, el subconjunto no convierte cada problema en una representación exhaustiva de la ingeniería de software ni elimina toda posible ambigüedad interpretativa.

Una ejecución reproducible requiere más que el texto de la incidencia. Debe especificar la revisión de los datos, el identificador de cada instancia, la imagen o definición de entorno, la versión del arnés, el parche producido y los límites de ejecución. La distribución de datos consultada se sirve desde una rama que puede cambiar; por eso, citar solo el nombre de la rama no fija el mismo conjunto para futuras repeticiones. Debe inmovilizarse una revisión completa y registrarse la fecha de consulta.

Cómo se define una resolución y por qué el porcentaje final oculta decisiones metodológicas

Según la descripción de la evaluación, el agente no ve las pruebas. El arnés evalúa el parche mediante dos grupos: las pruebas FAIL_TO_PASS y las pruebas PASS_TO_PASS. Las primeras representan el comportamiento que el cambio debe corregir; las segundas sirven para comprobar que la edición no haya roto de forma involuntaria partes no relacionadas de la base de código. Para que una edición cuente como resolución completa deben aprobarse ambos grupos.

Esta definición es más exigente que comprobar que el código compila o que una única prueba nueva pasa. También permite comparar parches funcionalmente distintos sin imponer igualdad con el cambio histórico. Pero un porcentaje final sigue ocultando decisiones: cuántas instancias entraron en el denominador, qué ocurrió con errores de infraestructura, cuánto tiempo tuvo cada tarea, cuántas muestras se generaron y cuál fue la política al elegir una de ellas.

El arnés oficial documenta parámetros para seleccionar el conjunto y las instancias, definir un tiempo de espera y separar ejecuciones. También aplica parches, ejecuta pruebas y calcula resultados. En consecuencia, informar solo una tasa de resolución sin publicar el comando o una configuración equivalente dificulta verificar si dos cifras usaron las mismas tareas, los mismos límites y el mismo mecanismo de evaluación.

Debe evitarse una conclusión inversa igualmente simplista: que una métrica binaria carece de utilidad porque no cubre todo el ciclo de desarrollo. La métrica sí puede aportar evidencia concreta sobre reparación de incidencias en condiciones definidas. La cuestión es delimitar su alcance y exigir trazabilidad suficiente para que otra persona pueda inspeccionar las condiciones de la afirmación.

Los siete campos mínimos para comparar dos resultados publicados

Una tabla responsable no necesita incluir cada detalle interno de un sistema, pero sí debe permitir distinguir una ejecución de otra. El primer campo es la identidad exacta del conjunto: nombre, variante, revisión fijada y lista de instancias o regla de selección. «SWE-Bench Verified» no basta si el resultado se produjo sobre una muestra, una copia modificada o una versión de datos distinta.

El segundo campo es el modelo: proveedor, nombre, versión o fecha identificable cuando exista, y parámetros de inferencia que afecten al resultado. El tercero es el andamiaje del agente: framework, versión y estrategia de planificación o edición. Un mismo modelo puede obtener resultados distintos si cambia el bucle de herramientas, el formato de contexto, la gestión de errores o el criterio para detenerse.

El cuarto campo describe las herramientas habilitadas: terminal, búsqueda local, edición de archivos, ejecución de pruebas, acceso de red y cualquier recuperación externa. El quinto declara el presupuesto: límite de pasos, llamadas al modelo, tokens si se dispone de ellos, tiempo por instancia y recursos de cómputo. El sexto indica el protocolo: número de muestras, temperatura u otra configuración de generación, reintentos y regla de selección. El séptimo aporta los artefactos que permitan comprobar el resultado: configuración, registros suficientes, parches o predicciones y salida del arnés cuando puedan compartirse.

La página del proyecto distingue un leaderboard general que reúne sistemas heterogéneos de una comparación de modelos con una configuración común basada en mini-SWE-agent. Esa separación es una advertencia metodológica: una clasificación de sistemas completos no aísla el efecto del modelo, mientras que una configuración común puede ayudar a esa comparación concreta. Además, el propio proyecto advierte que las versiones 1.x y 2.x de mini-SWE-agent no son necesariamente comparables.

No todos estos datos estarán disponibles en una nota de lanzamiento. En ese caso, el resultado no queda refutado automáticamente, pero debe etiquetarse como incompletamente especificado. La respuesta rigurosa no es rellenar los huecos con supuestos sobre el proveedor ni ordenar cifras heterogéneas como si pertenecieran a un experimento controlado.

Qué puede inflar o limitar una puntuación

La selección de tareas es el primer factor. Un subconjunto elegido por dificultad, por disponibilidad de entorno o por éxitos previos no tiene por qué conservar la misma distribución que el conjunto completo. También es relevante si se excluyen instancias que agotan el tiempo, fallan al construir la imagen o presentan problemas de infraestructura. Un informe debe separar, en la medida de lo posible, un fallo del agente de un fallo del entorno y explicar cómo ambos afectan al resultado agregado.

Los reintentos y las múltiples muestras merecen atención específica. Probar varios parches por incidencia puede ser una decisión técnica legítima, sobre todo si refleja el uso previsto del sistema, pero cambia la unidad práctica de evaluación: ya no se mide el éxito de un único intento. Deben informarse el número máximo de intentos, si hay reinicios del agente y si las ejecuciones que fallan se vuelven a lanzar.

La información accesible al sistema cambia la naturaleza de la tarea. Las pruebas ocultas reducen una vía directa de adaptación a la respuesta esperada, pero no eliminan otras diferencias: el agente puede disponer de búsqueda, de herramientas de ejecución, de documentación local o de acceso externo según el protocolo. Una comparación válida requiere saber qué recursos se habilitaron y si eran iguales para todos los sistemas comparados.

También existe una incertidumbre temporal. OpenAI ha expuesto su postura de que SWE-Bench Verified dejó de medir capacidades de programación de frontera y ha señalado el riesgo de contaminación por la disponibilidad pública de los problemas y soluciones históricas. Esta es una evaluación y recomendación de OpenAI, no una medición independiente que permita cuantificar la contaminación de cada modelo. Aun así, obliga a ser prudente al interpretar una mejora reciente como progreso general sin examinar la exposición potencial a los datos.

El análisis de Epoch AI plantea otra limitación: el benchmark se concentra en repositorios conocidos y en arreglos relativamente acotados. Esa es una interpretación secundaria, no una propiedad que deba presentarse como un hecho definitivo de cada instancia. Sirve, no obstante, para formular una pregunta útil: ¿la cartera de mantenimiento de la organización se parece materialmente a estas tareas históricas de repositorios Python? Si la respuesta es no, la transferencia esperable de la señal será limitada e incierta.

Por qué una incidencia resuelta no demuestra mantenimiento autónomo

En un repositorio real, resolver una incidencia empieza antes de escribir un parche. Hay que hacer triage, reproducir el problema, estimar impacto, identificar dependencias, negociar requisitos y decidir prioridades. Una tarea de benchmark ofrece una formulación histórica y un criterio de prueba preparado; en operaciones normales, esas entradas pueden faltar, ser contradictorias o cambiar mientras se investiga.

Después del parche también intervienen actividades que una tasa de resolución no cubre de forma suficiente: revisión por pares, análisis de seguridad, licencias, compatibilidad hacia atrás, migraciones, rendimiento, observabilidad, aprobación de cambios y despliegue. Las pruebas de preservación del benchmark son una protección importante dentro de la instancia, pero no equivalen a todas las validaciones de una organización ni a los efectos de integrar un cambio con ramas, servicios y usuarios actuales.

La responsabilidad operativa es otro límite. Un agente puede generar una modificación que pasa las pruebas del arnés y aun así requerir supervisión humana para decidir si se fusiona, cuándo se despliega y cómo se revierte. Por tanto, la compra, adopción o permiso de escritura de una herramienta no debería depender únicamente de un porcentaje de SWE-Bench Verified. Debe incorporar controles de acceso, revisión, trazabilidad, aislamiento y pruebas específicas del entorno propio.

Esto no implica que el benchmark sea irrelevante para responsables de ingeniería. Puede ayudar a seleccionar hipótesis para una prueba posterior: por ejemplo, si un sistema muestra capacidad de editar y validar parches en tareas históricas, puede merecer una evaluación controlada en incidencias internas de bajo riesgo. La transición correcta es de evidencia de benchmark a experimento local, no de benchmark a autonomía de producción.

Cómo trasladar la señal a una prueba breve en el repositorio propio

No es necesario reproducir todo SWE-Bench para obtener información más cercana a la realidad local. Una prueba breve puede usar un conjunto pequeño de incidencias ya cerradas o de cambios preparados expresamente, siempre que los responsables definan de antemano los criterios de inclusión, el acceso permitido y el método de evaluación. La finalidad no es fabricar una nueva tabla pública, sino reducir la incertidumbre de una decisión técnica concreta.

El diseño debe separar las tareas de desarrollo de las tareas de evaluación. La persona o equipo que prepare los casos puede conservar pruebas de aceptación no visibles para el agente, cuando sea viable y apropiado. Cada caso debe incluir un entorno aislado, un estado de repositorio fijado y límites explícitos de tiempo, coste y herramientas. No se debe dar al sistema acceso a credenciales de producción ni permitir cambios fuera del entorno controlado.

Mida más de una dimensión. Además de si las pruebas pasan, registre el tiempo hasta el parche, el número de intervenciones humanas, la calidad de la explicación, el cumplimiento de convenciones del repositorio, los hallazgos de revisión y los incidentes de seguridad o de proceso. Una muestra pequeña no permite inferencias amplias; sí puede revelar incompatibilidades evidentes, costes inesperados o clases de tareas donde el sistema requiere demasiada supervisión.

La comparación más útil mantiene constante el protocolo. Si se prueban dos sistemas, procure que reciban los mismos casos, la misma ventana temporal, el mismo acceso a herramientas y los mismos límites. Si se modifica el agente o se permite un presupuesto mayor a uno de ellos, informe ese cambio como parte del resultado en lugar de atribuir toda diferencia al modelo.

Ficha final: qué puede afirmarse con rigor

Una afirmación sólida adopta una forma limitada: «En la revisión declarada de SWE-Bench Verified, con este modelo, esta versión de agente, estas herramientas, este presupuesto y este protocolo, la ejecución obtuvo esta tasa de instancias que superaron el criterio del arnés». Si los artefactos están disponibles, puede añadirse que el resultado es auditable o reproducible bajo las condiciones publicadas. Si faltan, corresponde decir que la afirmación no puede verificarse completamente con la información disponible.

No es riguroso transformar esa afirmación en «el modelo resuelve ese porcentaje de los bugs reales», «es el mejor agente de código» o «puede mantener un repositorio sin supervisión». Esas conclusiones amplían población, contexto y responsabilidades sin una evidencia equivalente. Incluso una ejecución impecable en el benchmark solo responde a las tareas y al protocolo que efectivamente se evaluaron.

La documentación primaria ofrece bases claras para esta lectura: Verified es un subconjunto humano de 500 instancias; la resolución exige superar pruebas de corrección y de preservación; y la configuración del arnés forma parte material de la ejecución. A la vez, persisten incertidumbres: la disponibilidad pública de las tareas puede afectar a la validez temporal para ciertos modelos, las configuraciones de agentes cambian y una tarea histórica no reproduce todos los mecanismos sociales y operativos del mantenimiento.

La decisión práctica consiste en conservar ambas ideas. SWE-Bench Verified puede ser una señal técnica útil y más concreta que una demostración anecdótica. No es una garantía de autonomía, seguridad, productividad neta ni adecuación a un repositorio propio. Quien publique, compare o compre a partir de estos resultados debe hacer visibles las condiciones que convierten una cifra en evidencia y las incertidumbres que impiden convertirla en una promesa.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.