Разработчики Claude Code объяснили за лупинг

Разработчики Claude Code поделились, как они сами делят циклы (loops) и когда какой использовать. Ниже нормальный человеческий гайд.

Loop — это когда Claude повторяет цикл:

Понял задачу.
Собрал контекст.
Сделал действие.
Проверил результат.
Исправил, если не получилось.
Остановился, когда условие выполнено.

Главное отличие от обычного чата: вы заранее объясняете, что считать готовым результатом.

Не “сделай нормально”. А “тесты проходят”, “ошибок в консоли нет”, “скорость выше 90”, “все баг-репорты разобраны”.

Пример такого цикла:
--- name: verify-frontend-change description: Verify any UI change end-to-end before declaring it done. --- # Verifying frontend changes Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 1. Start the dev server and open the edited page in the browser. 2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after. 3. Check the browser console: zero new errors or warnings. 4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals. If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

Claude любит конкретику. Люди, кстати, тоже.

Это то, как большинство работает с Claude сейчас. Вы пишете задачу. Claude что-то делает. Вы проверяете. Потом пишете следующий промпт.

Подходит для:

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

Пример:

Добавь кнопку лайка на карточку товара, сохрани текущий стиль, проверь, что состояние меняется после клика.

Claude читает код, правит, запускает тесты, отвечает. Дальше вы смотрите и решаете, продолжать или нет.

Как улучшить: дать Claude способ самому проверять работу.

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

После UI-правки открой страницу, кликни по новому элементу, проверь состояние, посмотри консоль, сделай скриншот до и после. Не сдавай задачу, пока это не проверено.

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

Это уже интереснее. Команда /goal нужна, когда одной попытки мало, а критерий успеха понятен.

Пример:

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Что происходит:

Claude делает попытку;
проверяет результат;
если цель не достигнута, идет на следующий круг;
останавливается, когда цель выполнена или закончился лимит попыток.

Хорошо подходит для задач, где есть измеримый результат:

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

Плохой пример: Сделай код лучше.

Хороший пример: Убери все TypeScript errors в модуле payments, запусти проверку, остановись после 4 попыток, если останутся ошибки — покажи список.

Чем точнее критерий, тем меньше Claude будет играть в “мне кажется, уже нормально”.

Команды /loop и /schedule нужны для повторяющихся задач.

Например: /loop 5m check my PR, address review comments, and fix failing CI

Это значит: каждые 5 минут Claude проверяет PR, смотрит комментарии, чинит CI, отвечает по результату.

Подходит для:

PR, где прилетают ревью;
CI, который может падать;
мониторинга очередей;
регулярных отчетов;
проверки Slack/почты/таск-трекера;
задач, где внешний мир меняется без вас.

Разница простая:

/loop работает локально, пока включен ваш компьютер;
/schedule переносит повторение в облако, если эта возможность доступна.

Тут главное — не ставить интервал “каждые 30 секунд”, если задача меняется раз в день. Иначе вы не автоматизацию сделали, а маленький костер из токенов.

Это самый агентский вариант.

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

Пример сценария:

/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to.

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

Это подходит для хорошо описанной рутины:

разбор баг-репортов;
triage issues;
обновление зависимостей;
миграции;
регулярные проверки документации;
простые задачи поддержки;
анализ входящего фидбека.

Но тут уже важно не “дать ИИ свободу”, а собрать нормальные рельсы: права доступа, правила проверки, лимиты, ревью, логи.

Агент без рельсов — это не автономность. Это сюрприз в продакшене.

Claude Code team пишет важную вещь: качество loop зависит не только от модели, а от системы вокруг нее.

Что нужно:

Чистая кодовая базаClaude копирует ваши паттерны. Если в проекте хаос, он будет продолжать хаос, только быстрее.
Ясные правила проверкиОпишите, как понять, что задача сделана. Тесты, скриншоты, консоль, линтер, метрики, ручные сценарии.
Доступная документацияЕсли проект использует фреймворк или внутренние правила, дайте Claude короткий путь к актуальным докам.
Второй агент для ревьюРазработчики Claude советуют использовать отдельного агента для проверки кода. Свежий контекст полезен: агент-исполнитель уже “влюблен” в свое решение, ревьюер смотрит жестче.
Исправляйте систему, а не только багЕсли Claude снова ошибся в одном и том же месте, не просто поправьте результат. Добавьте правило, тест или skill, чтобы в следующий раз он сам это поймал.

Loops легко превращаются в дорогую игрушку, если запускать их без границ.

Правила простые:

не используйте сложный loop там, где хватит одного промпта;
ставьте лимит попыток;
пишите четкое условие остановки;
сначала прогоняйте на маленьком куске задачи;
используйте скрипты для механической работы;
не запускайте проверку чаще, чем нужно;
смотрите расход через /usage.

Пример плохого loop: Каждую минуту проверяй весь проект и улучшай всё, что найдешь.

Пример нормального loop: Каждые 30 минут проверяй PR #42. Если CI упал, найди причину, исправь только связанную ошибку, запусти тесты, оставь комментарий. Если новых событий нет — ничего не делай.

Первый вариант — генератор хаоса. Второй — рабочий помощник.

Обычный turn-based loop
Когда использовать: разовая задача, исследование, ручной контроль.
Что вы отдаете Claude: конкретную задачу.
Что оставляете себе: проверку и следующий шаг.

Goal-based loop
Когда использовать: есть понятный критерий успеха.
Что вы отдаете Claude: условие “готово”.
Команда: /goal.

Time-based loop
Когда использовать: задача повторяется по времени или зависит от внешних событий.
Что вы отдаете Claude: триггер.
Команды: /loop, /schedule.

Proactive loop
Когда использовать: регулярная, хорошо описанная работа.
Что вы отдаете Claude: весь процесс.
Инструменты: /schedule, /goal, skills, workflows, auto mode.

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

Например:

проверка PR;
разбор багов;
повторяющиеся UI-проверки;
обновление changelog;
обработка фидбека;
прогон Lighthouse;
проверка документации после изменений.

Задайте себе три вопроса:

Что Claude должен делать?
Как понять, что задача готова?
Когда он должен остановиться?

Если на эти вопросы есть ответы, можно делать loop.

Главная мысль от разработчиков Claude простая: будущее не в том, чтобы писать более хитрые промпты. Будущее в том, чтобы проектировать рабочие циклы, где агент понимает задачу, проверяет себя и не дергает человека на каждом шаге.

Промпт — это просьба. Loop — это процесс. И вот с процессами у AI-агентов начинается самое интересное.

Разработчики Claude Code объяснили за лупинг

Что такое loop

1. Обычный ручной цикл

2. Goal-based loop: когда вы знаете, что значит “готово”

3. Time-based loop: когда задачу надо повторять

4. Proactive loops: когда Claude сам забирает регулярную работу

Как не убить качество

Как не сжечь токены

Быстрая шпаргалка

С чего начать