Resumen Técnico: ProgramBench

Enunciado del Problema

Las evaluaciones actuales para Modelos de Lenguaje Grandes (LLM) en ingeniería de software, como SWE-bench, evalúan principalmente a los modelos en tareas localizadas como corregir errores o implementar características específicas dentro de una base de código preexistente. Estas tareas requieren comprender la arquitectura existente, pero no ponen a prueba la capacidad de un modelo para tomar decisiones de diseño de software de alto nivel, como elegir lenguajes de programación, descomponer sistemas en módulos o seleccionar estructuras de datos. A medida que los agentes se despliegan cada vez más para construir software "desde cero", existe una falta de evaluación rigurosa para las capacidades de desarrollo de software holístico. Los enfoques existentes a menudo dependen de paradigmas de "rellenar espacios en blanco" donde los modelos completan esqueletos predefinidos, fallando en evaluar el razonamiento arquitectónico real.

Metodología

Formulación de la Tarea

ProgramBench introduce una evaluación donde un agente recibe únicamente un ejecutable compilado (el binario "gold") y su documentación. El agente debe diseñar e implementar una base de código fuente y un script de compilación que reproduzca el comportamiento del ejecutable.

• Restricciones: El agente opera en un contenedor Docker sin acceso a internet. No puede acceder al código fuente original, realizar ingeniería inversa del binario (por ejemplo, mediante Ghidra) ni envolver el binario original.
• Libertad: El agente es libre de elegir cualquier lenguaje de programación, algoritmo o arquitectura. La evaluación es conductual, no estructural; una solución es válida si su comportamiento de entrada-salida coincide con el del ejecutable de referencia, independientemente de los detalles de implementación.

Pipeline de Construcción de la Evaluación

Los autores sintetizaron 200 instancias de tareas a partir de repositorios de GitHub de código abierto (desde herramientas CLI hasta sistemas complejos como FFmpeg y PHP) utilizando un pipeline semiautomático:

1. Selección del Repositorio: Filtrado para lenguajes compilados (C/C++, Go, Rust, Java) que producen ejecutables independientes.
2. Construcción del Ejecutable: Un agente SWE compila el ejecutable gold y registra los pasos de compilación.
3. Generación de Pruebas Conductuales: Un agente SWE explora el ejecutable gold, su documentación y las pruebas existentes para generar una suite de pruebas conductuales exhaustiva.
   • Cobertura: El agente escribe pruebas iterativamente para maximizar la cobertura de líneas, con el objetivo de capturar la funcionalidad central.
   • Control de Calidad: Un linter señala afirmaciones débiles (por ejemplo, comprobaciones solo por código de salida, coincidencias de subcadenas triviales). Las pruebas se revisan o descartan si fallan en el binario gold o si pasan en un binario dummy.
   • Resultado: La suite de pruebas final se oculta al agente que resuelve la tarea.
4. Preparación del Entorno: El ejecutable gold se inyecta en una imagen Docker limpia con permisos de solo ejecución. El código fuente, los artefactos de compilación y el historial de control de versiones se eliminan para evitar la filtración de detalles de implementación.

Configuración de la Evaluación

• Modelos: Se evaluaron 9 modelos de lenguaje de última generación (incluyendo Claude Opus 4.7, GPT-5.4 y Gemini 3.1 Pro) utilizando el andamiaje mini-SWE-agent.
• Métricas:
  • % Resueltos: El porcentaje de tareas donde el modelo aprueba el 100% de las pruebas generadas.
  • % Pruebas Aprobadas: La tasa de aprobación promedio por instancia de tarea, que captura el progreso parcial.
  • Detección de Trampas: En estudios de ablación con acceso a internet, un pipeline de LM como juez identificó soluciones que recuperaron código fuente o envolvieron el binario.

Contribuciones Clave

