Loop engineering: проєктуємо цикл, який сам ставить задачі AI-агенту
Чому вузьке місце агентних циклів — верифікатор, як складаються чотири вкладені цикли та які обмежувачі й точки перевірки людиною роблять автономного агента для коду безпечним.
Годі згодовувати агенту інструкції по одній. Побудуйте цикл, який робитиме це за вас. Цей зсув у мисленні вже має назву — loop engineering, і він змінює те, на що ви витрачаєте години, працюючи з AI-агентами.
Проблема другої ночі
Уявіть пізній вечір з агентом для коду. Він пише патч. Ви запускаєте тести, і три падають. Ви вставляєте червоний вивід у чат і пишете «виправ». Агент пробує знову, і ви знову вставляєте. На п'ятому колі до вас доходить: кожне ваше повідомлення механічне. Запусти тести. Прочитай помилку. Вкажи на ймовірну причину. Спробуй ще раз. Зупинись, коли все зелене.
Ви — найздібніший компонент цієї системи, а вас використовують як буфер обміну.
Тисячі інженерів уперлися в ту саму стіну приблизно в середині 2026 року, і висновок вийшов прямолінійним: перестаньте писати промпти агенту й спроєктуйте цикл, який писатиме їх за вас.
Від промптів до циклів
Loop engineering — остання сходинка драбини, якою галузь піднімається вже кілька років. Кожна сходинка обгортає попередню, а не замінює її. Спершу налаштовували слова, потім дані, потім оточення. Тепер проєктувати належить сам цикл.
- Prompt engineering (приблизно 2022–2024) питає, які слова використовувати. Його межа очевидна: жодне формулювання не дасть моделі факт, якого вона не отримала.
- Context engineering (2025) питає, які дані модель бачить у момент інференсу.
- Harness engineering (початок 2026) питає, що оточує модель: інструменти, пісочниця, валідатори.
- Loop engineering (2026) питає, який цикл має працювати і коли він закінчується.
Разом із цим змінюється й ваша роль. Ви починаєте оператором, що набирає промпти, стаєте менеджером, який наглядає за кількома агентами паралельно, і зрештою перетворюєтеся на проєктувальника систем. На цьому етапі ви формулюєте, що означає «добре» і «готово», а потім дозволяєте машині досягати цих цілей.
Робоче визначення таке. Loop engineering — це свідоме проєктування циклу, в якому працює агент, зокрема його тригера, мети, перевірок, пам'яті та правил зупинки, замість того щоб вручну писати кожну наступну інструкцію.
Будь-який агент уже працює в циклі
Каверза в тому, що агентів без циклу не буває. Майже в усіх він є, і мало хто формує його навмисно. Саме цей розрив відділяє агента, який спокійно доводить роботу до кінця, від того, який за ніч спалює бюджет, будучи певним, що просувається.
В основі лежить патерн ReAct із 2022 року: подумати, діяти через виклик інструмента, подивитися на результат, повторювати до готовності. Нічого нового. Змінилося у 2026 році те, що цей цикл почали вважати головним об'єктом інженерії й ставитися до нього так само ретельно, як до API. Коли агенти для коду різняться якістю, причина рідко в базовій моделі. Зазвичай — в устрої циклу.
Вузьке місце — верифікатор
Якщо запам'ятати одну думку, хай буде ця. У будь-якому циклі результат обмежує верифікатор, а не модель.
Цикл — це просто генератор, під'єднаний до верифікатора. Генератор, тобто модель, дешевий і ніколи не втомлюється, тож тисяча спроб майже нічого не коштує. А от верифікатор вирішує, чи перетвориться вся ця активність на щось корисне, чи на купу сміття.
Цикли взагалі окупаються завдяки асиметрії, яку іноді називають законом верифікатора: у багатьох задачах перевірити відповідь набагато простіше, ніж її отримати. Ось і вся економіка. Згенерував, перевірив, згенерував наново — і все одно в плюсі, бо перевірка коштує так мало.
Верифікатори бувають двох видів, і вибір між ними — більша частина майстерності:
- Детерміновані перевірки запускають тести, валідують схему або звіряють оцінку. Вони дешеві, надійні, і їх важко ошукати, тож віддавайте їм перевагу всюди, де можливо.
- Схеми LLM-as-judge доручають другій моделі оцінити результат за рубрикою. Вони підходять для розмитих цілей, але їх можна обіграти, а викривлення, пов'язані з позицією, багатослівністю та перевагою власних відповідей, добре задокументовані.
Ризик легко проґавити. Слабкий верифікатор не падає з гуркотом. Він упевнено видає сміття, сотні разів поспіль. Тому написання верифікатора й стало новим prompt engineering.
Складайте цикли довкола циклів
Ремеслом це робить вкладеність. Уявіть чотири концентричні цикли, кожен зі своїм, дедалі повільнішим годинником. Внутрішній виконує роботу, а кожне зовнішнє кільце робить систему надійнішою, автономнішою і зрештою здатною вдосконалювати саму себе.
- Агентний цикл. Модель викликає інструменти, доки задачу не розв'язано.
- Цикл верифікації. Оцінювач порівнює результат із рубрикою й повертає його із зауваженнями, якщо той не дотягує.
- Подієвий цикл. Запуски стартують за вебхуками, cron-задачами чи вхідними повідомленнями, тож агент працює, поки ви спите, а людина може схвалити результат до того, як щось піде в реліз.
- Цикл hill climbing. Окремий агент-аналітик читає продакшен-трейси й переписує сам harness: промпти, інструменти та рубрику. Система вдосконалює систему.
Зазвичай радять рухатися назовні, до третього й четвертого циклів, де виграш накопичується. Це розумно, з одним застереженням. Четвертий цикл довкола слабкого верифікатора просто автоматизує впевнене сміття в промислових масштабах. Тож нарощуйте зовнішні шари заради охоплення, але лише тоді, коли найвнутрішніший верифікатор надійний.
Пишіть контракт, а не промпт
Ось як цей зсув виглядає на практиці. Ви перестаєте писати інструкції й натомість пишете визначення «готово» — функцію винагороди плюс правило зупинки — і дозволяєте циклу до нього прагнути:
Goal: get the test suite passing.
Done when: all tests green - and no test was skipped or deleted to fake it.
Loop: run tests -> read failures -> fix the likely cause -> run again.
Stop when: done, or after 6 rounds (then summarize what's left).
Модель не отримала жодної інструкції — це і є loop engineering у найменшому вигляді.
Обмежте цикл, інакше він обмежить ваш бюджет
Цикл множить ваші зусилля, і це працює в обидва боки. Дайте кожному циклу три виходи: успіх, коли верифікатор проходить; капітуляція, коли вичерпано ліміт чи бюджет; передача, коли справу ескалюють людині. Головне правило: завершення циклу має гарантувати harness, а не агент.
Кожен типовий збій має свій обмежувач:
- Нескінченне кружляння лікується жорстким лімітом ітерацій і виявленням прогонів без прогресу.
- Неконтрольовані витрати лікуються перевіркою бюджету перед кожним викликом і дешевим сортуванням перед дорогою роботою.
- Вигадане «готово» лікується окремим детермінованим верифікатором. Ніколи не дозволяйте агенту оцінювати власну роботу.
- Злам винагороди лікується посиленими критеріями й обов'язковим схваленням людини для чутливих дій.
Перш ніж запускати цикл без нагляду, перевірте верифікатор на завідомо добрих і завідомо поганих прикладах. Переконайтеся, що він відкидає поганий результат, а не лише приймає добрий. Неперевірений верифікатор — це лише думка.
Тримайте руки на кермі
Автоматизація не означає вихід із процесу. Ставте контрольну точку для людини там, де це важливо: схвалення ризикованих викликів інструментів, оцінка критичних результатів, погодження перед тим, як зміна harness піде в роботу. Є й тихіша ціна. Коли цикл випускає виправлення, ви випускаєте те, чого, можливо, до кінця не розумієте. Цей розрив назвали боргом розуміння, і він цілком може стати наступною формою технічного боргу.
Уся етика вміщується в одне речення: будуйте цикл, але будуйте його як людина, яка збирається лишатися інженером, а не просто тим, хто натискає «старт».
І знову друга ночі
Знову друга ночі, і цього разу ви спите. Кілька годин тому спрацював вебхук. До ранку на вас чекає чорновий pull request. Цикл зупинився перед мержем, бо це рішення йому не дозволено ухвалювати самотужки, і залишив охайний опис того, що змінилося й чому.
Ви більше не буфер обміну. Ви той, хто спроєктував механізм, і кожна його деталь походить від вашого рішення: мета, верифікатор, ліміти й місця, де він мусить зупинитися й спитати.
Це і є loop engineering. Побудуйте свій цикл — і побудуйте його так, щоб лишитися інженером.