Resumen Técnico: SWE-Bench ProMax

Planteamiento del Problema

A medida que los agentes de codificación con IA avanzan, los benchmarks de ingeniería de software existentes se están saturando rápidamente, lo que plantea dudas sobre si el aumento en las puntuaciones refleja una mejora genuina en la capacidad o simplemente las limitaciones del diseño actual de los benchmarks. Una auditoría reciente de SWE-bench Verified reveló que casi el 60% de las instancias no resueltas contenían suites de pruebas defectuosas —ya fuera por ser demasiado estrechas (rechazando soluciones correctas) o demasiado amplias (verificando requisitos no declarados)— y que los modelos de frontera podían reproducir parches de oro (gold patches) de los datos de entrenamiento. Además, los benchmarks actuales se centran principalmente en correcciones de errores aisladas o implementaciones de características, involucrando a menudo modificaciones de un solo archivo. Esto no logra capturar la complejidad de la refactorización de código, una tarea crítica de largo horizonte en el desarrollo profesional que requiere cambios coordinados y que preserven el comportamiento a través de muchos archivos. Los benchmarks de refactorización existentes son limitados en escala, están restringidos a un solo lenguaje de programación o carecen de una verificación humana rigurosa de la calidad de las pruebas.

Metodología

Los autores introducen SWE-Bench ProMax, un benchmark multilingüe curado por expertos diseñado para abordar estas brechas mediante un riguroso proceso de construcción de tres etapas:

1. Recolección de Datos: Los autores identificaron repositorios candidatos en GitHub que cumplieran con criterios específicos (≥500 estrellas, licencia de código abierto aprobada, lenguaje principal entre Python, Java, TypeScript, Go, C, C++ o Rust). Extrajeron commits enviados después de enero de 2025 que contenían la palabra clave "refactor" (excluyendo "bug fix") que modificaban tanto archivos de prueba como archivos no pertenecientes a las pruebas. Esto produjo un grupo inicial de 29,782 candidatos.
2. Construcción del Entorno: Para cada candidato, se construyó un entorno Docker aislado que contenía el repositorio en el estado previo a la refactorización con todas las dependencias instaladas. Se aplicó el parche de oro (cambios en la fuente y en las pruebas) y se ejecutó la suite de pruebas. Las instancias donde el entorno falló al compilar o donde el parche de oro no pasó todas las pruebas fueron descartadas.
3. Filtrado y Reescritura de Problemas: Esta etapa involucró a expertos humanos asistidos por LLMs para asegurar una alta calidad:
   • Análisis de Commits: Los expertos analizaron los diffs para comprender el alcance y la intención.
   • Filtrado de Calidad: Se eliminaron las tareas con insuficiencia de complejidad (por ejemplo, cambios de un solo archivo, conteos de líneas triviales). Crucialmente, las suites de pruebas fueron revisadas manualmente para eliminar pruebas excesivamente estrechas (que imponen detalles de implementación específicos) y pruebas excesivamente amplias (que verifican comportamientos fuera del alcance de la tarea).
   • Reescritura del Planteamiento del Problema: Los mensajes de commit originales fueron reescritos desde cero para proporcionar especificaciones precisas y unívocas. Cada descripción fue verificada para ser una condición necesaria y suficiente para el parche de oro.
   • Verificación Humana: Una revisión final aseguró la alineación entre la descripción del problema, la suite de pruebas y el parche de oro.

El benchmark final consiste en 170 instancias extraídas de 70 repositorios distintos a través de siete lenguajes de programación.

Contribuciones Clave

1. Benchmark de Alta Calidad Curado por Expertos: A diferencia de los benchmarks automatizados, SWE-Bench ProMax se somete a una curación experta de múltiples etapas. Las descripciones de los problemas se reescriben para ser especificaciones precisas, y las suites de pruebas son vetadas manualmente para eliminar los defectos que plagaron a los benchmarks anteriores.
2. Escala y Complejidad Sin Precedentes: El benchmark apunta a la refactorización a gran escala, con instancias que promedian 11.4 archivos modificados y 261.6 líneas de código por tarea. Esto supera significativamente a los benchmarks existentes (por ejemplo, el 86% de las instancias de SWE-bench Verified modifican un solo archivo).
3. Cobertura Multilingüe: El conjunto de datos abarca siete lenguajes diversos (Python, Java, TypeScript, Go, C, C++, Rust), permitiendo el análisis de cómo los paradigmas específicos de cada lenguaje (por ejemplo, modelos de propiedad en Rust, gestión manual de memoria en C) afectan el rendimiento de los agentes.
4. Protocolo de Evaluación Riguroso: El benchmark utiliza una evaluación basada en resultados donde una instancia se resuelve solo si las modificaciones del agente pasan cada prueba en la suite, sin depender de pasos intermedios o comandos específicos.

Resultados y Análisis

Los autores evaluaron seis modelos de frontera (tres propietarios, tres de pesos abiertos) bajo dos andamiajes de agentes (mini-swe-agent y OpenHands).

• Desafío No Saturado: El modelo con mejor desempeño, GPT-5.2, logró una tasa de resolución del 41.2% en SWE-Bench ProMax. Esto es sustancialmente inferior a las tasas de resolución de >75% observadas en SWE-bench Verified, confirmando que la refactorización a gran escala y de múltiples archivos sigue siendo un desafío importante no resuelto.
• Eficiencia de Costos de los Modelos de Pesos Abiertos: Los modelos de pesos abiertos demostraron competitividad con los modelos propietarios a una fracción del costo. Por ejemplo, GLM-5 logró una tasa de resolución del 36.5% a $0.24 por instancia, comparado con Claude Sonnet 4.6 con un 38.8% por $4.77.
• Variación de Lenguaje: Ningún modelo único dominó todos los lenguajes. El rendimiento varió significamente por lenguaje (por ejemplo, Claude Sonnet 4.6 destacó en Rust y TypeScript, mientras que GPT-5.2 funcionó mejor en Python y C), sugiriendo que las fortalezas de los modelos están ligadas a los datos de entrenamiento y arquitecturas específicas de cada lenguaje.
• Análisis de Modos de Fallo: El análisis de trayectoria reveló dos patrones de fallo principales:
  1. Refactorización Incompleta: Los agentes modificaron consistentemente menos archivos de los requeridos por el parche de oro. Aunque a menudo identificaban los archivos centrales, fallaban al propagar los cambios a sitios de llamada periféricos, documentación y archivos de configuración, lo que provocaba fallos en las pruebas debido a dependencias descendentes inconsistentes.
  2. Exploración Improductiva: Los intentos fallidos consumieron significativamente más rondas de interacción que los exitosos, entrando a menudo en ciclos repetitivos de edición-reversión sin expandir el alcance de las modificaciones.

Significancia

El artículo afirma que SWE-Bench ProMax proporciona un benchmark significativo y no saturado para evaluar agentes de codificación con IA en tareas de ingeniería de software realistas y a gran escala. Al abordar los defectos de calidad de los benchmarks previos (pruebas defectuosas, descripciones ambiguas) y escalar la complejidad para igualar la refactorización de nivel de producción, ofrece una prueba más rigurosa de la capacidad de un agente para mantener planes coherentes a través de múltiples archivos. Los resultados sugieren que, si bien los modelos de frontera están mejorando, la capacidad de coordinación sostenida entre archivos sigue siendo un cuello de botella fundamental. Además, el benchmark destaca que los modelos de pesos abiertos pueden acercarse al rendimiento de frontera a un costo significativamente menor, desafiando la suposición de que los costos de API más altos garantizan resultados proporcionalmente mejores en escenarios de refactorización complejos.