Ne promtez plus manuellement votre agent de code. Créez une boucle d'automatisation

Vous ne devriez plus donner d'instructions directes (prompting) aux agents de codage. Vous devriez concevoir des boucles qui guident vos agents. Cela peut sembler une phrase anodine, mais elle souligne le changement le plus important dans la façon dont les bons ingénieurs travaillent avec l'IA actuellement. Les personnes qui tirent un réel parti des agents de codage IA ont cessé de traiter l'agent comme un partenaire de discussion. Elles le traitent comme un travailleur au sein d'une boucle qu'elles ont construite.

En bref

Une boucle d'agent de codage est une structure de contrôle qui exécute un agent de manière répétée : générer un changement, l'exécuter, vérifier le résultat par rapport à un signal fort, réinjecter l'échec, répéter jusqu'à ce que la vérification passe ou qu'une limite soit atteinte. L'agent n'est pas la partie difficile. La porte de vérification l'est. Une boucle avec une porte vague (« ça a l'air bien, réessayez ») dérive et hallucine le « terminé ». Une boucle avec une porte déterministe (un test échoué, une incompatibilité de schéma, un contrat rompu) converge. Pour le travail d'API et de backend, votre suite de tests automatisés et vos vérifications de contrats sont cette porte, c'est pourquoi les tests d'API doivent être au centre d'un flux de travail agentique, et non greffés à la fin.

Du "prompting" à la conception de boucles

La plupart des gens découvrent le codage par IA via une boîte de discussion. Vous tapez une requête, lisez la réponse, copiez ce qui fonctionne et tapez à nouveau. C'est du "prompting" (saisie d'instructions). C'est bien pour une fonction ponctuelle ou une explication rapide. Cela s'effondre dès que la tâche nécessite plus d'un cycle de rétroaction pour être correctement réalisée, ce qui est le cas de la plupart des tâches réelles.

Voici le problème du "prompting" manuel. Vous êtes la boucle. Vous lisez la sortie, vous repérez le bug, vous décidez quoi dire ensuite, vous collez l'erreur en retour. Chaque itération attend un humain. L'agent peut générer du code en quelques secondes, puis reste inactif pendant des minutes pendant que vous changez de contexte, faites défiler et tapez. Vous devenez la partie lente d'un système rapide.

Concevoir une boucle inverse cela. Au lieu d'être celui qui lit la sortie et décide de la prochaine instruction, vous construisez un harnais qui le fait automatiquement. L'agent écrit du code. Un script l'exécute. Le résultat est capturé. S'il a échoué, l'échec est directement renvoyé à l'agent comme instruction suivante. Aucun humain dans la boucle interne. Vous n'intervenez qu'aux limites : pour définir la tâche, pour approuver le résultat, pour arrêter l'exécution si cela dérape. L'article d'Anthropic sur la construction d'agents efficaces formule le même point avec des mots différents. Le succès vient de l'environnement que vous construisez autour du modèle, et non d'une instruction unique plus astucieuse.

Le changement de modèle mental est petit mais total. Cessez de demander « que dois-je dire à l'agent ? » Commencez à demander « quelle boucle permettrait à l'agent de se dire les choses lui-même ? »

Ce qu'est réellement une boucle d'agent de codage

Si l'on écarte le battage médiatique, une boucle d'agent de codage comporte cinq parties. Si l'une d'elles manque, la boucle ne se termine jamais ou se termine mal.

