Un test fondé sur les bugs révèle les limites de la revue de code automatisée

Si les commentaires de revue humains peuvent passer à côté de bugs réels, comment savoir si les relecteurs automatisés retrouvent des défauts que des personnes ont effectivement confirmés et corrigés ?

Pour être utile, un test doit évaluer le défaut lui-même tout en donnant aux agents le dépôt et le changement qu’ils auraient à examiner.

CRBugBench relie des bugs confirmés aux changements qui les ont introduits, puis mesure si des agents de revue les détectent dans des tâches portant sur des dépôts.

Pour chaque tâche, un agent examine un instantané du dépôt et la pull request qui a introduit un bug connu, sans être informé de sa présence.

Trois évaluateurs fondés sur des modèles de langage déterminent si ses signalements correspondent au bug, puis les chercheurs calculent la part des tâches où celui-ci figure parmi les cinq premières anomalies relevées.

Dans les tâches GitHub, claude-opus-5 a détecté plus souvent les bugs repérés avant la fusion que ceux trouvés après : 79,6 % contre 64,2 % des tâches. Les résultats montrent une détection élevée mais incomplète, qui varie selon le type de tâche.

Ces résultats mesurent la détection de bugs connus dans un ensemble de tâches issues de dépôts sélectionnés, et non l’utilité globale des revues ni les performances sur tous les projets logiciels.

Les associations ajustées décrivent des tendances dans les données ; elles ne montrent pas que la visibilité du bug, à elle seule, entraîne des différences de détection.