Déboguer un agent de codage et refactoriser la boucle agentique d'OpenFox

🎥 Résumé analytique

🎯 Promesse cognitive

À la fin, on comprend : comment diagnostiquer un agent de codage bloqué sur un bug, le déboguer par test rouge ou reproduction réelle, puis refactoriser la boucle agentique via un document fonctionnel, une spec technique générée par l’IA, une implémentation assistée et une validation par tests.

🧩 Carte du contenu

Débogage d’un agent de codage — Deux approches pour un agent qui tourne en boucle sur un bug : faire écrire un test rouge de bout en bout et reproduire le problème dans l’application réelle via un browser skill.
Refactoring architectural en cinq étapes — Pipeline du développeur : identifier la complexité, rédiger un document fonctionnel hors code, générer une spec technique, implémenter avec l’IA, valider par pyramide de tests et tests manuels ; appliqué à l’unification de la boucle agentique d’OpenFox.

✅ Ce que la vidéo apporte en plus de la lecture de ce post

Le matériau fourni n’établit pas de contribution visuelle déterminante au-delà de ce qui peut être condensé ici. L’original peut ajouter la restitution de quelques gestes concrets difficiles à restituer par l’écrit : la formulation du prompt de test rouge, l’usage du browser skill sur l’application réelle et le passage de la spec technique à l’implémentation.

🕒 Niveau d’engagement recommandé

lecture_seule
- La méthodologie de débogage et la méthode de refactoring peuvent être condensées efficacement dans le post.
- Le gain supplémentaire du visionnage reste ciblé : prompts, interactions navigateur et séquence d’implémentation, surtout si l’utilisateur veut reproduire précisément les gestes.

Passages susceptibles de mériter l’original

01:21 — Séquence susceptible de montrer le prompt exact qui contraint l’agent à produire uniquement un test rouge, utile pour réutiliser la formulation.
05:21 — Séquence susceptible de montrer l’agent utilisant le browser skill sur l’application réelle, geste difficile à restituer entièrement par l’écrit.
13:15 — Séquence susceptible de montrer le passage de la spec technique à l’implémentation par l’agent, utile pour évaluer le niveau de contrôle humain requis.

🧰 Pistes d’exploitation et points de vigilance

1 idée à tester : Quand un agent de codage tourne en boucle sur un bug, lui demander d’écrire d’abord un test rouge qui reproduit le bug, avec une instruction qui interdit de chercher la correction.
1 notion à creuser : la boucle agentique comme point de contrôle pour repérer les responsabilités mal séparées et les chemins d’exécution dupliqués dans les projets générés par IA.
1 limite / biais : La méthode est une pratique personnelle du créateur d’OpenFox, avec une possible dimension promotionnelle, et le bug des thinking blocks de GLM 5.2 n’est pas définitivement résolu.

🔍 Déroulé détaillé et analyse critique

📄 Voir la synthèse détaillée

Déroulé structuré

Segment 1 — Débogage d’un agent de codage bloqué

Statut : Pratique personnelle rapportée ; le bug spécifique de GLM 5.2 dans OpenFox est décrit comme non résolu.

L’auteur interprète une session de 200 000 tokens sans résolution d’un bug ciblé comme un signal de complexité architecturale du code, pas seulement comme une difficulté ponctuelle.
Première approche : demander à l’agent d’écrire un test rouge de bout en bout qui reproduit le bug, afin de lui donner un critère vérifiable.
Piège identifié : l’agent peut se focaliser sur la correction plutôt que sur la création du test ; le prompt doit le cantonner explicitement à la production du test.
L’auteur recommande de démarrer la session depuis un état clean ; démarrer depuis une session déjà chargée est présenté comme une mauvaise pratique.
Pour un test réaliste, l’agent doit recevoir la forme exacte de la réponse serveur afin de mocker correctement la réponse du fournisseur.
Seconde approche : donner à l’agent un browser skill pour interagir avec l’application réelle et reproduire le bug, avec des instructions pas à pas.
Cette approche est jugée moins optimale et plus lente qu’un script Playwright, mais elle réduit l’ambiguïté.
Dans le cas montré, les thinking blocks de GLM 5.2 apparaissaient dans des requêtes complexes mais pas dans des requêtes simples ; la résolution apparente n’a pas de cause racine identifiée.
Pendant la session navigateur, l’agent n’a pas utilisé les logs du serveur de développement, approche classique de débogage relevée par l’auteur.

