Resumen Técnico: SWE-Doctor

Declaración del Problema

Los agentes de ingeniería de software basados en Modelos de Lenguaje Extensos (LLM) se utilizan cada vez más para resolver problemas de software mediante la generación de parches a partir de informes de errores y repositorios de código. Un componente crítico de estos agentes es el Test de Reproducción de Errores (BRT, por sus siglas en inglés), que convierte informes de errores textuales en retroalimentación ejecutable. Si bien estudios recientes han demostrado que los BRTs son efectivos para la validación de parches (verificar si un parche generado pasa una prueba), no está claro si los BRTs pueden guiar eficazmente la etapa de generación de parches en sí misma, la cual es más central y desafiante.

Un estudio preliminar realizado por los autores revela que utilizar directamente generadores de BRT avanzados para guiar la generación de parches no es beneficioso. Se identificaron dos modos de falla primarios:

1. Limitaciones de Falla-a-Paso (F→P): Incluso cuando un BRT reproduce con éxito un error (falla en el código original, pasa en el código corregido), a menudo cubre solo una manifestación del problema reportado. Esto lleva a los agentes a producir parches parciales que satisfacen la prueba específica pero dejan sin abordar otros requisitos de comportamiento declarados.
2. Engaño de Falla-a-Falla (F→F): Cuando un BRT generado falla tanto en el código original como en el repositorio corregido de referencia (ground-truth), utilizarlo como un objetivo directo de paso/falla confunde al agente, ya que la prueba no captura correctamente el comportamiento que dispara el error o el comportamiento esperado de la corrección.

Metodología: SWE-Doctor

Para abordar estas limitaciones, los autores proponen SWE-Doctor, un agente de resolución de problemas de software que guía la generación de parches mediante la generación de BRT multifacética y el diagnóstico basado en tiempo de ejecución. El sistema opera a través de un flujo de trabajo de tres etapas:

1. Generación de BRT Multifacética

En lugar de generar un solo test por error, SWE-Doctor descompone el informe del error en múltiples requisitos de comportamiento (por ejemplo, salidas específicas, condiciones de excepción o necesidades de compatibilidad).

• Extracción de Requisitos: Un LLM extrae comportamientos observables del informe del error.
• Generación Dirigida: Para cada requisito, el agente realiza una localización de errores a nivel de requisito para identificar archivos fuente y funciones relevantes. Luego, genera un BRT dirigido mediante un ciclo de generar–ejecutar–refinar, asegurando que la prueba falle específicamente para el requisito previsto.
• Filtrado (Screening): Los BRTs se filtran para asegurar que fallen solo después de ejercer el código localizado, descartando errores ambientales.

2. Diagnóstico de Errores Basado en Tiempo de Ejecución

En lugar de tratar los BRTs como simples señales de paso/falla, SWE-Doctor los ejecuta bajo un depurador para construir registros de diagnóstico estructurados.

• Proceso de Depuración: Un agente de depuración basado en LLM interactúa con un depurador de tiempo de ejecución (por ejemplo, PDB para Python, Delve para Go) para inspeccionar trazas de pila (stack traces), valores de tiempo de ejecución y rutas de ejecución.
• Registro de Diagnóstico: El sistema sintetiza un registro estructurado que contiene:
  • Ubicaciones de fallas sospechosas.
  • Síntomas de falla en tiempo de ejecución (excepciones, aserciones).
  • Rutas de propagación de la falla.
  • Impactos potenciales del parche en el código relacionado.
  • Direcciones de corrección sugeridas.
• Validación: Una "verificación de fundamentación en tiempo de ejecución" asegura que el diagnóstico se base en la retroalimentación real de la ejecución y no se infiera únicamente de texto, rechazando conclusiones que carezcan de evidencia de tiempo de ejecución.

3. Generación de Parches Guiada por Múltiples Fuentes

La etapa final utiliza un agente estándar (mini-SWE-agent) pero aumenta su contexto con la información de las etapas anteriores.

• Referencia Cruzada: El agente recibe un contexto unificado que combina los requisitos extraídos, la localización a nivel de requisito y los registros de diagnóstico basados en tiempo de ejecución. Se le instruye a realizar una referencia cruzada de estas fuentes para decidir las ubicaciones de edición.
• Verificación de Completitud: Antes de la entrega, el agente realiza una verificación a nivel de prompt para verificar que el parche generado aborde todos los requisitos de comportamiento extraídos y sea consistente con el diagnóstico de tiempo de ejecución, reduciendo la probabilidad de parches parciales.

