C'est ce que me disait mon reviewer Opus apres avoir implemente une story.
Sauf que le Docker test derriere trouvait 3 regressions.
Vous connaissez le scenario : vous decrivez un bug a votre assistant IA. Il modifie un fichier. Les tests echouent. Il modifie le meme fichier autrement. Toujours rouge. Il ajoute un try/except. Dix minutes et 50 000 tokens plus tard, votre code est dans un etat pire qu'au depart.
Ce comportement a un nom : le flailing. L'IA tâtonne sans comprendre, comme un developpeur junior qui modifie des trucs au hasard en esperant que ca passe au vert.
Le probleme n'est pas l'IA. Le probleme, c'est qu'on lui demande de resoudre un bug sans methode.
Le vrai probleme : on a automatise le chaos
Quand un developpeur senior debug, il ne commence pas par modifier du code. Il observe. Il lit la stack trace. Il remonte la chaine d'appels. Il formule des hypotheses. Il les confronte aux faits. Et seulement apres, il touche au code.
Quand on donne un bug a une IA sans framework, on saute directement a l'etape "modifier du code". On supprime tout le raisonnement qui fait la difference entre un patch qui tient et un hack qui explose en production trois jours plus tard.
J'ai passe les derniers mois a construire un pipeline structure pour corriger ca. Il s'appelle dev-bugfix-pipeline, c'est une skill pour Claude Code, et il est en open source.
L'idee : forcer l'IA a reflechir avant d'agir
Le pipeline impose une discipline en 5 phases — de la description du bug jusqu'au commit. L'IA n'a pas le droit de toucher au code avant d'avoir traverse un processus de diagnostic rigoureux.
Phase 1 — Diagnostic structure
Pas de code. Que du raisonnement.
Au lieu de laisser l'IA sauter sur la premiere explication plausible, le pipeline lui impose le diagramme d'Ishikawa adapte au software. Elle doit generer 5 a 7 hypotheses reparties sur 7 categories : Logique, Donnees, Interface, Environnement, Architecture, Concurrence, Historique.
Pour casser l'anchoring bias. Sans cette contrainte, un LLM s'ancre sur la premiere hypothese qui semble tenir et ne lâche plus. En le forcant a explorer des categories qu'il n'aurait pas envisagees (concurrence ? historique de migrations ?), on obtient des diagnostics nettement plus fiables.
Ensuite, pour chaque hypothese, l'IA produit des arguments POUR et CONTRE — une technique issue de la recherche FVDebug de NVIDIA sur le debugging assiste par LLM. Et enfin, les 5 Whys de Toyota sur les 3 meilleures hypotheses pour creuser jusqu'a la cause racine.
Quand l'IA arrive a l'implementation, elle a une comprehension profonde du probleme. Pas juste "cette ligne crashe", mais "cette ligne crashe parce que le contrat d'interface a change lors de la migration Pydantic v2 et que le middleware d'erreur ne gere pas le nouveau format de validation".
Phase 2 — Validation humaine
Le diagnostic est presente au developpeur en 2-3 rounds de questions ciblees. L'IA ne decide pas seule — elle guide le developpeur vers la confirmation ou la correction de son analyse.
C'est le principe d'elicitation de la methodologie BMAD : l'IA propose des hypotheses structurees, l'humain apporte sa connaissance du contexte metier que le code seul ne revele pas.
Phase 3 — Avocat du diable
Avant d'ecrire la premiere ligne de code, un revieweur adversarial challenge la solution proposee. Il argumente CONTRE la solution, identifie les risques de regression, les edge cases manques, et propose au minimum 2 alternatives.
Le verdict est trinaire : PROCEED (go), REVISE (ajuster), ou PIVOT (changer d'approche). Cette etape tourne une seule fois — pas de boucle infinie. C'est un gate, pas un comite.
Phase 4 — Implementation + Review par personas
L'implementation suit, encadree par les acceptance criteria et le diagnostic valide. Puis le code passe devant 3 revieweurs specialises en parallele : un Security Auditor, un Architecture Purist, et un Edge Case Hunter.
Chaque persona a son propre angle d'attaque et ne voit pas les findings des autres (pour eviter le biais de conformite). Un evaluateur consolide, deduplique, et priorise. S'il reste des findings critiques, le cycle recommence — mais jamais plus de 3 rounds.
Phase 5 — Le protocole Respire
Circuit breaker pour agents IA qui flail
C'est la piece dont je suis le plus fier, et elle vient d'une idee de Gael Pereur. Le constat : quand un agent IA s'enlise, lui demander de "reessayer mieux" ne marche pas. Il faut un protocole de rupture.
Respire n'est pas declenche par l'agent lui-meme — c'est l'orchestrateur qui surveille des signaux concrets :
Quand un signal est detecte, tout s'arrete. L'agent est "tue". Le protocole se deroule en 4 temps :
Pourquoi un framework "carre" est indispensable
Le point cle
L'externalisation de la detection de flailing (l'orchestrateur observe, pas l'agent) est une decision architecturale critique. C'est le meme principe que dans la vraie vie : quand vous etes dans le trou, vous ne voyez pas la sortie.
En pratique
La skill s'utilise directement dans Claude Code :
/dev-bugfix-pipeline _bmad-output/tech-spec-fix-parsing.md
# En mode ad-hoc (juste une description du bug)
/dev-bugfix-pipeline "json.loads plante sur les reponses Mistral wrappees en backticks"
# Mode rapide pour les bugs triviaux
/dev-bugfix-pipeline "typo dans le endpoint /api/users" -D -X -e
# Mode auto (zero confirmation, pipeline complet)
/dev-bugfix-pipeline tech-spec.md -a
Le pipeline s'adapte : il auto-detecte le projet (langage, framework de test, patterns), estime la complexite du bug, et recommande le niveau de rigueur approprie. Un typo n'a pas besoin du diagramme d'Ishikawa. Un bug de concurrence multi-module, si.
A retenir
- Un agent IA sans methode de debug va tâtonner. C'est du by design, pas de l'incompetence.
- Le diagnostic structure (Ishikawa + 5 Whys) elimine l'anchoring bias et force l'exploration.
- La validation humaine apporte le contexte metier que le code ne revele pas.
- L'avocat du diable challenge la solution AVANT l'implementation.
- Les 3 revieweurs isoles couvrent 3x plus de surface qu'un seul reviewer.
- Le protocole Respire est un circuit breaker : detection externalisee, arret force, retry differencie.
Le debugging assiste par IA, c'est comme le reste de l'ingenierie : la discipline bat le talent. Surtout quand le "talent" a tendance a halluciner.