Le 7 juin, l’ingénieur logiciel chez Google Addy Osmani a publié un article définissant « Loop Engineering » comme une méthode de conception d’agents d’IA avec prompts automatisée qui remplace la démarche manuelle consistant à écrire des prompts par un système d’automatisation. Cette approche est composée de cinq blocs : Automations, Worktrees, Skills, Plugins/Connectors et Sub-agents.
Définitions et fonctions des cinq blocs
D’après le cadre présenté par Addy Osmani :
Automations (automatisations) : Tâches déclenchées par programmation, chargées d’exécuter automatiquement les phases de « découverte » (Discovery) et de « tri » (Triage). Osmani explique que les Automations sont le mécanisme central qui transforme la boucle en un véritable cycle plutôt qu’une simple exécution « one-shot ». L’application Codex utilise des pages Automations et fournit la commande /goal (exécuter jusqu’à ce que la condition soit satisfaite) ; Claude Code obtient la même fonctionnalité via des tâches planifiées, cron, /loop, /goal et GitHub Actions.
Worktrees (arbres de travail) : Utilise le mécanisme git worktree pour créer des répertoires de travail indépendants pour des agents exécutés en parallèle, évitant ainsi les conflits causés par plusieurs agents modifiant simultanément le même fichier. L’application Codex intègre worktree pour chaque thread ; Claude Code propose un mécanisme d’isolation équivalent via git worktree et l’option --worktree.
Skills (compétences) : Les connaissances du projet, les conventions et les étapes de build sont consignées dans un fichier externe au format SKILL.md, afin que l’agent n’ait pas besoin de recontextualiser le projet à chaque exécution. Les deux outils utilisent le même format SKILL.md ; Osmani précise qu’une description précise vaut mieux qu’un récit flou.
Plugins / Connectors (plugins et connecteurs) : Construits à partir de MCP (Model Context Protocol), afin que l’agent puisse accéder à des systèmes externes comme les Issue Trackers, des bases de données, des points d’API et des outils de communication. L’application Codex et Claude Code prennent en charge MCP ; Osmani confirme qu’un même connector peut généralement être utilisé directement dans les deux outils.
Sub-agents (sous-agents) : Sépare le « agent d’exécution » et le « agent de validation » en rôles indépendants, avec des commandes différentes voire des modèles différents pour permettre une relecture croisée et éviter qu’un agent ne s’auto-évalue de façon trop indulgente. L’application Codex définit cela en format TOML dans .codex/agents/ ; Claude Code définit les subagents de Task et des équipes d’agents dans .claude/agents/.
Mémoire externe (State) : définition et rôle du sixième composant
Osmani définit la mémoire externe comme « toute information qui existe en dehors d’une seule conversation et qui sert à consigner ce qui a été fait et ce qui doit se passer ensuite », par exemple des fichiers Markdown ou un tableau Linear. La raison de sa nécessité : les grands modèles de langage ne conservent pas de mémoire entre les exécutions ; la progression doit donc être stockée à l’extérieur, plutôt que dans la fenêtre de contexte du modèle.
Les deux outils prennent en charge ce mécanisme : Codex app relie Linear via Markdown ou un Connector ; Claude Code relie Linear via AGENTS.md, un fichier de progression ou une connexion MCP.
Questions fréquentes
Quelle est la différence clé entre Loop Engineering et le Prompt Engineering traditionnel ?
D’après le cadre d’Addy Osmani, le Prompt Engineering traditionnel consiste à ce que l’ingénieur écrive manuellement les prompts et interagisse avec l’agent à chaque tour ; Loop Engineering, lui, conçoit un système complet où Automations déclenche automatiquement, Worktrees isole l’exécution en parallèle, Skills fournit les connaissances, Connectors connecte les outils, et Sub-agents sépare l’exécution et la validation. Le rôle de l’ingénieur passe de « piloter directement l’agent » à « concevoir un système qui fait tourner l’agent ».
Quelles briques chacun des outils, Codex app et Claude Code, prend-il en charge actuellement ?
D’après l’analyse comparative d’Osmani, au moment de la publication de son article, les deux outils prennent tous deux en charge intégralement les cinq briques ainsi que le mécanisme de mémoire externe. Les principales différences résident dans les noms et les chemins précis : les fonctionnalités Automations ont une correspondance ; Worktrees repose sur git worktree ; Skills utilise le format SKILL.md ; Plugins/Connectors repose sur MCP ; Sub-agents utilise des fichiers de configuration dans le répertoire .agents/.
Comment la « séparation entre exécution et validation » des Sub-agents est-elle mise en œuvre ?
D’après les explications d’Osmani, le design des Sub-agents fait de « l’agent qui écrit le code » et de « l’agent qui vérifie le code » deux rôles distincts, avec éventuellement des instructions différentes voire des modèles différents. La commande /goal de Claude Code applique la même logique : un tout nouveau modèle décide si la tâche est terminée, plutôt que le modèle qui exécute la tâche de s’auto-évaluer. Osmani appelle cela l’application « celui qui fait vs celui qui vérifie » au mécanisme même des conditions d’arrêt.
