Разборы · Статья: · Видео: · 20:56
Loop Engineering: как перестать быть оператором LLM и начать проектировать циклы
Разбор концепции Loop Engineering: почему ручной промтинг упёрся в потолок, из каких шести компонентов состоит автономный цикл вокруг агента, как написать для него проверяемый контракт и по каким пяти рискам автономность ломает проект.
Смотреть на YouTube Не будь оператором LLM – освой Loop Engineering с агентами
Eugene Pro AI · 20:56
Главы видео — нажми, чтобы перейти к моменту 9
- 0:34 Оператор LLM против инженера циклов Почему ручной промтинг плохо масштабируется и как разработчик незаметно превращается в оператора модели.
- 1:44 Внутренний и внешний цикл Внутренний цикл агент делает сам; внешний — триггеры, изоляцию, лимиты и критерии — проектирует разработчик.
- 2:59 Техника Ральфа и внешняя память Короткие атомарные итерации с чистым контекстом; состояние живёт снаружи, в plan.md и status.md.
- 3:53 Шесть компонентов Loop Engineering Automations, git worktrees, skills, коннекторы через MCP, субагенты и внешняя память.
- 5:59 Как это выглядит в Codex и Claude Code Codex Automations, команда /loop, hooks, GitHub Actions и /go с быстрой судейской моделью.
- 8:04 Хороший контракт для агента Измеримая цель, машинно-проверяемые критерии, границы, лимиты итераций и стоп-факторы.
- 12:00 Maker-Checker: зачем нужен независимый чекер Модель слишком лояльна к своему результату, поэтому проверять её должен отдельный агент.
- 14:48 Матрица зрелости: пять уровней автономности От полностью ручной работы до авто-мёржа — как внедрять постепенно.
- 16:02 Пять рисков автономных циклов Расход бюджета, подгонка тестов, архитектурная деградация, бутылочное горлышко ревью и потеря бдительности.
Коротко
Если ты общаешься с агентом больше, чем принимаешь инженерные решения, ты превратился из инженера в оператора LLM — и упёрся в потолок ручного промтинга. Loop Engineering предлагает проектировать не отдельный промт, а цикл вокруг модели: с внешней памятью, изоляцией, независимым чекером, измеримым контрактом и лимитами — но внедрять его по нарастающей, оставляя финальную ответственность на человеке.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Раньше разработчик писал промт, ждал ответ, писал следующий — вручную вёл ИИ за руку. Loop Engineering — это про то, чтобы вместо ручного диалога построить автоматический цикл: система сама запускает агента по расписанию или событию, даёт ему задачу, проверяет результат, хранит состояние в отдельных файлах и решает, что делать дальше. Человек проектирует правила этого цикла и остаётся финальным контролёром, а не набирает каждый следующий промт руками.
Как ребёнку
Представь робота-помощника для уроков. Раньше ты стоял рядом и подсказывал каждый шаг. Теперь ты пишешь ему чёткую инструкцию: сделай вот это, проверь себя вот так, а если не получилось за пять попыток — позови меня. Робот работает сам, а ты только смотришь на итог. Loop Engineering — это искусство писать такие инструкции для ИИ-программиста.
Аналогия — «это как…»
Это как перейти от роли повара, который сам жарит каждую котлету, к роли шеф-повара: ты настроил кухню — расписал рецепты, поставил таймеры, назначил, кто готовит и кто пробует блюдо, — и вмешиваешься, только когда что-то подгорает.
Зачем это мне
Если ты тратишь на переписку с агентом больше времени, чем на инженерные решения, ты упёрся в потолок текущего способа работы. Разбор показывает, как масштабировать работу с ИИ без потери контроля — и одновременно честно предупреждает, где автономность агентов жжёт бюджет, ломает архитектуру и усыпляет критическое мышление.
Для тех, кто в теме
Систематизация внешнего цикла поверх внутреннего agent loop: триггеры, worktree-изоляция параллельных агентов, декомпозиция, машинно-проверяемый контракт (exit-code и coverage-критерии, границы, лимиты итераций, стоп-факторы), maker-checker верификация и внешнее состояние (Ральф-паттерн, plan.md/status.md). Практика привязана к Codex Automations, Claude Code /loop, hooks и /go с быстрой судейской моделью. Ключевой нюанс: /go судит по контексту основного агента, поэтому тесты, линтеры и сборку надо явно встраивать в цикл. Замыкают разбор матрица зрелости L1–L5 и пять рисков автономности.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Термин Loop Engineering введён в 2026-м (Эди Османи, перекличка с Борисом Чёрным из Anthropic), а привязка к Codex Automations и Claude Code /loop свежая.
Плотный разбор: шесть компонентов, контракт, матрица зрелости и пять рисков без явной воды.
Сильный синтез, но концепция чужая (Османи, Чёрный), а половина практик — переупакованные CI и оркестрация агентов.
Даёт конкретный контракт (exit-code, coverage, лимиты, стоп-факторы) и пошаговую матрицу внедрения.
Полразбора — честные риски автономности, а не хайп; финал прямо оставляет ответственность на человеке.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков и программистов 4.8 /5
Прямое попадание: как перестроить ежедневную работу с кодинг-агентами, где ставить лимиты и как не утонуть в ручном промтинге.
Для тимлидов и инженерных менеджеров 4.4 /5
Матрица зрелости и maker-checker — готовый каркас, как постепенно давать команде агентов автономию без потери контроля над архитектурой.
Для ML- и AI-инженеров 4.1 /5
Полезно про декомпозицию задач, внешнюю память и разведение ролей моделей (мощные на аудит, дешёвые на сбор контекста).
Для DevOps- и платформенных инженеров 3.9 /5
Worktree-изоляция, коннекторы через MCP, hooks и GitHub Actions ложатся на задачу встроить агентов в CI/CD и мониторинг.
Для QA-инженеров 3.7 /5
Разбор прямо показывает риск подгонки тестов под решение агента и почему независимая верификация обязательна.
Для технических основателей 3.5 /5
Помогает трезво оценить, где автономные агенты реально ускоряют разработку, а где растят когнитивный долг и жгут бюджет.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Метрика, что ты стал оператором, а не инженером 0:16
Простой самотест: если ты взаимодействуешь с агентом больше, чем пишешь код или принимаешь инженерные решения сам, ты уже упёрся в потолок текущего способа работы. Это не про мощность модели, а про то, кем стал ты.
02 Объект труда сместился с промта на систему 1:44
Ценность инженера теперь не в одном удачном промте, а в проектировании цикла, который решает как, когда и зачем модель получает задачи. Это ближе к системному дизайну и оркестрации, чем к переписке с чат-ботом.
03 Память должна жить вне контекста модели 2:59
Длинные сессии деградируют: контекст засоряется нерабочими версиями и устаревшими рассуждениями. Контринтуитивный вывод — чистый контекст на каждой итерации плюс состояние в файлах (plan.md, status.md) даёт результат стабильнее, чем одна большая сессия.
04 Агент — плохой судья самому себе 12:17
Модель, только что написавшая решение, склонна считать его корректным и защищать. Поэтому self-review не работает: проверять должен независимый чекер — другой агент, модель или тест-скрипт, а не тот же самый агент.
05 Узкое горлышко переезжает на человека 17:53
Агенты генерируют код быстрее, чем человек принимает инженерные решения. Если не дробить задачи и не задавать критерии, растёт когнитивный долг: изменений много, но ты теряешь связь с проектом и перестаёшь понимать, откуда взялись зависимости и абстракции.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«В такой парадигме разработчик всё чаще превращается из инженера в оператора ЛМ. Он не проектирует систему, а ведёт агента за руку.»
«Мы создаём не один промт, а цикл, который сам запускает агента, передаёт ему задачи, проверяет результат, сохраняет состояние и решает, что делать дальше.»
«Плохой промт внутри цикла будет тиражировать ошибки.»
«Не должно быть абстрактных формулировок. Вроде сделай хорошо, улучши качество или довети до идеала.»
«Модель, которая только что написала решение, часто слишком лояльна к собственному результату.»
«Скорость генерации кода не равна скорости принятия инженерных решений.»
«Автоматизация снижает нагрузку, но не отменяет ответственность инженера.»
«Инженерная задача — не просто написать один удачный промт, а спроектировать цикл, который будет безопасно использовать промты, контекст, инструменты, проверки и внешнюю память.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Замерь, сколько ты оператор, а не инженер
15 минут поймёшь, упёрся ли ты в потолок ручного промтинга
Замерь, сколько ты оператор, а не инженер
Понаблюдай за рабочим днём: сколько времени уходит на переписку с агентом против времени на код и архитектурные решения. Перекос в сторону диалога — сигнал переходить к проектированию циклов.
Что делать
- 1 Один рабочий день грубо отмечай: сейчас я промчу агента или принимаю решение сам.
- 2 В конце дня прикинь соотношение.
- 3 Если разговоров с агентом заметно больше — выбери одну повторяющуюся задачу под автоматизацию.
2 Заведи внешнюю память для агента
30 минут состояние перестанет теряться между сессиями
Заведи внешнюю память для агента
По технике Ральфа состояние процесса должно жить снаружи модели. Заведи два файла: из плана агент берёт задачи, в статус пишет, что сделал, где ошибся и что проверить дальше.
Что делать
- 1 Создай в репозитории plan.md со списком атомарных задач.
- 2 Создай status.md, куда агент после каждой итерации пишет итог.
- 3 В промте цикла явно укажи читать план и обновлять статус.
3 Дроби задачи на атомарные с чистым контекстом
вечер меньше деградации и мусора в контексте
Дроби задачи на атомарные с чистым контекстом
Вместо одной длинной сессии — короткие итерации: маленькая задача, фиксация изменений, сохранение состояния, новая сессия с чистого листа. Так контекстное окно не переполняется устаревшими решениями.
4 Напиши агенту машинно-проверяемый контракт
1 час цикл перестанет завершаться на глазок
Напиши агенту машинно-проверяемый контракт
Абстрактное сделай хорошо ведёт либо к преждевременному завершению, либо к бесконечным итерациям. Задай измеримую цель и критерии, которые проверит машина, а не человек на ощущениях.
Что делать
- 1 Сформулируй цель числом: например, довести покрытие тестами до 80%.
- 2 Задай проверяемые критерии: npm test с exit code ноль, coverage не меньше 80%.
- 3 Пропиши границы: что нельзя трогать (prod-конфиги, схему БД, публичный API).
5 Поставь лимиты и стоп-факторы
20 минут не сольёшь бюджет и токены на пустые итерации
Поставь лимиты и стоп-факторы
Бесконечная итерация — это не только потеря времени, но и расход токенов и лимитов. Задай потолок и условия аварийной остановки с передачей задачи человеку.
Что делать
- 1 Ограничь: не больше 25 итераций или не дольше 2 часов.
- 2 Определи стоп-факторы: например, упали интеграционные тесты — стоп и передача разработчику.
- 3 Встрой в цикл логирование, чтобы видеть, что запускалось и что упало.
6 Разведи роли Maker и Checker
полдня независимая проверка вместо самолюбования агента
Разведи роли Maker и Checker
Один субагент пишет код, другой независимо проверяет: гоняет тесты, смотрит diff, сверяет с архитектурными правилами. На аудит ставь модель помощнее, на сбор контекста — быструю и дешёвую.
Что делать
- 1 Опиши в конфиге двух субагентов: maker и checker с разными ролями и моделями.
- 2 Задай чекеру максимально конкретные условия приёмки.
- 3 Настрой: чекер сомневается — задача уходит человеку на ревью.
7 Изолируй параллельных агентов в git worktree
30 минут агенты перестанут ломать работу друг друга
Изолируй параллельных агентов в git worktree
Отдельное рабочее дерево даёт каждому агенту свою копию файлов, свой head и индекс при общей истории репозитория. Это не отменяет конфликты слияния позже, но убирает хаос во время самой работы.
8 Внедряй по матрице зрелости, а не прыжком
недели дашь автономию там, где агент реально стабилен
Внедряй по матрице зрелости, а не прыжком
Не переходи сразу на авто-мёрж. Двигайся по уровням: сначала ручной контроль, потом разбор задач в todo, потом правки в worktree, потом чекер, и только затем частичный автомёрж для безопасных классов задач.
Сценарии применения
Как разные люди применяют это на практике
Я как Разработчик в продуктовой команде
Проблема: полдня уходит на однотипную переписку с агентом по багам из логов
Хочу: чтобы рутина разбиралась сама, а я занимался архитектурой
Поможет: статья показывает, как настроить разбор задач в todo и запускать агента по расписанию, оставив себе ревью
Я как Тимлид
Проблема: команда бесконтрольно гоняет агентов, и я теряю связь с тем, что меняется в проекте
Хочу: постепенно дать автономию, не потеряв контроль над архитектурой
Поможет: матрица зрелости даёт готовые пять уровней и точки, где ставить обязательный код-ревью
Я как Соло-разработчик и indie-хакер
Проблема: один человек не успевает и писать, и проверять всё, что генерирует агент
Хочу: запускать агента ночью и утром получать проверенный результат
Поможет: техника Ральфа и maker-checker показывают, как автономный цикл сам себя проверяет между итерациями
Я как Мейнтейнер legacy-проекта
Проблема: нужно поднять покрытие тестами, но вручную это бесконечно
Хочу: поставить агенту измеримую цель и уйти
Поможет: раздел про контракт даёт точную формулировку цели, критериев и стоп-факторов для такой задачи
Я как DevOps-инженер
Проблема: агентов надо встроить в CI/CD, но они дерутся за одни и те же файлы
Хочу: безопасно запускать несколько агентов параллельно
Поможет: worktree-изоляция и коннекторы через MCP показывают, как развести работу и подключить трекеры, алертинг и pull-реквесты
Я как QA-инженер
Проблема: тесты проходят, но реальная задача решена неправильно
Хочу: понять, почему нельзя доверять зелёным тестам от агента
Поможет: разбор прямо называет риск подгонки тестов под решение и объясняет роль независимого чекера
Я как Технический основатель стартапа
Проблема: соблазн сразу перевести всё на автономных агентов ради скорости
Хочу: оценить реальные риски до того, как это ударит по проекту
Поможет: пять рисков и вывод про баланс помогают решить, где автономия оправдана, а где нет
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка Ручной промтинг упёрся в потолок 0:34
Написал промт, дождался ответа, написал следующий — эта петля плохо масштабируется и превращает инженера в оператора.
-
Аргумент Нужен внешний цикл поверх внутреннего 1:44
Внутренний цикл агент делает сам; разработчик проектирует внешний — триггеры, изоляцию, декомпозицию, лимиты и условия завершения.
-
Аргумент Состояние должно жить вне контекста 2:59
Длинные сессии деградируют; техника Ральфа хранит память в файлах и стартует каждую итерацию с чистого контекста.
-
Пример Цикл собирается из компонентов 3:53
Automations, git worktrees, skills, коннекторы через MCP, субагенты и внешняя память — кирпичики автономной системы.
-
Аргумент Проверять агента должен независимый чекер 12:00
Модель лояльна к своему результату, поэтому нужен отдельный агент или тест-скрипт для верификации — паттерн maker-checker.
-
Аргумент Циклу нужен измеримый контракт 8:04
Без конкретных, машинно-проверяемых критериев и лимитов цикл либо завершается рано, либо жжёт бюджет в бесконечных итерациях.
-
Пример Автономность растёт по матрице зрелости 14:48
Пять уровней от полностью ручной работы до авто-мёржа — прыгать сразу наверх опасно.
-
Вывод Внедрять по нарастающей, ответственность на человеке 19:22
Баланс: атомарные задачи, лимиты, логи, механизм передачи человеку. Промт и контекст никуда не делись — стали частью большей системы.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Стоит ли смотреть целиком
Да — если ты пишешь код с агентами каждый день и чувствуешь, что ручной промтинг превратился в бесконечную переписку. Разбор плотный, structured и, что редкость для темы, честный: половину времени автор тратит не на восторги, а на риски автономности. За двадцать минут ты получаешь и словарь понятий (внутренний/внешний цикл, техника Ральфа, maker-checker), и практический каркас — контракт, лимиты, матрицу зрелости.
Главная ценность выпуска не в самой концепции (она чужая — Эди Османи и Борис Чёрный из Anthropic), а в том, что она собрана в связную картину и приземлена на конкретные инструменты: Codex Automations, Claude Code /loop, hooks, /go. Если убрать привязку к командам, останется устойчивая идея: инженер будущего проектирует не удачный промт, а безопасный цикл вокруг модели.
Что здесь важнее всего
Один тезис стоит вынести отдельно: тесты и зелёный чекер не равны корректности. Агент склонён подгонять проверки под собственное решение, поэтому финальным чекером — особенно для продакшн-кода — остаётся человек. Всё остальное (worktree, MCP, субагенты) — инструменты; ответственность не автоматизируется.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 6
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Чем Loop Engineering отличается от обычного промтинга?
-
2. Зачем состояние процесса выносят в файлы вроде plan.md и status.md?
-
3. Почему нельзя доверить проверку результата тому же агенту, что его создал?
-
4. Что обязательно должно быть в хорошем контракте для агента?
-
5. В чём риск, когда агент сам пишет тесты к своему коду?
-
6. Почему опасно сразу прыгать на верхний уровень автономности с авто-мёржем?
-
7. Что делает команда /go в Claude Code и в чём её ограничение?
Словарь терминов
Понять незнакомое простым языком
Показать 9 терминов Свернуть словарь
- Loop Engineering
- Проектирование не отдельного промта, а цикла вокруг модели: он сам запускает агента, ставит задачи, проверяет результат, хранит состояние и решает, что делать дальше.
- Внутренний и внешний цикл
- Внутренний — то, что агент делает по умолчанию (собрал контекст, сделал, исправил ошибки). Внешний проектирует разработчик: триггеры, расписание, изоляцию, лимиты и условия завершения.
- Техника Ральфа
- Паттерн автономной работы: агент делает маленькую задачу, фиксирует изменения, сохраняет состояние, а следующая итерация стартует как новая сессия с чистым контекстом.
- Git worktree
- Отдельное рабочее дерево репозитория: своя копия файлов, свой head и индекс при общей истории. Позволяет нескольким агентам работать параллельно, не мешая друг другу.
- Maker-Checker
- Паттерн, где один агент создаёт результат, а другой независимо его проверяет — запускает тесты, смотрит diff, сверяет с архитектурными правилами.
- MCP
- Способ подключить агента к внешним системам — трекерам, базам данных, GitHub, CI/CD, алертингу и мессенджерам, чтобы закрыть весь процесс от тикета до pull-реквеста.
- Субагент
- Отдельно настроенный агент со своей ролью, специализацией, моделью и инструкциями. Мощные модели ставят на аудит и верификацию, быстрые — на сбор контекста.
- Контракт (для агента)
- Формальное задание циклу: измеримая цель, машинно-проверяемые критерии успеха, границы дозволенного, лимиты итераций и стоп-факторы.
- Когнитивный долг
- Накопленное непонимание собственного проекта: агенты нагенерировали много изменений, и человек теряет связь с тем, откуда взялись структуры, зависимости и абстракции.
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Loop Engineering подан как новая инженерная дисциплина
Значительная часть практик — расписания, изоляция веток, независимая проверка, стоп-факторы — давно известна по CI/CD и оркестрации задач. Красивое имя переупаковывает знакомые вещи, откровения тут меньше, чем кажется из названия.
Пять компонентов и матрица зрелости подаются как канон
Это авторские формулировки Османи и самого ведущего, а не отраслевой стандарт (что для матрицы зрелости даже оговорено в видео). Полезная модель для мышления, но не универсальная истина, на которую можно опираться как на спецификацию.
Риски перечислены умозрительно, без примеров реальных провалов
Пять рисков логичны, но не подкреплены ни кейсами, ни цифрами: неясно, как часто они срабатывают и на каких классах задач. Читателю дают карту опасностей без оценки их вероятности.
Привязка к конкретным командам инструментов быстро устареет
Codex Automations, Claude Code /loop и /go активно меняются от релиза к релизу. Концепция циклов переживёт годы, а вот конкретные команды и их поведение — вопрос месяцев.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Loop Engineering — это менеджмент, а не программирование
Ты фактически становишься тимлидом армии агентов: ставишь задачи, задаёшь критерии приёмки, разделяешь роли исполнителя и ревьюера, следишь за бюджетом. Навыки управления людьми внезапно оказываются применимы к управлению моделями.
Контракт для агента — это TDD и SLA в новой обёртке
Измеримая цель плюс машинно-проверяемые критерии — по сути спецификация-как-тест из TDD и формальных методов. Стык с давней инженерной культурой: сначала пиши проверяемое условие, потом добивайся его выполнения.
Матрица зрелости работает для любой автоматизации
Тот же путь от ручного контроля к полной автономии проходили промышленная робототехника, автопилоты и RPA. Уровни доверия растут по мере накопления статистики надёжности — принцип универсален далеко за пределами кода.
Когда генерация бесплатна, дефицитом становится верификация
Если написать код почти ничего не стоит, узкое место — проверка, вкус и архитектурное суждение. Ценность инженера смещается от производства строк к умению отличить правильное решение от правдоподобного.
Похожие разборы
Циклы для ИИ-агентов простыми словами: heartbeat, cron, hook и goal в Claude Code и Codex
Цикл — это просто автоматический промпт: вы один раз проектируете агенту «должность», а он сам запускает себя по расписанию или по цели, без ваших рук на клавиатуре. Heartbeat, cron, hook и goal — это знакомые ещё до-ИИ автоматизации, которыми теперь дёргают не скрипт, а умного агента с его собственной армией сабагентов.
Читать → РазборLoop Engineer: как настроить агентов, которые сами находят и делают работу
AI Jason объясняет loop engineer как «внешний слой» вокруг агента: вы не промптите агента вручную, а настраиваете триггеры, общую файловую память и agent-friendly кодовую базу, чтобы агенты сами находили и закрывали работу. Главный поворот: если несколько циклов читают и пишут в одну общую папку «сигналов», они начинают усиливать друг друга — поддержка кормит разработку, реклама кормит SEO, всё работает на один «мозг».
Читать → РазборПетли (loops) в AI-кодинге: как заставить агента работать на цель без человека
Петля — это связка «триггер + цель», которая позволяет ИИ-агенту работать автономно к результату, убрав человека из цикла. Главный приём: цель должна быть либо проверяемой детерминированно (например, «все страницы грузятся < 50 мс»), либо отданной на суд самой модели («рефактори, пока не будешь доволен»); петли мощные, но пока не годятся для постройки фич с нуля и очень дороги по токенам.
Читать → РазборTraycer Desktop: как заставить Claude Code, Codex и Cursor работать в одной задаче
Traycer Desktop не пытается быть «ещё одним лучшим агентом» — он даёт общий воркспейс, где твои Claude Code, Codex, Cursor и Open Code планируют, реализуют и ревьюят одну задачу, не теряя контекст. Главная идея: вопрос не «какого агента выбрать», а «как заставить уже оплаченных агентов работать вместе».
Читать →