Автономный SDLC на AI-агентах: очередь задач, границы решений и контроль результата

Несколько 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. Тем самым участие человека концентрируется на границах полномочий и качестве результата, а не на ручной диспетчеризации.

Почему состояние вынесено из контекста модели

Длинная управляющая сессия быстро начинает содержать детали несвязанных задач: обсуждения референсов, настройки Unity, результаты тестов, исправления UI и исторические решения. Чем больше в ней операционных подробностей, тем сложнее отличить актуальное состояние от устаревшего.

Поэтому Producer не должен выполнять производственную работу. Под неё создаются отдельные исполнители, а работа передаётся через файловый контракт — TASK.md. Сокращённая структура из плана реализации:

# T-NNNN · <название>
Статус: запланирована
Ведущий: <CD | TD | PD>
Исполнитель: <специалист>
Ревьюер: <CD | TD | PD>
Срок: <дата>
Лимит: <сумма | без затрат>

Бриф:
  Цель: <один ожидаемый результат>
  Входные файлы: <пути>
  Критерии готовности: <проверяемые условия>
  Ограничения: <что нельзя менять>
  Можно писать в: <разрешённые папки>

Исполнителю не требуется история всех обсуждений проекта. Ему нужны входные материалы, полномочия, критерии готовности и место для результата. Руководитель проверяет выполненную работу в своей области, отдельная 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 = 3
rework_rounds = 3
founder_open_cards = 5
founder_open_actions = 3
founder_open_packs = 1

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

В CLAUDE.md описана и реакция на заполнение очереди: сходные вопросы объединяются, обратимые закрываются по допустимому правилу, а новая ручная операция может быть отложена в STATUS.md. Ожидание ответа Founder блокирует только зависимую ветку: другие доступные задачи продолжают движение.

Дашборд производственного процесса. Надпись «В работе · 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 в дашборде: в карточке разделены наблюдаемое состояние, материалы проверки и требуемое решение Founder.

Для проверки подготовлен лист: игровой кадр сопоставлен с утверждённым ориентиром; ниже показаны крупные планы рычага. Это позволяет обсуждать расхождения в камере, свете и отдельных элементах, а не обмениваться общими оценками «лучше» или «хуже».

Материал для приёмки метода. На этом этапе рассматривается доказательство работоспособности способа сборки, а не завершённая локация.

4. Контрольная точка оставила измеримое требование для следующего этапа

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

Для T-0169 это означает: следующий этап — производство полного зала с учётом нового условия, а не закрытие всей локации. STATUS.md за 9 ноября фиксирует переход к работам над залом целиком. Доказательства финальной приёмки этой локации в предоставленном наборе материалов нет.

Что подтверждает кейс: существует прослеживаемая цепочка «референс → проба → материалы сравнения → решение Founder → уточнённые требования к продолжению». Чего он не подтверждает: сокращение стоимости разработки, производительность готовой сцены или выполнение всех требований к локации.

Ревью результата должно менять и процесс

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

В проектной спецификации заложен еженедельный пересмотр производственного процесса. Ошибочное правило предлагается исправлять в производственных инструкциях и связывать изменение с записью в DECISIONS.md. Это плановый механизм, однако сам факт проведения каждого еженедельного ревью по предоставленному архиву не подтверждён.

Зато конкретная корректировка подтверждается журналом: способ переноса визуального эталона теперь проверяется и утверждается до масштабирования на всю локацию. Для багажного зала отказались от сборки преимущественно из имеющихся объектов в пользу графических слоёв, а затем уточнили, что именно должно визуально совпадать с референсом. Это наблюдаемое изменение регламента и требований на основе результата, а не утверждение о том, что модель «самообучилась».

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

Перезапуск и возможная смена модели

Управляющая сессия не должна быть единственным местом хранения состояния. Согласно CLAUDE.md, на старте и после сжатия контекста загружается сводка, затем Producer сверяет её с Git, STATUS.md и папками задач. Для незавершённой работы предусмотрен HANDOFF.md с выполненными шагами, оставшейся частью, веткой и коммитами. Сессия может восстановить работу после остановки, опираясь на записанные артефакты.

Переносимость при этом имеет несколько уровней:

Следовательно, состояние и контракты не привязаны принципиально к одной модели, но автоматическая замена Claude Code на другой инструмент пока не доказана. Нужны адаптеры вызовов и отдельные испытания совместимости, а не только копирование файлов с инструкциями.

Цена делегированной автономности

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

Есть и инфраструктурные ограничения. В CLAUDE.md отдельно указан единственный тяжёлый процесс на доступном Mac: Unity или один рендер Blender. Ночная работа предусмотрена только по команде Founder. Лимиты подписки, остановка сессии и отсутствие доступных задач могут остановить цикл; никакая конфигурация задач не отменяет этих ограничений.

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

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

Вывод: автономность — это границы решений и проверяемые передачи

В этом подходе агентам переданы не только поручения, но и право выбирать следующий допустимый шаг, организовывать проверку и закрывать решения в установленных пределах. Система становится менее зависимой от постоянных подсказок Founder не благодаря числу ролей, а благодаря нескольким связанным механизмам: ограниченной очереди, файловому контракту задачи, явным классам решений, внешнему состоянию и контрольным точкам с материалами для приёмки.

Кейс T-0169 показывает практическую границу такого управления. Студия подготовила пробу, оформила решение и получила условие для следующего этапа; при этом право утвердить визуальную методику осталось у человека. Для руководителя ценность такой схемы определяется не числом агентов, а переносом повторяемых решений в регламент без потери управляемости. Следующий инженерный шаг — измерить, какой ценой достигается эта автономность и какие проверки действительно предотвращают ошибки, а не только формально фиксируют соблюдение правил.