TL;DR
· У червні 2026 року кілька практиків AI-програмування майже одночасно запропонували Loop Engineering. Stripe вже використовує Minions для щотижневого злиття понад 1300 AI-генерованих PR.
· Цей метод більше не покладається на послідовні підказки людини, а дозволяє системі автоматично виявляти завдання, передавати їх, перевіряти, зберігати стан і переходити до наступного циклу.
· Надійність все ще залежить від незалежних оцінювачів, жорстких шлюзів і ручної перевірки. Борг верифікації та зниження розуміння можуть навпаки посилити ризики.

Нещодавно інженер Anthropic опублікував 11-сторінковий документ про «циклічну інженерію агентних систем», розташувавши Loop Engineering після Prompt Engineering, Context Engineering та Harness Engineering, вважаючи це ключовим методом для наступного етапу AI-програмування.

Цей документ привернув увагу, оскільки він точно потрапив у поворотний момент обговорень AI-програмування в червні 2026 року. Addy Osmani, Boris Cherny та Peter Steinberger майже того ж тижня назвали новий етап AI-програмування Loop Engineering, а конвеєр Stripe Minions уже використовував подібний підхід для щотижневого злиття понад 1300 AI-генерованих Pull Request.

Це число важливе не тому, що AI написав ще кілька рядків коду, а тому, що центр ваги розробки програмного забезпечення зміщується від «людина каже моделі, що писати» до «людина проєктує систему, яка сама ставить у чергу, бере завдання, пише код, перевіряє результати, зберігає стан і продовжує працювати».

За останній рік наратив навколо інструментів AI-програмування зосереджувався на можливостях моделей: точніше доповнення коду, довший контекстний вік, здатність агентів виконувати складніші завдання за один раз. Але Loop Engineering обговорює інше: коли генерація коду стає дедалі дешевшою, інженери мають проєктувати стійкий цикл, що постійно працює. Машина може нескінченно пропонувати варіанти, а людина має вирішувати, яким результатам довіряти, які заблокувати та які довгострокові витрати приховані.

Нещодавно інженер Anthropic опублікував 11-сторінковий документ про «циклічну інженерію агентних систем», розташувавши Loop Engineering після Prompt Engineering, Context Engineering та Harness Engineering, вважаючи це ключовим методом для наступного етапу AI-програмування. Ця стаття використовує цей документ як початкову точку, поєднуючи публічні обговорення Boris Cherny, Addy Osmani та інших, а також приклад Stripe Minions, який щотижня зливає понад 1300 AI-генерованих PR, щоб пояснити, що таке Loop Engineering, чому це раптово обговорюється по всьому інтернету, і що насправді змінюється не написання коду, а верифікація, планування та судження в розробці програмного забезпечення.

AI-програмування: від «однієї підказки» до «постійного циклу»

Loop Engineering розташовано після Prompt Engineering, Context Engineering та Harness Engineering як четвертий рівень стеку AI-інженерії.

Prompt Engineering вирішує «як запитувати»; Context Engineering вирішує «що показувати моделі»; Harness Engineering вирішує «як інтегрувати один запуск моделі з інструментами, тестами та робочими процесами». Loop Engineering робить крок далі: система не просто виконує одне завдання, а може перезапускатися через фіксований час або за тригером, використовуючи попередній результат як вхідні дані для наступного циклу.

Повний цикл зазвичай складається з п'яти дій.

Перший крок — виявлення роботи, наприклад, сканування невдалих CI, відкритих Issue, комітів коду або завдань, що очікують. Другий крок — передача завдання, оформлення завдання в контекст, який може обробити модель. Третій крок — незалежна перевірка: чи дійсно код, створений моделлю, працює, чи проходить тести, чи не викликає побічних ефектів. Четвертий крок — збереження результатів: запис стану, суджень і незавершених справ у файли або систему. П'ятий крок — планування циклу, щоб наступний раунд продовжувався в потрібний час.

Найважливішим тут є не «генерація», а «верифікація». Якщо цикл просто постійно змушує модель писати код, а потім та сама модель хвалить свої результати, він легко перетворюється на «цикл кивання»: кожен раунд здається прогресом, але насправді лише краще пакує помилки.

Власний ранковий триажний цикл Osmani — особистий приклад: система щодня автоматично зчитує невдалі тести CI попереднього дня, відкриті Issue та останні коміти, створює файл стану і поміщає необроблені питання в ручну папку «вхідні». Його цінність не в тому, щоб приймати всі рішення за інженера, а в тому, щоб завершити попередній відбір до того, як інженер прокинеться, залишаючи увагу для частин, які дійсно потребують судження.

1300 PR від Stripe: надійність походить від обмежень, а не від моделі

Конвеєр Stripe Minions — найбільш вражаючий корпоративний приклад у цьому обговоренні: щотижня зливається понад 1300 AI-генерованих Pull Request, і код не написаний людиною рядок за рядком.

Але це не означає, що Stripe віддає виробничу систему на волю великої моделі. Навпаки, ключ до Minions — висококонтрольований процес: детермінований оркестратор спочатку збирає контекст, витягуючи інформацію про завдання з Jira, пошуку коду та внутрішніх інструментів; LLM відповідає за генерацію коду; потім через жорстко закодований linter, шлюзи комітів і остаточну ручну перевірку вирішується, чи можна злити.

