Fable против 10 LLM: кто лучше справляется с god node из реального агента

Автор с Habr в июле 2026 года провёл детальный эксперимент: взял god node из реального рабочего LangGraph-агента и устроил двухэтапный турнир для 11 языковых моделей — пяти американских и шести китайских, включая Fable от Anthropic. Дополнительно применил три независимых метода анализа, чтобы понять, кому из участников можно доверять.

Почему god node — честный тест

В LangGraph-проектах god node — монолитный узел, который берёт на себя слишком много обязанностей: парсит входные данные, принимает решения о вызове инструментов, обрабатывает результаты, формирует финальный вывод. Такие узлы вырастают постепенно: на старте проекта границы ответственности ещё не очевидны, а потом менять архитектуру страшно — и узел продолжает разрастаться.

Рефакторинг god node — задача, в которой LLM нельзя угадать «правильный» ответ по статистическому паттерну. Здесь нужно реальное понимание архитектуры:

• Разобраться в графе целиком и найти скрытые зависимости между узлами
• Предложить конкретную схему декомпозиции с обоснованием выбора границ
• Не нарушить существующий контракт: входы, выходы, побочные эффекты
• Учесть особенности LangGraph — передачу состояния, условные рёбра, точки прерывания

Помимо понимания архитектуры, важна аккуратность: рефакторинг god node в production-коде рискует задеть неожиданные зависимости. Модель, которая предлагает «просто разбить на несколько функций», не понимает контекста — и её план бесполезен на практике.

Автор использовал не синтетический пример, а реальный рабочий код с реальной историей. Это принципиально: реальный код содержит случайности, исторические артефакты и неочевидные зависимости, которых нет в учебных примерах.

Как работал двухэтапный турнир

На первой фазе каждая из 11 моделей получила god node и задание: предложить конкретный план декомпозиции. В числе американских участников — Fable, последняя на момент публикации модель Anthropic. Шесть китайских моделей представляли крупнейшие AI-лаборатории Китая.

На второй фазе каждая модель получила предложения остальных десяти и должна была их оценить: найти сильные и слабые стороны каждого решения, выбрать лучшее и обосновать выбор. Это позволяет измерить два навыка сразу — способность генерировать архитектурные решения и способность критически анализировать чужие.

Перекрёстный аудит — методологически нестандартный приём. В обычных бенчмарках модель получает задачу и выдаёт ответ, но неизвестно, понимает ли она, что такое хорошее решение в этой области. Когда модель оценивает конкурентов, становится видно, насколько её представление о «правильном» ответе совпадает с реальными инженерными стандартами.

После сбора всех предложений и взаимных оценок автор применил три независимых метода анализа. Результаты частично совпали, частично разошлись — и именно это стало главным выводом эксперимента. Именно отсюда «Гибель богов» в названии: флагманские модели с лучшей репутацией не дали стабильно превосходящего результата. По мнению автора, синтетический бенчмарк и реальный инженерный код — это две разные задачи, и лидеры в одной не всегда оказываются лидерами в другой.

Что это значит

Позиция в публичных лидербордах плохо предсказывает, как модель справится с code review или архитектурными предложениями в конкретном проекте. Разрыв между «лучшей моделью по рейтингу» и «лучшей моделью для вашего стека» может оказаться существенным.

Практический вывод: прежде чем делегировать технические решения конкретной LLM — особенно в задачах рефакторинга или архитектурного ревью — стоит протестировать её на задачах из реального кода. Двухэтапный формат с перекрёстными оценками из этого эксперимента — хороший шаблон для такого теста: он выявляет не только генеративные способности, но и критическое понимание предметной области.