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

Résumé technique : Rédaction de rapports de bogues pour les agents de réparation de logiciels

Énoncé du problème
Les flux de travail de développement de logiciels adoptent de plus en plus des approches « axées sur l'agent » (agentic-first), où des agents d'IA se voient assigner des rapports de problèmes pour générer des correctifs initiaux avant la revue humaine. Dans ce paradigme, les rapports de bogues passent de la documentation destinée aux mainteneurs humains à une spécification de tâche servant de base principale aux agents automatisés. Cependant, il reste difficile de déterminer quels types d'informations spécifiques au sein des rapports de bogues sont les plus efficaces pour permettre aux agents de produire des correctifs corrects. Les benchmarks existants, tels que SWE-bench Verified, contiennent des problèmes dont le contenu informationnel est très variable, ce qui rend difficile la distinction entre le succès de l'agent dû aux capacités de raisonnement du modèle ou à la richesse de la description du bogue. Cette étude examine ce qui constitue un rapport de bogue « prêt pour l'agent », en analysant spécifiquement quels types d'informations sont corrélés à une réparation automatisée réussie.

Méthodologie
Les auteurs ont mené une étude empirique utilisant le benchmark SWE-bench Verified, qui comprend 500 problèmes réels issus de GitHub, associés à des correctifs de référence (gold patches) et des suites de tests.

1. Curation du jeu de données : Parmi les 500 problèmes, 441 ont été classés comme rapports de bogues (excluant les demandes de fonctionnalités et les refactorisations).
2. Annotation : Deux auteurs ont annoté manuellement le texte de ces 441 rapports au niveau du caractère en utilisant une taxonomie dérivée de la littérature existante. La taxonomie comprenait neuf types d'informations : Résumé, Comportement observé, Comportement attendu, Références, Étapes de reproduction, Environnement, Zone affectée (indices de localisation au niveau de la ligne, de la fonction, du fichier ou de manière générique), Correctifs suggérés (en code ou en langage naturel), et Solutions de contournement actuelles. L'accord inter-annotateurs était modéré ($\kappa = 0,57$), les conflits ayant été résolus par un troisième auteur.
3. Exécution de l'agent : L'étude a utilisé mini-swe-agent, une architecture d'agent qui interagit avec les dépôts via des commandes bash. Cet agent a été exécuté sur les 441 rapports de bogues en utilisant trois noyaux de modèles de langage étendu (LLM) distincts : GPT-5-mini, MiniMax M2.5, et Gemini 3 Flash. Chaque problème a été exécuté trois fois par modèle pour tenir compte de la stochasticité, résultant en un total de 3 969 observations.
4. Analyse statistique :
   • Étude observationnelle : Un modèle de régression binomiale à effets mixtes a été ajusté pour estimer l'association entre la présence de types d'informations spécifiques et le succès de l'agent (passage de la suite de tests). Le modèle contrôlait la longueur du bogue, la taille du correctif de référence, la difficulté, les mentions de code et les effets aléatoires du dépôt.
   • Étude d'ablation : Pour isoler l'impact causal des types d'informations, les auteurs ont sélectionné 65 problèmes « complets en informations » (contenant toutes les macro-catégories). Ils ont généré des variantes en supprimant systématiquement des types d'informations spécifiques (par exemple, supprimer les indices de localisation, supprimer les correctifs suggérés, ou supprimer les deux) et ont réexécuté les agents. Cela a permis une évaluation contrôlée de la manière dont l'absence de points de données spécifiques affecte la performance.

Contributions clés

1. Conceptualisation : L'article introduit la notion de « rapports de bogues axés sur l'agent », les distinguant des rapports traditionnels orientés vers l'humain en se concentrant sur l'information qui opérationnalise la tâche de réparation.
2. Annotation : Il fournit un jeu de données annoté au niveau du caractère des problèmes de SWE-bench Verified, catégorisant le contenu en types comportementaux, environnementaux, de localisation et de suggestion de réparation.
3. Preuve empirique : Il offre la première analyse empirique à grande échelle de la relation entre le contenu des rapports de bogues et le succès des agents basés sur les LLM à travers plusieurs noyaux de modèles.
4. Orientation : Il fournit des recommandations fondées sur des preuves pour structurer les rapports de bogues afin de maximiser l'efficacité des agents.