1. Une spécification de tâche. Une description claire et écrite de ce à quoi ressemble le résultat final. Pas « faites-le fonctionner », mais « le point de terminaison POST /orders renvoie 201 avec la commande créée, valide le corps par rapport au schéma et rejette les champs manquants avec 422 » ou quelque chose de similaire.
2. L'agent. Le modèle et ses outils : lire des fichiers, écrire des fichiers, exécuter des commandes shell. C'est la partie sur laquelle tout le monde se concentre et celle que vous contrôlez le moins.
3. Une étape d'action. L'agent effectue un changement, puis quelque chose l'exécute réellement. Des tests, une compilation, une vérification de type, une requête contre un point de terminaison en direct.
4. Une porte de vérification. Une vérification déterministe qui renvoie succès ou échec avec une raison concrète. C'est le volant. Nous consacrerons la majeure partie de cet article ici.
5. Une condition de terminaison. Quand la boucle s'arrête-t-elle ? La porte passe, ou vous atteignez un nombre maximum d'itérations, ou vous dépassez un budget de coût. Une boucle sans sortie est un emballement, pas un flux de travail.

En pseudocode, l'ensemble du modèle tient en quelques lignes :

task = load_spec("orders-endpoint.md")
for attempt in range(MAX_ITERATIONS):
    agent.run(task, feedback=last_result)   # générer
    result = run_verification()             # exécuter + vérifier la porte
    if result.passed:
        break                               # terminer : succès
    last_result = result.failures           # réinjecter l'échec
else:
    escalate_to_human(last_result)          # terminer : abandon

Cette boucle est l'idée maîtresse. L'agent génère, la porte juge, l'échec devient l'instruction suivante, et le tout s'exécute jusqu'à ce que tout soit correct ou que les tentatives soient épuisées. La variante que les gens partagent en ligne comme technique « Ralph » est celle-ci avec MAX_ITERATIONS défini haut et la spécification écrite de manière rigoureuse. Si vous avez lu notre analyse de l'architecture du harnais d'agent, voici le harnais dans sa forme la plus simple et la plus honnête.

Pourquoi le "prompting" ponctuel atteint ses limites

Une seule instruction suppose que le modèle réussit du premier coup, ou que vous repérerez ce qu'il a mal fait. Ces deux hypothèses s'effondrent à grande échelle.

Les modèles sont performants pour générer du code plausible, mais faibles pour savoir si ce code est correct. Ils écriront un point de terminaison qui semble correct, compile et renvoie discrètement le mauvais code d'état dans un cas limite. Dans une discussion, vous pourriez ne pas le remarquer avant que la production ne le fasse. Le modèle n'a aucune rétroaction lui indiquant que le cas limite a échoué, il signale donc avec confiance le succès. Cet écart entre « semble terminé » et « est terminé » est précisément là où les boucles trouvent leur utilité.

Une boucle comble cet écart en refusant d'accepter l'opinion du modèle sur son propre travail. L'agent n'a pas son mot à dire sur le fait que c'est terminé. C'est la porte qui le dit. Exécutez les tests ; s'ils sont rouges, la tâche n'est pas terminée, point final, et la sortie rouge est la prochaine chose que l'agent lira. La confiance du modèle n'a plus d'importance. Seul le signal compte.

Il y a aussi un aspect productivité. Le "prompting" manuel limite votre débit à un seul agent que vous surveillez activement. Les boucles vous permettent d'en exécuter plusieurs à la fois, chacun travaillant sur sa propre tâche contre sa propre porte, car aucun d'entre eux n'a besoin de vous dans le cycle interne. C'est le pas en avant que notre article sur les flux de travail d'agents dynamiques et parallèles aborde : une fois la boucle automatisée, vous passez à l'échelle en ajoutant des boucles, et non en tapant plus vite.

La partie que tout le monde sous-développe : la porte de vérification

Voici la vérité inconfortable. La plupart des flux de travail d'agents échouent non pas parce que le modèle était trop faible. Ils échouent parce que le signal de rétroaction était trop mou.

Pensez à ce que fait la porte. À chaque itération, elle dit à l'agent l'une des deux choses suivantes : vous avez réussi, arrêtez-vous ; ou vous avez échoué, voici exactement pourquoi. La qualité de « voici exactement pourquoi » détermine si l'itération suivante s'améliore ou s'égare. Donnez à l'agent une trace de pile précise pointant vers la ligne 42 et l'assertion qui a échoué, et il corrigera la bonne chose. Donnez-lui « quelque chose ne va pas, veuillez vérifier », et il devinera, rendant souvent le code pire tout en paraissant plus confiant.

