Типовые рабочие процессы: исследование, план, реализация

Любой опытный разработчик знает: самая дорогая ошибка — быстро написать правильный код не для той задачи. Агентный цикл Claude Code умножает эту проблему: если агент прыгает сразу к коду без понимания контекста, он может написать несколько сотен строк качественного, хорошо структурированного решения, которое решает не ту проблему. Именно поэтому официально рекомендованный паттерн работы выглядит так:

Explore → Plan → Code → Commit

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

flowchart TD A([🚀 Новая задача]) --> B{Задача простая?} B -- Да, один файл,\nодно изменение --> G[⚡ Прямо к коду] B -- Нет, несколько файлов\nили незнакомый код --> C C[🔍 EXPLORE\nПлан-режим: Shift+Tab\nЧтение файлов, @ссылки,\nсубагенты для больших исследований] --> D D[📋 PLAN\nCtrl+G — редактировать план\nСписок файлов, шаги, верификаторы] --> E E[💻 CODE\nОбычный режим\nРеализация + тесты/билд\nАгент итерирует до прохождения] --> F F[✅ COMMIT\nОсмысленный коммит\ngh pr create\nclaude --from-pr для возобновления] --> H([🎯 Готово]) G --> F style A fill:#4CAF50,color:#fff style H fill:#4CAF50,color:#fff style C fill:#2196F3,color:#fff style D fill:#FF9800,color:#fff style E fill:#9C27B0,color:#fff style F fill:#607D8B,color:#fff style G fill:#9C27B0,color:#fff

flowchart TD
    A([🚀 Новая задача]) --> B{Задача простая?}
    B -- Да, один файл,\nодно изменение --> G[⚡ Прямо к коду]
    B -- Нет, несколько файлов\nили незнакомый код --> C

    C[🔍 EXPLORE\nПлан-режим: Shift+Tab\nЧтение файлов, @ссылки,\nсубагенты для больших исследований] --> D

    D[📋 PLAN\nCtrl+G — редактировать план\nСписок файлов, шаги, верификаторы] --> E

    E[💻 CODE\nОбычный режим\nРеализация + тесты/билд\nАгент итерирует до прохождения] --> F

    F[✅ COMMIT\nОсмысленный коммит\ngh pr create\nclaude --from-pr для возобновления] --> H([🎯 Готово])
    G --> F

    style A fill:#4CAF50,color:#fff
    style H fill:#4CAF50,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#FF9800,color:#fff
    style E fill:#9C27B0,color:#fff
    style F fill:#607D8B,color:#fff
    style G fill:#9C27B0,color:#fff

Паттерн Explore → Plan → Code → Commit: полный путь от задачи до коммита

Фаза 1: Explore — сначала понять, потом трогать

Самый важный принцип: Claude не должен редактировать файлы, пока не понял контекст. Для этого существует план-режим (plan mode) — специальный режим, где агент может читать файлы, выполнять Bash-команды, задавать вопросы, но не вносить изменений в файловую систему.

Включить план-режим можно тремя способами:

# Запуск сразу в плановом режиме
claude --permission-mode plan

# Переключение в середине сессии — Shift+Tab
# или команда:
/plan

Типичные запросы для фазы исследования:

Прочитай src/auth и разберись, как мы обрабатываем сессии и логин.
Также посмотри, как управляем переменными окружения для секретов.

Покажи мне архитектуру модуля payments — какие файлы за что отвечают?

Проследи путь запроса от фронтенда до базы данных для эндпоинта /api/users

Обратите внимание на синтаксис @ — он позволяет явно передать файл или директорию без ожидания, пока Claude сам найдёт нужное:

Объясни логику в @src/utils/auth.js

Какова структура @src/components?

Разница между @file и просьбой «прочитай файл» — в том, что @-ссылка включает содержимое немедленно, до генерации ответа.

Когда исследование занимает слишком много контекста. Если задача требует прочитать десятки файлов, стоит делегировать исследование субагенту — он работает в отдельном контекстном окне и возвращает только выжимку:

Используй субагент для исследования того, как наша auth-система
обрабатывает refresh токенов и есть ли уже существующие OAuth-утилиты.

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

Проверь себя

Зачем при исследовании большой кодовой базы стоит использовать субагент вместо того, чтобы просить Claude читать файлы напрямую в основной сессии?

Фаза 2: Plan — детальный план до первого изменения

После того как агент понял структуру кода, запросите конкретный план реализации — прямо в план-режиме:

Хочу добавить Google OAuth. Какие файлы нужно изменить?
Какой будет flow сессии? Составь детальный план.

Получив план, вы можете его отредактировать прямо в текстовом редакторе — нажмите Ctrl+G внутри сессии, и план откроется в вашем редакторе. Это не просто удобство: можно убрать ненужные шаги, добавить ограничения, уточнить приоритеты. Claude будет следовать отредактированному плану при реализации.

Хороший план содержит:

Список файлов с конкретными изменениями
Последовательность шагов (что сначала, что потом)
Точки верификации (после каких шагов запустить тесты)
Явные ограничения («не трогать legacy-модуль X», «не добавлять новые зависимости»)

Документация Anthropic предлагает полезный трюк для сложных фич — дать Claude провести «интервью» перед планированием:

Хочу реализовать систему уведомлений. Проведи детальное интервью
с помощью AskUserQuestion. Спроси о техническом подходе, UX,
крайних случаях, trade-offs. Не задавай очевидных вопросов —
копай в трудные места, о которых я мог не подумать.
После интервью напиши полный spec в SPEC.md.

Получив spec, начните чистую сессию для реализации — так контекст планирования не засоряет контекст имплементации.

Проверь себя

В чём конкретная польза нажатия Ctrl+G при работе в план-режиме? Что это даёт, чего нельзя сделать прямо в чате?

Фаза 3: Code — реализация с верификацией

Переключитесь из план-режима в обычный и запустите реализацию. Ключевой принцип этой фазы: давайте Claude способ верифицировать результат.

Без механизма проверки Claude останавливается тогда, когда «выглядит готово». С тестами, билдом или скриптом он итерирует сам:

# Плохой запрос:
реализуй OAuth flow из твоего плана

# Хороший запрос:
реализуй OAuth flow из твоего плана. Напиши тесты для callback handler,
запусти suite и исправь все падения. Убедись, что билд проходит.

Что можно использовать как верификатор:

Тип задачи	Верификатор
Логика/алгоритмы	Тесты (unit, integration)
Рефакторинг	Тесты + билд
UI-изменения	Скриншот + сравнение с макетом
Баг-фикс	Failing test → fix → passing test
Миграция	Линтер + типы + тесты

Ещё несколько принципов качественного промпта для фазы кода:

Ссылайтесь на существующие паттерны. Вместо абстрактного «добавь виджет» покажите образец:

Посмотри, как реализованы существующие виджеты на home page.
HotDogWidget.php — хороший пример. Следуй этому паттерну,
чтобы реализовать новый CalendarWidget. Без сторонних библиотек,
кроме уже используемых в кодовой базе.

Описывайте симптом, а не догадку о причине. Вместо «почини баг логина»:

Пользователи сообщают, что логин падает после истечения сессии.
Проверь auth flow в src/auth/, особенно token refresh.
Напиши failing test, который воспроизводит проблему, потом почини её.

Указывайте на источники для ответа на вопросы:

Почему ExecutionFactory имеет такой странный API?
Посмотри git-историю ExecutionFactory и расскажи, как это получилось.

Фаза 4: Commit — осмысленные коммиты и PR

После успешной верификации попросите Claude зафиксировать изменения:

сделай коммит с описательным сообщением и открой PR

ClaudeCode умеет создавать коммиты, пуш-ить ветку и открывать PR через gh pr create — всё это он делает через Bash-инструмент. Важный нюанс: если сессия создала PR через gh pr create, она автоматически привязывается к этому PR. Вернуться к ней позже можно через:

claude --from-pr <номер>

Это позволяет продолжить работу над PR в следующей сессии без потери контекста.

Вариации паттерна: когда упрощать

Паттерн explore → plan → code → commit не нужен для каждой задачи. Он добавляет накладные расходы — и это стоит учитывать.

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

Исправить опечатку или добавить лог-строку
Переименовать переменную
Задача умещается в одно предложение: «добавь null-check в строку 42»

Когда планирование обязательно:

Изменение затрагивает несколько файлов
Вы не знакомы с изменяемым кодом
Задача архитектурная — несколько подходов с trade-offs
После нескольких сессий Sonnet так и не нашёл правильное решение

Проверь себя

Команда просит вас исправить баг: «логин падает после истечения сессии». Перефразируйте это в качественный промпт для фазы Code, учитывая принципы из статьи.

Паттерн Writer/Reviewer. Для сложных изменений стоит использовать две сессии:

Сессия A (Writer)	Сессия B (Reviewer)
`Реализуй rate limiter для API`
	`Проверь реализацию в @src/middleware/rateLimiter.ts. Ищи edge cases, race conditions и несоответствия нашим паттернам middleware.`
`Вот отзыв ревьюера: [вывод сессии B]. Устрани эти замечания.`

Ревьюер работает в чистом контексте — он не знает рассуждений, которые привели к реализации, и оценивает результат объективно.

Типичные анти-паттерны

«Кухонная раковина»-сессия. Начали с одной задачи, спросили о несвязанном, вернулись к первой. Контекст засорён. Фикс: /clear между несвязанными задачами.

Бесконечная коррекция. Claude сделал что-то не так, вы поправили, он снова не так. После двух неудачных коррекций в одной сессии — /clear и новый, более конкретный промпт с учётом того, что узнали. Чистая сессия с лучшим промптом почти всегда выигрывает у длинной сессии с накопленными правками.

Бесконечное исследование. Попросили «исследовать» что-то без границ — Claude прочитал сотни файлов, контекст заполнен. Фикс: ограничивайте исследование конкретными директориями или используйте субагент.

Доверие без верификации. Claude написал правдоподобную реализацию, вы отправили в прод, там упал edge case. Фикс: всегда давайте верификатор.

Проверь себя

После третьей неудачной коррекции Claude всё ещё не понимает, что именно нужно исправить в коде. Что делать дальше?