Loop engineering : concevoir des workflows fiables autour des agents de codage IA

Une interaction classique avec un agent de codage IA est séquentielle : rédiger un prompt, examiner la response, fournir davantage de contexte, puis recommencer. Cela fonctionne pour des tâches ciblées, mais le développeur reste responsable du pilotage de chaque étape.

Le loop engineering modifie ce modèle de contrôle. Au lieu de solliciter manuellement l’agent tout au long de la tâche, vous concevez un workflow capable de sélectionner le travail à effectuer, de l’exécuter, de vérifier le résultat, d’enregistrer la progression et de décider de la suite.

Le changement important ne consiste pas simplement à exécuter le même prompt de manière répétée. Une boucle utile nécessite une structure, des limites et des éléments prouvant que le travail est réellement terminé.

Des prompts aux systèmes de contrôle

Un prompt décrit généralement l’action suivante. Une boucle décrit un objectif et le processus permettant de l’atteindre.

Par exemple, demander à un agent de corriger un test en échec constitue un prompt. Une boucle pourrait plutôt :

1. Lire les derniers résultats des tests.
2. Sélectionner un échec.
3. Le reproduire localement.
4. Examiner le code concerné.
5. Apporter une modification limitée.
6. Exécuter les tests concernés et les vérifications statiques.
7. Enregistrer le résultat.
8. Continuer, s’arrêter ou déclencher une escalade en fonction des éléments recueillis.

Cela ressemble aux automatisations existantes fondées sur des tâches planifiées, des webhooks, des files d’attente et des pipelines CI. La différence est qu’un agent peut prendre des décisions adaptatives au sein du workflow, par exemple choisir les fichiers à examiner ou la commande de diagnostic à exécuter.

Cette flexibilité est utile, mais elle rend aussi la vérification et les limites opérationnelles plus importantes.

Les composants d’une boucle utile

Une boucle d’ingénierie pratique nécessite généralement plusieurs éléments.

Un déclencheur lance le workflow. Il peut s’agir d’une planification, d’un nouveau ticket, d’un build en échec, d’un rapport d’erreur ou d’une request manuelle.

Un objectif mesurable définit ce qui doit devenir vrai. « Améliorer le service de paiement » est trop vague. « Faire réussir la suite de tests de conformité du paiement sans modifier son API publique » fournit à la boucle un résultat qu’elle peut évaluer.

Des outils et du contexte donnent à l’agent accès au dépôt, aux tests, aux commandes de build, au système de suivi des tickets, aux logs et aux conventions du projet. Sans ces informations, l’agent doit deviner le fonctionnement du système.

Un persistent state enregistre le travail terminé, les constats actuels, les tentatives infructueuses et les tâches restantes en dehors d’une conversation unique avec le modèle. Il peut s’agir d’un fichier Markdown, d’un tableau de tickets, d’un enregistrement de database ou d’un autre espace de stockage durable. Le state conservé permet à une exécution ultérieure de reprendre sans avoir à reconstituer l’intégralité de l’historique à partir du contexte de la conversation.

La vérification contrôle le résultat selon des critères explicites. Les contrôles déterministes, tels que la compilation, les tests, le formatage, la validation des schémas et les seuils de performance, doivent être privilégiés lorsqu’ils sont disponibles. Un agent réviseur distinct peut apporter un autre point de vue, mais il ne doit pas remplacer les contrôles objectifs.

Les règles d’arrêt et d’escalade empêchent la boucle de se poursuivre indéfiniment. Parmi les limites utiles figurent un nombre maximal de tentatives, des budgets de tokens ou de coûts, des délais d’expiration, des périmètres de fichiers restreints et des conditions exigeant une approbation humaine.

La vérification constitue le véritable travail d’ingénierie

La partie exécution d’une boucle est généralement facile à décrire : laisser l’agent examiner le problème et apporter une modification. La difficulté consiste à définir ce qui constitue une réussite.

Le fait qu’un agent déclare une tâche terminée ne constitue pas une preuve suffisante. La boucle doit recueillir des résultats qu’un autre processus ou une autre personne peut examiner. Pour une modification de code, cela peut inclure :

• Le diff exact produit
• Les résultats des tests et du build
• Les résultats de l’analyse statique
• Les mesures de performance
• Une liste d’hypothèses et de questions non résolues
• Un lien entre la modification et le ticket dont elle est issue

Il est également utile de séparer le créateur du vérificateur. Un agent peut mettre en œuvre la modification tandis qu’un autre l’examine au regard de l’objectif et des règles du projet. Cela réduit l’auto-confirmation, bien que cela augmente la latence et l’utilisation du modèle.

La révision humaine reste importante lorsque l’exactitude dépend de l’architecture, de l’intention produit, de la sécurité ou du contexte métier. Les contrôles automatisés peuvent confirmer que les tests réussissent. Ils ne peuvent pas toujours déterminer si l’implémentation constitue la bonne modification pour le système.

Commencer par des workflows délimités

Le loop engineering convient mieux aux tâches répétitives dont les résultats sont observables qu’au développement vague et sans limites précises.

Parmi les points de départ raisonnables figurent le tri des échecs de CI, la révision des mises à jour de dépendances, la reproduction des erreurs enregistrées, la vérification des liens de documentation ou l’analyse des tests instables. Ces workflows disposent déjà d’entrées, de résultats attendus et d’outils de validation établis.

La première version doit rester limitée : traiter un seul élément à la fois, travailler dans une branche isolée ou un Git worktree, exiger la réussite des tests, limiter le nombre de nouvelles tentatives et produire une pull request à réviser plutôt que de fusionner automatiquement.

L’ingénieur reste responsable

Une boucle peut réduire les interactions répétitives avec un agent de codage, mais elle ne transfère pas la responsabilité. Un contexte insuffisant, des critères d’achèvement trop faibles ou l’absence de limites permettent aux erreurs de se répéter à la vitesse d’une machine, tout en consommant davantage de temps et de tokens.

La partie utile du loop engineering n’est donc pas la génération de code sans supervision. C’est la conception explicite du système qui l’entoure : comment le travail entre dans le système, ce que l’agent peut modifier, comment la progression est conservée entre les exécutions, comment les résultats sont vérifiés et quand un humain doit reprendre le contrôle.

La qualité des prompts reste importante au sein de ce système. La tâche d’ingénierie plus large consiste à décider comment les prompts, les outils, le state, les contrôles et le jugement humain fonctionnent ensemble au sein d’un workflow contrôlé unique.

Références

• Loop Engineering — addyosmani.com
• The Art Of Loop Engineering — langchain.com
• What Is Loop Engineering — newsletter.pragmaticengineer.com