Lundi matin. Tu tapes un prompt dans Cursor, Claude Code ou Copilot. Trois minutes plus tard, une feature atterrit dans ta PR — la pull request que ton code soumet avant d'être mergée dans le projet principal. La CI passe au vert. Ticket fermé. Shot de dopamine. Tu es un dev 10x maintenant.

Une semaine plus tard, cette feature pète à 3h du mat'. Tu ouvres le fichier. Impossible de tracer le bug. T'as pas écrit ce code. L'IA l'a fait. Et elle n'a laissé aucune trace. Tu as besoin d'un debugger. Mais tous les debuggers ne veulent plus dire la même chose.

Deux outils de debug entrent dans une semaine

Entre le 14 et le 16 avril, pendant que le reste de l'industrie continuait à construire des générateurs de code toujours plus rapides, deux outils ont enfin admis que le code généré par l'IA casse différemment du code écrit par des humains — et nécessite des outils différents pour le réparer.

Le 14 avril, Cursor 3.1 a livré à la fois une commande CLI /debug et des agents en arrière-plan qui créent automatiquement des PRs à partir d'issues GitHub — une seule release à cheval sur les deux côtés du fossé. Le 16 avril, Visual Studio 18.5 a lâché un debugger agentique qui génère des hypothèses de défaillance et pose des breakpoints à ta place. Pendant ce temps, le côté génération gardait le rythme : Claude Code a lancé les Routines le 14 avril et OpenAI a mis à jour Codex le 16 avril — 3 millions d'utilisateurs hebdomadaires avec l'utilisation desktop et plus de 90 plugins.

Ratio génération/debug cette semaine : 3:2 (en comptant les agents de Cursor côté génération, son /debug côté debug). Du progrès, j'imagine.

Même mot, deux philosophies différentes

Le /debug de Cursor et le debugger agentique de Visual Studio prétendent tous les deux debugger. Ils font des choses fondamentalement différentes.

Le /debug de Cursor lit la sortie d'erreur de ton terminal — stack traces, assertions échouées, hurlements du compilateur — les corrèle avec tes fichiers ouverts et le contexte du projet, puis génère un patch. Sous le capot, c'est un re-prompting avec un meilleur contexte. L'IA ingère l'erreur, devine ce qui a cassé, et produit du code de remplacement. Si le patch ne tient pas, tu re-promptes. Si ça ne tient toujours pas, tu supprimes la fonction et tu régénères à partir de zéro. Le workflow optimise la vitesse : erreur → patch → ship. Ton job, c'est d'évaluer le résultat, pas de comprendre le chemin.

C'est un choix de design légitime. Les agents en arrière-plan dans cette même release Cursor 3.1 — tournant dans des sandboxes cloud, transformant des issues GitHub en PRs sans intervention humaine — révèlent clairement la philosophie produit. Le code est jetable, c'est le résultat qui compte, l'itération est bon marché. /debug est cohérent avec cette vision du monde. Ne comprends pas le code cassé. Remplace-le par du code qui marche. Passe à la suite.

Le debugger agentique de Visual Studio prend le pari inverse. Quand tu décris un bug ou colles une exception, l'agent ne génère pas un fix. Il génère des hypothèses — des explications classées par probabilité de pourquoi la défaillance s'est produite. Ensuite, il instrumente ton code : pose des breakpoints conditionnels aux endroits que chaque hypothèse prédit comme fautifs, configure des expressions de surveillance sur les variables suspectes, et te guide à travers le chemin d'exécution réel, étape par étape.

L'annonce de Microsoft décrit l'agent évaluant "le code pertinent, les changements récents et les patterns d'erreur courants" pour produire sa liste d'hypothèses. Le debugger entre alors dans ce qu'ils appellent une boucle d'investigation : toucher un breakpoint, inspecter l'état, confirmer ou rejeter une hypothèse, passer à la suivante. Tu ne lis pas du code généré par l'IA. Tu lis le comportement réel de ton runtime, guidé par une IA qui réduit l'espace de recherche.

La différence mécanique clé : le /debug de Cursor opère sur du texte — le code source comme une chaîne à réécrire. Le debugger de Visual Studio opère sur l'exécution — l'état runtime comme preuve à examiner. L'un traite le code comme un document. L'autre traite le code comme une machine.

Pourquoi cette distinction compte vraiment

Pour un null pointer dans une fonction utilitaire, elle ne compte pas. Le /debug de Cursor le patchera en quelques secondes. Le debugger de Visual Studio serait une usine à gaz pour si peu.

Mais les bugs générés par l'IA ne sont généralement pas des null pointers. Les études s'accumulent — les données de qualité de code de GitClear, de multiples réplications académiques — montrant que le code co-écrit avec l'IA porte significativement plus d'erreurs de logique et de problèmes de performance que le code écrit à la main. Les bugs qui comptent ne sont pas des problèmes de syntaxe. Ce sont des décalages comportementaux subtils : un handler d'API qui passe les tests mais double-écrit sous requêtes concurrentes, une requête base de données qui retourne des résultats corrects sur des petits jeux de données mais génère des jointures O(n²) à l'échelle, une machine à états qui gère le happy path mais corrompt silencieusement les données au retry.

