Les boucles agentiques ne réparent pas les agents menteurs

Publié le 15 juin 2026 par gyorgy

Le discours actuel dit que vous devriez arrêter de demander des agents de codage et commencer à concevoir des boucles autour d'eux. Donnez à l'agent un déclencheur et un objectif vérifiable, laissez un évaluateur vérifier le résultat et ne vous arrêtez que lorsqu'il réussit. Un fournisseur majeur a expédié un/butcommande pour cela. Les gens organisent des sessions sans surveillance de 25 heures et appellent cela de l'ingénierie en boucle.

L'instinct est correct. N'acceptez jamais la parole de l'agent selon laquelle quelque chose est fait. Exigez des preuves.

Mais « vérifiable » fait tout le travail dans cette phrase. Je crée un framework qui génère une infrastructure cloud sur GCP, AWS et Azure, et j'y utilise quotidiennement des agents de codage. Je conserve un document d'audit de chaque défaillance grave. Le lire à travers le prisme de l’ingénierie des boucles est inconfortable, car chaque bug qu’il contient aurait survécu à une boucle. Pas parce que la boucle a été répétée trop peu de fois. Parce que le vérificateur n’a pas pu voir le mensonge.

En voici trois.

Le travail d'initialisation qui n'a jamais existé

Lors de la mise en œuvre d'AWS, l'agent a généré le Terraform pour la couche de base de données. L'équivalent GCP crée des bases de données et des utilisateurs par service via des ressources Terraform natives. AWS ne dispose pas de telles ressources, donc quelque chose d'autre doit les créer.

L'agent a résolu ce problème avec un commentaire :