Loop Engineering.
Автор оригіналу: Addy Osmani
Переклад: Пеггі, BlockBeats

Редакційна примітка: спосіб використання AI-агентів для кодування змінюється з «людина вручну пише запити та поетапно виконує завдання» на «людина проектує цикли, щоб система автоматично планувала агентів». Суть Loop Engineering (циклічного інжинірингу), про який говорить Addy Osmani, полягає у створенні робочого процесу, який автоматично виявляє завдання, розподіляє їх, перевіряє результати, фіксує прогрес і вирішує наступні кроки.

Цей цикл складається приблизно з п’яти модулів: Automations (автоматичне виявлення та розподіл завдань), Worktrees (ізоляція кількох паралельних середовищ розробки), Skills (зберігання знань про проєкти та командних практик), Plugins/Connectors (підключення до реальних інструментів, таких як GitHub, Linear, Slack, бази даних), Sub-agents (розділення виконавців та рецензентів), а також зовнішній шар пам’яті, наприклад, Markdown-файли або дошки Linear, для збереження стану та прогресу.

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

Нижче наведено оригінал:

Loop engineering (циклічне інженерія) замінює вашу роль як «автора підказок для агентів». Ви повинні розробити систему, яка буде замість вас формулювати підказки для інтелектуального агента. Тут цикл можна розуміти як рекурсивну мету: ви визначаєте мету, а штучний інтелект безперервно ітерує, доки завдання не буде виконано. Вона складається з п’яти компонентів, і Claude Code та Codex вже мають усі ці п’ять компонентів.

Я вірю, що це може бути тим, як ми зможемо співпрацювати з кодовими агентами у майбутньому. Однак все це все ще на початковій стадії, і я залишаюся скептичним. Ви точно повинні обережно ставитися до витрат на токени, оскільки витрати можуть сильно відрізнятися в залежності від моделі використання, особливо якщо ви «багаті на токени» чи «страждаєте від нестачі токенів». Вам також потрібен механізм, що забезпечує збереження якості. Теж обґрунтовано ставитися до занепокоєнь щодо «AI-сміття» (slop). Проте давайте розглянемо, в чому справа.

@steipete недавно сказав: «Ви більше не повинні писати підказки для кодових агентів. Ви повинні розробити цикли, які будуть давати підказки вашим агентам». Подібним чином @bcherny, відповідальний за Claude Code в Anthropic, сказав: «Зараз я більше не підказую Claude. У мене є купа циклів, які підказують Claude і самі вирішують, що робити далі. Моя робота — писати цикли».

Тоді, що це означає?

Протягом останніх приблизно двох років, щоб заставити кодовий агент щось зробити, ви просто писали добрий запит і надавали достатньо контексту. Ви вводили одне речення, читали відповідь, а потім вводили наступне. Агент був інструментом, який ви тримали в руках і поступово продовжували керувати ним. Цей етап, певною мірою, закінчився, принаймні деякі вважають, що він майже закінчився.

Зараз ви створюєте невелику систему: вона сама виявляє роботу, розподіляє завдання, перевіряє результати, фіксує виконання та вирішує, що робити далі. Іншими словами, ви надаєте цій системі можливість керувати агентами, а не самостійно постійно надсилати їм підказки. Раніше я писав про її «ближчого родича» — agent harness engineering (інженерія середовища виконання агентів), тобто створення середовища для одного агента; а також factory model (фабрична модель), тобто систему для побудови програмного забезпечення. Loop engineering розташований на рівні вище, ніж harness. Вона схожа на harness, але працює за таймером, створює невеликих помічників і здатна сама себе підживлювати.

Мене здивувало, що це вже не просто питання «інструментального рівня». Рік тому, якщо ви хотіли створити цикл, вам доводилося писати величезну кількість bash-скриптів і постійно підтримувати цей код. Це було вашою власною річчю, і належало лише вам. Зараз ці компоненти вже безпосередньо вбудовані у продукт. Здатності, перелічені Штейнбергером, майже однозначно відповідають функціям Codex, а також майже так само добре підходять до Claude Code. Коли ви розумієте, що їхня форма однакова, ви більше не будете думати, який інструмент вибрати — замість цього ви будете проектувати цикл: незалежно від того, в якому інструменті ви сидите, він продовжуватиме працювати.

П’ять компонентів, а також деякі пояснення

Для циклу потрібно п’ять речей, плюс місце для зберігання інформації. Спочатку я перелічу їх, а потім поясню кожну.

По-перше, Automations (автоматизовані завдання): запускаються за розкладом, автоматично виявляють та розподіляють.

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

Третє, навички: запишіть знання про проект, щоб агент не мусив постійно вгадувати.

Четверте, Plugins and connectors (плагіни та конектори): дозволяють агентам підключатися до інструментів, які ви вже використовуєте.

П’яте: суб-агенти (підагенти): один відповідає за запропонування рішень, інший — за перевірку рішень.

