Loop Engineering: как собрать агентский цикл вместо ручных промптов

Loop Engineering, это проектирование агентских циклов: человек один раз собирает цикл, а внутри цикла агент промптит себя сам. Термин ввёл Адди Османи в эссе от 07.06.2026 (Loop Engineering).

Через три недели, 30 июня 2026 года, Anthropic использовала этот термин в своём посте (getting started with loops).

Инженер при этом перестаёт писать промпт на каждый шаг: код пишет агент внутри цикла, а инженер решает, где цикл останавливается.

Чем цикл отличается от промпта

Промпт это разовая инструкция. Он действует на один запрос, и для следующего шага агенту нужен новый промпт.

Цикл задаёт поведение агента во времени: что он делает, чем проверяет результат и когда останавливается. Ручной промптинг перестаёт окупаться, когда переписка с агентом занимает больше времени, чем написание кода.

Османи в эссе приводит фразу Бориса Черни, руководителя Claude Code. В переводе: Я больше не пишу промпты для Claude. У меня работают циклы, они его промптят и решают, что делать. Моя работа, это писать циклы.

Из чего собирается агентский цикл

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

Цикл собирают из готовых компонентов.

1) Автоматизация. Цикл стартует по расписанию или по событию, без участия человека.

2) Git Worktrees. Каждый агент работает в своей копии репозитория и не мешает другим агентам.

3) Навыки. Отдельные файлы с инструкциями, которые агент загружает под конкретную задачу. Готовые файлы формата SKILL.md для Claude Code и Cursor собраны в разделе навыков платформы.

4) Плагины и коннекторы через MCP. Связь агента с инструментами за пределами чата.

5) Субагенты с разведёнными ролями: один делает, другой проверяет.

6) Память вне контекстного окна, она сохраняется после конца сессии.

Harness (обвязка) и цикл, это разные вещи. Цикл описывает поведение агента во времени, а harness это то, в чём он исполняется: инструменты, права, обработчики событий, память.

Почему агент не должен проверять сам себя

Модель, которая только что написала решение, склонна считать его верным: допущения из решения она при проверке принимает за факты.

Valmeekam, Marquez и Kambhampati замерили это на задачах планирования. Самокритика там ухудшает результат по сравнению с внешним проверяющим, а проверяющий внутри той же модели заметную долю неверных планов признаёт верными (arXiv 2310.08118).

Паттерн maker-checker разводит роли. Один агент, maker, делает работу. Второй, checker, проверяет её по заранее заданным критериям и отмечает каждое расхождение.

Выигрывает структурированная проверка: рубрика с критериями, тесты, правила проекта, отдельный проверяющий. Checker смотрит на конкретный результат: тесты прошли, линтер не выдаёт ошибок, поведение совпало с ожидаемым. Оценка "нравится или нет" в проверку не идёт.

Второй агент, это лишние токены и время. На мелкой и обратимой задаче отдельный checker, это перебор. Роли разводят там, где ошибка стоит дорого.

Как развести агентов по рабочим копиям

Несколько агентов на одном коде разводятся по рабочим каталогам. Git Worktrees даёт каждому агенту свою рабочую копию репозитория, привязанную к своей ветке.

Изоляция нужна только на время работы. Слить изменения в общую ветку всё равно придётся, и при слиянии возможны конфликты.

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

Что писать в контракте для агента

Агент делает не то, когда задачу ему поставили словами "сделай хорошо". Без критерия готовности он додумывает задачу сам.

В контракт входят:

1) Цель числом: поднять покрытие тестами до 80%.

2) Критерий приёмки: pytest завершается с кодом 0.

3) Границы: публичный интерфейс не менять.

4) Лимиты: сколько попыток, времени и токенов есть у цикла, прежде чем он отдаст задачу человеку.

Главная часть контракта, это критерий приёмки. Он проверяется командой с понятным результатом, оценка "выглядит рабочим" не годится. В такую проверку идут типы, линтеры, автотесты, ошибки времени выполнения и правила проекта (Anthropic про циклы проверки).

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

Сколько автономии давать агенту

Автономию поднимают ступенями, сразу её не включают. Ступени по эссе Османи:

1) Всё руками, агент максимум подсказывает.

2) Агент разбирает задачу на шаги и составляет список дел, код пишет человек.

3) Агент пишет код сам, в изолированном Worktree, результат смотрит человек.

4) Появляется отдельный checker, агент проверяет работу агента, последнее слово за человеком.

5) Система сама сливает безопасные изменения, без человека и только для заранее разрешённых классов задач.

Следующая ступень включается тогда, когда предыдущей доверяют.

У Claude Code есть ограничения: 20 одновременных субагентов в сессии и глубина вложенности три уровня ниже основного разговора, дальше запуск падает с ошибкой. Оба ограничения меняются переменными окружения, то есть поднимают их сознательно (документация про субагентов).

Чем рискует автономный цикл

Риски автономного цикла по эссе Османи:

1) Расход токенов. Цикл, который запускает себя сам, тратит токены заметно быстрее ручной работы.

2) Зелёные тесты. Они закрывают только то, что в них написано, а работа принимается по ним целиком.

3) Деградация архитектуры. Агент решает свою узкую задачу и может нарушить общий замысел системы.

4) Скорость чтения. Код появляется быстрее, чем человек успевает его осмыслить.

5) Привычка не вникать. Человек перестаёт разбираться в коде, когда цикл работает без его участия.

27 апреля 2026 года в компании PocketOS автономный агент удалил боевую базу вместе с резервными копиями. Задача была рутинная, работа шла через Cursor на Claude Opus 4.6, и, по словам основателя, на всё ушло девять секунд. Сервис не работал 30 часов, потеряны три месяца данных о бронированиях и клиентах. Сам агент потом написал, в переводе: Я предположил вместо того, чтобы проверить.

Случай PocketOS занесён в реестр инцидентов OECD.AI (карточка инцидента).

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

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

Как закрепить правила цикла кодом

В агенте, которого я собрал под работу с текстами и видео, правила сначала лежали текстом в инструкции, и агент не всегда им следовал. Теперь их проверяют обработчики (hooks), то есть код.

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

Второй приём, это потолок попыток. Три неудачные попытки подряд на одной задаче, и цикл отдаёт задачу человеку: агент пишет, что пробовал и чем кончилось. Четвёртая попытка того же приёма запрещена. Без потолка цикл упирается в лимит подписки вместо решения. Этот потолок держится инструкцией, кодом он пока не проверяется, и в этом его слабое место.

Оба приёма, это лимиты из контракта: запрет проверяется командой, а у цикла есть предел по попыткам.

Что меняется в работе инженера

Цикл берёт на себя рутину: запуск, изоляцию, проверки и память. Решение, где цикл останавливается, и ответственность за результат остаются за человеком.

Отраслевого замера выигрыша пока нет, а ощущение выигрыша ненадёжно. METR в 2025 году дала опытным разработчикам open source задачи в знакомых им репозиториях и замерила время с ИИ и без него. С ИИ они работали на 19% медленнее. Сами участники при этом были уверены, что стали быстрее примерно на 20% (отчёт METR).

Повторный замер в 2026 году надёжной оценки не дал. Замедление там снова есть, но разброс такой, что в него попадает и ускорение. Из-за отбора участников исследователи называют свой замер заниженным (обновление METR).

Ориентиром служит свой результат на своей кодовой базе: время на задаче до цикла и после.

Коротко

Что такое Loop Engineering? Проектирование агентских циклов: человек собирает цикл один раз, а внутри цикла агент промптит себя сам. Термин ввёл Адди Османи 07.06.2026.

Из чего состоит цикл? Из трёх действий по формуле Anthropic (собрать контекст, действовать, проверить) и шести компонентов: автоматизация, Worktrees, навыки, коннекторы MCP, субагенты, память.

Почему нужен отдельный проверяющий? Модель склонна считать своё решение верным, а самокритика ухудшает итог по сравнению с внешним проверяющим, это замерено в работе arXiv 2310.08118.

Что писать в контракте? Цель числом, критерий приёмки командой, границы и лимиты по попыткам, времени и токенам.

Чем рискует автономный цикл? Расходом токенов, зелёными тестами, деградацией архитектуры, скоростью чтения и привычкой не вникать. Перед необратимым действием нужна отдельная проверка.