Resumen Técnico: SWE-INTERACT

Planteamiento del Problema

Los benchmarks actuales de ingeniería de software (SWE) de vanguardia evalúan principalmente a los agentes de codificación en tareas de implementación autónomas de un solo turno. En estos entornos, los agentes reciben requisitos completos y bien especificados de antemano y son evaluados por su capacidad para ejecutar una solución de forma independiente. Sin embargo, estudios a gran escala de las interacciones reales entre desarrolladores y agentes (por ejemplo, SWE-chat) revelan un contraste marcado: los flujos de trabajo reales rara vez son de un solo paso. En su lugar, implican bucles iterativos de múltiples turnos donde los usuarios proporcionan instrucciones vagas o incompletas inicialmente, inspeccionan el espacio de trabajo del agente y revelan progresivamente los requisitos mediante retroalimentación y revisiones dirigidas.

Los benchmarks existentes que intentan simular interacciones con el usuario en el bucle suelen simplificar el problema comenzando con un prompt razonablemente detallado o utilizando "usuarios" estáticos y no agénticos que no pueden inspeccionar código ni ejecutar comandos. Esto crea una brecha entre el rendimiento del benchmark y la realidad del descubrimiento interactivo de objetivos, donde los agentes deben inferir la intención, adaptarse a las restricciones evolutivas y refinar su propio trabajo previo sin una especificación completa al inicio.

Metodología: SWE-INTERACT

Los autores presentan SWE-INTERACT, un nuevo banco de pruebas diseñado para replantear los benchmarks de SWE como sesiones de codificación de largo alcance impulsadas por el usuario. La metodología consta de tres componentes principales:

1. Adaptación de Tareas

Los autores adaptaron 75 tareas de tres benchmarks de vanguardia existentes (SWE-bench Pro, SWE Atlas y DeepSWE). Estas eran originalmente tareas de un solo turno con especificaciones completas. Fueron convertidas en tareas de múltiples turnos eliminando del prompt inicial los requisitos detallados, dejando solo una descripción de alto nivel y vaga.

2. El Simulador de Usuario

Una innovación crítica es el simulador de usuario condicionado por persona, basado en datos de sesiones de codificación reales (SWE-chat).

• Persona: Modelada tras la persona del "Experto Quisquilloso" (Expert Nitpicker), caracterizada por una comunicación corta, directa e iterativa. Este usuario no escribe código, sino que critica implementaciones, pide detalles específicos de la API y revela requisitos uno por uno.
• Capacidades Agénticas: A diferencia de los simuladores estáticos anteriores, este agente de usuario tiene acceso a la shell al espacio de trabajo del agente. Puede ejecutar comandos (por ejemplo, git, grep, sed) para inspeccionar diffs, buscar en el codebase y verificar el trabajo del agente antes de proporcionar retroalimentación.
• Flujo de Interacción: El flujo de trabajo sigue un bucle de DESCUBRIMIENTO DE OBJETIVO → PLANIFICACIÓN → APROBACIÓN → IMPLEMENTACIÓN → REVISIÓN → ENTREGA. El usuario comienza con una solicitud vaga, revisa el plan del agente, inspecciona el espacio de trabajo y hace emerger progresivamente los requisitos latentes hasta que se realiza la entrega completa de la tarea.

3. Marco de Evaluación

Las tareas se ejecutan en el framework Harbor utilizando sandboxes contenedorizados.

• Verificación: El éxito se determina mediante el verificador de la tarea original (pruebas unitarias y rúbricas) de los benchmarks de origen, no por la aprobación del simulador de usuario. Esto aisla la dificultad de la interacción de la dificultad de la implementación.
• Métricas: El estudio rastrea tasas de resolución, pasos de interacción, uso de tokens, costo y modos de fallo específicos (por ejemplo, requisitos olvidados, errores técnicos).

Contribuciones Clave

1. Un Nuevo Banco de Pruebas: Una suite de 75 tareas de múltiples turnos con un harness que convierte los benchmarks estáticos en flujos de trabajo dinámicos impulsados por el usuario.
2. Simulador de Usuario Agéntico: Un marco para crear agentes de usuario realistas que emulan comportamientos de desarrolladores reales, incluyendo la inspección del espacio de trabajo y la crítica iterativa, yendo más allá de las simples llamadas a la API.
3. Análisis Exhaustivo: Un desglose detallado de las capacidades de los agentes en entornos de múltiples turnos, incluyendo análisis de trayectoria, puntuación de descubrimiento de objetivos y categorización de modos de fallo.

