Habr AI : comment les LLM coûteux sont devenus des gestionnaires d'état et ont réduit les coûts de développement

Habr AI a publié une analyse d'une architecture de développement par IA dans laquelle le LLM coûteux n'écrit plus le code lui-même, mais pilote un exécutant moins cher. L'auteur affirme que cette refonte a supprimé les boucles d'erreurs sans fin, raccourci le contexte et nettement réduit les dépenses d'API.

Où les agents échouaient

L'équipe a commencé par la voie classique : elle a pris Aider et l'a intégré au CI/CD pour qu'un agent mette à jour automatiquement la documentation après chaque modification du code. Pour cette tâche, l'outil a bien fonctionné et a résorbé une partie de la dette technique. Mais quand on a voulu lui confier le cycle complet de développement, du backlog et des spécifications jusqu'au code et aux tests, le système a vite atteint ses limites. Deux problèmes principaux sont apparus : un contrôle faible sur les intégrations et un transfert flou des artefacts entre les étapes, où l'agent crée quelque chose, mais où il est difficile de le récupérer de façon fiable pour l'intégrer à l'étape suivante.

La tentative suivante ressemblait davantage à un organigramme habituel : un orchestrateur fixe la tâche et plusieurs agents codeurs l'exécutent par morceaux. Sur le papier, le schéma paraît logique, mais en pratique il a provoqué deux défaillances systémiques. La première est une rupture de responsabilité : si un agent n'achève pas une partie d'une fonction et que le suivant bâtit déjà sa logique dessus, l'erreur se propage en cascade. La seconde est la paralysie par l'analyse. Les modèles lisent le dépôt à l'infini, revérifient les fichiers et repoussent les vraies modifications pendant que le contexte gonfle et que la facture de tokens grimpe.

Pourquoi changer les rôles

Pendant les tests, l'équipe a constaté que les différents modèles ont bel et bien un « caractère » de travail. Gemini 3 Pro se comporte comme un développeur trop sûr de lui et peut s'écarter du cahier des charges initial. MiniMax M2.5, au contraire, est prudent et lit la moitié du projet avant de faire un premier pas. Claude Sonnet 4.6 a offert le meilleur équilibre entre autonomie et discipline, mais l'utiliser pour chaque petite action s'est révélé trop cher pour une start-up.

C'est de là qu'est née la nouvelle idée : le modèle puissant doit être placé non sur la routine, mais sur le contrôle.

« Le PDG ne fait pas de démarchage téléphonique. »

Au lieu d'un schéma où le LLM coûteux écrit le code le plus complexe, l'équipe a instauré plusieurs règles strictes :

• Un agent mène une spécification du début à la fin et corrige lui-même ses erreurs.
• L'agent ne travaille qu'avec un « bureau » limité de 5–8 fichiers, et non avec tout le dépôt.
• En fermant un fichier, il enregistre une courte mémoire des découvertes utiles, afin de ne pas traîner le code source entier dans le contexte.
• Le modèle le plus intelligent ne code pas à la main, mais joue le rôle de gestionnaire d'état pour le worker bon marché.

Comment fonctionne le gestionnaire

Dans la nouvelle architecture, un LLM bon marché et rapide joue le rôle de worker : il écrit du code, appelle des outils, reçoit les erreurs de compilation et effectue les passes de routine. Quand le worker bute sur un problème ou épuise sa limite d'actions, le modèle coûteux, le gestionnaire d'état, prend la main. Il ne touche pas directement au code : il lit l'historique accumulé, écarte le bruit et prépare pour l'étape suivante une version compacte et utile du contexte.

Le gestionnaire d'état accomplit quatre tâches à la suite :

• Il consigne brièvement ce qui a réellement été fait et ce qui fonctionne.
• Il met à jour la mémoire : variables, décisions, conflits de bibliothèques détectés et impasses.
• Il vérifie s'il est pertinent de continuer ou si la tâche a atteint les limites des outils.
• Il formule une directive claire sur la manière dont le worker doit avancer et contourner les erreurs.

L'astuce la plus intéressante tient à la manière de transmettre ces consignes. Outre le bloc de mémoire, les recommandations du gestionnaire sont présentées au worker comme un nouveau message utilisateur. L'exécutant les perçoit ainsi comme prioritaires et les conteste moins. En parallèle, le système efface sa conversation précédente, faite de logs et d'erreurs, pour démarrer un nouveau cycle avec une « fenêtre propre ».

Ce schéma comporte aussi un risque : si le gestionnaire interprète mal les logs et inscrit un fait erroné en mémoire, le worker suivra obstinément la mauvaise voie. Mais l'auteur écrit que, dans un rôle d'analyse, le modèle coûteux hallucine bien moins souvent que lorsqu'il génère directement du code.

Un effet supplémentaire : les tests et la documentation apparaissent par défaut avec la tâche, et les développeurs passent du rôle d'exécutants manuels à celui d'opérateurs et d'architectes du processus.

Ce que cela signifie

Ce cas montre que le gain dans le développement par IA ne vient pas seulement du choix du modèle, mais aussi d'une bonne répartition des rôles entre eux. Si l'on utilise le LLM coûteux comme répartiteur de mémoire, contrôleur des décisions et frein d'urgence face aux boucles absurdes, on peut à la fois renforcer la stabilité du processus et réduire le coût des reprises. Pour les équipes déjà échaudées par les « programmeurs autonomes », c'est l'un des enseignements d'architecture les plus pratiques de ces derniers mois.