Habr AI : plutôt que des pipelines d'agents complexes, on conseille aux développeurs markdown, git et mémoire de sessions

Une tribune publiée sur Habr avance une idée simple mais tranchée : la plupart des équipes compliquent à l'excès leur travail avec les agents d'IA. Elles construisent des pipelines lourds avec LangChain, du RAG et des bases de données vectorielles, alors que dans le développement réel, la mémoire des décisions prises compte plus que l'orchestration. L'auteur compare l'engouement actuel pour les stacks d'agents à l'ère LAMP du milieu des années 2000 : l'industrie se passionne de nouveau pour l'infrastructure et se demande trop rarement en quoi elle aide à résoudre les problèmes concrets du produit.

Le texte examine une approche d'entreprise typique : un orchestrateur répartit les tâches entre plusieurs agents, qui vont chercher du contexte dans le RAG, appellent des outils, écrivent du code et ouvrent des pull requests. Selon l'auteur, ce schéma convient assez bien à l'automatisation de tâches routinières comme la revue de code, les tests et le linting, mais tient mal sur le long terme. Le problème tient moins au modèle qu'à la conception de la mémoire : chaque nouveau ticket démarre souvent, pour l'agent, presque de zéro, sans historique solide des décisions, sans compréhension du domaine et sans les contraintes accumulées du projet.

La recherche sémantique dans le code paraît donc utile, mais elle ne remplace pas la connaissance réelle des raisons pour lesquelles l'équipe a un jour choisi telle voie.

Comme alternative, l'auteur propose un système presque ascétique, fondé sur des fichiers markdown et git. Au lieu d'un pipeline universel, il construit une mémoire de travail à partir de sessions, de rôles, de compétences, de contextes et de règles. La session conserve trois niveaux de contexte, court, moyen et profond, afin que le travail suivant reparte de décisions consignées et non d'un chat vide. Le rôle décrit non pas un programmeur abstrait, mais une spécialisation précise dotée de connaissances du domaine : quelles API utiliser, quelles erreurs sont typiques, quelles contraintes imposent le matériel, le protocole ou le projet. D'après l'auteur, cela réduit les hallucinations du modèle mieux qu'une couche de plus autour des appels au LLM.

L'auteur insiste particulièrement sur les règles nées des erreurs. Si un agent a un jour supprimé un fichier sans confirmation, s'est enlisé dans un débogage sans fin ou a perdu des modifications non validées en changeant de branche, cela ne donne pas un nouveau service middleware, mais une règle explicite pour les sessions suivantes. Il appelle cette approche l'apprentissage par la réflexion : l'erreur devient un contrat, et le système gagne en robustesse avec le temps.

L'article donne aussi des chiffres concrets : sur quatre mois, selon l'auteur, le schéma a servi dans plus de 400 sessions sur 11 projets, dont du firmware, de la cryptographie et de la PKI, et les dépenses d'IA pour l'un des projets se sont élevées à environ 30 dollars. La logique : des tokens bon marché et une structure de fichiers simple apportent parfois plus qu'une plateforme coûteuse à plusieurs niveaux.

Une part importante de l'article porte 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 vibe coding, comme on l'appelle, jusqu'au partenariat architectural, où l'ingénieur définit les rôles, les contrats et les limites, et où le code découle d'un processus bien organisé. D'où une thèse plus large : les entreprises achètent souvent une illusion d'autonomie.

Des outils comme Devin, Copilot Workspace ou les plateformes d'agents d'entreprise promettent un travail sans humain, mais butent en pratique sur le manque de mémoire et de contexte du projet. En ce sens, l'IA est présentée non comme un remplaçant de l'ingénieur, mais comme un exosquelette qui renforce le spécialiste et donne une valeur particulière à celui qui sait transformer sa propre expérience en système formalisé. Pour étayer cette idée, l'auteur cite même d'anciens concepts de symbiose entre l'humain et l'ordinateur, le Design by Contract et le contexte de travail unifié, afin de montrer que la méthodologie compte ici plus que la pile technologique à la mode.

Pour le marché, c'est un signal de plus que la prochaine étape du développement avec l'IA pourrait passer de la course aux orchestrateurs à la course à la qualité du contexte. Les pipelines autonomes resteront utiles pour la routine de masse, mais, dans les tâches d'ingénierie complexes, les équipes gagnantes seront celles qui savent conserver l'historique des décisions, formaliser l'expertise métier et bâtir une mémoire durable autour du modèle, plutôt que d'empiler de nouvelles couches d'infrastructure.