Writing Bug Reports for Software Repair Agents: What Information Matters Most?

Resumen Técnico: Escritura de Reportes de Errores para Agentes de Reparación de Software

Planteamiento del Problema
Los flujos de trabajo de desarrollo de software están adoptando cada vez más enfoques "prioritarios para agentes" (agentic-first), donde se asignan reportes de problemas a agentes de IA para generar correcciones iniciales antes de la revisión humana. En este paradigma, los reportes de errores pasan de ser documentación para mantenedores humanos a servir como la especificación de tarea principal para agentes automatizados. Sin embargo, sigue sin estar claro qué tipos de información específicos dentro de los reportes de errores son más efectivos para permitir que los agentes produzcan parches correctos. Los benchmarks existentes, como SWE-bench Verified, contienen problemas con un contenido de información altamente variable, lo que dificulta distinguir si el éxito del agente proviene de la capacidad de razonamiento del modelo o de la riqueza de la descripción del problema. Este estudio investiga qué constituye un reporte de error "listo para agentes", analizando específicamente qué tipos de información se correlacionan con una reparación automatizada exitosa.

Metodología
Los autores realizaron un estudio empírico utilizando el benchmark SWE-bench Verified, que comprende 500 problemas del mundo real de GitHub emparejados con parches de oro y suites de pruebas.

1. Curación del Conjunto de Datos: De los 500 problemas, 441 fueron clasificados como reportes de errores (excluyendo solicitudes de características y refactorizaciones).
2. Anotación: Dos autores anotaron manualmente el texto de estos 441 reportes a nivel de carácter utilizando una taxonomía derivada de la literatura existente. La taxonomía incluyó nueve tipos de información: Resumen, Comportamiento Observado, Comportamiento Esperado, Referencias, Pasos de Reproducción, Entorno, Área Afectada (pistas de localización a niveles de línea, función o archivo, o niveles genéricos), Sugerencias de Corrección (en código o lenguaje natural) y Soluciones Alternativas Actuales. El acuerdo entre anotadores fue moderado ($\kappa = 0.57$), y los conflictos fueron resueltos por un tercer autor.
3. Ejecución del Agente: El estudio utilizó mini-swe-agent, una arquitectura de agente que interactúa con repositorios mediante comandos bash. Este agente se ejecutó en los 441 reportes de errores utilizando tres backbones de Modelos de Lenguaje Grande (LLM) distintos: GPT-5-mini, MiniMax M2.5 y Gemini 3 Flash. Cada problema fue ejecutado tres veces por modelo para dar cuenta de la estocasticidad, resultando en 3,969 observaciones totales.
4. Análisis Estadístico:
   • Estudio Observacional: Se ajustó un modelo de regresión binomial de efectos mixtos para estimar la asociación entre la presencia de tipos de información específicos y el éxito del agente (pasar la suite de pruebas). El modelo controló la longitud del problema, el tamaño del parche de oro, la dificultad, las menciones de código y los efectos aleatorios del repositorio.
   • Estudio de Ablación: Para aislar el impacto causal de los tipos de información, los autores seleccionaron 65 problemas "completos de información" (que contenían todas las macrocategorías). Generaron variantes eliminando sistemáticamente tipos de información específicos (por ejemplo, eliminando pistas de localización, eliminando sugerencias de corrección, o eliminando ambos) y volvieron a ejecutar los agentes. Esto permitió una evaluación controlada de cómo la ausencia de puntos de datos específicos afecta el desempeño.

Contribuciones Clave

1. Conceptualización: El artículo introduce la noción de "reportes de errores prioritarios para agentes", distinguiéndolos de los reportes tradicionales orientados a humanos al centrarse en la información que operacionaliza la tarea de reparación.
2. Anotación: Proporciona un conjunto de datos anotado a nivel de carácter de los problemas de SWE-bench Verified, categorizando el contenido en tipos de comportamiento, entorno, localización y sugerencia de reparación.
3. Evidencia Empírica: Ofrece el primer análisis empírico a gran escala de la relación entre el contenido del reporte de error y el éxito de los agentes basados en LLM a través de múltiples backbones de modelos.
4. Guía: Proporciona recomendaciones basadas en evidencia para estructurar reportes de errores para maximizar la efectividad de los agentes.

