Fable contre 10 LLMs : qui maîtrise le mieux le god node d'un agent réel ?

L'auteur de Habr en juillet 2026 a mené une expérience détaillée : il a pris un god node d'un véritable agent LangGraph fonctionnant et a organisé un tournoi en deux étapes pour 11 modèles de langage — cinq américains et six chinois, y compris Fable d'Anthropic. De plus, il a appliqué trois méthodes d'analyse indépendantes pour comprendre en qui on pouvait avoir confiance parmi les participants.

Pourquoi god node est un test équitable

Dans les projets LangGraph, un god node est un nœud monolithique qui assume trop de responsabilités : analyser les données d'entrée, prendre des décisions sur les invocations d'outils, traiter les résultats, former la sortie finale. De tels nœuds croissent graduellement : au début d'un projet, les limites de responsabilité ne sont pas encore claires, et plus tard il devient effrayant de changer l'architecture — et le nœud continue de se développer.

Refactoriser un god node est une tâche où un LLM ne peut pas deviner la bonne réponse en se basant sur des modèles statistiques. Ici, vous avez besoin d'une véritable compréhension de l'architecture :

• Comprendre le graphe dans son ensemble et trouver les dépendances cachées entre les nœuds
• Proposer un schéma spécifique de décomposition avec justification des limites choisies
• Ne pas violer le contrat existant : entrées, sorties, effets secondaires
• Tenir compte des particularités de LangGraph — transfert d'état, arêtes conditionnelles, points de rupture

Au-delà de la compréhension architecturale, la prudence est importante : refactoriser un god node dans du code de production risque de toucher des dépendances inattendues. Un modèle qui propose "simplement de diviser en plusieurs fonctions" ne comprend pas le contexte — et son plan est inutile en pratique.

L'auteur a utilisé non pas un exemple synthétique, mais du vrai code en fonctionnement avec une véritable histoire. C'est crucial : le vrai code contient du hasard, des artefacts historiques et des dépendances non évidentes qui n'existent pas dans les exemples de manuels.

Comment le tournoi en deux étapes a fonctionné

Dans la première phase, chacun des 11 modèles a reçu un god node et une tâche : proposer un plan de décomposition spécifique. Parmi les participants américains se trouve Fable, le dernier modèle d'Anthropic au moment de la publication. Six modèles chinois représentaient les plus grands laboratoires d'IA de Chine.

Dans la deuxième phase, chaque modèle a reçu les propositions des dix autres et devait les évaluer : trouver les forces et les faiblesses de chaque solution, choisir la meilleure et justifier le choix. Cela permet de mesurer deux compétences à la fois — la capacité à générer des solutions architecturales et la capacité à analyser critiquement les autres.

L'audit croisé est une technique méthodologiquement non standard. Dans les benchmarks typiques, un modèle reçoit une tâche et produit une réponse, mais on ne sait pas s'il comprend ce qu'est une bonne solution dans ce domaine. Quand un modèle évalue les concurrents, il devient clair à quel point sa compréhension de la "bonne" réponse s'aligne avec les véritables normes d'ingénierie.

Après avoir collecté toutes les propositions et évaluations mutuelles, l'auteur a appliqué trois méthodes d'analyse indépendantes. Les résultats ont partiellement coïncidé, partiellement divergé — et c'est exactement ce qui est devenu la principale conclusion de l'expérience. De là vient "La Mort des Dieux" dans le titre : les modèles phares avec la meilleure réputation n'ont pas fourni de résultats systématiquement supérieurs. Selon l'auteur, les benchmarks synthétiques et le code d'ingénierie réel sont deux tâches différentes, et les leaders dans l'une ne sont pas toujours leaders dans l'autre.

Ce que cela signifie

La position sur les classements publics prédit mal comment un modèle gérera l'examen du code ou les propositions architecturales dans un projet spécifique. L'écart entre "le meilleur modèle selon l'évaluation" et "le meilleur modèle pour votre pile" peut être substantiel.

Conclusion pratique : avant de déléguer des décisions techniques à un LLM spécifique — surtout dans les tâches de refactorisation ou d'examen architectural — il vaut la peine de le tester sur des tâches de code réel. Le format en deux étapes avec évaluations croisées de cette expérience est un bon modèle pour un tel test : il révèle non seulement les capacités génératives, mais aussi la compréhension critique du domaine.