Claude Code: как ставить задачу ИИ-агенту в разработке и проверять его код

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

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

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

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

Критерий	Чат без доступа к проекту	Агент в проекте
Откуда контекст	вы описываете его в запросе	агент читает файлы проекта сам
Кто выполняет действия	вы копируете код и команды	агент запускает команды и правит файлы
Как проверяется результат	вы сами запускаете проверки	агент запускает тесты и линтер, вывод возвращается к нему
Главный риск	ответ не учитывает проект	агент делает лишнее или не останавливается

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

Возможности агента делятся на четыре группы:

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

Последнее не стоит переоценивать. Агент чинит код, пока тесты не пройдут, но тесты проверяют только то, что в них написано: если бизнес-правило в них не попало, агент его не заметит. Удобнее всего поручать агенту локальные изменения с ясными критериями и тестами. Миграции базы данных — отдельный случай: они затрагивают данные, поэтому для них нужны свой план, резервная копия и ревью.

Как поставить задачу агенту

Качество результата зависит не от длины запроса, а от полноты значимых ограничений. Агенту формулировать нужно точнее, чем человеку: фраза вроде «проверь проект и сделай красиво» для него слишком размыта.

Пять вопросов, на которые должна отвечать каждая постановка:

1. Что входит в задачу?
2. Что должно получиться на выходе?
3. Чем проверяется результат и какими инструментами?
4. Что агенту запрещено?
5. Когда он обязан остановиться?

Сквозной пример на всю статью — учебный внутренний сервис заявок на Python: сотрудники пишут заявки в техподдержку (например, на доступ к системе или ремонт ноутбука), исполнители меняют их статус. Задача для агента — запретить переход заявки из статуса «закрыта» обратно в «в работе» и покрыть это тестами. Две плохие постановки и одна рабочая:

Постановка	Пример	Чего не хватает
Плохая	«Проверь проект и сделай красиво»	нет входа, выхода, проверки и запретов
Плохая	«Почини, почему упал прод»	нет источника, по которому сверять результат, нет точки остановки
Рабочая	«Прочитай ticket-142.md и CLAUDE.md. Запрети в app/status.py переход «закрыта» -> «в работе», добавь тесты на запрещенный и разрешенный переход. Меняй только app/status.py и tests/, прогони pytest и ruff. Если нужно менять другие файлы — остановись и спроси»	закрыты все пять вопросов

Хорошая первая задача имеет ясные вход и выход, проверяется локально и легко откатывается. Плохие кандидаты — управление релизом, выкатка в прод, задачи с неясным контекстом, продовые секреты и платежи.

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

Шаблон постановки на примере

Та же рабочая постановка, разложенная по строкам:

Задача: в сервисе заявок запретить переход заявки из статуса «закрыта» обратно в «в работе».
Источники: ticket-142.md (описание и критерии приемки), CLAUDE.md, модуль app/status.py.
Порядок: сначала план и список файлов, которые изменятся, без правок. После моего подтверждения - правка и тесты на каждый критерий приемки.
Разрешено: читать проект, менять app/status.py и файлы в tests/, запускать тесты и линтер.
Запрещено: менять другие модули, миграции и зависимости, коммитить в main.
Проверка: python -m pytest и ruff check . проходят; есть тест на запрещенный переход и тест на разрешенный; новый тест падает на старом коде.
Результат: короткий отчет - что изменено, какие тесты добавлены, вывод команд проверки.
Остановка: если критерий приемки противоречит коду или нужно менять файлы вне списка - остановиться и спросить.

Строки шаблона закрывают пять вопросов: «Задача» и «Источники» — что входит, «Результат» — что выходит, «Проверка» — чем проверяется, «Запрещено» — что агенту запрещено, «Остановка» — когда он обязан остановиться. «Порядок» и «Разрешено» уточняют, что агент может делать.

Если хотите отработать постановку задач агенту на своем проекте под присмотром практикующих разработчиков, записывайтесь на курс «Claude Code: от нуля до ИИ-агента».

Постоянный контекст: CLAUDE.md

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

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

CLAUDE.md — это инструкция для модели, а не техническая защита: модель старается ее выполнять, но может и нарушить. Чем конкретнее и короче файл, тем стабильнее правила выполняются. Документация советует держаться в пределах порядка 200 строк на файл — это рекомендация, а не жесткий лимит. У других агентов для кода аналогичный файл называется иначе, например AGENTS.md, и Claude Code умеет читать его вместо CLAUDE.md.

Пример CLAUDE.md

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

# Сервис заявок

## Назначение и границы
- Внутренний сервис: сотрудники создают заявки в техподдержку, исполнители меняют их статус.
- `app/` - API и бизнес-логика, `tests/` - автотесты, `migrations/` - миграции БД.
- Платежей, данных клиентов и внешних интеграций в проекте нет.