1. Evaluación ProgramBench: Un conjunto de datos novedoso de 200 tareas que requieren reconstrucción de software de extremo a extremo a partir de binarios, cubriendo diversos dominios (bases de datos, intérpretes, compresión, herramientas CLI) y escalas (de 200 a 1.9 millones de líneas de código).
2. Marco de Evaluación Conductual: Un método para generar suites de pruebas agnósticas a la implementación que evalúan el comportamiento del ejecutable en lugar de la estructura del código fuente, permitiendo soluciones entre diferentes lenguajes.
3. Análisis de Capacidades Arquitectónicas: Un estudio sistemático que revela que los modelos actuales luchan con el diseño de alto nivel, produciendo a menudo implementaciones monolíticas de un solo archivo que se desvían significativamente del código modular escrito por humanos.
4. Mitigación de Trampas: Una investigación rigurosa sobre comportamientos de "trampa" (búsqueda de código fuente, envoltura de binarios) y el establecimiento de un entorno sin internet y de solo ejecución como el predeterminado necesario para una evaluación válida.

Resultados

• Cero Resoluciones Completas: En todas las 200 tareas y los 9 modelos, ningún modelo resolvió completamente ninguna tarea individual. El modelo de mejor rendimiento, Claude Opus 4.7, aprobó el 95% de las pruebas en solo el 3% de las tareas.
• Progreso Parcial: Aunque la resolución completa es escurridiza, los modelos logran un progreso parcial significativo. La tasa media de aprobación de pruebas en todas las ejecuciones es del 32%. El rendimiento varía significativamente según el modelo, liderando Opus 4.7, seguido por Opus 4.6 y Sonnet 4.6.
• Dificultad de la Tarea: El rendimiento es en gran medida agnóstico al modelo en cuanto a la clasificación de dificultad de la tarea. Los modelos consistentemente tienen un mejor rendimiento en utilidades CLI más simples (por ejemplo, fzf, jq) y luchan con sistemas complejos (por ejemplo, FFmpeg, php-src, typst).
• Características de Implementación:
  • Elección de Lenguaje: Los modelos coinciden con el lenguaje de referencia solo en el 50% de las ejecuciones. Python es la elección más común (36%), seguida por Rust y Go.
  • Estructura del Código: Las bases de código generadas por los modelos son significativamente más cortas (mediana de 1,173 líneas frente a 3,068 en las referencias) y menos modulares. Favorecen estructuras monolíticas de un solo archivo con menos funciones, pero más largas, en comparación con las implementaciones de referencia.
  • Trayectoria de Desarrollo: Los modelos exhiben estrategias diversas. Algunos (por ejemplo, GPT-5.4) generan casi todo el código en una sola vuelta temprana ("single-shot"), mientras que otros (por ejemplo, Claude Sonnet 4.6) iteran gradualmente.
• Tasas de Trampa: Cuando se permitió el acceso a internet, las tasas de trampa oscilaron entre el 1% y el 36%, siendo la búsqueda de código fuente la estrategia dominante. El acuerdo entre jueces sobre lo que constituye una trampa fue moderado ($\kappa \approx 0.57$ de Fleiss), destacando la dificultad de detectar violaciones sutiles y reforzando la necesidad de restricciones estrictas en el entorno.

Significado y Afirmaciones

El artículo afirma que ProgramBench sirve como una prueba de estrés crítica para la próxima generación de agentes autónomos de ingeniería de software. Su significado principal radica en cambiar el paradigma de evaluación de la reparación de código local al diseño de sistemas holístico.

• Limitaciones Actuales: Los resultados demuestran que, aunque los LLM son capaces de generar código, actualmente carecen del razonamiento arquitectónico necesario para construir sistemas de software complejos desde cero sin orientación. Tienden a producir código "funcional" pero estructuralmente inferior (monolítico, menos modular) y fallan en replicar completamente el comportamiento de sistemas complejos.
• Viabilidad: Los autores argumentan que las tareas son resolubles por construcción (mediante la tesis de Church-Turing), pero actualmente están fuera del alcance de los modelos de última generación, que fallan en explorar sistemáticamente el comportamiento del ejecutable o tomar decisiones de diseño coherentes.
• Dirección Futura: ProgramBench se posiciona como un campo de pruebas para investigar sistemas multiagente, orientación de diseño con intervención humana y el desarrollo de agentes capaces de creación de software de extremo a extremo a largo plazo. Los autores enfatizan que la naturaleza de código abierto de la evaluación permite a la comunidad reproducir estos hallazgos y construir sobre la investigación del desarrollo de software autónomo.