Несколько AI-агентов, выполняющих задачи параллельно, ещё не образуют автономный процесс разработки. Если человек по-прежнему выбирает каждое следующее поручение, переносит результаты между сессиями и решает, пора ли отправлять работу на проверку, меняется исполнитель, но не способ управления.
Для технического руководителя вопрос шире выбора модели и количества агентов: какие операционные решения можно делегировать, как сохранить контроль над качеством и рисками и по каким показателям оценивать результат. В рассматриваемой схеме человек управляет целями, ограничениями и исключениями, а не каждым шагом исполнения. Это архитектурная цель — не утверждение о доказанной экономии ресурсов.
Практический пример — разработка игры с рабочим названием Ghosts on the Side Job. Это кооперативная 2.5D головоломка-платформер для двух игроков: два призрака, Эдгар и Физз, исследуют ночной отель в стилистике ар-деко, преодолевают препятствия и решают задачи с игровыми предметами. Проект создаётся на Unity; в работе игровые механики, локации и демоверсия. Предмет статьи — не сюжет игры, а организация её разработки. Производственные решения делегированы AI-агентам в пределах заданных полномочий: управляющая сессия Producer ведёт очередь, зависимости и проверки; специалисты получают ограниченные задачи; Founder подключается к контрольным точкам и исключениям. Периодический пересмотр результатов позволяет менять не только конкретные задачи, но и правила производства.
Ниже — устройство такого процесса, конкретные ограничения из studio.toml, контракт TASK.md, проверка границ решений и разбор задачи T-0169. Важная граница: речь об автономности внутри работающей сессии и доступных ресурсов, а не о независимом сервисе, гарантированно продолжающем работу после выключения компьютера или исчерпания лимита модели.
От исполнения команд — к управлению очередью
У обычного AI-ассистента единица взаимодействия — запрос человека. У набора агентов, запускаемых вручную, запросов становится больше: кому передать задачу, когда ждать результат, кто проверит и что делать после проверки. В обоих случаях человек остаётся диспетчером.
Здесь ответственность разделена иначе. Founder задаёт продуктовые цели и пределы допустимых решений. Producer получает право самостоятельно менять порядок работ внутри утверждённого плана, запускать исполнителей, направлять результаты на ревью и выбирать следующую задачу после освобождения слота. Его функция — поддерживать движение производственного процесса без нового поручения на каждом шаге.
По проектной документации сравнивались три варианта: постоянные агенты для каждой специальности, один универсальный Producer и схема «Producer → руководители направлений → временные специалисты». Выбран третий вариант. Постоянные специализированные агенты увеличивали бы стоимость координации и риск расхождения состояний; универсальная сессия совмещала бы планирование, исполнение и самооценку, перегружая контекст.
В принятой схеме:
Участник
Принимает решения
Не вправе делать самостоятельно
Producer
Приоритеты, допустимый следующий запуск, маршрутизация, статус, эскалация
Подменять утверждение Founder на контрольной точке
Creative Director
Художественное ревью в рамках утверждённых референсов и библии
Менять канон персонажей без согласования
Technical Director
Техническая реализация, тесты и архитектурные решения в согласованных пределах
Самовольно выходить за технические и продуктовые ограничения
Production Director
Пайплайн создания материалов, приёмка ассетов и производственные QA-процедуры
Утверждать субъективные изменения художественного направления вместо Creative Director
Временный исполнитель
Конкретные технические шаги в рамках брифа
Расширять задачу или область изменений
Разделение ролей — логический контракт, а не защита уровня операционной системы. Текстовая инструкция «не изменять чужие файлы» не заменяет прав доступа, изоляции процессов и настроек инструментов.
С точки зрения управления здесь разделены три уровня ответственности. Операционные решения — выбор следующей задачи, назначение исполнителя, организация ревью — остаются у Producer. Изменения правил процесса оформляются через пересмотр регламента и журнал решений, чтобы следующая сессия работала по обновлённой версии. Стратегические и необратимые решения, включая изменение продукта, существенных ограничений и утверждение контрольных точек, передаются Founder. Тем самым участие человека концентрируется на границах полномочий и качестве результата, а не на ручной диспетчеризации.
Почему состояние вынесено из контекста модели
Длинная управляющая сессия быстро начинает содержать детали несвязанных задач: обсуждения референсов, настройки Unity, результаты тестов, исправления UI и исторические решения. Чем больше в ней операционных подробностей, тем сложнее отличить актуальное состояние от устаревшего.
Поэтому Producer не должен выполнять производственную работу. Под неё создаются отдельные исполнители, а работа передаётся через файловый контракт — TASK.md. Сокращённая структура из плана реализации:
# T-NNNN · Статус: запланированаВедущий: Исполнитель: Ревьюер: Срок: Лимит: Бриф: Цель: Входные файлы: Критерии готовности: Ограничения: Можно писать в: Исполнителю не требуется история всех обсуждений проекта. Ему нужны входные материалы, полномочия, критерии готовности и место для результата. Руководитель проверяет выполненную работу в своей области, отдельная QA-стадия проверяет поведение и соответствие требованиям. Исполнитель не принимает собственный результат.
Отсюда следует важная оговорка: разделение уменьшает состав контекста, передаваемого каждому исполнителю, но не гарантирует меньшую суммарную стоимость токенов. Одни и те же правила приходится загружать в новые сессии; появляются расходы на делегирование и ревью. Экономический эффект без измерений утверждать нельзя.
Файлы как источник состояния
Рабочие документы распределены по назначению. STATUS.md содержит актуальную сводку; BACKLOG.md — отложенную работу; FOUNDER_QUEUE.md — открытые вопросы; DECISIONS.md — принятые решения с основаниями и затронутыми документами. Папки задач предназначены для брифов, результатов и передачи незавершённой работы. Репозитории и Git фиксируют изменения; двоичные материалы игры хранятся отдельно по правилам пайплайна.
В CLAUDE.md прямо задано: чат и память агента не считаются источником истины. Решение Founder должно попасть в DECISIONS.md, затронутые документы обновляются, а изменения коммитятся. При следующем запуске Producer сверяет STATUS.md с Git и задачами, прежде чем продолжать работу.
Здесь важна не сама технология Markdown. Важен внешний, проверяемый и переносимый формат состояния, который не исчезает вместе с контекстом конкретной сессии.
Планирование без ручного запуска каждой задачи
В CLAUDE.md закреплён принцип task pull — самостоятельный выбор следующей работы: при закрытии задачи, освобождении производственного слота и после стартовой сверки Producer должен брать следующую доступную задачу без нового запроса Founder. Приоритет у ревью; новая задача допускается, только если её зависимости выполнены и нет блокирующей карточки решения.
Очередь не сводится к одному полю priority. Регламент различает фичи, критические дефекты и полировку; в трёх основных производственных слотах предусмотрены два для фич и один для исправлений. Для критических дефектов существует специальное исключение. При конфликте за тяжёлый ресурс приоритет также определён правилами. Это политика распределения работы, описанная в файлах, а не доказательство существования отдельного автономного планировщика.
Конфигурация задаёт верхние пределы:
[rules]wip_production = 3rework_rounds = 3founder_open_cards = 5founder_open_actions = 3founder_open_packs = 1Первые два параметра ограничивают объём незавершённой производственной работы и число раундов доработки перед эскалацией. Остальные три — нагрузку на человека: одновременно не более пяти открытых решений, трёх ручных действий и одного пакета контрольной точки.
В CLAUDE.md описана и реакция на заполнение очереди: сходные вопросы объединяются, обратимые закрываются по допустимому правилу, а новая ручная операция может быть отложена в STATUS.md. Ожидание ответа Founder блокирует только зависимую ветку: другие доступные задачи продолжают движение.
Очередь работ в дашборде: задачи в производстве, QA и блокировке
Дашборд производственного процесса. Надпись «В работе · 7» относится к общей группе карточек, а не к семи одновременно запущенным производственным агентам: в неё включены задачи разных состояний, в том числе QA и блокировки.
Ограничения полезны ровно настолько, насколько хорошо соблюдаются. Наличие чисел в TOML и текста в CLAUDE.md ещё не доказывает отсутствие превышений при исполнении; для этого нужны фактические проверки состояния и журнал переходов.
Полномочия как данные, а не только текст промпта
Автономность требует явного ответа на вопрос: какое решение допустимо принять без человека? Руководители действуют внутри утверждённых художественных и технических правил. Канон, превышение бюджета, публикации и контрольные точки остаются за Founder.
Для отдельных решений предусмотрен класс обратимое: если карточка содержит рекомендацию и срок истёк, регламент допускает выполнение рекомендуемого варианта с записью результата. Для остальных классов такой механизм не применяется.
Это правило описано не только в инструкции. В плане реализации, а не в подтверждённом текущем исполняемом файле, приведена проверка карточки FOUNDER_QUEUE.md:
cls = card.fields.get("Класс", "")default = card.fields.get("По умолчанию", "")if cls and cls != "обратимое" and default and not default.startswith("нет"): errors.append( f"FOUNDER_QUEUE.md {card.id}: only «обратимое» cards may have a default (D-012)" )Там же описан негативный тест: карточке Q-001 с классом канон присвоено действие по умолчанию делаем вариант 1. Ожидаемая реакция — ошибка линтера. Сокращённый фрагмент теста из того же плана:
card("Q-001", "2026-10-30 12:00", cls="канон", default="делаем вариант 1")# ... запись тестовой карточки и вызов lint ...self.assertIn( "FOUNDER_QUEUE.md Q-001: only «обратимое» cards may have a default (D-012)", errors,)В спецификации проверяются также обязательные поля, допустимые классы и формат срока. Сценарий теста показывает ожидаемое поведение, но не подтверждает, что он был успешно запущен на текущей версии системы.
Это пример связки «конфигурация → правило → проверка → эскалация». Программа способна отклонить структурно недопустимую карточку. Но она не определяет смысл решения: если агент ошибочно назовёт изменение канона «обратимым», одна проверка полей не обнаружит подмену. По той же причине проверка существования файлов результатов не подтверждает художественного качества или правильности реализации.
В предоставленном архиве есть CLAUDE.md со ссылкой на tools/lint_office.py и код из плана реализации, но нет самого актуального tools/lint_office.py и результатов его запуска. Следовательно, приведённый пример показывает запроектированный механизм защиты, а не независимую проверку конкретной версии рантайма.
Кейс T-0169: принять способ производства, а не незавершённую локацию
Наиболее показательный участок процесса — задача T-0169 по багажному залу. Здесь хорошо видна разница между выполнением работы, оценкой результата и изменением самого пайплайна.
1. Проблема обнаружилась на границе концепта и игрового кадра
Рабочий журнал за 8 ноября показывает, как уточняли требования к багажному залу. Сначала согласовали компоновку игровых элементов: расположение колонн, окон, рычага и других деталей сцены. Но сборка окружения из уже имеющихся игровых объектов не давала требуемого визуального соответствия эталонному изображению. Поэтому способ оформления изменили: основой должны стать графические слои, подготовленные по утверждённому референсу, а не повторное использование существующих объектов. Затем уточнили приоритеты двух источников: референс определяет внешний вид пола, ямы, стрелок разгона тележки, колонн, стен и рычага; согласованная компоновка определяет расположение игровых элементов. Отдельно сохранили знак, картины и вид города за окнами, уже присутствовавшие в игре.
Это не просто ещё один круг правок картинки. Несоответствие результата ожиданиям привело к уточнению контракта между художественным ориентиром и технологией сборки.
2. Процесс разделили на две приёмки
В том же журнале закреплён двухэтапный порядок приёмки оформления локаций. Сначала утверждается визуальный референс, затем студия показывает на одной позиции игровой камеры пробу выбранной технологии — из каких слоёв собран кадр, как устроены глубина и освещение и насколько результат соответствует эталону. Только после отдельного одобрения способа вся локация оформляется по этой методике. Финальная приёмка готового пространства проводится позже.
Это устраняет распространённую подмену понятий: «способ приблизился к референсу» не равно «локация готова». Для пробы достаточно доказать, что выбранный способ может дать нужный кадр; полная геометрия, проходимость и производительность принимаются в другом контуре проверок.
3. Решение сформулировано в отдельной карточке
В интерфейсе задачи T-0169 блок «Что есть» содержит факт подготовки пробы у рычага, ссылку на лист сравнения и конкретные отличия. Блок «Что принять» спрашивает не о том, нравится ли изображение вообще, а разрешает ли результат собирать остальной зал по той же методике.
Карточка T-0169 с блоками «Что есть» и «Что принять»
Задача T-0169 в дашборде: в карточке разделены наблюдаемое состояние, материалы проверки и требуемое решение Founder.
Для проверки подготовлен лист: игровой кадр сопоставлен с утверждённым ориентиром; ниже показаны крупные планы рычага. Это позволяет обсуждать расхождения в камере, свете и отдельных элементах, а не обмениваться общими оценками «лучше» или «хуже».
Проба методики багажного зала: игровой кадр, эталон и детали
Материал для приёмки метода. На этом этапе рассматривается доказательство работоспособности способа сборки, а не завершённая локация.
4. Контрольная точка оставила измеримое требование для следующего этапа
На контрольной точке 9 ноября 2026 года Founder одобрил пробы способа оформления сразу трёх локаций — багажного зала, шахты лифта и кладовой, — но добавил обязательное условие: пол должен восприниматься как единый материал по всей длине. На границах изображения-эталона, дорисованного продолжения и игровых слоёв не должен появляться участок пола с иной фактурой или цветом.
Для T-0169 это означает: следующий этап — производство полного зала с учётом нового условия, а не закрытие всей локации. STATUS.md за 9 ноября фиксирует переход к работам над залом целиком. Доказательства финальной приёмки этой локации в предоставленном наборе материалов нет.
Что подтверждает кейс: существует прослеживаемая цепочка «референс → проба → материалы сравнения → решение Founder → уточнённые требования к продолжению». Чего он не подтверждает: сокращение стоимости разработки, производительность готовой сцены или выполнение всех требований к локации.
Ревью результата должно менять и процесс
Независимое ревью полезно, но не устраняет систематическую ошибку, если каждый новый исполнитель получает тот же неудачный бриф. Поэтому предусмотрен второй уровень обратной связи: разбор не только результата, но и маршрута, который к нему привёл.
В проектной спецификации заложен еженедельный пересмотр производственного процесса. Ошибочное правило предлагается исправлять в производственных инструкциях и связывать изменение с записью в DECISIONS.md. Это плановый механизм, однако сам факт проведения каждого еженедельного ревью по предоставленному архиву не подтверждён.
Зато конкретная корректировка подтверждается журналом: способ переноса визуального эталона теперь проверяется и утверждается до масштабирования на всю локацию. Для багажного зала отказались от сборки преимущественно из имеющихся объектов в пользу графических слоёв, а затем уточнили, что именно должно визуально совпадать с референсом. Это наблюдаемое изменение регламента и требований на основе результата, а не утверждение о том, что модель «самообучилась».
Механизм улучшения здесь человечески проверяемый: выявить повторяющееся отклонение, изменить входные требования или правило проверки, записать основание, затем оценивать новые задачи по обновлённому регламенту. Эффективность изменения требует отдельного сравнения результатов до и после.
Перезапуск и возможная смена модели
Управляющая сессия не должна быть единственным местом хранения состояния. Согласно CLAUDE.md, на старте и после сжатия контекста загружается сводка, затем Producer сверяет её с Git, STATUS.md и папками задач. Для незавершённой работы предусмотрен HANDOFF.md с выполненными шагами, оставшейся частью, веткой и коммитами. Сессия может восстановить работу после остановки, опираясь на записанные артефакты.
Переносимость при этом имеет несколько уровней:
Что переносится
Что остаётся проверить
Брифы и критерии готовности в Markdown
Одинаково ли модели трактуют требования
Файлы результатов, история решений и Git-коммиты
Доступ к тем же репозиториям и версиям
Разделение ролей и правила эскалации
Поддержку инструментов, agents, skills, hooks и разрешений
Открытые задачи после остановки сессии
Корректность восстановления и отсутствие повторного исполнения
Следовательно, состояние и контракты не привязаны принципиально к одной модели, но автоматическая замена Claude Code на другой инструмент пока не доказана. Нужны адаптеры вызовов и отдельные испытания совместимости, а не только копирование файлов с инструкциями.
Цена делегированной автономности
У отдельной управляющей роли есть стоимость: вызовы модели на планирование, повторная загрузка контекста каждым исполнителем, ревью, QA, повторные попытки и хранение промежуточных результатов. При небольшом объёме работ один агент может оказаться дешевле и быстрее. Кроме того, «независимые» ревьюеры могут воспроизводить сходные ошибки, а неверная классификация решения оставляет риск обхода эскалации даже при структурно корректной карточке.
Есть и инфраструктурные ограничения. В CLAUDE.md отдельно указан единственный тяжёлый процесс на доступном Mac: Unity или один рендер Blender. Ночная работа предусмотрена только по команде Founder. Лимиты подписки, остановка сессии и отсутствие доступных задач могут остановить цикл; никакая конфигурация задач не отменяет этих ограничений.
Для руководителя разработки количество агентов само по себе не является показателем эффективности. Единица сравнения — принятый результат с учётом времени человека, затрат на координацию и качества. Для оценки пригодности подхода можно использовать следующие метрики:
Измерение
Что считать
На какой вопрос отвечает
Автономность
Доля задач, прошедших от назначения до ревью без ручной диспетчеризации
Насколько процесс перестал зависеть от постоянных поручений?
Участие человека
Минуты Founder на одну принятую задачу; число и причины эскалаций
Сокращается ли операционная нагрузка без потери контроля?
Предсказуемость
Cycle time, в том числе медиана и 90-й перцентиль
Насколько стабильно система доводит работу до приёмки?
Качество
Доля возвратов с ревью, повторные дефекты и число раундов доработки
Не покупается ли автономность ростом переделок?
Экономика
Суммарные затраты на модели, инструменты, QA и координацию на принятый результат
Окупается ли разделение ролей по сравнению с более простой схемой?
Такие показатели следует сравнивать на сопоставимых типах задач и при одинаковых критериях приёмки. В представленном кейсе измерения «до/после» ещё не собраны, поэтому утверждать снижение расходов или ускорение производства нельзя. Для управленческого решения о масштабировании архитектуры необходима именно такая проверка, а не демонстрация числа запущенных агентов.
Вывод: автономность — это границы решений и проверяемые передачи
В этом подходе агентам переданы не только поручения, но и право выбирать следующий допустимый шаг, организовывать проверку и закрывать решения в установленных пределах. Система становится менее зависимой от постоянных подсказок Founder не благодаря числу ролей, а благодаря нескольким связанным механизмам: ограниченной очереди, файловому контракту задачи, явным классам решений, внешнему состоянию и контрольным точкам с материалами для приёмки.
Кейс T-0169 показывает практическую границу такого управления. Студия подготовила пробу, оформила решение и получила условие для следующего этапа; при этом право утвердить визуальную методику осталось у человека. Для руководителя ценность такой схемы определяется не числом агентов, а переносом повторяемых решений в регламент без потери управляемости. Следующий инженерный шаг — измерить, какой ценой достигается эта автономность и какие проверки действительно предотвращают ошибки, а не только формально фиксируют соблюдение правил.
Источник: habr.com