После глав 1 и 2 должно быть понятно, что такое Claude Code и как он работает. В этой главе мы строим ритм, который можно повторять каждый день в одной и той же форме: четыре такта — разведка, план, реализация, коммит.
Зачем нужна форма, видно сразу. Причина неудачного дня почти всегда в том, что такт пропустили. Дали писать, не дав прочитать; поручили работу, не дав способа проверки; гнали дальше, не ставя рубежей. Симптомы разные, а возвращаться приходится в одно и то же место.
Форма одного дня: четыре такта
Дать прочитать связанные файлы и проговорить словами текущее положение. Писать пока не даём.
Пусть сначала выдаст порядок действий, а вы его поправите. Единственная дешёвая точка правки.
Дать написать и тут же прогнать проверку. Пусть цикл из главы 1 провернётся до конца.
Как только прошло, поставить точку возврата. Следующая разведка начнётся отсюда.
Ориентир для одного круга: если вы уже не можете вспомнить, что происходило по дороге, круг слишком велик. Четыре круга по часу почти всегда устойчивее, чем один на полдня.
Это не значит «каждый раз делать всё». Для исправления опечатки план не нужен. Решать нужно, какой такт можно опустить, а исходная установка — «делать все».
Прежде чем начать, дайте способ проверки
До входа в четыре такта есть одно дело, которое делают один раз: заранее дать Claude способ проверять самого себя.
Как мы видели в главе 1, внутри крутится цикл сбор → действие → проверка. Сила его в наличии STEP 3: он может сам править, пока тесты не пройдут. И наоборот — без способа проверки цикл останавливается после первого же круга: написал, наверное правильно, конец. Ровно как в чате.
Хватает «прогони тесты». Вывод об ошибке становится следующим входом, и цикл крутится, даже когда вы не смотрите.
Запускаете вы, сообщаете результат и снова даёте писать. Узким местом становитесь вы. Ощущение делегирования — и только.
Передавать что-то громоздкое не требуется. Хватит одной строки в духе «выполни эту команду, и станет ясно, верно ли». И надёжнее записать это в файл, чем сказать вслух: CLAUDE.md в корне проекта перечитывается с диска даже после сжатия контекста.
Что стоит записать в CLAUDE.md (пример)
- команды, которые прогоняются после изменений: тесты / проверка типов / линтер
- не докладывать «готово», пока они не прошли
- места, которые трогать нельзя (сгенерированное, боевые настройки и т. п.)
Записав это, вы получаете вот что: он начинает проверять себя после каждого изменения, и говорить «протестируй» больше не нужно. Уменьшается не число указаний, а число ситуаций, где указание вообще требуется. Так и работает форма (как это писать — глава 6). Задачи, отнесённые в главе 1 к «не подходит», отваливаются здесь именно потому, что для них нечего дать в качестве проверки.
Разведка: сначала читать, потом писать
Такт первый. Дело одно: дать прочитать связанные файлы и заставить объяснить, как всё устроено сейчас. Писать пока не даём. Если этот такт пропустить, Claude достроит непрочитанное догадками. Вернётся правдоподобный код, слегка расходящийся с принятым в проекте стилем, а заметите расхождение вы на ревью или в бою.
Плохая разведка: «Почини всё вокруг аутентификации»
→ правки начинаются сразу. на что он опирался, непонятно
Хорошая разведка: «Найди и прочитай файлы, связанные с аутентификацией.
Объясни, как сейчас обрабатывается вход,
и приложи список задействованных файлов.
Пока ничего не меняй»
→ предпосылки видны на экране. если они разошлись, правим здесь
Полученное объяснение прочитайте. Это самая дешёвая точка вмешательства. Одна фраза «этот файл уже не используется» стоит в десятки раз меньше, чем обнаружение неверной реализации на ревью.
И ещё: у разведки есть цена. Прочитанные файлы ложатся в контекст, поэтому чем шире разведка, тем меньше запаса останется дальше. Из этого и вырастает «заполняется, вялеет, забывает начало» из главы 1. Сдерживать можно тремя способами.
- Ограничьте область: «пока только аутентификация». Общая картина нужна, все файлы — нет
- Огромные файлы читайте частями: целиком они забивают контекст разом. Обычно хватает диапазона строк или отдельной функции
- Разборы с большим выводом выносите отдельно: изучение логов и массовый поиск отдавайте субагентам. У них свой контекст, а возвращается только сводка, поэтому основной не разбухает (глава 6)
План: когда режим планирования помогает, а когда тяжёл
Такт второй. Пусть до начала письма выдаст, что и в каком порядке будет меняться. Для этого такта в Claude Code есть режим планирования: он останавливается на том, что изучил и предъявил план, и не переходит к записи, пока вы не согласуете. Способ переключения меняется от версии к версии, так что сверьтесь со справкой своей.
Суть в том, чтобы перенести ворота разрешений с «каждой правки» на «вход в работу». По умолчанию подтверждение приходит при каждом вызове инструмента, а режим планирования собирает их в одно и выносит вперёд. И согласовываете вы не «эту строку», а «подход к этой работе».
Затрагивает несколько файлов / есть два и более способа сделать / нужно вписаться в существующую архитектуру / откат при ошибке хлопотный / вы и сами ещё не выбрали лучший ход
Дело всего одно / порядок действий уже определён / неудачу можно откатить мгновенно / читать план дольше, чем реализовывать
Правую колонку смело пропускайте. План не бесплатен: он съедает время на составление, время на чтение и контекст. Получив его, смотрите всего на три вещи. Во-первых, верны ли предпосылки (если первый такт ушёл в сторону, план уйдёт туда же целиком). Во-вторых, есть ли в нём проверка (нет «прогнать тесты» — добавьте). В-третьих, достаточно ли мелкое дробление (по плану, где всё делается одним ходом, при неудаче не найти причину).
Для долгой работы план стоит вынести в файл. План, живущий только в разговоре, при длинной сессии сомнётся в сводку. Если попросить выписать его в место вроде PLAN.md, его можно перечитать даже после свёртки контекста, и он же станет точкой возобновления, когда вы отошли и вернулись.
Реализация: мелкими шагами, правя на ходу
Такт третий. Вот теперь даём писать. Правил два.
Первое: прогоняйте проверку после каждого хода. Если сделать пять изменений и только потом запустить тесты, при падении появится отдельная работа — выяснять, какое из них виновато. Написали одно, прогнали одно — причина в последнем ходе. Это правило скорее для вас, чем для Claude.
Второе: вывод об ошибке передавайте как есть. Пересказывать своими словами не нужно. STEP 3 — это «прочитать вывод и вернуться к STEP 1», поэтому сырой вывод и есть самый информативный вход. Разжёвывание, наоборот, убирает зацепки.
Один круг реализации (дробим и повторяем)
[ПРАВКА] переписать ровно один пункт плана
↓
[ЗАПУСК] прогнать тесты и проверку типов
↓
зелено → к следующему пункту (или коммит)
красно → прочитать вывод и снова к [ПРАВКА]
если в одном месте три раза подряд красно, не гоните дальше
→ остановиться и перейти к локализации причины (глава 4)
Последняя строка — эмпирика. Начавшиеся повторы одной и той же ошибки чаще означают не «ещё чуть-чуть», а «предпосылка неверна».
Когда проверка длится долго — большая сборка, ожидание CI, — можно не сидеть рядом, а передать это на откуп. Claude Code умеет повторять указание с заданным интервалом, а если интервал не указать, Claude сам решает, когда заглянуть снова, и останавливает цикл, когда считает работу законченной. Как это устроено и чего не может — в статье Что такое команда /loop. Учтите: закрытие сессии останавливает всё это.
Коммит: рубеж вы ставите сами
Такт четвёртый. Тесты прошли — коммитьте прямо сейчас. Не «когда дойду до подходящего места», а момент, когда прошло, и есть подходящее место.
- Появляется точка возврата: даже если следующий ход не удастся, вы гарантированно вернётесь туда, где было зелено
- Диф остаётся читаемого размера: изменения за полдня не прочитать. Нечитаемый диф фактически не ревьюят
- Разговор можно обрывать: когда результат уже внутри, выбросить сессию не страшно
Сообщение коммита тоже можно поручить, но не согласовывайте, не посмотрев диф. Если решить, что смотрите не «что изменено», а «не затесалось ли то, что менять не собирались», глаз перестанет скользить.
И ещё: коммит и push — разные решения. Насколько отдавать трудно отменяемые операции вроде деплоя, разбираем в главе 5.
Как сворачивать сессию и как откатываться
Пройдя несколько кругов из четырёх тактов, вы обязательно упрётесь в заполняющийся контекст. Появились два симптома из главы 1 — ответы вялые, начало забыто, — пора сворачивать. Способа два: сжатие и начать заново, а развилка одна.
Если дальше «продолжение» — сжимайте: ход дела перейдёт дальше в виде сводки, и, в отличие от автоматического запуска, вы можете указать, что именно оставить. Если дальше «другое дело» — начинайте заново: раз не нужна даже сводка, не нужны и затраты на её составление. Заодно и точность выше, потому что за вами не тянется посторонняя работа.
У момента тоже есть форма. Нажимайте на рубеже работы, а не по часам и не по процентам: круг закончен, впереди длинный отрезок. Нажмёте посреди — детали, которые пригодились бы дальше, сомнутся в сводку. Обоснование — в статье Стоит ли запускать /compact регулярно.
Перед свёрткой выпишите в файл то, что нельзя потерять. CLAUDE.md в корне проекта и автоматическая память перечитываются с диска, поэтому переживут сколько угодно свёрток, а вот решения, живущие только в разговоре, размываются в сводке.
Есть ещё механизм, который меняет саму манеру делегирования. Claude Code автоматически создаёт точку возврата на каждый запрос, и, если что-то пошло не туда, к ней можно откатиться. Откатить можно на выбор только код, только разговор или и то и другое, и чаще всего используют «код вернуть, разговор оставить»: изменений будто и не было, но вы помните, что именно не получилось, и можете переформулировать.
Работает тут не удобство самой операции, а то, как вы обращаетесь с риском. Считая, что откатиться нельзя, вы подтверждаете каждый шаг, и смысл в агенте почти пропадает. Зная, что откат есть, можно отдавать крупными кусками, и попробовать, а если не вышло — выбросить становится вариантом.
Однако откатываются только «файлы, которые Claude менял инструментом правки». Файлы, созданные или удалённые командой оболочки, ваши собственные правки и состояние базы данных не вернутся. Это не замена Git и предполагает, что вы всё равно коммитите на узловых точках. Черта проходит так: работу, которая укладывается в правку файлов, отдавайте крупно. Работу, меняющую состояние через оболочку, коммитьте до того, как отдать. Подробности — в статье Контрольные точки и откат.
Ревью: развести того, кто писал, и того, кто читает
Код, прошедший тесты, не обязательно хорош. Тесты ручаются за «ничего не сломано», но не отвечают на вопрос «стоило ли писать именно так».
Правило одно: разведите контекст письма и контекст чтения. Если сказать «сделай ревью» тому же разговору, который только что дописал эту реализацию, он склонен подтвердить собственные решения. Состояние, где все причины выбора на виду, для придирок не годится. Конкретно — три приёма.
- Читать в отдельной сессии: закоммитьте, получите диф и отдайте в чистый разговор один только диф. Пусть читают глаза, не знающие предыстории
- Задать угол зрения: не «сделай лучше», а «граничные условия», «согласованность с принятым стилем». Расплывчатая просьба рождает расплывчатые замечания
- Не принимать замечания на веру: верность проверяйте на живом коде. Прежде чем давать править, сначала прочитайте
Третий пункт связан с остальной главой. Ревью — типичная «задача без способа проверки»: правильность не определяется автоматически, поэтому Claude уверенным тоном говорит и мимо цели. Если пустить такое прямо в указания на правку, вы сломаете код, который был верен. Обращайтесь с замечаниями как с кандидатами и разбирайте их по одному. А когда захочется гонять один и тот же набор углов зрения каждый раз, это знак, что пора превратить его в механизм (глава 6).
Несколько сессий: до какого предела это выгодно
Пока одна сторона гоняет долгие тесты, заняться другим делом — мысль возникает сама. Claude Code умеет поднимать несколько независимых сессий в фоне и управлять ими с одного экрана. Суть тут в изоляции: фоновая сессия переходит в собственный рабочий каталог, прежде чем править хоть один файл. Чтение общее, запись разделена, поэтому две сессии, затирающие один и тот же файл, по устройству невозможны. Подробности — в статье Agent view и диспетчеризация.
Задачи независимы друг от друга / промежуточный ход смотреть не нужно / достаточно решать по полученному результату / одна из них подолгу ждёт
Зависят от одного и того же решения по архитектуре / направление придётся пересматривать на ходу / включают неотменяемые операции / их столько, что результат вы всё равно не проверите
Последний пункт справа — самое действенное ограничение. Параллелизация увеличивает общий объём ревью. Запустив три задачи, вы получите три вопроса «а точно ли так», и работа по проверке параллельно не выполняется. Предел числа запущенных задач — то, сколько результатов вы способны проверить. Растут и расходы: «в фоне, значит дешевле» не работает (глава 7).
Прежде чем начинать параллель, пересмотрите настройки разрешений. Сессии, идущие в фоне, не выбирают режим на месте, а наследуют разрешения из настроек. У того, кто обычно держит их послабее, ровно по числу задач появится «сессия с ослабленными правами, за которой никто не смотрит». Сначала глава 5.
Незаметная, но частая причина происшествий — уборка. Рабочее место, созданное фоновой сессией, исчезает вместе с ней, когда сессию удаляют. «Закончено» и «забрано к себе» — разные вещи: коммитьте до удаления.
Итоги
- Ритм дня — четыре такта: разведка → план → реализация → коммит. Причина сбоев почти всегда в пропущенном такте
- Перед началом дайте способ проверки. Без него цикл сбор → действие → проверка встаёт после первого круга
- Разведка идёт до письма. Но прочитанное съедает запас, поэтому ограничивайте область
- План — механизм, собирающий ворота разрешений на входе в работу. Для дела в один ход он тяжёл
- Реализация проверяется после каждого хода, а после трёх неудач переходим к локализации причины. Коммит ставится в момент, когда прошло
- Свернуть или начать заново решает вопрос «дальше продолжение или другое дело». Прямо перед свёрткой выписывайте в файл
- Откат возвращает только правки файлов. Изменения через оболочку не вернутся, поэтому сочетайте с коммитами
- Ревью отделяйте от контекста письма, а замечания считайте кандидатами. Предел параллели — сколько вы можете проверить
Форма формой, а застревать всё равно случается. Пусть следующая глава даст вам порядок локализации причины. Переходите к главе 4 «Как выбраться из тупика».