Loop Engineering: как проектировать циклы для кодинг-агентов

Loop engineering, или инженерия циклов, - это переход от разовых запросов к кодинг-агенту к системе, которая сама находит работу, запускает агентов, проверяет результат, сохраняет состояние и решает, что делать дальше. Человек проектирует этот контур и остается ответственным за качество.

Идея стала заметной после формулировки Peter Steinberger: инженеру уже стоит проектировать циклы, которые обращаются к агентам, а не вручную вести каждый шаг. Boris Cherny из Claude Code описал тот же сдвиг короче: его работа все чаще состоит в написании циклов, которые сами формулируют следующие действия для Claude.

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

Пять блоков цикла и одна память

У рабочего цикла есть пять базовых блоков. В Codex и Claude Code они называются немного по-разному, но форма почти совпадает.

1. Автоматизации. Запускаются по расписанию, ищут работу и раскладывают ее по категориям.
2. Рабочие деревья Git. Изолируют параллельных агентов, чтобы они не правили один и тот же checkout.
3. Skills, или навыки. Хранят проектные правила, контекст, команды и исключения, которые агент не должен каждый раз угадывать заново.
4. Плагины и коннекторы. Подключают агентный цикл к реальным инструментам: задачам, CI, базам данных, Slack, staging API.
5. Субагенты. Разделяют роли: один исследует или пишет, другой проверяет и спорит со сделанным.

Шестой элемент - состояние. Это может быть файл Markdown, доска Linear, запись в issue tracker или другой долговременный журнал. Он живет вне одной сессии и отвечает на простые вопросы: что уже пробовали, что прошло проверку, что осталось открытым, где цикл должен продолжить завтра.

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

Автоматизации задают ритм

Автоматизация делает цикл действительно циклом. В Codex App это описывается как запуск по проекту, запросу, расписанию и окружению: локальный checkout или фоновое рабочее дерево. Если запуск нашел работу, результат попадает во входящий список для разбора; если ничего не найдено, запуск можно архивировать без шума.

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

В Claude Code похожая идея собирается через расписания, hooks, команды вроде /loop и /goal или через GitHub Actions, если цикл должен жить после закрытия ноутбука. Важная деталь - /goal работает по таймеру только в первом приближении: он продолжается до выполнения проверяемого условия, например когда все тесты в test/auth проходят, а lint чистый.

Трудная часть здесь не синтаксис команды. Трудная часть - определить, что именно означает 'готово'. В обсуждении статьи это сформулировали очень точно: цикл может повторять схему цель - агент - проверка, но вся инженерная сложность спрятана в критерии остановки.

Рабочие деревья спасают параллельность от хаоса

Как только запускается больше одного агента, главным источником сбоев становятся файлы и пересечения изменений. Два агента, которые одновременно меняют один checkout, создают ту же проблему, что и два разработчика, редактирующие одни строки без синхронизации.

git worktree решает механическую часть: каждый агент получает отдельную директорию и отдельную ветку, но использует общую историю репозитория. Изменения одного агента физически не попадают в рабочую копию другого.

Codex в этой логике дает нескольким потокам работать с одним репозиторием без взаимного вмешательства. В Claude Code похожая изоляция строится через git worktree, флаг --worktree и настройку субагента вроде isolation: worktree, когда помощник получает отдельный checkout и потом убирает его за собой.

Но рабочие деревья убирают только столкновения файлов. Они не увеличивают пропускную способность ревью бесконечно. Потолком остается человек или команда, которые должны понять, принять и объединить результат.

Skills уменьшают долг намерения

Skill - это способ вынести проектное знание из головы и из чата. Обычно это папка с SKILL.md, метаданными, инструкциями, примерами, скриптами и ссылками. Агент вызывает skill явно, например через $name или /skills, либо подхватывает его по описанию задачи.

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

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

Плагин в этой картине - способ упаковать и распространить skills вместе с коннекторами. Если skill фиксирует знание, plugin помогает перенести готовую настройку между репозиториями и командами.

Коннекторы превращают цикл в часть среды

Цикл, который видит только файловую систему, остается маленьким. MCP-коннекторы дают агенту доступ к тому, где на самом деле живет работа: issue tracker, CI, база данных, staging API, Slack, документация, система мониторинга.

Разница большая. Агент без коннекторов может написать: 'вот исправление'. Цикл с коннекторами может открыть PR, связать его с задачей в Linear, дождаться зеленого CI и отправить сообщение в канал. То есть он превращает рекомендацию в действие внутри рабочей среды.

