Note de la rédaction : La manière d'utiliser les agents de codage IA évolue, passant de « l'humain rédigeant manuellement des prompts et avançant la tâche tour par tour » à « l'humain concevant des boucles pour que le système orchestre en continu les agents ». Ce qu'Addy Osmani appelle Loop Engineering (l'ingénierie de boucles) consiste essentiellement à construire un flux de travail capable de découvrir automatiquement des tâches, de les attribuer, de vérifier les résultats, d'enregistrer la progression et de décider de la prochaine étape.

Cette boucle est grossièrement composée de cinq modules : Automations (découverte et triage programmés des tâches), Worktrees (isolation de multiples environnements de développement parallèles), Skills (capitalisation des connaissances du projet et des pratiques de l'équipe), Plugins/Connectors (connexion à des outils réels comme GitHub, Linear, Slack, bases de données, etc.), Sub-agents (séparation de l'exécutant et du vérificateur), le tout surmonté d'une couche de mémoire externe, comme des fichiers Markdown ou un tableau Linear, pour sauvegarder l'état et l'avancement.

L'article rappelle que la signification du Loop Engineering ne se résume pas à « faire tourner l'IA plus de fois », mais à anticiper le jugement de l'ingénieur dans la conception du système. Les boucles peuvent amplifier significativement le levier de travail des développeurs, mais ne remplacent pas la vérification, la compréhension et le jugement. Le vrai risque ne réside pas dans l'utilisation de boucles, mais dans le fait de les utiliser comme excuse pour éviter de comprendre le code et le système. La compétence clé pour collaborer avec le codage IA à l'avenir ne sera peut-être plus seulement d'écrire un bon prompt, mais de concevoir des flux de travail d'agents fiables, vérifiables et capables de s'exécuter de manière durable.

Voici l'article original :

L'ingénierie de boucles (Loop Engineering) est en train de remplacer votre rôle de « rédacteur de prompts pour les agents ». Vous devez concevoir un système qui, à votre place, donnera les prompts à l'agent. Ici, la « boucle » peut être comprise comme un objectif récursif : vous définissez un but, et l'IA itère continuellement jusqu'à ce que la tâche soit accomplie. Elle est grossièrement composée de cinq éléments, et Claude Code et Codex possèdent désormais tous deux ces cinq éléments.

Je crois que c'est peut-être ainsi que nous collaborerons à l'avenir avec les agents de codage. Cependant, tout cela en est encore à un stade précoce, et je reste sceptique. Vous devez absolument être prudent avec les coûts en tokens, car ils peuvent varier énormément selon les modes d'utilisation, surtout selon que vous êtes « riche en tokens » ou « limité en tokens ». Vous avez aussi besoin d'un mécanisme pour garantir que la qualité ne se dégrade pas. Les inquiétudes concernant la « production de déchets par l'IA » (slop) sont également légitimes. Cela dit, voyons de quoi il s'agit vraiment.

@steipete a récemment déclaré : « Vous ne devriez plus rédiger de prompts pour les agents de codage. Vous devriez concevoir des boucles qui, elles, donneront les prompts à vos agents. » De même, @bcherny, responsable de Claude Code chez Anthropic, a dit : « Je ne donne plus de prompts à Claude. J'ai un tas de boucles en cours d'exécution qui donnent des prompts à Claude et décident elles-mêmes de la prochaine étape. Mon travail consiste à écrire des boucles. »

Mais qu'est-ce que cela signifie ?

Au cours des deux dernières années environ, la manière principale de faire faire quelque chose à un agent de codage était de rédiger un bon prompt et de fournir suffisamment de contexte. Vous saisissiez une phrase, lisiez le résultat, puis saisissiez la phrase suivante. L'agent était un outil que vous teniez en main, le poussant tour après tour. Cette phase est en quelque sorte terminée, du moins certains pensent qu'elle est sur le point de l'être.

Maintenant, vous construisez un petit système : il découvre lui-même le travail, attribue les tâches, vérifie les résultats, enregistre ce qui est fait, puis décide de l'étape suivante. En d'autres termes, vous laissez ce système piloter l'agent, au lieu de lui donner vous-même des prompts à répétition. J'ai déjà écrit sur son « cousin proche » – l'agent harness engineering (ingénierie de harnais pour agents), qui consiste à construire un environnement d'exécution pour un agent unique ; et le factory model (modèle d'usine), qui consiste à construire des systèmes qui construisent des logiciels. Le Loop Engineering se situe un niveau au-dessus du harness. C'est comme un harness, mais qui s'exécute selon un planificateur, génère des assistants et s'auto-alimente.

Ce qui me surprend, c'est que ce n'est plus seulement une question « d'outillage ». Il y a un an, si vous vouliez une boucle, vous deviez écrire un tas de scripts bash, puis les maintenir pour toujours. C'était votre truc, et seulement le vôtre. Maintenant, ces composants sont directement intégrés dans les produits. Les capacités listées par Steinberger correspondent presque une à une à l'application Codex, et presque aussi bien à Claude Code. Une fois que vous réalisez qu'elles ont la même forme, vous arrêtez de vous demander quel outil utiliser, et vous concevez une boucle : quel que soit l'outil dans lequel vous vous trouvez, elle peut continuer à fonctionner.

Cinq éléments, et quelques explications

Une boucle nécessite cinq choses, plus un endroit pour se souvenir des informations. Je vais les lister, puis les mettre en correspondance.

Premièrement, Automations (automatisations) : Déclenchées selon un planning, elles découvrent et trient automatiquement.

Deuxièmement, Worktrees (arbres de travail) : Permettent à deux agents travaillant en parallèle de ne pas écraser les fichiers de l'autre.

Troisièmement, Skills (compétences) : Écrire les connaissances du projet pour éviter que l'agent ne devine à chaque fois.

Quatrièmement, Plugins and connectors (plugins et connecteurs) : Permettent à l'agent d'interagir avec les outils que vous utilisez déjà.

Cinquièmement, Sub-agents (sous-agents) : L'un propose des solutions, l'autre les vérifie.

Puis la sixième chose : la mémoire (memory). Cela peut être un fichier Markdown, un tableau Linear, ou tout endroit indépendant d'une conversation unique, capable de sauvegarder les « choses faites » et les « prochaines choses ». Cela semble si simple que cela ne paraît pas important, mais c'est la même astuce dont dépend chaque agent à long terme. Je l'ai également détaillé dans long-running agents : le modèle oublie entre chaque exécution, donc la mémoire doit être sur le disque, et non dans le contexte. L'agent oublie, mais le dépôt de code, non.

Maintenant, les deux produits possèdent ces cinq éléments.

Leurs noms diffèrent par endroits, mais les capacités sont essentiellement les mêmes. Je vais les détailler, car, honnêtement, les détails font toute la différence entre une boucle qui tourne stablement et une qui fuit silencieusement de partout.

Automations : C'est le battement de cœur de la boucle

Les Automations sont ce qui fait d'une boucle une vraie boucle, et non une tâche ponctuelle que vous avez exécutée manuellement une fois. Dans l'application Codex, vous pouvez créer une automation dans l'onglet Automations, choisir le projet, le prompt qu'elle exécutera, la fréquence, et si elle s'exécute dans votre copie locale (checkout) ou dans un worktree en arrière-plan. Les exécutions qui trouvent des problèmes vont dans la Triage inbox (boîte de réception de triage), celles qui n'en trouvent pas sont automatiquement archivées, ce qui est bien. OpenAI l'utilise en interne pour des choses ennuyeuses mais nécessaires, comme le tri quotidien des issues, le résumé des échecs CI, la rédaction de rapports de commit, le suivi d'un bug introduit la semaine dernière. Les automations peuvent aussi appeler des skills, vous pouvez donc maintenir les tâches récurrentes : déclencher $skill-name, plutôt que de coller un mur de texte dans une tâche planifiée que personne ne mettra jamais à jour.

Claude Code atteint le même résultat, mais par un chemin différent : via la planification et les hooks. Vous pouvez utiliser /loop pour exécuter un prompt ou une commande à intervalles fixes, planifier une tâche cron, ou utiliser des hooks pour déclencher des commandes shell à certains moments du cycle de vie de l'agent. Si vous voulez qu'il continue après avoir fermé votre ordinateur, vous pouvez pousser le tout sur GitHub Actions. La logique est exactement la même : vous définissez une tâche autonome, vous lui donnez un rythme, et les découvertes viennent à vous, au lieu que vous alliez les vérifier partout.

Il y a aussi une primitive conversationnelle à connaître, plus proche du cœur de cet article. /loop répète l'exécution selon un rythme ; /goal continue de s'exécuter jusqu'à ce qu'une condition que vous avez écrite soit réellement remplie. Après chaque tour, un petit modèle séparé juge si la tâche est terminée, donc l'agent qui code n'est pas celui qui s'évalue lui-même. Vous pouvez lui donner une condition comme « tous les tests dans test/auth passent et le lint est propre », et partir. Codex a la même capacité, également appelée /goal. Il travaille de manière persistante sur plusieurs tours jusqu'à ce qu'une condition d'arrêt vérifiable soit remplie, avec support de la pause, de la reprise et de l'effacement. Même primitive, deux outils. C'est fondamentalement le motif qui revient dans tout l'article.

Donc, les Automations sont responsables de faire remonter le travail. Le reste de la boucle est responsable de traiter ce travail.

Worktrees : Pour que le parallélisme ne devienne pas du chaos

Dès que vous exécutez plus d'un agent, les conflits de fichiers deviennent un point de défaillance. Deux agents écrivant dans le même fichier sont aussi problématiques que deux ingénieurs modifiant la même ligne de code sans communication. Git worktree résout ce problème. C'est un répertoire de travail séparé sur une branche indépendante, mais partageant l'historique du même dépôt, donc les modifications d'un agent ne peuvent physiquement pas toucher le checkout de l'autre.

Codex intègre directement le support des worktrees, donc plusieurs threads peuvent traiter le même dépôt simultanément sans se heurter. Claude Code peut aussi réaliser la même isolation via git worktree : vous pouvez utiliser le flag --worktree pour ouvrir une session dans un checkout indépendant, ou définir isolation: worktree sur un subagent pour que chaque assistant obtienne un checkout entièrement nouveau, nettoyé automatiquement à la fin. J'ai écrit sur l'aspect humain dans the orchestration tax : les worktrees éliminent les conflits mécaniques, mais vous êtes toujours le goulot d'étranglement. Ce qui détermine réellement combien d'agents vous pouvez exécuter simultanément, ce n'est pas l'outil, mais votre review bandwidth (capacité de revue).

Skills : Pour ne pas avoir à réexpliquer le projet à chaque fois

Un Skill est un mécanisme pour éviter de réexpliquer le même contexte de projet à chaque session comme un poisson rouge. Les deux outils utilisent le même format : un dossier contenant un SKILL.md avec les instructions et métadonnées ; plus des scripts optionnels, des références et des fichiers de ressources. Codex exécute un skill lorsque vous l'appelez avec $ ou /skills, et aussi automatiquement lorsque votre tâche correspond à sa description. C'est pourquoi une description concise et sobre est souvent meilleure qu'une description astucieuse et fantaisiste. Claude Code fonctionne de la même manière, j'ai écrit sur ce modèle dans agent skills.

Les Skills sont aussi l'endroit où l'intention cesse de vous consumer à chaque fois. J'ai parlé de la dette d'intention (intent debt) : l'agent démarre à froid à chaque session, et tout blanc dans votre intention est comblé par des suppositions confiantes. Un Skill, c'est écrire cette intention à l'extérieur : les conventions du projet, les étapes de build, « on ne fait pas ça à cause de cet incident passé », etc., écrits une fois pour toutes dans un endroit que l'agent lit à chaque exécution. Sans skills, la boucle doit redériver tout votre projet à partir de zéro à chaque tour ; avec des skills, c'est un peu comme des intérêts composés.

Une distinction à faire : un skill est un format d'écriture, un plugin est un mode de distribution. Lorsque vous voulez partager un skill entre plusieurs dépôts, ou regrouper plusieurs skills, vous les empaquetez dans un plugin. Codex fait cela, Claude Code aussi.

Plugins and connectors : Pour que la boucle touche vos outils réels

Une boucle qui ne voit que le système de fichiers est une toute petite boucle. Les Connectors, construits sur MCP, permettent à l'agent de lire votre gestionnaire d'issues, d'interroger une base de données, d'appeler une API de staging, ou d'envoyer un message sur Slack. Codex et Claude Code supportent tous deux MCP, donc un connector écrit pour l'un fonctionne généralement aussi dans l'autre. Les Plugins empaquettent ensemble connectors et skills, permettant à vos collègues d'installer une configuration complète en une fois, plutôt que de la reconstruire de mémoire.

C'est la différence entre « un agent vous disant 'voici le correctif' » et « une boucle ouvrant elle-même une PR, liant le ticket Linear, et notifiant le canal une fois le CI passé ». Les Connectors sont importants parce qu'ils permettent à la boucle d'agir dans votre environnement réel, au lieu de vous dire seulement 'si je pouvais, je ferais cela'.

Sub-agents : Pour éloigner le fabricant du vérificateur

Dans une boucle, la conception structurelle la plus utile est de loin la séparation entre celui qui « écrit » et celui qui « vérifie ». Le modèle qui écrit le code est trop enclin à être indulgent en notant son propre devoir. Un autre agent avec des instructions différentes, parfois même utilisant un modèle différent, peut attraper les problèmes que le premier agent, s'étant auto-convaincu, a ignorés.

Codex ne génère des subagents que lorsque vous le demandez ; ils s'exécutent en parallèle, puis fusionnent les résultats en une seule réponse. Vous pouvez définir vos propres agents dans des fichiers TOML dans .codex/agents/ : chaque agent a un nom, une description, des instructions, et éventuellement un modèle et une intensité de raisonnement. Ainsi, votre réviseur de sécurité peut être un modèle fort avec un raisonnement intense, tandis que votre explorateur peut être un modèle léger, rapide et en lecture seule. Claude Code implémente des capacités similaires via les subagents et les équipes d'agents dans .claude/agents/, permettant à plusieurs agents de se passer le travail. La division la plus courante des deux côtés est : un agent explore, un agent implémente, un agent vérifie par rapport aux spécifications.

J'ai déjà exposé ce point deux fois : une fois dans code agent orchestra, et une autre dans adversarial code review. C'est particulièrement important dans une boucle, car une boucle s'exécute quand vous ne regardez pas, donc un vérificateur (verifier) en qui vous avez vraiment confiance est la seule raison pour laquelle vous osez vous absenter. Les Subagents consomment effectivement plus de tokens, car chaque agent fait son propre appel de modèle et d'outils, donc vous devriez les utiliser là où « une seconde opinion vaut la peine d'être payée ». C'est essentiellement ce que fait /goal de Claude Code en coulisses : un nouveau modèle juge si la boucle est terminée, plutôt que de laisser le modèle qui a fait le travail en juger. En d'autres termes, il applique la séparation entre le « fabricant » et le « vérificateur » à la condition d'arrêt elle-même.

À quoi ressemble une boucle

Assemblez ces éléments, et un simple thread devient un petit tableau de bord. Voici une structure que j'utilise souvent.

Chaque matin, une automation s'exécute sur le dépôt de code. Son prompt appelle un skill de triage (triage skill), lit les échecs CI de la veille, les issues ouvertes, les commits récents, et écrit ses découvertes dans un fichier Markdown ou un tableau Linear. Pour chaque problème méritant un traitement, le thread ouvre un worktree isolé, envoie un sous-agent (sub-agent) esquisser un correctif, puis un deuxième sous-agent pour examiner ce correctif par rapport aux skills du projet et aux tests existants.

Les Connectors permettent à cette boucle d'ouvrir elle-même une PR et de mettre à jour le ticket. Tout ce que la boucle ne peut pas traiter va dans la boîte de triage (triage inbox), pour que je m'en occupe. Le fichier d'état est la colonne vertébrale du système : il se souvient de ce qui a été tenté, de ce qui a réussi, de ce qui reste inachevé. Ainsi, l'exécution du lendemain matin reprend là où celle d'aujourd'hui s'est arrêtée.

Notez ce que vous faites réellement. Vous n'avez conçu qu'une seule fois. Ces étapes ne sont pas des prompts que vous avez saisis manuellement tour par tour. C'est la version concrète de la phrase de Steinberger. Et la même boucle peut s'exécuter sur Codex ou sur Claude Code, car les éléments constitutifs sont les mêmes.

Ce que les boucles ne feront toujours pas à votre place

Les boucles changent la façon de travailler, mais ne vous éliminent pas du travail. En fait, à mesure que les boucles deviennent plus puissantes, trois problèmes deviennent plus aigus, et non plus faciles.

La vérification dépend toujours de vous. Une boucle qui s'exécute sans surveillance peut aussi faire des erreurs sans surveillance. La raison pour laquelle vous séparez le sous-agent vérificateur (verifier) du fabricant (maker) est de donner un peu de sens à l'affirmation « terminé » de la boucle. Même ainsi, « terminé » reste une affirmation, pas une preuve. Je répète la même phrase dans code review in the age of AI : votre responsabilité est de livrer du code dont vous avez confirmé l'efficacité.

Si vous laissez faire, votre propre compréhension pourrira toujours. Plus une boucle livre rapidement du code que vous n'avez pas écrit vous-même, plus l'écart entre ce que vous comprenez réellement et ce qui existe réellement dans le système grandit. C'est la dette de compréhension (comprehension debt). Si vous ne lisez pas ce que la boucle produit, une boucle fluide ne fera qu'accélérer l'accumulation de cette dette.

Et oui, la posture la plus confortable est aussi probablement la plus dangereuse. Lorsqu'une boucle peut s'exécuter seule, il est facile d'arrêter de former votre propre jugement et d'accepter simplement tout ce qu'elle renvoie. J'appelle cela la reddition cognitive (cognitive surrender). Si vous concevez une boucle avec jugement, c'est un remède ; si vous concevez une boucle pour éviter de penser, c'est un accélérateur. Le même geste produit des résultats totalement opposés.

Construire des boucles, mais rester ingénieur

Je pense que cela présage l'évolution future de notre travail. Cela dit, si je ne révise pas le code moi-même, ou si je compte entièrement sur des boucles automatisées pour corriger le code, la qualité de mes produits en souffrira. Je risque probablement de tomber dans une spirale descendante : creuser sans cesse un trou plus profond.

Donc, vous pouvez certainement construire vos propres boucles, mais n'oubliez pas que donner des prompts directement à votre agent reste efficace. La clé est de trouver le bon équilibre.

Les résultats des boucles varieront aussi selon les personnes. Deux personnes peuvent construire exactement la même boucle et obtenir des résultats radicalement différents. L'une l'utilise pour accélérer un travail qu'elle comprend profondément ; l'autre l'utilise pour éviter de comprendre le travail lui-même. La boucle ne fait pas la différence. Vous, si.

C'est pourquoi la conception de boucles (loop design) est plus difficile que l'ingénierie des prompts (prompt engineering), et non plus facile. Cherny ne veut pas dire que le travail devient plus facile, mais que le point de levier se déplace.

Construisez des boucles. Mais construisez-les comme quelqu'un qui a toujours l'intention d'être un ingénieur, et non comme quelqu'un dont le seul travail est d'appuyer sur le bouton « démarrer ».