Ces bugs ne s'annoncent pas dans la sortie du terminal. Ils se manifestent par une dégradation lente, des pannes intermittentes, des incohérences de données qui remontent des jours plus tard. Le /debug de Cursor a besoin d'un message d'erreur pour fonctionner. Qu'est-ce que tu lui donnes quand le symptôme c'est "le revenu du checkout a baissé de 4% mardi et personne ne sait pourquoi" ?

L'approche par hypothèses de Visual Studio gère ça différemment. Tu décris le symptôme. L'agent propose des causes candidates — peut-être que la logique de retry de paiement double-facture, peut-être que la vérification d'inventaire fait une race condition avec la mise à jour du panier, peut-être que le calcul de remise tronque au lieu d'arrondir. Il pose des breakpoints à chaque emplacement candidat. Tu reproduis le scénario et tu regardes le chemin d'exécution révéler quelle hypothèse tient.

Plus lent ? Énormément. Te demande d'allumer ton cerveau ? Malheureusement, oui. Mais c'est le seul outil sorti ce mois-ci qui traite le debug comme une investigation plutôt qu'un autre tour de génération.

La bifurcation des workflows

C'est ici que l'industrie se sépare en deux.

Voie A : le modèle Cursor. Le code est bon marché. Debugger, c'est régénérer. Quand ça casse, jette-le et re-prompte. /debug resserre cette boucle. Les agents en arrière-plan la rendent autonome. La conclusion logique, c'est du code que personne ne lit jamais — généré, testé, déployé et remplacé par des machines dans une boucle continue. Les développeurs deviennent des product managers qui décrivent l'intention et évaluent le résultat.

Voie B : le modèle Visual Studio. Le code est une infrastructure. Debugger, c'est comprendre. Quand ça casse, comprendre pourquoi avant de corriger, parce que le même défaut structurel réapparaîtra dans la prochaine génération si tu ne le fais pas. La conclusion logique, c'est des développeurs qui comprennent moins de code au total mais le comprennent plus profondément — des spécialistes du comportement système plutôt que de la production de syntaxe.

Aucune des deux voies n'est idiote. Mais elles sont incompatibles dans la même codebase. Une équipe qui debug par régénération ne construit aucune connaissance institutionnelle du comportement réel de son système. Une équipe qui debug par investigation passe du temps que les équipes régénération-first appellent du gaspillage.

Devinez quelle approche gagne

Celle de Cursor, évidemment. C'est plus rapide. Ça demande moins de réflexion. Ça colle parfaitement au workflow vibe-coding que l'industrie a unanimement adopté. Supprimer, re-prompter, shipper, recommencer. L'investigation, c'est le problème de quelqu'un d'autre — jusqu'à ce que la prod brûle et que "quelqu'un d'autre" ce soit toi à 3h du mat', en train de fixer trois services que trois prompts différents ont écrits, regardant l'interaction entre eux faire tomber le checkout.

Tu ne peux pas re-prompter ta sortie d'un incident distribué. Tu as besoin de quelqu'un qui a cartographié les chemins d'exécution. Et si ta culture de debug c'est "remplace jusqu'à ce que ce soit vert", cette personne n'existe pas dans ton équipe.

L'approche de Visual Studio est plus dure à vendre. "Laisse-moi t'aider à réfléchir" perd face à "laisse-moi te corriger ça" dans chaque démo, chaque tweet, chaque cycle de hype. Mais la compréhension se compose. La régénération, non.

La partie inconfortable

La question n'est pas quel debugger est meilleur. C'est quelle philosophie de debug ton équipe adopte — et si tu as choisi délibérément ou si tu as juste pris par défaut l'outil le plus rapide.

Si ta stack, c'est des fonctions stateless et des services éphémères, la boucle de régénération de Cursor est peut-être sincèrement suffisante. Remplace la lambda cassée. Passe à la suite. Personne n'a besoin de comprendre une fonction qui vit le temps d'une release.

Si ta stack a de l'état, des transactions distribuées, un comportement qui émerge de l'interaction entre composants — quelqu'un doit comprendre le runtime. Pas le texte source. Le runtime. Le debugger de Visual Studio est le premier outil IA qui reconnaît que ce métier existe.

Lundi matin, tu taperas un autre prompt. Quelque chose va casser. La question n'est pas si tu vas debugger. C'est si debugger signifie "génère encore" ou "comprends pourquoi". Choisis consciemment. Le choix par défaut, c'est la régénération. Et à 3h du mat', les choix par défaut sont tout ce qu'il te reste.