Липень 2026 року галузь AI-програмування зазнала значних змін. Пітер Штейнбергер оголосив у X про кінець ери циклічного інжинірингу, спрямувавши галузь до інжинірингу графів. Циклічний інжиніринг походить від методу Ralph Джеффрі Хантлі, який обходив обмеження вікна контексту шляхом безперервного запуску AI-агентів до досягнення мети. У квітні–травні 2026 року інструменти, такі як Codex і Claude Code, впровадили функцію Goal, що зробило циклічний підхід комерційно доступним. Зараз галузь досліджує більш складні форми інжинірингу графів, що включають спільне проектування організаційних та робочих графів.

Автор статті, джерело:官方微信公众号 InfoQ (ID: infoqchina)

Ми ще обговорюємо цикл, чи вже перейшли до графіка?

18 липня 2026 року Петер Штайнбергер у X опублікував цей твіт, тихо оголосивши про кінець ери циклічного інжинірингу. Цей пост отримав 2,6 мільйона переглядів протягом двох днів після публікації.

Шість тижнів тому він отримав 8,4 мільйона переглядів за «дизайн циклів, що підказують агентам», змусивши розробників по всьому світу усвідомити, що ера промпт-інженерії йде на спад, і новим напрямком є цикл-інженерія.

Два пости, загальна кількість переглядів яких перевищила 11 мільйонів, вивели найпопулярніші обговорення в галузі AI-програмування на новий рівень.

Підйом циклу

За останній місяць «Loop Engineering» швидко став популярним поняттям у сфері AI-програмування.

Але справжній початок сягає року назад. У липні 2025 року інженер-програміст Джеффрі Хантлі запропонував метод, який він назвав «Ralph» — простий Bash-цикл, який дозволяє Claude повторювати завдання, поки не буде досягнуто мети:

поки :; do cat PROMPT.md | claude-code ; done

Суть методу Ральфа полягає в обході обмежень вікна контексту. На той час, у середині 2025 року, максимальний розмір вікна контексту становив 200 000 токенів, чого було недостатньо для більш складних завдань, тому необхідно було розбити виконання агента на менші одиниці та запускати їх по черзі.

На цьому тлі метод Ральфа працює так:

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

Хантлі використав цей метод, щоб побудувати мову програмування з нуля і підтвердив її придатність. Але вона поширилася серед розробників лише після появи потужніших моделей.

Розквіт Loop також не міг би відбутися без ключових розробників Anthropic і OpenAI. Спочатку на розробницькій конференції Anthropic створець Claude Code Борис Черні сказав: «Зараз я вже не надаю підказок Claude. Я запускаю цикли, які самі надають підказки Claude і вирішують, що робити далі. Моя робота — писати цикли».

Після цього Пітер Штайнбергер також опублікував пост, закликавши розробників припинити прямі підказки для програмних агентів: «Щомісячні нагадування: ви більше не повинні самостійно підказувати програмним агентам. Ви повинні створювати цикли, які самі підказують агентам».

Більш того, колишній інженер Google Addy Osmani написав статтю під назвою «Loop Engineering», у якій описав це як: «Циклічне інженерія — це вийти з позиції особистого надання підказок агенту та замість цього створити систему, яка зробить це за вас».

Концепція з’явилася, назва вибрана, і інфраструктура швидко відповідає.

У квітні–травні 2026 року Codex, Claude Code та Hermes послідовно запровадили команду /goal, щоб перетворити ручно написані цикли на одну команду.

Приблизно через шість місяців після початку широкого застосування Ральфом, Codex випустив функцію goal

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

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

У звичайних запитах Codex обробляє поточну інструкцію, повідомляє результат, а потім очікує на наступний крок. При використанні Goal на потоці прикріплюється постійна мета. Після завершення одного циклу виконання він може перевірити поточні дані та визначити, чи досягнуто мети. Якщо відповідь негативна, а Goal залишається активним і бюджет не вичерпано, Codex може продовжити роботу з останнього стану.

