Как использовать Claude Code: пять сценариев, которые окупаются

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

Чем Claude Code отличается от автодополнения в редакторе

Копилоты в IDE дописывают строку или функцию, глядя на открытый файл и соседние вкладки. Claude Code работает иначе: я даю ему задачу на человеческом языке, а дальше он сам решает, какие файлы читать, какие команды запускать в терминале, что искать по репозиторию, и возвращается с готовым результатом - диффом, тестами или объяснением. Он видит весь проект, а не один файл, и может сам прогнать тесты после правки, увидеть красный результат и исправить себя же.

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

На старте я и сам относился к этому скептически: казалось, что для реальных задач всё равно проще открыть файл самому и поправить руками. Переубедили не рекламные ролики про агентов, а конкретные часы, которые перестали уходить на рутину на нескольких проектах подряд.

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

Сценарий 1. Вход в чужой проект без документации

Свежий пример: взял в техподдержку интернет-магазин на WooCommerce с оплатой через Т‑Банк и доставкой СДЭК, документации ноль, прежний разработчик недоступен. Раньше на такие проекты у меня уходил целый рабочий день только на чтение кода: где обрабатывается вебхук от эквайринга, как считаются статусы заказа, куда прикручена доставка.

С Claude Code я начал с вопроса в духе «объясни, как проходит заказ от оплаты до передачи в СДЭК, и покажи, где обрабатывается вебхук от Т‑Банка». Агент прошёлся по плагинам и кастомным хукам темы, нашёл обработчик и собрал схему в виде списка файлов и функций. По моему опыту, на такое ушло около двух часов вместе с проверкой, день сократился до утра.

Важная оговорка: агент читает код, а не документацию у клиента в голове. Он не знает, почему кто-то пять лет назад захардкодил скидку 7% для одной категории товаров, может только предположить причину. Всё, что касается бизнес-логики и денег, я перепроверяю руками, а не принимаю объяснение агента как факт.

Сценарий 2. Массовая правка кода по всему проекту

Другой проект: Laravel-бэкенд, где статус заказа хранился строкой в четырёх местах с разным написанием одного и того же значения на русском и английском. Нужно было привести всё к единому enum и поправить все места, где статус сравнивается напрямую со строкой, включая старые миграции и очереди.

Ручной поиск-замена в таком случае почти гарантированно что-то ломает: часть сравнений идёт через строгое равенство, часть через in_array, часть зашита прямо в шаблоны отчётов. Я описал Claude Code задачу целиком: найти все места использования статуса, свести к одному enum-классу, поправить сравнения, прогнать тесты. Агент прошёл по всем найденным местам за один заход, а не по первому попавшемуся совпадению, и после каждой правки гонял PHPUnit, чтобы не сломать соседний модуль.

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

Сценарий 3. Генерация тестов на существующий код

Тесты чаще всего пишут в двух случаях: с нуля на новом проекте или задним числом перед рискованным рефакторингом старого. Второй случай - самый частый повод, с которым ко мне приходят: систему трогать страшно, тестов нет, а менять надо.

На одном таком Laravel API я попросил Claude Code не придумывать идеальные тесты, а зафиксировать текущее поведение: пройтись по контроллерам и сервисному слою, написать PHPUnit-тесты на то, что код делает сейчас, включая странности вроде скидки, которая не применяется к товарам определённой категории. Это тесты-характеристики, они не про то, как правильно, а про то, что сейчас так и есть, чтобы после рефакторинга ничего не отвалилось незаметно.

Агент неплохо справляется с механической частью: разложить кейсы, накидать моки, покрыть ветвления условий. Слабое место - бизнес-правила, которые нигде явно не написаны, а держатся в голове у заказчика. Из сгенерированных тестов часть, обычно один из пяти-шести, приходится переписывать: агент неверно понимает бизнес-правило и фиксирует текущий баг как ожидаемое поведение. Такие тесты я всегда читаю целиком, а не смотрю только на зелёный статус в консоли: зелёный тест на неправильном ожидании хуже, чем его отсутствие.

Сценарий 4. Разбор бага по логам и стектрейсу

Telegram-бот на aiogram у одного клиента падал ночью раз в несколько дней, в логах глухой стектрейс без явной причины, воспроизвести на локальной машине не получалось. Раньше такой баг вылавливался часами: расставляешь логирование, ждёшь следующего падения, смотришь заново.

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

Чинили классически, без экзотики: обновление состояния завернул в транзакцию с уникальным индексом на связку идентификаторов пользователя и чата в MySQL, второй параллельный апдейт теперь просто не проходит, а не роняет процесс. Ничего из этого не потребовало отдельной базы или очереди, хватило того, что уже было в MySQL.

Сценарий 5. Фоновые задачи, которые Claude Code гоняет ночью

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

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

Утром смотрю не код целиком, а диф по каждой задаче отдельно: что менялось, какие тесты прогнались, что агент не смог сделать и почему. Часть правок мёржу сразу, часть откатываю, например если обновление зависимости зацепило API, которое агент не проверил в реальном окружении.

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

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

Все пять сценариев объединяет одно: агент экономит время на механической части - чтении, поиске, черновике правки или теста, а решения по бизнес-логике, деньгам и архитектуре остаются за мной. На разовых мелких правках вроде одной строчки в конфиге эффект обратный: написать задачу и проверить результат дольше, чем поправить самому. Если непонятно, с каких задач начать внедрение в своей команде, проще один раз обсудить конкретные процессы, чем угадывать наугад, для этого у меня есть консультация.

Условия и возможности Claude меняются, поэтому перед запуском я уточняю их у самого сервиса.

Частые вопросы

Нужно ли уметь программировать, чтобы использовать Claude Code?

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

Можно ли доверять сгенерированному коду без проверки?

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

С чего начать, если раньше не пробовал Claude Code в работе?

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

Заменяет ли Claude Code разработчика?

На задачах из статьи - нет, ускоряет конкретного разработчика на конкретных этапах: чтении чужого кода, черновике теста, поиске причины бага. Решения о том, что мёржить, как трактовать бизнес-правило и где не экономить на проверке, всё равно принимает человек, который отвечает за проект.