А шосте — memory (пам’ять). Це може бути Markdown-файл, Linear-дошка або будь-яке інше місце, незалежне від окремої діалогової сесії, де зберігаються «виконані завдання» та «наступні кроки». Звучить просто, наче це не важливо, але це саме той самий підхід, на якому ґрунтуються всі довготривалі агенти. Я детально описував це в контексті long-running agents: модель забуває між кожним запуском, тому пам’ять має зберігатися на диску, а не в контексті. Агент може забути, але сховище коду — ні.

Зараз обидва продукти мають ці п’ять компонентів.

Їх назви відрізняються в деяких місцях, але здатності за суттю однакові. Нижче я детально поясню, бо, чесно кажучи, чи буде цикл стабільно працювати, чи тихо протікатиме в усіх місцях — залежить від деталей.

Автоматизація — це те, що робить loop справжнім loop, а не разовою задачею, яку ви запускали вручну. У додатку Codex ви можете створити автоматизацію на вкладці Automations, вибравши проект, промпт, який має виконуватися, частоту запуску та те, чи вона має працювати у вашому локальному checkout, чи у фоновому worktree. Результати запусків, які виявили проблеми, потрапляють до Triage inbox, а ті, що проблем не виявили, автоматично архівуються — це зручно. OpenAI використовує це всередині для виконання нудних, але необхідних завдань, таких як щоденне розподілення issue, підсумовування причин невдач CI, написання звітів про коміти та відстеження багів, введених тиждень тому. Автоматизації також можуть викликати skill, тому ви можете зберігати повторювані завдання підтримуваними: запускати $skill-name, а не вставляти цілий стовпець інструкцій у планове завдання, яке ніхто більше не оновлюватиме.

Claude Code також може досягти того ж ефекту, але іншим шляхом: він використовує планування та хуки. Ви можете використовувати /loop для виконання запиту або команди з фіксованим інтервалом, налаштовувати cron-завдання або запускати shell-команди за допомогою хуків у певних точках життєвого циклу агента. Якщо ви хочете, щоб це продовжувало працювати після закриття ноутбука, ви можете розмістити всю систему на GitHub Actions. Ідея повністю та сама: ви визначаєте автономне завдання, надаєте йому ритм і дозволяєте результатам приходити до вас, а не самому шукати їх.

Існує ще один примітив у сесії, який ближчий до справжньої суті, що обговорюється в цій статті. /loop виконується з певним ритмом; /goal працює неперервно, доки не виконається певна умова, яку ви вказали. Після кожного циклу окрема мала модель оцінює, чи завдання виконано, тому агент, що пише код, не оцінює себе сам. Ви можете вказати умову, наприклад: «усі тести в test/auth пройдені, і lint чистий», а потім відійти. Codex має таку ж здатність, і вона також називається /goal. Він працює протягом кількох циклів, доки не буде досягнуто перевірної умови зупинки, і підтримує паузу, відновлення та очищення. Цей самий примітив є в обох інструментах. Це базовий шаблон, який постійно зустрічається в цій статті.

Отже, Automations відповідають за виявлення завдань, а решта циклу — за їх виконання.

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

Codex має вбудовану підтримку worktree, тому кілька потоків можуть одночасно працювати з одним і тим самим репозиторієм, не завдаючи один одному конфліктів. Claude Code також може досягти такої ж ізоляції за допомогою git worktree: ви можете відкрити сесію в окремому checkout за допомогою прапора --worktree або встановити isolation: worktree на субагенті, щоб кожен агент отримував новий checkout, який автоматично очищається після завершення. Я писав про людський аспект цього в the orchestration tax: worktrees видаляють механічні конфлікти, але ви все ще є обмеженням. Те, що справді визначає, скільки агентів ви можете запускати одночасно, — це не інструменти, а ваша пропускна здатність до оцінки (review bandwidth).

Skill — це механізм, який дозволяє не пояснювати кожен раз, як рибка золота, той самий контекст проекту під час кожної сесії. Обидва інструменти використовують однаковий формат: папка з файлом SKILL.md, у якому зберігаються інструкції та метадані; крім того, можуть бути додаткові сценарії, посилання та ресурсні файли. Codex запускає skill, коли ви викликаєте його за допомогою $ або /skills, а також автоматично запускає його, коли ваше завдання відповідає опису skill. Саме тому стислий, простий опис часто кращий, ніж розкішний і витончений. Claude Code діє так само — я вже описував цей патерн у agent skills.

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

Є одна важлива різниця: skill — це формат написання, а plugin — це спосіб розповсюдження. Коли ви хочете поділитися skill між кількома репозиторіями коду або об’єднати кілька skill у один пакет, ви упаковуєте їх у plugin. Так само працює Codex, і Claude Code також.

Цикл, що відображає лише файлову систему, є дуже малим циклом. Connectors, побудовані на основі MCP, дозволяють агентам читати ваш трекер інцидентів, запитувати бази даних, викликати staging API або надсилати повідомлення в Slack. Codex і Claude Code підтримують MCP, тому connector, який ви написали для одного з них, зазвичай працюватиме і в іншому. Plugins об’єднують connectors і skills, щоб ваші колеги могли встановити повну конфігурацію за один раз, а не відновлювати її з пам’яті.

