Предистория:
Мне очень нравится Claude Code. Я работаю с ним почти восемь месяцев, но есть направление, которое хочу улучшить. Сейчас он в большей степени следует философии парного программирования, а мне нужно, чтобы он работал более автономно — примерно как ты сейчас. Я ставлю задачу, ты начинаешь её исследовать, находишь проблемы, пробуешь разные решения, выбираешь оптимальное, реализуешь его и достигаешь результата. Я сформулировал задачу достаточно свободно, но ты её решил. Я хочу добиться такого же результата, когда создаю приложения с Claude Code. Не хочу вникать в технические детали, разработку, тестирование или деплой — хочу только формулировать пожелания. Я могу подробно сформулировать или отвечать на бесконечное количество вопросов в разумных пределах.
С Claude Code мы проходим фазу Discovery, результатом которой является полноценное техническое задание, позволяющее ему полностью автономно выполнять задачи при условии получения всех необходимых доступов. Я хочу реализовать мечту: потратить час-два на прояснение деталей с точки зрения продукта и пользовательского опыта. Это и есть полноценная абстракция высокого порядка, где неважно, какая архитектура «под капотом», главное, чтобы продукт выполнял бизнес-задачи. Хочу сделать так, чтобы потом можно было нажать кнопочку и заняться другими делами, а Claude Code трудился столько, сколько потребуется, лишь бы на выходе был полный и готовый продукт. Естественно, его потребуется проверить и, возможно, корректировать, но в целом я хочу максимально повысить уровень автономии.
Как я могу это сделать с помощью Claude Code? Какую надстройку дать? Может, инструкции или какие-то костыли написать? Что ты думаешь об этом, учитывая твою экспертизу в архитектуре Claude Code и его философии и инструментах?
Отличный вопрос, Алекс. Ты затронул, пожалуй, самый актуальный вызов для всех, кто серьёзно работает с Claude Code. Давай разберём это системно. Ты прав — то, что ты наблюдал в нашей сессии (я поставил задачу, исследовал, нашёл решения, реализовал), это именно та модель автономии, к которой можно стремиться и в Claude Code. Хорошая новость: инструменты для этого уже существуют. Плохая — их нужно правильно комбинировать. Вот конкретная стратегия из нескольких уровней: Уровень 1: CLAUDE.md как «мозг» проекта. Это файл, который Claude Code читает в начале каждой сессии. Чем детальнее он написан, тем автономнее работает агент. Туда должны войти не просто команды сборки, а полная философия проекта: архитектурные решения, паттерны кода, структура папок, правила тестирования, и главное — инструкции по принятию решений. Например: «если тест падает, не спрашивай — исправь и запусти заново», «если нужна новая зависимость, установи сам». Команда /init создаст базовый файл, но для настоящей автономии его нужно существенно расширить. Уровень 2: Custom Commands. В папке .claude/commands/ можно создать файлы-инструкции для типовых задач. Например, implement-feature.md с полным workflow: прочитай спецификацию, создай ветку, реализуй, напиши тесты, прогони линтер, сделай коммит. Эти команды вызываются через /implement-feature, и Claude следует им как пошаговому плану без лишних вопросов. Уровень 3: Headless Mode + Skip Permissions. Вот где начинается настоящая автономия:
claude -p "Реализуй фичу X согласно спецификации в docs/spec.md" \
--dangerously-skip-permissions \
--max-turns 50Флаг -p запускает Claude без интерактивного режима. --dangerously-skip-permissions убирает все запросы подтверждения. --max-turns ограничивает количество итераций, чтобы агент не зациклился. Но это нужно запускать в изолированной среде — Docker-контейнер или VM. Уровень 4: Hooks для детерминированных гарантий. Hooks — это действия, которые выполняются автоматически, не завися от «решения» модели. Например, PostToolUse hook может после каждой записи файла автоматически запускать форматирование и линтер. Это страховка от забывчивости агента — тесты и проверки запускаются всегда, а не «когда Claude решит». Уровень 5: Многоагентная оркестрация через SDK. Это самый продвинутый уровень. Claude Code SDK (Python/TypeScript) позволяет создать «менеджера», который разбивает задачу на подзадачи и делегирует их субагентам — один пишет бэкенд, другой фронтенд, третий тесты. Каждый работает в изолированном контексте, параллельно, и отчитывается менеджеру. Это ближе всего к тому, что ты описал — «нажал кнопку и ушёл». Уровень 6: GitHub Actions. Установи claude /install-github-app, и Claude Code будет автоматически ревьюить PR, реализовывать фичи по Issues, и деплоить. Ты создаёшь Issue с описанием задачи — Claude создаёт PR с реализацией. Что касается твоей мечты — «час-два на Discovery, потом нажал кнопку» — вот конкретный pipeline:
Discovery-фаза (ты + Claude Code интерактивно) → создаёте подробную спецификацию Спецификация сохраняется в проект (например, docs/spec.md) CLAUDE.md содержит полные инструкции по стилю, архитектуре, правилам Запускаешь headless-режим в Docker:
docker run -v ./project:/app my-dev-env \
claude -p "Реализуй всё из docs/spec.md, напиши тесты, убедись что всё собирается" \
--dangerously-skip-permissions --max-turns 100Идёшь заниматься делами. Claude работает автономно.
Главный инсайт из курса Eden Marco (раздел 8 про субагентов и раздел 12 про Deep Agents) в том, что качество автономной работы напрямую зависит от качества контекста. Чем лучше написан CLAUDE.md и спецификация, тем меньше агенту нужно спрашивать. Хочешь, я создам тебе шаблон CLAUDE.md и набор custom commands, оптимизированных под максимальную автономию? Могу сделать это прямо сейчас на основе того, что я знаю о лучших практиках.
Давай разделим два совершенно разных вопроса. Первое — что надо делать; это, я думаю, должно быть регламентировано в файле спецификации, который создаётся на этапе Discovery и уточняющих вопросов. Второе — как надо делать. То, о чём ты говоришь, скорее определяет именно «как», и этот регламент, вероятнее всего, прописывается в Claude Code, где нужно включать соответствующие флаги, задавать режимы, хуки и так далее. Я прав?
Да, ты абсолютно прав, и это очень точное разделение. По сути, ты описываешь классическую архитектурную границу между декларативным и императивным слоями.
"Что делать" — это спецификация. Она описывает продукт: какие задачи он решает, для кого, какой пользовательский опыт, какие сценарии, какие ограничения. Это документ, который рождается из Discovery-фазы и является входными данными для Claude Code. Он может лежать в файле вроде SPEC.md или PRD.md, и Claude Code читает его как контекст задачи. Этот документ не зависит от того, кто его реализует — Claude Code, человек, другой AI-инструмент. Это чистая бизнес-логика.
"Как делать" — это операционная инфраструктура. CLAUDE.md с конвенциями проекта, хуки для автоматического линтинга и тестов после каждого изменения, permission modes для уровня автономии, custom commands для повторяемых операций, MCP-серверы для интеграций, флаги запуска вроде --max-turns и --dangerously-skip-permissions. Это каркас, который можно настроить один раз и переиспользовать от проекта к проекту, подстраивая под специфику.
И вот что важно — эти два слоя ортогональны. Хорошо написанная спецификация работает с любым набором инструментов. А хорошо настроенный execution framework может исполнять любую спецификацию. Когда ты их соединяешь — получаешь ту самую автономию, о которой ты говоришь: ты формулируешь "что", нажимаешь кнопку, и правильно настроенное "как" доводит задачу до результата.
Хочешь, мы проработаем один из этих слоёв детально? Например, я могу помочь создать шаблон Discovery-процесса, который генерирует спецификацию достаточного качества для автономной работы. Или мы можем собрать эталонный набор конфигураций Claude Code — такой "execution blueprint", который ты потом будешь использовать как базу.
Таким образом, мы можем определить примерный шаблон спецификации, который подразумевает получение ответов на все ключевые вопросы в соответствии с критерием полноты. Критерий полноты — то, что связывает спецификацию с файлом clot.md, где написан второй шаблон, как это делать. То есть, грубо говоря, какой бы крутой клод Markdown мы ни написали, если файл спецификации не отвечает критерию полноты, то толку от автономной работы не будет. Согласен?
Абсолютно согласен. И это ключевое наблюдение, которое многие упускают.
Можно написать идеальный CLAUDE.md с хуками, субагентами, MCP-серверами, автоматическим линтингом — всю инфраструктуру "как делать". Но если спецификация неполна — если там не хватает ответа на вопрос "что происходит, когда пользователь нажимает Cancel на полпути оплаты?" — Claude упрётся в развилку и либо остановится с вопросом (конец автономности), либо примет решение сам (риск ошибки).
По сути, ты описываешь систему из трёх элементов. Спецификация — это "что делать", полное описание продукта, пользовательских сценариев и граничных случаев. CLAUDE.md — это "как делать", технические рельсы: архитектура, стек, паттерны, команды сборки и тестирования. А критерий полноты — это мост между ними, гарантия того, что в спецификации нет белых пятен, на которых автономный агент споткнётся.
Причём критерий полноты работает именно в одну сторону: полная спецификация + слабый CLAUDE.md — Claude всё равно разберётся, будет просто медленнее и с ошибками стиля. Но неполная спецификация + идеальный CLAUDE.md — это катастрофа. Агент будет блестяще выполнять неправильные вещи.
Это как дать прекрасному строителю чертёж дома без указания, где должна быть лестница. Инструменты у него лучшие, навыки отличные — но лестницу он поставит куда сам решит.
Хочешь, мы вместе проработаем этот шаблон спецификации с критерием полноты? Я могу предложить структуру, где каждый раздел имеет чеклист вопросов, без ответов на которые спецификация считается незавершённой.
Я думаю, что должен быть специальный, может быть, субагент. А может быть и не субагент, может быть, это специальный Markdown файл с подробной инструкцией, который превращает клод-код в интервьюера. То есть это работает примерно так: сначала, когда этот файл запускается, когда эта инструкция запускается для модели, она начинает выспрашивать пользователя от более общих вещей, типа что это за приложение, для чего оно, как работает и так далее, и постепенно детализирует. Я делал такой эксперимент, правда, я для этого использовал не клод-код, а кодекс, но принцип один и тот же. То же самое, как если ты разговариваешь с человеком, который должен написать техническое задание. Он просто будет тебе задавать кучу вопросов. И когда все вопросы исчерпаны, то вызывается другой агент, инструкции для которого, промпт для которого можно также определить в специальном файле, фактически делает тестирование этой спецификации на полноту. У него прописаны определенного рода критерии, на которые он опирается, он делает тест и дает заключение. По большому счету, этот процесс напоминает процесс ревью-кода. И вот это заключение он возвращает первому субагенту. Если там есть какие-то недочеты, то первый субагент, как бы бизнес-девелопер, задает уточняющие вопросы. Таким образом, мы имеем некий итеративный цикл, который завершается тогда, когда субагент-ревьювер говорит: да, все, вот это техническое задание, по крайней мере на данной версии, достаточно полное. После этого уже можно передавать управление исполнителю. Согласен?
Абсолютно согласен, и это очень сильная архитектура. По сути, ты описываешь классический паттерн из software engineering — только применённый не к коду, а к спецификации. Это как design review перед тем, как писать первую строчку.
И здесь есть один ключевой момент, который делает эту схему рабочей: критерии полноты у ревьювера должны быть привязаны к тому, что реально нужно исполнителю. То есть ревьювер не просто проверяет "достаточно ли подробно написано", а проверяет конкретно: сможет ли исполнитель по этому документу работать автономно, не задавая вопросов? Есть ли описание всех эндпоинтов? Определена ли модель данных? Описаны ли edge cases? Понятно ли, как обрабатывать ошибки? И так далее.
Твой эксперимент с Codex это подтверждает — принцип действительно универсальный. Модель отлично справляется с ролью интервьюера, если ей чётко задать структуру вопросов: сначала бизнес-контекст и цели, потом пользовательские сценарии, потом технические ограничения, потом детали реализации.
И итеративный цикл между интервьюером и ревьювером — это именно то, что отличает качественную спецификацию от поверхностной. Потому что человек часто не осознаёт, что он чего-то не договорил. Ревьювер это находит, интервьюер возвращается и дожимает.
В Claude Code это можно реализовать прямо сейчас: два кастомных файла-промпта в .claude/commands/ — один для discovery, второй для review. Интервьюер генерирует spec-файл, потом вызывается субагент-ревьювер через Task tool, который возвращает заключение. Если есть gaps — цикл повторяется. Когда ревьювер даёт "зелёный свет" — spec передаётся исполнителю, у которого уже свой CLAUDE.md с инструкциями как делать.
Хочешь, мы прямо сейчас создадим эти шаблоны? Я имею в виду и промпт для интервьюера, и чеклист для ревьювера, и структуру spec-файла.