Здесь нужно заранее разделять два режима: цикл только сообщает или цикл меняет состояние. Для отчетных циклов риск ниже: они собирают факты, а человек решает, что запускать. Для циклов, которые создают ветки, PR и комментарии, нужны более строгие права, журналирование и проверки.

Субагенты разделяют автора и проверяющего

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

В Codex субагентов можно описывать как TOML-файлы в .codex/agents/: имя, описание, инструкции, модель, уровень рассуждения. В Claude Code аналогичная идея живет в .claude/agents/ и командах агентов. Типовое разделение ролей: исследователь находит контекст, исполнитель меняет код, проверяющий сверяет результат со спецификацией и тестами.

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

Не все проверки обязаны быть модельными. Из обсуждения вокруг статьи полезно вынести еще один слой: дешевые проверки формы артефакта, контрактов, вывода команд, тестов и инвариантов часто надежнее и быстрее, чем еще один LLM-судья. Модельный ревьюер лучше оставить для того, что нельзя выразить простым тестом.

Как выглядит один рабочий цикл

Представим спокойный утренний цикл для репозитория.

1. Автоматизация запускается каждый день и вызывает triage skill.
2. Skill читает вчерашние падения CI, открытые задачи, свежие коммиты и заметки из состояния.
3. Результаты попадают в Markdown-файл или доску Linear: что важно, что можно отложить, что требует человека.
4. Для задачи, которую можно делать автоматически, цикл открывает отдельное рабочее дерево.
5. Субагент готовит исправление, второй субагент проверяет его против skills, тестов и требований.
6. Коннекторы создают PR, обновляют задачу и отправляют уведомление, если CI прошел.
7. Все, что цикл не смог решить, попадает во входящий список для человека.

Состояние - позвоночник такой системы. Если в нем написано только 'готово', оно бесполезно. Хороший журнал хранит попытки, причины отказа, ссылки на PR, вывод ключевых проверок, нерешенные вопросы и следующий безопасный шаг.

При этом журнал нельзя слепо считать истиной. Если его пишет тот же цикл, которому мы не доверяем без проверки, состояние нужно сверять с источниками фактов: Git, CI, тестами, issue tracker и ручными решениями. Иначе цикл начинает верить собственной памяти.

Что обсуждение добавило к идее

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

• Расход токенов непредсказуем. У людей с разными лимитами один и тот же цикл будет ощущаться по-разному. Там, где у команды почти безлимитный бюджет, цикл можно держать шире. На обычном плане придется выбирать, какие проверки действительно окупаются.
• Качество нужно уметь измерять. Если команда не может описать, что для нее является хорошим результатом, цикл будет масштабировать неопределенность.
• Тихий сбой опаснее громкого. Плохой цикл не обязательно падает. Он может регулярно выпускать мелкие сомнительные изменения, а команда постепенно перестанет понимать кодовую базу.
• Человек должен видеть ход работы. Полезна отдельная проверочная сессия или обзорный чат, где можно разобрать, что цикл сделал, почему он так решил и какие вопросы остались.
• Сначала отчет, потом запись. Для новых циклов разумно начинать с режима наблюдения: пусть они собирают и объясняют работу, но не меняют состояние без явного разрешения.

Что цикл не решает

Инженерия циклов меняет форму работы, но не снимает ответственность.

Проверка остается на инженере. Цикл, который работает без наблюдения, способен ошибаться без наблюдения. Разделение автора и проверяющего повышает доверие, но 'готово' все равно остается утверждением, пока оно не подтверждено тестами, ревью и фактическим поведением системы.

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

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

Собирайте цикл, но оставайтесь инженером

Loop engineering выглядит как следующий шаг после ручной работы с кодинг-агентами. Сначала мы учились писать хорошие запросы. Теперь все чаще нужно проектировать систему, которая сама формирует задачи, дает контекст, запускает исполнителей, проверяет результат, записывает состояние и повторяет процесс.

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

Два человека могут собрать одинаковый контур и получить противоположные последствия. Один ускорит работу, которую понимает глубоко. Другой быстро накопит код, за который уже не может отвечать. Цикл не отличит эти случаи. Инженер - должен.

Источник

• Оригинальная публикация Addy Osmani в X: https://x.com/i/status/2064127981161959567

Сообщество энтузиастов - https://t.me/agents_lab