Resultos Clave

• La Localización y las Sugerencias de Corrección son Críticas: Las asociaciones positivas más fuertes con el éxito del agente se encontraron para las pistas de localización (referencias a líneas, funciones o archivos afectados) y las sugerencias de corrección (tanto en código como en lenguaje natural). Las sugerencias de corrección en lenguaje natural mostraron la razón de momios más alta (OR = 2.01) en el modelo agrupado.
• La Información Centrada en el Humano es Menos Decisiva: Contrario a las directrices tradicionales de reporte de errores, los tipos de información cruciales para la depuración humana —como los pasos de reproducción, el comportamiento esperado y el comportamiento observado— mostraron asociaciones más débiles o no significativas con el éxito del agente en el estudio observacional. El estudio de ablación confirmó que eliminar estos componentes no degradó significativamente el desempeño si las pistas operacionales (localización/sugerencias) permanecían.
• La Brecha "Operacional": El estudio de ablación reveló que la degradación más significativa en el desempeño del agente ocurrió solo cuando se eliminaban simultáneamente tanto las pistas de localización como las sugerencias de corrección (OR = 0.60). Esto sugiere que los agentes requieren al menos una "dirección de reparación" clara (ya sea dónde mirar o cómo reparar).
• Especificidad del Modelo: Aunque las sugerencias de corrección en lenguaje natural fueron robustamente útiles para los tres LLM, otros tipos de información mostraron dependencias específicas del modelo. Por ejemplo, GPT-5-mini se benefició de la localización en todos los niveles de granularidad, mientras que Gemini Flash 3 y MiniMax M2.5 se beneficiaron principalmente de pistas de mayor granularidad.
• Correlaciones Negativas: La longitud de las descripciones de los problemas y el tamaño de los parches de oro más grandes se asociaron negativamente con el éxito, lo que sugiere que la verbosidad puede introducir ruido o que los agentes luchan con correcciones inherentemente complejas independientemente de la calidad del reporte. Las referencias a recursos externos también se asociaron negativamente, probablemente porque los agentes no pueden inferir la relevancia de manera efectiva de los enlaces externos sin una sumarización explícita.

Significancia e Implicaciones
El artículo argumenta que el desarrollo prioritario para agentes requiere un cambio en la forma en que se escriben los reportes de errores. Los reportes deben tratarse menos como narrativas exhaustivas para la comprensión humana y más como especificaciones de reparación que estrechen explícitamente el espacio de búsqueda y reparación del agente.

• Diseño de Plantillas: Las plantillas de problemas deben priorizar la información accionable (localización e hipótesis de reparación) sobre el contexto descriptivo.
• Evolución del Flujo de Trabajo: Dado que la información crítica como la localización suele surgir durante la discusión, los autores sugieren que los flujos de trabajo de agentes deben ser incrementales. Los rastreadores de problemas podrían soportar la reejecución de agentes cuando se añaden nuevos comentarios accionables (por ejemplo, "Sospecho que el error está en file.py"), en lugar de disparar un intento de un solo paso inmediatamente después de la creación del problema.
• Arquitectura de Sistemas: Los hallazgos respaldan el diseño de sistemas de agentes de múltiples etapas donde un componente de localización dedicado identifica regiones de código sospechosas antes de que un agente de reparación intente la generación del parche.

Los autores concluyen que, si bien la calidad tradicional del reporte de errores sigue siendo importante para los mantenedores humanos, la "preparación para agentes" se define por la presencia de información que operacionaliza la corrección, específicamente al exponer una dirección de reparación plausible.