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

В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять ^[1] действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.

Поводом для этой статьи стала заметка Anthropic «Getting started with loops ^[2]» про циклы (loops) в Claude Code. Там термин«цикл» описывается как повторяющаяся работа агента до выполнения условия остановки.

Практический смысл такой: если задача состоит из нескольких повторяемых шагов, человеку не нужно каждый раз вручную читать вывод агента, запускать проверку, копировать ошибку ^[3] обратно в чат и писать следующую команду. Эту процедуру можно описать заранее.

Для этого агенту нужно указать:

• что взять на вход;

• где он имеет право работать;

• что ему запрещено;

• чем проверять результат;

• когда завершить работу;

• когда остановиться и передать вопрос человеку;

• что написать в отчёте.

Ручное управление итерациями

Обычная работа с 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 ^[4] легко перегрузить правилами: стиль кода, запуск тестов, особенности деплоя, правила именования, договорённости команды, исключения, запреты.

Повторяемые процедуры лучше выносить в отдельные навыки.

Например:

.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-доступ

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

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