Loop Engineering.
Auteur original : Addy Osmani
Compilé par Peggy, BlockBeats

Note de l’éditeur : La manière d’utiliser les agents de codage IA passe de « l’humain qui écrit manuellement des invites et avance étape par étape » à « l’humain qui conçoit des boucles, permettant au système de planifier continuellement les agents ». L’ingénierie des boucles, telle que décrite par Addy Osmani, consiste à créer un flux de travail capable de détecter automatiquement les tâches, de les attribuer, de vérifier les résultats, d’enregistrer les progrès et de déterminer la prochaine étape.

Ce cycle se compose approximativement de cinq modules : Automations (découverte et tri automatisés des tâches), Worktrees (isolation de plusieurs environnements de développement parallèles), Skills (accumulation des connaissances de projet et des pratiques d'équipe), Plugins/Connectors (intégration avec des outils réels tels que GitHub, Linear, Slack, les bases de données), Sub-agents (séparation des exécutants et des réviseurs), ainsi qu'une couche de mémoire externe, comme des fichiers Markdown ou un tableau Linear, pour stocker l'état et les progrès.

L'article souligne que l'importance de Loop Engineering ne se limite pas à « faire exécuter l'IA plusieurs tours », mais consiste à intégrer le jugement des ingénieurs dès la conception du système. Les boucles peuvent considérablement amplifier l'efficacité des développeurs, mais ne remplacent pas la validation, la compréhension et le jugement. Le véritable risque ne réside pas dans l'utilisation des boucles, mais dans l'usage de celles-ci comme prétexte pour éviter de comprendre le code et le système. La compétence clé pour collaborer avec l'IA dans la programmation à l'avenir ne sera peut-être plus seulement de rédiger un bon prompt, mais de concevoir des flux de travail d'agents fiables, vérifiables et durables.

The following is the original text:

Loop engineering (ingénierie de boucle) remplace votre rôle en tant que « personne qui rédige des invites pour les agents ». Vous devez concevoir un système qui prend en charge l'envoi d'invites aux agents à votre place. Ici, la boucle peut être comprise comme un objectif récursif : vous définissez un objectif, et l'IA itère en continu jusqu'à l'achèvement de la tâche. Elle se compose大致 de cinq composants, et Claude Code ainsi que Codex possèdent désormais tous ces cinq composants.

Je crois que ceci pourrait bien être la manière dont nous collaborerons avec des agents de codage à l'avenir. Toutefois, tout cela reste à un stade précoce, et je reste sceptique. Vous devez absolument faire attention aux coûts en tokens, car les différences de coût peuvent être énormes selon les modèles d'utilisation, en particulier selon que vous êtes « riche en tokens » ou « tendu en tokens ». Vous avez également besoin d'un mécanisme pour garantir que la qualité ne diminue pas. Les préoccupations concernant la « production de déchets AI » (slop) sont également légitimes. Malgré tout, examinons ce qui se passe réellement.

@steipete a récemment déclaré : « Vous ne devriez plus écrire de prompts pour des agents de codage. Vous devez concevoir des boucles qui enverront des prompts à vos agents. » De même, @bcherny, responsable de Claude Code chez Anthropic, a déclaré : « Je ne donne plus de prompts à Claude. J'ai un ensemble de boucles qui s'exécutent, elles envoient des prompts à Claude et décident elles-mêmes de la prochaine étape à prendre. Mon travail consiste à écrire des boucles. »

Then, what does this actually mean?

Au cours des deux dernières années environ, pour faire faire quelque chose à un agent de codage, la méthode de base consistait à rédiger un bon prompt et à fournir suffisamment de contexte. Vous saisissiez une phrase, lisiez le résultat retourné, puis saisissiez la phrase suivante. L’agent était un outil, et vous le teniez toujours en main, le poussant tour après tour. Ce stade est en quelque sorte terminé, du moins pour certaines personnes qui pensent qu’il est sur le point de l’être.

Vous construisez maintenant un petit système : il découvre automatiquement les tâches, les attribue, vérifie les résultats, enregistre leur accomplissement, puis décide de la prochaine étape à entreprendre. Autrement dit, vous faites en sorte que ce système pilote les agents, au lieu de devoir les encourager manuellement à chaque fois. J’ai précédemment écrit sur ses « proches parents » : l’ingénierie des frameworks d’agents (agent harness engineering), qui consiste à créer un environnement d’exécution pour un seul agent ; et le modèle usine (factory model), qui est un système de construction de logiciels. L’ingénierie de boucle (loop engineering) se situe au-dessus du framework. Elle ressemble à un harness, mais s’exécute selon un minuteur, génère des assistants miniatures et s’auto-alimente.

Ce qui m’a surpris, c’est que ce n’est plus seulement une question « outil » aujourd’hui. Il y a un an, si vous vouliez un boucle, vous deviez écrire une multitude de scripts bash et les maintenir indéfiniment. C’était votre propre chose, et uniquement la vôtre. Maintenant, ces composants sont directement intégrés dans le produit. Les capacités listées par Steinberger correspondent presque point par point à celles de l’application Codex, et presque aussi précisément à celles de Claude Code. Dès que vous réalisez qu’elles ont la même forme, vous ne vous demanderez plus quel outil utiliser, mais vous concevrez une boucle : peu importe dans quel outil vous vous trouvez, elle continuera de fonctionner.

Cinq composants, ainsi que quelques explications

Un loop nécessite cinq éléments, ainsi qu'un endroit pour mémoriser les informations. Je les énumère d'abord, puis je les correspondrai un par un.

Premièrement, Automations (tâches automatisées) : déclenchées selon un calendrier, permettent une découverte et un routage automatiques.

Deuxièmement, les Worktrees : permettent à deux agents travaillant en parallèle de ne pas se chevaucher sur les fichiers.

Troisièmement, les compétences : écrivez les connaissances du projet pour éviter que l'agent doive deviner à chaque fois.

Quatrièmement, Plugins et connecteurs : permettez à l’agent de se connecter aux outils que vous utilisez déjà.

Cinquièmement, les sous-agent(s) : un chargé de proposer des solutions, l’autre chargé de vérifier les solutions.

Ensuite, le sixième élément : la mémoire. Elle peut être un fichier Markdown, un tableau Linear, ou tout autre système indépendant d’une seule conversation, capable de stocker les « tâches terminées » et les « prochaines étapes ». Cela semble trop simple pour être important, mais c’est exactement la même technique sur laquelle reposent tous les agents à long terme. J’ai également détaillé cela dans les agents à long terme : le modèle oublie entre chaque exécution, donc la mémoire doit être stockée sur disque, et non dans le contexte. L’agent oublie, mais le dépôt de code ne l’oublie pas.

Maintenant, les deux produits possèdent tous ces cinq composants.

Leurs noms diffèrent légèrement, mais leurs capacités sont essentiellement les mêmes. Je vais les expliquer un par un, car, honnêtement, la différence entre une boucle qui fonctionne de manière stable et une qui fuit discrètement partout réside dans les détails.

Les automatisations sont ce qui transforme vraiment un loop en loop, et non en une tâche unique que vous avez exécutée manuellement une fois. Dans l'application Codex, vous pouvez créer une automatisation dans l'onglet Automations, en sélectionnant le projet, le prompt qu'il doit exécuter, la fréquence d'exécution, ainsi que l'endroit où elle s'exécute : dans votre checkout local ou dans un worktree en arrière-plan. Les résultats d'exécution ayant identifié des problèmes sont acheminés vers la boîte de réception Triage, tandis que les exécutions sans problème sont automatiquement archivées — ce qui est pratique. OpenAI l'utilise également en interne pour effectuer des tâches répétitives mais nécessaires, comme le tri quotidien des issues, la synthèse des causes d'échec CI, la rédaction de bulletins de commit et le suivi des bogues introduits la semaine précédente. Les automatisations peuvent également appeler des compétences, ce qui permet de maintenir facilement les tâches répétitives : déclenchez $skill-name au lieu de coller une longue liste d'instructions dans une tâche planifiée que personne ne mettra à jour à l'avenir.

Claude Code peut produire le même effet, mais par un chemin différent : il utilise la planification et les hooks. Vous pouvez exécuter une instruction ou une commande à intervalles fixes avec /loop, planifier une tâche cron, ou déclencher des commandes shell à certains points du cycle de vie de l'agent via des hooks. Si vous souhaitez qu'il continue de fonctionner après avoir fermé votre ordinateur, vous pouvez également déployer tout cela sur GitHub Actions. L'idée est exactement la même : vous définissez une tâche autonome, lui donnez un rythme, et laissez les résultats venir à vous au lieu d'avoir à les chercher partout.

Un autre primitif de session à connaître, plus proche du cœur véritable du sujet traité ici. /loop s'exécute en boucle selon un rythme ; /goal s'exécute en continu jusqu'à ce qu'une condition que vous avez définie soit véritablement remplie. Après chaque cycle, un petit modèle distinct évalue si la tâche est terminée, de sorte que l'agent qui écrit le code n'est pas celui qui s'évalue lui-même. Vous pouvez lui fournir une condition, par exemple « tous les tests dans test/auth réussissent et le lint est propre », puis partir. Codex possède la même capacité, également appelée /goal. Il continue de travailler sur plusieurs cycles jusqu'à ce qu'une condition d'arrêt vérifiable soit remplie, et prend en charge la pause, la reprise et la suppression. Le même primitif est présent dans les deux outils. C'est fondamentalement le modèle qui revient constamment dans cet article.

Ainsi, les Automations assurent la mise en évidence des tâches, tandis que le reste de la boucle en assure le traitement.

Lorsque vous exécutez plus d'un agent, les conflits de fichiers deviennent un point d'échec. Deux agents écrivant simultanément 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. Il s'agit d'un répertoire de travail distinct sur une branche indépendante, mais partageant le même historique de dépôt, ce qui empêche physiquement les modifications d'un agent d'entrer en conflit avec le checkout d'un autre agent.

Codex intègre directement le support de worktree, permettant à plusieurs threads de traiter simultanément le même dépôt sans conflit. Claude Code peut également atteindre cette même isolation via git worktree : vous pouvez ouvrir une session dans un checkout indépendant en utilisant l'option --worktree, ou définir isolation: worktree sur un subagent pour que chaque assistant dispose d'un checkout entièrement nouveau, nettoyé automatiquement à la fin. J'ai abordé ce point du côté humain dans « the orchestration tax » : les worktrees éliminent les conflits mécaniques, mais vous restez la limite. Ce qui détermine réellement le nombre d'agents que vous pouvez exécuter simultanément, ce n'est pas l'outil, mais votre bande passante de revue.

Skill est un mécanisme qui vous permet de ne pas avoir à réexpliquer à chaque session les mêmes éléments, comme un poisson rouge. Les deux outils utilisent le même format : un dossier contenant un fichier SKILL.md qui stocke les instructions et les métadonnées ; en plus, des scripts optionnels, des références et des fichiers ressources peuvent être inclus. Codex exécute un skill lorsque vous l'appelez avec $ ou /skills, et il le déclenche également automatiquement lorsque votre tâche correspond à la description du skill. C'est pourquoi une description concise et simple est souvent préférable à une description sophistiquée et élaborée. Claude Code applique la même approche ; j'ai déjà décrit ce modèle dans les compétences d'agent.

Les compétences sont également l’endroit où vous évitez de devoir répéter constamment vos intentions. J’ai mentionné dans la dette d’intention que chaque fois qu’un agent démarre une conversation, il démarre à froid ; tant qu’il y a des lacunes dans vos intentions, il les remplit avec des suppositions assurées. Les compétences consistent à écrire ces intentions à l’extérieur : conventions de projet, étapes de construction, « nous ne faisons pas cela parce que cet incident s’est produit auparavant », etc., tout est écrit une seule fois dans un endroit que l’agent lit à chaque exécution. Sans compétences, chaque tour de boucle doit reconstruire entièrement votre projet depuis le début ; avec des compétences, c’est un peu comme un effet de capitalisation.

Il faut bien distinguer : skill est un format d’écriture, tandis que plugin est un mode de distribution. Lorsque vous souhaitez partager un skill entre plusieurs dépôts de code ou regrouper plusieurs skills ensemble, vous les encapsulez dans un plugin. C’est ainsi que fonctionne Codex, et c’est aussi le cas pour Claude Code.

Un seul loop ayant accès au système de fichiers est un petit loop. Les connecteurs, construits sur MCP, permettent aux agents de lire votre suivi des incidents, de interroger des bases de données, d'appeler des API de staging ou d'envoyer des messages sur Slack. Codex et Claude Code prennent tous deux en charge MCP, donc un connecteur que vous écrivez pour l'un peut généralement être utilisé sur l'autre. Les plugins regroupent les connecteurs et les compétences pour permettre à vos collègues d'installer une configuration complète en un seul clic, au lieu de devoir la reconstruire à partir de leur mémoire.

C’est la différence entre « un agent vous dit : “Voici la solution de correction” » et « un loop ouvre automatiquement une PR, lie le ticket Linear, et notifie le canal une fois l’CI réussi ». Les connecteurs sont essentiels car ils permettent au loop d’agir dans votre environnement réel, et non pas simplement de vous dire : « Si je pouvais le faire, je le ferais ».

Dans une boucle, la conception structurelle la plus utile consiste largement à séparer « celui qui écrit » de « celui qui vérifie ». Le modèle qui écrit du code a tendance à être trop indulgent lorsqu'il évalue son propre travail. Un autre agent, doté d'instructions différentes et parfois même utilisant un modèle différent, peut repérer les problèmes ignorés par le premier agent après s'être convaincu lui-même.

Codex ne génère des subagents que sur demande, ils s'exécutent en parallèle, puis fusionnent leurs résultats en une seule réponse. Vous pouvez définir vos propres agents dans des fichiers TOML dans .codex/agents/ : chaque agent possède un nom, une description, des instructions, ainsi qu'un modèle et une intensité d'inférence optionnels. Ainsi, votre examinateur de sécurité peut être un modèle puissant avec une intensité d'inférence élevée, tandis que votre explorateur peut être un modèle léger, rapide et en lecture seule. Claude Code offre également une capacité similaire via des subagents et des équipes d'agents dans .claude/agents/, permettant à plusieurs agents de transmettre leur travail entre eux. La répartition la plus courante des tâches des deux côtés est la suivante : un agent explore, un agent implémente, et un agent valide selon les spécifications.

J'ai déjà exposé ce point deux fois : une fois dans le contexte de code agent orchestra, et une autre fois dans le cadre de adversarial code review. Il est particulièrement important dans une boucle, car la boucle s'exécute sans que vous soyez présent ; un vérificateur en qui vous avez pleinement confiance est donc la seule raison pour laquelle vous pouvez vous permettre de vous éloigner. Les sous-agents consomment effectivement davantage de tokens, car chaque agent effectue ses propres appels de modèle et d'outils ; vous devriez donc les utiliser uniquement là où une seconde opinion vaut le coût. C'est précisément ce que fait en fond /goal de Claude Code : un nouveau modèle évalue si la boucle est terminée, plutôt que de laisser le modèle ayant accompli la tâche en décider. Autrement dit, il applique la séparation entre « créateur » et « vérificateur » directement à la condition d'arrêt.

À quoi ressemble un loop ?

En assemblant tout cela, un seul fil devient un petit tableau de bord. Voici la structure que j'utilise fréquemment.

Chaque matin, une automation s'exécute sur le dépôt de code. Son prompt appelle une compétence de tri, qui lit les échecs CI de la veille, les problèmes ouverts et les commits récents, puis enregistre les découvertes dans un fichier Markdown ou un tableau Linear. Pour chaque problème méritant une attention, le thread ouvre un worktree isolé, déclenche un sous-agent pour rédiger une proposition de correction, puis un second sous-agent pour examiner cette proposition selon les compétences du projet et les tests existants.

Les connecteurs permettent à ce loop d'ouvrir automatiquement une PR et de mettre à jour le ticket. Tout ce que le loop ne peut pas gérer est redirigé vers la boîte de réception triage, où je m'en occupe. Le fichier d'état est l'épine dorsale du système entier : il mémorise ce qui a été essayé, ce qui a réussi et ce qui reste incomplet. Ainsi, l'exécution du lendemain matin reprend là où elle s'est arrêtée aujourd'hui.

Faites attention à ce que vous avez réellement fait. Vous n’avez simplement conçu qu’une seule fois. Ces étapes ne vous ont pas été saisies une par une. Voici la version concrète de la phrase de Steinberger. Et le même boucle peut s’exécuter sur Codex ainsi que sur Claude Code, car les composants sont exactement les mêmes.

Loop ne fera toujours rien pour vous

Loop a changé sa manière de fonctionner, mais ne vous éliminera pas de votre travail. En fait, à mesure que loop devient plus puissant, trois problèmes deviennent plus aigus, et non plus faciles.

La vérification dépend toujours de toi. Un loop qui s'exécute sans surveillance peut aussi commettre des erreurs sans surveillance. La raison pour laquelle tu as séparé le sous-agent vérificateur et le maker, c'est pour que le mot « terminé » du loop ait un peu de sens. Même ainsi, « terminé » reste une affirmation, pas une preuve. Je répète constamment la même phrase dans « code review in the age of AI » : ta responsabilité est de livrer du code que tu as confirmé comme valide.

Si vous laissez faire, votre propre compréhension continuera de se dégrader. Plus Loop 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 s'agrandit. C'est ce qu'on appelle la dette de compréhension. Si vous ne lisez pas ce que produit Loop, un flux fluide ne fera qu'accélérer l'accumulation de cette dette.

Et oui, la posture la plus confortable est probablement aussi la plus dangereuse. Lorsque le loop peut fonctionner tout seul, il est facile d’arrêter de former vos propres jugements et de simplement accepter tout ce qu’il vous renvoie. J’appelle cela une reddition cognitive. Si vous concevez le loop avec jugement, il devient le remède ; si vous le concevez uniquement pour éviter de réfléchir, il devient un accélérateur. Le même geste peut produire des résultats exactement opposés.

Construire une boucle, mais rester ingénieur

Je pense que cela préfigure l'évolution de notre travail futur. Cela dit, si je ne vérifie pas moi-même le code ou que je compte entièrement sur une boucle automatisée pour le corriger, la qualité de mes produits en souffrira. Je risque fortement de tomber dans une spirale descendante : m'enfoncer de plus en plus profondément dans le problème.

Donc, vous pouvez bien sûr créer votre propre boucle, mais n'oubliez pas que le fait de donner directement des instructions à votre agent reste efficace. L'essentiel est de trouver le bon équilibre.

Les résultats de Loop varient également d'une personne à l'autre. Deux personnes peuvent construire exactement le même loop et obtenir des résultats totalement opposés. L'une l'utilise pour accélérer son travail dans un domaine qu'elle comprend profondément ; l'autre l'utilise pour éviter de comprendre le travail lui-même. Loop ne connaît pas la différence entre les deux. Toi, tu la connais.

C'est pourquoi le loop design est plus difficile que le prompt engineering, et non pas plus simple. Ce que Cherny entend, ce n'est pas que le travail devient plus facile, mais que le point de levier a changé.

Construire une boucle. Mais construisez-la comme quelqu’un qui compte encore devenir ingénieur, et non comme quelqu’un qui se contente d’appuyer sur le bouton « démarrer ».

[Original link]

Cliquez pour en savoir plus sur les postes vacants chez BlockBeats

Rejoignez la communauté officielle de律动 BlockBeats :

Groupe Telegram abonné : https://t.me/theblockbeats

Groupe Telegram : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia