Технический контекст
Я зацепился не за очередной фреймворк, а за очень земной рабочий паттерн: write spec - plan - subagent-driven development. Суть простая и, честно, болезненно знакомая. Если кодогенерация пошла вразнос, спасает не новый промпт, а живая спека, которую можно открыть и пересобрать решение почти с нуля.
В этом кейсе фигурирует change_spec.md как опорный файл, который живёт рядом с кодом. Не документ ради галочки, а источник истины: что меняем, какие ограничения, что считаем успешным результатом. Когда кодовая база «загрязнилась» или агенты начали тащить решение не туда, я могу вернуться к спецификации и перегенерировать ветку без гадания на кофейной гуще.
Особенно понравилась оценка времени: на большую задачу уходит 2-3 дня на спеку и всего 0.5-1 день на генерацию кода. То есть 70-80% усилий съедает не программирование, а формализация задачи. Звучит почти обидно, пока сам не упрёшься в мультиагентную систему, которая идеально быстро делает не то.
Технически это очень похоже на нормальную иерархию. Один агент или человек формирует spec через brainstorming, дальше планировщик режет её на шаги, потом субагенты берут узкие куски: backend, frontend, тесты, валидацию. Такой расклад я считаю взрослее, чем попытка запихнуть весь проект в один длинный контекст и надеяться, что модель «сама поймёт».
Ещё один сильный момент тут в декомпозиции. Если спека стала слишком жирной, её надо не дописывать до бесконечности, а разбивать по естественным границам: intake, analysis, execution, validation. И вот тут мультиагентность начинает приносить пользу, а не просто жечь токены ради красивой схемы.
Что это меняет для бизнеса и автоматизации
Для бизнеса вывод жёсткий: основная неопределённость в AI-проектах сидит не в модели, а в постановке задачи. Если у вас нет живой спецификации, никакая автоматизация с помощью ИИ не будет стабильной. Будет серия демонстраций, после которых команда тихо ненавидит слово «агент».
Я это вижу на проектах, где просят создать ИИ агента под внутренние процессы. Почти всегда первый реальный прорыв происходит не после смены модели, а после того как мы вынимаем из голов людей критерии результата, исключения, роли, ограничения по данным и правила эскалации. Как только это легло в нормальную spec-структуру, архитектура ИИ-решений становится сильно спокойнее.
Кто выигрывает? Команды, у которых длинные R&D-циклы, много неоднозначности и дорогие ошибки: продуктовая разработка, внутренние платформы, сложные интеграции, enterprise-процессы. Кто проигрывает? Те, кто ждёт мгновенной магии и считает спецификацию бюрократией. Мультиагенты без хорошей спеки легко превращаются в дорогой способ распараллелить путаницу.
Я бы не советовал тащить multi-agent setup в каждый кейс. Если задачу закрывает один агент с нормальными tool calls, этого часто достаточно. Но когда контекст пухнет, этапов много, а результат нужно уметь пересобирать, spec-first подход начинает окупаться очень быстро.
Мы в Nahornyi AI Lab такие штуки обычно собираем через практичную связку: живая спецификация, планировщик, изолированные исполнители, контроль артефактов и понятный контур ревью человеком. Это уже не «поиграться с LLM», а нормальное внедрение ИИ в разработку и операционные процессы, где важна повторяемость.
Я, Вадим Нагорный из Nahornyi AI Lab, смотрю на такие паттерны не как наблюдатель, а как человек, который регулярно собирает ИИ автоматизации, агентные пайплайны и кастомную AI-архитектуру под реальные задачи. Если хотите обсудить ваш кейс, заказать ИИ автоматизацию, разработку ИИ агента под заказ или n8n-автоматизацию, пишите. Разберём, где вам правда нужен рой агентов, а где хватит одной внятной спеки и хорошей сборки.