Claude Code: как использовать в разработке

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

Чат ждёт вопрос. Claude Code заходит в проект, читает файлы, предлагает правки, запускает команды и может довести задачу до состояния "можно смотреть diff". Иногда это экономит вечер. Иногда приносит уверенный баг в трёх файлах.

Нормальная работа начинается не с магического промпта, а с рамок: что можно читать, что менять, какие команды запускать и как проверять результат.

Если вы только разбираетесь в теме, начните с базы: что такое ИИ-агент.

Основа статьи — проверенные сценарии из документации Anthropic по Claude Code: работа с кодовой базой, файлами, shell-командами, permissions, CLAUDE.md, hooks и типовыми workflow. Частотности, позиции и кейсы с цифрами здесь не используются.

Что такое Claude Code

Claude Code — агентный инструмент Anthropic для разработки. Он работает в терминале, IDE, desktop/web-режимах, читает кодовую базу, редактирует файлы и запускает shell-команды.

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

Он хорош там, где задача живёт в проекте: код, тесты, Git, документация, конфиги, миграции.

Для каких задач он подходит

Самые удачные задачи обычно звучат скучно:

• найти, где собирается конкретный экран или API-ответ;
• объяснить, почему тест падает;
• добавить проверку, обработчик, поле, флаг, логирование;
• написать тесты к существующей логике;
• обновить документацию после изменения кода;
• пройтись по diff и найти подозрительные места.

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

Плохой запрос: "улучши проект". Хороший запрос: "найди, где формируется invoice PDF, добавь туда ИНН клиента, обнови тесты и покажи список изменённых файлов".

Во втором случае агенту дали карту, финиш и способ проверки.

Как запускать задачу без хаоса

Перед стартом сделайте четыре вещи.

Первое: откройте чистую ветку. Не работайте в main, если задача меняет код.

Второе: сформулируйте задачу через результат. Не "посмотри авторизацию", а "почини сценарий, где пользователь с истёкшим токеном получает 500 вместо 401".

Третье: назовите ограничения. Например: "не менять публичный API", "не трогать схему базы", "сначала предложить план".

Четвёртое: попросите отчёт: какие файлы изменил, какие команды запускал, какие тесты прошли, что осталось непроверенным.

Пример промпта:

Нужно починить баг: при истёкшем access token запрос к /api/profile возвращает 500.
Ожидаемое поведение: 401 и понятный JSON error.
Сначала найди место ошибки и предложи план.
Не меняй схему базы и публичный контракт ответа, кроме статуса и error message.
После правки запусти релевантные тесты и покажи diff по файлам.

Скучный запрос. В разработке это комплимент.

Файлы, контекст и память проекта

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

Для этого используют инструкции проекта: например, CLAUDE.md или настройки внутри .claude. Туда стоит положить не философию компании, а рабочие правила:

• как запустить тесты;
• какой package manager использовать;
• какие директории не трогать;
• какие команды требуют ручного подтверждения.

Плохо: "пиши хороший чистый код". Это молитва у кофемашины.

Лучше: "для backend запускай npm test -- --runInBand; не меняй файлы в generated/; перед изменением миграций спроси подтверждение; ошибки API оформляй через AppError".

Если проект использует внешние инструменты через MCP, заранее опишите, зачем они нужны. Подробнее: MCP server: что это. Чем больше инструментов, тем важнее права доступа и логирование.

Git, тесты и контроль результата

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

Рабочий цикл лучше держать таким:

1. Создали ветку.
2. Дали задачу и ограничения.
3. Попросили план.
4. Разрешили правки.
5. Посмотрели diff.
6. Запустили тесты.
7. Прочитали итоговый отчёт.
8. Только потом коммит.

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

Нормальная инструкция:

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

После генерации тестов смотрите руками: тест правда падает без правки или всегда зелёный; проверяется поведение пользователя; команда запуска записана в отчёте.

Рефакторинг без героизма

Claude Code хочется дать большую задачу: "перепиши старый модуль нормально". Чаще вы получите огромный diff, где трудно понять, что улучшилось, а что просто переехало.

Безопаснее резать рефакторинг на куски:

• сначала объясни текущую структуру;
• найди дубли;
• предложи план без правок;
• вынеси одну функцию;
• запусти тесты;
• остановись и покажи diff.

Хороший рефакторинг скупо меняет код. Если агент тронул 28 файлов ради одной функции, открывайте diff и спрашивайте: "Зачем?"

Безопасность и доступы

Claude Code умеет запускать команды и менять файлы. Значит, ему нужны границы.

Не давайте агенту секреты в промпте. Не просите вставлять production-токены в конфиги. Не разрешайте удаление данных, миграции и push без подтверждения.

Полезные правила для команды:

• отдельная ветка под каждую задачу;
• минимум прав на локальной машине и в облаке;
• секреты только через штатные env/secret manager;
• опасные команды требуют ручного подтверждения;
• агент пишет отчёт по изменённым файлам и запущенным командам;
• человек смотрит diff перед merge.

В новом проекте начинайте осторожно: сначала чтение и план, потом точечные правки.

Как понять, что результат можно принимать

Не принимайте работу Claude Code по ощущению "вроде звучит уверенно". Уверенность у моделей дешёвая. Дорого стоит проверка.

Минимальный чек-лист:

• diff соответствует задаче;
• нет случайных изменений форматирования на полпроекта;
• тесты запущены и команда известна;
• поведение проверено вручную, если тестов мало;
• нет секретов, временных файлов, лишних логов;
• агент явно написал, что не успел или не смог проверить;
• вы понимаете каждое изменение перед коммитом.

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

Если хотите собрать похожего помощника под бизнес-процессы без кода, посмотрите: как создать ИИ-агента без программирования.

Claude Code хорошо работает не тогда, когда ему верят. Он хорошо работает, когда его проверяют.

@yourself_realize

Больше практики — в Telegram

Разбираю AI-инструменты, разработку с агентами и автоматизацию без сказок про волшебную кнопку.

Подписаться