Les portes déterministes convergent. Les portes floues dérivent. C'est tout l'enjeu.

Qu'est-ce qui fait une bonne porte ?

• Elle est binaire et reproductible. Même entrée, même verdict, à chaque fois. Pas de « cela dépend de l'humeur du modèle aujourd'hui ».
• Elle échoue bruyamment avec une raison. Un nom de test, une différence attendue/réelle, un numéro de ligne, un code d'erreur. La raison est la prochaine instruction, elle doit donc être spécifique.
• L'agent ne peut pas la modifier discrètement. Si l'agent peut modifier le test pour le faire passer, la porte est du théâtre. Protégez la porte. Traitez-la comme la spécification, et non comme du code appartenant à l'agent.
• Elle s'exécute suffisamment vite pour une boucle. Une porte qui prend 20 minutes limite votre vitesse d'itération. Les boucles serrées nécessitent des vérifications rapides.

De bonnes portes existent déjà dans chaque base de code mature. Tests unitaires. Vérificateurs de type. Linters. Compilateurs. Validateurs de schéma. Tests de contrat. Ce sont des oracles déterministes. Ils ont été conçus pour dire aux humains « c'est faux et voici pourquoi », ce qui est précisément le signal dont une boucle d'agent a besoin. Vous n'avez pas à inventer la porte. Vous devez orienter la boucle vers les portes auxquelles vous faites déjà confiance, et en écrire de nouvelles là où la couverture est faible. Si vous n'avez jamais formalisé cette couche, notre guide sur ce qu'est réellement le test automatisé est une bonne base avant de l'intégrer dans une boucle.

Pour le travail d'API et de backend, votre suite de tests est la boucle

C'est là que l'idée abstraite devient concrète pour quiconque construit des services. Lorsqu'un agent écrit un point de terminaison API, quelle est la vérité fondamentale qui dit qu'il fonctionne ? Pas le résumé du modèle. Le comportement réel du point de terminaison testé : les bons codes d'état, le corps de la réponse correspondant au schéma, l'authentification appliquée, les mauvaises entrées rejetées, le contrat respecté.

Chacun de ces éléments est vérifiable, automatiquement, avec un résultat déterministe. Ce qui signifie que votre suite de tests API est déjà structurée exactement comme la porte de vérification dont une boucle d'agent a besoin. Vous construisiez la porte depuis le début ; vous l'appeliez simplement test.

Une boucle concrète pour le travail sur les points de terminaison ressemble à ceci :

1. L'agent lit la spécification de la tâche et la définition OpenAPI, puis écrit ou modifie le point de terminaison.
2. Le harnais exécute la suite de tests API contre le service en cours d'exécution : assertions de statut, validation du schéma JSON sur chaque réponse, vérifications de contrat par rapport à la spécification.
3. Les échecs sont renvoyés de manière structurée. « Attendu 422 sur customer_id manquant, obtenu 500. » « Le champ de réponse total est une chaîne, le schéma indique un nombre. » « Le point de terminaison /orders/{id} dans la spécification n'a pas d'implémentation. »
4. Cet échec structuré devient l'instruction suivante de l'agent. Il corrige l'écart spécifique.
5. Répétez jusqu'à ce que la suite soit au vert, puis transmettez à un humain pour révision.

La clé est que la rétroaction à l'étape 3 est précise et générée par machine, et non une impression. C'est ce qui maintient la boucle convergente au lieu de la faire dériver. Les tests basés sur le schéma (schema-first) et les tests de contrat sont plus importants que jamais ici, car la spécification OpenAPI devient la source de vérité partagée que l'agent et la porte lisent. L'écart entre le code et la spécification cesse d'être un problème de documentation lent et devient une porte rouge instantanée.

