Comment j'ai construit un système d'agentic coding qui n'a pas besoin de moi pour le babysitter

La plupart des gens qui utilisent l'IA pour coder s'y prennent mal. Pas parce qu'ils choisissent le mauvais modèle ou écrivent de mauvais prompts. Parce qu'ils essaient de shortcut jusqu'au résultat sans construire le système qui rend le résultat bon.

J'ai passé quelques mois à faire exactement ça. Prompt, fix, re-prompt. J'avançais, mais pas de façon fiable. Puis j'ai changé de question.

Au lieu de demander « comment est-ce que je fais en sorte que cet agent fasse ce que je veux ? », j'ai commencé à demander « comment est-ce que je construis quelque chose où je n'ai à me montrer que pour les décisions qui ont réellement besoin de moi ? ».

Ça, c'est le vrai objectif : un système humain-dans-la-loop. Pas micromanager chaque output. Pas rubber-stamper du code que tu n'as pas lu. Se présenter aux checkpoints critiques, et laisser tout le reste tourner.

Voilà comment je l'ai construit.

Ce que « humain dans la loop » veut vraiment dire

Le terme est balancé à toutes les sauces. L'équipe de Martin Fowler chez ThoughtWorks le définit comme structurer les workflows IA pour que les humains restent dans la chaîne de décision à des moments qui comptent. Pas comme un bottleneck sur chaque ligne de code, mais comme un checkpoint sur les décisions qui importent.

Le failure mode, c'est d'essayer d'être dans la loop partout. Si tu review chaque ligne qu'écrit un agent, tu n'as rien gagné. Tu es juste devenu un compilateur plus lent. Le but, c'est d'ingénierer le système pour que tu puisses te retirer en confiance du travail à bas enjeu et rester présent pour les appels à haut enjeu.

Y arriver, c'est un processus de construction, pas un réglage que tu flips.

Commencer par la codebase, pas par le prompt

Ça, c'est la partie que presque tout le monde skip.

Matt Pocock a planté le clou dans une vidéo récente : ta codebase, bien plus que ton prompt, c'est ce qui influence le plus ce que l'IA produit. Une codebase confuse produit un output confus. Ça ne se fixe pas avec un meilleur prompting.

Les choses qui font le plus mal aux agents :

• Des fichiers et modules qui ne reflètent aucun grouping logique
• Aucun moyen rapide de savoir si un changement a marché (l'agent edit quelque chose et n'obtient aucun signal)
• Du naming incohérent à travers les composants

Ce dernier point importe plus que ce que les gens imaginent. J'ai demandé directement à Claude : qu'est-ce qui rend facile pour toi de composer un écran à partir d'une lib de composants existante ? Voilà un bout de ce qu'il a répondu :

Des interfaces de props claires et self-documenting. Quand je vois <Button variant="primary" size="lg" disabled>, je sais instantanément quoi faire. Quand je vois <Button style={complexStyleObject} onPress={...} customRenderer={...}>, je galère plus. Moins de props bien nommées battent plein de props configurables.

Des conventions de naming cohérentes. Si ton Button utilise variant, ton Card aussi. Si l'un utilise size="lg" et l'autre size="large", je vais faire des erreurs.

Les molecules sont mon sweet spot. Les atoms purs sont trop bas niveau : je finis par réinventer ton design system. Les templates complets sont trop rigides. Les molecules comme <FormField label="Email" error={...}> tapent au milieu : elles encodent des décisions de design mais laissent la composition flexible.

J'ai donc refactoré. Naming de props unifié à travers la lib de composants. Design system extrait dans un package séparé à l'intérieur du monorepo. Chaque module doté d'une interface propre.

La différence sur la qualité de l'output a été immédiate. Pas parce que j'ai mieux prompt. Parce que l'agent avait un meilleur matériau avec lequel travailler.

Skills vs MCPs : la question du budget de contexte

Ça m'a pris un moment à comprendre correctement.

