Continuité d'intention : une nouvelle solution au problème de longue histoire des agents de codage
Les agents de codage dans les projets de longue durée oublient souvent les règles précoces, entraînant des problèmes comme la fuite d'ID de base de données internes. Les solutions classiques reposent sur des fenêtres de contexte plus grandes ou la recherche RAG, mais même si le modèle peut « se souvenir » de tout le texte, il ne peut pas juger automatiquement si une ancienne règle est pertinente pour la tâche en cours. Cet article introduit le concept de « continuité d'intention » et fournit une implémentation légère en Python pur : en ajoutant une couche de vérification à la recherche de base, la couverture des exigences passe de 57 % à 100 %, avec les 8 tâches de test correctes. La conception n'utilise aucune base de données vectorielle, aucun embedding et aucun appel LLM, ce qui la rend très facile à déployer. L'auteur reconnaît également honnêtement un bogue dans l'expérience originale, démontrant une rigueur d'ingénierie.
Contexte et problématique
Dans les projets de longue haleine pilotés par des agents de codage, un phénomène aussi frustrant que récurrent se manifeste : les règles fondamentales établies en début de projet semblent s'évanouir sans laisser de trace. Personne ne les a supprimées, le contexte n'est pas saturé, elles demeurent dans l'historique des échanges, mais lorsqu'une nouvelle requête survient, l'agent ne vérifie plus si ces décisions anciennes restent applicables. Prenons un cas concret : le premier jour, le développeur spécifie clairement « n'exposez jamais d'ID de base de données interne dans les réponses API ». Soixante tours de dialogue plus tard, lorsqu'on sollicite l'agent pour construire un nouveau flux d'authentification, ce dernier, n'étant pas explicitement rappelé à cette règle, produit un endpoint qui divulgue précisément ces identifiants. Ce scénario n'a rien d'une hypothèse théorique : il s'agit du cas de validation central utilisé par l'auteur pour ses expériences.
Les solutions techniques actuelles n'adressent pas le problème à sa racine. L'augmentation de la fenêtre contextuelle (GPT-4-32k, Claude 100k) permet certes d'ingurgiter davantage de texte, mais les travaux de Liu et al. (2023) ont démontré que les modèles ignorent systématiquement les informations situées au milieu de longs prompts. Le RAG (Retrieval-Augmented Generation) tente d'extraire les éléments pertinents de l'historique, mais sa logique de questionnement se limite à « quelles informations pourraient être liées à la requête courante ? », sans jamais s'interroger sur leur validité actuelle ni sur l'intention historique qui devrait guider la tâche présente. En définitive, l'agent peut se souvenir de toutes les règles, mais demeure incapable de discriminer celles qui restent opérantes. L'échec mémoriel n'est pas le problème — c'est la capacité à décider ce qui compte qui fait défaut.
Architecture et mécanisme
L'auteur désigne cette capacité sous le terme d'« Intent Continuity » (continuité d'intention) et la décompose en trois niveaux distincts. Le premier, Retrieval, répond à la question « quelles informations historiques pourraient être pertinentes ? ». Le second, Verification, ajoute une couche critique : « ces informations sont-elles toujours valides ? ». Le troisième, Intent Continuity, va plus loin en demandant « quelle intention historique doit influencer la tâche courante et demeurer active jusqu'à ce qu'une nouvelle règle la supplante ? ». Ces trois strates forment une pyramide dont la plupart des systèmes de mémoire pour agents n'exploitent que la base.
L'implémentation, réalisée en Python 3.12 pur, refuse délibérément toute infrastructure lourde : zéro base vectorielle, zéro modèle d'embedding, zéro appel LLM. Le cœur du système repose sur un pipeline léger d'enregistrement et de validation des exigences. Un registre central maintient la liste des contraintes actives. Lorsqu'une nouvelle tâche arrive, une recherche basique par mots-clés ou correspondance directe extrait un premier ensemble de candidats — avec un taux de couverture d'environ 57 %. C'est l'ajout d'une couche de validation indépendante qui fait la différence : elle examine chaque règle candidate dans le contexte courant, vérifie l'absence d'une règle plus récente qui la contredirait ou la remplacerait, et ne retient que les exigences réellement applicables. Cette simple étape porte la couverture de 57 % à 100 % sur les huit cas de test.
L'auteur fait preuve d'une rigueur scientifique remarquable en révélant un bug dans sa conception initiale : la première version couplait incorrectement la couche de validation avec la couche de recherche, ce qui conservait artificiellement des règles obsolètes et produisait des résultats trompeusement meilleurs. La correction a fourni des données plus fidèles, mais a paradoxalement confirmé le rôle central de la validation — sans elle, le système « sur-respecte » les règles en imposant des contraintes superflues qui nuisent à la pertinence réelle de l'agent.
Performances et impact pratique
L'évaluation comparative porte sur huit tâches représentatives. Le scénario de base — sans aucun historique, uniquement la requête courante — obtient zéro réponse correcte. L'ajout de la recherche basique en produit quatre. Le système complet avec recherche et validation atteint huit sur huit, soit 100 % de réussite. Tous les résultats proviennent d'exécutions réelles sous Python 3.12, sans dépendance externe, et le code est disponible sur GitHub (Emmimal/intent-continuity) via le script `run_experiment.py` pour reproductibilité intégrale.
La valeur pratique de cette approche réside dans son coût d'infrastructure quasi nul. Aucune base vectorielle à provisionner, aucun appel à des LLM coûteux pour calculer des embeddings, aucun service d'indexation à maintenir. Une simple bibliothèque Python légère suffit à garantir la continuité des règles pour les agents de codage engagés dans des projets de longue durée. Les bénéfices concrets concernent des scénarios comme les refontes s'étalant sur plusieurs semaines — où une règle de nommage établie en semaine 1 doit rester active en semaine 8 —, la traçabilité des contraintes historiques dans les grandes bases de code, ou encore les projets où plusieurs développeurs alternent les instructions à l'agent. Dans tous ces cas, le surcoût d'implémentation est négligeable, tandis que le gain en stabilité et en sécurité du comportement de l'agent est considérable.
L'auteur insiste sur un point technique crucial : la validation ne nécessite aucune sémantique profonde. Un simple mécanisme de résolution de conflits temporels — une règle plus récente prime sur une plus ancienne pour le même domaine — suffit à éliminer les faux positifs. Cette approche, bien que rudimentaire en apparence, s'avère plus fiable que des systèmes sophistiqués de similarité sémantique qui peinent à capturer la notion d'abrogation implicite d'une règle par une autre.
Perspectives et implications
Le débat actuel sur la mémoire des agents se polarise quasi exclusivement sur deux axes : comment stocker davantage d'historique et comment accélérer la recherche. Ce travail propose une bifurcation radicale : plutôt que d'accroître indéfiniment la capacité de mémorisation, il s'agit d'apprendre à l'agent à juger de la pertinence persistante de ce qu'il a retenu. La continuité d'intention introduit une forme de métacognition dans l'architecture des agents — non plus « tout retenir passivement », mais « décider activement de ce qu'il faut oublier ou conserver ». C'est un changement de paradigme qui replace la qualité de l'inférence au-dessus de la quantité d'information stockée.
Plusieurs pistes d'évolution se dessinent. L'intégration d'un graphe de dépendances explicite entre les règles permettrait une versioning formel : chaque règle hériterait d'une date d'activation, d'une portée, et d'une liste de règles qui la surchargent. Un tel système autoriserait l'expiration automatique des contraintes devenues obsolètes. On peut également envisager l'ajout d'un modèle de validation léger — un petit classifieur, par exemple — capable de détecter les conflits entre règles et de négocier une priorité sans intervention humaine. Rien n'empêche non plus de coupler ce mécanisme avec un LLM pour les cas ambigus, mais l'essentiel du travail resterait dans le domaine déterministe, garantissant prévisibilité et faible coût.
Pour les agents de codage appelés à opérer sur des cycles de maintenance longs, la continuité d'intention s'avère probablement plus utile que n'importe quel agrandissement de fenêtre contextuelle. Elle nous force à repenser une question fondamentale : un agent n'a pas besoin d'un historique plus long — il a besoin d'une capacité d'héritage intelligent des intentions. C'est cette thèse, solidement étayée par une implémentation minimaliste et des mesures reproductibles, qui fait de cette contribution un jalon important pour l'ingénierie des systèmes multi-agents durables.
Sources
FAQ
Quel est le problème fondamental rencontré par les agents de codage dans les projets de longue durée ?
Ils oublient fréquemment les règles précoces établies, entraînant des fuites d'ID de base de données et nuisant à la cohérence et à la sécurité du projet.
Pourquoi les solutions traditionnelles (grand contexte, RAG) ne résolvent-elles pas complètement ce problème d'oubli ?
Même si le modèle se souvient de tout le texte, il ne peut pas décider automatiquement si une règle ancienne est pertinente pour la tâche actuelle ; les approches traditionnelles n'étendent que la mémoire, sans validation active ni jugement de priorité.
Quelle est l'idée centrale de l'approche 'Continuité d'intention' et ses caractéristiques de mise en œuvre ?
Elle utilise une recherche de base plus une couche de validation, sans base de données vectorielle, sans embedding, sans appel LLM, augmentant la couverture des exigences de 57 % à 100 %, réussissant les 8 tâches de test, tout en divulguant honnêtement les bugs des expériences originales.