Как я использую Claude Code

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

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Как я использую Claude Code

How I Use Claude Code Автор: Boris Tane Оригинальный текст:

Я использую Claude Code как основной инструмент разработки уже около 9 месяцев, и выработанный мной рабочий процесс радикально отличается от того, что делает большинство с ИИ-инструментами для кодинга. Большинство разработчиков пишет промпт, иногда использует режим планирования, исправляет ошибки и повторяет. Те, кто поглубже погружён в тему, собирают сложные конструкции из ralph loops, MCP, gas towns (помните такое?) и прочего. Результат в обоих случаях — хаос, который разваливается на чём угодно нетривиальном.

Рабочий процесс, который я опишу, строится на одном принципе: никогда не позволять Claude писать код, пока вы не проверили и не утвердили письменный план. Это разделение планирования и реализации — самое важное в моём подходе. Оно предотвращает напрасную работу, оставляет архитектурные решения под моим контролем и даёт значительно лучшие результаты с минимальным расходом токенов (токены, единицы текста), чем если сразу переходить к коду.

Фаза 1: Исследование

Каждая серьёзная задача начинается с директивы на глубокое изучение. Я прошу Claude тщательно разобраться в соответствующей части кодовой базы, прежде чем делать что-либо ещё. И я всегда требую, чтобы выводы были записаны в постоянный markdown-файл, а не просто озвучены в чате.

Обратите внимание на формулировки: «глубоко», «в деталях», «тонкости», «пройди через всё». Это не пустые слова. Без них Claude будет читать по верхам. Он прочитает файл, увидит что делает функция на уровне сигнатуры, и пойдёт дальше. Нужно дать сигнал, что поверхностное чтение неприемлемо.

Письменный артефакт (research.md) критически важен. Дело не в том, чтобы заставить Claude делать домашнюю работу. Это моя поверхность для проверки. Я могу прочитать его, убедиться что Claude действительно понял систему, и исправить недопонимания до начала планирования. Если исследование неверно, план будет неверным, и реализация будет неверной. Мусор на входе — мусор на выходе.

Это самый дорогой режим отказа при кодинге с ИИ, и это не неправильный синтаксис или плохая логика. Это реализации, которые работают изолированно, но ломают окружающую систему. Функция, игнорирующая существующий слой кэширования. Миграция, не учитывающая соглашения ORM. API endpoint (точка доступа API), дублирующий логику, которая уже есть в другом месте. Фаза исследования предотвращает всё это.

Фаза 2: Планирование

После проверки исследования я прошу детальный план реализации в отдельном markdown-файле.

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

Я использую собственные .md файлы планов вместо встроенного режима планирования Claude Code. Встроенный режим планирования отстой. Мой markdown-файл даёт полный контроль. Я могу редактировать его в редакторе, добавлять inline-заметки, и он сохраняется как реальный артефакт в проекте.

Один приём, который я постоянно использую: для хорошо изолированных фич, где я видел хорошую реализацию в open source репозитории, я делюсь этим кодом как референсом вместе с запросом на план. Если хочу добавить сортируемые ID, я вставляю код генерации ID из проекта, который делает это хорошо, и говорю «вот так они делают сортируемые ID, напиши plan.md объясняющий как мы можем адаптировать похожий подход». Claude работает значительно лучше, когда у него есть конкретная референсная реализация, а не проектирование с нуля.

Но сам документ плана — не самое интересное. Интересно то, что происходит дальше.

Цикл аннотаций

Это самая отличительная часть моего рабочего процесса и та, где я добавляю наибольшую ценность.

После того как Claude пишет план, я открываю его в редакторе и добавляю inline-заметки прямо в документ. Эти заметки исправляют предположения, отклоняют подходы, добавляют ограничения или предоставляют доменные знания, которых у Claude нет.

Заметки сильно варьируются по длине. Иногда заметка — два слова: «не опционально» рядом с параметром, который Claude пометил как опциональный. В других случаях это абзац, объясняющий бизнес-ограничение или вставляющий сниппет кода, показывающий ожидаемую структуру данных.

Примеры заметок, которые я бы добавил:

• «используй drizzle:generate для миграций, не сырой SQL» — доменное знание, которого у Claude нет
• «нет — это должен быть PATCH, не PUT» — исправление неверного предположения
• «убери этот раздел полностью, нам здесь не нужно кэширование» — отклонение предложенного подхода
• «queue consumer уже обрабатывает повторы, поэтому эта логика повторов избыточна. убери её и просто дай ему упасть» — объяснение почему что-то должно измениться
• «это неправильно, поле visibility должно быть на самом списке, не на отдельных элементах. когда список публичный, все элементы публичные. перестрой раздел схемы соответственно» — перенаправление целого раздела плана

Затем я отправляю Claude обратно к документу:

Этот цикл повторяется от 1 до 6 раз. Явная защита «пока не реализуй» существенна. Без неё Claude перескочит к коду, как только посчитает план достаточно хорошим. Он недостаточно хорош, пока я так не скажу.

Почему это так хорошо работает

Markdown-файл действует как разделяемое изменяемое состояние между мной и Claude. Я могу думать в своём темпе, точечно аннотировать где именно что-то не так, и вернуться к работе без потери контекста. Я не пытаюсь объяснить всё в сообщении чата. Я указываю на точное место в документе, где проблема, и пишу исправление прямо там.

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

Три раунда «я добавил заметки, обнови план» могут превратить общий план реализации в такой, который идеально вписывается в существующую систему. Claude отлично понимает код, предлагает решения и пишет реализации. Но он не знает моих продуктовых приоритетов, болевых точек пользователей или инженерных компромиссов, на которые я готов пойти. Цикл аннотаций — вот как я внедряю это суждение.

