Loop Engineering - Concevoir des systèmes qui promptent les agents

• Fin de la méthode consistant à prompt directement un agent de code à chaque tour, au profit d’une façon de travailler où l’on conçoit un système qui prompt l’agent à votre place
• Une loop est un objectif récursif : on définit un but, puis l’IA itère jusqu’à ce qu’il soit atteint ; elle se compose d’environ cinq éléments
• Ces cinq éléments sont Automations, Worktrees, Skills, Plugins·connectors, Sub-agents ; aujourd’hui, Claude Code comme Codex possèdent les cinq
• Le sixième élément, la mémoire, prend la forme d’un fichier Markdown ou d’un board Linear qui stocke l’état en dehors d’une conversation unique et compense des modèles qui oublient à chaque exécution
• Nous en sommes encore aux débuts, et il faut impérativement surveiller le coût en tokens ; la validation et la compréhension restent toujours du ressort humain (build the loop, stay the engineer)

---

Définition du loop engineering et contexte de son émergence

• Le loop engineering consiste à remplacer l’humain qui prompt l’agent par un système, et à concevoir soi-même ce système qui le fait à votre place
  • Une loop est un objectif récursif (recursive goal) : on définit un but, puis l’IA itère jusqu’à ce qu’il soit atteint
  • Cela pourrait devenir la manière de travailler avec des agents de code à l’avenir, mais nous n’en sommes qu’au début, et il faut absolument faire attention au coût en tokens (les usages changent fortement selon qu’on soit token rich ou token poor)
• Citations
  • Peter Steinberger : « Ne promptez plus directement vos agents de code ; concevez une loop qui les prompt à votre place »
  • Boris Cherny (responsable de Claude Code chez Anthropic) : « Je ne prompt plus Claude directement ; je fais tourner une loop qui prompt Claude et décide quoi faire. Mon travail consiste à écrire cette loop »
• Depuis environ deux ans, la pratique consistait à fournir un bon prompt et suffisamment de contexte, puis à échanger tour par tour en tenant directement l’agent comme un outil ; cette façon de faire touche à sa fin
• Désormais, on construit un petit système qui cherche le travail, le répartit, le valide, enregistre ce qui est terminé et décide de la suite, puis ce système va solliciter l’agent
  • Cela se situe au-dessus des notions précédentes d’agent harness engineering (l’environnement d’exécution d’un agent) et de factory model (le système qui fabrique le logiciel)
  • C’est un harness qui s’exécute sur timer, génère de petits helpers et se réalimente lui-même
• Ce n’est plus vraiment une question d’outils — il y a un an, si l’on voulait une loop, il fallait écrire et maintenir soi-même des scripts bash rudimentaires ; aujourd’hui, ces composants sont directement intégrés dans les produits
  • La liste de Steinberger correspond presque exactement à l’application Codex et très largement à Claude Code ; au lieu de débattre de l’outil, mieux vaut concevoir des loops qui fonctionnent des deux côtés

Les cinq composants d’une loop et la mémoire

• Une loop a besoin de cinq éléments, auxquels s’ajoute un endroit pour mémoriser l’état
  • Automations — se déclenchent selon un planning et assurent découverte et triage automatiquement
  • Worktrees — évitent que deux agents travaillant en parallèle n’entrent en conflit
  • Skills — consignent les connaissances projet que l’agent comblerait sinon par des suppositions
  • Plugins·connectors — relient l’agent aux outils déjà utilisés
  • Sub-agents — l’un produit des idées, l’autre les vérifie
• Le sixième élément est la mémoire, par exemple un fichier Markdown ou un board Linear vivant hors d’une conversation unique et conservant ce qui a été fait ainsi que la suite
  • Cela paraît trop simple, mais c’est le même procédé sur lequel reposent tous les agents de longue durée d’exécution (cf. l’article précédent sur les long-running agents)
  • Les modèles oublient tout entre deux exécutions ; la mémoire doit donc vivre sur disque, pas dans le contexte — l’agent oublie, le repo non
• Les deux produits disposent aujourd’hui des cinq composants, seuls les noms changent un peu ; les capacités sont équivalentes

Automations — le battement de cœur de la loop

• Les Automations sont l’élément qui fait d’une loop une véritable boucle, et non une simple exécution ponctuelle
  • Dans l’application Codex, on les crée depuis l’onglet Automations en choisissant le projet, le prompt à exécuter, la fréquence, et si l’exécution doit se faire sur un checkout local ou dans un worktree d’arrière-plan
  • Une exécution qui détecte quelque chose envoie le résultat dans la Triage inbox ; si elle ne trouve rien, elle s’archive d’elle-même
  • OpenAI les utilise en interne pour des tâches rébarbatives comme le triage quotidien des issues, le résumé des échecs CI, la rédaction de briefings de commits ou la chasse aux bugs ajoutés la semaine précédente
  • Une automation peut appeler un skill, ce qui permet de déclencher $skill-name au lieu de coller un immense pavé d’instructions, et rend les tâches répétitives plus maintenables
• Claude Code atteint le même résultat avec la planification et les hooks
  • /loop permet d’exécuter un prompt ou une commande à intervalles réguliers, de planifier des tâches cron, et des hooks peuvent lancer des commandes shell à certains moments du cycle de vie de l’agent
  • Pour que cela continue même une fois l’ordinateur portable fermé, on peut déléguer l’ensemble à GitHub Actions
• Le deuxième primitive de session, plus proche encore du cœur de l’article, existe aussi
  • /loop relance l’exécution selon une fréquence définie
  • /goal continue tant que la condition rédigée n’est pas réellement vraie ; après chaque tour, un petit modèle distinct vérifie l’état d’achèvement, afin que l’agent qui a écrit le code ne soit pas aussi le juge
    • Exemple : donner des conditions comme « tous les tests de test/auth passent, lint clean », puis quitter son poste
  • Codex propose lui aussi /goal : cela enchaîne les tours jusqu’à ce qu’une condition d’arrêt vérifiable soit satisfaite, avec prise en charge de pause, resume et clear

Worktrees — pour que le parallélisme ne tourne pas au chaos

• Dès qu’on exécute plus d’un agent, les conflits de fichiers commencent ; c’est là que tout casse
  • Laisser deux agents écrire dans le même fichier, c’est le même mal de tête que deux ingénieurs qui commitent la même ligne sans se parler
  • git worktree résout cela — un historique de repo partagé, mais des répertoires de travail séparés sur des branches distinctes, si bien que les modifications d’un agent ne peuvent pas toucher le checkout de l’autre
• Codex intègre nativement la prise en charge des worktrees, ce qui permet à plusieurs threads d’agir sur le même repo sans collision
• Claude Code offre la même isolation avec git worktree, l’option --worktree pour ouvrir une session dans son propre checkout, et le paramètre isolation: worktree appliqué aux subagents (chaque helper reçoit un nouveau checkout, nettoyé automatiquement à la fin)
• Les worktrees éliminent les conflits mécaniques, mais vous restez toujours le facteur limitant — le nombre réel d’agents qu’on peut faire tourner dépend moins de l’outil que de sa propre bande passante de revue (cf. l’article précédent sur the orchestration tax)

Skills — pour ne pas réexpliquer le projet à chaque fois

• Un skill sert à ne plus avoir à réexpliquer le même contexte projet à chaque session, comme si l’agent avait la mémoire d’un poisson rouge
  • Les deux outils utilisent le même format — un dossier contenant un SKILL.md avec instructions et métadonnées, plus éventuellement des scripts, références ou assets
  • Dans Codex, on peut l’appeler avec $ ou /skills, ou bien l’outil l’exécute de lui-même si la tâche correspond à sa description ; mieux vaut donc une description sobre, concise et un peu ennuyeuse qu’une prose brillante
  • Claude Code fonctionne de la même manière (cf. l’article précédent sur les agent skills)
• Le skill est l’endroit où l’intention cesse d’être un coût récurrent
  • L’agent démarre chaque session à froid et comble les trous d’intention par des suppositions assurées (cf. l’article précédent sur the intent debt)
  • Un skill consiste à écrire cette intention à l’extérieur — conventions, étapes de build, ou encore « on ne fait pas ça ainsi à cause de tel incident » ; écrit une fois, relu à chaque exécution par l’agent
  • Sans skill, la loop doit redéduire le projet depuis zéro à chaque cycle ; avec un skill, les connaissances s’accumulent et produisent un effet composé
• Le skill est un format d’écriture, et le plugin est un mode de distribution — pour partager ou regrouper sur plusieurs repos, on package cela sous forme de plugin (même logique dans Codex comme dans Claude Code)

Plugins·connectors — pour que la loop atteigne les vrais outils

• Une loop qui ne voit que le système de fichiers reste une petite loop
  • Un connector basé sur MCP permet à l’agent de lire un issue tracker, interroger une base de données, appeler une API de staging ou envoyer un message Slack
  • Codex et Claude Code parlent tous deux MCP, si bien qu’un connector conçu pour l’un fonctionne souvent tel quel avec l’autre
  • Un plugin regroupe connector et skill, afin qu’un collègue puisse l’installer d’un bloc au lieu de tout reconstruire de mémoire
• C’est ce qui fait la différence entre un agent qui dit « voici un correctif » et une loop qui ouvre la PR, relie le ticket Linear et envoie un ping sur le canal quand la CI passe au vert
  • Les connectors permettent à la loop non pas seulement de décrire des possibilités, mais d’agir dans l’environnement réel

Sub-agents — séparer celui qui produit de celui qui contrôle

• Dans une loop, la structure la plus utile est sans doute la séparation entre l’agent qui écrit le code et celui qui le contrôle
  • Le modèle qui a écrit le code est trop indulgent lorsqu’il doit corriger sa propre copie
  • Un deuxième agent, avec d’autres instructions et parfois un autre modèle, détecte ce que le premier a fini par accepter lui-même
• Codex ne crée des subagents que sur demande, les exécute en parallèle, puis agrège les résultats en une seule réponse
  • On peut définir ses propres agents dans .codex/agents/ sous forme de fichiers TOML (name, description, instructions, avec en option model et reasoning effort)
  • Exemple : un relecteur sécurité sur un modèle puissant avec high effort, ou un explorer en lecture seule sur un modèle rapide
• Claude Code gère cela de façon équivalente avec les subagents dans .claude/agents/ et les agent teams qui se répartissent les tâches
  • Dans les deux outils, une répartition classique consiste à avoir un agent pour l’exploration, un pour l’implémentation et un pour la vérification face à la spec (cf. les articles précédents the code agent orchestra et adversarial code review)
• Comme une loop tourne pendant qu’on ne la regarde pas, il faut un vérificateur fiable (verifier) pour pouvoir s’éloigner
  • Chaque subagent utilisant son propre modèle et ses propres outils, cela consomme davantage de tokens ; mieux vaut réserver la seconde opinion aux endroits où elle a une vraie valeur
  • C’est aussi ce que fait en interne /goal dans Claude Code — un nouveau modèle décide si c’est terminé à la place de celui qui a fait le travail, en appliquant la séparation maker/checker à la condition d’arrêt elle-même

À quoi ressemble une loop concrète

• Une fois assemblé, un thread unique se transforme en petit panneau de contrôle ; voici une forme récurrente
  • Une automation s’exécute chaque matin sur le repo ; son prompt appelle un triage skill qui lit les échecs CI de la veille, les issues ouvertes et les commits récents, puis écrit les résultats dans un fichier Markdown ou un board Linear
  • Pour chaque élément qui vaut la peine, le thread ouvre un worktree isolé et confie un premier jet de correctif à un sub-agent ; un second sub-agent relit ensuite ce brouillon au regard du skill projet et des tests existants
  • Un connector permet ensuite à la loop d’ouvrir une PR et de mettre à jour le ticket ; ce que la loop n’arrive pas à traiter finit dans la Triage inbox
  • Le fichier d’état (state file) forme la colonne vertébrale de l’ensemble — il mémorise ce qui a été tenté, ce qui est passé et ce qui reste ouvert, afin que l’exécution du lendemain reprenne là où celle d’aujourd’hui s’est arrêtée
• L’essentiel est qu’aucune de ces étapes n’a été promptée au moment de l’exécution : elle a été conçue une fois, et qu’on soit sur Codex ou Claude Code, les composants étant les mêmes, la loop l’est aussi

Ce que la loop ne fait toujours pas à votre place

• La loop change la nature du travail, mais ne supprime pas l’humain ; au contraire, plus elle s’améliore, plus trois problèmes deviennent aigus
• La validation reste votre responsabilité
  • Une loop qui tourne sans supervision est aussi une loop qui peut se tromper sans supervision
  • Si l’on sépare le sub-agent verifier du maker, c’est pour donner un sens au « c’est fini » de la loop ; mais malgré cela, done n’est pas une preuve, c’est une affirmation (cf. l’article précédent code review in the age of AI — le vrai travail consiste à livrer du code dont on a vérifié le fonctionnement)
• La compréhension se dégrade si on la laisse de côté
  • Plus une loop permet de livrer vite du code qu’on n’a pas écrit soi-même, plus l’écart se creuse entre ce qui existe et ce que l’on comprend réellement
  • C’est la comprehension debt ; une loop fluide l’aggrave encore plus vite si l’on ne lit pas ce qu’elle produit
• La posture la plus confortable est aussi la plus dangereuse
  • Quand la loop tourne seule, il devient facile de cesser d’avoir un avis et d’accepter tel quel ce qui revient (cognitive surrender)
  • Concevoir des loops est un remède si cela s’accompagne de jugement ; c’est un accélérateur du problème si l’on s’en sert pour éviter de penser — même geste, résultat opposé

Construisez la loop, mais restez ingénieur

• Cela ressemble à un aperçu de l’évolution du travail, mais si l’on ne relit plus directement le code ou que l’on ne s’appuie que sur des loops automatiques, la qualité produit peut se dégrader et entraîner dans une spirale descendante de plus en plus profonde
• Mettre en place des loops n’empêche pas que prompter directement un agent reste toujours efficace ; l’enjeu est de trouver le bon équilibre
• Les loops peuvent produire des effets totalement opposés selon les personnes — parmi deux personnes ayant construit la même loop, l’une ira plus vite sur un travail qu’elle comprend en profondeur, l’autre s’en servira pour éviter de comprendre
  • La loop ne connaît pas cette différence, mais vous, si
• Voilà pourquoi concevoir des loops n’est pas plus simple que le prompt engineering, mais plus difficile encore — le point de Cherny n’est pas que le travail est devenu facile, c’est que le point de levier s’est déplacé
• Conclusion : construisez des loops, mais faites-le comme quelqu’un qui restera ingénieur, pas comme quelqu’un qui se contente d’appuyer sur le bouton Start

[shakespeares]

La vérification reste malgré tout de votre ressort

La compréhension se dégrade si on la laisse à l’abandon

Une posture confortable est une posture dangereuse

=> Au final, il faut quand même vérifier soi-même et recourir à un prompting qui minimise les tâches répétitives.