Прогнали 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". Я спрашивал другое: "есть ли у нас задачи, где параллельный запуск нескольких агентов даст то, чего обычный скилл дать не может".
Для сравнения я разложил наши задачи на четыре типа.
Подход | Где живёт логика | Когда подходит |
|---|---|---|
Скилл NaCl | В инструкции, которую исполняет Claude Code | Последовательные задачи, диалог, гейты, участие человека |
Одиночный сильный агент | В одном контексте и одном проходе | Ревью, анализ, задачи, которые помещаются в контекст |
Многоагентный workflow | В скрипте, который оркестрирует агентов | Параллельный анализ, независимые роли, состязательная проверка |
Детерминированный код | В обычном скрипте | Git, Cypher, файлы, линтеры, тесты, механические проверки |
Тут я сразу понял одну вещь. Workflow - это не замена всему подряд. Механику надо отдавать коду, диалог с остановками - скиллу. А workflow нужен там, где тебе нужно несколько независимых точек зрения одновременно.
Когда workflow вообще имеет смысл
Когда я прикинул, куда workflow ложится, а куда нет, вырисовалось простое правило. Workflow имеет смысл только на задачах, где нужно суждение - не «прогони 50 запросов», а «посмотри, нет ли тут дыры в безопасности». При этом агенты не должны стоять в очереди друг за другом, иначе проще запустить одного. И главное - разные углы зрения должны реально давать разные находки. Ревьюер безопасности видит одно, ревьюер корректности - другое. Если этого нет, ты просто жжёшь токены ради красивого отчёта.
Про токены, раз уж зашла речь. Даже на подписке расход никуда не исчезает. Большие прогоны сжигают лимиты и время. Вопрос всегда один: стоит ли результат потраченного лимита.
Какие задачи NaCl мы рассматривали
Я посмотрел на существующие скиллы NaCl и отобрал кандидатов, куда workflow теоретически мог бы лечь.
Кандидат | Почему мог подойти | Что решили |
|---|---|---|
Код-ревью | Частая задача, есть зрелый скилл, можно честно сравнить новое со старым | Взяли как полигон |
Аудит / пост-мортем проекта | Редкая задача с высокой ценой ошибки, полезны независимые взгляды - когда система упала в три часа ночи, хочется, чтобы каждый аспект разобрал отдельный агент, а не один перегруженный контекст | Хороший кандидат, но не для первого замера |
Диагностика проекта | Широкий анализ с разных сторон - похоже на аудит незнакомого проекта без документации, где каждый слой (инфра, API, бизнес-логика) требует отдельного прохода | Хороший кандидат на будущее |
Для эксперимента выбрал код-ревью.
Причина простая: мы делаем его постоянно, у нас уже есть привычный скилл, и можно сравнить три вещи в лоб:
как работает обычный скилл / одиночный агент;
что даёт многоагентный workflow;
стоит ли результат кратно большего расхода.
Как был устроен многоагентный workflow для ревью
Я собрал workflow, который повторяет контракт вывода нашего обычного NaCl-скилла ревью, но внутри раскладывает работу на несколько независимых агентов.
Артефакты эксперимента:
Устройство было таким:
Механику я не стал раздавать LLM-агентам. Линтер, типы, тесты, проверки по графу - это не работа, требующая суждения. Её должен делать скрипт или дешёвая быстрая модель.
На LLM я оставил только то, что требует смысловой оценки: безопасность, корректность, API-контракты, работу с данными, требования, frontend/backend-специфику. Каждую область разбирал отдельный агент. На серьёзные находки запускался агент-скептик, который пытался их опровергнуть.
Заход 1. Искусственный пример
Сначала я сделал маленький NestJS-бэкенд с заранее размеченной истиной. Взял NestJS, потому что Family Cinema на нём; один баг и одна ловушка - минимальный набор, чтобы проверить и точность, и устойчивость к ложным срабатываниям.
Что заложено | Тип | Ожидание |
|---|---|---|
SQL-инъекция через интерполяцию пользовательских данных в запрос | Реальная блокирующая ошибка | Должен найти |
«Нет авторизации на deleteOrder» | Ложная проблема: защита стоит выше на контроллере | Должен отбросить |
Первый сырой прогон выглядел так:
Прогон | Агенты | Токены | Время | Находки |
|---|---|---|---|---|
Без настройки | 16 | 592 743 | 345 c | 26 |
Что получилось:
Проверка | Результат |
|---|---|
SQL-инъекция | Найдена и пережила перепроверку |
Ложная проблема с авторизацией | Отброшена |
Незаложенный баг | Найден недостижимый метод: сервис реализует GET /orders, но маршрут не подключён |
Шум | Много замечаний уровня «придраться» |
Дубли | Одна причина могла всплыть в нескольких категориях |
Самое интересное здесь - незаложенный баг. Workflow нашёл класс проблемы «код есть, но снаружи он недостижим». Это как раз тот случай, где независимые углы анализа могут дать пользу: один агент смотрит на метод, другой - на маршрутизацию, третий - на контракт.
Но 26 находок на маленький кусок кода - это перебор. Я ожидал шума, но не такого: две трети находок были придирками, которые в реальном ревью никто бы не стал обсуждать. Поэтому я сделал три настройки:
сузил фокус ревьюеров;
добавил перепроверку для более широкого набора находок;
добавил удаление дублей на этапе синтеза.
После настройки:
Прогон | Агенты | Токены | Время | Находки |
|---|---|---|---|---|
Без настройки | 16 | 592 743 | 345 c | 26 |
После настройки | 16 | 521 836 | 419 c | 12 |
Шум удалось срезать примерно вдвое. На этом этапе казалось, что направление перспективное.
Грабли №1. Настройки запуска не дошли до workflow
Первый инструментальный сюрприз был не про качество ревью, а про запуск.
Когда я запускал workflow с кастомными параметрами - какие файлы ревьюить, какой чеклист использовать - эти параметры молча терялись. Workflow запускался с настройками по умолчанию и проверял не то, что я ему передал.
На последней версии Claude Code это воспроизводилось стабильно. Обход был простой: вместо передачи параметров я генерировал отдельную версию скрипта с зашитыми значениями и запускал уже её.
Если workflow запускается не на том входе, красивый отчёт становится бесполезным.
Заход 2. Реальная задача и ложное одобрение
Дальше я взял настоящую задачу из Family Cinema: backend для админского дашборда пайплайнов - список, детали, обновления прогресса в реальном времени, репозиторий, схемы валидации. Изменение было уже не игрушечное: 1484 строки, 7 файлов.
Сравнивал два подхода:
многоагентный workflow после настройки;
наш обычный скилл ревью на модели Opus, со спецификацией и чеклистом.
Но в этом сравнении была важная асимметрия, которую я сначала недооценил:
workflow смотрел только на изменённые файлы;
одиночный агент мог читать весь репозиторий.
Результат:
Метод | Контекст | Вердикт | Токены | Время | Агенты |
|---|---|---|---|---|---|
Многоагентный workflow | Только изменённые файлы | Одобрен, неверно | 1 072 026 | ~619 c | 22 |
Одиночный агент | Весь проект | На доработку, верно | 89 417 | ~170 c | 1 |
Это был главный негативный результат этого захода: дорогой многоагентный workflow разрешил публиковать код с реальным багом, а одиночный агент нашёл проблему и завернул задачу.
22 агента, миллион токенов, десять минут прогона - и на выходе вся эта армада разрешает катить в продакшн код с реальным багом. [TODO: уточни свою реакцию - что ты почувствовал в этот момент]
А дальше стало ещё обиднее. Workflow не просто «не увидел» баг. Один из его агентов увидел. И поднял. И его заткнули.
Баг был такой. У нас есть обновления прогресса пайплайна в реальном времени. Новый код, который мы ревьюили, подписывал клиента на статусы running и completed. А в другой части системы - в файлах, которые в этой задаче никто не трогал - статусы назывались processing и ready. Фронтенд слушал одни слова, бэкенд говорил другие. На экране прогресс просто замирал.
Один из ревьюеров внутри workflow это поймал и поднял как блокирующую ошибку. Но проверяющий агент - тот, чья работа перепроверять чужие находки - полез искать подтверждение в изменённых файлах. Не нашёл, потому что доказательство лежало в файле, который никто не менял. И по инструкции «если не можешь подтвердить - отклоняй» выкинул находку.
Одиночный агент просто прочитал весь проект. Нашёл файл с реальными статусами. Увидел, что тесты маскируют баг тем же словарём. И завернул задачу.
Я потратил миллион токенов на 22 агента. Выиграл один, который мог прочитать соседний файл.
Что пришлось исправить
После этого я поменял четыре вещи в workflow.
Проблема | Было | Стало |
|---|---|---|
Слепота к соседним файлам | Ревьюеры и проверяющий видят только изменённые файлы | Могут читать зависимости, тесты, связанные модули |
Агрессивная перепроверка | «Если не можешь подтвердить - отклоняй» | Отклонять находку только при доказательстве, что она ложная |
Слабая логика итогового вердикта | Одобрение при нуле блокирующих ошибок | Одобрение только при нуле блокирующих и нуле критических ошибок |
Недостаточная проверка требований | Только технические категории ревью | Добавлена отдельная проверка на соответствие требованиям |
Больше всего на результат повлияла перепроверка. Мы по сути перевернули её логику: проверяющий агент больше не выкидывает находку, если не смог её подтвердить. Он обязан доказать, что находка ложная. Не смог - находка остаётся. Когда агент видит только кусок проекта, это критически важно.
Заход 3. Честное сравнение: оба видят проект
Третий заход - задача крупнее: backend-часть обработки видео, оркестрация, ретраи, интеграция с внешними сервисами. На этот раз оба метода получили доступ к одному и тому же срезу проекта.
Результат:
Метод | Контекст | Вердикт | Токены | Время | Агенты | Находки |
|---|---|---|---|---|---|---|
Одиночный агент | Весь проект | На доработку | 125 927 | ~237 c | 1 | 9 |
Многоагентный workflow | Весь проект | На доработку | 1 951 852 | ~1094 c | 33 | 28 |
Фиксы сработали: ложных одобрений больше не было. Workflow прочитал соседние файлы и поймал проблемы на стыке модулей.
Один пример. Настройки модели для видео и музыки в конфиге существовали, но клиент сервиса их игнорировал и всегда отправлял одну и ту же модель. Часть заявленной функциональности была мёртвой. В прошлом заходе 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 миллиона токенов на аудит, чем откатывать продакшн в три часа ночи.