How to Actually Use Claude Code to Build Serious Software

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

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

Дайте Claude увидеть ваше приложение

Прежде всего, для базовых задач подойдёт любой тариф Claude Code. Но как только вы начинаете использовать его более интенсивно — для построения фич, для тестирования, для фоновых процессов — вы, скорее всего, превысите лимит тарифа за $20 в месяц. Тариф Max — это то, что я бы рекомендовал на данном этапе, потому что тогда можно просто оставлять его работать. Через секунду вы поймёте, почему это важно.

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

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

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

И Claude это сделает. Он воссоздаст ситуацию, сделает скриншоты и реально исследует, что происходит, погружаясь как в визуальную, так и в иерархическую структуру страницы.

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

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

Цикл Ральфа Виггама

Одно из крупнейших изобретений в области удобства агентных систем — это плагин Ralph Wiggum, или цикл Ralph Wiggum.

Это может прозвучать неожиданно. Очевидно, Ralph Wiggum — персонаж из «Симпсонов». Какое это имеет отношение к агентному кодингу?

Дело в том, что Ralph воплощает философию упорной итерации вопреки неудачам. Ты пробуешь что-то, не получается, пробуешь снова, не получается, пробуешь снова — пока в конце концов не получится. В этом и состоит вся идея этого петлевого подхода.

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

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

Работает это так: вы описываете задачу, и Claude над ней работает. Он пытается выйти из задачи, но stop-hook блокирует выход. Stop-hook возвращает тот же промпт обратно, и пока задача не выполнена, этот цикл просто продолжается.

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

У меня сильное ощущение, что Claude Code в итоге внедрит эту методологию в основной цикл. Но прямо сейчас именно этот плагин даёт вам такое поведение.

Разрешения: что разрешать, что ограничивать

Разрешать и ограничивать что-то для Claude Code — это довольно критично. Вам не хочется постоянно сидеть рядом и говорить: «Да, можешь это сделать. Да, тебе разрешено запустить эту команду».

Команды, про которые вы знаете, что их совершенно нормально запускать автоматически без подтверждения, вы хотите сохранить как разрешения в массиве allow в вашем settings.local.json. Claude Code сделает это за вас, если вы скажете «Да, и разреши это в будущем», — он автоматически добавит соответствующую строку.

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

Но не менее важно заглянуть в массив deny в настройках разрешений.

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

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

Если вы используете PHP и Laravel, как я, вы наверняка захотите добавить php artisan db:wipe, migrate:fresh или команды db:* в deny-список. Как только это в deny-списке, Claude попробует, у него не получится, он остановится и спросит вас. В этот момент вы сможете разобраться, что агент сейчас пытается сделать. Он реально пытается удалить мою базу? Если да, то какую? Тестовую? Это нормально. Мою dev? Скорее нет. Мою prod? О боже, нет.

Вот в чём реально помогают deny-разрешения.

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

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

Тестирование — там, где Claude Code блистает

Мой последний совет по эффективному использованию Claude Code: просите его писать тесты для каждой вещи, которую он строит.

Тестирование с Claude Code — крайне просто. Он умеет писать тесты под язык, под фреймворк, на котором вы работаете. Он умеет их выполнять. Он умеет выполнять их безопасно, если вы это правильно определите.

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

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

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

Постройте прочный системный промпт

Чтобы системный промпт был эффективным, он должен быть самодостаточен. Если посмотреть на инструменты Augster — это A-U-G-S-T-E-R — у них есть репозиторий на GitHub, содержащий промпт Augster, которым я давно пользуюсь. Это очень специфический системный промпт, который побуждает Claude Code работать в цикле, отчасти как Ralph Wiggum, но более конкретно — как определение того, как выглядит хороший код. Это скорее описание результата, а не процесса.

Я всё же рекомендую построить прочный системный промпт для вашего проекта. Хороший системный промпт должен содержать:

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

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

Собираем всё вместе

Очевидно, всё это меняется чуть ли не еженедельно. Но прямо сейчас, имея системный промпт, который поощряет тестирование, пару вещей, которые вы разрешаете автоматизировать, пару вещей, которые ограничиваете, чтобы не снести вашу локальную систему, операционный цикл вроде Ralph Wiggum или промпт Augster и доступ к браузеру через флаг Chrome, — вы, вероятно, окажетесь в топ-1–2% пользователей Claude Code на этом этапе.

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

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

Опубликовано Arvid Kahl

Я пишу о бутстреппинге, выстраивании аудитории и публичной разработке в The Bootstrapped Founder. В прошлом — FeedbackPanda (exit/2019). Написал Zero to Sold, The Embedded Entrepreneur и сделал Find your Following. View all posts by Arvid Kahl