Loop Engineering - Addy Osmani

L’étape suivante proposée pour les agents de codage IA : le « loop engineering »

Cet article, centré sur « Loop engineering » d’Addy Osmani, explore l’idée qu’on peut passer d’un mode où l’humain donne à chaque fois des instructions directes à l’agent de codage, à un mode où l’on conçoit un système itératif dans lequel l’agent trouve le travail, le découpe, le vérifie et détermine la tâche suivante. Ici, la boucle se rapproche d’un « flux de travail que l’IA exécute de manière répétée plusieurs fois vers un objectif défini ». L’article ne présente toutefois pas cela comme une solution miracle. Il souligne aussi les coûts bien réels : coût en tokens, responsabilité de la vérification et baisse possible de la compréhension côté développeur.

Résumé des points clés

Ce que signifie le loop engineering

Jusqu’ici, le développeur écrivait un prompt pour l’agent de codage, lisait le résultat, puis redonnait des instructions. Le loop engineering décrit dans l’article est une approche qui transforme ce processus en une structure automatisée. Autrement dit, au lieu d’intervenir à chaque étape, l’humain conçoit le système : « quoi chercher, comment le traiter et quand s’arrêter ».

Éléments de composition

L’auteur présente comme composants nécessaires à la création d’une boucle : l’exécution automatique, les worktrees, les skills, les plugins et connecteurs, les sous-agents, ainsi que la mémoire externe. Les worktrees sont une fonctionnalité Git qui divise le même dépôt en plusieurs espaces de travail afin de réduire les conflits. Les skills servent à documenter les règles et connaissances du projet pour éviter que l’agent ait à les deviner à chaque fois. Les connecteurs sont les passerelles vers des outils externes comme Linear, Slack ou des bases de données.

Avantages

Pour réduire les tâches répétitives, il devient possible d’automatiser des travaux comme le résumé des échecs de CI, la classification des issues ou la revue des commits récents. Côté traitement parallèle, plusieurs agents peuvent travailler chacun dans un worktree différent afin de limiter les conflits de fichiers. En matière de réutilisation des connaissances, les pratiques du projet et les procédures de build peuvent être conservées sous forme de skills, évitant de répéter les mêmes explications à chaque session.

Inconvénients et risques

La charge de vérification ne disparaît pas. Les résultats produits par la boucle doivent toujours être contrôlés par un humain. Le coût en tokens peut aussi augmenter. Lorsque le nombre de sous-agents grandit, chacun utilise séparément le modèle et les outils. La dette de compréhension constitue également un problème. Si les développeurs acceptent les résultats sans les lire, le codebase peut grossir tandis que la part réellement comprise par les humains se réduit.

Ce qui le distingue

Là où le prompt engineering classique se concentre sur « une bonne question unique », le loop engineering se rapproche davantage de la conception d’un « système de travail répétable ». L’auteur estime qu’à mesure que Codex et Claude Code intègrent des composants similaires — automatisation, skills, connexions basées sur MCP, sous-agents —, la conception des boucles devient un sujet plus important que l’outil lui-même.

Points forts

La séparation entre l’auteur et le vérificateur est une caractéristique importante. Si l’agent qui a produit le code évalue lui-même le résultat, il peut se montrer trop indulgent ; l’article propose donc une structure où un sous-agent distinct effectue la revue. Le maintien d’une mémoire externe est également central. Il faut conserver l’état en dehors de la conversation, dans un fichier Markdown ou un tableau d’issues par exemple, pour pouvoir reprendre au prochain lancement.

Le loop engineering se lit moins comme une histoire de remplacement des développeurs que comme un déplacement des points d’intervention du développeur. Le centre de gravité se déplace de l’écriture continue de prompts vers la conception de structures répétitives, de conditions de vérification, de répartition du travail et de méthodes de traçabilité. Mais une bonne boucle ne remplace pas un bon jugement. Sans la capacité d’ingénierie nécessaire pour lire le code, le vérifier et comprendre les limites du système, l’automatisation peut faire croître les risques avant même d’accélérer la vitesse.