Si vous avez déjà regardé un agent essayer de corriger un bug, vous l'avez vu tùtonner. Il lit le code, émet une hypothÚse, fait une modification, et espÚre. Parfois, il a raison. Mais souvent, vous obtenez un correctif qui a l'air confiant et qui cache en réalité le vrai bug.
Le mode Debug a été conçu pour cela. Au lieu de réfléchir au code, l'agent va chercher des preuves de ce que fait le code lorsqu'il s'exécute.
Voici le processus
- L'agent Ă©met plusieurs hypothĂšses et commence par la plus plausible
- Ensuite, du logging est ajouté pour tester une hypothÚse (sans toucher à l'implémentation)
- Un petit serveur de debug collecte les résultats d'exécution dans .cursor/debug.log pendant que votre programme s'exécute.
- Vous reproduisez le bug, et l'agent peut maintenant lire les logs et comprendre ce qui s'est passé au lieu de devoir deviner
- Cursor trouve la cause racine dans les logs, effectue la correction, et retire le logging qu'il a ajouté.
Voici un exemple avec un vrai bug, accéléré en environ une minute :
Comment l'Ă©quipe l'utilise
Voici quelques problÚmes intéressants que nous avons résolus en interne avec le mode Debug :
- Un problÚme de concurrence qui se produisait 1 fois sur 20. Il corrompait les métadonnées git dans nos runs best-of-N. Le mode Debug l'a identifié en moins d'une heure
- Une fuite mémoire, tracée en un seul passage. Elle était due à une mauvaise utilisation de notre framework frontend. La correction tenait en une seule ligne.
- Un crash natif au cĆur du C++. Un crash Electron que les gens contournaient habituellement. Les logs ont permis de le trouver.
- Un scintillement SSR qui avait été abandonné. Un bug de rendu que personne ne voulait toucher, corrigé une fois que l'agent a pu voir ce que faisait la page au moment de l'exécution.
Essayez avec Shift+Tab (c'est aussi dans le CLI, via /debug).
Je suis sûr que les gens l'utilisent de maniÚre à laquelle je n'ai pas pensé, alors faites-moi savoir !
