CuraLoc repère les bugs dans les dépôts avec un seul plan et consomme 90% de tokens en moins

Des chercheurs de l'équipe de Sangeeta Warrier proposent CuraLoc, une méthode de localisation d'erreurs à l'échelle d'un dépôt entier. Elle remplace une longue chaîne d'appels au modèle par un seul plan d'inspection du code. Sur SWE-bench Verified avec GPT-5.2, le système obtient un Func@1 de 59,3%, contre 53,8% pour LocAgent, et consomme 90,3% de tokens écrits en moins. Le preprint est paru sur arXiv le 22 octobre 2026, et une deuxième version est sortie le 26 octobre.

Pourquoi un rapport de bug indique mal où corriger

Un rapport de bug décrit un symptôme : ce qui ne fonctionne pas et dans quelles conditions. Il précise presque jamais l'endroit exact où modifier le code. C'est pourquoi les agents de correction d'erreurs comportent une étape distincte de localisation : parmi des milliers de fichiers et de fonctions, ils doivent trouver ceux qu'il convient de corriger.

La plupart des méthodes existantes traitent ce problème de façon itérative. Le modèle examine la structure du dépôt, choisit un fichier, le lit, décide où aller ensuite, et ainsi de suite. Chaque étape implique un nouvel appel au LLM et une nouvelle charge de tokens dans le contexte. La facture grimpe vite, et la qualité dépend de la capacité de l'agent à ne pas s'engager sur une fausse piste à la troisième ou à la cinquième étape.

Les auteurs de CuraLoc testent une autre hypothèse : les décisions sur ce qu'il faut inspecter peuvent être planifiées à l'avance, avant le chargement du code source.

Un seul plan à la place d'une chaîne d'étapes

Le pipeline de CuraLoc se déroule en plusieurs étapes. Le système sélectionne d'abord des fichiers candidats et décrit leurs symboles (fonctions, classes, méthodes) à l'aide de descriptions comportementales et structurelles compactes. À ce stade, le code source lui-même n'est pas transmis au modèle.

Vient ensuite l'unique décision de planification. En un seul appel, le modèle accomplit trois tâches :

• il choisit les symboles de départ ;
• il détermine quelles relations vérifier à partir de chacun d'eux (appels, dépendances et autres relations structurelles dans le code) ;
• il formule des hypothèses sur les modifications les plus probables.

Une recherche déterministe prend ensuite le relais. Sans intervention du modèle, elle rassemble le code source demandé. Le modèle procède alors à un classement final, en s'appuyant sur les hypothèses déjà formulées. Son raisonnement porte sur le choix et la comparaison du code, et non sur le pilotage de chaque étape d'extraction.

Ce que montrent les benchmarks

Les auteurs ont testé la méthode sur SWE-bench Lite et SWE-bench Verified. La métrique principale sur Verified est le Func@1, c'est-à-dire la proportion de cas où la bonne fonction arrive en première position. Pour Lite, ils indiquent le Func@5, où elle figure parmi les cinq premières.

Comparaison sur SWE-bench Verified avec GPT-5.2, en Func@1 :

• CuraLoc : 59,3% ;
• RepoSearcher : 56,2% ;
• LocAgent : 53,8% ;
• Agentless : 39,6%.

Côté consommation, CuraLoc utilise 90,3% de tokens écrits en moins que LocAgent. Ce n'est pas une optimisation marginale : au lieu de dizaines d'appels au modèle, toute la navigation se réduit à un nombre minimal d'appels.

Sur SWE-bench Lite, CuraLoc atteint 83,8% de Func@5. Par rapport à Agentless, cela représente une amélioration de plus de 15%.

Par ailleurs, les auteurs montrent que la méthode n'est pas liée à un seul modèle. CuraLoc affiche une forte précision de localisation aussi bien avec GPT-5.2 qu'avec GPT-6 Astra.

Ce qu'on peut en retenir en pratique

La principale leçon pour les développeurs d'agents : la navigation autonome d'un modèle dans une base de code ne justifie pas toujours son coût. Si l'on confie une partie des décisions à une couche déterministe et que l'on réserve au modèle ce qu'il fait bien (formuler des hypothèses de modification et comparer des candidats), on peut gagner à la fois en précision et en coût sur la localisation d'erreurs.

Pour les équipes qui construisent leurs propres agents de codage, c'est l'occasion de revoir le budget de tokens alloué à l'étape de recherche. La localisation précède souvent la génération du patch et détermine si ce patch aura le moindre sens. Une première étape peu coûteuse et stable allège aussi tout le cycle de correction.

Il existe aussi des limites, qui tiennent au cadre et aux métriques eux-mêmes. Tous les résultats proviennent de SWE-bench Lite et Verified, c'est-à-dire de dépôts Python avec des tâches connues. Le comportement du schéma sur des monorepos fermés et dans d'autres langages reste à vérifier séparément. Mais pour la tâche « trouver la fonction à partir d'un rapport de bug », CuraLoc apporte un argument solide en faveur de la planification plutôt que de l'errance.

L'article est publié dans la catégorie Machine Learning, avec Software Engineering (cs.SE) en catégorie croisée, DOI 10.48550/arXiv.2610.31809.