В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.
Поводом для этой статьи стала заметка Anthropic «Getting started with loops» про циклы (loops) в Claude Code. Там термин«цикл» описывается как повторяющаяся работа агента до выполнения условия остановки.
Практический смысл такой: если задача состоит из нескольких повторяемых шагов, человеку не нужно каждый раз вручную читать вывод агента, запускать проверку, копировать ошибку обратно в чат и писать следующую команду. Эту процедуру можно описать заранее.
Для этого агенту нужно указать:
что взять на вход;
где он имеет право работать;
что ему запрещено;
чем проверять результат;
когда завершить работу;
когда остановиться и передать вопрос человеку;
что написать в отчёте.
Ручное управление итерациями
Обычная работа с AI‑кодером часто выглядит так:
Человек: поправь авторизацию
Агент: готово, я внёс изменения
Человек: тесты падают, вот ошибка
Агент: готово, я поправил
Человек: ты изменил лишний файл, откати
Агент: ок, откатил
Человек: теперь проверь крайний случай
Агент: проверил
Формально это уже повторяемая процедура. Просто решение о каждом следующем шаге принимает человек. Он держит задачу в голове, оценивает результат, решает, что делать дальше, и завершает работу. Так сказать, живой while (true).
Для короткой задачи это нормально:
Посмотри, почему этот обработчик иногда возвращает 500. Пока код не меняй, сначала покажи гипотезы и места, которые стоит проверить.
Но если работа повторяется, человек начинает постоянно возвращать агента к одной и той же процедуре:
Пока CI красный: прочитать лог понять причину внести минимальную правку прогнать тест повторить
Или:
Пока в очереди есть issue с меткой bug: прочитать issue проверить, хватает ли данных определить компонент поставить метку написать комментарий, если данных не хватает перейти к следующему
Такая задача уже содержит запуск, повторение, проверку, ограничения и завершение. Это и есть область, где циклы становятся полезнее обычного диалога.
Какие циклы бывают в Claude Code
Anthropic делит такие сценарии на четыре вида:
turn‑based — работа по шагам в обычном диалоге;
goal‑based — работа до достижения цели;
time‑based — повторение по времени;
proactive — запуск по событию или расписанию.
В русском тексте их можно назвать проще:
ручной диалог;
работа до достижения цели;
работа по расписанию;
работа по событию.
(английские названия буду оставлять там, где речь идёт о конкретных командах или терминах из документации Claude Code)
1. Ручной диалог
Самый простой вариант — обычный запрос. Вы просите Claude Code что‑то сделать, он читает проект, меняет файлы, запускает проверки и отвечает. После этого человек решает, продолжать или нет.
Пример:
Найди, почему тесты billing падают после последнего изменения. Пока не меняй код. Сначала покажи причину и предложи минимальное исправление.
Этот режим подходит для диагностики, коротких задач и ситуаций, где сначала нужно разобраться.
Проблемы начинаются, когда так пытаются вести длинную повторяемую работу. Тогда человек вынужден регулярно напоминать агенту процедуру: «запусти тест», «посмотри лог», «не меняй этот каталог», «снова проверь линтер».
Для таких повторяемых правил в Claude Code есть skills — навыки. Это отдельные инструкции, которые можно хранить в проекте и подключать к подходящим задачам.
Например, вместо того чтобы каждый раз писать:
После изменения фронтенда открой страницу, нажми кнопку, проверь консоль, сделай скриншот и не считай задачу выполненной, если в браузере есть ошибка.
можно вынести это в файл:
.claude/skills/frontend-check/SKILL.md
Для человека это документация проекта. Для агента — инструкция, которую можно применять при подходящей задаче.
2. Работа до достижения цели: /goal
Команда /goal позволяет задать результат, до которого Claude должен продолжать работу.
Пример:
/goal tests in tests/auth pass and npm run lint exits 0, or stop after 8 turns
После каждого шага выполняется проверка, достигнута ли цель. Если цель не достигнута, Claude продолжает работу.
Здесь важно не формулировать цель как пожелание.
Слабая постановка:
/goal make the code better
Более точная постановка:
/goal pytest tests/billing exits 0, ruff check exits 0, and git diff contains no changes outside billing/, or stop after 6 turns
В русском описании это можно записать так:
Цель: тесты tests/billing проходят ruff check завершается без ошибок diff не выходит за каталог billing/ если после шести попыток тест всё ещё падает — остановиться и объяснить причину
Такой формат ближе к критериям приёмки, чем к общей просьбе «доведи до рабочего состояния».
3. Работа по расписанию: /loop
Команда /loop нужна для повторяемой проверки состояния. Например, когда нужно ждать CI, отслеживать комментарии в PR или периодически проверять результат деплоя.
Пример:
/loop 5m check my PR, address review comments, and fix failing CI
В рабочей постановке лучше сразу задавать процедуру:
Каждые 5 минут: проверить PR посмотреть новые комментарии ревьюера если CI упал — прочитать лог внести минимальное исправление остановиться, когда CI зелёный и комментариев больше нет
Для таких задач важно явно описывать права. Если агент только читает статус CI, риски ограничены. Если он может менять код, писать в Slack, открывать PR и запускать команды, его область действий нужно задавать точно.
4. Работа по событию: routines
Routines — сохранённые задания Claude Code, которые запускаются по расписанию, через API или по событию GitHub.
Примеры:
Каждое утро: прочитать новые bug reports разложить их по компонентам поставить метки назначить владельцев отправить сводку в Slack
После открытия PR: проверить код по командному чек-листу найти возможные регрессии оставить комментарии
После production deploy: проверить smoke tests посмотреть свежие ошибки сравнить их с предыдущим релизом написать короткое сообщение в release channel
Для таких сценариев нужно заранее решить, от чьего имени агент действует. Если commit, PR или сообщение в Slack выполняются через личную учётную запись, в журналах это будет выглядеть как действие конкретного пользователя. Это влияет на права, аудит и разбор инцидентов.
Как должна выглядеть постановка цикла
Обычная команда обычно отвечает на вопрос «что сделать». Для цикла этого мало.
Нужно указать:
когда запускаться;
что считать входными данными;
какие файлы можно менять;
какие действия запрещены;
как проверять результат;
когда завершать работу;
когда звать человека;
сколько попыток допустимо;
что должно попасть в отчёт.
Слабая постановка:
/loop improve the project
Чуть подробнее, но всё ещё недостаточно:
/loop 10m check the project and fix problems
Более точная постановка:
/loop 20m check PR #184. If CI failed: inspect only the failed job logs make the smallest change required to make the failed job pass modify only src/billing and tests/billing Stop when: CI is green there are no unresolved review comments Stop early if: the same test fails after 3 attempts the fix requires credentials the fix requires production access the fix requires changes outside the allowed directories At the end: summarize what changed and why
Такую постановку можно адаптировать под Claude Code, Codex, Cursor или внутреннего агента.
Примеры слабых и точных постановок
Пример 1. Исправить CI
Слабая постановка:
Проверь CI и исправь всё, что сломалось.
Проблемы:
непонятно, какие файлы можно менять;
непонятно, сколько попыток допустимо;
непонятно, какие проверки считать достаточными;
непонятно, когда нужно остановиться.
Более точная постановка:
Проверь CI в PR #184. Если CI красный: прочитай только лог упавшей задачи CI найди минимальную причину падения измени только файлы, уже затронутые в PR запусти локально тот же тест, если это возможно Заверши работу, когда: CI зелёный нет новых ошибок линтера Остановись и напиши отчёт, если: после трёх попыток падает тот же тест нужно менять файлы вне PR нужны секреты или внешний доступ
Так агент разбирает конкретный сбой и не выходит за границы PR.
Пример 2. Починить нестабильный тест
Слабая постановка:
Найди и исправь нестабильные тесты.
Проблемы:
непонятно, какой тест нестабилен;
агент может отключить тест;
агент может увеличить timeout и скрыть проблему;
нет проверки, что тест стал стабильнее.
Более точная постановка:
Разбери нестабильный тест: pytest tests/payment/test_retry.py::test_retry_timeout -q Повтори тест до 20 раз. Если тест падает: сохрани пример ошибки проверь, зависит ли падение от времени, порядка выполнения или внешнего состояния предложи минимальное исправление Разрешено менять: tests/payment/test_retry.py src/payment/retry.py Запрещено: увеличивать timeout без объяснения отключать тест помечать тест как xfail или skip Считать задачу завершённой, если: тест прошёл 20 раз подряд изменение объяснено
Здесь заранее запрещены способы спрятать проблему вместо исправления.
Пример 3. Обновить зависимость
Слабая постановка:
Обнови зависимости и поправь несовместимости.
Проблемы:
агент может обновить лишние пакеты;
изменение может затронуть слишком много файлов;
трудно понять, какая несовместимость была исправлена;
может измениться публичный API.
Более точная постановка:
Обнови только pydantic с версии 1.x до 2.x. Разрешено: менять requirements.txt менять код, который прямо использует pydantic BaseModel, Field, validator менять связанные тесты Запрещено: обновлять другие зависимости переписывать бизнес-логику менять публичный API После каждого набора правок запусти: pytest tests/api tests/models ruff check src tests Заверши работу, когда: тесты проходят линтер проходит в отчёте перечислены все места, где API pydantic изменился Остановись, если: нужно менять больше 20 файлов несовместимость затрагивает публичный API
Здесь обновление ограничено одной библиотекой и задан список проверок.
Пример 4. Изменить Ansible role
Слабая постановка:
Приведи роль в порядок и сделай restart сервиса правильно.
Проблемы:
«правильно» не определено;
restart может начать происходить при каждом запуске playbook;
проверка конфигурации может оказаться формальной;
агент может изменить общие роли или inventory.
Более точная постановка:
Измени Ansible role unbound так, чтобы restart сервиса происходил только при изменении конфигурации. Разрешено менять: roles/unbound/tasks/*.yml roles/unbound/handlers/*.yml roles/unbound/templates/*.j2 Нужно проверить: template tasks имеют notify только на restart unbound handler сначала запускает unbound-checkconf restart не выполняется, если template не изменился changed_when не заставляет handler срабатывать на каждом запуске Запусти проверки: ansible-lint roles/unbound yamllint roles/unbound В отчёте обязательно ответь: при каком событии будет restart будет ли restart при каждом запуске playbook что произойдёт, если unbound-checkconf вернёт ошибку Остановись, если: для проверки нужен доступ к production нужно менять общие роли или inventory
Это проверочный список для конкретной административной задачи.
Пример 5. Разобрать production‑лог
Слабая постановка:
Посмотри логи и исправь ошибку.
Проблемы:
непонятно, какой период смотреть;
непонятно, какую ошибку искать;
агент может исправлять следствие, а не первичный сбой;
есть риск получить общий catch вместо исправления причины.
Более точная постановка:
Разбери ошибку 500 в billing API за период 12:00–12:30. Входные данные: файл logs/billing-api-2026-07-08.log request_id: req-9f31a Порядок работы: найди все строки с этим request_id восстанови цепочку вызовов найди первое исключение, а не последующие ошибки обработки сопоставь ошибку с кодом Разрешено: предложить исправление изменить тест изменить код только в src/billing Запрещено: менять обработку всех ошибок глобально скрывать exception общим catch менять формат логов Считать задачу завершённой, если: найден первичный сбой есть минимальный patch добавлен тест на этот случай
Такая постановка ограничивает диагностику конкретным периодом, запросом и модулем.
Пример 6. Подготовить миграцию базы
Слабая постановка:
Сделай миграцию для новой модели.
Проблемы:
не указаны требования к полю;
не описан rollback;
агент может добавить default или backfill;
не задано, где нельзя выполнять миграцию.
Более точная постановка:
Подготовь миграцию для добавления поля users.last_seen_at. Требования: поле nullable default не задавать существующие строки не обновлять rollback должен удалять поле Разрешено менять: migrations/* src/users/model.* tests/users/* Проверки: миграция применяется на пустой базе миграция применяется на базе с существующими users rollback возвращает схему назад тесты users проходят Остановись и не применяй миграцию, если: нужно блокирующее изменение таблицы требуется backfill требуется изменение индекса на большой таблице
Для миграций условия остановки особенно важны. Агент не должен самостоятельно применять изменения, которые требуют отдельного решения.
Пример 7. Ревью PR
Слабая постановка:
Проверь PR.
Проблемы:
агент может начать комментировать стиль ради стиля;
может предложить общий рефакторинг;
может обсуждать код, который PR не меняет;
результат будет трудно использовать.
Более точная постановка:
Проверь PR #241 как ревьюер. Проверять только: изменения в diff связанные тесты явные регрессии Не нужно: предлагать общий рефакторинг переписывать стиль автора комментировать код, который PR не меняет Ищи: нарушение обратной совместимости ошибки в обработке null или пустых значений лишние запросы к базе отсутствие теста на изменённое поведение небезопасную работу с пользовательским вводом Формат результата: blocking issues non-blocking suggestions questions Если blocking issues нет — прямо напиши, что PR можно принимать после прохождения CI.
Такой формат отделяет блокирующие проблемы от замечаний и вопросов.
Пример 8. Обработка очереди issue
Слабая постановка:
Разбери баги в GitHub.
Проблемы:
агент может закрывать задачи;
может менять приоритеты;
может обещать сроки;
непонятно, сколько задач он должен обработать.
Более точная постановка:
Разбери issue с label=bug, созданные за последние 7 дней. Для каждого issue: определить компонент проверить, есть ли шаги воспроизведения проверить, есть ли версия продукта проверить, есть ли ожидаемое и фактическое поведение Если данных достаточно: поставить label с компонентом предложить минимальный план проверки Если данных недостаточно: написать комментарий с конкретным списком недостающих данных Запрещено: закрывать issue назначать milestone менять priority обещать срок исправления Завершить работу после обработки 10 issue.
Такой сценарий подходит для первичной сортировки задач. Агент помогает собрать и структурировать данные, но не принимает продуктовые решения.
Пример 9. Найти причину роста нагрузки
Слабая постановка:
Посмотри, почему сервер начал тормозить.
Проблемы:
«тормозить» не определено;
непонятен период;
агент может начать менять конфиги вместо диагностики;
нет запрета на опасные действия.
Более точная постановка:
Разбери рост CPU на сервере app-03 за период 14:00–14:30. Входные данные: вывод top за период nginx access log application log список последних deploy Порядок работы: определить, какой процесс потреблял CPU проверить, совпадает ли рост с deploy найти самые частые URL за период проверить, есть ли всплеск ошибок отделить причину от следствий Запрещено: перезапускать сервисы менять конфиги удалять файлы выполнять команды, влияющие на production Считать задачу завершённой, если: названа наиболее вероятная причина приведены строки логов или метрики, которые это подтверждают предложены следующие безопасные действия
В production‑задачах агенту часто стоит давать только диагностическую роль.
Пример 10. Подготовить изменение nginx
Слабая постановка:
Поправь nginx config для нового сервиса.
Проблемы:
непонятно, какой
server blockменять;можно сломать существующий routing;
нет проверки синтаксиса;
не указано, можно ли делать reload.
Более точная постановка:
Добавь nginx location для сервиса reports-api. Требования: путь /api/reports/ проксируется на http://reports-api:8080/ существующие location не менять TLS-настройки не трогать client_max_body_size не менять Разрешено менять: nginx/sites-enabled/app.conf Проверки: nginx -t должен завершиться успешно в diff нет изменений TLS-настроек существующие location остались без изменений Запрещено: выполнять nginx reload менять upstream других сервисов менять общие include-файлы В отчёте: покажи изменённый location напиши, нужна ли ручная команда reload после проверки
Агент может подготовить изменение и проверку. Применение на production остаётся отдельным действием.
Не заменять проверки моделью
Модель не должна выполнять проверки, которые лучше делать обычными инструментами.
Не нужно просить агента «проверь форматирование», если есть gofmt, ruff, prettier или php-cs-fixer.
Не нужно просить агента «убедись, что API не сломан», если есть контрактные тесты.
Не нужно просить агента «посмотри, не изменилось ли поведение», если это покрыто регрессионными тестами.
Модель полезна там, где нужно понять ошибку, сопоставить лог с изменением, найти минимальное исправление, обновить тест, объяснить результат человеку. Проверять результат лучше обычной машинной проверкой.
Слабая постановка:
Проверь, что всё работает.
Более точная постановка:
Запусти: pytest tests/billing ruff check src/billing tests/billing mypy src/billing Считай задачу выполненной только если все три команды завершились с кодом 0.
Чем больше в цикле конкретных команд проверки, тем меньше результат зависит от оценки самой модели.
Навыки как проектная инструкция
Файл CLAUDE.md легко перегрузить правилами: стиль кода, запуск тестов, особенности деплоя, правила именования, договорённости команды, исключения, запреты.
Повторяемые процедуры лучше выносить в отдельные навыки.
Например:
.claude/skills/verify-ansible-role/SKILL.md
Содержимое:
--- name: verify-ansible-role description: Verify Ansible role changes before reporting completion. --- # Проверка Ansible role Перед тем как считать задачу завершённой: 1. Запусти ansible-lint для изменённых файлов роли. 2. Проверь YAML-синтаксис. 3. Проверь handlers: если изменился template, service restart должен вызываться только при изменении содержимого. 4. Если есть restart service, объясни, какое изменение его вызывает. 5. Не отмечай задачу выполненной, если проверка синтаксиса не прошла.
После этого не нужно каждый раз писать агенту:
Не забудь проверить handlers. Не забудь проверить changed_when. Не забудь объяснить, будет ли restart при каждом запуске playbook.
Правило фиксируется в репозитории и становится частью работы с проектом.
Разделение ролей
Агент, который писал код, не должен быть единственным проверяющим своего результата.
Рабочая схема может быть такой:
агент A реализует изменение;
агент B проверяет diff как ревьюер;
CI запускает машинные проверки;
человек принимает результат или возвращает на доработку.
Даже простая схема «один агент пишет, второй проверяет» обычно лучше, чем ситуация, где автор изменения сам объявляет задачу завершённой.
Когда нужен не один агент
Некоторые задачи плохо укладываются в последовательную работу одного исполнителя:
найти все неправильные использования старого API;
проверить сотни файлов;
сравнить несколько вариантов миграции;
разобрать десятки похожих ошибок в разных модулях;
проверить большой документ на технические ошибки.
Для таких случаев Claude Code предлагает workflows: сценарии, где несколько подзадач выполняются отдельными агентами, а общий ход работы описывается кодом.
Пример разбиения:
агент 1 проверяет backend агент 2 проверяет frontend агент 3 проверяет тесты агент 4 ищет устаревшие вызовы API сводящий агент собирает общий отчёт
Этот подход полезен, когда работа параллелится и есть понятный формат результата. Чем больше агентов и чем шире задача, тем важнее ограничения на область изменений и формат отчёта.
Частые ошибки
Первая ошибка — расплывчатая цель:
Сделай лучше. Наведи порядок. Улучши архитектуру. Проверь проект.
Для автономной работы агенту нужен проверяемый критерий.
Вторая ошибка — отсутствие лимита. У цикла должен быть предел: количество попыток, время, число шагов, список файлов, бюджет токенов.
Третья ошибка — слишком широкие права. Если не ограничить каталог, агент может изменить соседний модуль. Если не запретить внешние действия, он может вызвать API, отправить сообщение или поменять настройки.
Четвёртая ошибка — слабая инфраструктура проекта. Если нет тестов, понятного запуска, линтера, документации и правил ревью, агенту не на что опереться.
Пятая ошибка — смешивание ролей. Один агент не должен одновременно быть автором, ревьюером, тестировщиком и принимающим решение для серьёзного изменения.
Практический шаблон
Универсальная заготовка для постановки цикла:
Задача: что нужно сделать Входные данные: откуда брать информацию какой PR, issue, лог, файл или каталог смотреть Разрешено: какие файлы можно менять какие команды можно запускать какие внешние системы можно читать Запрещено: какие файлы нельзя менять какие команды нельзя запускать какие действия требуют человека Порядок работы: шаг 1 шаг 2 шаг 3 Проверка: какие команды должны завершиться успешно какие признаки результата обязательны Завершить работу, когда: критерий 1 выполнен критерий 2 выполнен Остановиться и написать отчёт, если: превышено число попыток нужны секреты нужен production-доступ задача вышла за разрешённую область Отчёт: что было сделано какие проверки прошли что осталось спорным
Эту структуру можно использовать как обычный промпт, как /goal, как /loop, как skill или как routine. Конкретная команда зависит от инструмента.
За пределами Claude Code
Подход не ограничен Claude Code. Codex, Cursor, Devin‑подобные агенты и внутренние корпоративные боты требуют похожей организации работы:
правила проекта;
повторяемые инструкции;
хуки;
проверки CI;
отдельный ревьюер;
запуск по расписанию;
запуск по событию;
лимиты;
журнал действий.
Промпт остаётся частью работы, но сам по себе он не задаёт права, проверки, ограничения и критерии завершения.
Более полезный вопрос теперь звучит так:
Как дать агенту задачу так, чтобы он: работал только в разрешённой области проверял результат конкретными командами останавливался по понятным правилам не тратил ресурсы бесконечно оставлял проверяемый след звал человека в спорных случаях
Заключение
Циклы в Claude Code — это способ описать повторяемую работу агента без ручной команды после каждого шага.
Слабая постановка:
Каждые 10 минут улучшай проект.
Более точная постановка:
Когда CI красный: прочитай лог упавшей задачи CI внеси минимальное исправление в разрешённых файлах запусти конкретную проверку остановись после пяти попыток позови человека, если нужны секреты или production-доступ
Для таких задач важны проверяемое «готово», ограниченная область изменений, лимиты и машинные проверки. Всё, что можно проверить обычной командой, лучше проверять обычной командой.
При этом важно не забывать, что чем больше самостоятельности получает агент, тем точнее должны быть заданы права, определены проверки и условия остановки.
