Le Responsable de Claude Code a Arrêté de Prompter. Ce N'est Pas un Conseil. C'est une Chronologie.

Vous ne devriez plus donner d'instructions aux agents de code. Vous devriez concevoir des boucles qui donnent des instructions à vos agents.

Cette phrase m'a fait éclater de rire quand je l'ai vue. Peter Steinberger a lâché ces 12 mots sur X le 7 juin, et 6,5 millions de personnes les ont lus en 24 heures. Et 5 jours avant ça, Boris Cherny, le responsable de Claude Code, avait dit exactement la même chose sur scène lors d'un événement WorkOS. Mot pour mot, ou presque.

Ça m'a fait marrer parce que je faisais ça depuis des mois sans avoir de nom pour le décrire.

TLDR : Cherny a arrêté de donner des instructions à Claude. Son boulot maintenant, c'est d'écrire les systèmes qui donnent des instructions à Claude à sa place. Si vous avez utilisé /goal et que vous êtes partis jusqu'à ce que ça se termine, vous faisiez déjà une version de ça, sans savoir comment ça s'appelait ni à quel point l'écart entre votre version et la vraie ingénierie de boucles était énorme.

J'appelais ça le "Mode Débrouille-toi"

Le workflow était simple, peut-être embarrassant de simplicité. Je définissais un objectif dans /goal, je lâchais un CLAUDE.md avec les règles du projet, je donnais le contexte du repo à Claude Code, et je me barrais. Je revenais 20 minutes plus tard, parfois 2 heures. Soit il y avait une fonctionnalité qui marchait, soit il y avait un bordel à réparer. Les deux résultats faisaient avancer le projet.

Je ne faisais pas ça par conviction philosophique. C'est juste arrivé quand j'ai arrêté de regarder le flux de sortie et que j'ai commencé à traiter Claude Code comme un dev junior à qui je pouvais déléguer. Fixer l'objectif, donner le contexte, et se casser.

Aucune étiquette pour tout ça.

Puis Steinberger a posté, et la moitié de mon feed hochait la tête pendant que l'autre moitié débattait pour savoir si c'était vraiment nouveau ou juste du prompting avec des étapes en plus. Et le clip de Cherny d'il y a 5 jours a commencé à tourner. "Je ne donne plus d'instructions à Claude. J'ai des boucles qui tournent et qui donnent des instructions à Claude en déterminant quoi faire. Mon boulot, c'est d'écrire des boucles."

Reconnaissance, pas découverte. Je faisais déjà une version de ça. Ça a juste eu un nom.

Cette nomination compte plus qu'il n'y paraît à première lecture. Sans terme pour une pratique, vous ne pouvez pas comparer vos notes dessus, vous ne pouvez pas améliorer délibérément le pattern, et vous ne pouvez pas dire si vous le faites bien ou mal. "Mode débrouille-toi" marchait bien comme raccourci personnel. "Ingénierie de boucles", c'est quelque chose autour de quoi vous pouvez construire une méthodologie. Le concept n'a pas changé entre le 2 et le 7 juin. Ce qui a changé, c'est que maintenant tout le monde dans la même conversation utilise le même mot, et les gens qui ne le faisaient pas encore savent maintenant ce qui leur manque.

À quel échelon êtes-vous ?

Ce que Cherny a décrit au WorkOS Acquired Unplugged le 2 juin se décompose en 3 étapes d'évolution dans la façon dont les développeurs travaillent avec un agent de code.

Échelon 1 : vous utilisez Claude comme de l'autocomplétion. Plus malin que Copilot, mais vous écrivez encore du code, vous révisez chaque ligne, vous tenez l'outil. L'agent assiste. Vous dirigez chaque étape.

Échelon 2 : vous donnez des instructions à 5 ou 10 Claude en parallèle. Vous déléguez des tâches, révisez les sorties, routez entre eux manuellement. Vous êtes encore dans la boucle, juste un gestionnaire de trafic plus occupé au lieu d'un conducteur. Beaucoup de gens qui pensent être "avancés avec l'IA" sont ici et supposent qu'ils sont à l'échelon 3.

Échelon 3 : vous n'êtes pas du tout dans la boucle. Vous avez construit le système qui fait tourner la boucle pour vous. Claude n'attend pas votre prochain message. Il exécute contre des conditions, des portes de vérification, et une logique de retry que vous avez définie une fois et qui tourne maintenant sans vous. Votre boulot est passé de "écrire le prompt" à "concevoir ce qui arrive quand l'agent échoue, réussit, ou tombe sur quelque chose que vous n'aviez pas anticipé."

