Plan Mode в Claude Code: пошаговая инструкция и 4 этапа в 2026

Веду эти разборы публично. Подпишись на канал, где каждый день разбираю инструменты, примеры и ошибки вайб-кодинга.

Что такое Plan Mode и почему его одного недостаточно?

Я включил Plan Mode впервые, когда Claude в обычном режиме снёс мне половину auth-модуля за один промпт. Просил поправить magic-link - получил дифф на 14 файлов. С тех пор любая задача больше двух файлов у меня идёт через Plan Mode. В обычном режиме Claude Code сразу пишет код, и если ты не уследил - получаешь точно такой же дифф на ровном месте. Plan Mode разворачивает шаги наоборот: сначала исследование и план, потом одобрение, потом изменения.

В официальной документации Anthropic Plan Mode описывают так:

Звучит просто, но за этим прячется главный сдвиг. Plan Mode меняет ритм работы: сначала договорись, потом действуй. Это смена режима, не косметика. Боль вайб-кодера в том, что ИИ-агент склонен к спешке. Если попросить «прикрути авторизацию через Google», в обычном режиме Claude напишет код за минуту, но половина файлов окажется не той, что нужна. В Plan Mode тот же запрос превращается в текстовый план, который ты прочитаешь за две минуты и поправишь до того, как код тронут.

Здесь ловушка, о которой никто не пишет в зарубежных гайдах. Plan Mode сам по себе слабый инструмент: план живёт только в текущем диалоге. Закрыл окно - потерял план. Передать другому агенту нельзя. Версий и истории нет. Если задача большая (рефакторинг модуля на 30 файлов, миграция на новую базу), план быстро упрётся в потолок контекстного окна и начнёт деградировать.

Поэтому Plan Mode хорошо работает в связке с папкой plans/ в репозитории. План сохраняется как plans/2026-05-21-google-oauth.md, разбивается на фазы с чек-боксами, и любой следующий агент его подхватит. Так работает контекст-инжиниринг - управление контекстом до промпта, а не во время.

Как включить Plan Mode в Claude Code

В сессии быстрее всего через клавиатуру:

Shift+Tab           # циклически переключает режимы: default → acceptEdits → plan

После двух нажатий внизу терминала появится индикатор ⏸ plan mode on. Третье нажатие вернёт в обычный режим. Это самый удобный способ - переключаешь на лету, когда видишь, что задача растёт.

Второй способ - префикс перед одиночным промптом:

/plan напиши план миграции базы с MySQL на Postgres

Этот вариант полезен, когда ты в auto-accept режиме и не хочешь его менять для всей сессии. Один запрос в Plan Mode, дальше работа продолжается как раньше.

Третий способ - при запуске сессии:

claude --permission-mode plan

Используй когда заранее знаешь, что задача требует планирования. Например, перед большим рефакторингом или миграцией.

Четвёртый способ - настройка по умолчанию через .claude/settings.json в проекте:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Когда это полезно: команда работает над сложной системой, где любая правка может задеть смежные модули. Тогда дефолт Plan Mode защищает всех от случайных правок.

Пятый приём, который часто пропускают - Ctrl+G открывает план в текстовом редакторе. Это нужно, когда план почти правильный, но 2-3 пункта надо перефразировать или добавить ограничение. Правишь руками, сохраняешь, Claude продолжит с твоей версией.

Какие 4 фазы Anthropic канонически в Plan Mode: Explore, Plan, Implement, Commit?

Многие гайды пишут про 3 фазы (Explore-Plan-Execute) или вообще 2 (Plan-Implement). Это упрощения. Anthropic в официальном гайде best practices описывает именно 4 фазы. Разница важная: Commit как отдельная фаза заставляет тебя зафиксировать результат, не оставляя «вот тут я ещё немного поправил, потом закоммичу» - самый частый источник потерянной работы.

Boris Cherny, создатель Claude Code, объясняет логику так:

