0: Если почитать комментарии под видео, многие уже научились эффективно промить ллм, использовать агентов скиллс и msp в разработке, но, оказывается, в 2026 году этого уже недостаточно. История, когда мы вручную написали пром.
1: Дождались ответа, проанализировали результаты, написали следующий промт плохо масштабируется в такой парадигме. Разработчик все чаще превращается из инженера в оператора ллм. Он не проектирует систему, а ведёт агента за руку, если ты взаим
2: Взаимодействуешь с агентом больше, чем пишешь код или принимаешь инженерные решения самостоятельно. Значит, скорее всего, ты уже упёрся в потолок. Возможностей текущего способа работы. Нужны новые подходы, и 1 из таких подходов это loop инженеринг. Это не просто улучше.
3: Prompt, или контекст инжениринг, как может показаться из названия, это паттерн проектирования агентских воркфлоу мы создаём не 1 промт, а цикл, который сам запускает агента, передаёт ему задачи, проверяет результат, сохраняет состояние и решает, что делать дальше всем при
4: Привет. В этом видео я расскажу про саму концепцию луп инженеринг. Разберу, из каких компонентов она состоит. Обсудим риски применения и посмотрим, как внедрить эту парадигму постепенно и без лишнего риска. Название loop инженеринг в 2026 году начал исполь.
5: Эдди Османи, инженерный лидер, много лет работавший в google и google cloud иай он написал пост о том, что работа программистов, которые используют кодинг агентов, все больше смещается от простого промти к проектированию циклов, которые будут автоматически промтите.
6: Модель. При этом сама идея проектировать цикл, который промти агентов появилась не на пустом месте. Похожую мысль высказывал Борис чёрный из антропка руководитель клод код. Он говорил, что больше не пишет промты напрямую, а проектирует циклы вокруг модели. Давайте
7: Разбираться из чего состоит луп инженеринг для простоты понимания выделим внутренний и внешний циклы. Внутренний цикл это то, что агент делает по умолчанию, собирает контекст, анализирует его, выполняет действия, получает обратную связь, исправляет ошибки.
8: Продолжает работу, но чтобы автоматизировать запуск и управление этим внутренним циклом, нужен внешний цикл его как раз проектирует разработчик. Во внешнем цикле появляются триггеры расписание, изоляция работы агента, декомпозиция задач управ.
9: Множеством операций критерии успешного выполнения лимиты проверки и условия завершения цикла.
10: Именно это и отличает луп инженеринг от обычного промти га мы проектируем не отдельный запрос к модели, а систему, которая управляет тем, как, когда и зачем модель получает задачи. При этом луп инженеринг не отменяет промты. Контекст инженеринг нам все равно нуж.
11: Нужно следить за качеством промта и контекста плохой промт внутри цикла будет тиражировать ошибки плохой контекст будет нестабильно влиять на архитектуру проекта и приводить агента к неправильным решениям, поэтому качество промта и контекст остаётся обязательным.
12: У луп инженеринг есть родственные практики, 1 из них, так называемый ральф виггам луп или техника ральфа. Это простой паттерн автономной работы агента, когда он выполняет небольшую атомарную задачу, фиксирует изменения, сохраняет состояние и завершает
13: Операцию. Следующая итерация начинается как новая сессия с чистым контекстом. Вы наверняка замечали, что продолжительность сессии часто деградирует, контекстное окно переполняется, появляются нерабочие версии файлов, ошибочные рассуждения, устаревшие.
14: Промежуточное решение. Все это засоряет контекст и снижает качество результата в ральф подходе. Состояние хранится не только внутри модели, но и снаружи. Например, у нас могут быть план точка Эмди и статус точка Эмди из план точка Эмди. Агент берет новые задачи
15: Статус мди записывает то, что уже сделал, где возникли ошибки и что нужно проверить дальше. Конкретные названия файлов могут быть любыми. Важно не это важно, что память процесса живёт вне контекстного окна модели и не теряется между итерациями. Теперь перейдём
16: Компонентом луп инженеринг в популярной формулировке Эдис мани у луп инженеринг есть 5 основных компонентов, а также память 1 компонент автомейшен или автоматизация это процесс, который запускает цикл по расписанию.
17: Или событию делает первичный разбор задачи, решает, есть ли работа, которую нужно передать агенту 2 компонент гид ворк tris это изолированные рабочие деревья, гид, они нужны, чтобы параллельные агенты не писали в 1 и ту же рабочую директорию и не Ломали незавершённую работу.
18: Друг друга важно уточнить ворк трисс не отменяют конфликты слияния в гид полностью, если 2 агента изменят одни и те же строки, конфликт может появиться позже при интеграции изменений, но work трисс помогают избежать хаоса во время самой работы.
19: Каждый агент получает отдельную директорию, свой хэд, свой индекс и в зависимости от настройки отдельную ветку. 3 компонент это скилл, который вытащит баги из Логов, проверит открытые тикеты в таск, трекере, пополнит файл туду точка Эмди для дальнейшей обработки агентами четвер.
20: 4 компонент плагины и коннекторы. Они связывают агентов с реальными инструментами сиайсиди, таск, трекерами, базами данных, системами аллертинга и мониторинга слаг гитхаб жира и другими сервисами. Часто такая интеграция делается через эмсипи 5 компонент.
21: Субагенты нужны для разделения ролей например, 1 агент пишет код, а другой независимо проверяет его это pattern maker чекер мейкер делает чекер, проверяет и 6 элемент, который часто выделяют отдельно память это внешний.
22: Источник правды о всем процессе это может быть mark down, файл в репозитории, тикет в жире, запись в базе данных или другая система хранения состояния смысл в том, что память живёт вне контекстного окна и сохраняется между сессиями, если сама
23: Идея проектировать автономные циклы вокруг агентов кажется вам полезной. Поставьте лайк этому видео для YouTube это сигнал, что такие инженерные разборы стоит показывать большему числу разработчиков теперь посмотрим, как это может выглядеть на практике, например в ко.
24: Клод код в кодекс эта история может настраиваться через автомейшен, там можно выбрать проект промт, который будет запускаться автоматически расписание выполнения и среду выполнения, локальную папку или git ворк 3 для гит репозиториев авто.
25: Смогут запускаться в отдельном бэкграунд ворк 3, чтобы не конфликтовать с текущей локальной работой. Клод код есть команда луп. Это регулярный запуск промта по расписанию. Фактически крон лайк механизм внутри сессии. Его можно использовать, например,
26: Чтобы периодически проверять статус деплоя континиус, интегрейшн, пулл, реквест или другой продолжительный процесс, также в клод код есть хукс и github actions, с их помощью можно встроить агента в жизненный цикл разработки, запускать провер.
27: Форматировать файлы, реагировать на события, выполнять автоматизацию в github workflow и переносить часть процесса на удалённую инфраструктуру. Отдельно стоит упомянуть команду гол. Она задаёт условия завершения. Агент продолжает работать до тех пор, пока это
28: Условие не будет выполнено в клод код команда гол после каждого шага использует отдельную быструю модель, которая оценивает, достигнуты ли условия, но эта модель не запускает тесты сама и не читает файлы независимо она судит по тому, что основной агент уже сделал.
29: И показал в контексте. Поэтому тесты, линтеры, сборка и другие проверки должны быть явно встроены в основной цикл или хуки. По сути, у нас получается несколько уровней автономности. 1 уровень, выполнение задач по расписанию, например, мониторинг багов, проверка сиай.
30: Или сортировка входящих задач, 2 уровень, выполнение целей по итерациям. Агент продолжает работать, пока не достигнет заданного результата. 3 уровень независимая проверка критериев готовности, отдельный чекер модель или автоматическая проверка по правилам.
31: Определяет, можно ли считать задачу выполненной здесь критически важны чёткие критерии успешности. Не должно быть абстрактных формулировок вроде сделай хорошо, улучши качество или доведи до идеала. Такие условия могут привести либо к преждевременному завершению цикла, либо
32: К бесконечным операциям. Бесконечные итерации это не только потеря времени, но и повышенный расход токенов, лимитов и бюджета, поэтому за этим нужно следить. Давайте поговорим, как составить хороший контракт. Сначала задаём измеримую цель. Например, если мы хо,
33: Хотим покрыть тестами 80% кодовой базы, то на удивление так и пишем. Цель довести тест каверидж до 80%. Дальше задаём критерии, которые машина сможет проверить. Если речь идёт о тестах, указываем конкретную команду и ожидаемый результат.
34: Например, npm тест завершается с exit код зироу npm run lindt проходит без ошибок, каверич репорт показывает не меньше 80%, также в контракте нужно задать границы, что нельзя трогать, запускать или редактировать, например, не использовать.
35: Интернет, не вызывать публичный пиай, не редактировать конкретные файлы, а также не менять схему базы данных, не трогать продакшн конфиги. Дальше задаём лимит по итерациям времени или бюджету. Например, задача должна выполняться не больше 25 итераций или
36: Не дольше 2 часов. Если условие не достигнуто, агент должен остановиться и передать задачу человеку в цикл нужно встроить логирование и проверки, а также определить стоп факторы, условия, при которых цикл должен завершиться. Например, если после изменений
37: Начинают падать интеграционные тесты. Это может быть стоп фактором для остановки агента и передачи задачи разработчику. Все, кто работал с агентами эллэ. Неважно, это недорогие опенсорс модели или топовые коммерческие модели вроде клод опус gpt 5 или
38: Замечали 1 вещь. Агент часто склонен считать результат своей работы корректным. Иногда приходится спорить с агентом и доказывать, что решение не идеальное. Более того, агент может сгенерировать в принципе нерабочее решение. Например, агент написал код. Вы пытаетесь его запустить.
39: Сервис падает с ошибками именно здесь нужен валидатор простыми словами мы назначаем отдельную модель отдельного агента или test script для автоматизированной проверки результата работы или test script для автоматизированной проверки результата работы это
40: Есть история про pattern maker чекер теперь поговорим подробнее про гит ворк 3 гитво 3 это способ вести параллельную работу в 1 репозитории через отдельные рабочие директории у каждого ворк 3 своя копия файлов проекта свой хэд, свой индекс.
41: Отдельное состояние рабочей директории, при этом история репозитория остаётся общей для агентов. Это особенно важно, когда несколько агентов работает, параллельно, появляется конкуренция за одни и те же файлы. Если все они пишут в 1 директорию, можно получить
42: Chaos 1 агент переписывает изменения другого, ломаются промежуточные состояния, непонятно кто что поменял здесь work 3 изолирует работу физически, агенты работают в разных ворк trees и не мешают друг другу на уровне файловой системы ворк 3 не решает.
43: Все конфликты, если 2 агента изменили 1 и ту же часть кода, конфликт может возникнуть позже, когда вы будете объединять изменения. Поэтому ворк 3 это не замена ревью имедж процесса, а способ безопаснее организовать параллельную работу агентов, а также
44: Стоит упомянуть про скиллс и память Османи предлагает определить в skills проектные правила, например, как собирать проект, какие команды запускать для сборки и Тестов, какие архитектурные ограничения соблюдать, какие папки нельзя трогать, какие паттерны считаются допустимыми.
45: Но, на мой взгляд, для этого есть agents точка Эмди в контексте луп инженеринг логичнее добавить в skills инструкции, которые извлекут ошибки из Логов ci, проверят открытые тикеты в таск трекере, пополнят ими файл туду точка Эмди для дальнейшей обработки агентами память.
46: Динамическое состояние, что уже сделано, что не прошло тесты, что находится в очереди, какие гипотезы проверялись, какие решения были отклонены, какие задачи требуют внимания человека? Коннекторы через эмсипи дают агенту доступ к внеш.
47: Системам, алертингу, мессенджерам, вроде slack таск, трекерам, базам данных гитхаб, сиайсиди. Это нужно, чтобы закрывать весь рабочий процесс от тикета до пулреквеста и уведомления. И давайте рассмотрим паттерн мейкер. Чеккер. Это
48: Паттерн, в котором 1 участник создаёт результат, а другой, независимо его проверяет в контексте агентских систем мейкер это агент, который пишет код или предлагает решение. Чеккер это агент, который проверяет результат, запускает тесты, смотрит дифф, сверяет изменения с архитек.
49: Культурными правилами и критериями задачи. Почему нельзя просто доверить проверку тому же агенту? Потому что модель, которая только что написала решение, часто слишком лояльна к собственному результату. Она может не заметить логическую ошибку, пропустить нарушение архитектуры или
50: Убедить себя, что задача выполнена. Хотя на самом деле это не так. Отдельный чекер снижает этот риск, не устраняет полностью, но снижает. В практической реализации субагентов можно настраивать через конфигурационные файлы. Там создаётся имя агента, его роль
51: Специализация, модель, уровень, ризонинг и инструкции, например, более мощные модели можно ставить на аудит архитектуру и верификацию, более быстрые и дешёвые модели на исследование кодовой базы, сбор контекста или подготовку.
52: Простых изменений. Давайте обсудим, как может выглядеть весь процесс. Например, по триггеру или расписанию срабатывает планировщик. Он запускает скил, разбор задач, собирает информацию сиайсиди, Логов, тикетов или алертов.
53: И записывает состояние файл со списком задач. Например, туду точка Эмди. Для каждой задачи создаётся изолированный гит ворк 3. В нём запускается исполнитель субагент мейкер. Он анализирует задачу, вносит изменения, запускает проверки.
54: Фиксирует результат. После этого субагент чекер проверяет дифф, прогоняет тесты, сверяет изменения с конвенциями проекта и критериями успешности. Если все в порядке, агент через эмсипи может создать пуллреквест и обновить статус задачи в трекере. Если
55: Есть сомнения. Задача уходит в статус, который требует проверки разработчиком. Например, в жира можно настроить отдельный статус. Вроде необходимо ревью кожаного или внимание нейросла. Сконфигурировать чекер агента. Условия должны быть максимально конкрет.
56: Тесты прошли успешно, проект запускается без критических ошибок линтер и type checker проходят структура папок не нарушена, архитектурные ограничения соблюдены, запрещённые файлы не изменены, критерии задачи выполнены, дифф.
57: Не содержит подозрительных изменений вне скоупа задачи. Если все соблюдено, изменения можно передать на ревью или автоматический мерж в зависимости от уровня зрелости процесса. Если нет, результат работы агента отклоняется, а задача переводится на разра.
58: Ботчика для контрольной проверки. Плюс у нас есть файл состояния, например, статус точка Эмди, куда записывается информация по итерациям, что запускалось, что прошло, что упало, какие решения были приняты и что нужно сделать дальше. Теперь поговорим о
59: Матрица зрелости, то есть о том, как внедрить луп инженеринг. Постепенно. Это не официальный стандарт, а удобная практическая модель. На 1 уровне мы все делаем руками промти агента, проверяем результат вручную, если нужно снова промти, чтобы
60: Он внёс изменения или исправил баги. На 2 уровне. Система сама разбирает задачи из жир, гитхаб, июс или другого трекера и формирует туду точка Эмди код. При этом все ещё пишет разработчик. Агент код не трогает. На 3 уровне агент
61: Уже занимается правками в выделенном гит ворк 3. Программист проверяет дифф, запускает тесты и вручную мержит изменения. На 4 уровне появляется чекер, отдельный агент, модель или набор автоматических проверок по правилам, которые валидируют пулл реквест.
62: Разработчик в этом случае делает финальное одобрение если все выглядит нормально на 5 уровне, система сама мержит изменения после успешного прохождения Тестов, линтеров и других проверок разработчик контролирует процесс по логам, алертам и периодическим
63: Code review не погружаясь в каждое изменение, казалось бы, хорошо бы сразу перейти на самый верхний уровень мы написали задачи, задали критерии успешности, настроили цикл, и система сама все делает, но переходить сразу на этот уровень опасно.
64: У луп инженеринг есть несколько рисков, которые особенно заметны именно при росте автономности. 1 риск это повышенный расход токенов и бюджета. Если цикл плохо ограничен, агент может гонять операции впустую, повторять одни и те же действия, запускать слишком.
65: Дорогие модели и тратить лимиты без реального прогресса. 2 риск тесты и ложное чувство безопасности тесты это хорошо, но они не дают стопроцентного доказательства, что весь код корректен. Архитектура соблюдена, а приложение работает именно так, как задумано.
66: Более того, есть риск, что агент будет писать тесты так, чтобы они подтверждали его собственное решение, а не реальные требования. Это риск подгонки. Решения под формальные критерии. Тесты проходят, метрика достигнута, но реальная задача может быть решена неправильно, поэтому
67: Тесты должны быть частью проверки, но не единственным источником истины. Все равно финальный чеккер это разработчик, особенно если речь идёт о продакшн коде, можно автоматизировать запуск Тестов, линтеров, тайпчек, привью диплой смок, тестс.
68: Проверки на тестовом стенде, но если вы деплоите код, написанный агентами в продакшн, ответственность все равно остаётся на людях. 3 риск это архитектурная деградация. Агент может локально решить задачу, но нарушить общий дизайн системы, например,
69: Дублировать код, сломать импорты модулей, добавить ненужные зависимости или обойти существующие абстракции. Даже если вы описали корректные конвенции, архитектурные решения, правила, это не значит, что агент будет строго их придерживаться. Чеккер может проверить
70: Что приложение работает, но не факт, что он заметит нарушение архитектуры, плохой дизайн или будущие проблемы сопровождения. 4 риск это эффект бутылочного горлышка. Агенты, особенно если запускать их параллельно, очень быстро генерируют код, но скорость генера
71: Кода не равна скорости принятия инженерных решений, разработчик все равно должен спроектировать архитектуру, решения, разбить работу на атомарные задачи и задать для каждой задачи конкретные измеримые критерии оценки. Если этого не сделать, агенты начнут производить
72: Много изменений, которые вроде бы выглядят полезно, но постепенно увеличивают когнитивный долг. Вы можете потерять связь с проектом, перестать понимать, что именно изменилось. Почему появилась такая структура папок, откуда взялись новые зависимости и зачем были добавлены новые абстракции. Поэтому код
73: Остаётся обязательным нужно смотреть, что агенты пишут, понимать структуру изменений, проверять импорты, границы модулей, архитектурные решения и последствия для проекта. 5 риск. Соблазн отключить критическое мышление. Вы видите, что агент написал код
74: Приложение запускается, тесты прошли, чекер ничего не нашёл, и кажется, что все готово, но это не всегда так. Автоматизация снижает нагрузку, но не отменяет ответственность инженера. Поэтому внедрять луп инженеринг нужно по нарастающей, сначала ручной.
75: Контроль, все результаты работы агента нужно самостоятельно проверять, затем постепенная автоматизация, сначала подготовка задач, потом изолированный ворк триз, потом мейкер чекер, потом частичный автомердж только для безопасных классов задач авто.
76: Нужно давать не сразу, а по мере того, как вы понимаете, где агент стабильно справляется с решением задач, а где ошибается главный вывод такой луп инженеринг нужно внедрять через баланс. Задачи должны быть атомарными, с конкретными измеримыми и проверяемыми.
77: Критериями у цикла должны быть лимиты, логи, условия завершения и понятный механизм передачи задачи человеку промт, контекст, инженеринг никуда не исчезают, они становятся частью более крупной системы хороший промт и хороший контекст. Все
78: Ещё важны, но теперь инженерная задача не просто написать 1 Удачный промт, а спроектировать цикл, который будет безопасно использовать промты, контекст, инструменты, проверки и внешнюю память. Техника Раль флуп показывает ценность Коротких операций с чистым контекстом.
79: Внешним состоянием мейкер чекер доказывает, почему автономной системе нужен независимый слой верификации гитор trees помогает безопаснее организовать параллельную работу агентов agents точка Эмди фиксирует проектные правила.
80: Сохраняет состояние между сессиями эмсипи и коннекторы связывают агента с реальным воркфлоу тикетами сиайсиди, пуллреквестами, алертами и мониторингом. Но финальная ответственность все равно остаётся на разработчике, если вам
81: Вам интересны такие практические разборы ай разработки агентских воркфлоу и новых инженерных подходов? Подписывайтесь на канал. Дальше будем разбирать не только концепции, но и конкретные схемы внедрения, как настраивать агентов, как проектировать циклы, как писать критерии.
82: Успешности и как безопасно давать