Les agents IA n'ont besoin que de documentation structurée, pas de systèmes de mémoire
En bref
- Un article défend l'idée que les agents IA gèrent mieux les tâches avec une documentation bien organisée plutôt que des systèmes de mémoire dédiés.
- Les systèmes de mémoire existants accumulent trop d'informations, deviennent obsolètes rapidement et consomment inutilement des tokens.
- Le débat HN conteste le manque de test concret et soulève des problèmes pratiques : comment les agents trouvent les documents pertinents, gestion du cycle de vie des infos, cohérence dans les environnements multi-agents.
Ce que dit la source
L'article propose que les agents IA abandonnent les systèmes de mémoire (memory plugins) au profit d'une documentation structurée et versionnée, directement intégrée au codebase. L'auteur affirme que les memory systems prolifèrent inutilement, deviennent rapidement obsolètes, créent de la confusion par manque de synchronisation, et gaspillent des tokens en retraçant constamment le passé plutôt que de consulter des notes bien organisées.
- Les systèmes de mémoire actuels surchargent le contexte en accumulant trop de micro-notes sans discerner ce qui reste pertinent
- Documentation versionnée avec catalogs / index : chaque document porte une brève description et des conditions de lecture (« read_if ») pour que l'agent saisisse la pertinence sans charger tous les fichiers
- Staleness : les documents comme les memory snippets se déprécient, mais une approche documentation permet d'archiver explicitement plutôt que d'accumuler des traces obsolètes
- Approches parallèles dans les commentaires : ADRs (Architectural Decision Records), principes versionnés cités dans le code, dossiers structurés (plans, notes, knowledge) avec droits de modification graduels
- Problème non résolu par la proposition : comment l'agent identifie les documents pertinents avant même de lancer une recherche, surtout dans un environnement avec des centaines de fichiers ?
Dans les commentaires
Débat partagé : la thèse est séduisante mais peu convaincante sans mesures. Des commentateurs valident l'approche générale (documentation > memory plugins), d'autres relèvent que la proposition réplique simplement les mêmes problèmes (staleness, découverte) sous un autre nom. Critique principale : l'article manque de tests, de comparaisons empiriques et ne traite pas les cas réels (multi-agents, lifecycle temporel, préférences vs faits).
- Plusieurs commentaires contestent que la solution évite réellement les problèmes qu'elle reproche aux memory systems : trouver un document pertinent sans embeddings reste un problème non résolu, et la documentation devient aussi obsolète que les memory snippets.
- Un commentateur souligne que la proposition assume implicitement un unique agent CLI sur machine locale, alors que les déploiements réels incluent chatbots, agents event-driven sur serveurs et multi-tenants où accéder à un filesystem partagé crée des risques de corruption.
- Le manque de temporalité est signalé : aucune notion de durée de pertinence (ex : garder une note pendant une migration, la supprimer après) ni de séparation nette entre préférences (style de sortie) et mémoire factuelle dans un contexte multi-utilisateurs.
- L'article esquive la question du coût en tokens : consulter et mettre à jour constamment de la documentation dans chaque session accumule aussi des frais, sans gain démontré par rapport aux memory plugins.
- Un commentateur qualifie le texte de « marketing post mediocre » : beaucoup de répétitions sur ce que l'approche ne fait pas, aucun test empirique ni démonstration du gain réel.
Alternatives citées : Encephalon (append-only log + queries ms) ; mattpocock/skills (génération d'ADRs) ; habit-hooks (linting avec explications) ; principledriven.dev (versioning de principes en commentaires de code).
Notre lecture
La critique du statut quo (memory plugins = accumulation inefficace) tient debout et résonne avec l'expérience de nombreux développeurs. Mais passer de « memory plugins sont mauvais » à « documentation structurée est la solution » n'emporte pas la conviction sans données. Les commentaires valides montrent que le problème réel dépasse la dichotomie memoire/docs : c'est la découverte, la temporalité, l'arbitrage token et la cohérence multi-agents. À surveiller plutôt qu'à déployer. Les approches des commentateurs (ADRs versionnés, catalogs auto-documentés, séparation notes/knowledge) offrent plus de substance, mais restent empiriques. Pas de recommandation immédiate, sauf explorer comment structurer la documentation pour que les agents la trouvent naturellement.