Les boucles de codage agent : de la commande Bash en une ligne à /goal, les vérifications et les arrêts définitifs.

Une seule phrase de Peter Steinberger a dominé la discussion sur l’encodage par IA en juin 2026 et a atteint deux millions de vues : les agents de codage ne devraient plus être sollicités manuellement, et ce sont plutôt les boucles qui sollicitent ces agents qui devraient être conçues. Les réponses ont donné lieu à un débat sur ce que cela signifie. Lorsqu’on a demandé à quoi cela ressemblait en pratique, la réponse la plus citée a plaisanté en disant que seules deux personnes le savaient. C’est amusant, mais faux. L’idée n’est pas mystique, et la manière d’y parvenir consiste en un seul ordre.

Plutôt que de débattre du fait que l’ingénierie des prompts soit morte, la démarche utile consiste à en créer un, en partant d’une ligne qui peut être collée en cinq minutes.

Trois points suffisent pour comprendre le reste :

• Une boucle est un script qui envoie une instruction à l’agent, examine la sortie, détermine si la tâche est terminée et la répète en cas contraire. L’humain n’est plus présent pour taper des instructions au sein de ce cycle. La boucle est écrite une seule fois, et le modèle agit comme une sous-routine à l’intérieur d’elle.
• La boucle la plus simple et utile se résume à une ligne de bash, et la plus efficace est une commande contenant un seul slash. Aucun cadre d’orchestration n’est nécessaire pour la lancer, et commencer sans en utiliser est une erreur.
• Ce qui distingue une boucle qui fonctionne d’une autre qui épuise un budget réside en deux éléments : un moyen de tester sa propre sortie par rapport à une vérité externe, et des arrêts clairs qui la font cesser.

Une définition et une échelle

Boris Cherny a créé Claude Code, et selon ses dires, Claude Code a rédigé chacune de ses propres contributions au cours du dernier mois, soit 259 demandes de fusion, alors que son IDE a été désinstallé depuis novembre. Il décrit simplement la méthode : il ne sollicite plus Claude, les boucles s’exécutent et décident seules de la suite, et son travail se limite à écrire ces boucles.

Son échelle à trois barreaux rend cette idée concrète. Il y a un an, le travail se faisait sous forme de code manuscrit avec complétion automatique. Puis sont apparues plusieurs sessions d’agents en parallèle, chacune initiée manuellement. Aujourd’hui, c’est le programme qui donne des instructions à l’agent, et l’ingénieur peut s’occuper d’autre chose. Le travail a progressé d’un niveau, en passant de l’écriture de code à l’écriture de ce qui écrit du code. Il précise que cela ne met pas les ingénieurs au chômage : quelqu’un doit toujours décider de ce qui sera construit, les bons ingénieurs restent essentiels, et la vérification des résultats est toujours importante. Les frappes au clavier ont disparu, mais le jugement est resté.

Le plus petit boucle : une ligne de bash

Tout le concept tient dans une seule ligne, et la lancer une fois permet de s’en faire une idée. On l’appelle la boucle Ralph, d’après Ralph Wiggum, et Geoffrey Huntley l’a popularisée en 2025.

while :; do cat PROMPT.md | claude -p --dangerously-skip-permissions; done

C’est tout. Le même fichier de prompt est fourni à Claude Code en mode headless, l’agent fonctionne jusqu’à ce qu’il s’arrête, puis le cycle reprend avec un prompt identique. Une exécution ne se souvient jamais de la précédente, elle se réoriente donc à partir des fichiers, de la liste de contrôle et des commits laissés par les exécutions antérieures. Il n’y a ni framework ni machine à états impliqués, seulement une boucle infinie autour d’un agent de codage.

Faites attention avant de le coller : le paramètre qui permet d’éviter les demandes de permission est aussi direct que son nom l’indique, et l’agent exécutera les commandes sans demander d’autorisation. Un arbre de travail git ou un conteneur jetable, sur une branche dont on peut se passer, est l’endroit approprié, jamais le branch principal.

La finesse réside dans l’habitude, pas dans le code. Plutôt que de laisser une conversation volumineuse devenir obsolète, chaque itération part d’un ensemble fixe de fichiers de référence. Le fichier de prompt nomme toujours les mêmes documents, généralement une spécification et une liste de contrôle que l’agent coche et enregistre au fur et à mesure de son travail. Ainsi, chaque nouvelle tentative débute de manière ciblée, et l’enregistrement des progrès à chaque tour empêche l’agent de s’égarer ou de refaire du travail déjà terminé.

