«The Coming Loop»: чому зовнішні цикли змінюють розробку програм

Розробник програмного забезпечення Армін Ронахер опублікував 23 червня есей під назвою «The Coming Loop», у якому стверджує, що найважливіша зміна в розробці з підтримкою ШІ — це не сам кодовий агент, а зовнішній шар автоматизації, побудований навколо нього.

Текст відкривається цитатою, приписуваною Борису Черни: «Я більше не пишу промпти для Claude. У мене працюють цикли, які пишуть промпти для Claude і вирішують, що робити. Моя робота — писати цикли».

Два цикли, а не один

Ронахер розрізняє цикл агента всередині кожного інструменту — модель викликає інструмент, читає результат, редагує файл, запускає тести — і цикл рівня обгортки (harness), який його оточує. У другому випадку завдання потрапляє в чергу, машина бере його, намагається виконати, а потім обгортка вирішує, чи справді роботу завершено. Якщо ні — сесія продовжується додатковим повідомленням, стартує нова сесія зі зміненим контекстом, або завдання передається іншій машині.

Зовнішній цикл не новий, зазначає автор, але за останні тижні він перемістився з периферії агентної інженерії в центр обговорення.

Де працює, а де ні

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

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

Програмне забезпечення як організм

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

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