Habr AI : au lieu de pipelines d'agents complexes, les développeurs devraient adopter Markdown, Git et la mémoire de session

Habr a publié un article avec une idée simple mais tranchante : la plupart des équipes compliquent trop le travail avec les agents IA en construisant des pipelines lourds avec LangChain, RAG et base de données vectorielle où, pour le développement réel, se souvenir des décisions passées importe plus que l'orchestration.

L'auteur compare le boom actuel des piles d'agents à l'ère LAMP du milieu des années 2000 : l'industrie s'est une fois de plus éprise de l'infrastructure et se demande rarement comment cette infrastructure aide réellement à résoudre des problèmes concrets du produit.

L'article examine une approche typique des entreprises : un orchestrateur distribue les tâches à plusieurs agents, qui récupèrent le contexte de RAG, invoquent des outils, écrivent du code et ouvrent des pull requests.

De l'avis de l'auteur, un tel schéma fonctionne raisonnablement bien pour automatiser des tâches routinières comme la révision de code, les tests et le linting, mais échoue à maintenir un horizon de travail à long terme.

Le problème ne réside pas tant dans le modèle lui-même que dans le fonctionnement de la mémoire : chaque nouveau ticket pour un agent commence souvent presque de zéro, sans un historique stable de décisions, de compréhension du domaine ou de contraintes accumulées du projet.

Ainsi, la recherche sémantique sur le code semble utile, mais elle ne remplace pas la vraie connaissance de la raison pour laquelle l'équipe a choisi ce chemin particulier en premier lieu.

En alternative, l'auteur propose un système presque ascétique basé sur des fichiers markdown et git.

Au lieu d'un pipeline universel, l'auteur crée une mémoire de travail à partir de sessions, de rôles, de compétences, de contextes et de règles.

Une session stocke des niveaux brefs, moyens et profonds de contexte, pour que le travail ultérieur continue non pas à partir d'un chat vide, mais à partir de décisions documentées.

Un rôle décrit non pas un programmeur abstrait, mais une spécialisation concrète avec connaissance du domaine : quelles API utiliser, quelles erreurs sont typiques, quelles contraintes existent dans le matériel, le protocole ou le projet.

Cela, soutient l'auteur, réduit les hallucinations du modèle mieux que toute autre couche d'enrobage autour des appels LLM.

Un accent particulier est mis sur les règles nées des erreurs.

Si un agent a une fois supprimé un fichier sans confirmation, s'est enlisé dans un débogage infini ou a perdu des modifications non validées lors d'un changement de branche, cela devient non pas un nouveau service middleware, mais une règle explicite pour les sessions ultérieures.

L'auteur appelle cette approche l'apprentissage par la réflexion : une erreur devient un contrat, et le système devient plus robuste au fil du temps.

L'article inclut également des chiffres pratiques : sur quatre mois, selon l'auteur, l'approche a été utilisée dans plus de 400 sessions sur 11 projets, incluant le firmware, la cryptographie et l'infrastructure de clé publique, tandis que les coûts d'IA pour un projet totalisaient environ 30 dollars.

La logique est que les jetons bon marché et les structures de fichiers simples fournissent parfois plus de valeur que des plates-formes multi-couches coûteuses.

Une partie importante de l'article se concentre non seulement sur les outils mais aussi sur le niveau d'interaction avec l'IA.

L'auteur décrit une échelle de maturité : de l'autocomplétion et du soi-disant vibe-coding au partenariat architectural, où l'ingénieur définit les rôles, les contrats et les limites, et le code devient le résultat d'un processus correctement organisé.

Cela mène à une thèse plus large : les entreprises achètent souvent l'illusion d'autonomie quand des outils comme Devin, Copilot Workspace ou des plates-formes d'agents d'entreprise promettent du travail sans un humain, mais en pratique se heurtent toujours au manque de mémoire de projet et de contexte.

En ce sens, l'IA devrait être envisagée non pas comme un remplacement des ingénieurs, mais comme un exosquelette qui amplifie les spécialistes et rend particulièrement précieux ceux qui peuvent transformer leur expérience en un système formalisé.

Pour soutenir cette idée, l'auteur fait même référence à d'anciens concepts de symbiose homme-machine, Design by Contract et contexte de travail unifié, montrant que la méthodologie elle-même importe plus qu'une pile à la mode.

Pour le marché, c'est un autre signal que la prochaine étape du développement de l'IA pourrait basculer d'une course entre orchestrateurs à une course pour la qualité du contexte.

Les pipelines autonomes resteront utiles pour les tâches routinières, mais dans les travaux d'ingénierie complexe, les équipes qui peuvent stocker l'historique des décisions, formaliser l'expertise du domaine et construire une mémoire à long terme autour des modèles l'emporteront, plutôt que de simplement ajouter de nouvelles couches d'infrastructure.