Un procédé aussi rudimentaire en vaut-il la peine ? Une équipe lors d’un hackathon de Y Combinator a créé six dépôts en une seule nuit en utilisant une boucle Ralph, pour un coût d’environ 297 dollars en API, ce qu’ils ont évalué à près de cinquante mille dollars de main-d’œuvre de prestataires. Huntley a également développé un petit langage de programmation entier de cette manière. En tant que jouet, cette approche simple devient rapidement insuffisante, mais elle permet d’apprendre les principes fondamentaux en une demi-minute.

Le problème, c’est que ceux qui maîtrisent le mieux ce sujet le considèrent comme quelque chose d’obsolete. La boucle Ralph part du principe que la terminal reste ouverte et ne vérifie jamais si la tâche est terminée. Elle s’exécute donc indéfiniment, et les deux sections suivantes abordent ce point.

Une seule commande : /goal et /loop

Il n’est pas nécessaire d’écrire le bash manuellement. Claude Code propose deux commandes qui encapsulent cette même boucle de manière plus sûre.

La commande /goal fait en sorte que l’agent continue de fonctionner jusqu’à ce qu’une condition prédéfinie soit remplie, et c’est justement cette condition qui constitue l’essentiel du mécanisme.

/goal all tests in test/auth pass and the lint step is clean,
      or stop after 20 turns

Ce qui le distingue de la structure while-true, c’est l’étape suivante. Lorsque chaque tour se termine, Claude Code transmet la condition ainsi que la conversation à un petit modèle rapide distinct, par défaut Haiku, qui répond par oui ou non et donne une raison. En cas de réponse négative, cette raison est renvoyée comme guide pour le tour suivant. Le modèle de travail ne peut jamais déclarer avoir terminé son travail.

La limitation la plus importante est que le juge ne réalise pas de tests et ne consulte pas le répertoire de code. Il ne voit que le compte rendu, ce qui signifie que la condition doit être prouvée à partir des propres résultats générés par l’agent. Le fait d’avoir réussi les tests situés dans le dossier d’authentification suffit, car l’agent les a exécutés et le résultat figure dans la conversation. En revanche, une affirmation selon laquelle l’authentification est fiable ne suffit pas, puisque rien dans le compte rendu ne peut le confirmer. Le juge lit les reçus sans auditer le code ; par conséquent, la véritable vérification reste une commande réellement exécutée par l’agent, le juge se contentant de déterminer si le reçu indique un résultat positif.

Une condition de validité définit un état final mesurable et précise comment l’agent le manifestera dans sa sortie. Améliorer la vérification d’authentification n’en est pas une condition. Le fait que les tests d’authentification réussissent, qu’il n’y ait pas de sortie du commandement de test et que le statut Git ne montre que des modifications dans les fichiers d’authentification en fait une condition, car chacune de ces clauses apparaît dans le transcript comme un commandement exécuté par l’agent. Ajoutez une limite, comme s’arrêter après 20 tours, ainsi qu’un drapeau indiquant le nombre maximal de tours en tant que mesure de sécurité, afin qu’un exécution non surveillée ne puisse pas durer indéfiniment.

Une exécution unique non surveillée utilise le mode sans interface avec ce drapeau et l’objectif entre guillemets. Le processus doit rester actif pendant son exécution, il a donc besoin d’une terminal ouverte ou d’un serveur, et non d’un ordinateur portable fermé. Pour fermer le couvercle, Claude Code dans le cloud est la solution. Ctrl+C met fin prématurément à une exécution locale.

Une exécution courte en pratique, avec deux tours et environ quarante cents, se présente comme ceci.

> /goal all tests in test/auth pass, npm test exits 0, or stop after 15 turns

◎ /goal active · turn 1
  ran: npm test
  ✗ 2 failing in test/auth/login.test.ts
  judge: not done, expired-token case still throws◎ /goal active · turn 2
  edited src/auth/token.ts
  ran: npm test
  ✓ 41 passing, exit 0
  judge: done, npm test exits 0 and only auth files changed✓ goal achieved · 2 turns · ~$0.40

Tout y est visible : l’agent effectue la vérification, le résultat est inscrit dans le procès-verbal, puis le juge le lit et décide si la procédure se poursuit ou s’arrête.

La commande /loop est l’équivalent planifié qui assure un suivi continu. L’exemple de base de Cherny vaut la peine d’être copié, en modifiant simplement les noms propres.

/loop babysit all my PRs. Auto-fix build issues, and when
      comments come in, use a worktree agent to fix them.

Il se répète à intervalles réguliers, traite tout ce qui est nouveau depuis le passage précédent, et continue jusqu’à ce que quelqu’un l’arrête ou qu’il constate que le travail est terminé. Il s’agit de sondage et non de gestion d’événements, ce qui suffit pour surveiller les demandes de fusion et corriger les dysfonctionnements. Ce qui est enregistré, c’est l’intention et le comportement de cessation, sans les étapes détaillées.

