La trace entière
Pas seulement la dernière ligne. La cause réelle est souvent au milieu de la pile, et le premier « caused by » vaut souvent tout le reste du message.
1 · L’entrée
Donner une erreur qui serve à quelque chose
La qualité du diagnostic dépend directement de ce que tu fournis. « Ça marche pas » oblige l’agent à deviner, et il devinera une cause plausible plutôt que la vraie.
✗ Ce qui produit des suppositions
Aucun élément vérifiable. L’agent va proposer les trois causes les plus courantes sur Internet, au hasard.
Mon build plante, tu peux regarder ?✓ Ce qui produit un diagnostic
Le message exact, le contexte, ce qui a changé, ce que tu as déjà éliminé.
Erreur au build depuis mon dernier commit :
[colle la stack trace COMPLÈTE, pas juste la
dernière ligne]
Contexte : Node 22, pnpm, build OK en local
mais échoue en CI.
Ce qui a changé : j'ai ajouté le package X.
Déjà éliminé : cache CI vidé, lockfile régénéré.Ce qui a changé
La plupart des bugs apparaissent après une modification. Dire ce que tu as touché en dernier réduit énormément l’espace de recherche.
Ce que tu as déjà écarté
Sinon l’agent te propose exactement ce que tu viens d’essayer. C’est le premier motif d’agacement en debugging assisté.
L’écart attendu / obtenu
« Devrait retourner 200 avec le user, retourne 500 avec ce message. » Sans les deux moitiés, l’agent ne sait pas ce qui compte comme réussite.
L’environnement
Versions, OS, local ou CI, container ou pas. Beaucoup de bugs ne vivent que dans un environnement précis, et cette info oriente tout le diagnostic.
Le fichier concerné
Si tu sais où ça se passe, dis-le. Ça évite qu’il relise trente fichiers — ce qui coûte du contexte et dilue son attention.
2 · La méthode
Reproduire, isoler, corriger, prouver
L’ordre compte. Sauter l’étape de reproduction est la source de la plupart des faux correctifs.
Reproduire d’abord
Demande un test ou un script minimal qui déclenche le bug, et vérifie qu’il échoue. Tant qu’on ne sait pas reproduire, on ne sait pas non plus si on a corrigé quoi que ce soit.
Si le bug n’est pas reproductible, c’est en soi le premier problème à traiter :
logs supplémentaires, conditions précises, jeu de données réel.
Exiger la cause avant le patch
« Explique-moi la cause racine avant de proposer quoi que ce soit. » Si l’explication est vague ou ne colle pas au code que tu lis, ne le laisse pas corriger : il va traiter un symptôme.
Corriger au bon endroit
Le correctif doit viser la cause, pas l’endroit où l’erreur devient visible. Un
if (x == null) return ajouté là où ça plante masque souvent un
problème né trois couches plus haut.
Prouver, et verrouiller
Le test de reproduction doit passer, et le reste de la suite aussi. Garde ce test : c’est lui qui empêchera le bug de revenir dans six mois.
3 · Le piège
La spirale des tentatives
Le scénario classique : l’agent propose un correctif, ça ne marche pas, il en propose un autre, puis un autre. Au bout de cinq tours, ton code a cinq modifications et personne ne sait laquelle sert à quoi.
Le mécanisme est logique : à chaque échec, l’agent essaie la piste suivante par ordre de probabilité — sans jamais remettre en cause son hypothèse de départ, ni retirer ce qu’il a ajouté avant.
Résultat : du code défensif empilé, des try/catch ajoutés « au cas
où », et un bug qui a parfois juste changé de forme.
Trois tentatives sans amélioration mesurable. Des ajouts défensifs qui ne
correspondent à aucune cause identifiée. Des explications qui changent à chaque
tour. Ou la phrase « essayons plutôt ceci » sans nouveau diagnostic.
1
Arrête après deux échecs
Au troisième, ce n’est plus du debugging, c’est de la loterie. Reviens à l’état propre avec git.
2
Repars d’un contexte neuf
La session est polluée par les hypothèses ratées. Une session propre avec un résumé factuel donne souvent la réponse immédiatement.
3
Change de mode de pensée
Demande trois hypothèses concurrentes et un moyen de départager chacune, plutôt qu’un correctif de plus.
4
Reprends la main
Sur un bug tordu, lis le code toi-même dix minutes. L’agent est excellent pour explorer, pas toujours pour comprendre un système que tu connais mieux que lui.
4 · Prompts
Trois demandes qui débloquent
Un correctif sans diagnostic n'est pas un correctif, c'est un pansement sur un symptôme. Il reviendra — souvent au pire moment.
La règle qui évite la spiraleDiagnostic sans correctif
Voici l'erreur complète : [trace]
Contexte : [versions, environnement, ce qui a changé]
Déjà écarté : [ce que tu as testé]
Ne corrige RIEN pour l'instant.
1. Explique-moi la cause racine, en citant les lignes
de code concernées.
2. Donne-moi 3 hypothèses possibles, classées par
probabilité, avec pour chacune un moyen simple
de la confirmer ou de l'éliminer.
J'attends ton diagnostic avant toute modification.Forcer la reproduction
Avant toute correction, écris le test le plus petit
possible qui reproduit ce bug.
Lance-le et montre-moi qu'il échoue, avec la sortie.
Si tu n'arrives pas à le reproduire, dis-le clairement
au lieu de proposer un correctif : on cherchera
d'abord les conditions exactes du bug.Sortir de la spirale
On repart de zéro sur ce bug. J'ai annulé toutes les
modifications précédentes.
Faits établis :
- symptôme : [ce qu'on observe]
- ce qui NE marche PAS comme piste : [tentatives ratées
et pourquoi elles ont échoué]
Reprends le problème sans partir des hypothèses
précédentes. Commence par relire le code concerné
et dis-moi ce que tu comprends du flux réel.Vérifie que c’est acquis
L’agent propose un correctif, tu l’appliques, le bug persiste. Il en propose un deuxième, puis un troisième. Que fais-tu ?
Après deux échecs, la session est polluée par les hypothèses ratées et le code par
les tentatives. Changer de modèle sans nettoyer garde le même contexte biaisé. Revenir
à un état propre et redonner uniquement les faits établis débloque bien plus souvent.
À retenir
Diagnostic d’abord, correctif ensuite
Donne la trace complète et ce qui a changé, exige une reproduction qui échoue, demande la cause racine avant tout patch, et arrête-toi après deux tentatives ratées. Un bug corrigé sans cause comprise revient toujours — souvent au pire moment.