La différence entre l'échelon 2 et l'échelon 3 n'est pas une question de compétence en prompting. C'est architectural. Vous n'arrivez pas à l'échelon 3 en promptant mieux. Vous y arrivez en arrêtant de prompter et en encodant la logique dans quelque chose qui tourne tout seul. Pensez-y comme au problème de tower defense : arrêtez de défendre chaque position manuellement et commencez à placer des structures qui tiennent sans vous. Le prompting, c'est du combat direct. L'ingénierie de boucles, c'est construire vos tourelles avant de quitter la base.

L'écart est maintenant lisible

Le post du 7 juin n'était pas un rapport de tendance. C'était une mesure.

Quand les meilleurs praticiens d'un domaine annoncent publiquement un changement dans leur propre pratique, l'écart entre les gens qui le font déjà et tous les autres bascule d'invisible à visible. C'est ce qui s'est passé. La pratique tournait depuis des mois. Ce qui a changé, c'est que le tableau de bord est devenu public.

Le projet AutoResearch de Karpathy est la preuve concrète la plus claire au dossier. Il fait tourner 50 expériences ML pendant la nuit sur un seul GPU. L'agent modifie le code d'entraînement, l'exécute, lit les résultats, itère, aucune décision humaine dans la boucle. Il a inventé "Loopy Era of AI" exactement pour ça, dans un épisode de podcast No Priors qui a fait 875K vues contre une moyenne de chaîne d'environ 8 500. C'est un outlier 100x sur un pod IA niveau recherche. L'appétit pour comprendre ça n'est plus théorique.

Le chiffre de Cherny est plus direct : 100% de son code personnel pendant les 30 jours avant décembre 2025 a été écrit par des routines qu'il avait mises en place, pas par lui donnant des instructions à Claude directement. Et les rapports de l'industrie de juin 2026 placent Claude Code à près de 4% de tous les commits publics sur GitHub. 4% de tout le graphe GitHub public, c'est une empreinte massive, et ça n'arrive pas par des sessions de prompting manuel une par une. Ce sont des boucles qui tournent. À ce stade, faire tourner des prompts individuels pour livrer du code en production, c'est le "ça marche sur ma machine" du développement agentique.

La raison pour laquelle le timing compte plus que le concept, c'est la logique de composition, et c'est la partie que la plupart des threads d'explication sautent entièrement. Un développeur qui prompte manuellement devient meilleur en prompting, avec des itérations plus rapides et des résultats plus ciblés au fil du temps. C'est une amélioration linéaire sur une courbe d'effort linéaire, et c'est vraiment précieux. Un développeur qui encode la logique de boucle opère dans un modèle structurellement différent. Chaque boucle qu'il conçoit tourne sans lui. Chaque amélioration de cette boucle s'applique automatiquement à chaque exécution future. Une trajectoire améliore le travail qu'il fait déjà. L'autre construit un système qui gère cette catégorie pendant qu'il conçoit la boucle suivante. Ces 2 trajectoires se ressemblent presque identiquement au début. Vous ne pouvez pas les distinguer en semaine 1. Le différentiel devient visible au bout de semaines, il se compose dans la direction de la personne qui a construit la boucle, et ce n'est pas récupérable en promptant plus vite. C'est exactement ce que le moment du 7 juin a rendu lisible : le tableau de bord est devenu public, et vous pouvez maintenant à peu près dire sur quelle trajectoire vous êtes juste en regardant votre production du mois dernier.

La boucle que vous n'aviez pas nommée

Quelque chose que j'ai remarqué quand le post de Steinberger a commencé à circuler : beaucoup de développeurs qui hochaient la tête en reconnaissance n'avaient aucune idée qu'ils étaient déjà à l'échelon 3 pour certaines tâches.

/goal est déjà une boucle fermée. Vous définissez une condition d'arrêt. Claude itère jusqu'à ce qu'elle soit remplie ou qu'il tombe sur une erreur dure. Vous ne prenez pas de décisions entre les itérations. La fonctionnalité a été livrée dans Claude Code v2.1.139 en mai 2026, et les développeurs qui l'ont comprise tôt, qui ont fixé l'objectif, sont partis, et sont revenus aux résultats faisaient techniquement déjà de l'ingénierie de boucles. Je faisais tourner ça avant même que /goal existe, juste en utilisant de longues sessions avec un contexte détaillé et en espérant que Claude reste sur la tâche. Je n'avais juste pas nommé ça.

