Gains :
- Possibilité de réduire un bug à la plus petite instance reproductible et de le déplacer vers l'IA avec une preuve complète
- Capacité à tester des hypothèses fondées sur des preuves avec le contrôle le moins cher et à trouver la cause profonde
- Capacité à résoudre la cause première et à la sécuriser avec un test de régression plutôt que de corriger le symptôme
Le débogage est le processus consistant à découvrir pourquoi un logiciel se comporte de manière inattendue et à le corriger. C'est le travail où un développeur passe le plus de temps et est le plus fatigué ; Parce que la plupart du temps, l’erreur n’est pas là où elle apparaît, mais est cachée quelques pas derrière. L’IA est un puissant partenaire de réflexion qui accélère cette recherche, mais seulement si vous lui fournissez les bonnes preuves. Le débogage sans preuves est le domaine dans lequel l’IA produit le plus d’hallucinations.
Dans cette unité, nous établissons un flux discipliné depuis la génération de l'erreur jusqu'à la cause première : clarification du symptôme, collecte de preuves (message d'erreur, trace de pile, journal, entrée), génération d'une hypothèse, test de l'hypothèse et validation du correctif. L'IA aide à chaque étape ; mais la décision « corrigée » est prise en constatant que le bug a effectivement disparu.
Pourquoi les preuves sont tout ?
Un LLM ne voit pas les erreurs comme vous ; Il sait seulement ce que vous lui dites. Une phrase comme « L'application plante » ne donne presque aucune information au modèle, et le modèle comble le vide avec une prédiction, c'est-à-dire une hallucination. À son tour, le message d'erreur complet, la trace de la pile - une répartition des appels de fonction par lesquels l'erreur s'est produite, l'entrée qui a déclenché l'erreur et ce qui était attendu, etc. Compte tenu du comportement observé, le modèle peut classer les vraies probabilités.
Lors du débogage, considérez l’IA comme l’assistant d’un détective : plus vous présentez de preuves, plus l’hypothèse qu’elle génère est précise. S’il n’y a aucune preuve, l’assistant ne fera que deviner et pourra vous conduire sur une mauvaise piste.
Astuce : Avant de porter un bug vers l'IA, réduisez-le au plus petit exemple reproductible. Le plus petit code et la plus petite entrée qui déclenche l'erreur rendent les choses radicalement plus faciles pour vous et pour le modèle ; le plus souvent lors de cette réduction, vous en trouvez vous-même la cause.
Étape par étape : flux d'analyse des causes profondes
- Clarifiez le symptôme. "Que se passe-t-il, à quoi t'attendais-tu ?" Écrivez les deux en une seule phrase.
- Rassemblez des preuves. Message d'erreur complet, trace de pile, lignes de journal pertinentes, entrée de déclenchement, informations de version.
- Faites générer l’hypothèse. D'après l'IA « 3 causes possibles qui expliquent ce symptôme et comment puis-je tester pour chacune ? » demander.
- Testez d’abord l’hypothèse la moins chère. Ajoutez un journal, imprimez une valeur, exécutez un test. Les preuves confirment-elles l’hypothèse ?
- Corrigez la cause profonde, pas le symptôme. Au lieu de faire taire le symptôme avec un patch, attaquez-vous à la cause profonde.
- Validez et ajoutez des tests de régression. Voyez l'erreur disparaître ; Ensuite, écrivez un test qui détectera cette erreur afin qu'elle ne revienne pas.
Trois mini-étuis
Cas 1 — La trace de pile a conduit au fichier correct. Une application renvoyait une erreur 500 sur certaines requêtes. Le développeur a donné la trace complète de la pile et la demande de déclenchement à l'IA ; Le modèle a émis l’hypothèse que l’erreur était causée par une valeur Aucun dans une couche d’analyse de date. Le développeur a ajouté un journal à cette ligne, l'a vérifié et l'a résolu en 15 minutes ; 2 heures ont été perdues la veille avec des expériences non prouvées.
Cas 2 – L’hallucination a conduit à une mauvaise voie. Un autre développeur a simplement écrit "la connexion à la base de données est interrompue". L'IA a accusé un paramétrage du pool de connexions sans aucune preuve ; Le développeur a passé 40 minutes à bricoler ce paramètre. La véritable cause était un délai d'attente du côté du réseau et n'a été révélée qu'en consultant les journaux. Leçon : une hypothèse prise sans preuves n’est que probable, pas fiable.
Cas 3 — Erreur floconneuse détectée. Il y avait un test qui échouait parfois. L'IA a reçu le code de test, le message d'échec et l'information « parfois ça réussit, parfois ça échoue » ; le modèle indiquait une dépendance partagée entre le temps et l'ordre des tests. L'examen a confirmé que le test était basé sur l'heure locale du système. Une fois l'horloge réparée (moquée), le test est devenu stable.
Quatre modèles copiables
Génération d’hypothèses fondées sur des preuves :
Je débogue un bug. Preuves ci-dessous.- Comportement attendu : {{expected}}- Comportement observé : {{observed}}- Message d'erreur/trace de pile : {{trace}}- Entrée déclenchante : {{input}}- Environnement/version : {{version}}Énumérez les 3 causes profondes LES PLUS PROBABLES qui expliquent ce symptôme. Pour chacun : comment tester (vérification la moins chère) et comment y remédier si c'est vrai. Si les preuves sont insuffisantes, dites-moi de quelles informations supplémentaires vous avez besoin.
Interprétation de la trace de pile :
Lisez cette trace de pile. Faites la distinction entre la ligne à laquelle l'erreur commence PROBABLEMENT (la racine) et les lignes qui ne sont que des continuations de la chaîne. Suggérez 1 à 2 endroits où regarder en premier. Code associé :{{code}}Trace :{{trace}}
Soustraction de reproduction minimale :
Le code ci-dessous produit une erreur. Réduisez-le à la PLUS PETITE instance qui déclenche toujours l'erreur mais supprime tout ce qui n'est pas nécessaire. Ne présumez pas que chaque élément que vous supprimez n'affecte pas l'erreur, mais ajoutez une note disant "si l'erreur disparaît lorsque vous supprimez ceci, c'est pourquoi".{{code}}
Validation post-correction et tests de régression :
Supposons que la cause première est {{cause}} et j'apporte le correctif suivant : {{fix}}.1) Ce correctif corrige-t-il réellement le symptôme, aura-t-il des effets secondaires ?2) Écrivez un test de régression qui détectera ce bug à l'avenir.
Invite faible/Invite forte
Faible : « Le code ne fonctionne pas, pourquoi ?
Strong : "Nœud 20 / Express. POST /orders renvoie 500 lorsque items est une chaîne vide dans le corps ; aurait dû renvoyer 400. Trace de pile : TypeError : Impossible de lire les propriétés d'undéfini (lecture de '0') - ci-joint la trace complète et le gestionnaire associé. Donnez-moi les 3 causes les plus probables qui expliquent ce symptôme et comment tester chacune d'entre elles. [trace + code]"
Version puissante ; Il donne l'environnement, le point de terminaison, l'entrée du déclencheur, le type d'erreur exact et le comportement attendu. Le modèle ne peut plus faire de prédictions, mais faire des analyses.
étape
La contribution de l'IA
votre contrôle
rassembler des preuves
Quelles preuves sont nécessaires, rappelle
Rassemble vraiment des preuves
génération d'hypothèses
Énumérez les raisons possibles
Priorise avec le contexte
test d'hypothèse
Recommande la méthode de test
Opère et observe personnellement
correction
patch recommande
Est-ce que cela résout la cause profonde ? C'est vrai.
régression
écrit un test
Vérifie que le test est rompu
Résoudre la cause profonde, pas le symptôme
La plupart du temps, l'IA proposera un patch qui fera rapidement taire le symptôme : ajoutez un try/catch, mettez une vérification nulle, avalez l'erreur. C'est parfois vrai, souvent dangereux ; parce que la cause originelle reste en place et surgit à nouveau d’ailleurs. À chaque correction, demandez-vous : « Est-ce que cela corrige la cause de l’erreur ou la rend-elle invisible ? » Une fois que vous avez trouvé la cause première, le correctif est généralement plus petit, plus robuste et permanent.
Attention : Avaler silencieusement une exception (catch vide) ne résout pas l'erreur ; il ne fait que dissimuler et rendre impossible un diagnostic futur. Si l’IA suggère une telle « solution », ne l’acceptez pas sans vous interroger sur la cause profonde.
Erreurs courantes
- Poser des questions sans preuves. Les phrases ambiguës poussent le modèle à l'hallucination ; Donnez l'erreur complète, la trace et la saisie.
- S'en tenir à la première hypothèse. La première suggestion de l’IA n’est peut-être pas la plus probable ; Commencez par l’hypothèse contrôlable la moins chère.
- Corriger le symptôme et manquer la cause première. L'erreur réduite au silence revient.
- Fermer le correctif sans le vérifier. Vérifiez dans des conditions de production que l'erreur disparaît réellement.
- Ne pas écrire de tests de régression. Si aucun test n’est ajouté, la même erreur reviendra silencieusement dans les versions ultérieures.
En résumé
Lors du débogage, la puissance de l'IA est directement proportionnelle aux preuves que vous lui fournissez : sans le message d'erreur complet, la trace de la pile, les entrées de déclenchement et le comportement attendu, le modèle ne fait que spéculer. Un flux discipliné : clarifier les symptômes, rassembler des preuves, générer des hypothèses, tester avec le contrôle le moins cher, corriger la cause première, vérifier et ajouter des tests de régression - ferme le bogue rapidement et définitivement. L'IA est un générateur d'hypothèses ; C'est vous qui décidez que le bug est réellement résolu.
Tâche de candidature
Choisissez un bug réel que vous avez rencontré récemment (ou reproduisez un bug de test). Effectuez d'abord l'étape de « reproduction minimale » ; Supprimez le plus petit code et l'entrée qui déclenche l'erreur. Obtenez ensuite 3 causes possibles et méthodes de test de l'IA avec le modèle « Génération d'hypothèses fondées sur des preuves ». Testez vous-même l'hypothèse la moins chère, trouvez la cause première, corrigez-la et enfin écrivez un test de régression qui détectera ce bug à l'avenir et vérifiera que le test est réellement défectueux.
liste de contrôle
- [ ] Je réduis l'erreur au plus petit échantillon reproductible avant de la déplacer vers l'IA.
- [ ] J'ajoute le message d'erreur complet, la trace de la pile, l'entrée et le comportement attendu à l'invite.
- [ ] Je commence par le contrôlable le moins cher, sans m'enfermer dans une seule hypothèse.
- [ ] Je vérifie que j'ai résolu la cause première plutôt que de corriger le symptôme.
- [ ] J'observe que le correctif corrige réellement le bug.
- [ ] J'ajoute un test de régression pour chaque bug résolu.