Loop Engineering - новая мета? Честный обзор.

"Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents."

Сказал Питер Штайнбергер (создатель OpenClaw) и улетел в закат на своём лэмбо

Именно с этого твита и начался огромный хайп вокруг этого новомодного понятия loop engineering

Да что же это за чудо методология?

Как заявляет Питер и другие умные люди из X: ты больше не должен задавать промпты, ты должен создавать ЦИКЛЫ, внутри которых агент самостоятельно: запускается, находит себе задачу, сам проверяет свой код и достигает цель.

Человек же в этой методологии (как ИИ-энтузиасты любят говорить) перестаёт быть оператором, который пишет раз за разом промпты, он становится архитектором системы, которая сама управляет ИИ-агентом

Цикл состоит из следующих компонентов:

1. Триггер
2. Автоматическая постановка цели
3. Распределение задач по достижению цели между субагентами в изолированных средах
4. Ревьюинг кода отдельным субагентом
5. Документирование ошибок и рефлексия над ними

Чё имеется в виду под триггерами?

Это cron job (например, automation в Codex), в которой вы устанавливаете промпт по следующей структуре:

1. Проверить источники на наличие задач (например, посмотреть новые issues через GitHub MCP)
2. Приоритизировать задачи и положить их в triage inbox
3. Для каждой задачи написать задачи на спринт и промпт для /goal

Чё имеется в виду под автоматической постановкой цели?

Далее мы устанавливаем ещё один cron job, который будет проверять появились новые артефакты от первой ↑ кроны. Если да, то запустить /goal в соответствии с промптом и идти в рамках спланированного спринта

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

А при чём здесь субагенты, ревьювер и рефлексия?

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

После завершения каждого блока работы в работу включается субагент-ревьювер, который проверяет написанный код. Ревьювер опирается на рубрикатор - набор машиночитаемых критериев или тестов (например, линтеры, метрики заполненности данных, схемы). Отчёт ревьювера возвращается обратно основному агенту (который все управляет субагентами-разработчками) до тех пор, пока рубрикатор не выдаст успех

Все ошибки субагент логирует и рефлексирует на их счёт, занося в долгосрочную память, чтобы больше их не допускать

Бай зе вей, для подобного воркфлоу хорошо подходит superpowers - в нём уже есть скилл /subagent-driven development, который проводит всю разработку субагентами в изолированных средах и после завершения работы каждого, спаунит субагента-ревьювера. Сам использовал этот плагин, когда запускал /goal в Codex

Также во всех материалах по данному подходу делается отдельный акцент на: 1) Обязательном использовании скиллов в качестве процедурной памяти, чтобы цикл каждый раз не изобретал архитектуру проекта заново; 2) Обязательно вести агентам лог разработки и выносить статусы и контекст по проектам во внешнюю память в виде .md файлов или в Linear, чтобы была память между сессиями и вся информация не висела в контекстном окне

И касаемо субагентов важный момент: в источниках мнения разделяются, кто-то пишет, что нужно юзать именно 2-ух субагентов (один - исполнитель, второй - ревьювер), а кто-то пишет, что нужно для разработки использовать несколько субагентов и одного агента-ревьювера

ВСЁ

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

Как я уже сказал, глобально ничё нового Питер и прочие ИИ-энтузиасты не придумали: крон джобы, /goal, subagent driven development с ревьювером уже существовали до луп инжиниринга. Но по крайней мере ребята всё систематизировали и создали из этого новую методологию и дисциплину, которую мильон % подхватят корпы или стартаперы и будут внедрять как целостную фичу, а не набор отдельных инструментов

Я очень постарался постарался вам разжевать суть loop engineering и переложить на понятный кейс с Codex, тк термин ОЧЕНЬ новый - люди массово заговорили о нём после поста Питера, который вышел буквально 5 дней назад (так что цените, авангардный разборчик получился). Из-за этого очень много неясностей и размытостей в этом подходе к разработке

И чё касаемо применения в проде - очень большой скепсис у меня. Loop engineering требует огромных затрат на токены, и само построение такой системы (на уровне, что всё работает около безотказно) безумно сложный процесс, тк:

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

Все эти несовершенства нужно учитывать при построении собственного цикла.

Также прикрепляю блокнот в NotebookLM, в котором собрал самые интересные материалы по loop engineering на текущий момент

В общем, как-то так, народ, надеюсь, материал был для вас полезным или по крайней мере познавательным)

Статью подготовил Григорий a.k.a. Пироман 17 - ранее я работал в DS, а сейчас разрабатываю свой медицинский ИИ стартап и веду свой Телеграм канал, в котором рассказываю всё про AI и AI-native бизнес

Всем удачи!