Les 3 choses qui séparent "j'ai utilisé /goal et je suis parti" d'une vraie boucle de production : un fichier de compétences qui encode les règles de qualité, une étape de vérification qui vérifie la sortie contre ces règles, et un agent de révision qui voit le résultat à neuf avant que quoi que ce soit soit livré. Vous avez peut-être déjà 1 d'entre eux sans savoir que les 2 autres existent. Beaucoup de développeurs ont un CLAUDE.md. Peu l'ont connecté à une couche de vérification. Et encore moins ont ajouté l'agent de révision, qui est là où la boucle attrape les choses que l'agent de build a rationalisées comme acceptables.

L'anatomie complète, comme Anthropic le démontre dans leur vidéo de vérification : un SKILL.md qui encode les non-négociables de votre projet, une étape de vérification navigateur qui vérifie la sortie rendue contre ces règles, et un second agent qui révise avant que quoi que ce soit soit mergé. Le CLAUDE.md que vous avez déjà écrit est la fondation, /goal tourne contre lui, et l'agent de révision filtre la sortie avant qu'elle soit livrée. Connectez ces 3 et vous avez une boucle qui tourne sans vous dans la pièce.

Pour quiconque a déjà fait le passage du vibe coding à l'encodage de la logique de projet dans les prompts, la boucle est la couche suivante de la même architecture. L'instinct de rendre explicites les règles implicites du projet et d'arrêter d'évaluer à l'œil nu la sortie après coup. La boucle fait juste tourner cette logique en mode autonome.

Note de côté qui se connecte à peine mais que je mets ici quand même. Quand j'ai appris à coder dans les années 90, on avait un Bull DPS 7000 partagé à l'école. Vieux mainframe. 1 slot de compilation à la fois, premier arrivé premier servi. Ce que j'ai compris, c'était d'écrire un script shell débile qui pollait la queue du compilateur toutes les 15 secondes et resoumettait mon job à l'instant où un slot s'ouvrait. Mon code était toujours compilé. Mes camarades de classe rafraîchissaient manuellement. Je leur ai avoué ça bien plus tard. Désolé les gars. Pas si désolé que ça, honnêtement.

L'instinct d'encoder le retry plutôt que de le faire vous-même à la main a 30 ans. Le branding est nouveau.

Votre première boucle n'a pas besoin d'une flotte

L'échelon 3 ne nécessite pas 100 agents et une couche d'orchestration. C'est la version que Karpathy fait tourner pour les expériences ML de nuit. Votre première boucle est plus simple, et vous pouvez probablement la commencer aujourd'hui.

La boucle de production minimale :

/goal "Implémenter la fonctionnalité de filtrage de produits depuis la spec. Terminé quand la suite de tests passe et qu'il n'y a pas d'erreurs TypeScript."

C'est déjà l'échelon 3 pour cette tâche. Claude tourne jusqu'à ce que la condition soit remplie ou qu'il tombe sur une erreur qu'il ne peut pas résoudre. Vous n'êtes pas entre les deux. La clé, c'est le mot "quand" dans l'objectif, parce que la condition d'arrêt doit être quelque chose que l'agent peut vérifier automatiquement, pas quelque chose que vous devez regarder et juger après.

Une boucle sans couche de vérification, c'est juste de la supposition automatisée. L'upgrade qui la rend utilisable en production :

Étape 2. Ajoutez un SKILL.md avec les non-négociables de votre projet : vos vraies règles, pour votre vrai projet, écrites comme vous brieferiez un nouveau dev le jour 1. Les conventions que vous appliquez, les cas limites qui reviennent toujours, les choses que vous attraperiez en code review 3 jours plus tard si personne ne les écrivait. Plus la règle est spécifique, plus la boucle se comporte comme quelqu'un qui a vraiment lu vos docs avant de commencer.

