Loop Engineering: как перестать промптить вручную и начать проектировать циклы для ИИ-агентов
Практический разбор loop engineering: что это, из каких компонентов состоит, как реализуется в Codex и Claude Code, какие есть риски и как внедрять подход по шагам.
Большинство разработчиков уже научились эффективно промптить LLM, собирать контекст, использовать skills и MCP. Ещё пару лет назад этого хватало, чтобы считаться продвинутым пользователем AI–инструментов. Но в 2026 году выясняется, что это лишь базовый уровень мастерства.
Привычная схема работы – написал промпт, дождался ответа, проанализировал, написал следующий промпт – плохо масштабируется. В этой парадигме разработчик постепенно превращается из инженера в оператора LLM: он не проектирует систему, а вручную ведёт агента за руку шаг за шагом.
Есть простой индикатор. Если вы взаимодействуете с агентом больше, чем сами пишете код и принимаете инженерные решения, скорее всего, вы уже упёрлись в потолок текущего способа работы. Выход – подняться на уровень выше. Один из таких подходов получил название loop engineering.
Что такое loop engineering
Loop engineering – это не «улучшенный промптинг» и не ещё одно название для context engineering, как может показаться. Это формирующийся инженерный паттерн проектирования агентских workflow. Идея проста по формулировке и непроста в реализации: вы проектируете не один промпт, а цикл, который сам запускает агента, выдаёт ему задачи, проверяет результат, сохраняет состояние и решает, что делать дальше.
Название популяризировал в 2026 году Addy Osmani – инженерный лидер, много лет работавший в Google и Google Cloud AI. В своём посте он описал, как работа программистов, использующих кодинг-агентов, смещается от написания промптов к проектированию циклов, которые промптят модель автоматически.
Сама идея возникла не на пустом месте. Как её сформулировал Peter Steinberger: разработчикам пора не промптить агентов, а проектировать циклы, которые промптят агентов за вас. А Boris Cherny из Anthropic, руководитель Claude Code, говорил, что больше не пишет промпты напрямую – его работа теперь в том, чтобы проектировать циклы вокруг модели.
Внутренний и внешний циклы
Внутренний цикл – это то, что агент делает по умолчанию: собирает контекст, анализирует его, выполняет действия, получает обратную связь, исправляет ошибки и продолжает работу.
Внешний цикл – это то, что проектирует разработчик, чтобы автоматизировать запуск и управление внутренним циклом. Сюда входят триггеры и расписание запуска, изоляция работы агентов, декомпозиция задач, управление множеством итераций, критерии успешного выполнения, лимиты, проверки и условия остановки.
Именно это отличает loop engineering от обычного промптинга: вы проектируете не отдельный запрос к модели, а систему, которая управляет тем, как, когда и зачем модель получает задачи.
Loop engineering не отменяет prompt engineering и context engineering. Плохой промпт внутри цикла будет тиражировать ошибки на каждой итерации, а плохой контекст – стабильно ломать архитектуру. Качество промпта и контекста остаётся обязательным; цикл лишь управляет их применением в процессе.
Ralph loop – родственная практика
У loop engineering есть родственные практики. Одна из самых известных – Ralph Wiggum loop, или «техника Ральфа». Это простой паттерн автономной работы: агент выполняет небольшую атомарную задачу, фиксирует изменения, сохраняет состояние и завершает итерацию. Следующая итерация начинается как новая сессия – с чистым контекстом.
Зачем это нужно? Каждый, кто работал длительными сессиями с агентом, замечал, как они деградируют: контекстное окно переполняется, появляются нерабочие версии файлов, ошибочные рассуждения и устаревшие промежуточные решения. Всё это засоряет контекст и снижает его качество.
В Ralph–подходе состояние хранится не только внутри модели, но и снаружи. Например, в двух файлах – условных PLAN.md и STATUS.md. Из PLAN.md агент берёт новые задачи, а в STATUS.md записывает, что сделал, что прошло или не прошло тесты и что проверить дальше. Конкретные имена файлов не важны. Важно, что память процесса живёт вне контекстного окна и не теряется между итерациями.
Шесть компонентов loop engineering
В популярной формулировке Addy Osmani у loop engineering пять основных компонентов плюс память.
1. Automations (автоматизации)
Процесс, который запускает цикл по расписанию или событию, делает первичный разбор задач и решает, есть ли работа, которую нужно передать агенту.
2. Git worktrees
Изолированные рабочие деревья Git. Они нужны, чтобы сабагенты параллельно не записывали изменения в одну и ту же директорию и не ломали незавершённую работу друг друга.
Важная оговорка: worktrees не отменяют merge–конфликты полностью. Если два агента изменят одни и те же строки, конфликт всплывёт позже – при интеграции. Но во время самой работы хаоса не будет: каждый агент получает свою директорию, свой HEAD, свой индекс и, в зависимости от настройки, отдельную ветку или detached HEAD.
3. Skills
В формулировке Osmani в Skills предлагается зафиксировать проектные правила: как собирать проект, какие команды запускать, какие архитектурные ограничения соблюдать. Но на мой взгляд для этого уже есть AGENTS.md. В контексте loop engineering у Skills есть более прикладная роль – автоматический разбор задач: skill извлекает баги из логов CI, проверяет открытые тикеты в таск–трекере и пополняет файл TODO.md задачами для дальнейшей обработки агентами.
4. Плагины и коннекторы
Связывают агентов с реальными инструментами: CI/CD, таск–трекерами, базами данных, системами алертинга и мониторинга, Slack, GitHub, Jira. Чаще всего такая интеграция делается через MCP.
5. Сабагенты
Разделение ролей. Один агент пишет код, другой независимо проверяет его. Это паттерн maker–checker: maker делает, checker проверяет.
6. Память
Внешний источник правды о процессе: markdown–файл в репозитории, тикет в Jira, доска в Linear, запись в базе данных. Память живёт вне контекстного окна и сохраняется между сессиями.
Как это работает на практике
Codex. Автоматизация настраивается через вкладку Automations: выбираете проект, промпт для регулярного запуска, расписание и среду выполнения – локальную папку или Git worktree. Для Git–репозиториев автоматизации могут запускаться в отдельном фоновом worktree, чтобы не конфликтовать с текущей локальной работой.
Claude Code. Здесь есть команда /loop – регулярный запуск промпта по расписанию, фактически cron–механизм внутри сессии. Удобно, например, чтобы периодически проверять статус деплоя, CI или pull request. Дополнительно доступны hooks и GitHub Actions: с их помощью агента встраивают в жизненный цикл разработки – запуск проверок, форматирование файлов, реакция на события, автоматизация в GitHub workflow или перенос работы на удалённую инфраструктуру.
Отдельно стоит команда /goal. Она задаёт условие завершения, и агент работает, пока условие не выполнено.
Важный нюанс про
/goal: после каждого шага отдельная быстрая модель оценивает, достигнуто ли условие. Но она не запускает тесты сама и не читает файлы независимо – она судит по тому, что основной агент уже сделал и показал в контексте. Поэтому тесты, линтеры и сборку нужно явно встраивать в основной цикл или в hooks.
Из этого складываются несколько уровней автономности:
– Задачи по расписанию – мониторинг багов, проверка CI, сортировка входящих задач.
– Выполнение цели по итерациям – агент работает, пока не достигнет заданного состояния.
– Независимая проверка результата – отдельный checker, модель или автоматическая проверка по правилам определяет, можно ли считать задачу выполненной.
Критерии успешности как контракт
Ключевой элемент любого цикла – чёткие критерии успешности. Их нужно определять как контракт, а не как пожелание. «Сделай хорошо», «улучши качество», «доведи до идеала» – недопустимые формулировки: они приводят либо к преждевременному завершению цикла, либо к бесконечным итерациям. А бесконечные итерации – это прямой расход токенов, лимитов и бюджета впустую.
Хороший контракт состоит из нескольких частей.
- Измеримая цель. Хотите покрыть тестами 80% кодовой базы – так и пишите: довести test coverage до 80%.
- Проверяемые критерии. Конкретная команда и ожидаемый результат:
npm testзавершается с exit code 0,npm run lintбез ошибок, coverage report не ниже 80%. - Границы. Что нельзя трогать, запускать или редактировать: не ходить в интернет, не использовать публичные API, не менять схему БД, не трогать production–конфиги.
- Лимиты. Не больше 25 итераций или не дольше двух часов. Не достигли условия – агент останавливается и передаёт задачу человеку.
- Логи и стоп–факторы. Условия принудительного выхода: например, если после изменений начинают падать интеграционные тесты – это сигнал остановиться и позвать разработчика.
Зачем нужен валидатор
Все, кто работал с AI–агентами – от недорогих open–source моделей до топовых коммерческих вроде Claude Opus, GPT–5 или Gemini, – замечали одну особенность: агент склонен считать собственный результат корректным. Иногда с ним приходится буквально спорить, доказывая, что решение неидеально. А порой он генерирует и вовсе нерабочий код: вы запускаете сервис – и он падает с ошибками.
Именно здесь нужен валидатор. Простыми словами – отдельная модель, отдельный агент или автоматическая проверка по правилам, которая проверяет результат чужой работы. Это и есть суть паттерна maker–checker.
Git worktrees
Git worktree – это способ вести параллельную работу в одном репозитории через отдельные рабочие директории. У каждого worktree своя файловая копия проекта, свой HEAD, свой индекс и собственное состояние рабочей директории. История репозитория при этом общая.
Для агентов это критично. При параллельной работе возникает конкуренция за одни и те же файлы. Если все пишут в одну директорию – хаос: один агент переписывает изменения другого, ломаются промежуточные состояния, непонятно, кто что менял. Worktree изолирует работу физически: один агент в одной директории, другой – в другой.
Но worktree не решает все конфликты магически. Если два агента изменили одну и ту же часть кода, конфликт возникнет при объединении изменений. Worktrees – это не замена review и merge–процесса, а способ безопаснее организовать параллельную работу.
Skills и память: что чем является
Эти два компонента важно не путать.
– Skills. Osmani предлагает определить в Skills проектные правила – как собирать проект, какие команды запускать, какие архитектурные ограничения соблюдать, какие папки не трогать. Но на мой взгляд для этого есть AGENTS.md. В контексте loop engineering в Skills логичнее положить прикладную логику: извлечь ошибки из логов CI, проверить открытые тикеты в таск–трекере и пополнить ими TODO.md для дальнейшей обработки агентами.
– Память – динамическое состояние: что сделано, что упало, что в очереди, какие гипотезы проверялись, какие решения отклонены, что требует внимания человека. Отвечает на вопрос: «что уже произошло в этом процессе?»
Коннекторы через MCP дают агенту доступ к внешним системам – алертингу, мессенджерам, таск–трекерам, базам данных, GitHub, CI/CD, – чтобы закрывать весь рабочий процесс от тикета до pull request и уведомления.
Паттерн maker–checker
Maker–checker – паттерн, в котором один участник создаёт результат, а другой независимо его проверяет. В агентских системах maker пишет код или предлагает решение, а checker проверяет: запускает тесты, смотрит diff, сверяет изменения с архитектурными правилами и критериями задачи.
Почему нельзя доверить проверку тому же агенту? Потому что модель, только что написавшая решение, слишком лояльна к собственному результату. Она может пропустить логический дефект, не заметить нарушение архитектуры или убедить себя, что задача выполнена. Отдельный checker этот риск снижает – не устраняет полностью, но снижает.
На практике сабагенты настраиваются через конфигурационные файлы: имя, роль, специализация, модель, уровень reasoning effort и инструкции. Более мощные модели логично ставить на аудит, архитектуру и верификацию, а более быстрые и дешёвые – на исследование кодовой базы, сбор контекста и подготовку простых изменений.
Как выглядит весь процесс целиком
По триггеру или расписанию срабатывает планировщик. Он запускает skill разбора задач, собирает информацию из CI/CD, логов, тикетов или алертов и записывает состояние в файл со списком задач – например, TODO.md.
Для каждой задачи создаётся изолированный Git worktree, в нём запускается исполнитель – сабагент–maker. Он анализирует задачу, вносит изменения, запускает проверки и фиксирует результат. Затем сабагент–checker проверяет diff, прогоняет тесты и сверяет изменения с конвенциями проекта и критериями успешности.
Если всё в порядке, агент через MCP создаёт pull request и обновляет статус задачи в трекере. Если есть сомнения – задача уходит в статус, требующий ручной проверки. Например, в Jira можно завести отдельный статус вроде «Необходимо ревью кожаного» или «Внимание! Нейрослоп!». Файл состояния STATUS.md хранит историю по итерациям: что запускалось, что прошло, что упало и что делать дальше.
Условия для checker–агента стоит делать максимально конкретными:
Если всё соблюдено – изменения идут на review или авто–merge (в зависимости от зрелости процесса). Если нет – результат отклоняется, задача уходит разработчику.
Матрица зрелости: как внедрять по шагам
Это не официальный стандарт, а удобная практическая модель.
| Уровень | Что делает система | Роль разработчика |
|---|---|---|
| 1 | Ничего автоматического | Промптит и проверяет всё вручную |
| 2 | Разбирает задачи из трекера, формирует TODO.md | Пишет код сам, агент код не трогает |
| 3 | Вносит правки в выделенном Git worktree | Проверяет diff, гоняет тесты, мержит вручную |
| 4 | Добавляется checker, валидирующий pull request | Делает финальное одобрение |
| 5 | Сама мержит после прохождения тестов и линтеров | Контролирует по логам, алертам и периодическим review |
Кажется логичным сразу прыгнуть на верхний уровень: написал задачи, задал критерии, настроил цикл – и система всё делает сама. Но переходить туда сразу опасно.
Риски, которые растут вместе с автономностью
1. Расход токенов и бюджета. Плохо ограниченный цикл гоняет итерации впустую, повторяет действия, запускает дорогие модели и сжигает лимиты без реального прогресса.
2. Тесты и ложное чувство безопасности. Тесты не дают стопроцентного доказательства, что код корректен, архитектура соблюдена, а приложение работает как задумано. Хуже того, агент может писать тесты так, чтобы они подтверждали его собственное решение. Это риск подгонки решения под формальные критерии: тесты проходят, метрика достигнута, но реальная задача может быть решена неправильно. Поэтому финальный checker – это всё равно разработчик, особенно для production–кода. Запуск тестов, линтеров, typecheck, preview–deploy и smoke–тестов автоматизируется, но ответственность за деплой в прод остаётся на людях.
3. Архитектурная деградация. Агент может локально решить задачу, но нарушить общий дизайн: добавить дублирование, сломать границы модулей, создать неправильные зависимости, обойти существующие абстракции. Даже описанные конвенции не гарантируют, что агент будет их строго соблюдать, а checker не всегда заметит архитектурный дефект.
4. Эффект бутылочного горлышка. Агенты, особенно параллельные, генерируют код очень быстро – но скорость генерации не равна скорости принятия инженерных решений. Если не разбить работу на атомарные задачи с измеримыми критериями, накапливается когнитивный долг: вы теряете связь с проектом и перестаёте понимать, что изменилось, откуда новые зависимости и зачем новые абстракции. Code review остаётся обязательным.
5. Соблазн отключить критическое мышление. Код написан, приложение запускается, тесты прошли, checker молчит – кажется, что всё готово. Но автоматизация снижает нагрузку, а не отменяет инженерную ответственность.
Как внедрять безопасно
Давать автономию нужно по нарастающей. Сначала – ручной контроль и самостоятельная проверка всех результатов. Потом – постепенная автоматизация: сначала разбор задач, затем изолированные worktrees, затем checker, и только потом частичный авто–merge для безопасных классов задач. Автономию расширяют по мере того, как становится понятно, где агент стабильно справляется, а где ошибается.
Главный вывод
Loop engineering нужно внедрять через баланс. Задачи – атомарные, с конкретными, измеримыми и проверяемыми критериями. У цикла – лимиты, логи, стоп–условия и понятный механизм передачи задачи человеку.
Prompt engineering и context engineering никуда не исчезают – они становятся частью более крупной системы. Хороший промпт и хороший контекст по–прежнему важны, но инженерная задача теперь не в том, чтобы написать один удачный промпт, а в том, чтобы спроектировать цикл, который безопасно использует промпты, контекст, инструменты, проверки и внешнюю память.
Соберём картину воедино:
– Ralph loop показывает ценность коротких итераций с чистым контекстом и внешним состоянием.
– Maker–checker объясняет, почему автономной системе нужен независимый слой верификации.
– Git worktrees помогают безопаснее организовать параллельную работу агентов.
– AGENTS.md фиксирует проектные правила, а Skills в loop engineering берут на себя разбор задач – извлекают баги из логов CI и тикеты и пополняют TODO.md.
– Память сохраняет состояние между сессиями.
– MCP и коннекторы связывают агента с реальным workflow – тикетами, CI/CD, pull request, алертами и уведомлениями.
Но финальная ответственность всё равно остаётся на разработчике. Loop engineering – это не способ перестать быть инженером. Это способ подняться на уровень выше: вместо того чтобы вручную вести агента за руку, вы проектируете систему, в которой агент работает автономно – но в понятных границах, с проверками, логами, лимитами и человеческим контролем там, где он действительно нужен.
Источники: пост Addy Osmani «Loop Engineering», документация Codex (Automations, Worktrees), документация Claude Code (
/loop,/goal, hooks, GitHub Actions) и документация Git по worktree.