Перевод не нужен - мысль простая. Чем точнее план, тем меньше итераций в реализации. Если ты потратил 10 минут на план, реализация занимает один промпт. Если план накидал за минуту, реализация займёт час исправлений.

Вот как выглядят 4 фазы на примере добавления Google OAuth (пример из Anthropic Docs):

Промпты в каждой фазе тоже разные. В Explore: «read /src/auth and understand how we handle sessions and login». В Plan: «I want to add Google OAuth. What files need to change? Create a plan». В Implement: «implement the OAuth flow from your plan, write tests, run the suite and fix failures». В Commit: «commit with a descriptive message and open a PR».

Важный нюанс - Plan Mode не запрещает Claude запускать команды для исследования. Read, LS, Glob, Grep, web fetch и shell-команды для exploration разрешены. Запрещены только Edit, Write и любые мутирующие операции в файловой системе. Это значит, что Claude может прочитать структуру проекта, запустить git log, посмотреть тесты - но не сможет случайно что-то изменить.

Как читать план Claude и решать, принимать его или нет?

Когда Claude закончил составлять план, он показывает варианты дальнейших действий:

• Approve and start in auto mode
• Approve and accept edits
• Approve and review each edit manually
• Keep planning with feedback
• Refine with Ultraplan (browser review)

Решение принимать план - ключевое умение в Plan Mode. Сам ловил себя на этом раз пять: жмёшь «Approve» на автомате, а потом откатываешь 8 коммитов. ИИ-подхалим стремится дать быстрый ответ, ты стремишься быстрее перейти к коду. Оба ошибаются.

Хороший план проходит по 7 признакам:

1. Конкретные имена файлов. Не «обновлю auth», а «изменю src/auth/login.ts:42-58, создам src/auth/oauth-callback.ts, обновлю src/auth/session.ts:103».
2. Указана последовательность. План делится на фазы или шаги, а не «сделаю всё это где-то».
3. Названы внешние зависимости. Если задача требует новой библиотеки, она прописана. Если нужны переменные окружения - перечислены.
4. Перечислены риски. Хороший план сам говорит «миграция может сломать существующие сессии, нужно проверить X». Плохой - молчит про побочные эффекты.
5. Есть критерии успеха. «Тесты test/auth зелёные, линтер чист, дев-сервер запускается без ошибок».
6. Нет «потолочных» допущений. Если Claude пишет «использую библиотеку Z», проверь - а ты вообще в проекте её ставил? Если ИИ её выдумал, это будет видно по тому, что она не упомянута в package.json.
7. План помещается на экран. Если план Claude занял 200 строк на простую фичу, скорее всего, задача слишком крупная для одного плана. Разбей на части.

Когда план не проходит проверку, есть три варианта:

• Keep planning with feedback - даёшь Claude конкретный комментарий, что не нравится, он переписывает.
• Ctrl+G - открываешь план в редакторе, правишь руками, сохраняешь. Claude продолжит с твоей версией.
• Refine with Ultraplan - план уходит в браузерный режим Claude Code on the web, ты ревьюешь секции, комментируешь, потом исполняешь локально или в облаке.

Boris Cherny здесь прямо говорит:

Перевод в живой речи: если что-то пошло не так посреди реализации, не дожимай. Возвращайся в Plan Mode, переписывай план. Это в 10 раз дешевле, чем потом откатывать 40 коммитов.

Хочешь не только освоить Plan Mode, но и собрать связку, которая делает Claude стабильным? Plan Mode - лишь один кирпич. На практикуме за 3 эфира собираешь все три: ИИ-клон + Второй мозг + Контекст-инжиниринг - связка, которая превращает Claude из «помощника с галлюцинациями» в надёжный инструмент.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 26–28 мая  ·  2 000 ₽

Записаться →

Plan Mode + папка plans/ - связка для длинного контекста

Это раздел, которого нет ни в одном англоязычном гайде. Plan Mode - режим Claude Code. Папка plans/ - методология поверх него. Если ты пользуешься только Plan Mode без папки, ты упираешься в потолок через час работы.