Contribuciones Clave

1. Estudio Preliminar: El artículo presenta un estudio que demuestra que utilizar directamente los generadores de BRT de vanguardia como objetivos de generación de parches no mejora las tasas de resolución y puede degradar el rendimiento debido a parches parciales y pruebas engañosas.
2. Marco de Trabajo SWE-Doctor: La propuesta de una nueva arquitectura de agente que cambia el paradigma de "BRT como un objetivo" a "BRT como una sonda de diagnóstico", utilizando la generación de pruebas multifacética y el diagnóstico basado en tiempo de ejecución.
3. Evaluación Exhaustiva: Evaluación integral en dos benchmarks (SWE-bench Verified y SWE-bench Pro) y cinco backends de LLM de cuatro proveedores.
4. Código Abierto: Lanzamiento público de la implementación de SWE-Doctor y los datos asociados para apoyar la reproducibilidad.

Resultados Experimentales

La evaluación se realizó sobre problemas de corrección de errores de Python de SWE-bench Verified (436 problemas) y SWE-bench Pro (107 problemas), utilizando cinco backends de LLM (GPT-5.4, GPT-5.4-mini, Claude Sonnet 4.6, DeepSeek-V4-Pro, MiMo-V2.5-Pro).

• Efectividad General: SWE-Doctor superó consistentemente a dos bases sólidas (mini-SWE-agent y live-SWE-agent) en todas las 10 combinaciones de LLM–benchmark.
  • SWE-bench Verified: Logró una tasa de resolución promedio del 75.7% (frente al 73.7% y 71.8% de las bases de comparación).
  • SWE-bench Pro: Logró una tasa de resolución promedio del 59.4%, mejorando sobre las bases de comparación entre 8.0 y 8.9 puntos porcentuales.
• Resoluciones Únicas: SWE-Doctor resolvió de forma única más del doble de problemas que cualquiera de las bases de comparación (108 problemas únicos totales frente a 51 y 38 para las bases), lo que indica que expande el conjunto de problemas resolubles.
• Análisis de Resultados de BRT:
  • Problemas F→P: SWE-Doctor mejoró las tasas de resolución en 8.3 puntos porcentuales en SWE-bench Pro, atribuido a que la generación de BRT multifacética evita los parches parciales.
  • Problemas F→F: SWE-Doctor mejoró las tasas de resolución en 9.2 puntos porcentuales en SWE-bench Pro, atribuido al diagnóstico basado en tiempo de ejecución que extrae información útil de las pruebas fallidas en lugar de tratarlas como callejones sin salida.
• Estudio de Ablación: Eliminar la etapa de generación de BRT multifacética o la etapa de diagnóstico basado en tiempo de ejecución redujo el rendimiento entre 8.0 y 10.0 puntos porcentuales, confirmando que ambos componentes son esenciales.
• Estabilidad: SWE-Doctor demostró una menor varianza en ejecuciones repetidas en comparación con las bases de comparación.
• Generalización de Lenguaje: Evaluado en problemas de Go de SWE-bench Pro, SWE-Doctor logró una tasa de resolución del 36.0%, superando a las bases de comparación (32.0% y 30.0%), lo que sugiere que el enfoque se generaliza más allá de Python.

Significancia

El artículo argumenta que el valor de los Tests de Reproducción de Errores en los agentes de ingeniería de software no depende meramente de su capacidad para reproducir un error, sino de cómo se utilizan sus ejecuciones. SWE-Doctor demuestra que, al tratar los BRTs como fuentes de evidencia diagnóstica de tiempo de ejecución en lugar de simples objetivos de paso/falla, los agentes pueden superar las limitaciones de los parches parciales y las señales de prueba engañosas. El trabajo sugiere un cambio en el diseño de agentes: pasar de depender de los resultados de las pruebas a aprovechar la rica información contenida dentro de las ejecuciones de las pruebas (trazas de pila, estados de tiempo de ejecución) para guiar los procesos de razonamiento y toma de decisiones de los agentes basados en LLM.