Étape 3. Ajoutez une étape de vérification navigateur. Claude dans Chrome ou le Chrome DevTools MCP vérifie la sortie rendue contre vos critères de qualité : layout shifts, Core Web Vitals, régressions visuelles. Des choses qui n'apparaissent pas dans les suites de tests mais qui apparaissent en production. La démo d'Anthropic montre un layout shift attrapé automatiquement, hors du scope de la tâche originale, parce que les Core Web Vitals étaient déjà dans le SKILL.md. C'est la boucle qui fait du travail que vous n'avez pas explicitement demandé, parce que vous avez encodé à quoi ressemble "bon" à l'avance.

Étape 4. Ajoutez un agent /code-review comme second passage. Cet agent voit la sortie à neuf, sans l'historique de comment elle a été construite. Il attrape les décisions rationalisées que l'agent de build s'est fait passer à lui-même, ce qu'il fera, parce que l'agent de build a fixé le même contexte pendant toute l'exécution.

Commencez avec les étapes 1 et 2 si vous voulez faire tourner quelque chose aujourd'hui. Ajoutez 3 et 4 quand la boucle de base est stable.

Je pense que l'étape qui fait trébucher la plupart des gens, et peut-être que je me trompe là-dessus mais ça colle avec chaque échec de boucle que j'ai vu, c'est la condition d'arrêt. Spécifiquement : en fixer une qui ne peut pas être vérifiée automatiquement. "Rendre l'UI polie" n'est pas une condition d'arrêt. C'est une prière. "Pas de layout shift au-dessus de 0.1 CLS" est une condition d'arrêt. Point de sauvegarde avant la porte du boss, pas après. Fixez la porte avant que la boucle commence, ou vous refaites tout le donjon. La porte doit être conçue avant de commencer, pas vérifiée quand c'est fini.

Une boucle sans porte de vérification ne fait pas gagner de temps. Elle automatise le fait d'avoir tort.

Avant que tout ça marche de façon consistante, l'échafaudage en dessous doit être solide. Spec vague, pas de couverture de tests, dépendances que vous avez héritées mais ne comprenez pas vraiment (la boucle tournera contre elles avec confiance et livrera de la merde). Le Blueprint en 8 étapes dans Vibe Coding, For Real a été construit exactement pour ça : passer de démo cassée à app déployée avant de passer l'itération à un système autonome. La boucle a besoin de quelque chose de réel contre quoi tourner.

Et quand vous êtes prêt à étendre la boucle aux systèmes externes (déclencher un déploiement, faire tourner un check de service, appeler une API), construire cette couche avec des CLI plutôt que des connecteurs MCP change à quel point cette extension finit par être debuggable et fiable en production.

Quand le tableau de bord est devenu public

Je ne savais pas que le "mode débrouille-toi" avait un nom. Je ne savais pas que ça me mettait à l'échelon 3 pour certaines tâches. Je ne savais pas que l'ère Bull DPS 7000 et l'ère Boris Cherny faisaient tourner le même instinct à 30 ans d'intervalle.

Ce qu'était vraiment le moment du 7 juin : pas le début de l'ingénierie de boucles pour les gens qui la faisaient déjà. Le moment où l'écart entre les praticiens et tous les autres est devenu visible des deux côtés. Cherny faisait tourner 100% de son code par des routines depuis décembre 2025. Karpathy lançait des expériences de nuit depuis des mois. L'écart était déjà là. Le post de Steinberger a juste rendu le tableau de bord public.

Les gens qui le faisaient déjà n'ont rien appris de nouveau le 7 juin. Les gens qui ne le faisaient pas savent maintenant que l'horloge tourne.

Le taux de composition est réel et il n'attend pas. Chaque boucle que vous concevez tourne sans vous. Chaque amélioration de la boucle s'applique à chaque exécution future. C'est une trajectoire structurellement différente de devenir plus rapide en prompting, et l'écart entre les 2 devient mesurable plus vite que la plupart des gens s'y attendent.

À quel échelon êtes-vous maintenant, et est-ce celui sur lequel vous voulez rester ?

---

Sources

• Peter Steinberger (@steipete), X, 7 juin 2026
• Addy Osmani, "Loop Engineering," addyosmani.com, 7 juin 2026
• Andrej Karpathy, Skill Issue: Code Agents, AutoResearch, and the Loopy Era of AI, podcast No Priors
• explainx.ai, "Loop Engineering: The Claude Code Guide," juin 2026
• datasciencedojo.com, "Agentic Loops: From ReAct to Loop Engineering," juin 2026
• Anthropic, How to get Claude Code to verify its own work, YouTube

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer à livrer des articles de qualité chaque jour pour votre plaisir de lecture).