La qualité d’un agent de programmation diminue souvent non pas parce que le modèle est devenu moins capable, mais parce que le projet ne dispose pas d’un système d’exploitation clair qui encadre ce que l’agent lit, ce qu’il fait et la manière dont ses modifications sont révisées. Lorsque le travail s’étend sur des semaines et implique des milliers de modifications, l’agent peut redécouvrir les mêmes fichiers, contredire une décision antérieure, deviner la commande de test ou cesser d’écrire des tests si ces étapes ne lui sont pas imposées.
Dans la sixième partie de la série « Running LLMs in Production », le Stack Overflow Blog propose de construire une couche organisationnelle autour du modèle, comprenant une constitution concise du projet, des limites d’autonomie, un contexte à plusieurs niveaux, une mémoire persistante, un comité de révision et un hook exécuté après chaque modification. Lorsque plusieurs agents travaillent sur le même dépôt, il faut également ajouter une carte de propriété des fichiers ainsi que des journaux de requêtes et de décisions partagés.
Le problème réside dans le dispositif opérationnel, pas uniquement dans le modèle
L’article définit l’agent comme le modèle auquel s’ajoutent les instructions, les outils, les politiques de contexte, les hooks, l’isolation, les sous-agents et les mécanismes de surveillance. Il cite un résultat général du benchmark Terminal-Bench 2.0, dans lequel LangChain a fait passer un agent de l’extérieur du top 30 au top 5 en modifiant uniquement le dispositif opérationnel : le score est ainsi passé de 52,8 % à 66,5 %, soit une hausse de 13,7 points, tout en conservant le même modèle.
La leçon pratique est que des outils incomplets, des règles ambiguës ou un contexte encombré peuvent constituer la cause d’échec la plus facile à corriger. Contrairement au modèle, cette couche peut être modifiée par l’équipe de développement et adaptée à son dépôt.
Six éléments pour un agent unique et discipliné
- Constitution du projet : un fichier tel que CLAUDE.md ou AGENTS.md définit le cycle de travail : planification, documentation, implémentation, tests, révision, puis validation. Il devrait inclure les critères de qualité et les limites d’utilisation des paquets des fournisseurs, tout en restant court puisqu’il est lu à chaque session.
- Limites d’autonomie : l’agent est autorisé à effectuer des opérations réversibles, comme la lecture, l’édition, les tests et la création de validations, tandis que les opérations de poussée, de déploiement et d’application de modifications de l’infrastructure nécessitent une approbation. Il faut vérifier la sémantique de la correspondance des commandes afin que des règles larges, comme npm:*, n’autorisent pas accidentellement un déploiement.
- Contexte à plusieurs niveaux : le CONTEXT.md racine contient la carte du projet ainsi que les procédures de lancement et de test, tandis que le fichier de chaque module explique sa responsabilité, ses fichiers et ses dépendances. Le DECISIONS.md consigne les décisions, leurs raisons et les alternatives rejetées. Un contexte obsolète constitue une erreur qui doit être corrigée dans la modification elle-même.
- Mémoire persistante : l’article propose des fichiers mémoire distincts pour chaque fait, un index concis et un fichier graph.jsonl reliant les modules et les décisions au moyen de relations telles que « dépend de » ou « remplace ».
- Comité de révision sous plusieurs angles : des sous-agents examinent la modification du point de vue du produit, de l’ingénierie, de l’infrastructure, de la sécurité et des tests. Seul un blocage ou un problème grave assorti d’un niveau de confiance élevé doit empêcher la modification.
- Hook après modification : PostToolUse s’exécute après chaque Edit, Write ou MultiEdit et produit une liste de rappel demandant de mettre à jour le contexte, la mémoire et le journal des décisions dans le cadre de la modification elle-même, plutôt que de réécrire silencieusement les fichiers.
Lorsqu’une flotte d’agents est exécutée
Un nouveau problème apparaît lorsque plusieurs agents travaillent sur le même dépôt : ils peuvent modifier les mêmes fichiers ou annuler les décisions des autres. L’article ne recommande pas de s’appuyer sur des conversations directes entre eux, mais sur un état partagé, écrit et vérifiable, comprenant une carte de propriété des chemins, des journaux CLAIM et RELEASE, un journal de progression et une branche indépendante pour chaque tâche, avec fusion humaine.
Ces revendications ne constituent pas un véritable verrouillage : deux agents peuvent lire le même état et revendiquer le même chemin au même moment. Lorsqu’un isolement réel est nécessaire, l’article recommande un mécanisme atomique, tel qu’une branche Git au nom unique ou une écriture conditionnelle dans un magasin de coordination.
Pourquoi cette approche est-elle importante ?
Le véritable changement consiste ici à déplacer l’attention de la capacité de l’agent à écrire une fonction vers la capacité du système qui l’entoure à le maintenir orienté et révisable au fil du temps. Le journal des décisions joue un rôle contractuel, et pas seulement documentaire : les anciennes décisions ne sont pas modifiées ; de nouvelles décisions les remplaçant sont ajoutées, avec l’explication de la raison et des alternatives rejetées. Ainsi, l’historique de conception reste visible et peut être relié à des contrôles automatisés, comme l’interdiction de certains imports.
Cette approche reste une recommandation organisationnelle et ne garantit pas l’exactitude des résultats. L’article reconnaît également que les revendications fondées sur des fichiers sont consultatives lorsque les collisions sont simultanées, et que la révision humaine demeure le point de contrôle lors de la fusion, de la poussée et du déploiement. La conclusion de l’article est que le confinement du modèle et la construction de traces vérifiables peuvent avoir davantage d’effet sur la fiabilité du travail de longue durée que l’attente d’un modèle plus intelligent.