La vérification automatique en fait un outil fiable

Un boucle qui écrit du code sans jamais le vérifier commet des erreurs de plus en plus fréquentes. Il doit tester son résultat à l’aide de quelque chose d’externe et d’objectif, et non en se basant sur sa propre interprétation.

Les personnes qui gèrent ces processus s’accordent sur un principe : c’est un contrôle externe, et non l’évaluation propre au modèle, qui détermine si la tâche est terminée. La boucle se poursuit jusqu’à ce que docker build réussisse, que le conteneur démarre et que la vérification de santé soit réussie ; dans ce cas, l’indication de l’agent selon laquelle tout semble en ordre n’a plus aucune valeur. Des critères objectifs remplacent les impressions subjectives. En pseudocode, un corps de boucle solide ressemble à ceci.

loop:
  agent: make progress on the task
  run:   npm test  (or the build, or the linter)
  if check passes:   done, exit
  if check fails:    feed the failure back, try again
  if no progress in N tries, or budget hit: stop and ping me

Les utilisateurs de production apportent deux améliorations. La première consiste à faire examiner le code par un modèle différent de celui qui l’a écrit, car un modèle a ses propres points aveugles et un nouvel examinateur peut détecter ce que l’auteur a manqué. Dan Kornas a créé roborev à cette fin : il examine chaque modification en arrière-plan et envoie ses constatations à l’agent tant que le contexte est encore frais. La seconde amélioration consiste à effectuer au moins deux passes d’examen, même si la première est sans erreur, et à limiter le nombre de tours à cinq ou six afin que le cycle ne puisse pas osciller indéfiniment.

Le cycle n’est pas là où réside la magie ; c’est le feedback qu’il contient. Avec une vérification réelle, il fonctionne comme un moteur, tandis qu’en l’absence de celle-ci, il ne génère qu’une facture.

Des garde-fous pour préserver le budget

Avec une génération de code presque gratuite, les coûts se déplacent vers la boucle qui la met en œuvre, et une boucle sans limites représente un véritable risque financier. Uber a limité chaque ingénieur à 1 500 dollars par outil et par mois pour Claude Code et Cursor, après avoir épuisé tout son budget annuel consacré à l’IA en quatre mois seulement. Ce que craignent les équipes de production, c’est la boucle qui ne s’arrête jamais, où un terminal oublié se transforme en une facture à quatre chiffres d’ici le matin.

Toute boucle sérieuse comporte ces trois arrêts obligatoires, et il est essentiel que tous soient en place avant qu’elle ne soit exécutée sans surveillance.

max_iterations:   stop after N turns           (the runaway cap)
no_progress:      stop if M turns change nothing (the stuck cap)
budget_ceiling:   stop at $X or T tokens         (the wallet cap)
on_stop:          ping me with the state and the reason

La commande /goal donne presque gratuitement le plafond de dépenses non contrôlé, en ajoutant une condition de arrêt après 20 tours ainsi qu’un flag de tour. Les deux valeurs restantes doivent être ajoutées manuellement. La détection d’un manque de progression n’est pas intégrée par défaut ; l’approche la plus simple consiste à utiliser un hook Stop ou un petit wrapper qui compare les résultats de git diff --stat entre les tours et arrête après quelques tours sans modification. Un plafond budgétaire doit faire partie des contrôles de dépenses du fournisseur, sous forme d’une limite en dollars fixée une fois dans la console avant que n’ait lieu la boucle. Cela peut sembler évoquer l’idée d’écrire des boucles pendant que mille agents construisent une entreprise en une nuit, mais en pratique, la majeure partie des efforts d’ingénierie vise à s’assurer qu’elles s’arrêtent.

L’élément interne est une compétence

La boucle n’est que le mécanisme de base, tandis que la partie précieuse est ce qu’elle permet d’accomplir.

Steinberger réitère un deuxième conseil qui a plus d’impact à long terme. Tout ce qui est fait à deux reprises devient une compétence réutilisable, et tout ce qui est difficile devient une compétence une fois résolu, ce qui permet de réaliser la tâche suivante sans effort. Un boucle qui redécouvre à chaque itération comment exécuter des tests, localiser les paramètres de configuration et formater les résultats oblige le modèle à réapprendre le projet indéfiniment. Une autre boucle qui fait appel à une petite bibliothèque de compétences éprouvées et nommées, comme l’exécution d’un ensemble de tests, l’ouverture d’une demande de fusion selon le style de l’équipe ou le déploiement sur l’environnement de préparation, s’améliore progressivement, car chaque itération commence déjà avec des compétences acquises. Cela coûte moins cher et entraîne moins d’écart. Ce sont les compétences qui ont de la valeur, et la boucle se contente de les invoquer dans l’ordre.