Логика такая. Контекстное окно Claude - это память сессии. Туда влезает 1 миллион токенов в Opus 4.7, но это объём всей твоей беседы. Если ты планируешь сложную задачу в одном диалоге, потом просишь реализовать, потом обсуждаешь баг, потом ещё что-то - окно «передуется». Claude начинает забывать ранние решения, путать контексты, повторно задавать вопросы.

Решение - золотое правило: одна задача - один диалог.

Делается так:

1. Диалог 1 - формирование плана. Включаешь Plan Mode, описываешь задачу, Claude составляет план. Сохраняешь план в файл plans/2026-05-21-feature-name.md. Закрываешь окно.
2. Диалог 2 - деление на фазы. Открываешь новый чат. Просишь: «возьми plans/2026-05-21-feature-name.md, раздели на фазы». Сохраняешь обновлённый файл.
3. Диалог 3 - реализация фазы 1. Открываешь новый чат. Просишь: «реализуй Фазу 1 из plans/2026-05-21-feature-name.md, отметь чек-боксы по мере выполнения». Закрываешь окно.
4. Диалог 4 - реализация фазы 2. Аналогично.

Что это даёт. Контекстное окно каждого диалога остаётся свежим. Claude в фазе 3 не знает деталей фазы 1, но знает план - потому что файл plans/ живёт в репозитории. Любой следующий агент (хоть субагент, хоть новая сессия, хоть запуск через /goal) подхватит план и продолжит.

Сравнение подходов:

У меня в репозитории сейчас лежат сотни файлов планов. На каждую фичу - свой файл со средней длиной 150-300 строк. Когда через три месяца нужно вспомнить, почему выбрали именно этот платёжный провайдер, а не альтернативу, открываю соответствующий план и читаю историю решений: что обсуждалось, какие варианты рассматривались, почему выбрали именно этот путь.

Это второй мозг проекта в виде живых рабочих планов. Статичная документация устаревает за месяцы. См. подробный разбор: второй мозг в Claude Code.

Как заставить Claude работать пока ты спишь через Plan Mode и /goal?

Daisy Hollman из Anthropic на конференции Code with Claude 2026 сформулировала это одним предложением:

Это и есть /goal - фича, которую большинство ещё не пробовало, но в англоязычных разборах за две недели вышло 8 статей. Avi Chawla из Daily Dose of DS сформулировал суть так:

Главное ограничение долгих сессий с ИИ - не сама модель, а человек, нажимающий Enter. Каждый раз, когда Claude доходит до конца хода, он ждёт твоей реакции. /goal снимает это ожидание.

Синтаксис простой:

/goal все тесты в test/auth проходят и линт чист, или стоп через 20 ходов

Условие может быть до 4000 символов. Один goal на сессию. После каждого хода Claude мини-модель Haiku смотрит транскрипт и решает: «условие выполнено - закончить» или «не выполнено - следующий ход». Эвалюатор не вызывает инструменты, он только читает.

Aliases для сброса: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

Связка с Plan Mode выглядит так:

1. Включаешь Plan Mode (Shift+Tab дважды).
2. Просишь: «составь план миграции базы с MySQL на Postgres, сохрани в plans/2026-05-21-postgres-migration.md с фазами и критериями».
3. Просматриваешь план, правишь, одобряешь.
4. Выходишь из Plan Mode (Shift+Tab ещё раз).
5. Ставишь goal: «выполни все фазы из plans/2026-05-21-postgres-migration.md, отметь чек-боксы, все тесты зелёные, или стоп через 50 ходов».
6. Закрываешь ноутбук, идёшь спать.

Утром смотришь результат: либо «✓ goal completed», либо «◎ stopped after 50 turns» с историей того, что сделано.

Есть три обязательных правила для /goal, иначе токены сгорят впустую:

Правило 1: измеримое финальное состояние. «Сделай красиво» - плохо. «npm test возвращает 0, npm run lint возвращает 0, в CHANGELOG.md добавлена запись» - хорошо.

Правило 2: явная проверка. Условие должно ссылаться на что-то проверяемое: команда, файл, эндпоинт. Не «всё работает», а «curl localhost:3000/api/users возвращает 200».

Правило 3: ограничение по ходам. Всегда добавляй или стоп через N ходов. Anthropic в документации прямо рекомендует:

Почему это критично. Команда FindSkill.ai опубликовала разбор: разработчик оставил /goal без or stop after на 14-часовой ночной запуск с расплывчатыми условиями. Утром получил счёт на $200 - вся недельная квота сгорела на цикле «попытаться-проверить-не-получилось-попробовать ещё». Это типичная история «как НЕ использовать /goal».

CloudZero отмечает, что параллельные сессии Claude Code в среднем съедают $13/день на разработчика, при 5 параллельных агентах - $50-65/день. Если ты включил /goal без or stop after, бюджет может уйти за ночь.

Какой 4-шаговый цикл превращает Plan Mode в инженерный процесс?

Главная моя ошибка в первые две недели работы с Plan Mode - спрашивал «как починить?». Claude давал решение, я применял, ничего не работало или становилось хуже. Это «ИИ-подхалим»: он натренирован отвечать быстро, а я хотел быстрее перейти к коду. Оба ошибались. Решил это через 4-шаговый цикл, который выработал на сложных багах в одном из своих проектов.

4-шаговый цикл блокирует этот режим. Он применяется внутри одной сессии Plan Mode, последовательно:

Шаг 1. Установить факты без решения.

Промпт: «Я столкнулся со следующим: [описание симптома]. Сейчас твоя задача - установить факты. Запрещены любые решения, идеи, советы. Только: что я наблюдаю, какие воспроизводимые шаги, какие данные есть, какие данные отсутствуют. Жёсткое стоп-условие: НЕ предлагать решений, только фиксировать диагноз».

Это блокирует первый порыв ИИ «вот решение». Claude вынужден остановиться на состоянии «что есть, что неизвестно».

Шаг 2. Выработать варианты с прецедентами.

Промпт: «Теперь когда диагноз установлен, найди в интернете прецеденты решения подобных проблем. Минимум 3 разных подхода. Для каждого: ссылка на первоисточник, краткое описание, плюсы и минусы для нашей ситуации».

Это блокирует второй порыв ИИ - «выдумать решение из головы». Заставляем сходить во внешний мир и принести проверяемые подходы.

Шаг 3. Детальный план с рисками.

Промпт: «Возьми лучший вариант из Шага 2 и распиши детальный план: какие конкретные файлы трогаем, что добавляем, что удаляем, какие тесты пишем, что может сломаться, какие риски на 2-3 шага вперёд».

Это уже знакомая фаза Plan, но с одним отличием - она опирается на верифицированные варианты из Шага 2, а не на догадки Claude.

Шаг 4. Самопроверка плана.

Промпт: «Теперь обязательная самопроверка. Перепроверь свой план честно: в нём есть места, которые ты взял с потолка и не подтвердил кодом, документацией или прецедентом из Шага 2? Если есть - отметь их и переделай».

Это последний фильтр. Claude вынужден проверить собственное мышление и признать, где он галлюцинировал. Минимум 2 пункта плана обычно правятся на этом шаге.

После 4 шагов план готов к одобрению. На реализацию переходишь с уверенностью, что задача понята, варианты взвешены, риски осмыслены.

Эту методологию я использую при диагностике сложных багов и архитектурных решений - там, где цена ошибки высокая. Перенесённая в Plan Mode, она убирает основную боль вайб-кодера - «ИИ дал решение, я применил, всё сломалось».

Какие 5 готовых промптов работают в Plan Mode для типовых задач?

Шаблон 1. Рефакторинг модуля.

Включаю Plan Mode. Задача: рефакторинг модуля {название-модуля}.

Шаг 1: Изучи текущую структуру модуля {путь-к-модулю}. Опиши:
- какие файлы входят в модуль
- какие внешние зависимости
- какие места дублируются
- какие функции переусложнены

Шаг 2: Найди в интернете 2-3 примера рефакторинга похожих модулей.
Минимум 1 источник - официальная документация Anthropic или связанного фреймворка.

Шаг 3: Составь план рефакторинга в plans/YYYY-MM-DD-refactor-{module}.md:
- какие файлы переименовать
- какие функции вынести в отдельные модули
- какие тесты сохранить, какие переписать
- риски: что может сломаться у пользователей

Шаг 4: Самопроверка. В плане есть допущения "с потолка"?
Перепиши их или удали.

Шаблон 2. Миграция базы данных.

Включаю Plan Mode. Задача: миграция БД с {старая} на {новая}.

Шаг 1: Изучи текущую схему БД через {команда-чтения-схемы}. Опиши:
- какие таблицы есть, их размер
- какие связи, индексы, ограничения
- где хранятся миграции
- какие данные критичны

Шаг 2: Найди прецеденты миграций {старая → новая} в продакшен-проектах.
Минимум 3 разных подхода: pg_dump, dual-write, blue-green.
Для каждого - плюсы и риски для нашего размера данных.

Шаг 3: Составь план миграции в plans/YYYY-MM-DD-db-migration.md:
- фазы (бэкап, миграция, проверка, переключение)
- критерии успеха каждой фазы
- план отката если что-то пошло не так
- даунтайм или его отсутствие

Шаг 4: Самопроверка. Все цифры подкреплены документацией?
Все шаги проверены на dev-окружении мысленно?

Шаблон 3. Добавление новой фичи.

Включаю Plan Mode. Задача: добавить фичу {описание} в проект.

Шаг 1: Изучи как сейчас работают похожие фичи в проекте.
Конкретно посмотри:
- {файл-1}
- {файл-2}
- какие паттерны архитектуры используются
- какие тесты пишутся для подобных фич

Шаг 2: Найди как эта фича реализована в open-source проектах
с похожей архитектурой. Минимум 2 разных подхода.

Шаг 3: Составь план в plans/YYYY-MM-DD-feature-{name}.md:
- список новых файлов
- список изменяемых файлов с конкретными строками
- последовательность реализации
- какие тесты добавить
- что добавить в CLAUDE.md как правило для будущих сессий

Шаг 4: Самопроверка. План соблюдает архитектуру проекта?
Есть допущения о библиотеках, которые ещё не установлены?

Шаблон 4. Написание тестов.

Включаю Plan Mode. Задача: покрыть тестами модуль {название}.

Шаг 1: Изучи модуль {путь}. Определи:
- публичные функции и их сигнатуры
- внутренние функции, которые НЕ тестируем (детали реализации)
- edge cases: пустой ввод, ошибки, конкурентный доступ

Шаг 2: Найди примеры тестов для похожего класса задач
в популярных open-source проектах того же фреймворка.

Шаг 3: Составь план тестов в plans/YYYY-MM-DD-tests-{module}.md:
- для каждой публичной функции - список тестов
- какие моки нужны
- какие фикстуры
- какой подход к проверке (assertion-стиль)

Шаг 4: Самопроверка. Все тесты проверяют поведение, а не реализацию?
Покрытие включает edge cases?

Шаблон 5. Отладка сложной ошибки.

Включаю Plan Mode. Задача: понять причину ошибки {описание-симптома}.

Шаг 1: УСТАНОВИТЬ ФАКТЫ. Запрещены решения и идеи. Только:
- что я наблюдаю (точная формулировка ошибки)
- воспроизводимые шаги
- какие данные есть (логи, трейсы, версии библиотек)
- какие данные отсутствуют (что нужно собрать дополнительно)