Іншими словами, надійність походить не від того, що «модель раптом стала достатньо розумною», а від низки обмежень. Модель пропонує кандидати змін, система обмежує, до чого вона може торкатися і які перевірки повинна пройти, а людина приймає остаточне рішення про входження в основну гілку.

У цьому й полягає різниця між Loop Engineering та звичайними AI-скриптами програмування. Звичайні скрипти зосереджуються на тому, щоб «змусити модель виконати завдання»; циклічні системи повинні враховувати, звідки беруться завдання, як обробляти невдачі, як зберігати стан, як контролювати бюджет і хто запобігає потраплянню помилок у виробниче середовище.

Без цих обмежень щотижневі 1300 PR — це не стрибок ефективності, а потенційний генератор технічного боргу.

Генератор і оцінювач повинні бути розділені

Одне з ключових проєктних рішень у Loop Engineering — розділення генератора та оцінювача.

Генератор відповідає за написання коду, зміну файлів і подачу кандидатів. Оцінювач відповідає за пошук помилок, і бажано, щоб він спочатку припускав, що код має проблеми. Вони не можуть виконуватися одним «оптимістичним агентом», оскільки модель, оцінюючи себе, часто схильна схвалювати власні результати, особливо коли опис завдання нечіткий, тестове покриття недостатнє або контекст неповний.

Незалежний оцінювач може бути простішим, більш підозріливим і легшим для налаштування. Йому не потрібно творчо вирішувати проблеми — лише перевірити, чи завантажується сторінка, чи проходять тести, чи не порушені граничні умови, чи відповідає код встановленим правилам. Деякі практики змушують оцінювача фактично клацати по сторінках через інструменти автоматизації браузера, а не просто читати код і давати висновок.

Це пояснює, чому «верифікація» є найскладнішою частиною п'ятикрокового циклу. Генерація коду стає дешевшою, але довести, що фрагмент коду дійсно правильний, все ще дорого. Особливо у великих кодовій базі помилки можуть не проявитися одразу, а тести не завжди покривають реальні бізнес-шляхи. Чим швидше працює цикл, тим швидше накопичуються неперевірені припущення.

Приховані витрати посилюють одна одну

Ризик Loop Engineering не в тому, що він може написати неправильний код, а в тому, що він може ускладнити команді виявлення власної втрати розуміння.

Перший тип витрат — борг верифікації. Помилки, не покриті тестами, накопичуються в циклі до моменту злиття або випуску, коли вони вибухають скупчено. Другий тип — зниження розуміння. Кодова база постійно зростає, але інженери не брали безпосередньої участі в ключових проєктних рішеннях, їхня ментальна карта залишається на старій версії. Третій тип — когнітивна капітуляція. Люди починають автоматично приймати результати машини, лише формально схвалюючи. Четвертий тип — вибух витрат на токени. Повторні спроби, підагенти, довгі контексти та багаторазові перевірки швидко збільшують рахунок.

Ці чотири види витрат живлять одна одну: недостатні тести призводять до боргу верифікації, борг верифікації змушує інженерів менше заглиблюватися, зниження розуміння перетворює ручну перевірку на гумову печатку, а гумова печатка стимулює більше автоматичних повторів і вищих витрат.

Отже, один і той самий набір циклічних компонентів у різних інженерів може давати абсолютно протилежні результати. Люди з сильним судженням і чіткими межами можуть використовувати цикл для посилення власного розуміння системи, використовуючи машину як невтомний виконавчий шар; люди зі слабким судженням або надмірною залежністю від автоматизації можуть через кілька місяців стати «воротарями» власної системи, лише схвалюючи або відхиляючи, не здатні пояснити, чому система працює так.

Код став дешевим, дорогим стало судження

Loop Engineering виводить довгострокову тенденцію на чіткіше місце: код, плани, PR і декомпозиція завдань стають майже безкоштовними, але «що дійсно правильно» не стало дешевшим.

Для бізнесу це означає, що інвестиції в AI-програмування можуть зміститися від придбання потужніших моделей до проєктування стабільніших процесів: межі завдань, збірка контексту, незалежне оцінювання, збереження стану, бюджетні обмеження, точки ручної перевірки та як зупинити цикл у разі аномалій. Можливості моделі все ще важливі, але вони лише частина системи.

Для інженерів ролі також змінюються. Раніше основною працею було написання коду, тепер все більше праці перетворюється на перевірку кандидатів, створених машиною: чи відповідають вони вимогам, чи не руйнують архітектуру, чи лише здаються правильними, чи переносять складність на майбутніх розробників.

Це не означає, що програмістів уже замінили. Навпаки, Loop Engineering більше схожий на підсилювач судження. Він може дозволити одному інженеру виконати обсяг змін, який раніше потребував невеликої команди, але також може перетворити лінь, сліпу віру та відсутність перевірки на виробничі аварії.

Справжнє розгалуження полягає в тому, чи зберігають люди достатньо сильне судження та право вето. AI може постійно подавати PR, але чи можна їх зливати, чи варто випускати, чи не зруйнують вони систему в довгостроковій перспективі — це все ще залежить від людини.

Натисніть, щоб дізнатися про відкриті вакансії BlockBeats

Ласкаво просимо до офіційної спільноти BlockBeats:

Telegram-підписка: https://t.me/theblockbeats

Telegram-група для спілкування: https://t.me/BlockBeats_App

Офіційний акаунт у Twitter: https://twitter.com/BlockBeatsAsia