Loop Engineering: The Guide for AI Agents

À retenir

1. Définition en une phrase. le loop engineering construit des systèmes qui promptent les agents selon un planning et vers un objectif, au lieu de taper des prompts individuels. Le levier passe de la qualité d'un prompt à la conception du système.
2. Deux niveaux de boucle. la boucle interne (perceive-reason-act-observe à chaque tour, déjà native aux agents) vs la boucle externe qu'on conçoit (planning, helpers, auto-alimentation en travail, persistance sur de nombreux tours).
3. Filiation en 3 couches. (chacune englobe la précédente) : Prompt Engineering (1 instruction) → Context Engineering (contenu de la fenêtre) → Loop Engineering (système qui décide quoi prompter, quand, et si le résultat est acceptable). Le prompt et le contexte restent indispensables — un mauvais prompt produit juste du mauvais travail plus vite.
4. Origine du terme. popularisé par Addy Osmani (Google) en juin 2026, sur les observations de Peter Steinberger (« you should be designing loops that prompt your agents ») et de Boris Cherny (lead Claude Code chez Anthropic : son focus est passé à écrire des boucles plutôt qu'à prompter directement).
5. Technique Ralph. (Geoffrey Huntley, début 2026, d'après Ralph Wiggum) : faire tourner l'agent dans une simple boucle while, même prompt à chaque itération, contre une spec écrite, contexte neuf à chaque tour. L'innovation non-évidente = le reset du contexte (évite la dégradation des longues sessions). L'intelligence vient des specs claires + résultats vérifiables + mémoire externe (PLAN.md, STATUS.md), pas de runs héroïques.
6. Le loop engineering productise Ralph. le while devient automation planifiée, les resets deviennent worktrees/sub-agents, le check « ALL TASKS DONE » devient une condition /goal vérifiée par un modèle séparé.
7. 5 briques + mémoire. (1) Automations (déclencheurs planifiés de découverte/tri) ; (2) Worktrees (agents parallèles sans collision) ; (3) Skills (savoir projet documenté) ; (4) Plugins/connecteurs (MCP, accès aux outils réels) ; (5) Sub-agents (séparer génération et vérification) ; (6) Mémoire (markdown, boards Linear/GitHub — hors fenêtre de contexte). « Agents forget. Repositories remember. »
8. Claude Code et Codex embarquent les 5 briques + mémoire. sous des noms différents mais structures identiques → concevoir des boucles qui survivent au changement d'outil.
9. Automations. Codex (onglet Automations, runs vers Triage inbox, runs vides s'auto-archivent) ; Claude Code (/loop + hooks + intégration GitHub Actions). Primitive in-session clé = /goal : maintient le travail jusqu'à ce que la condition spécifiée soit vérifiablement vraie, un modèle plus petit distinct note la complétion à chaque tour (l'agent ne s'auto-évalue pas).
10. État mi-2026. /goal livré dans Claude Code v2.1.139 (11 mai 2026), branche 2.1.x avec Opus 4.8 par défaut + workflows dynamiques orchestrant de larges flottes de sub-agents ; Codex a ajouté /goal en CLI 0.128.0. Des praticiens rapportent des agents travaillant des dizaines d'heures sans surveillance → les conditions d'arrêt deviennent l'élément le plus critique.
11. Écrire les conditions d'arrêt comme des contrats. état final + preuve + contraintes + plafond turns/budget. Ex. « couverture src/billing ≥ 90 % ; npm test sort 0 ; aucune API publique modifiée ; stop après 25 tours ou 5 $ ».
12. Trois pratiques pour des boucles fiables. (équipes Claude Code) : préserver les erreurs (pour que la boucle apprenne au lieu de répéter), intégrer la vérification dès le départ, traiter tests rouges / CI rouge comme des signaux d'honnêteté. Une boucle sans preuve d'échec croit toujours avoir réussi.
13. Worktrees. = isolation git réelle (répertoires séparés sur branches distinctes, historique partagé). Mais « You remain the ceiling » : la capacité humaine de revue, pas le nombre de worktrees, détermine combien d'agents parallèles on fait vraiment tourner.
14. Sub-agents maker-checker. = le changement structurel le plus puissant : un agent vérificateur adversarial (modèle fort, haute réflexion, instruit pour rejeter ce qui n'est pas prouvé) gardant le travail avant la revue humaine. Les modèles qui notent leur propre travail sont trop généreux.
15. Échelle de maturité (Niveaux 0→4). 0 Manuel → 1 Triage (findings en markdown, pas de code) → 2 Draft (fixes sur branches isolées) → 3 Verified PR (sub-agent vérificateur en gate) → 4 Auto-merge (catégories à faible risque sur CI verte). Ne monter d'un cran que si le niveau actuel produit du travail qu'on aurait fait soi-même.
16. 3 risques qui s'aggravent (pas s'atténuent). la vérification reste ta responsabilité (« done » = revendication, pas preuve) ; la dette de compréhension s'accélère (le code part plus vite qu'on ne le comprend) ; la capitulation cognitive (accepter les sorties sans jugement) — deux personnes construisant la même boucle obtiennent des résultats opposés selon qu'elles l'utilisent pour avancer sur du travail compris ou pour éviter de le comprendre.
17. Attention aux tokens. boucles planifiées + modèles vérificateurs post-tour brûlent des tokens vite. Commencer avec des cadences lentes et des conditions serrées, monitorer les coûts plusieurs jours, scaler seulement après preuve de travail mergé utile.
18. Sécurité. les boucles autonomes avec connecteurs touchent la prod → garde-fous, permissions, audit logging nécessaires.