Шаг 2: Найди прецеденты этой ошибки.
Минимум 3 источника: GitHub issues, Stack Overflow, документация.
Для каждого - ссылка и краткая суть решения.

Шаг 3: Составь план диагностики в plans/YYYY-MM-DD-bug-{name}.md:
- какие гипотезы проверять (отсортированы по вероятности)
- какие команды/скрипты запустить для проверки каждой
- ожидаемый результат каждой проверки

Шаг 4: Самопроверка. В плане есть гипотезы "с потолка"?
Все гипотезы привязаны к фактам из Шага 1?

Каждый шаблон копируешь, заменяешь {параметры} на свои, вставляешь в Claude Code в Plan Mode. На выходе - рабочий план в plans/, который ты одобряешь и пускаешь в реализацию.

Plan Mode vs обычный режим: когда что выбрать?

Anthropic в документации прямо пишет:

Если можешь описать diff одним предложением - пропусти план. Если задача затрагивает 3+ файла, или не знаешь как подступиться, или область кода тебе незнакома - всегда Plan Mode.

Таблица решений:

Главное правило перед включением Plan Mode: можешь ли ты сейчас, прямо сейчас, набросать список из 3-5 файлов, которые точно будут затронуты? Если да - Plan Mode избыточен, делай напрямую. Если нет - Plan Mode обязателен, иначе Claude поедет наугад.

Как собрать связку Plan Mode + CLAUDE.md + Subagents для надёжной работы?

CLAUDE.md - это файл, который Claude читает в начале каждой сессии, включая Plan Mode. Если в CLAUDE.md написано «никогда не хардкодить даты, всегда брать из БД», план никогда не предложит хардкод. Если правила нет - план может предложить что угодно.

Связка работает так:

Слой 1. CLAUDE.md задаёт правила.

В файле прописаны: стек проекта, архитектурные принципы, запреты («не использовать deprecated API»), требования («все email через единый layout»). Подробный гайд: как настроить CLAUDE.md.

Слой 2. Plan Mode применяет правила к задаче.

Когда ты включаешь Plan Mode и просишь «добавь OAuth», Claude читает CLAUDE.md, видит правила («хранить токены в Redis, не в БД»), и план учитывает это сразу. План соответствует архитектуре проекта.

Слой 3. Субагенты делят работу.

Если план разбит на фазы, каждую фазу можно поручить отдельному субагенту. Субагент работает в собственном контекстном окне, не загрязняя главное. План в plans/ остаётся центральным источником истины - субагенты читают его, выполняют свою фазу, обновляют чек-боксы.

Эта связка - практическая реализация трёх китов методологии: контекст-инжиниринг (Plan Mode), второй мозг (папка plans/), ИИ-клон (CLAUDE.md как зафиксированные правила мышления).

Andrej Karpathy публично делился своим подходом к CLAUDE.md в начале 2026 года. На основе его публикаций собрана популярная подборка skills, набравшая больше 140 000 звёзд на GitHub. Четыре принципа Karpathy:

1. Think Before Coding - проговори свои допущения явно. Если не уверен - спроси.
2. Simplicity First - минимум кода, решающий задачу. Ничего спекулятивного.
3. Surgical Changes - трогай только то, что необходимо. Прибирай только свой беспорядок.
4. Goal-Driven Execution - определи критерии успеха. Зацикливайся пока не проверено.

Третий и четвёртый принципы - ровно про Plan Mode. Surgical Changes ограничивает скоуп (план не должен трогать лишнее), Goal-Driven Execution - это прямо /goal команда.

Какие 7 ошибок ломают Plan Mode?

Ошибка 1. План живёт только в чате.

Симптом: написал план, закрыл окно, на следующий день нужно вернуться - ничего нет, контекст ушёл. Решение: всегда сохранять план в plans/YYYY-MM-DD-feature-name.md в репозитории. Чат - рабочий стол, файл - архив.

Ошибка 2. Все задачи в одном чате.

