От промптов к циклам: как давать AI‑агенту проверяемые задачи

В работе с 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/billingStop when:  CI is green  there are no unresolved review commentsStop 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 directoriesAt 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-roledescription: 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-доступ

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

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