Resumen Técnico: ROADMAPBENCH

Declaración del Problema

Las evaluaciones actuales para agentes de programación, como SWE-bench y sus variantes, se centran predominantemente en correcciones de errores a corto plazo y de un solo problema, con métricas de evaluación gruesas de tipo aprobado/reprobado. Estas evaluaciones suelen involucrar commits aislados con soluciones oráculo que oscilan entre 33 y 107 líneas de código (LOC). En consecuencia, no logran capturar la complejidad de la ingeniería de software del mundo real, que a menudo requiere un desarrollo sostenido y multiobjetivo que abarca semanas o meses, involucrando cambios coordinados en numerosos archivos y módulos. Además, las evaluaciones existentes están fuertemente concentradas en repositorios de Python, lo que aumenta el riesgo de contaminación de datos procedentes de corpus de preentrenamiento. Existe una brecha crítica en la evaluación de agentes en tareas de evolución de software a largo plazo y multiobjetivo que reflejen la escala y la estructura de las actualizaciones de versiones reales.

Metodología

Los autores presentan ROADMAPBENCH, una evaluación diseñada para evaluar agentes de programación en tareas de desarrollo de software a largo plazo y multiobjetivo, fundamentadas en actualizaciones de versiones reales de código abierto.

Construcción del Conjunto de Datos

• Alcance: La evaluación comprende 115 tareas derivadas de 17 repositorios de código abierto en 5 lenguajes de programación (Python, TypeScript, C++, Go, Rust).
• Definición de la Tarea: Cada tarea presenta al agente una instantánea del código de la versión de origen y una instrucción de hoja de ruta multiobjetivo. El agente debe implementar la funcionalidad introducida en una versión objetivo. La hoja de ruta especifica qué implementar (firmas de API, semántica de parámetros, valores predeterminados, comportamiento de excepciones) sin revelar cómo implementarlo.
• Escala: Las tareas implican una modificación mediana de 3.700 líneas de código en 51 archivos, con conteos de subtareas que oscilan entre 3 y 12 (mediana 5).
• Protocolo de Evaluación:
  • Tasa de Resolución: Una métrica binaria que indica si el agente supera todas las subtareas.
  • Puntuación de Finalización: Una métrica ponderada que captura el progreso parcial. Cada subtarea tiene un peso basado en la complejidad; la puntuación es la fracción ponderada de subtareas superadas.
  • Entorno: Las tareas se ejecutan en un entorno Docker fijo (utilizando el marco Harbor) donde el agente no tiene acceso al código de la versión objetivo, a los archivos de prueba ni al parche oráculo.

Pipeline de Construcción

La construcción del conjunto de datos sigue un pipeline riguroso de cuatro etapas para garantizar la calidad y eliminar defectos del lado de la tarea:

1. Minería de Repositorios: Selección de repositorios con altos recuentos de estrellas, historiales de lanzamiento activos hasta 2025 y documentación de lanzamiento de alta calidad.
2. Construcción de Tareas: Alineación de narrativas de lanzamiento con diferencias de código para generar instrucciones y suites de pruebas adaptadas. Los parches oráculo se extraen y validan.
3. Validación Estática: Verificación de la autosuficiencia de la especificación, la trazabilidad de la fuente y la validez de las pruebas para garantizar que no haya fugas de información.
4. Control de Calidad Basado en Ejecución: Agentes de tres niveles de capacidad intentan las tareas. Los fallos se atribuyen ya sea a defectos del lado de la tarea (por ejemplo, especificaciones ambiguas) o a limitaciones del modelo. Los defectos del lado de la tarea se reparan iterativamente hasta que la tarea está "limpia", asegurando que las puntuaciones bajas reflejen limitaciones genuinas del modelo y no artefactos de la evaluación.

Contribuciones Clave

1. Creación de la Evaluación: Construcción de ROADMAPBENCH, la primera evaluación dirigida específicamente al desarrollo de software a largo plazo y multiobjetivo en 17 repositorios y 5 lenguajes, estableciendo un entorno de evaluación distinto más allá de la resolución de problemas aislados.
2. Innovación del Pipeline: Desarrollo de un pipeline de construcción que transforma actualizaciones de versiones reales en tareas estructuradas, combinando validación estática con control de calidad basado en ejecución para separar los defectos del lado de la tarea de las limitaciones genuinas del modelo.
3. Evaluación Exhaustiva: Evaluación sistemática de 13 modelos de vanguardia (incluyendo Claude-Opus-4.7, GPT-5.4, Gemini-3.1-Pro y otros) que revela brechas significativas de rendimiento en comparación con las evaluaciones existentes de corrección de errores.

Resultados

La evaluación de 13 modelos de vanguardia en ROADMAPBENCH revela que los agentes actuales están lejos de resolver tareas de desarrollo de software a largo plazo:

• Bajas Tasas de Resolución: Incluso el modelo más fuerte, Claude-Opus-4.7, resuelve solo el 39.1% de las tareas. El modelo más débil, Seed-2.0-Pro, resuelve apenas el 5.2%. Esto contrasta marcadamente con las puntuaciones superiores al 80% que estos sistemas alcanzan en SWE-bench Verified.
• Progreso Parcial: La Puntuación de Finalización (con un promedio de 0.692 para el modelo superior) es consistentemente más alta que la tasa de resolución, lo que indica que los agentes a menudo completan varias subtareas antes de detenerse en la integración, la corrección o los objetivos posteriores.
• Varianza por Dominio: El rendimiento varía significativamente según el dominio. Las tareas de ML y Datos son las más desafiantes, con seis de los trece modelos resolviendo cero tareas. Las tareas de ORM y Validación son relativamente más manejables. UI y Renderizado muestra la separación más aguda entre los modelos de vanguardia y los más débiles.
• Modos de Fallo:
  • Modelos Fuertes: Los fallos están dominados por Errores de Implementación (por ejemplo, defectos de código, errores de conexión, malentendidos), lo que sugiere que pueden construir código completo y compilable, pero luchan con la precisión del comportamiento.
  • Modelos Débiles: Los fallos están dominados por Errores de Construcción (fallos de compilación/enlace) y Implementaciones Faltantes, lo que indica un cuello de botella en la producción de código completo y construible.
• Eficiencia: Los modelos de vanguardia (por ejemplo, Claude-Opus-4.7) demuestran una mayor eficiencia de pasos, logrando tasas de resolución más altas con menos llamadas a herramientas en comparación con los modelos de nivel medio que consumen presupuestos más grandes con menores retornos.

Significancia

El artículo posiciona a ROADMAPBENCH como una evaluación diagnóstica que revela las limitaciones actuales de los agentes de programación en el desarrollo de software sostenido. Los resultados sugieren que, aunque los agentes han avanzado en la corrección de errores a corto plazo, el desarrollo de software a largo plazo y multiobjetivo sigue siendo un problema en gran medida sin resolver. La evaluación destaca que el cuello de botella de vanguardia ha cambiado de la generación de código a la ejecución de cambios precisos y coordinados en bases de código complejas. Al proporcionar un entorno de evaluación riguroso, multiidioma y multiobjetivo, ROADMAPBENCH ofrece una herramienta necesaria para medir el progreso más allá de la resolución de problemas aislados, guiando la investigación futura hacia la mejora de la integración, la corrección y la fiabilidad en los flujos de trabajo de ingeniería del mundo real.