Resultados Experimentales

Los autores evaluaron varios modelos de vanguardia (GPT 5.5, Opus 4.8, Kimi K2.6, Gemini 3.5 Flash, Sonnet 4.6) tanto en líneas base de un solo turno como en las nuevas tareas de múltiples turnos de SWE-INTERACT.

Brecha de Rendimiento

• Tasas de Resolución: El fuerte rendimiento en un solo turno no se transfiere de manera fiable a los entornos de múltiples turnos. Mientras que los mejores modelos lograron aproximadamente un 50% de tasas de resolución en las líneas base de un solo turno, esto cayó a aproximadamente un 25–27% en el entorno de múltiples turnos.
• Consumo de Recursos: Las tareas de múltiples turnos requirieron significativamente más recursos. Los agentes realizaron de 3 a 4 veces más pasos, usaron de 2 a 4 veces más tokens e incurrieron en costos de 2 a 3.5 veces mayores por intento en comparación con las líneas base de un solo turno.
• Varianza de Modelos:
  • Mejores Desempeños: GPT 5.5 y Opus 4.8 comenzaron con fuerza incluso con instrucciones vagas, perseveraron ante la ambigüedad e integraron bien los requisitos, aunque todavía sufrieron de errores técnicos y requisitos olvidados.
  • Modelos Más Débiles: Modelos como Kimi K2.6 y Sonnet 4.6 tuvieron dificultades significativas bajo la ambigüedad, a menudo rindiéndose prematuramente, ignorando instrucciones o fallando en la refinación efectiva del código.

Descubrimiento de Objetivos vs. Implementación

• Planificación: Los modelos fuertes (por ejemplo, GPT 5.5) a menudo identificaron un alto porcentaje (>80%) de los objetivos latentes durante la fase inicial de planificación.
• Caída de Implementación: Hubo una caída significativa en la cobertura de objetivos al pasar del plan al primer punto de control de implementación, a menudo debido a errores técnicos o especificaciones omitidas.
• Recuperación: La mayoría de los modelos recuperaron la cobertura de objetivos en turnos subsiguientes a medida que el usuario revelaba los requisitos omitidos, pero la implementación final a menudo aún fallaba ante el verificador debido a errores técnicos o regresiones.

Modos de Fallo

Una auditoría de 2 de 287 trayectorias fallidas reveló las causas primarias del fallo:

• Errores de Implementación Técnica (~34%): El agente entendió el requisito pero introdujo errores de código.
• Requisitos Olvidados (~34%): El agente no implementó un requisito introducido en un turno anterior.
• Malinterpretación/Malas Suposiciones (~14%): El agente malinterpretó el requisito o tomó suposiciones incorrectas sin pedir aclaraciones.
• Requisitos de Usuario Faltantes (~12%): Casos donde el simulador no logró hacer emerger un requisito necesario (falsos negativos del benchmark).

Estudios de Ablación

• Impacto de la Persona: El uso de la persona "Experto Quisquilloso" (frente a una línea base neutral) hizo que las tareas fueran más difíciles y largas, aumentando los pasos de interacción en un 30–50% y disminuyendo las tasas de resolución para la mayoría de los modelos, lo que resalta la brecha entre las interacciones idealizadas y las realistas.
• Modelo del Simulador: La elección del modelo del simulador de usuario (GPT 5.5 vs. Opus 4.7) afectó significativamente el realismo. GPT 5.5 actuó como un crítico más riguroso, revelando requisitos a lo largo de más turnos e inspeccionando el espacio de trabajo más profundamente, lo que llevó a un mejor desempeño final del agente pero a trayectorias más largas.

Significado y Reivindicaciones

El artículo afirma que SWE-INTERACT mide un eje de capacidad ortogonal para el desarrollo de modelos de vanguardia: el descubrimiento interactivo de objetivos y el refinamiento iterativo con un usuario en el bucle.

Los autores argumentan que trabajar eficazmente con un usuario no es simplemente una versión más larga de la codificación autónoma, sino un conjunto de habilidades distinto. Los resultados sugieren que, si bien los modelos de vanguardia pueden perseverar bajo la ambigüedad y recuperar la mayoría de los objetivos previstos mediante la revisión, todavía luchan por mantener implementaciones correctas a medida que se acumula la retroalimentación. El artículo posiciona a SWE-INTERACT como un instrumento más afilado para estudiar esta capacidad específica, con el objetivo de guiar el desarrollo de agentes de codificación que puedan colaborar de manera más fiable en flujos de trabajo de ingeniería de software realistas.