Boucles : la primitive agentique sur laquelle tout a convergé

Tous les chemins mènent à /goal

En l’espace de quelques mois, chaque outil de codage agentique majeur a convergé indépendamment vers le même primitif exact : une boucle autonome qui prend un objectif et s’exécute jusqu’à ce qu’elle décide qu’elle a terminé.

• Claude Code a livré /goal.
• OpenAI Codex a livré /goal.
• Antigravity a construit tout son modèle autour des boucles.
• GitHub Copilot a livré les Routines et les Automations.

Quatre équipes, quatre bases de code, quatre ensembles d’incitations. Un seul primitif. Quand Boris Cherny, le créateur de Claude Code, décrit sa façon de travailler aujourd’hui, la phrase est révélatrice :

“Il a arrêté d’écrire du code. Il écrit des boucles.”

Ce n’est pas une coïncidence. Lorsque des équipes indépendantes, sous pression concurrentielle, aboutissent à la même abstraction, c’est la preuve d’un véritable primitif, de la même manière que map et reduce étaient de véritables primitifs. La question intéressante n’est pas pourquoi la convergence s’est produite. C’est ce que vous en faites. Car si tout le monde a la boucle, la boucle elle-même ne vaut rien. L’épisode 1 de Agents, Orchestrated porte sur le déplacement de la valeur réelle.

Ce qu’est réellement une boucle

“Exécuter jusqu’à la fin” n’est pas une boucle. C’est un espoir avec un délai d’expiration. Une boucle bien formée a trois parties, et j’ai constaté que les nommer explicitement est le moyen le plus rapide de repérer une boucle mal conçue.

Résultat. À quoi ressemble le succès. C’est l’état objectif que l’agent essaie d’atteindre, et le mot clé est état. Pas une tâche (“refactoriser le module d’authentification”) mais un endpoint vérifiable (“tous les tests d’authentification passent et le module exporte la même interface publique”). Si vous ne pouvez pas énoncer le résultat comme quelque chose de vérifiable, vous n’avez pas encore de boucle. Vous avez une impression.

Preuve. Comment vous savez que c’est terminé. C’est l’étape de vérification : les tests passent, la sortie correspond à la spécification, le diff est correct. C’est là que la plupart des boucles échouent, et elles échouent silencieusement. Un agent qui déclare victoire de son propre chef déclarera victoire que le travail soit correct ou non. La preuve doit être quelque chose que l’agent ne peut pas générer en souhaitant que ce soit vrai.

Garde-fou. Ce qui empêche l’emballement. La condition de sortie, le budget, ou la porte humaine qui empêche la boucle de tourner indéfiniment. Sans cela, une boucle qui ne peut pas atteindre son résultat ne s’arrête pas. Elle brûle des tokens, modifie l’état et réessaie jusqu’à ce que quelque chose d’extérieur intervienne. Le garde-fou est ce qui rend le mode de défaillance ennuyeux au lieu d’être coûteux.

Résultat, preuve, garde-fou. Chaque boucle que j’ai vue en production a les trois. Chaque boucle que j’ai vue échouer manquait d’au moins un, généralement la preuve.

Quatre types de boucles

Toutes les boucles ne sont pas égales, et un framework a rendu tout cet espace lisible pour moi. Deux axes le définissent : où la boucle s’exécute (dans votre session ou dans le cloud) et ce qui conditionne sa sortie (un déclencheur ou une vérification).

Cela donne quatre quadrants :

	Conditionné par un déclencheur	Conditionné par une vérification
En session	Exécution ad-hoc	Exécution orientée objectif
Cloud	Tâche planifiée	Agent autonome

Exécution ad-hoc (en session, conditionnée par un déclencheur). L’utilisateur la démarre, l’agent s’exécute jusqu’à un délai d’expiration ou un budget, et elle s’arrête quand vous l’arrêtez. C’est la majeure partie de l’utilisation des agents aujourd’hui. C’est utile, mais l’humain est la couche de vérification, ce qui signifie que cela ne passe pas l’échelle de l’attention humaine.

