Debugging avec un agent
Un agent diagnostique et corrige un bug bien plus vite, a condition de lui donner le bon contexte (stacktrace, reproduction) et un oracle pour verifier sa correction. Diagnostic de la cause racine, test de reproduction et pieges du debugging assiste.
Diagnostiquer avant de corriger
Debugger se fait en deux temps distincts : diagnostiquer (comprendre pourquoi le code se comporte mal) puis corriger. L’erreur la plus courante, avec ou sans agent, est de sauter le diagnostic et de patcher le premier endroit qui plante.
Le symptome est l’endroit ou le bug se manifeste (l’exception, l’assertion rouge). La cause racine est la raison reelle. Corriger le symptome — ajouter un if (x != null) la ou ca crashe — fait disparaitre l’erreur visible mais laisse le defaut en place : il ressurgira ailleurs.
Point cle : Un agent suit la consigne donnee. « Fais disparaitre cette exception » pousse au patch du symptome ; « trouve pourquoi cette valeur est nulle » pousse a remonter vers la cause racine.
Le bon contexte fait la moitie du diagnostic
Un agent ne devine pas l’etat de ton systeme : il ne voit que ce que tu lui donnes. « Ca ne marche pas » est inutilisable. Plus le contexte d’erreur est precis, plus le diagnostic est rapide et juste.
| A fournir | Pourquoi |
|---|---|
| Stacktrace complete + message exact | Localise le point de defaillance et la chaine d’appels |
| Etapes de reproduction | Permet de rejouer le bug, condition d’un diagnostic fiable |
| Comportement attendu vs observe | Definit la cible : sans elle, l’agent ignore ce qui est « correct » |
| Logs, entrees, version/env | Distingue un bug de code d’un probleme de donnees ou d’environnement |
Attention : Coller un message tronque sans la stacktrace force l’agent a deviner la ligne fautive. Donne la trace entiere.
Le test de reproduction : l’oracle de la correction
La pratique la plus solide : avant de corriger, ecrire un test qui reproduit le bug. Il echoue (rouge), ce qui prouve qu’on a bien capture le defaut. On corrige jusqu’a ce qu’il passe (vert), puis on le garde en non-regression.
Point cle : Ce test est l’oracle du debugging : il definit objectivement « bug corrige ». C’est aussi une boucle fermee (closed-loop) que l’agent peut piloter seul : corrige, relance les tests, recommence jusqu’au vert.
Sans test de repro, « j’ai corrige le bug » repose sur la conviction de l’agent. Avec, c’est verifiable, et le bug ne reviendra pas silencieusement.
Standard out : rendre l’agent voyant
Un agent qui ne voit pas le resultat de ses actions est aveugle. La sortie console — stacktrace, erreurs de compilation, sortie de tests — est le retour qui lui permet de s’auto-corriger. C’est un levier fondamental d’autonomie.
Point cle : Si l’agent peut lancer la commande qui echoue et lire sa sortie (
dotnet test,dotnet build, le log), il diagnostique et corrige seul. S’il code « a l’aveugle » sans jamais executer, il devine.
Pieges du debugging assiste
Attention — masquer le symptome. Un fix qui fait disparaitre l’erreur sans expliquer la cause est suspect. Demande toujours : « quelle est la cause racine ? ».
Attention — modifier le test pour le faire passer. Si l’agent change l’assertion au lieu du code de prod, il corrompt l’oracle et masque le bug. Le test de repro ne bouge pas.
Attention — boucler sur un bug non deterministe (flakey). Si la repro n’est pas stable, l’agent peut « corriger » puis voir le test rechouer sans fin. Stabilise d’abord la repro, et fixe une limite de tentatives.
Attention — context rot sur une longue session. Apres de nombreux tours, l’agent oublie les hypotheses deja ecartees et tourne en rond. Repartir avec un contexte frais et un resume des pistes mortes est souvent plus rapide.
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.