Un MCP (Model Context Protocol) expose des systèmes externes comme des outils appelables. Quand tu connectes le MCP Playwright, Claude voit 50+ signatures de fonctions injectées dans le contexte à chaque tour : browser_click, browser_navigate, browser_screenshot... Que tu en aies besoin ou non. C'est un bout non négligeable de ton budget de contexte, alloué en permanence.

Une skill, c'est différent. C'est un fichier Markdown : un nom, une description, un set d'instructions. Elle ne se charge dans le contexte que quand l'agent décide qu'elle est pertinente pour la tâche en cours. Le reste du temps, elle n'existe pas.

Prends Playwright comme exemple concret. Playwright a à la fois un MCP et un CLI. Si tu utilises le MCP, tu te coltines ces 50+ signatures de fonctions en contexte tout le temps. Si tu écris une skill à la place (« voilà comment lancer les tests Playwright, voilà la commande CLI, voilà comment interpréter l'output »), l'agent lit ce fichier une fois au moment de lancer les tests, puis il disparaît. Même capacité, une fraction du coût.

La même logique s'applique à travers toute la stack. Les conventions de navigation, les règles de la lib de composants, comment gérer les env vars, le setup CI : tout ça n'a pas besoin d'exécution en live. C'est du savoir que l'agent lit une fois. Les Skills gèrent ça bien. Les MCPs, c'est pour quand tu as réellement besoin que l'agent appelle une API externe ou interagisse avec un système live au milieu d'une tâche.

J'utilise encore des MCPs. Juste moins, pour les choses que seuls eux peuvent faire.

/feedback : arrêter de perdre les bonnes idées

On a tous vécu la même expérience : un insight sharp à 23h, un souvenir vague deux jours plus tard, plus rien d'utile une semaine après. Le point de friction qui aurait dû changer ta façon de travailler disparaît juste parce que tu étais deep dans autre chose quand il est arrivé.

J'ai donc ajouté /feedback à Claude Code. Quand quelque chose dans le workflow m'énerve, je le lance sans quitter le terminal. Ça crée une issue GitHub avec les bons labels automatiquement. Claude va aussi le suggérer pendant une session quand il détecte une friction répétée ou des échecs inattendus. Et /feedback-triage me laisse traverser le backlog et décider de ce sur quoi agir vraiment.

Les petites choses se font capturer maintenant. Une API de composant confuse. Un pattern de spec qui cause encore et encore des malentendus. Une tâche qui a tourné parfaitement et qui devrait devenir un template. Rien de tout ça ne demande de switcher de contexte ou de se rappeler de l'écrire plus tard.

Avec le temps, ça se transforme en quelque chose : les rugosités se lissent, et ce qui marche se codifie. Pas parce que je suis devenu plus discipliné. Parce que l'outillage a arrêté d'exiger de la discipline pour être utilisé.

Ce que ça donne réellement au quotidien

Le but n'est pas de ne jamais toucher au code. C'est de toucher le bon code, au bon moment.

La plupart des matins, j'écris des specs. Je réfléchis à à quoi ressemble le done, quels sont les edge cases, ce que l'agent ne doit explicitement pas faire. C'est le travail le plus précieux que je fais : une spec serrée tourne proprement, une spec vague me coûte une heure de back-and-forth.

Pendant la journée, les agents taffent. Je reviens checker aux checkpoints que j'ai bâtis dans les specs : après la décision d'architecture, après la première version qui marche, avant que quoi que ce soit touche la production. Pas après chaque fichier.

À la fin de la journée, je review l'output et je log ce qui vaut le coup d'être gardé. Ça prend quinze minutes.

Le système n'est pas fini. Il ne le sera pas. C'est ça le point. Ce qui comptait, ce n'était pas de trouver le setup parfait, c'était de construire quelque chose conçu pour s'adapter.

Dans six mois, la moitié de ce que j'ai écrit ici sera peut-être outdated. Les pratiques qui tiennent sont celles construites autour de la capture de ce qui casse, pas celles qui assument que les outils restent les mêmes.