Exécution orientée objectif (en session, conditionnée par une vérification). L’agent s’exécute jusqu’à la preuve d’achèvement. C’est /goal. L’agent propose qu’il a terminé, l’étape de vérification contrôle, et la boucle ne se termine que sur preuve. C’est la boucle que vous pouvez auditer, car la condition de sortie est inspectable après coup.

Tâche planifiée (cloud, conditionnée par un déclencheur). Cron la déclenche, l’agent s’exécute pendant un temps fixe, et il n’y a aucune boucle de vérification du tout. C’est là que réside discrètement une grande partie du marketing des “agents autonomes” : une tâche cron portant un trench-coat.

Agent autonome (cloud, conditionné par une vérification). Hébergé dans le cloud, orienté objectif, de longue durée. C’est là que se dirige le travail agentique, et je dirais que cela ne fonctionne que si la couche de vérification est solide. Tout le reste dans ce quadrant est une tâche planifiée qui a occasionnellement de la chance.

Le framework justifie son existence car il sépare deux choses que les gens confondent : où l’agent s’exécute et pourquoi il s’arrête. Les questions d’autonomie sont presque toujours des questions “pourquoi s’arrête-t-il” déguisées.

Le fossé est la vérification, pas l’autonomie

La convergence est excitante, et je comprends pourquoi les démos se concentrent sur l’autonomie. Mais l’autonomie seule n’est pas un fossé. Chaque laboratoire l’a maintenant. Quatre outils livrant le même primitif au cours du même trimestre est la preuve que le primitif est une commodité.

Le fossé est ce qui se passe à l’intérieur de la boucle quand elle pense avoir terminé. Une couche de vérification qui détecte les mauvaises sorties, annule les erreurs et produit une piste d’audit est la différence entre une démo et un produit. Je travaille avec des institutions financières, et la première question n’est jamais “à quel point est-il autonome”. C’est “montrez-moi pourquoi il a fait cela”, et la boucle qui ne peut pas répondre n’est pas une capacité, c’est une responsabilité.

C’est la thèse de tout l’épisode, et honnêtement de toute la série : la boucle que vous pouvez auditer est la seule qui est livrée.

Ce qui n’a pas été inclus dans le post LinkedIn

L’épisode lui-même a été construit avec le primitif qu’il décrit, et cette partie mérite la version honnête.

L’EP 01 a été livré sous forme de motion graphic d’environ 58 secondes, au format 4:5, avec une voix off de présentateur, construit avec ma compétence explainer-video-studio et le primitif /goal de Claude Code s’exécutant contre une spécification écrite. Ce qui signifie que les trois parties de la boucle étaient à ma charge de conception : le résultat était la spécification, la preuve était une passe de vérification image par image qui vérifiait que les images rendues montraient réellement les légendes verrouillées, et le garde-fou, c’était moi, observant l’exécution.

Deux remarques honnêtes. Premièrement, l’étape de preuve est la raison principale pour laquelle la vidéo a été livrée. La boucle naïve produit joyeusement un mp4 qui existe et est faux ; seule la vérification image par image par rapport à la spécification a détecté les décalages de légendes et de synchronisation. Deuxièmement, il s’agissait d’une exécution en session, orientée objectif, et non du quadrant cloud autonome vers lequel le framework pointe. J’étais la porte humaine. Je ne vais pas décrire une exécution supervisée comme de l’autonomie, car l’écart entre ces deux quadrants est exactement la couche de vérification dont parle cet épisode.

La spécification, la configuration de la boucle et la sortie sont toutes dans le dépôt, vous pouvez donc vérifier les affirmations par rapport à l’artefact.

Journal de livraison

• Format : motion graphic d’environ 58s, 4:5, voix off de présentateur
• Construit avec : Claude Code /goal contre une spécification écrite
• Pipeline : compétence explainer-video-studio
• Rendu : Remotion
• Vérification : contrôles image par image de la sortie rendue par rapport à la spécification verrouillée
• Dépôt : letmereviewyourcode/what-are-loops