SWE-Together: Evaluating Coding Agents in Interactive User Sessions

Resumen Técnico: SWE-Together

Planteamiento del Problema

Los benchmarks actuales para agentes de codificación, como la familia SWE-Bench y Terminal-Bench, dependen predominantemente de protocolos estáticos de un solo turno. En estas configuraciones, un agente recibe una descripción completa de la tarea de antemano y se evalúa únicamente en función de la corrección de su entrega de código final. Este enfoque no logra reflejar la realidad del apoyo en la ingeniería de software, que es inherentemente interactivo y de múltiples turnos. En los flujos de trabajo del mundo real, los usuarios revelan su intención de forma incremental, aclaran solicitudes ambiguas, refinan los requisitos y proporcionan retroalimentación correctiva a lo largo de varios turnos.

Los benchmarks existentes sufren dos desajustes primarios con la práctica:

1. Diseño de Tareas: Tratan las tareas como instrucciones fijas, ignorando que la información relevante para la tarea suele estar distribuida en múltiples turnos y que las solicitudes iniciales son frecuentemente incompletas.
2. Métricas de Evaluación: Se centran exclusivamente en el éxito de la tarea final, fallando al capturar el costo de interacción. Dos agentes pueden lograr el mismo puntaje final, pero uno puede tener éxito a partir de una solicitud vaga mientras que el otro requiere especificaciones detalladas extensas y retroalimentación correctiva repetida.

Además, construir un benchmark que preserve la interacción realista del usuario asegurando la verificabilidad es un desafío. Los registros de conversación brutos suelen carecer de estados de repositorio reproducibles, objetivos identificables o resultados observables. Adicionalmente, simplemente reproducir los turnos originales del usuario para un nuevo agente es defectuoso porque los turnos posteriores del usuario deben estar condicionados por la trayectoria del nuevo agente para evitar la deriva de la interacción, pero deben permanecer anclados a la intención del usuario original.

Metodología

Para abordar estos desafíos, los autores presentan SWE-Together, un benchmark que comprende 109 tareas a nivel de repositorio reconstruidas a partir de sesiones reales de usuario-agente de codificación. La metodología consta de tres componentes principales:

1. Pipeline de Construcción de Sesión-a-Tarea

Los autores curan 109 tareas a partir de 11,260 sesiones registradas provenientes de cuatro conjuntos de datos ascendentes: DataClaw, Pi-staging, Hyperswitch y SWE-chat. El pipeline de construcción involucra tres etapas:

• Filtrado de Elegibilidad Determinista: Las sesiones brutas se filtran para retener aquellas con interacciones genuinas de múltiples turnos, ediciones de código concretas y contextos de repositorio recuperables. Se excluyen las sesiones donde el usuario humano realizó el cambio final para asegurar que el agente realizó un trabajo sustantivo.
• Tamizaje de Viabilidad: Un juez basado en LLM examina los candidatos para asegurar que el trabajo de codificación pueda reconstruirse como una tarea autónoma y ejecutable localmente. Se rechazan las sesiones que dependen de estados externos (p. ej., despliegues de servicios en vivo, credenciales privadas).
• Construcción de la Tarea: Un orquestador de sandbox convierte las sesiones viables en paquetes de benchmark ejecutables. Esto incluye la restauración del repositorio en un commit fijado, la definición de artefactos de verificador deterministas y la generación de prompts de simulación de usuario específicos para la tarea.

2. Simulador de Usuario Anclado y Condicional al Estado

Para reproducir las interacciones con nuevos agentes, los autores desarrollan un simulador de usuario reactivo basado en LLM. A diferencia de las reproducciones estáticas, este simulador:

• Se Condiciona a la Trayectoria: Observa el último turno del agente evaluado, los cambios en el repositorio y el tiempo transcurrido.
• Se Ancla a la Intención Original: Utiliza un análisis precomputado de la sesión original (objetivos, restricciones y condiciones de intervención) para asegurar que la simulación permanezca fiel a las metas del usuario original.
• Política de Decisión Condicional al Estado: El simulador decide si intervenir (enviar un mensaje) o permanecer en silencio (no-op) basándose en si la trayectoria actual del agente amerita retroalimentación de acuerdo con la lógica de la sesión original. Esto evita intervenciones prematuras o irrelevantes.

3. Protocolo de Evaluación Conjunta

La evaluación mide dos dimensiones distintas:

• Corrección de la Tarea: El estado final del repositorio se califica contra una rúbrica agnóstica a la implementación y congelada. Esta rúbrica se deriva en la Fase 1 (offline) de la sesión original y el parche de referencia, y luego se aplica en la Fase 2 a los repositorios candidatos. La calificación combina verificaciones ejecutables deterministas con un juez de rúbrica agéntico para evaluar la completitud del comportamiento en lugar de la similitud del código.
• Diagnósticos de Interacción:
  • Corrección del Usuario: Cuantifica la dirección correctiva provocada por el agente. Cuenta las correcciones explícitas y los "empujones" (nudges) ponderados (retroalimentación más suave) proporcionados por el simulador.
  • Cobertura de la Intención: Una métrica diagnóstica que mide qué tan fielmente el simulador preserva las intenciones y el alcance del usuario original a través de diferentes ejecuciones del agente.

Contribuciones Clave

1. Benchmark SWE-Together: Un benchmark de 109 tareas reconstruidas a partir de sesiones reales de múltiples turnos entre usuario y agente, que cuenta con un pipeline que convierte sesiones registradas en tareas verificables y en entornos controlados (sandboxed).
2. Simulador de Usuario Condicional al Estado: Un simulador de LLM anclado que preserva las intenciones originales del usuario y el orden de intervención, adaptando el tiempo de la retroalimentación a la trayectoria específica de cada agente evaluado.
3. Protocolo de Evaluación Conjunta: Un marco que califica la corrección del repositorio final frente a rúbricas fijas mientras caracteriza las trayectorias de interacción mediante Corrección del Usuario y Cobertura de la Intención, yendo más allá de las simples métricas de aprobado/fallido.

Resultados

Los autores evaluaron siete modelos de codificación de frontera en el benchmark de 109 tareas utilizando el harness opencode con dos réplicas por tarea.

• Ranking de Desempeño: Claude Opus 4.8 logró el mayor desempeño en todas las métricas (pass@1: 63%, Tasa de Resolución Estable: 59%, Puntuación Media del Juez: 0.801). GPT-5.5 ocupó el segundo lugar (Juez Medio: 0.763), seguido de Claude Opus 4.6. Los modelos más débiles fueron DeepSeek-V4-Pro y MiniMax-2.7.
• Capacidad vs. Intervención: Se observó una fuerte correlación negativa entre la capacidad del modelo y la Corrección del Usuario (correlación de Pearson de -0.92 con pass@1). Los modelos más fuertes requirieron significativamente menos intervenciones correctivas para alcanzar niveles de desempeño comparables (por ejemplo, Claude Opus 4.8 requirió 1.38 correcciones en promedio, mientras que MiniMax-2.7 requirió 2.17).
• Eficiencia: GPT-5.5 fue el más eficiente, requiriendo la menor cantidad de tokens (29.9k) y tiempo de ejecución (10.7 min) por tarea mientras mantenía una alta capacidad.
• Fidelidad del Simulador: La Cobertura de la Intención se mantuvo estable en todos los cohortes de modelos (puntajes entre 0.70–0.72), indicando que el simulador preservó consistentemente las intenciones originales independientemente del comportamiento del agente.
• Indistinguibilidad Humana: En una prueba de tipo Turing, los anotadores humanos no pudieron distinguir estadísticamente entre las trayectorias de usuario simuladas y las reales (tasa de éxito del 46%, con un intervalo de confianza que incluye el 50%).

Significancia y Reivindicaciones

El artículo afirma que SWE-Together redefine la evaluación de agentes de codificación de tareas de un solo paso a sesiones reproducibles de múltiples turnos, ofreciendo una evaluación más realista de la experiencia del usuario.

• Más allá de la Corrección Final: Los resultados sugieren que evaluar agentes únicamente por el código final es insuficiente; la cantidad de dirección correctiva requerida es un indicador crítico de la capacidad y la experiencia del usuario.
• Interacción Realista: Al derivar tareas de sesiones reales y utilizar un simulador condicional al estado, el benchmark captura la naturaleza dinámica de la ingeniería de software donde los requisitos evolucionan.
• Comparación Confiable: La estabilidad de la Cobertura de la Intención y la indistinguibilidad de las trayectorias simuladas de las reales validan la capacidad del benchmark para proporcionar evaluaciones justas y comparables entre diferentes cohortes de modelos.

Los autores concluyen que SWE-Together demuestra la importancia de evaluar los agentes de codificación no solo por si completan una tarea, sino por cuánta guía humana requieren para hacerlo, alineando así las métricas del benchmark más estrechamente con los flujos de trabajo reales de los usuarios.