| title | Автономная продуктовая компания на базе Claude Code |
|---|---|
| subtitle | Посадка оркестраторской модели: владелец остаётся продуктом, агент ведёт производство |
| version | 1.0 |
| date | 2026-07-25 |
Парный документ к методичке «Автономная продуктовая компания на базе Codex». Методология одна; здесь — её посадка на архитектуру и инструменты Claude Code. И в отличие от «сделайте сами» — эта посадка уже реализована и опубликована: Claude Code Starter v6.3.0 «Orchestrator Model».
Версия 1.0 · 25 июля 2026
Базовая методичка (по ссылке выше) описывает провайдер-агностик ядро: роли и контуры, task charter, критерии полноты ТЗ, quality gates, четыре статуса доказательств, стоп-правила. Всё это верно для любого сильного агента.
Но посадка на конкретный инструмент — не деталь. У Codex и Claude Code разная родная архитектура оркестрации, и попытка воспроизвести чужую форму буквально даёт худший результат, чем перенос намерения на родные примитивы.
| Codex | Claude Code | |
|---|---|---|
| Родная модель | менеджер поднимает сессии; его копии внутри сессий поднимают своих субагентов (рекурсия на уровне сессий) | один оркестратор + флот подчинённых воркеров (субагенты, изолированные worktree, программные workflows) |
| Куда садится методология | управляющие файлы AGENTS.md | конституция CLAUDE.md + слой правил + сохранённые workflows + allowlist полномочий |
| Изоляция параллельных писателей | конвенция + владение файлами | физическая: каждый пишущий воркер в своём git-worktree |
| Детерминированная оркестрация | план оркестратора | workflow-скрипт: граф работ кодом (pipeline/parallel), бюджет токенов как жёсткий потолок, resume по журналу |
| Непрерывность между сессиями | контекст менеджера | двух-осевая память проекта + handoff-протокол (см. §6) |
Вывод, который сэкономит вам недели: не воспроизводите архитектуру другого инструмента — воспроизводите свой workflow. Цель одна: вы остаётесь продуктом, агент ведёт производство. Чем он его ведёт — сессиями, субагентами или «филиппинскими воркерами» — вопрос посадки, не методологии.
Стандартная ошибка при работе с Claude Code — плоская модель: агент как «менеджер проекта», а владелец при этом сам открывает параллельные сессии, сам переносит между ними контекст, сам интегрирует результаты. То есть владелец остаётся диспетчером и шиной данных своей же виртуальной команды.
Оркестраторская модель делает уровней три:
ВЛАДЕЛЕЦ продукт / методолог / архитектор абстракций — НАД производством.
Даёт: цель + границы полномочий + ревью результата + решения на стоп-точках.
НЕ делает: не поднимает воркеров, не носит контекст, не дирижирует.
│
▼
ОРКЕСТРАТОР агент в ведущей сессии — архитектор + главный девелопер.
Держит карту швов и контрактов; режет работу на потоки; САМ поднимает
воркеров; интегрирует по зависимостям; независимо верифицирует; коммитит.
Будит владельца ТОЛЬКО на стоп-точках.
│
▼
ВОРКЕРЫ эфемерные исполнители в СВОИХ свежих контекстах.
Владельцу невидимы. Носят территорию, возвращают выводы.
Ключевой сдвиг: шаг «владелец поднимает сессию и вставляет в неё handoff» схлопывается в «оркестратор поднимает воркера и выдаёт ему charter». Handoff из ручного моста, который вы переносили между окнами, превращается во внутренний контракт, который агент выдаёт воркерам сам.
Стоп-точки, на которых агент обязан остановиться и спросить, — те же, что в базовой методичке: production deploy, внешние публикации и сообщения, платежи, необратимые действия, удаление или перезапись рантайм-данных. Это не ограничение автономности — это контур, внутри которого автономность вообще легитимна.
Практическая карта для Claude Code. Правило: побеждает самый дешёвый работающий примитив — не начинайте с тяжёлого.
| Намерение | Примитив Claude Code | Заметка |
|---|---|---|
| Делегировать поток работы по ходу | Субагент (Agent tool, foreground/background) | Свежий контекст; результат возвращается оркестратору; веер «читателей» под разными углами экономит контекст ведущей сессии |
| Детерминированный граф работ с интеграцией | Workflow (скрипт: pipeline / parallel / фазы) | Ядро производства: сохраняется под именем, бюджет токенов — жёсткий потолок, упавший прогон возобновляется по журналу |
| Запретить двух писателей в общий файл/контракт | Worktree-изоляция | Каждый пишущий воркер в своём git-worktree — конфликт физически невозможен, а не «запрещён дисциплиной» |
| Вынести воркера в облако | Remote-агент | Ближе всего к «отдельной сессии»; всегда фоном |
| «Компания работает непрерывно» | Cron / scheduled runs | Свежие автономные прогоны по расписанию или триггеру |
| Реально отдельные параллельные сессии | session-management | Крайняя ступень; клей — messaging, не автоматика |
Два усиления относительно «чек-листной» методологии, которые даёт именно программная оркестрация:
- Гейты из пожеланий становятся механизмами. «Не допускайте двух писателей в один файл» — в Codex-методичке это правило; в Claude Code это свойство рантайма (worktree). «Контролируйте бюджет» — здесь это жёсткий потолок токенов в workflow, при достижении которого новые воркеры просто не поднимаются.
- Разделение суждения и бухгалтерии. Внутри производственного графа модель-воркер делает только суждение (что построить, релевантно ли, как назвать), а учёт — порядок интеграции, дедупликация, статусы, агрегация — делает детерминированный код workflow-скрипта. Гейты ловят ошибку постфактум; это разделение делает целый класс ошибок структурно невозможным.
Без изменений относительно базовой методички — эти принципы переносятся один в один, и именно они не дают автономности выродиться в «агент бодро рапортует»:
- Каждое доказательство имеет ровно один статус: passed / failed / not_run / inconclusive. Последние два не переписываются оптимистичной формулировкой. «Не проверено» — это статус, а не повод сказать «должно работать».
- Верификатор — независимый воркер. Он проходит сценарии против реального результата, фиксирует наблюдаемое и не чинит собственные находки. Проверять фикс той же логикой, которой был сделан баг, — способ воспроизвести баг и назвать это подтверждением.
- Отчёт верификатора различает: подтверждённый дефект / сознательную продуктовую границу / непроверенное состояние.
В Claude Code это оформляется буквально: в производственном workflow стадия Verify — отдельный агент с отдельным промптом и схемой ответа, в которой статусы перечислены enum'ом. Выдумать пятый статус «почти работает» он не может структурно.
Всё вышеописанное — не концепт, а отгруженный релиз. Claude Code Starter — открытый фреймворк-«управляющая среда» для проектов, где основной агент — Claude Code. С версии 6.3.0 оркестраторская модель — его режим по умолчанию.
Что поставляется:
orchestration-model.md— концептуальный документ посадки: переносимый свод из 12 принципов (O1–O12). Кто что делает (владелец/оркестратор/воркеры), charter как единица управления воркером, один писатель на контракт через worktree, четыре статуса доказательств, границы полномочий, карта «намерение → примитив», когда веером нельзя (авторски-цельную работу не параллелят), и путь внедрения в живой проект.- Правила
autonomyиdelegationэволюционированы под трёхуровневую модель: «не дёргай владельца» теперь явно покрывает весь производственный слой — поднятие воркеров, интеграцию, коммиты. - Скилл
/handoff— теперь в поставке: типизированные по ролям handoff'ы сессий (orchestrator / executor / reviewer / owner), дисциплина заземления фактов в код (не в самоописание проекта) и протокол приёмки — новая сессия сначала верифицирует понимание, потом работает. - Двух-осевая память проекта (была с v6.2): контракты (
ARCHITECTURE,INVARIANTS, методологии) ⟂ состояние (SNAPSHOT,BACKLOG). Это несущая конструкция непрерывности — см. §6.
Установка (одним файлом в корень проекта):
curl -fsSL https://github.com/alexeykrol/claude-code-starter/releases/download/v6.3.0/init-project.sh -o init-project.sh
bash init-project.shИли глобальным слоем ~/.claude/ — тогда модель действует во всех проектах сразу (bash scripts/install-global.sh из checkout'а). Все изменения аддитивны: существующие кастомизированные файлы не перезаписываются.
Полные ноуты релиза: release-notes/v6.3.0.md · CHANGELOG
Автономность отвечает на вопрос «кто что делает». Второй, не менее важный вопрос: что переживает смену сессий? Контекстное окно ведущей сессии конечно; сессии умирают, сжимаются, начинаются заново. Если каждая новая сессия стартует с нуля — автономность обнуляется вместе с ней.
Наивное решение — «файл контекста», в который пишется всё, — не работает: такой файл растёт неограниченно и топит ровно ту сессию, которую должен спасать. Континуитет-файл, растущий без предела, — это баг, а не архив.
Рабочее решение — три слоя:
- Раздельная ограниченная память: контракты (меняются редко) отдельно от состояния (меняется каждую сессию). Новая сессия читает компактный слой состояния, а не всю историю.
- Handoff как тонкий указатель, а не как дамп: что сделано, что активно, следующий безопасный шаг — и команды, которыми новая сессия сама проверит эти факты по коду. Метафайлы — карта; истина — территория.
- Durability через git: частые атомарные коммиты + журналы workflow-прогонов. Смерть сессии оркестратора не стирает производство — оно восстанавливается из закоммиченного.
Поэтому в этой модели частые коммиты — не гигиена, а несущий элемент архитектуры.
Если у вас уже есть работающий процесс (в том числе ручная модель, где вы сами клеите сессии handoff'ами) — не сносите его. В него вбиты месяцы; риск регресса при переписи выше ценности чистоты.
Путь внедрения:
- Зафиксируйте ориентир: владелец над оркестратором; воркеров поднимает агент; handoff → charter.
- Сделайте gap-анализ: где сегодня вы руками открываете сессии / носите контекст / интегрируете — это долг, а не контракт.
- Переносите по одному потоку: существующие роли оставляете (они верны), забираете у себя только шаг «поднять воркера и склеить результат».
- Каждый перенос закрепляйте правилом и коммитом. Не блокируйте живой проект большой переписью.
Это ровно та же логика, по которой внедряют агентские пайплайны в боевое легаси: North Star + дорожная карта, а не революция.
Чтобы не продавать лишнего:
- Оркестратор — единая точка контекста. Смягчается тем, что воркеры держат территорию в своих контекстах и возвращают выводы (оркестратор держит карту), плюс слоем непрерывности из §6 — но потолок существует у любой сегодняшней архитектуры.
- Владелец меняет пер-сессионный контроль на «не быть клеем». Отдельных воркеров вы не видите — вы видите результат, доказательства и стоп-точки. Это осознанный размен.
- Модель обкатывается в поле. v6.3.0 — первая версия посадки; ошибки внедрения ожидаемы, фиксируются и дистиллируются обратно в свод. Это нормальный цикл: полевые кейсы → правки принципов → следующая версия (так же родились v6.2.x — из разборов реальных регрессий, см. FRAMEWORK-CASE-ONBOARDING.md).
Формула та же, что в базовой методичке:
Роль человека = продуктовая цель + приоритеты + архитектурные и рискованные решения. Роль агента = декомпозиция + постановка задач + координация воркеров + владение кодом + интеграция + проверки + непрерывность.
Разница посадок — в том, чем это обеспечено. В Claude Code методология не остаётся текстом, который агент «читает и старается соблюдать»: один писатель на контракт обеспечен worktree, бюджет — жёстким потолком, статусы доказательств — схемой ответа, непрерывность — раздельной памятью и handoff-протоколом, а всё вместе — фреймворком, который ставится одной командой.
- Базовая методичка (ядро, Codex-посадка): «Автономная продуктовая компания на базе Codex»
- Релиз посадки для Claude Code: Claude Code Starter v6.3.0 «Orchestrator Model»
- Концептуальный документ внедрения:
orchestration-model.md(принципы O1–O12 + карта примитивов + путь для легаси) - Полные ноуты релиза: release-notes/v6.3.0.md
- Репозиторий фреймворка: github.com/alexeykrol/claude-code-starter