SWE-Shift: los agentes de programación tropiezan si el proyecto cambia

Qué mide SWE-Shift

Los benchmarks de programación a escala de repositorio, como SWE-bench, dan por hecho que la tarea y su entorno no cambian una vez empieza la ejecución, según Victor Shea-Jay Huang y otros nueve autores. En el desarrollo real, sostienen, el código, las dependencias, el estado de ejecución y los requisitos pueden cambiar mientras el agente sigue trabajando.

SWE-Shift mide precisamente eso, según Huang. Contiene 120 escenarios repartidos en 12 familias de cambio: actualizaciones de código y dependencias, colaboración, estado de ejecución y de sesión, efectos externos, objetivos revisados y evidencia obsoleta o mal vinculada. Cada escenario se evalúa en nueve posiciones de intervención, lo que suma 1.080 casillas de evaluación por sistema.

Según Huang, cada cambio debe ser relevante y recuperable. Relevante significa que ignorarlo puede invalidar una continuación que habría salido bien; recuperable, que tras el cambio sigue existiendo al menos una forma válida de completar la tarea con las herramientas a las que accede el agente.

Mismo punto de partida, dos caminos

En un punto programado, según Huang, el sistema guarda el historial visible para el agente, el espacio de trabajo, el estado del controlador, las herramientas disponibles, la configuración y los contadores de ejecución, y restaura ese estado dos veces. Hasta ahí, las dos ramas comparten historial y espacio de trabajo; solo después de la intervención pueden divergir.

El criterio de éxito es estricto, según Huang: no basta con pasar las pruebas originales. Según el escenario, también hay que conservar el comportamiento que sigue siendo válido, seguir el objetivo o la interfaz vigentes, evitar efectos prohibidos u obtener evidencia válida para el estado actual. Fallar cualquier comprobación aplicable invalida la continuación.

Todos empeoran, también el mejor

Los 17 sistemas evaluados tienen menos éxito en la continuación desplazada que en la limpia, según Huang y sus coautores. El caso más visible es GPT-6 Astra, el de mayor éxito sin cambios, cuya caída recoge la tabla.

Según Huang, la brecha varía además entre familias de cambio y posiciones de intervención: en las intervenciones tardías, el éxito emparejado baja en unos sistemas y sube en otros. Para los autores, eso apunta a que la robustez ante cambios a mitad de ejecución capta un comportamiento que el éxito en tareas estáticas no revela.

Donde no acierta ninguno

Los cambios de herramienta o de sesión y la evidencia obsoleta dejan el éxito emparejado en el 0 % para los 17 sistemas, según Huang. En el primer caso, una herramienta, una autorización, un esquema o el protocolo de sesión cambian después de empezar la ejecución; en el segundo, la evidencia se refiere a un estado ya superado.

Los límites del estudio

Huang y sus coautores sostienen que la evaluación cubre 120 escenarios diseñados, algunos con raíces de tarea compartidas, y un solo cambio por ejecución. Los controles de diagnóstico abarcan cinco sistemas, el azar de los modelos queda sin controlar y el presupuesto de tokens tras la bifurcación es fijo.