C'est le rôle qu'Apidog joue dans un flux de travail agentique. C'est une plateforme API tout-en-un où la conception, le schéma, le serveur de maquette et les tests automatisés vivent au même endroit, ce qui signifie que la porte et la spécification restent synchronisées par défaut. Vous pointez la boucle vers un scénario de test Apidog, l'agent obtient un succès/échec validé par schéma à chaque itération, et le serveur de maquette remplace les dépendances qui ne sont pas encore construites afin que l'agent puisse travailler contre une cible stable. Les équipes qui utilisent déjà ce modèle câblent l'accès aux outils de l'agent via quelque chose comme le débogueur d'agent IA d'Apidog afin que l'agent puisse atteindre et inspecter les points de terminaison de la même manière qu'un testeur humain. Téléchargez Apidog si vous souhaitez construire la porte visuellement au lieu de créer un exécuteur de tests à la main.

Construire une boucle API auto-correctrice minimale dès aujourd'hui

Vous n'avez pas besoin d'un framework pour commencer. Vous avez besoin d'une spécification, d'une commande de test et de quelques lignes de code "glue". Voici la version la plus simple qui fait un travail réel.

Étape 1 : écrivez la spécification comme l'intention de la porte. Mettez le contrat dans un fichier OpenAPI et le comportement dans des cas de test. L'agent lit les deux. Cela sert aussi de documentation, donc ce n'est pas du travail jetable.

Étape 2 : choisissez une commande de test qui se termine avec un code de sortie non nul en cas d'échec. Tout fonctionne tant que le code de sortie est honnête. Une suite pytest, une exécution Newman, un scénario de test Apidog CLI. La boucle ne se soucie que du succès/échec plus la sortie capturée.

# la porte, comme une seule commande
apidog run ./tests/orders-suite --reporter json > result.json

Étape 3 : connectez la boucle. Exécutez l'agent, exécutez la porte, décidez en fonction du résultat.

MAX_ITERATIONS = 8
feedback = None
for attempt in range(MAX_ITERATIONS):
    run_agent(task="implement orders API per spec", feedback=feedback)
    gate = subprocess.run(["apidog", "run", "./tests/orders-suite",
                           "--reporter", "json"], capture_output=True)
    if gate.returncode == 0:
        print(f"green on attempt {attempt + 1}")
        break
    feedback = parse_failures(gate.stdout)   # la prochaine instruction s'écrit d'elle-même
else:
    print("8 tentatives, toujours rouge ; remontée à un humain")

Étape 4 : protégez la porte. Maintenez les fichiers de test et la spécification hors de l'ensemble des fichiers que l'agent est autorisé à modifier. S'il peut réécrire le test pour le faire passer, vous avez construit une machine à simuler le progrès.

Étape 5 : limitez les coûts. Limitez les itérations. Limitez les dépenses. Enregistrez chaque tentative pour voir si la boucle converge ou s'emballe. Si vous surveillez les dépenses en jetons, nos notes sur la réduction des coûts de jetons d'agent s'appliquent directement, car une boucle qui ne converge pas brûle rapidement le budget.

C'est une boucle auto-correctrice fonctionnelle. L'agent écrit, la suite juge, les échecs dirigent, et vous obtenez un point de terminaison au vert ou une remontée propre au lieu d'un mensonge confiant.

Concevoir de bonnes boucles : les erreurs qui coûtent cher

Quelques schémas séparent les boucles qui fonctionnent de celles qui gaspillent discrètement de l'argent.

