Прогнали Dynamic Workflows Claude Code на реальном проекте поверх NaCl: что сработало, а что нет

Привет! Меня зовут Максим Никитин, я фаундер небольшой, но гордой студии разработки сложных и нетиповых проектов ITSalt. В начале 2025 года мы начали переходить на агентскую разработку и постепенно собрали вокруг этого собственный фреймворк - NaCl. Сейчас он закрывает бизнес-анализ, системное проектирование, TDD, код-ревью, QA и релиз - по сути, весь цикл от требования до продакшна.

NaCl можно посмотреть в публичном репозитории. Внутри - набор скиллов, пайплайн ролей, граф Neo4j как источник истины по требованиям и решениям, плюс набор правил, которые заставляют агента работать не «по вдохновению», а по воспроизводимой методологии.

Когда в Claude Code появилась фича Dynamic Workflows, я решил проверить её не на демке, а на реальном проекте. Не ради хайпа и не ради вывода «хорошая фича / плохая фича». Мой вопрос был чисто практический:

• усиливает ли Dynamic Workflows наш текущий стек;

• где это имеет смысл применять внутри NaCl;

• где это может быть полезно тем, у кого своего фреймворка нет;

• и где лучше не тратить на это лимиты, токены и время.

Проверяли на нашем реальном проекте Family Cinema - сервисе для генерации семейных фильмов. Это не учебная песочница и не специально собранный демо-код, а продуктовый проект с backend/frontend, пайплайнами генерации видео и музыки через внешние сервисы и инженерным контекстом, который приходится учитывать при ревью.

Что такое Dynamic Workflows и с чем мы это сравнивали

Dynamic Workflows в Claude Code - это не просто "запусти несколько агентов". Это скрипт, который Claude Code исполняет как оркестратор: внутри можно описывать фазы, запускать агентов, параллелить независимые задачи, строить конвейеры, ждать завершения всех веток и собирать результат.

В NaCl механизм другой. Скиллы - это инструкции, которые ведут Claude Code через задачу последовательно: бизнес-аналитик, системный аналитик, тимлид, ревьюер, QA и так далее. Важная часть подхода - человеческие гейты: агент не должен сам перепрыгивать через принципиальные решения.

Поэтому я не спрашивал себя "заменить ли скиллы на workflow". Я спрашивал другое: "есть ли у нас задачи, где параллельный запуск нескольких агентов даст то, чего обычный скилл дать не может".

Для сравнения я разложил наши задачи на четыре типа.

Тут я сразу понял одну вещь. Workflow - это не замена всему подряд. Механику надо отдавать коду, диалог с остановками - скиллу. А workflow нужен там, где тебе нужно несколько независимых точек зрения одновременно.

Когда workflow вообще имеет смысл

Когда я прикинул, куда workflow ложится, а куда нет, вырисовалось простое правило. Workflow имеет смысл только на задачах, где нужно суждение - не «прогони 50 запросов», а «посмотри, нет ли тут дыры в безопасности». При этом агенты не должны стоять в очереди друг за другом, иначе проще запустить одного. И главное - разные углы зрения должны реально давать разные находки. Ревьюер безопасности видит одно, ревьюер корректности - другое. Если этого нет, ты просто жжёшь токены ради красивого отчёта.

Про токены, раз уж зашла речь. Даже на подписке расход никуда не исчезает. Большие прогоны сжигают лимиты и время. Вопрос всегда один: стоит ли результат потраченного лимита.

Какие задачи NaCl мы рассматривали

Я посмотрел на существующие скиллы NaCl и отобрал кандидатов, куда workflow теоретически мог бы лечь.

Для эксперимента выбрал код-ревью.

Причина простая: мы делаем его постоянно, у нас уже есть привычный скилл, и можно сравнить три вещи в лоб:

• как работает обычный скилл / одиночный агент;

• что даёт многоагентный workflow;

• стоит ли результат кратно большего расхода.

Как был устроен многоагентный workflow для ревью

Я собрал workflow, который повторяет контракт вывода нашего обычного NaCl-скилла ревью, но внутри раскладывает работу на несколько независимых агентов.

Артефакты эксперимента:

• workflow: nacl-review-panel.js;

• README с запуском;

• тестовая фикстура: bench/fixtures/review-panel.

Устройство было таким:

Механику я не стал раздавать LLM-агентам. Линтер, типы, тесты, проверки по графу - это не работа, требующая суждения. Её должен делать скрипт или дешёвая быстрая модель.

На LLM я оставил только то, что требует смысловой оценки: безопасность, корректность, API-контракты, работу с данными, требования, frontend/backend-специфику. Каждую область разбирал отдельный агент. На серьёзные находки запускался агент-скептик, который пытался их опровергнуть.

Заход 1. Искусственный пример

Сначала я сделал маленький NestJS-бэкенд с заранее размеченной истиной. Взял NestJS, потому что Family Cinema на нём; один баг и одна ловушка - минимальный набор, чтобы проверить и точность, и устойчивость к ложным срабатываниям.

Первый сырой прогон выглядел так:

Что получилось:

Самое интересное здесь - незаложенный баг. Workflow нашёл класс проблемы «код есть, но снаружи он недостижим». Это как раз тот случай, где независимые углы анализа могут дать пользу: один агент смотрит на метод, другой - на маршрутизацию, третий - на контракт.

Но 26 находок на маленький кусок кода - это перебор. Я ожидал шума, но не такого: две трети находок были придирками, которые в реальном ревью никто бы не стал обсуждать. Поэтому я сделал три настройки:

• сузил фокус ревьюеров;

• добавил перепроверку для более широкого набора находок;

• добавил удаление дублей на этапе синтеза.

После настройки:

Шум удалось срезать примерно вдвое. На этом этапе казалось, что направление перспективное.

Грабли №1. Настройки запуска не дошли до workflow

Первый инструментальный сюрприз был не про качество ревью, а про запуск.

Когда я запускал workflow с кастомными параметрами - какие файлы ревьюить, какой чеклист использовать - эти параметры молча терялись. Workflow запускался с настройками по умолчанию и проверял не то, что я ему передал.

На последней версии Claude Code это воспроизводилось стабильно. Обход был простой: вместо передачи параметров я генерировал отдельную версию скрипта с зашитыми значениями и запускал уже её.

Если workflow запускается не на том входе, красивый отчёт становится бесполезным.

Заход 2. Реальная задача и ложное одобрение

Дальше я взял настоящую задачу из Family Cinema: backend для админского дашборда пайплайнов - список, детали, обновления прогресса в реальном времени, репозиторий, схемы валидации. Изменение было уже не игрушечное: 1484 строки, 7 файлов.

Сравнивал два подхода:

• многоагентный workflow после настройки;

• наш обычный скилл ревью на модели Opus, со спецификацией и чеклистом.

Но в этом сравнении была важная асимметрия, которую я сначала недооценил:

• workflow смотрел только на изменённые файлы;

• одиночный агент мог читать весь репозиторий.

Результат:

Это был главный негативный результат этого захода: дорогой многоагентный workflow разрешил публиковать код с реальным багом, а одиночный агент нашёл проблему и завернул задачу.

22 агента, миллион токенов, десять минут прогона - и на выходе вся эта армада разрешает катить в продакшн код с реальным багом. [TODO: уточни свою реакцию - что ты почувствовал в этот момент]

А дальше стало ещё обиднее. Workflow не просто «не увидел» баг. Один из его агентов увидел. И поднял. И его заткнули.

Баг был такой. У нас есть обновления прогресса пайплайна в реальном времени. Новый код, который мы ревьюили, подписывал клиента на статусы running и completed. А в другой части системы - в файлах, которые в этой задаче никто не трогал - статусы назывались processing и ready. Фронтенд слушал одни слова, бэкенд говорил другие. На экране прогресс просто замирал.