Симптом: за день в одной сессии обсудили auth, потом миграцию, потом дизайн UI, потом баг. Контекстное окно «передулось», Claude забывает раннее. Решение: одна задача - один диалог. Закончил план - закрыл окно. Начинаешь реализацию - открываешь новое.

Ошибка 3. Один план на 3000 строк без фаз.

Симптом: план есть, но без чек-боксов и без разбивки. Невозможно понять, что сделано, что нет. Невозможно делегировать. Решение: каждый план делится на 3-7 фаз. Каждая фаза - список чек-боксов с конкретными действиями.

Ошибка 4. Без deep research перед планом.

Симптом: Claude предлагает решение из головы, потому что ты не попросил искать прецеденты. Через неделю выясняется, что в open-source давно есть лучший подход. Решение: Шаг 2 4-шагового цикла - заставить Claude найти 2-3 прецедента в интернете, прежде чем составлять план.

Ошибка 5. ИИ-подхалим даёт решение без диагноза.

Симптом: ты спрашиваешь «как починить ошибку Х?», Claude даёт решение, ты применяешь, ничего не работает или становится хуже. Решение: всегда первым шагом «установи факты, запрещены решения». Только после диагноза - варианты.

Ошибка 6. Пропуск самопроверки.

Симптом: план выглядит правдоподобно, но в нём 2-3 «потолочных» допущения (выдуманная библиотека, несуществующий API, неверная версия). Реализация ломается на этих пунктах. Решение: Шаг 4 4-шагового цикла - заставить Claude перепроверить свой план честно и отметить допущения.

Ошибка 7. Расплывчатые условия в /goal.

Симптом: поставил /goal сделай красиво, оставил на ночь, утром $200 квоты сгорели. Решение: только измеримые условия с командой проверки и обязательным or stop after N turns. Никаких «сделай хорошо», «доведи до ума».

Восьмая ошибка, которую вайб-кодеры делают чаще всего - игнорировать саму концепцию папки plans/. Plan Mode без папки plans/ - это не методология, это игрушка. Если ты пользуешься Plan Mode, но не создаёшь файлы, ты получаешь 10% от его возможностей.

Что делать дальше после первого опыта Plan Mode?

Три конкретных шага в порядке возрастания сложности:

Шаг 1. Настрой CLAUDE.md, если ещё нет.

Без CLAUDE.md Plan Mode работает «в вакууме» - Claude не знает правил проекта и предлагает планы, которые ломают архитектуру. Полное руководство: как настроить CLAUDE.md. Минимальный CLAUDE.md - 50-80 строк со стеком, правилами, запретами. Karpathy показал, что 65 строк достаточно. Объём вторичен. Главное - конкретность.

Шаг 2. Создай папку plans/ в репозитории.

В корне проекта добавь папку plans/. Договорись с собой о формате имён: YYYY-MM-DD-feature-name.md. Каждый план - отдельный файл. Через месяц у тебя будет 20-30 файлов, через полгода - 100+. Это и есть второй мозг проекта в виде живой истории решений. Подробнее про методологию: второй мозг в Claude Code.

Шаг 3. Попробуй /goal на одной задаче.

Выбери задачу, которую обычно делаешь руками по 30-40 минут. Включи Plan Mode, составь план, сохрани в plans/. Выйди из Plan Mode. Поставь /goal выполнить все фазы из plans/file.md, все тесты зелёные, или стоп через 30 ходов. Закрой ноутбук на час, иди заниматься чем-то другим. Вернись и посмотри результат.

Три шага - это минимум. У меня в plans/ накопились сотни файлов, CLAUDE.md на 280 строк и пара субагентов под типовые задачи. Это нарастает постепенно, не пытайся собрать всё за вечер. Начни с CLAUDE.md, через неделю добавь plans/, через месяц попробуй /goal overnight.

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира, 2 000 ₽. Записи остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 26–28 мая  ·  2 000 ₽

Записаться →