La prochaine etape du codage avec IA n’est pas seulement d’ecrire de meilleurs prompts. C’est de concevoir de meilleures boucles.
C’est l’argument de cobusgreyling/loop-engineering, un depot de reference sous licence MIT pour les workflows recurrents d’agents de codage IA. Le projet donne aux developpeurs des patterns, starters, checklists, exemples et outils CLI pour transformer des prompts ponctuels en systemes capables de decouvrir du travail, conserver l’etat, tourner a une cadence, verifier les sorties et escalader quand le jugement humain est necessaire.
Le message est direct : arretez de prompter, concevez la boucle, obtenez un score.
C’est important parce que beaucoup de workflows de codage IA restent fragiles. Un developpeur ouvre un chat, colle du contexte, demande a l’agent de corriger quelque chose, relit le resultat, puis repete manuellement. C’est utile, mais cela passe mal a l’echelle. Chaque nouvelle session perd l’intention. Chaque prompt manuel devient du travail d’orchestration. Chaque tache longue depend de la memoire humaine.
Loop Engineering traite l’agent comme une partie d’un systeme de controle.
Ce qu’est Loop Engineering
Loop Engineering est un projet de reference pour construire des workflows recurrents d’agents de codage IA. Ce n’est pas seulement une collection de prompts. C’est un guide de conception systeme pour des boucles d’agents.
Le depot inclut :
- des patterns de boucle comme daily triage, PR babysitter, CI sweeper, dependency sweeper, changelog drafter, post-merge cleanup et issue triage
- des starters pour Grok, Claude Code, Codex, OpenClaw, Opencode et GitHub Actions
- des outils CLI comme
loop-init,loop-audit,loop-cost,loop-sync,loop-contextetloop-mcp-server - des templates, exemples, skills, docs, stories et conseils d’exploitation
- une checklist de preparation qui va de l’intention documentee au mode rapport, puis aux corrections assistees, puis a l’operation autonome
L’idee centrale est simple : si un agent de codage IA doit travailler de facon repetee, il lui faut une boucle autour de lui.
Pourquoi c’est important
Le prompt est une surface de controle manuelle. Cela fonctionne quand la tache est petite et que l’humain est present. Mais beaucoup de problemes engineering sont recurrents :
- surveiller les issues et les categoriser
- scanner les PR et reperer les discussions bloquees
- inspecter les echecs CI et proposer la prochaine correction
- verifier les dependances et ouvrir des PR de mise a jour prudentes
- rediger des entrees de changelog apres merge
- nettoyer l’etat apres merge
- maintenir une memoire projet a jour
Ce ne sont pas des problemes a prompt unique. Ils ont besoin de cadence, d’etat, de verification et de regles de handoff.
Loop Engineering rend ce changement explicite. Le role de l’humain passe de “ecrire la prochaine instruction” a “concevoir le systeme de controle qui decide quelle instruction vient ensuite”.
Les six primitives utiles
Le depot presente loop engineering autour de cinq primitives plus la memoire.
La premiere primitive est automation ou scheduling. Une boucle a besoin d’un battement : cron, GitHub Actions, scheduling natif d’un outil, /loop, /goal ou un autre declencheur recurrent. Sans scheduling, le workflow reste une execution manuelle d’agent.
La deuxieme est l’isolation par worktree. Si plusieurs agents modifient les memes fichiers dans le meme working tree, les collisions deviennent inevitables. Les worktrees permettent a des executions separees d’operer dans des repertoires isoles tout en partageant l’historique Git.
La troisieme est les skills. Les skills capturent conventions projet, standards de revue, commandes de build et connaissance domaine. Cela reduit la dette d’intention, car la boucle n’a pas a redecouvrir les memes regles a chaque lancement.
La quatrieme est plugins et connectors, souvent via MCP. Une boucle devient plus utile quand elle peut lire des tickets, mettre a jour des issues, poster des resumes, interroger des systemes internes ou creer des PR avec permissions limitees.
La cinquieme est les sous-agents, surtout la separation maker/checker. L’agent qui ecrit le changement ne doit pas etre le seul juge de sa correction. La verification a besoin de separation.
La sixieme est memoire ou etat. Une boucle a besoin de contexte durable hors du chat : STATE.md, LOOP-STATE.json, un board, une ligne de base de donnees ou un autre journal de ce qui s’est passe au run precedent.
Les outils CLI
Le depot est pratique parce qu’il livre des outils, pas seulement des concepts.
loop-init scaffold un projet avec fichiers de boucle, skills, fichiers de budget et commandes de demarrage. Il peut cibler differents outils agents et patterns.
loop-audit donne un Loop Readiness Score et des suggestions. C’est utile parce que la plupart des automations agents echouent aux frontieres invisibles : etat manquant, verification faible, scope flou, pas de denylist ou pas de budget.
loop-cost estime la depense en tokens pour un pattern et une cadence. C’est important parce que les boucles autonomes peuvent devenir couteuses discretement, surtout avec sous-agents ou checks CI frequents.
loop-sync verifie la derive entre STATE.md et LOOP.md. C’est un detail operationnel petit mais important. Une boucle qui agit depuis un etat obsolet est pire qu’aucune boucle.
loop-context gere la memoire stateful et des comportements de circuit breaker pour les longues executions. loop-mcp-server expose via MCP la recherche runtime de patterns, skills et etat.
Ensemble, ces outils transforment loop engineering d’une idee de blog en quelque chose qu’un developpeur peut tester dans un depot.
Niveaux de preparation : L1, L2, L3
Le modele de preparation est l’un des meilleurs aspects du projet.
L0 est l’intention documentee. Vous savez ce que la boucle doit faire, mais elle n’est pas prete a tourner.
L1 est le mode rapport. La boucle peut trier, resumer et ecrire l’etat. Elle ne modifie pas le code. C’est le bon point de depart pour la plupart des equipes, car elle montre ce que la boucle ferait sans la laisser agir.
L2 est l’operation assistee. La boucle peut faire de petits changements, mais seulement avec permissions limitees, verification separee, isolation par worktree, handoff humain explicite et permissions de connecteurs claires.
L3 est l’operation autonome. Elle exige toute la checklist : objectif, scheduling, skills, separation maker/checker, etat, regles de handoff, scopes de connecteurs, limites de cout, observabilite, politique de securite et criteres d’arret.
Cette progression est saine. Trop d’equipes passent directement de “l’agent peut modifier du code” a “l’agent devrait tourner seul”. Loop Engineering pousse le chemin inverse : observer d’abord, assister ensuite, automatiser seulement quand les modes d’echec sont compris.
Ou cela s’insere avec Codex, Claude Code, Grok et Opencode
Loop Engineering est volontairement conscient des outils, sans etre verrouille a un outil.
Le depot inclut des exemples et starters pour Grok, Claude Code, Codex, OpenClaw, Opencode et GitHub Actions. C’est le bon niveau d’abstraction. Le concept de boucle doit survivre aux changements d’outil, car les parties durables ne sont pas le nom du modele. Ce sont la cadence, l’etat, la chaine de verification, la politique de securite et les regles de handoff.
Pour des agents locaux de style Codex, le pattern est particulierement pertinent. Une bonne boucle peut :
- lire l’etat du repo et la memoire au debut d’un run
- choisir une petite tache cadre
- faire les changements dans un workspace isole
- executer tests et gates de build
- demander l’approbation humaine quand les permissions ou le jugement produit l’exigent
- mettre a jour l’etat durable avant de sortir
C’est beaucoup plus proche du fonctionnement reel des equipes engineering.
Risques et limites
Loop Engineering n’est pas un raccourci autour du jugement engineering.
Le depot est explicite sur les dangers : les couts en tokens peuvent exploser, les boucles autonomes peuvent faire des erreurs autonomes, la dette de comprehension augmente si les humains cessent de lire les sorties, et deux personnes peuvent executer la meme boucle avec des resultats opposes car la boucle ne comprend pas le jugement organisationnel par defaut.
Le plus grand risque est la reddition cognitive : traiter la boucle comme un remplacement de la pensee. Une bonne boucle encode le jugement. Une mauvaise boucle cache le fait que le jugement a disparu.
C’est pourquoi les consignes de securite comptent. Mettez secrets et chemins d’infrastructure en denylist. Evitez l’auto-merge sans allowlist explicite. Gardez des triggers d’escalade humaine clairs. Journalisez chaque run. Limitez les couts. Separez l’implementer du verifier.
Mon avis
Loop Engineering est l’un des patterns les plus utiles du developpement assiste par IA parce qu’il nomme le vrai probleme.
Le goulot n’est plus seulement la qualite du prompt. Le goulot est la repetabilite : comment les agents decouvrent le travail, conservent le contexte, isolent les changements, verifient les resultats, gerent le cout et rendent la main a un humain quand la tache franchit une limite de risque.
Le projet n’est pas une plateforme finie, et c’est une force. C’est un kit de reference pour concevoir votre propre boucle autour de votre repo, votre agent et votre tolerance au risque.
Pour les equipes qui utilisent deja Codex, Claude Code, Grok, Cursor, Opencode ou des outils similaires, cobusgreyling/loop-engineering merite d’etre etudie parce qu’il deplace la conversation de “quel prompt ecrire ensuite ?” vers “quel systeme doit decider, executer, verifier et memoriser la prochaine etape ?”