Список задач

Перед началом реализации я всегда прошу гранулярную разбивку задач:

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

Фаза 3: Реализация

Когда план готов, я выдаю команду на реализацию. Я отточил её до стандартного промпта, который переиспользую в разных сессиях:

Этот единственный промпт кодирует всё важное:

• «реализуй всё»: сделай всё в плане, не выбирай частично
• «отметь как выполненную в документе плана»: план — источник истины о прогрессе
• «не останавливайся пока все задачи и фазы не завершены»: не делай паузу для подтверждения посреди работы
• «не добавляй ненужные комментарии или jsdocs»: держи код чистым
• «не используй any или unknown типы»: поддерживай строгую типизацию
• «постоянно запускай typecheck»: ловить проблемы рано, не в конце

Я использую эту точную формулировку (с минимальными вариациями) практически в каждой сессии реализации. К моменту когда я говорю «реализуй всё», каждое решение было принято и проверено. Реализация становится механической, не творческой. Это намеренно. Я хочу чтобы реализация была скучной. Творческая работа произошла в циклах аннотаций. Когда план правильный, выполнение должно быть простым.

Без фазы планирования обычно происходит так: Claude делает разумное-но-неверное предположение в начале, строит поверх него 15 минут, а потом мне приходится откатывать цепочку изменений. Защита «пока не реализуй» полностью это устраняет.

Обратная связь во время реализации

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

Там где заметка к планированию может быть абзацем, исправление реализации часто одно предложение:

• «Ты не реализовал функцию `deduplicateByTitle`.»
• «Ты построил страницу настроек в главном приложении, а она должна быть в админском, перенеси её.»

У Claude есть полный контекст плана и текущей сессии, поэтому коротких исправлений достаточно.

Работа с фронтендом — самая итеративная часть. Я тестирую в браузере и выдаю быстрые исправления:

• «шире»
• «всё ещё обрезано»
• «там зазор 2px»

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

Я также постоянно ссылаюсь на существующий код:

• «эта таблица должна выглядеть точно как таблица пользователей, тот же header, та же пагинация, та же плотность строк.»

Это намного точнее, чем описывать дизайн с нуля. Большинство фич в зрелой кодовой базе — вариации существующих паттернов. Новая страница настроек должна выглядеть как существующие страницы настроек. Указание на референс передаёт все неявные требования без необходимости их прописывать. Claude обычно читает референсный файл(ы) прежде чем делать исправление.

Когда что-то идёт в неправильном направлении, я не пытаюсь латать. Я откатываю и сужаю scope, сбрасывая изменения в git:

• «Я откатил всё. Теперь всё что я хочу — сделать list view более минималистичным — ничего больше.»

Сужение scope после отката почти всегда даёт лучшие результаты, чем попытки постепенно исправить плохой подход.

Оставаться за рулём

Хотя я делегирую выполнение Claude, я никогда не даю ему полную автономию над тем, что строится. Подавляющую часть активного руководства я делаю в документах plan.md.

Это важно, потому что Claude иногда предлагает решения, которые технически корректны, но неправильны для проекта. Может подход переусложнён, или меняет публичную сигнатуру API от которой зависят другие части системы, или выбирает более сложный вариант когда подошёл бы более простой. У меня есть контекст о более широкой системе, направлении продукта и инженерной культуре, которого нет у Claude.

Выборочное принятие из предложений: Когда Claude находит несколько проблем, я прохожу по ним по одной: «для первой просто используй Promise.all, не усложняй; для третьей вынеси в отдельную функцию для читаемости; четвёртую и пятую игнорируй, они не стоят сложности.» Я принимаю решения на уровне пунктов, основываясь на знании что важно прямо сейчас.

Обрезка scope: Когда план включает nice-to-have, я активно их вырезаю. «убери фичу скачивания из плана, я не хочу это реализовывать сейчас.» Это предотвращает расползание scope.

Защита существующих интерфейсов: Я ставлю жёсткие ограничения когда знаю что что-то не должно меняться: «сигнатуры этих трёх функций не должны меняться, вызывающий код должен адаптироваться, не библиотека.»

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

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

Одна длинная сессия

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

Я не вижу деградации производительности, о которой все говорят после 50% контекстного окна (контекстное окно). На самом деле, к моменту когда я говорю «реализуй всё», Claude провёл всю сессию выстраивая понимание: читая файлы во время исследования, уточняя ментальную модель во время циклов аннотаций, впитывая мои доменные исправления.

Когда контекстное окно заполняется, авто-компактизация Claude сохраняет достаточно контекста чтобы продолжать. А документ плана — постоянный артефакт — переживает компактизацию в полной сохранности. Я могу указать на него Claude в любой момент времени.

Рабочий процесс в одном предложении

Читай глубоко, пиши план, аннотируй план пока он не станет правильным, затем дай Claude выполнить всё без остановок, проверяя типы по ходу.

Вот и всё. Никаких магических промптов, никаких хитрых системных инструкций, никаких умных хаков. Просто дисциплинированный pipeline (пайплайн, конвейер обработки), который разделяет думание и печатание. Исследование не даёт Claude делать невежественные изменения. План не даёт делать неправильные изменения. Цикл аннотаций внедряет моё суждение. А команда реализации позволяет ему работать без прерываний, когда каждое решение уже принято.

Попробуйте мой рабочий процесс, и вы будете удивляться как вообще что-то выпускали с кодинг-агентами без аннотированного документа плана между вами и кодом.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot