Le codage autonome passe de meilleurs prompts à de meilleurs systèmes de contrôle. Le changement important est que les ingénieurs apprennent à encapsuler les agents dans des objectifs, des évaluateurs, des boucles et des artefacts qui leur permettent de continuer à travailler après que l’humain a cessé de taper.
C’est important car la plupart des travaux d’ingénierie sérieux s’étendent sur de longs horizons : des exigences ambiguës, des contraintes cachées, des échecs partiels, un contexte changeant et une vérification répétée. La nouvelle frontière consiste à concevoir le système autour de l’agent afin qu’il puisse planifier, exécuter, vérifier son travail, se remettre de ses erreurs et continuer à progresser sans intervention humaine constante.
Cet article est basé sur une session de la DAIR.AI Academy sur les agents de codage autonomes de longue durée, où j’ai présenté le mode /goal de Claude Code, la nouvelle commande /loop, les vérificateurs, les artefacts et les modèles d’orchestration en pratique. Rédigé en collaboration avec Codex et Claude Code.
Des prompts à la conception d’objectifs
L’idée centrale derrière des fonctionnalités comme /goal de Claude Code est simple. Un agent de codage reste l’exécuteur, mais l’humain n’interagit plus avec lui tour à tour. Au lieu de cela, l’humain spécifie l’état final souhaité, les preuves requises pour prouver le succès, les contraintes qui ne doivent pas être violées et, dans la mesure du possible, le nombre de tours et le budget.
Cet objectif fonctionne davantage comme un contrat que comme un prompt plus long. Un objectif faible donne au modèle la possibilité de s’arrêter tôt, de prendre des raccourcis ou de redéfinir le succès d’une manière qui semble plausible dans la transcription mais échoue dans le système réel. Un objectif fort donne à l’agent une cible contre laquelle il peut se mesurer à plusieurs reprises.
Le jugement d’ingénierie compte toujours ici. Les meilleurs objectifs encodent des connaissances du domaine que le modèle devinerait autrement. Pour une expérience de recherche, cela peut signifier un score de référence cible, une évaluation sur un jeu de données de validation, une courbe de perte requise et une règle selon laquelle le résultat doit battre une baseline initiale. Pour une tâche d’interface utilisateur, cela peut signifier une capture d’écran de référence, des contraintes de mise en page concrètes et une étape de vérification dans le navigateur. Le modèle peut exécuter, mais l’humain définit toujours ce que « terminé » signifie réellement.
L’évaluateur devient un composant de première classe
Les agents de longue durée ont besoin d’un second rôle en plus de l’objectif. Cet évaluateur peut être un autre agent de codage, un LLM-juge, un script, une suite de tests, un banc d’essai de référence, ou un mélange de tous. Le choix de conception clé est d’adapter l’évaluateur à la tâche. Quand le succès est net, les vérifications déterministes sont meilleures. Les vérifications de type, les tests unitaires, les règles de lint, les tests d’intégration et les scripts de référence doivent être utilisés chaque fois qu’ils peuvent exprimer clairement la condition.
Quand le succès est flou, un évaluateur agent devient utile. Un script peut vous dire si les tests passent, mais il ne peut pas facilement décider si un rapport de recherche généré est cohérent, si une implémentation suit fidèlement un article, ou si une interface utilisateur correspond à une intention de conception. C’est là que l’évaluateur bénéficie du langage, du jugement et parfois de la vision.
Le modèle pratique utilise les vérifications déterministes comme base et l’évaluation par agent comme révision de niveau supérieur. Cette combinaison réduit les réussites hallucinées tout en permettant l’autonomie sur des tâches qui ne cadrent pas parfaitement avec une assertion de test.
Les vérificateurs définissent la limite de confiance
Le point plus profond est que l’autonomie ne fonctionne que lorsque le système dispose d’un vérificateur fiable. Un agent de codage peut générer un plan, implémenter une fonctionnalité et expliquer pourquoi il croit que le travail est terminé, mais cette explication ne doit pas être considérée comme une preuve. La preuve vient d’un contrôle externe que l’agent ne peut pas facilement contourner par la parole.
Pour le code, le vérificateur peut être une suite de tests, un vérificateur de type, un benchmark, une exécution dans le navigateur, une comparaison de captures d’écran ou un script reproductible. Pour le travail de recherche, il peut s’agir d’une évaluation sur un jeu de validation, d’un tableau reproduit, d’une courbe de perte ou d’un score de référence qui s’améliore par rapport à la baseline. Pour le travail de conception, il peut s’agir d’une capture d’écran de référence associée à une étape de révision visuelle. Le vérificateur est ce qui transforme un agent de longue durée d’un générateur de texte confiant en un système auquel on peut confier plus de temps.
La plupart des raccourcis apparaissent à cette limite. Si le vérificateur est vague, le modèle satisfera souvent l’interprétation la plus facile de la tâche. Si le vérificateur est trop étroit, le modèle peut surapprendre et manquer l’intention plus large. Un bon workflow autonome nécessite donc une vérification en couches, avec des vérifications déterministes peu coûteuses pour détecter les échecs de base et une révision de plus haut niveau pour les échecs lourds de jugement. Quelques-uns des modèles de pointe peuvent déjà atteindre un certain niveau de vérification, mais d’après mes recherches, il existe encore un problème évident de distribution hors échantillon (OOD) : si la tâche de vérification que vous assignez à l’agent se trouve en dehors de la distribution d’entraînement, les modèles rencontrent des difficultés significatives.
Les vérificateurs sont encore un domaine de recherche ouvert, mais je prévois que de plus en plus d’entreprises commenceront à investir massivement dans ce domaine. Le concept de vérificateurs ajustés (fine-tuned) est également très demandé dans le monde de l’entreprise.
Les boucles rendent l’autonomie durable
Un objectif donne une direction à l’agent, mais une boucle maintient le travail en vie. Cette distinction est importante car les modèles s’arrêtent souvent avant que la tâche réelle ne soit terminée. Ils peuvent atteindre une limite de tours, perdre confiance, épuiser le contexte ou décider qu’une solution partielle est suffisante.
La boucle est le système de contrôle externe. Elle se réveille, inspecte la progression, exécute des vérifications, compare le résultat à l’objectif et renvoie l’agent avec l’instruction suivante lorsque l’objectif n’est pas atteint. Dans sa forme la plus simple, il s’agit du modèle de boucle Ralph avec un agent de codage et une condition déterministe. Dans une forme plus flexible, la boucle inclut un agent évaluateur capable de raisonner sur la progression et de décider de la suite.
L’autonomie de longue durée fonctionne comme un effort répété sous la supervision d’une couche de contrôle, et non comme un acte continu d’intelligence. L’agent peut encore échouer, mais la boucle donne au système un moyen de remarquer l’échec et de continuer, au lieu de déclarer silencieusement la victoire.
La planification est là où l’expertise entre en jeu
L’un des thèmes les plus forts de la session était que la planification reste cruciale. Vous pouvez demander à un modèle de pointe de générer un plan, mais vous devez encore l’inspecter, remettre en question les hypothèses et affiner les critères de succès avant de confier la tâche à une boucle autonome.
Cela conduit à une division du travail utile. Un modèle de planification plus fort peut aider à définir l’objectif, identifier les contraintes manquantes et structurer l’évaluation. Un modèle d’exécution différent peut ensuite réaliser l’implémentation une fois le plan clair. En pratique, cela signifie que les ingénieurs devraient cesser de considérer « le modèle » comme un choix unique. Le choix du modèle devient une décision d’architecture.
Certains modèles sont de meilleurs planificateurs. D’autres sont de meilleurs exécuteurs. Certains sont des évaluateurs moins chers. D’autres sont meilleurs pour la révision basée sur la vision. Un bon orchestrateur vous permet d’échanger ces rôles plutôt que d’attendre qu’un seul fournisseur propose l’interface d’agent de codage parfaite.
Les artefacts visuels deviennent des surfaces de contrôle
Les transcriptions de terminal ne passent pas à l’échelle lorsque de nombreux agents sont en cours d’exécution. Une fois que vous avez plusieurs sessions travaillant en parallèle, le texte brut devient une mauvaise interface pour comprendre la progression.
Les artefacts en direct sont importants car un tableau de bord avec des courbes de perte, des scores de référence, des états de tâches, des captures d’écran, des estimations de coûts et des décisions récentes donne à l’humain un bien meilleur moyen de superviser l’autonomie. L’artefact devient la surface de contrôle pour décider quand intervenir, plutôt qu’un rapport généré après coup.
Le modèle le plus utile est de séparer le stockage de la présentation. Le Markdown ou un coffre peut stocker des preuves durables, des logs, des notes, des plans et des résultats. Les artefacts HTML peuvent rendre cet état visuel et interactif. L’agent peut rechercher dans le Markdown, tandis que l’humain peut surveiller l’artefact.
Pour le travail d’interface utilisateur et de produit, les indices visuels sont particulièrement puissants. Une capture d’écran de référence peut communiquer l’intention de conception plus précisément que de la prose, et un évaluateur capable de vision peut comparer l’implémentation à cette référence. Cela réduit le mode d’échec courant où l’agent implémente techniquement le composant demandé mais manque l’espacement, la hiérarchie, l’alignement ou le ressenti du produit.
L’exploration des sessions transforme l’utilisation en mémoire
Une autre information importante est que les sessions d’agents passées sont une source riche de données de workflow. Si un agent échoue répétitivement de la même manière, oublie d’exécuter la même vérification, utilise le mauvais chemin ou réessaie la même commande cassée, ce motif ne doit pas rester enterré dans les logs.
L’exploration des sessions transforme ces transcriptions en règles d’exploitation. Un agent peut analyser les trente derniers jours de travail, trouver les modes d’échec récurrents et proposer des mises à jour des instructions du projet, des apprentissages du coffre ou des règles de l’agent. C’est ainsi qu’une équipe peut améliorer progressivement son harnais sans se souvenir manuellement de chaque erreur.
L’objectif est de rendre l’environnement local plus intelligent sans entraîner un modèle à partir de zéro. Une petite règle dans un fichier d’instructions d’agent peut empêcher des échecs répétés lors de sessions futures, surtout lorsque la règle est spécifique au projet.
Un modèle opérationnel pratique
Pour les ingénieurs en IA, le workflow émergent ressemble à ceci.
- Commencez par un sous-ensemble petit et peu coûteux avant de lancer l’exécution autonome complète.
- Rédigez un objectif avec des critères de succès mesurables, des contraintes explicites et, si possible, un budget de tours ou de temps.
- Séparez l’exécuteur de l’évaluateur afin que l’implémentation et le jugement ne soient pas confondus en un seul rôle.
- Définissez des vérificateurs externes avant que la boucle de longue durée ne commence.
- Utilisez des vérifications déterministes autant que possible, puis ajoutez une révision par agent pour les critères flous.
- Exigez des artefacts de preuve comme les logs, les captures d’écran, les courbes de référence ou les fichiers modifiés.
- Exploitez les sessions passées et transformez les leçons répétées en instructions de projet.
C’est la différence entre utiliser un agent de codage et concevoir un système de codage autonome. L’un vous offre une conversation. L’autre vous offre un harnais.
Ce qui casse encore
Rien de tout cela ne supprime les problèmes difficiles. Les agents prennent encore des raccourcis. Ils s’arrêtent encore tôt. Ils surestiment encore l’achèvement. Ils produisent encore des plans confiants mais faibles, en particulier sur des articles récents, des benchmarks inconnus ou des systèmes en dehors de leur distribution d’entraînement.
Leur faire davantage confiance ne résoudra pas cela. De meilleurs systèmes de contrôle le feront. Les objectifs, les boucles, les évaluateurs, les vérifications déterministes, les artefacts visuels et la mémoire des sessions sont tous des moyens de rendre l’autonomie observable et corrigeable.
La direction est claire. L’avenir des agents de codage dépend d’une meilleure orchestration autour de modèles plus capables, où les ingénieurs conçoivent les conditions dans lesquelles les agents peuvent fonctionner en toute sécurité pendant des heures ou des jours et produire encore un travail vérifiable.
