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

Sur Habr AI, une analyse de l'architecture de développement IA a été publiée, dans laquelle un LLM coûteux n'écrit plus le code lui-même, mais gère un exécuteur moins cher. L'auteur affirme que cette restructuration a contribué à éliminer les boucles infinies d'erreurs, à réduire la taille du contexte et à réduire significativement les dépenses API.

Où les Agents ont Échoué

L'équipe a commencé par une approche populaire : elle a pris Aider et l'a intégré dans CI/CD pour que l'agent mette automatiquement à jour la documentation après les changements de code. Pour cette tâche, l'outil a bien fonctionné et a résolu une partie de la dette technique. Mais quand ils ont essayé de lui confier le cycle complet de développement — du backlog et des spécifications au code et aux tests — le système a rapidement buté sur des limitations.

Il y avait deux problèmes principaux : un contrôle faible des intégrations et un transfert d'artefacts peu clair entre les étapes, quand un agent créait quelque chose mais il était difficile de l'extraire et l'intégrer de manière fiable à l'étape suivante.

La tentative suivante était plus proche d'une structure organisationnelle familière : un orchestrateur définit la tâche et plusieurs agents-codeurs l'exécutent par parties. Sur le papier, le schéma semblait logique, mais en pratique il a produit deux défaillances systémiques. La première était une rupture de responsabilité : si un agent ne complétait pas une partie d'une fonction, et que le suivant construisait déjà sa logique dessus, l'erreur commençait à se propager en cascade. La seconde était une paralysie analytique. Les modèles lisaient infiniment le dépôt, reverrouillaient les fichiers et retardaient les changements réels tandis que le contexte s'enflait et la facture des tokens augmentait.

Pourquoi Changer de Rôles

Pendant les tests, l'équipe a remarqué que différents modèles ont en effet un "caractère" de travail distinct. Gemini 3 Pro agit comme un développeur trop confiant et peut dévier de la spécification originale. MiniMax M2.5, au contraire, est prudent et lit la moitié du projet avant de faire le premier pas. Claude Sonnet 4.6 a montré le meilleur équilibre entre autonomie et discipline, mais l'utiliser pour chaque petite action s'est avéré trop coûteux pour une startup.

C'est d'ici que l'idée nouvelle a émergé : un modèle puissant doit être assigné non pas à la routine, mais au contrôle.

"Le PDG ne fait pas d'appels à froid."

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

• Un agent mène une spécification du début à la fin et corrige ses propres erreurs.
• Un agent ne travaille qu'avec un "bureau" limité de 5-8 fichiers, pas l'ensemble du dépôt.
• En fermant un fichier, il sauvegarde une brève mémoire des découvertes utiles pour éviter de traîner le code source entier dans le contexte.
• Le modèle le plus intelligent ne code pas directement, mais agit comme gestionnaire d'état pour un travailleur bon marché.

Comment Fonctionne le Gestionnaire

Dans la nouvelle architecture, un LLM bon marché et rapide agit comme travailleur : il écrit le code, appelle les outils, reçoit les erreurs de compilation et effectue des passages routiniers. Quand le travailleur rencontre un problème ou atteint sa limite d'actions, le contrôle est repris par le modèle coûteux — le gestionnaire d'état. Il ne corrige pas directement le code, mais lit l'historique accumulé, filtre le bruit et assemble une version compacte et utile du contexte pour l'étape suivante.

Le gestionnaire d'état fait quatre choses en séquence :

• Enregistre brièvement ce qui a réellement été fait et ce qui fonctionne.
• Met à jour la mémoire : variables, décisions, conflits de bibliothèque trouvés et impasses.
• Vérifie s'il a du sens de continuer, ou si la tâche a buté sur des limitations d'outils.
• Formule une directive claire sur comment le travailleur doit avancer et contourner les erreurs.

La technique la plus intéressante est la manière dont ces instructions sont transmises. Les recommandations du gestionnaire, en plus du bloc de mémoire, sont présentées au travailleur comme un nouveau message utilisateur. Grâce à cela, l'exécuteur perçoit les instructions comme prioritaires et les conteste moins. Parallèlement, le système efface la conversation antérieure du travailleur avec les logs et les erreurs pour commencer un nouveau cycle avec une "fenêtre propre".

Il y a un risque dans cette approche : si le gestionnaire interprète mal les logs et inscrit un faux fait en mémoire, le travailleur suivra obstinément un parcours erroné. Mais l'auteur écrit que dans le rôle analytique, le modèle coûteux hallucine beaucoup moins fréquemment que dans la génération directe de code.

Un effet supplémentaire — les tests et la documentation commencent à apparaître avec la tâche par défaut, et les développeurs se décalent du rôle d'exécutants manuels vers le rôle d'opérateurs et d'architectes de processus.

Ce que Cela Signifie

Ce cas démontre bien que le succès en développement IA vient non seulement du choix du modèle, mais aussi de la bonne distribution des rôles entre eux. Si vous utilisez un LLM coûteux comme despacheur de mémoire, contrôleur de décisions et disjoncteur pour les boucles sans sens, vous pouvez simultanément augmenter la stabilité du processus et réduire le coût des retouches.

Pour les équipes qui ont déjà été brûlées par des "programmeurs autonomes", c'est l'une des conclusions architecturales les plus pratiques des derniers mois.