ES
Una opción para escalar ayuda a los agentes a detenerse ante obstáculos de reparación
Knowing When to Stop: The Evidence-Action Gap in Coding Agents · arXiv:2610.31895
En palabras sencillas
Los agentes de programación pueden encontrarse con problemas que no pueden resolver por sí solos, por ejemplo, cuando el entorno de reparación rechaza los cambios. Este artículo presenta Impasse Bench, un conjunto de tareas de reparación de software con obstáculos controlados, para medir si los agentes actúan de forma razonable a medida que reúnen pistas.
En las tareas evaluadas con obstáculos persistentes, la mayoría de las ejecuciones reunió pruebas suficientes, pero muchas agotaron los 80 pasos. Añadir una forma de pedir ayuda redujo estos finales en las ejecuciones evaluadas, aunque algunos agentes también pidieron ayuda cuando un fallo temporal se habría resuelto al volver a intentarlo.
La investigación
Cuando las herramientas de un agente de programación muestran que el entorno está bloqueando una reparación, ¿cómo podemos saber si ha reunido pruebas suficientes para detenerse y si actuará en consecuencia?
Una medida útil debe distinguir entre derivar el caso antes de tiempo y seguir intentándolo después de que las pruebas hayan dejado claro que el obstáculo persiste.
Impasse Bench evalúa a los agentes de programación según las pruebas que reúnen, y las pruebas emparejadas muestran que una opción para escalar puede frenar los intentos excesivos ante obstáculos persistentes.
Los autores emparejaron ejecuciones con y sin una herramienta para escalar el problema e instrucciones para derivar obstáculos persistentes de infraestructura.
En 4.271 pares con pruebas suficientes en ambas condiciones, la media de llamadas válidas a herramientas después de ese punto bajó de 38,9 a 17,5.
En el grupo completo de 4.344 pares con obstáculos persistentes, las ejecuciones que terminaron al llegar al límite de 80 pasos o tras tres respuestas consecutivas solo en texto bajaron del 33,5% al 6,6%.
Esto respalda la conclusión de que una opción para derivar el problema puede ayudar a los agentes a detenerse tras reconocer estos obstáculos, aunque algunos modelos la usaron pocas veces.
Estos resultados proceden de fallos controlados en tareas de reparación aisladas y de evaluadores definidos. No demuestran que los agentes sean seguros en producción ni fuera de las conductas y los entornos medidos.
Qué muestran las pruebas
- Cuándo detenerse
Impasse Bench es un conjunto de tareas de reparación de software que mide si los agentes de programación actúan de acuerdo con las respuestas de sus herramientas cuando fallos del entorno bloquean el avance.
Las tareas siguen teniendo solución, pero un fallo controlado puede impedir una reparación, limitar la verificación o desaparecer al volver a intentarlo. Los autores llaman brecha entre evidencia y acción a la discrepancia entre las pruebas disponibles y la conducta del agente: puede seguir intentándolo cuando las pistas indican que necesita ayuda externa o detenerse antes de probar opciones razonables de recuperación.
- Vincular las acciones con las pruebas
Para distinguir esos dos errores, los autores asocian cada fallo con una ficha destinada solo a los evaluadores que define las señales esperadas, las comprobaciones, los intentos de recuperación y la respuesta adecuada.
Un anotador basado en reglas usa la ficha y las respuestas registradas de las herramientas para marcar la primera ronda en que se han reunido pruebas suficientes. Ese punto sirve de referencia para juzgar lo que ocurre después; no afirma que reparar sea imposible ni que se hayan agotado todas las opciones de recuperación.
- La evidencia solía llegar primero
Con la interfaz básica, el 98,6% de las 4.344 ejecuciones con obstáculos persistentes reunió pruebas suficientes, pero el 33,5% alcanzó el límite de 80 pasos. Todas las ejecuciones de este grupo que agotaron el presupuesto ya habían reunido pruebas suficientes.
Esto indica que, en estos casos evaluados, muchos agentes no se detuvieron después de reconocer el obstáculo. El resultado es un agregado de ocho configuraciones de modelos, no una descripción de cada modelo ni de cada ejecución.
- Derivar el problema cambia la conducta
Los autores compararon ejecuciones emparejadas con y sin una herramienta para escalar el problema e instrucciones para derivar obstáculos persistentes. En el grupo completo con obstáculos persistentes, las ejecuciones que terminaron al llegar al límite de 80 pasos o tras tres respuestas consecutivas solo en texto bajaron del 33,5% al 6,6%.
Entre los pares con pruebas suficientes en ambas condiciones, la media de llamadas válidas a herramientas posteriores a ese punto bajó de 38,9 a 17,5. Los resultados respaldan la idea de que una opción explícita para derivar el problema puede ayudar a los agentes a actuar según las pruebas en estas tareas.
- Detenerse bien requiere criterio
Los resultados también muestran por qué no basta con detenerse antes. Diez ejecuciones con la herramienta para escalar derivaron el caso durante un fallo temporal del entorno aislado que se resolvió tras dos llamadas fallidas; todas tenían parches vacíos y no superaron las pruebas objetivo.
En una comparación independiente del sistema de evaluación, la tasa de éxito de reparación fue mayor después de una restauración automatizada cuando se añadieron juntos los recordatorios basados en pruebas y una plantilla de informe.
Las valoraciones de los informes también mostraron que una derivación puede identificar el obstáculo y dejar poco claro el avance del agente.
Detalles
- Autores del paper original
- Tianyu Chen, Xinran Zhao, Vijay Viswanathan, Shoubin Yu, Mingyuan Zhou
- Enviado a arXiv
- Licencia
- CC BY 4.0