Loop Engineering: в эпоху агентных систем разработчики переходят от промптов к проектированию автоматических циклов

В сообществе разработчиков ИИ обсуждают концепцию Loop Engineering, подход к созданию агентных систем, где главный акцент смещается с написания промптов на проектирование автоматических рабочих циклов. Сам термин предложил Peter, автор OpenClaw. Последние два года в индустрии доминировал Prompt Engineering: человек формулирует запрос, модель выдает результат, затем запрос корректируют и повторяют попытку. Но с появлением кодовых агентов вроде Claude Code и Codex ситуация меняется. Они уже умеют читать код, править файлы, запускать тесты и вызывать инструменты, поэтому ключевой задачей становится устройство среды, в которой такие агенты могут действовать автономно.

Loop в этой модели, замкнутый автоматический процесс работы. Система сама находит задачи (например, читает issues или ошибки CI), подтягивает нужный контекст, выполняет работу в изолированной среде, затем проверяет результат через тесты или других агентов. После этого она фиксирует состояние и решает, что делать дальше: продолжать выполнение, отправить PR или эскалировать проблему.

Google engineering lead Addy Osmani описывает структуру такого цикла через пять элементов. Это Skills, повторно используемые наборы инструкций; Context Injection, чтение текущего состояния среды; Sub-agents, небольшие автономные агенты под узкие задачи; Connectors, действия после завершения работы (например, создание PR); и State Files, где сохраняется прогресс. Loop Engineering при этом не то же самое, что Context Engineering, который определяет, какую информацию видят агенты, и не Harness Engineering, где система нацелена на стабильное выполнение одной операции. В материале приводят простую аналогию, Harness похож на кухню, где повар готовит одно блюдо и на этом всё заканчивается, тогда как Loop скорее напоминает ресторан с непрерывной работой, расписанием, кухонными процессами и обновлениями меню.

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