Boucles qui supervisent d’autres boucles

À la frontière, et c’est ce que Steinberger et Cherny entendent réellement, des boucles surveillent d’autres boucles. Une boucle de supervision attribue des tâches à de nombreux agents en même temps, les surveille et choisit l’étape suivante, tout en maintenant un état fiable basé sur Git afin qu’une panne ne mette pas fin à tout. Le projet open source Gas Town de Steve Yegge l’illustre : vingt à trente instances de Claude Code sont gérées par un agent maire tandis que des agents de patrouille effectuent des boucles en continu. Les workflows dynamiques de Claude Code représentent la forme packagée, où l’agent écrit le script d’orchestration et gère une flotte d’agents secondaires.

Nul ne commence par là. L’ordre est d’abord un /objectif, puis une auto-vérification, ensuite les trois limites maximales, et l’orchestration n’intervient que lorsque une seule boucle ne peut pas gérer les tâches, ce qui se produit plus tard que ne le suggèrent les promesses.

Une première boucle cette semaine

1. Testez la vérification manuellement sur une branche temporaire. Créez une branche comme loop-test et exécutez vous-même la commande de test, en vous assurant qu’elle se termine avec un code de sortie différent de zéro en cas de problème. Là où l’agent ne peut pas distinguer un résultat positif d’un résultat négatif, le juge ne le peut pas non plus.
2. Choisissez une tâche délimitée avec une ligne d’arrivée claire. Un test instable, une petite migration ou une opération de nettoyage de code conviennent. Évitez tout ce dont l’achèvement dépend du jugement subjectif.
3. Formulez-le comme un /goal avec une limite. Utilisez une commande concrète et non une description vague, par exemple une appelation sans interface avec un plafond de 15 tentatives, une condition spécifiant les tests d’authentification, un code de sortie égal à zéro depuis la commande de test, ainsi qu’une arrêt après 15 tentatives.
4. Vérifiez que l’agent peut exécuter la vérification du début à la fin. Les dépendances doivent être installées, rien ne doit attendre une touche, et une échec doit entraîner un code de sortie différent de zéro. Les premières exécutions s’arrêtent silencieusement à cet étape.
5. Restez présent pour la première exécution. Observez où le juge indique que la tâche n’est pas terminée et comment l’agent réagit à une vérification échouée. Ctrl+C permet de l’arrêter.
6. Fixez des limites de dépenses avant de laisser quoi que ce soit fonctionner sans surveillance. Une limite stricte en dollars pour l’espace de travail dans la console, ainsi qu’un plafond de tours par exécution : le premier élément empêche les dérives, le second limite les pertes progressives.
7. Conservez la partie répétitive sous forme de compétence. La commande de test, les étapes de la demande de fusion ou toute explication récurrente sont placées dans un SKILL.md afin que le prochain cycle parte de la compétence acquise.

À la fin de la semaine, il y a un travail réel que personne n’a tapé, une boucle qui s’auto-vérifie et s’auto-corrige, ainsi qu’une limite qui empêche qu’elle ne dépasse un point critique. C’est toute la pratique en miniature.

La réponse à la question de savoir ce qu’est une boucle n’a rien à voir avec la disparition de l’ingénierie des prompts. Il s’agit simplement de sortir de l’intérieur du cycle : écrire la boucle une seule fois, y ajouter une vérification réelle et des compétences réutilisables, en fixer une limite pour qu’elle s’arrête, puis consacrer l’attention ainsi libérée à décider de ce à construire. Steinberger et Cherny décrivent le même phénomène sous deux angles, et aujourd’hui, l’entrée principale se résume à une seule commande slash.

Lectures complémentaires

• Notes pratiques : 21 patterns de conception agents expliqués simplement — Guide pas à pas des Notes pratiques : 21 patterns de conception agents expliqués simplement : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes qui utilisent ce pattern.
• Un environnement de test pour Claude Code : environnements d’agents isolés sur un ordinateur portable — Comment un environnement local Kubernetes fournit aux agents de codage leur propre machine, des identifiants ciblés, une liste d’autorisation d’égress et une vue d’ensemble du groupe, avec les avantages et inconvénients de la création personnalisée par rapport à l’achat.

Ornith-1.0 : modèles de codage à poids ouverts allant de 9B à 397B sous licence MIT — Ce que la version Ornith-1.0 affirme sur SWE-Bench et Terminal-Bench, la manière dont elle entraîne le squelette avec la solution, et ce que cela pourrait signifier pour les agents de codage fermés.