## Стек
- Python 3.12, FastAPI, SQLAlchemy, pytest.
- Новые зависимости не добавлять без согласования.

## Команды
- Установить зависимости: `pip install -r requirements.txt`
- Все тесты: `python -m pytest`
- Один файл тестов: `python -m pytest tests/test_status.py`
- Линтер: `ruff check .`

## Правила работы
- Работать только в отдельной ветке, не в main.
- Не менять `migrations/` и `.env`, не выводить и не коммитить секреты.
- Перед правкой кода - план и список файлов, которые изменятся.
- Задача выполнена, когда тесты и линтер проходят, поведение сверено с критериями приемки из тикета, а инженер просмотрел diff; в отчете - команды и их вывод.
- Если тест падает по причине вне задачи - остановиться и описать причину, не чинить.

Сначала план, потом код

Большую задачу стоит делить на этапы: спроектировать — реализовать минимальную часть — проверить — исправить — зафиксировать и только потом продолжать. Так вы видите результат каждого шага, и агент не уходит в сторону.

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

Для этого в Claude Code есть режим планирования: агент читает и исследует проект, предлагает план, но не правит файлы, пока вы план не одобрите. Включить его можно тремя способами: нажимать Shift+Tab, пока внизу не появится «plan mode on»; начать отдельный запрос с команды /plan; запустить сессию командой claude --permission-mode plan.

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

Что агенту можно делать без вас: режимы и правила

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

Режимы разрешений

Режим	Что агент делает без запроса	Когда рассматривать
Ручной (default)	только читает; перед правками файлов, командами и выходом в сеть спрашивает	первый опыт, незнакомый проект
Автопринятие правок (acceptEdits)	правит файлы и выполняет часть обычных файловых команд (создать папку, переместить, скопировать) в рабочей папке; остальные команды и запись в служебные папки вроде .git и .claude — по запросу	типовые задачи в знакомой кодовой базе
Планирование (plan)	читает и исследует, файлы не правит до одобрения плана	этап проектирования
Автоматический (auto)	часть действий перед запуском оценивает отдельная модель-классификатор: например, блокирует скачивание и запуск чужого кода, выкатку в прод и принудительный push	когда нужно меньше ручных подтверждений
Обход разрешений (bypassPermissions)	выполняет все без запросов	только в изолированной среде: контейнер или виртуальная машина без доступа в интернет

Режим переключают сочетанием Shift+Tab в терминале (оно перебирает ручной, автопринятие правок и планирование, а автоматический — если он доступен), флагом при запуске, например claude --permission-mode acceptEdits, или ключом defaultMode в файле настроек. В VS Code и в приложении Claude для компьютера режим выбирают переключателем рядом с полем ввода.

Автоматический режим уменьшает число ручных подтверждений, но не заменяет заданные запреты: документация прямо предупреждает, что безопасности он не гарантирует. А запрет, произнесенный в переписке («не пушь»), классификатор учитывает, но правилом он не становится и может потеряться, когда длинная сессия сжимается.

Правила: запрет, подтверждение, разрешение

Правила хранятся в файлах настроек, посмотреть и изменить их можно командой /permissions. Каждое правило относится к одному из трех списков: запретить (deny), спрашивать (ask), разрешить (allow). Например, правило Read(./.env) в списке запретов не дает агенту прочитать файл с секретами, а Bash(git push *) — отправить изменения на сервер.

Порядок проверки простой. Сначала Claude Code смотрит запреты, потом правила «спрашивать», потом разрешения, и первое совпадение решает. Поэтому широкий запрет нельзя обойти узким разрешением: если запрещены все команды git push, разрешение на одну из них не сработает.

Главное отличие правил от CLAUDE.md: правила выполняет сам Claude Code, а не модель. Строку «не читай .env» в CLAUDE.md модель может нарушить, например когда отлаживает ошибку подключения к базе и ищет пароль. Запрет Read(./.env) Claude Code применяет сам: правило закрывает файл для встроенных файловых инструментов агента и для команд, которые Claude Code распознает, например cat .env. Но это не защита на уровне системы: скрипт на Python или Node, который запустит агент, может открыть файл сам, и правило его не остановит. Чтобы файл был недоступен любому процессу, нужна песочница Claude Code (sandbox) с ограничением доступа к путям или секрет, которого в окружении агента просто нет. Для проверок сложнее одного шаблона есть хуки — ваши скрипты, которые Claude Code запускает перед действием агента; хук может действие заблокировать.

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

Практика безопасности:

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

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

Основные риски и что от них защищает:

Риск	Мера	Чего мера не делает
Агент меняет файлы вне задачи	запрет в постановке, работа в отдельной ветке	не заменяет ревью diff
Секреты попадают в код или вывод	запрет на чтение файлов с секретами в правилах, секретов нет в доступном агенту окружении, проверка diff и вывода	строка в CLAUDE.md — только просьба к модели; хук защищает, только если он правильно настроен и проверен
Утечка персональных данных	обезличивание перед отправкой в облако	не делает данные анонимными
Внедренные инструкции в чужом тексте	правила-запреты, изоляция, проверка команд перед одобрением	ни одна система не защищена полностью
Опасная команда в продакшене	песочница, запрет доступа к прод-окружению	песочница дополняет ревью, а не заменяет

Как проверить код, который написал агент

Тесты прошли — в отчете CI они «зеленые», — но это еще не значит, что программа делает то, что нужно: тесты могут быть неполными или проверять не то. Агент экономит время, но каждую итерацию проверяет человек. Отвечает за код инженер, который отдал задачу агенту. Код-ревью и сканирование безопасности остаются обязательными: агенты пишут код с уязвимостями и ошибаются в интеграции.

Чек-лист ревью:

1. Изменения только в заявленных файлах.
2. Агент показал доказательства — команды и их вывод, а не «готово».
3. Новый тест падает на старом коде и проходит на новом.
4. Тесты проверяют бизнес-правило, а не повторяют реализацию.
5. Тесты маленькие: подготовка данных — действие — проверка ожиданий.
6. Линтер и CI проходят.
7. Нет секретов, лишних зависимостей и потенциально уязвимых мест, сделано сканирование безопасности.
8. Архитектура не превратилась в разрастающийся код без структуры.
9. Изменения принимает инженер; второй агент может помочь с независимым ревью diff, критериев и нужного ему контекста проекта.

Для нашей задачи приемка выглядит так. Первое: тест пытается перевести закрытую заявку в работу, сервис отклоняет переход, и статус остается «закрыта». Второе: разрешенный переход, например из «в работе» в «закрыта», по-прежнему работает. Третье: в diff изменены только app/status.py и файлы в tests/. Если хотя бы одно не выполнено, задача не закрыта, даже если все тесты проходят.

Второй агент в свежей сессии полезен как ревьюер: он не писал этот код и не склонен его защищать. Но ему нужен контекст проекта, иначе замечания будут нелогичными. Учтите и другое: ревьюер, которого попросили найти недочеты, найдет их почти всегда. Инженер принимает только те замечания, которые обоснованы и влияют на корректность или требования задачи.

Тесты можно развести по сессиям: одна пишет тесты по критериям из тикета, другая — код, который должен их пройти. Тогда агент, который пишет код, не может подогнать тесты под свою реализацию.

Типовые сбои и что с ними делать:

Симптом	Причина	Что сделать
Агент менял файлы вне задачи	слабые запреты в постановке	дописать запреты, проверить diff, откатить лишнее
Агент бесконечно исследует проект	нет точки остановки	добавить в постановку условие остановки
Агент игнорирует правило из CLAUDE.md	правило слишком длинное или размытое, а CLAUDE.md — только инструкция	сократить файл, критичное вынести в правило-запрет или хук
Тесты проходят, но поведение неверное	тесты проверяют реализацию, а не правило	переписать тесты на бизнес-критерии
После двух исправлений агент повторяет ошибку	контекст засорен неудачными попытками	начать новую сессию с уточненной постановкой
Агент не задал уточняющих вопросов и додумал сам	модель посчитала что-то очевидным	прописать источники и запрет додумывать

Когда агент не нужен

Агент — инструмент для задач с ясными границами, а не замена инженеру. Есть случаи, где он не оправдан:

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

Выводы

• Точная постановка задает границы и критерии проверки: пять вопросов — что входит, что выходит, чем проверяется, что запрещено, когда остановиться — важнее длины запроса. Результат все равно сверяют с этими критериями.
• CLAUDE.md — просьба к модели, а правила разрешений и хуки Claude Code выполняет сам. Но и правила закрывают не все: то, что не должно случиться никогда, обеспечивают изоляцией — песочницей, отдельной средой, отсутствием секретов в окружении агента.
• Проходящие тесты — не приемка: код принимает инженер по критериям задачи и diff.

Как освоить работу с Claude Code на практике

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

Смежные темы: Как создать ИИ-агента, Непрерывная интеграция (CI), RAG в LLM.

FAQ

Можно ли писать задачи и CLAUDE.md по-русски?
Да. Постановки и CLAUDE.md можно писать на русском, агент будет работать с ними так же.

Можно ли работать с Claude Code через другие модели?
Claude Code рассчитан на модели Claude, в том числе через облачные платформы крупных провайдеров. Подключение сторонних моделей через обертки — неофициальный путь, и поведение агента на них никто не гарантирует.

Нужно ли уметь программировать, чтобы ставить задачи агенту?
Описать цель можно без глубоких навыков. А проверять план, diff и тесты и принимать изменения должен тот, кто понимает код и требования к нему.