Не будь оператором LLM – освой Loop Engineering с агентами

Если почитать комментарии под видео, многие уже научились эффективно промтить LLM, использовать агентов, скиллс и MCP в разработке. Но оказывается, в 2026 году этого уже недостаточно. История, когда мы вручную написали промт, дождались ответа, проанализировали результат и написали следующий промт, плохо масштабируется. В такой парадигме разработчик все чаще превращается из инженера в оператора LLM. Он не проектирует систему, а ведет агента за руку. Если ты взаимодействуешь с агентом больше, чем пишешь код, или принимаешь инженерные решения самостоятельно, значит, скорее всего, ты уже уперся в потолок возможностей текущего способа работы. Нужны новые подходы. И один из таких подходов – это Loop Engineering. Это не просто улучшенный промт или контекст инжиниринг, как может показаться из названия. Это паттерн проектирования агентских workflow. Мы создаем не один промпт, а цикл, который сам запускает агент и передает ему задачи, проверяет результат, сохраняет состояние и решает, что делать дальше. Всем привет! В этом видео я расскажу про саму концепцию Loop Engineering, разберу из каких компонентов она состоит, обсудим риски применения и посмотрим, как внедрить эту парадигму постепенно и без лишнего риска. Название Loop Engineering в 2026 году начал использовать Eddie Asmani. инженерный лидер, много лет работавший в Google и Google Cloud AI. Он написал пост о том, что работа программистов, которые используют кодинг-агентов, все больше смещается от простого промтинга к проектированию циклов, которые будут автоматически промтить модель. При этом сама идея проектировать циклы, которые промтят агентов, появилась не на пустом месте. Похожую мысль высказывал Борис Черный из Anthropic, руководитель CloudCode. Он говорил, что больше не пишет промты напрямую, а проектирует циклы вокруг модели. Давайте разбираться, из чего состоит Loop Engineering. Для простоты понимания выделим внутренний и внешний циклы. Внутренний цикл – это то, что агент делает по умолчанию, собирает контекст, анализирует его, выполняет действия, получает обратную связь, исправляет ошибки и продолжает работу. Но чтобы автоматизировать запуск и управление этим внутренним циклом, нужен внешний цикл. Его как раз проектирует разработчик. Во внешнем цикле появляются триггеры, расписание, изоляция работы агента. декомпозиция задач, управление множеством итераций, критерии успешного выполнения, лимиты, проверки и условия завершения цикла. Именно это и отличает Loop Engineering от обычного промтинга. Мы проектируем не отдельный запрос к модели, а систему, которая управляет тем, как, когда и зачем модель получает задачи. При этом Loop Engineering не отменяет промт и контекст инжиниринг. Нам все равно нужно следить за качеством промта и контекста. Плохой промт внутри цикла будет тиражировать ошибки. Плохой контекст будет нестабильно влиять на архитектуру проекта и проводить агента к неправильным решениям, поэтому качество промпта и контекст остается обязательным. У Loop Engineering есть родственные практики. Один из них – так называемый Ralph Wigam Loop или техника Ральфа. Это простой паттерн автономной работы агента. Когда он выполняет небольшую атомарную задачу, фиксирует изменения, сохраняет состояние и завершает итерацию. Следующая итерация начинается как новая сессия с чистым контекстом. Вы наверняка замечали, что продолжительные сессии часто деградируют. Контекстное окно переполняется, появляются нерабочие версии файлов, ошибочные рассуждения, устаревшие промежуточные решения. Все это засоряет контекст и снижает качество результата. В RALF подходе состояние хранится не только внутри модели, но и снаружи. Например, у нас могут быть plan.md и status.md. Из plan.md агент берет новые задачи, а в status.md записывает то, что уже сделал. где возникли ошибки и что нужно проверить дальше. Конкретные названия файлов могут быть любыми. Важно не это, важно, что память процесса живет вне контекстного окна модели и не теряется между итерациями. Теперь перейдем к компонентам Loop Engineering. В популярной формулировке Edi Osmani у Loop Engineering есть пять основных компонентов, а также память. Первый компонент – Automations или автоматизация. Это процесс, который запускает цикл по расписанию или событию, делает первичный разбор задач и решает, есть ли работа, которую нужно передать агенту. Второй компонент – Git WorkTrees. Это изолированные рабочие деревья Git. Они нужны, чтобы параллельные агенты не писали в одну и ту же рабочую директорию и не ломали незавершенную работу друг друга. Важно уточнить, WorkTrees не отменяют конфликты слияния в Git полностью. Если два агента изменят одни и те же строки, конфликт может появиться позже. при интеграции изменений. Но WorkTrees помогают избежать хаоса во время самой работы. Каждый агент получает отдельную директорию, свой хэд, свой индекс, в зависимости от настройки, отдельную ветку. Третий компонент — это скилл, который вытащит баги из логов, проверит открытые тикеты в TaskTracker, пополнит файл todo.md для дальнейшей обработки агентами. Четвертый компонент — плагины и коннекторы. Они связывают агентов с реальными инструментами CICD, таск-трекерами, базами данных, системами алертинга и мониторинга, Slack, GitHub, Jira и другими сервисами. Часто такая интеграция делается через MCP. Пятый компонент — субагенты. Нужны для разделения ролей. Например, один агент пишет код, а другой независимо проверяет его. Это паттерн Maker Checker. Maker делает, Checker проверяет. И шестой элемент, который часто выделяют отдельно — память. Это внешний источник правды о всем процессе. Это может быть Markdown файл в репозитории, текет в жире, запись в базе данных или другая система хранения состояния. Смысл в том, что память живет вне контекстного окна и сохраняется между сессиями. Если сама идея проектировать автономные циклы вокруг агентов кажется вам полезной, поставьте лайк этому видео. Для YouTube это сигнал, что такие инженерные разборы стоит показывать большему числу разработчиков. Теперь посмотрим, как это может выглядеть на практике, например, в кодексе CloudCode. В кодексе эта история может настраиваться через Automations. Там можно выбрать проект, промт, который будет запускаться автоматически, расписание выполнения и среду выполнения, локальную папку или GitWork3. Для Git-репозиторий в Automations могут запускаться в отдельном BackgroundWork3, чтобы не конфликтовать с текущей локальной работой. В CloudCode есть команда Loop. Это регулярный запуск промта по расписанию. Фактически крон-лайк механизм внутри сессии. Его можно использовать, например, чтобы периодически проверять статус деплоя, continuous integration, pull request или другой продолжительный процесс. Также в Cloud Code есть hooks и GitHub Actions. С их помощью можно встроить агентов жизненной циклы разработки, запускать проверки, форматировать файлы, реагировать на события, выполнять автоматизацию в GitHub Workflow и переносить часть процесса на удаленную инфраструктуру. Отдельно стоит упомянуть команду Goal. Она задает условия завершения. Агент продолжает работать до тех пор, пока это условие не будет выполнено. В Cloud Code команда Goal после каждого шага использует отдельную быструю модель, которая оценивает, достигнуты ли условия. Но эта модель не запускает тесты сама и не читает файлы независимо. Она судит по тому, что основной агент уже сделал и показал в контексте. Поэтому тесты, линтеры, сборка и другие проверки должны быть явно встроены в основной цикл или хуки. По сути, у нас получается несколько уровней автономности. Первый уровень – выполнение задач по расписанию, например, мониторинг багов, проверка CI или сортировка входящих задач. Второй уровень – выполнение цели по итерациям. Агент продолжает работать, пока не достигнет заданного результата. Третий уровень – независимая проверка критериев готовности. Отдельный чекер, модель или автоматическая проверка по правилам определяет, можно ли считать задачу выполненной. Здесь критически важны четкие критерии успешности. Не должно быть абстрактных формулировок вроде «сделай хорошо», «улучши качество» или «доведи до идеала». Такие условия могут привести либо к преждевременному завершению цикла, либо к бесконечным итерациям. Бесконечная итерация – это не только потеря времени, но и повышенный расход токенов, лимитов и бюджета. Поэтому за этим нужно следить. Давайте поговорим, как составить хороший контракт. Сначала задаем измеримую цель. Например, если мы хотим покрыть тестами 80% кодовой базы, то, на удивление, так и пишем. Цель — довести тест-каverage до 80%. Дальше задаем критерии, которые машина сможет проверить. Если речь идет о тестах, указываем конкретную команду и ожидаемый результат. Например, npm-тест завершается с exit-code 0. npm-run-lint проходит без ошибок. Каверич-репорт показывает не меньше 80%. Также в контракте нужно задать границы, что нельзя трогать, запускать или редактировать. Например, не использовать интернет, не вызывать публичные API, не редактировать конкретные файлы, а также не менять схему базы данных, не трогать production-конфиги. Дальше задаем лимит по итерации, времени или бюджету. Например, задача должна выполняться не больше 25 итераций или не дольше 2 часов. Если условие не достигнуто, агент должен остановиться и передать задачу человеку. В цикл нужно встроить логирование и проверки, а также определить стоп-факторы, условия, при которых цикл должен завершиться. Например, если после изменений начинают падать интеграционные тесты, это может быть стоп-фактором для остановки агента и передачи задачи разработчику. Все, кто работал с AI-агентами LLM, неважно, это недорогие open-source модели или топовые коммерческие модели вроде Cloud Opus, GPT-5 или Gemini, наверняка замечали одну вещь. Агент часто склонен считать результат своей работы корректным. Иногда приходится спорить с агентом и доказывать, что решение не идеальное. Более того, агент может сгенерировать в принципе нерабочее решение. Например, агент написал код, вы пытаетесь его запустить, и сервис падает с ошибками. Именно здесь нужен валидатор. Простыми словами, мы назначаем отдельную модель отдельного агента или тест-скрипт для автоматизированной проверки результата работы. Или тест-скрипт для автоматизированной проверки результата работы. Это и есть история про Pattern Banker Checker. Теперь поговорим подробнее про Git WorkTrees. Git WorkTree — это способ вести параллельную работу в одном репозитории через отдельные рабочие директории. У каждого в WorkTree своя копия файлов проекта, свой хед, свои индексы и отдельное состояние рабочей директории. При этом история репозитория остается общей. Для агентов это особенно важно. Когда несколько агентов работает параллельно, появляется конкуренция за одни и те же файлы. Если все они пишут в одну территорию, можно получить хаос. Один агент переписывает изменения другого, ломаются промежуточные состояния, непонятно кто что поменял. Здесь Work3 изолирует работу физически. Агенты работают в разных Work3s и не мешают друг другу на уровне файловой системы. Но Work3 не решает все конфликты. Если два агента изменили одну и ту же часть кода, конфликт может возникнуть позже, когда вы будете объединять изменения. Поэтому Work3s это не замена ревью и мердж процесса, а способ безопаснее организовать параллельную работу агентов. А также стоит упомянуть про Skills и память. Asmani предлагает определить в Skills проектные правила. Например, как собирать проект, какие команды запускать для сборки и тестов, какие архитектурные ограничения соблюдать, какие папки нельзя трогать, какие паттерны считаются допустимыми. Но на мой взгляд для этого есть Agents.md. В контексте Loop Engineering логичнее добавить Skills, инструкции, которые извлекут ошибки из логов CI, Проверят открытые тикеты в TaskTracker и пополнят имя файл to do.md для дальнейшей обработки агентами. Память — это динамическое состояние, что уже сделано, что не прошло тесты, что находится в очереди, какие гипотезы проверялись, какие решения были отклонены, какие задачи требуют внимания человека. Коннекторы через MCP дают агенту доступ к внешним системам, алертингу, мессенджерам вроде Slack, TaskTracker, базам данных, GitHub, CICD. Это нужно, чтобы закрывать весь рабочий процесс, от тикета до пол-реквеста и уведомления. И давайте рассмотрим паттерн Maker Checker. Это паттерн, в котором один участник создает результат, а другой независимо его проверяет. В контексте агентских систем, Maker — это агент, который пишет код или предлагает решение. Checker — это агент, который проверяет результат, запускает тесты, смотрит дифф, сверяет изменения с архитектурными правилами и критериями задачи. Почему нельзя просто доверить проверку тому же агенту? Потому что модель, которая только что написала решение, часто слишком лояльна к собственному результату. Она может не заметить логическую ошибку, пропустить нарушение архитектуры или убедить себя, что задача выполнена. Хотя на самом деле это не так. Отдельный чекер снижает этот риск. Не устраняет полностью, но снижает. Практическая реализация субагентов можно настраивать через конфигурационные файлы. Там создается имя агента, его роль, специализация, модель, уровень резонинга и инструкции. Например, более мощные модели можно ставить на аудит, архитектуру и верификацию, более быстрые и дешевые модели – на исследование кодовой базы, сбор контекстов или подготовку простых изменений. Давайте обсудим, как может выглядеть весь процесс. Например, по триггеру или расписанию срабатывает планировщик. Он запускает скилл-разбор задач, собирает информацию из CICD, логов, тикетов или алертов и записывает состояние в файл со списком задач, например, todu.md. Для каждой задачи создается изолированный Gitwork3. В нем запускается исполнитель, субагент Maker. Он анализирует задачу, вносит изменения, запускает проверки и фиксирует результат. После этого субагент Checker проверяет диф, прогоняет тесты, сверяет изменения с конвенциями проекта и критериями успешности. Если все в порядке, агент через MCP может создать pull request и обновить статус задачи в трекере. Если есть сомнения, задача уходит в статус, который требует проверки разработчикам. Например, в Jira можно настроить отдельный статус, вроде «Необходимо ревью кожаного» или «Внимание нейрослоп». Как сконфигурировать чекер-агента? Условия должны быть максимально конкретными. Тесты прошли успешно, проект запускается без критических ошибок. Линтер и тайп-чекер проходят. Структура папок не нарушена. Архитектурные ограничения соблюдены. Запрещенные файлы не изменены. Критерии задачи выполнены. Див не содержит подозрительных изменений вне скоупа задачи. Если все соблюдено, изменения можно передать на ревью или автоматический мерж, в зависимости от уровня зрелости процесса. Если нет, результат работы агента отклоняется, а задачи переводятся на разработчика для контрольной проверки. Плюс у нас есть файл состояния, например status.md. куда записывается информация по итерациям, что запускалось, что прошло, что упало, какие решения были приняты и что нужно сделать дальше. Теперь поговорим о матрице зрелости, то есть о том, как внедрить Loop Engineering постепенно. Это не официальный стандарт, а удобная практическая модель. На первом уровне мы все делаем руками. Промтим агента, проверяем результат вручную, если нужно, снова промтим, чтобы он внес изменения или исправил баги. На втором уровне система сама разбирает задачи из JIR, GitHub issues или другого трекера и формирует todo.md. Код при этом все еще пишет разработчик, агент код не трогает. На третьем уровне агент уже занимается правками в выделенном Gitwork 3. Программист проверяет div, запускает тесты и вручную мержит изменения. На четвертом уровне появляется чекер, отдельный агент, модель или набор автоматических проверок по правилам, которые валидирует pull request. Разработчик в этом случае делает финальное одобрение, если все выглядит нормально. На пятом уровне система сама мержит изменения после успешного прохождения тестов, линтеров и других проверок. Разработчик контролирует процесс по логам, алертам и периодическим код-ревью, не погружаясь в каждое изменение. Казалось бы, хорошо бы сразу перейти на самый верхний уровень. Мы написали задачи, задали критерии успешности, настроили цикл и система сама все делает. Но переходить сразу на этот уровень опасно. У Loop Engineering есть несколько рисков, которые особенно заметны именно при росте автономности. Первый риск – это повышенный расход токенов и бюджета. Если цикл плохо ограничен, агент может гонять итерации впустую. Повторять одни и те же действия, запускать слишком дорогие модели и тратить лимиты без реального прогресса. Второй риск – тесты и ложное чувство безопасности. Тесты – это хорошо, но они не дают стопроцентному доказательству, что весь код корректен, архитектура соблюдена, а приложение работает именно так, как задумано. Более того, есть риск, что агент будет писать тесты так, чтобы они подтверждали его собственное решение, а не реальные требования. Это риск подгонки решений под формальные критерии. Тесты проходят, метрика достигнута, но реальная задача может быть решена неправильно. Поэтому тесты должны быть частью проверки, но не единственным источником истины. Все равно финальный чекер – это разработчик. Особенно если речь идет о продакшн-коде. Можно автоматизировать запуск тестов, линтеров, тайп-чек, превью-деплой, смок-тест и проверки на тестовом стенде. Но если вы деплойте код, написанный агентами, в продакшн ответственность все равно остается на людях. Третий риск – это архитектурная деградация. Агент может локально решить задачу, но нарушить общий дизайн системы. Например, дублировать код, сломать импорты модулей, добавить ненужной зависимости или обойти существующие абстракции. Даже если вы описали корректные конвенции, архитектурные решения и правила, это не значит, что агент будет строго их придерживаться. Чекер может проверить, что приложение работает, но не факт, что он заметит нарушение архитектуры, плохой дизайн или будущие проблемы сопровождения. Четвертый риск – это эффект бутылочного горлышка. Агенты, особенно если запускать их параллельно, очень быстро генерируют код. Но скорость генерации кода не равна скорости принятия инженерных решений. Разработчик все равно должен спроектировать архитектуру решения, разбить работу на атомарные задачи и задать для каждой задачи конкретно измеримые критерии оценки. Если этого не сделать, агенты начнут производить много изменений, которые вроде бы выглядят полезно, но постепенно увеличивают когнитивный долг. Вы можете потерять связь с проектом, перестать понимать, что именно изменилось, почему появилась такая структура пабок, откуда взялись новые зависимости и зачем были добавлены новые абстракции. Поэтому код-ревью остается обязательным. Нужно смотреть, что агенты пишут, понимать структуру изменений, проверять импорты, границы модулей, архитектурные решения и последствия для проекта. Пятый риск – соблазн отключить критическое мышление. Вы видите, что агент написал код, приложение запускается, тесты прошли, чекер ничего не нашел и кажется, что все готово. Но это не всегда так. Автоматизация снижает нагрузку, но не отменяет ответственность инженера. Поэтому внедрять Loop Engineering нужно по нарастающей. Сначала ручной контроль, все результаты работы агента нужно самостоятельно проверять. Затем постепенная автоматизация. Сначала подготовка задач, потом изолированный WorkTrees. потом мейкер-чекер, потом частичный автомердж, только для безопасных классов задач. Автономию нужно давать не сразу, а по мере того, как вы понимаете, где агент стабильно справляется с решением задач, а где ошибается. Главный вывод такой. Loop Engineering нужно внедрять через баланс. Задачи должны быть атомарными, с конкретными измеримыми и проверяемыми критериями. У цикла должны быть лимиты, логи, условия завершения и понятный механизм передачи задачи человеку. Промпт и контекст инженеринг никуда не исчезают, они становятся частью более крупной системы. Хороший промпт и хороший контекст все еще важны, но теперь инженерная задача не просто написать один удачный промпт, а спроектировать цикл, который будет безопасно использовать промпты, контекст, инструменты, проверки и внешнюю память. Техника Raleflop показывает ценность коротких итераций с чистым контекстом и внешним состоянием. MakerChecker доказывает, почему автономной системе нужен независимый слой верификации. Gitworktrees помогает безопаснее организовать параллельную работу агентов. Agents.md фиксирует проектные правила. Память сохраняет состояние между сессиями. MCP и коннекторы связывают агента с реальным workflow, тикетами, CICD, pull-реквестами, алертами и мониторингом. Но финальная ответственность все равно остается на разработчике. Если вам интересны такие практические разборы AI и разработки, агентских workflow и новых инженерных подходов, подписывайтесь на канал. Дальше будем разбирать не только концепции, но и конкретные схемы внедрения, как настраивать агентов, как проектировать циклы, как писать критерии успешности и как безопасно давать AI большей автономности. Всем пока!

Ты просто нажимаешь Enter промпт за промптом? Значит ты оператор LLM. Время стать инженером.

В этом видео – продвинутые техники Loop Engineering: как строить agentic AI системы, которые сами себя проверяют, корректируют и не ломаются при первой же ошибке.

Если ты работаешь с AI agents или хочешь перейти от простых LLM-запросов к настоящим agentic AI пайплайнам – это видео именно для тебя.

Текстовая версия с подробными диаграммами доступна по ссылке: https://ai4dev.ru/posts/loop-engineering/

⏱ Тайм-коды:
0:00 – Почему промптинга уже недостаточно
0:42 – Что такое Loop Engineering
1:48 – Inner Loop и Outer Loop
2:57 – Техника Ralph
3:59 – Компоненты Loop Engineering
5:58 – Практическая реализация в Codex и Claude Code
8:19 – Контракт успешности
9:34 – Валидатор и Maker-Checker
10:16 – Git WorkTrees
11:12 – Skills, Memory и MCP
13:19 – Весь процесс
15:02 – Матрица зрелости
16:26 – Главные риски
19:09 – Постепенное внедрение
19:34 – Главный вывод
20:48 – Финал

#AIAgents #AgenticLoop #LoopEngineering