Fareed Khan описал, как собрал из субагентов Claude Code инженерную организацию (оригинал статьи): оркестратор в роли staff-инженера, ростер специализированных ролей, «employee handbook» из четырнадцати с лишним скиллов и жёсткие гейты на каждом переходе пайплайна design → plan → execute → review → ship. Я гоняю собственные субагентные команды — четыре роли, обязательное параллельное ревью и тест-контроль, изоляция в git worktrees, лимит в пять итераций на цикл правок — и читал статью как чужой production-сетап, а не как манифест. Дальше по пунктам: с чем согласен, что забираю, чему не верю.
Изоляция контекста — ядро, и оно работает
Центральный тезис: субагент не наследует историю сессии, а получает ровно то, что нужно для задачи. Автор называет это защитой от «уставшего senior», который после часа работы путает требования соседних фич. Мой опыт это подтверждает: в четырёхрольной команде ревьюер, не видевший переписку оркестратора с разработчиком, находит проблемы, которые «замыленный» общий контекст стабильно пропускает. Свежий контекст на роль — самый дешёвый способ поднять качество мультиагентной работы, дешевле любых промпт-ухищрений. Во что эта изоляция обходится по токенам — отдельная тема.
Verification-before-completion — забираю как правило
Формула автора: «заявлять о завершении работы без верификации — это нечестность, а не эффективность». К ней прилагается таблица «утверждение → обязательное доказательство»: «тесты прошли» означает свежий вывод команды в этом же сообщении, а не «должны пройти» и не «проходили вчера». У меня эта дисциплина жила как привычка, но нигде не была зафиксирована правилом — а привычка под давлением дедлайна проседает первой. Забираю формулировку в свои командные шаблоны почти дословно.
TDD для документации — лучшая идея статьи
Скилл не считается готовым, пока не прошёл цикл RED/GREEN на свежем субагенте: сначала фиксируется, что без скилла агент под давлением нарушает правило, потом — что со скиллом соблюдает. Документацию так не тестирует почти никто, хотя скиллы — это код, который исполняет LLM. Отдельно точное замечание: description скилла должен отвечать на вопрос «когда применять», а не «что делает» — иначе модель читает описание, решает, что поняла суть, и не открывает полный текст. Проверил на своих скиллах: половина описаний написана неправильно именно в этом смысле.
1% Rule — красиво, но не верю
Правило «если есть хоть один процент вероятности, что скилл применим, агент обязан его вызвать» защищает процесс от эрозии через рационализации («это же просто вопрос»). Проблема в цене: тотальная обязательность превращает каждый мелкий вопрос в процессию из чтения скиллов. Дешевле маршрутизировать: скилл срабатывает по типу задачи, а не по вероятности применимости. Эрозию процесса надёжнее ловить редким аудитом сессий, чем налогом на каждое действие.
Delete Rule — тоже пропускаю
Требование удалять весь код, написанный до теста, — без «оставить как референс» — заявлено как Iron Law. Как манифест понятно: tests-after проверяют то, что реализовано, tests-first — то, что должно быть реализовано. Как ежедневная практика — расточительно: выбрасывать работающий черновик, чтобы переписать его же по тесту, оправдано в учебном сценарии и почти никогда — в реальной задаче с бюджетом.
Вывод
Жёсткий каркас с iron laws оправдан там, где несколько агентов работают долго и без присмотра: предсказуемость стоит дороже токенов. Для персонального сетапа выгоднее забрать три вещи — изоляцию контекста на роль, verification-gate перед любым «готово» и RED/GREEN-тест для собственных скиллов — и не тащить каркас целиком. Автор при этом спорит честно: система выложена в открытый репозиторий, и несогласие проверяется экспериментом, а не риторикой. Что происходит с этим каркасом, когда правил становится много, — тюнинг на масштабе.