Segment 2 — Refactoring architectural de la boucle agentique

Statut : Information first-party du créateur d’OpenFox ; la méthode est une pratique personnelle et les choix philosophiques sont des opinions de l’auteur.

Le point de départ est la complexité architecturale : responsabilités mal définies et plusieurs chemins d’exécution pour la même fonctionnalité.
Dans OpenFox, la boucle agentique comportait quatre implémentations techniques distinctes, héritées de la phase de beta ; l’objectif est de les unifier en un seul chemin.
La boucle agentique décrite consiste à envoyer un prompt au LLM, recevoir thinking blocks, contenu et appels d’outils, exécuter les outils, renvoyer les résultats et relancer une nouvelle itération.
La méthode en cinq étapes : identifier la complexité, rédiger un document fonctionnel hors code, faire générer une spec technique par l’IA, lancer une session d’implémentation sur cette spec, puis valider via pyramide de tests et tests manuels.
Le document fonctionnel est rédigé par le développeur en langage courant, sans code ; il sert à définir les blocs logiques, les flux et toutes les branches.
La spec technique générée par l’IA fait 476 lignes et inclut diagrammes, interfaces, noms de fonctions et plan de migration en quatre phases.
L’auteur ne fait pas de code review sur OpenFox parce que l’ensemble du code est produit par l’IA ; il reconnaît que davantage de code review aurait pu éviter le refactoring, mais présente ce choix comme son arbitrage personnel vitesse-perfection.
La philosophie générale est d’abord de produire vite, puis d’entrer dans des phases de stabilisation et de refactoring pour traiter la dette architecturale accumulée.
L’auteur soutient que le rôle du développeur se déplace vers l’architecture des fonctions et des flux, avec le document fonctionnel comme artefact principal, plutôt que vers la rédaction de chaque ligne de code.
Demander à l’agent d’expliquer pourquoi une session a été difficile donne rarement la bonne réponse, selon l’auteur ; l’identification de la complexité relève de l’expérience du développeur.

Points notables

Le test rouge n’est pas seulement une validation : il sert de garde-fou contre l’agent qui saute à la correction sans reposer le problème.
La reproduction réelle via browser skill privilégie la certitude opérationnelle sur la rapidité, par opposition à un script type Playwright.
Le document fonctionnel hors code est le pivot de la méthode : c’est là que le développeur fixe les branches logiques avant la transformation technique par l’IA.
La spec technique de 476 lignes, avec diagrammes et plan de migration en quatre phases, matérialise le passage de la vision fonctionnelle au chantier technique.
L’unification des quatre chemins de la boucle agentique illustre une dette architecturale typique d’un produit développé vite avec des agents, hérité de la beta.
La distinction entre vitesse de production et stabilisation explicite est centrale : le refactoring est présenté comme la phase de traitement des irritations accumulées.

Limites & biais factuels

Méthodologie personnelle non formalisée et non testée à l’échelle, présentée par le créateur d’OpenFox.
Biais promotionnel possible : OpenFox sert à la fois d’outil de démonstration et de projet du présentateur.
Le bug des thinking blocks de GLM 5.2 est décrit comme mystérieux et non reproductible, sans cause racine identifiée.
Le titre évoque une IA locale, mais la configuration cite DeepSeek V4 Flash via API, donc le cadre local est partiel.
Les affirmations de philosophie de développement (pas de code review, vitesse-puis-stabilisation) sont des opinions de l’auteur, pas des résultats établis.