ES
Pruebas revelan las carencias de los modelos que crean software para agentes de programación
Doc2Harness: Benchmarking LLMs on Long-Horizon Harness Engineering of Coding Agents · arXiv:2610.20344
En palabras sencillas
Doc2Harness evalúa si un modelo de lenguaje puede crear el software que rodea a un agente de programación. Ese software, llamado arnés, administra herramientas, permisos, el estado guardado de una sesión y la recuperación ante fallos.
Un modelo construye un candidato y, después, un modelo simulado mediante scripts lo pone a prueba en sesiones. En el estudio de 19 modelos, incluso los arneses del modelo con mejor puntuación fallaron muchas pruebas de comportamiento, en promedio entre tres construcciones. Esto mide el comportamiento del software creado, no el éxito en tareas reales de programación.
La investigación
Cuando las pruebas de agentes de programación mantienen fijo el software que los rodea, dejan una pregunta concreta sin respuesta: ¿puede un modelo crear ese software bien?
El arnés administra las herramientas, el contexto, los permisos, el estado de la sesión y la recuperación, y todo ello condiciona lo que puede hacer el agente. Doc2Harness permite poner a prueba esa capacidad de construcción.
Doc2Harness es una prueba en dos etapas: los modelos construyen arneses para agentes de programación y luego sesiones mediante scripts puntúan la proporción de pruebas de comportamiento que supera cada construcción congelada.
Cada modelo construyó tres candidatos a partir de un documento de desarrollo y un esqueleto que solo definía interfaces. Un modelo simulado mediante scripts guio cada candidato congelado en sesiones de prueba, y las comprobaciones evaluaron su comportamiento. La tasa de aprobación es la proporción de casos superados, sin contar los controles positivos.
Entre 19 modelos, los candidatos de GPT-6 Astra promediaron una tasa de aprobación del 53.05% y los de Hy3, del 27.44%, en 328 casos y tres construcciones.
Esta dispersión, junto con los fallos incluso del líder, respalda la conclusión de los autores de que el conjunto distinguió a los modelos evaluados sin saturarse.
Los candidatos se congelaron después de una comprobación de forma, así que las puntuaciones no muestran si los modelos podrían mejorar un arnés con comentarios sobre su comportamiento. Las pruebas las ejecutó un modelo simulado mediante scripts, por lo que no miden el éxito en tareas reales de programación.
Qué muestran las pruebas
- Una capacidad de construcción sin evaluar
Doc2Harness es un benchmark en dos etapas que evalúa si los modelos de lenguaje grandes pueden crear el software que rodea a los agentes de programación. Su puntuación es la proporción de casos de prueba de comportamiento que supera cada arnés construido; sirve como medida indirecta de la capacidad del modelo para crearlo.
Las pruebas existentes de agentes de programación suelen mantener fijo este software y medir la finalización de tareas, por lo que no evalúan la capacidad de construirlo.
- Construcción a partir de documentos de comportamiento
Durante la construcción, el modelo trabaja en un entorno fijo y recibe un documento de desarrollo que describe el comportamiento del candidato, además de un esqueleto inicial con interfaces, pero sin implementación. Escribe un candidato completo en un contenedor aislado.
Una comprobación de forma confirma que el candidato se compile y se instale, tenga los comandos y las interfaces requeridos y no contenga elementos provisionales; no ejecuta pruebas de comportamiento. Los candidatos que la superan quedan congelados.
- Pruebas de sesiones completas mediante scripts
En la segunda etapa, un modelo simulado mediante scripts guía cada arnés congelado a través de una sesión completa por cada caso de prueba. Las comprobaciones examinan las solicitudes enviadas al modelo, los archivos en el disco, el código de salida del proceso y la salida de los comandos.
Algunos casos incluyen controles positivos que comprueban si se puede observar el comportamiento y sus efectos. Si falla un control, el caso también falla; los controles no cuentan en el denominador de la tasa de aprobación.
- Las puntuaciones muestran una amplia dispersión
Los autores evaluaron 19 modelos de vanguardia de 11 proveedores, construyeron tres candidatos independientes por modelo y los puntuaron en 328 casos de prueba. La tasa de aprobación es la proporción de casos superados, sin incluir los controles positivos en el denominador; la tasa de cada modelo es el promedio de sus tres construcciones.
GPT-6 Astra lideró con un 53.05%, frente al 27.44% de Hy3, así que incluso los candidatos del líder fallaron en casi la mitad de los casos. La dispersión indica que el conjunto pudo distinguir a los modelos evaluados sin saturarse.
- El orden general oculta variaciones
El orden general no se mantiene en todas las partes del conjunto de pruebas. En seis categorías principales, cada una con al menos 20 casos, los rankings de los modelos cambiaron hasta 16 puestos.
GPT-6 Astra lideró cuatro categorías; Grok 4.7 y Qwen3.8 Max lideraron las otras dos. Como las categorías incluyen casos distintos y tienen tamaños diferentes, estos cambios matizan el ranking general, pero no aíslan la capacidad específica de cada categoría.
- Más módulos se asocian con puntuaciones más bajas
Un análisis separado del código fuente abarcó los 57 arneses candidatos puntuados. Tras ajustar estadísticamente según las líneas de código, los autores encontraron una correlación parcial de −0.423 entre el número de módulos y la tasa de aprobación. Al repetir el análisis dejando fuera cada modelo por turno, la asociación siguió siendo negativa, entre −0.484 y −0.309.
En este conjunto, un mayor número de módulos tendía a ir acompañado de puntuaciones más bajas, pero el análisis no demuestra que el número de módulos causara la diferencia.
Detalles
- Autores del paper original
- Yuyao Ge, Shenghua Liu, Peizhong Gao, Chendi Ge, Chenxu Liu
- Enviado a arXiv
- Licencia
- CC BY 4.0