Наприклад: «Знизити p95 затримку в тесті оплати до нижче 120 мс, забезпечуючи при цьому проходження всіх тестів на коректність.»

Це достатньо чіткий «критерій завершення», який можна безпосередньо передати агенту. Після цього агент самостійно розбije завдання, створить підагентів і продовжуватиме роботу, доки завдання не буде виконано. Команда Codex запозичила ідеї циклу Ральфа та на їх основі створила інфраструктуру: координацію кількох агентів, щоб уникнути їх взаємного втручання; управління станом; запуск тестів; запуск та зупинку агентів; пізніше додано такі функції, як встановлення бюджету.

Архітектура функції Goals

Як розробники використовують цикли

А що саме розробники фактично роблять за допомогою циклів? Згідно з відгуками спільноти, найпоширенішим сценарієм залишається обробка періодичних завдань.

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

Наприклад, завершення масштабного міграції коду. Засновник стартапу Рафель Мендіола мав перетворити React-додаток на React Native. Традиційний підхід передбачав створення великої Epic, а потім розбиття на 50–100 тасків — сама інфраструктура викликала страх.

Його альтернативою було створити Skill, який дозволить Agent самостійно визначати переносні блоки коду, виконувати перетворення та відстежувати прогрес, а потім додати цей Skill у Cron-завдання, яке запускається кожні 30 хвилин. У порівнянні з управлінням величезним планом міграції, цей підхід набагато легший когнітивно.

Наступна зупинка: Graph

Проблема з твітом Пітера насправді вказує на шлях розвитку.

Рік тому інжиніринг підказок був ключовою навичкою. До 2025–2026 років акцент змістився на проектування циклів. А зараз Петер вказує на ще більш віддалену мету: проектування графів, що складаються з кількох циклів — кожен агент виконує свій цикл і з’єднаний з іншими через залежності.

Найкращий коментар у дискусії до цього твіту від Luis Catacora: «Цикл має великий запас міцності. Діаграма змусить вас признати, скільки частин робочого процесу взагалі не було правильно смодельовано».

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

Шубхам Сабу, старший продукт-менеджер з штучного інтелекту в Google та автор кодового репозиторію Awesome LLM Apps (з понад 124 000 зірками на GitHub), надав інший розбір, в якому він розрізняє два рівні: «організаційна діаграма визначає, хто відповідає за яку область та зберігає контекст; діаграма робіт визначає, що потрібно зробити зараз, і може бути розбита, об’єднана, переставлена або повністю зникнути на основі доказів».

Що це за Graph?

Loop робить поведінку агента програмованою. Graph робить організацію агента програмованою.

Наступний крок — динамічна організація агентів: під час виконання завдання Graph самостійно змінює свою структуру.

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

Шубхам Сабу: Довгострокова «організаційна діаграма» визначає, хто відповідає за кожен регіон і несе відповідальність за збереження контексту. «Діаграма робіт» визначає, які завдання потрібно виконати зараз. Зі з’явленням нових даних вона може розбитися, об’єднатися, змінити порядок або зовсім зникнути.

Це ключ до виробничої багатоагентної системи: насправді одночасно працюють дві схеми.

Організаційна діаграма (Org Graph): визначає, хто відповідає за що. Вона складається з довготривалих агентів, кожен з яких відповідає за фіксовану область, зберігаючи контекст, професійні компетенції та права доступу до інструментів цієї області. Організаційна діаграма відносно стабільна, подібна до організаційної структури компанії.

Робочий граф (Work Graph): визначає «що потрібно робити зараз і як передаються завдання». Він постійно змінюється разом із завданнями та новими даними, їх можна розбивати, об’єднувати, змінювати порядок або скасовувати безпосередньо. Робочий граф схожий на проектний план, що генерується в реальному часі.

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

Якщо цикл робить поведінку агента програмованою, то граф робить організацію агента програмованою. Наступним кроком є динамічна організація агентів — під час виконання завдання граф самостійно переписує свою структуру.

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