• Laisser l'agent corriger son propre travail. Si la seule vérification est « agent, as-tu terminé ? », vous n'avez pas de boucle, vous avez un chatbot avec des étapes supplémentaires. La porte doit être externe à l'agent.
• Une porte trop grossière. « Les tests passent » avec trois tests superficiels signifie que l'agent satisfait trois tests et livre des bugs dans tout ce qui n'est pas couvert. La qualité de la boucle est limitée par la couverture de la porte. Tests minces, résultats minces.
• Pas de garde de terminaison. Les boucles sans nombre maximal d'itérations et sans plafond de coût peuvent tourner indéfiniment sur une tâche que le modèle ne peut pas résoudre. Définissez toujours une sortie, et remontez toujours à un humain lorsqu'elle est déclenchée.
• Des portes lentes. Une suite d'intégration de 15 minutes est une bonne vérification nocturne, et une terrible boucle interne. Conservez une porte rapide pour la boucle et une porte approfondie pour la fusion. Simulez les dépendances externes afin que la boucle n'attende pas un tiers instable.
• Spécifications mutables. Si l'agent modifie le fichier OpenAPI pour correspondre à son code buggé, le test de contrat passe au vert pour la mauvaise raison. La spécification est la constitution. L'agent travaille en dessous, pas dessus.
• Une tâche géante. Une boucle qui s'attaque à « construire tout le service » converge rarement. Décomposez en tâches de taille de point de terminaison, chacune avec sa propre porte. Les petites boucles se terminent ; les grandes s'emballent.

La plupart de ces points se résument à la même discipline : investissez dans le signal, pas dans l'instruction. Les schémas de câblage et les modes de défaillance ici correspondent à ce que nous avons couvert dans le câblage des outils de flux de travail agentique, et ils sont valables que votre agent soit Claude Code, Cursor, Codex, ou quelque chose que vous avez construit vous-même.

Où cela nous mène

L'expression « arrêtez les instructions, commencez les boucles » est un aperçu d'une tendance plus longue. La compétence qui devient précieuse n'est pas l'art de l'instruction. C'est l'art de la boucle : écrire des spécifications précises, construire des portes déterministes, choisir des conditions de terminaison et décider ce que l'agent est autorisé ou non à toucher. C'est plus proche de la conception de systèmes que de l'ingénierie d'instructions, et cela récompense les ingénieurs qui pensent déjà en termes de tests, de contrats et de CI.

Cela change également la valeur d'une bonne infrastructure de test. Pendant des années, les tests automatisés étaient une assurance dont vous espériez ne jamais avoir besoin. Dans un flux de travail agentique, ils deviennent le mécanisme de direction, ce qui transforme un générateur rapide mais peu fiable en un système qui converge vers la correction. Les équipes qui disposent déjà d'une forte couverture de tests automatisés et de contrats clairs sont celles qui intègrent les agents et obtiennent immédiatement un avantage. Les équipes sans cela obtiennent un moyen rapide de générer du code confiant mais non testé.

Ainsi, la démarche pratique n'est pas de courir après un meilleur modèle ou une instruction plus astucieuse. C'est de construire la porte. Resserrez vos spécifications. Rendez vos tests d'API déterministes et rapides. Gardez votre schéma comme source de vérité. Puis enveloppez-le d'une boucle et laissez l'agent faire des tours jusqu'à ce que la porte devienne verte.

À retenir

Le changement est simple à énoncer et difficile à intérioriser. Ne vous améliorez pas dans l'envoi d'instructions à votre agent de codage. Améliorez-vous dans la conception de la boucle qui l'invite, et dans le signal de rétroaction sur lequel cette boucle s'appuie. L'agent est un générateur rapide qui n'a aucune idée fiable de la justesse de son travail. La boucle, via une porte déterministe, lui fournit cette information. Pour quiconque construit des API, vous possédez déjà la porte. Votre suite de tests, votre schéma et vos contrats sont la vérité fondamentale qui transforme un générateur zélé en un système qui converge vers la correction.

Commencez petit. Rédigez une spécification précise, pointez une boucle vers une suite de tests API rapide, protégez la porte, limitez les itérations, et regardez un agent faire passer un point de terminaison du rouge au vert sans votre intervention dans la boucle interne. Puis construisez la boucle suivante. Si vous voulez que la porte soit visuelle, consciente du schéma et partageable au sein de votre équipe, Apidog vous offre la conception, la simulation et les tests automatisés dans un seul espace de travail ; téléchargez-le et faites de vos tests ce qui pilote vos agents.