Це різниця між «агент повідомляє вам: „ось рішення“» і «цикл сам відкриває PR, пов’язує Linear-тікет і повідомляє в канал після успішного проходження CI». Connectors важливі, бо дозволяють циклу діяти у вашому реальному середовищі, а не просто повідомляти: «якби я міг, я б це зробив».

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

Codex створює субагенти лише за вашим запитом; вони працюють паралельно, а потім об’єднують результати в одну відповідь. Ви можете визначити власні агенти за допомогою файлів TOML у директорії .codex/agents/: кожен агент має назву, опис, інструкції, а також необов’язкові параметри моделі та інтенсивності міркувань. Наприклад, ваш перевірщик безпеки може бути потужною моделлю з високою інтенсивністю міркувань, тоді як ваш дослідник — швидкою, лише для читання, легковагою моделлю. Claude Code також надає подібну функціональність за допомогою субагентів і команд агентів у .claude/agents/, дозволяючи кільком агентам передавати роботу один одному. Найпоширеніше розподілення обов’язків з обох сторін: один агент досліджує, один реалізує, а один перевіряє відповідність специфікаціям.

Я вже двічі висловлював цю думку: один раз у code agent orchestra, і ще раз у adversarial code review. Вона особливо важлива у loop, бо loop працює, коли ви не дивитеся, і саме надійний verifier — єдине обґрунтування для того, щоб ви могли відійти. Subagents справді витрачають більше token, оскільки кожен agent виконує власні виклики моделі та інструментів, тому варто застосовувати їх там, де варто заплатити за другу думку. Саме це на нижчому рівні робить /goal Claude Code: нова модель оцінює, чи завершено loop, а не модель, яка виконала роботу. Іншими словами, вона застосовує розділення «виробника» і «перевіряючого» до самого умови зупинки.

Як виглядає цикл

З’єднайте це все разом, і окремий потік перетвориться на невелику панель керування. Нижче — структура, яку я часто використовую.

Щодня вранці автоматизація запускається в репозиторії коду. Її запит викликає навичку triage, яка читає невдалий CI з вчора, відкриті питання та останні коміти, а потім записує знайдене в Markdown-файл або до дошки Linear. Для кожної проблеми, яка вимагає дії, потік відкриває ізольований worktree, запускає суб-агент, щоб розробити пропозицію з виправлення, а потім — другого суб-агента, щоб перевірити цю пропозицію згідно з навичками проекту та наявними тестами.

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

Зверніть увагу, що ви справді зробили. Ви просто спроектували один раз. Ці кроки не були вами вручну введені по одному. Ось реальна версія цього твердження Штейнбергера. І той самий цикл може працювати як у Codex, так і у Claude Code, оскільки компоненти є однаковими.

Loop все ще нічого за вас не зробить

Loop змінив спосіб роботи, але не видалить вас із роботи. Насправді, зі зростанням потужності loop три проблеми стають гострішими, а не простішими.

Перевірка все ще залежить від тебе. Автоматизований цикл, що працює без нагляду, також може без нагляду робити помилки. Ти розділив verifier sub-agent і мейкер саме для того, щоб фраза «завершено» у циклі мала хоч якийсь зміст. Навіть тоді «завершено» — це лише твердження, а не доведення. У статті «Code review in the age of AI» я постійно повторюю одне й те саме: твоя відповідальність — надавати код, який ти підтвердив як дійсний.

Якщо ти не втручаєшся, твоє власне розуміння все одно розкладатиметься. Чим швидше Loop доставляє тобі код, який ти не писав сам, тим більшою стає різниця між тим, що ти насправді розумієш, і тим, що існує в системі. Це й є comprehension debt (борг розуміння). Якщо ти не читаєш те, що виробляє Loop, гладкий loop лише прискорює зростання цього боргу.

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

Створюйте loop, але все ще залишайтеся інженером

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

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

Результати Loop також відрізняються від людини до людини. Дві особи можуть створити абсолютно однаковий Loop, але отримати зовсім протилежні результати. Один використовує його для прискорення роботи, яку глибоко розуміє; інший — щоб уникати розуміння самої роботи. Loop не розрізняє ці дві ситуації. Ти розумієш.

Ось чому loop design (циклічний дизайн) складніший, ніж prompt engineering (інженерія підказок), а не простіший. Cherny мав на увазі не те, що робота стала легшою, а те, що точка опори змістилася.

Будуйте цикл. Але будуйте його так, як інженер, який ще планує залишатися інженером, а не як людина, яка лише натискає кнопку «Почати».

[Посилання на оригінал]

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

Долучайтесь до офіційного спільноти律动 BlockBeats:

Телеграм-канал з підпискою: https://t.me/theblockbeats

Telegram-чат: https://t.me/BlockBeats_App

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