Cursor et Microsoft Research testent si un agent IA a besoin d'un accès complet au débogueur

Pour un agent IA chargé de corriger des bugs, lire le code et collecter des logs ne suffit plus : lorsqu'il accède à un vrai débogueur, il se comporte davantage comme un développeur humain et comprend bien mieux où le programme casse exactement.

Fin 2025, Cursor a lancé Debug Mode, un mode dans lequel l'agent peut collecter des logs directement depuis le runtime et les utiliser comme source de contexte supplémentaire. Pour le débogage concret, c'est une étape importante : au lieu de deviner à partir des stack traces, le modèle voit ce qui se passe au moment de l'exécution, quelles valeurs traversent les fonctions et à quel endroit le système se comporte autrement que prévu.

Cette approche s'est aussi révélée intuitive pour les développeurs : à en juger par la réaction de la communauté, l'idée n'est pas perçue comme un énième mode marketing, mais comme un outil réellement utile au travail quotidien sur les bugs.

Mais la journalisation n'est pas le seul moyen de rapprocher l'IA des pratiques d'ingénierie courantes. La question suivante est encore plus directe : si l'agent vit déjà à côté de l'IDE, pourquoi ne pas lui donner les mêmes outils qu'à un humain ? Il s'agit de points d'arrêt, d'exécution pas à pas, d'inspection de l'état du programme et d'evaluate expression sur la ligne voulue.

C'est précisément ce que les chercheurs de Microsoft Research ont testé dans le framework expérimental Debug2Fix. Dans leur configuration, un sous-agent distinct recevait des outils pour interagir avec le débogueur et, sur des tâches issues de GitBug-Java et de SWE-Bench-Live, il venait à bout des bugs environ 20 % mieux qu'un agent ordinaire sans cet accès. Ce n'est pas une amélioration cosmétique : pour la correction automatique de code, un tel écart change la valeur pratique de l'outil.

L'idée est simple. Les logs aident presque toujours à voir les symptômes, mais le débogueur permet d'atteindre la mécanique de la panne. L'agent peut faire plus que lire qu'une valeur est erronée : il peut retracer le moment où elle l'est devenue, quelle branche de la condition s'est exécutée, ce que contiennent les objets à cet instant et comment une expression se comporte quand on teste une hypothèse sur place.

En somme, le modèle obtient non seulement de l'observation, mais aussi une expérience contrôlée. Pour déboguer des états complexes, des race conditions, des valeurs null inattendues ou des erreurs de logique métier, cela peut être crucial, car c'est là que l'analyse statique, et même des logs détaillés, font souvent défaut.

Dans ce contexte, il est logique que les assistants d'IDE complets commencent à aller au-delà de la simple lecture de fichiers. Si l'agent est déjà intégré à l'environnement de développement, l'accès au débogueur paraît moins exotique que comme une extension naturelle de ses capacités. C'est pourquoi la dernière version de l'assistant pour IntelliJ inclut un Debug Agent, capable d'interagir avec le débogueur directement dans l'IDE. Le scénario est presque humain : l'agent lance le programme, s'arrête au bon endroit, examine l'état, teste une hypothèse et ne propose une correction qu'ensuite. C'est une différence importante avec l'approche où le modèle s'appuie surtout sur la journalisation et sur des indices indirects du problème.

Le plus intéressant dans cette histoire n'est pas seulement le gain sur les benchmarks, mais la question elle-même : qu'est-ce qui sera le plus utile au développeur IA de demain, un bon accès aux logs de runtime ou de véritables « mains » dans le débogueur ? Une seule expérience ne donne pas encore de réponse complète, mais on voit déjà que le marché avance dans deux directions à la fois. Une voie mise sur une observation de qualité de l'exécution du programme, l'autre sur l'intervention active dans le processus de débogage.

Si la seconde approche confirme son avantage sur un plus grand nombre de cas réels, les AI coding assistants cesseront vite d'être de simples outils d'autocomplétion intelligents pour devenir de véritables partenaires, capables non seulement d'écrire du code, mais aussi de remonter méthodiquement à la racine d'un bug.