Résultats clés

• La localisation et les correctifs suggérés sont critiques : Les associations positives les plus fortes avec le succès de l'agent ont été trouvées pour les indices de localisation (références aux lignes, fonctions ou fichiers affectés) et les correctifs suggérés (tant en code qu'en langage naturel). Les correctifs suggérés en langage naturel présentaient l'odds ratio le plus élevé (OR = 2,01) dans le modèle groupé.
• L'information centrée sur l'humain est moins décisive : Contrairement aux directives traditionnelles de rapport de bogue, les types d'informations cruciaux pour le débogage humain — tels que les étapes de reproduction, le comportement attendu et le comportement observé — ont montré des associations plus faibles ou non significatives avec le succès de l'agent dans l'étude observationnelle. L'étude d'ablation a confirmé que la suppression de ces composants n'entraînait pas de dégradation significative de la performance si les indices opérationnels (localisation/suggestions) restaient présents.
• Le fossé « opérationnel » : L'étude d'ablation a révélé que la dégradation la plus significative de la performance de l'agent ne se produisait que lorsque les indices de localisation ET les correctifs suggérés étaient supprimés simultanément (OR = 0,60). Cela suggère que les agents nécessitent au moins une « direction de réparation » claire (soit où chercher, soit comment réparer).
• Spécificité des modèles : Bien que les correctifs suggérés en langage naturel soient robustement utiles pour les trois LLM, d'autres types d'informations présentent des dépendances spécifiques aux modèles. Par exemple, GPT-5-mini bénéficie de la localisation à tous les niveaux de granularité, tandis que Gemini Flash 3 et MiniMax M2.5 bénéficient principalement de indices plus fins.
• Corrélations négatives : Les descriptions de bogues plus longues et les tailles de correctifs de référence plus importantes étaient négativement associées au succès, suggérant que la verbosité peut introduire du bruit ou que les agents peinent face à des correctifs intrinsèquement complexes, indépendamment de la qualité du rapport. Les références à des ressources externes étaient également négativement associées, probablement parce que les agents ne peuvent pas inférer efficacement la pertinence à partir de liens externes sans une sommatisation explicite.

Signification et implications
L'article soutient que le développement axé sur l'agent nécessite un changement dans la manière dont les rapports de bogues sont rédigés. Les rapports doivent être traités moins comme des récits exhaustifs pour la compréhension humaine et davantage comme des spécifications de réparation qui restreignent explicitement l'espace de recherche et de réparation de l'agent.

• Conception de modèles (Templates) : Les modèles de rapports devraient prioriser l'information exploitable (localisation et hypothèses de réparation) plutôt que le contexte descriptif.
• Évolution du flux de travail : Puisque des informations critiques comme la localisation émergent souvent lors de la discussion, les auteurs suggèrent que les flux de travail agentiques devraient être incrémentaux. Les outils de suivi de problèmes pourraient supporter la réexécution des agents lorsque de nouveaux commentaires exploitables (par exemple, « Je soupçonne que le bogue est dans file.py ») sont ajoutés, plutôt que de déclencher une tentative unique immédiatement après la création du ticket.
• Architecture système : Les conclusions soutiennent la conception de systèmes d'agents à plusieurs étapes où un composant de localisation dédié identifie les régions de code suspectes avant qu'un agent de réparation ne tente la génération du correctif.

Les auteurs concluent que, bien que la qualité traditionnelle des rapports de bogues reste importante pour les mainteneurs humains, la « préparation pour l'agent » est définie par la présence d'informations qui opérationnalisent la correction, spécifiquement en exposant une direction de réparation plausible.