Один из ревьюеров внутри workflow это поймал и поднял как блокирующую ошибку. Но проверяющий агент - тот, чья работа перепроверять чужие находки - полез искать подтверждение в изменённых файлах. Не нашёл, потому что доказательство лежало в файле, который никто не менял. И по инструкции «если не можешь подтвердить - отклоняй» выкинул находку.

Одиночный агент просто прочитал весь проект. Нашёл файл с реальными статусами. Увидел, что тесты маскируют баг тем же словарём. И завернул задачу.

Я потратил миллион токенов на 22 агента. Выиграл один, который мог прочитать соседний файл.

Что пришлось исправить

После этого я поменял четыре вещи в workflow.

Больше всего на результат повлияла перепроверка. Мы по сути перевернули её логику: проверяющий агент больше не выкидывает находку, если не смог её подтвердить. Он обязан доказать, что находка ложная. Не смог - находка остаётся. Когда агент видит только кусок проекта, это критически важно.

Заход 3. Честное сравнение: оба видят проект

Третий заход - задача крупнее: backend-часть обработки видео, оркестрация, ретраи, интеграция с внешними сервисами. На этот раз оба метода получили доступ к одному и тому же срезу проекта.

Результат:

Фиксы сработали: ложных одобрений больше не было. Workflow прочитал соседние файлы и поймал проблемы на стыке модулей.

Один пример. Настройки модели для видео и музыки в конфиге существовали, но клиент сервиса их игнорировал и всегда отправлял одну и ту же модель. Часть заявленной функциональности была мёртвой. В прошлом заходе workflow бы эту находку выбросил - контекста не хватило бы. Теперь она дошла до отчёта.

Но самое важное - сравнение находок.

Тут уже нет простого ответа «workflow лучше» или «одиночный агент лучше».

Workflow нашёл гонку данных, которую одиночный агент пропустил. Поднял риск атаки через внешние ссылки. Вытащил несоответствие требованиям. Но два реальных бага одиночный агент поймал, а workflow - нет. И за эту широту workflow берёт в 15 раз больше токенов и в 4-5 раз больше времени.

Главные выводы

1. Настройка решает всё

На заходе 2 у нас 22 агента уверенно одобрили код с багом. Не потому, что workflow плохой. А потому, что мы неправильно настроили контекст, логику перепроверки и правила вердикта. Починили - и на заходе 3 workflow уже нашёл то, что одиночный агент пропустил.

2. Контекст важнее параллелизма

Один агент, который видит весь проект, поймал баг, который 22 агента с ограниченным обзором потеряли. Я потом перенёс этот принцип обратно в наш обычный скилл ревью: теперь агент обязан смотреть зависимости, а не только изменённые файлы. И обязан обосновывать каждую находку конкретным доказательством. Качество ревью выросло без всякого workflow.

3. Для ежедневного ревью workflow слишком дорог

В наших прогонах многоагентный workflow тратил в 12-15 раз больше токенов и в 4-5 раз больше времени. И всё равно пропускал баги, которые ловил одиночный агент.

Для обычного ревью по задаче или по пулл-реквесту нам хватает одного сильного агента с доступом к проекту.

4. Что мы забрали из workflow обратно в скиллы

Главный практический результат эксперимента для NaCl - не сам workflow, а то, что мы из него вытащили и перенесли в обычные скиллы: перевёрнутую логику перепроверки (отклонять находку, только если доказал, что она ложная), отдельную трассировку требований, более строгую логику вердикта, удаление дублей по причинам, а не по симптомам.

Мы не стали тащить workflow целиком в ежедневный процесс - дорого. Но приёмы, которые мы в нём нашли, уже работают в обычных скиллах. Об этом, скорее всего, будет следующая статья.

Когда 15-кратная цена оправдана

Многоагентный workflow имеет смысл, если цена ошибки выше цены токенов.

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

Ещё один вероятный кандидат - предрелизный аудит крупного рискованного изменения. Мы пока не пробовали, но логика понятная: лучше потратить 2 миллиона токенов на аудит, чем откатывать продакшн в три часа ночи.