Інженер Google навчає вас, що таке Loop Engineering? П’ять блоків + зовнішня пам’ять, обов’язковий курс з ШІ на 2026 рік

Loop Engineering — це система, яка сама виконує роль промпт-агента, замінюючи вас у цій ролі, і зроблена вона з п’яти блоків: Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents, а також зовнішньою пам’яттю. Стаття походить від інженера Google Адді Османі.
(Передісторія: Anthropic у Claude Fable 5 додали функцію дистиляційного детектування, щоб блокувати китайські open-source моделі?)
(Додатковий контекст: Anthropic: США — лідер у AI-моделях, щоб захистити демократію, пропонують кримінальну відповідальність за дистиляційні атаки)

Зміст статті

Перемикач

• П’ять блоків, з кількома зауваженнями
• Automations: серце циклу
• Worktrees: не дозволяйте паралелізму ставати хаосом
• Skills: нарешті не потрібно кожного разу повторювати свої проєкти
• Plugins і connectors: рука циклу, яка торкається ваших справжніх інструментів
• Sub-agents: розділяємо тих, хто робить, і тих, хто перевіряє
• Як виглядає один цикл
• Що цикл ще не робить для вас
• Побудувати цикл, але залишитись інженером

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

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

Пітер Стайнбергер нещодавно сказав: «Ви більше не повинні промптити свого кодового агента. Ви маєте проектувати цикл, який промптить вашого агента.» Боріс Черні, керівник Claude Code у Anthropic, сказав щось подібне: «Я вже не промптю Claude. Я запускаю цикл, щоб промптити Claude, і цикл сам вирішує, що робити.»

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

Зараз ви створюєте невелику систему: вона шукає роботу, делегує її, перевіряє, що зроблено, і вирішує, що робити далі, — і ця система «тикатиме» агентів замість вас. Раніше я писав про її близького родича — «agent harness engineering», тобто створення середовища для запуску одного агента, тобто фабричну модель для розробки софту.

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

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

П’ять блоків, з кількома зауваженнями

Один цикл потребує п’яти компонентів і однієї пам’яті. Спершу я їх перерахую і співвіднесу.

2. Automations: запуск за розкладом, автоматичне виявлення та сортування.
3. Worktrees: ізоляція паралельних агентів, щоб вони не заважали один одному.
4. Skills: закодувати знання про проєкт, яке раніше можна було здогадатися.
5. Plugins і connectors: під’єднати агентів до вже використовуваних інструментів.
6. Sub-agents: один генерує ідеї, інший перевіряє.

І ще один компонент — пам’ять. Це markdown-файл або Linear-дошка, або будь-який запис, що зберігається поза межами одного запуску і фіксує «що зроблено, що далі». Здається, це дурниця, але саме вона потрібна для довготривалих агентів: модель забуває все між запусками, тому пам’ять має зберігатися на диску, а не у контексті. Агент забуває, репозиторій — ні.

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

| Назва | | --- | Роль у циклі | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Розклад і сортування виявлень | Автоматизація: вибір проєкту, промпт, частота, середовище; результати — у Triage; /goal — для run-until-done | Задачі за розкладом, cron, /loop, /goal, hooks, GitHub Actions | | Worktrees | Ізоляція паралельної розробки | Кожен потік має свою worktree | git worktree, --worktree, ізоляція у subagent: worktree | | Skills | Кодування знань про проєкт | Agent Skills (SKILL.md), виклик через $name або неявно | Agent Skills (SKILL.md) | | Plugins / connectors | Під’єднання до інструментів | Connectors (MCP) + плагіни для розповсюдження | MCP сервери з плагінами | | Sub-agents | Генерація і перевірка ідей | В .codex/agents/ — визначення TOML | . claude/agents/ — Task subagents, агентські команди | | State | Відстеження статусу завершення | Markdown або через connector — Linear | Markdown (AGENTS.md, прогрес) або через MCP — Linear |

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

Automations: серце циклу

Automations — це те, що робить «цикл» справжнім циклом, а не просто «ти один раз його запустив». У Codex app ви створюєте автоматизацію у відповідній вкладці, обираєте проєкт, промпт, частоту, середовище — локально або у background worktree. Виявлення потрапляє у Triage, якщо нічого не знайдено — автоматично архівується.

OpenAI використовує це для рутини: щоденне сортування issues, підсумки CI, brief-інформація про коміти, пошук багів, внесених минулого тижня. Automation може викликати skill, тому циклічні задачі можна підтримувати: просто триггерите $skill-name, а не вставляєте купу команд у застарілий розклад.

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

Ще один важливий термін — /loop. Це повторний запуск за ритмом. /goal — запуск до тих пір, поки не виконається умова, яку ви задали. Кожен цикл завершується, і ще один невеликий модель визначає, чи завершено. Тобто «писати код» — не означає «оцінювати».

Наприклад, поставити умову «усі тести в /test/auth проходять, lint чистий» — і цикл зупиниться, коли вона виконається. У Codex є те саме — /goal, що запускає цикл до виконання умови, можна поставити паузу, відновити або очистити. Це одна й та сама команда, але для різних інструментів — і це основний патерн статті.

Отже, це «виявлення роботи». Решта — «робити щось із цим».

Worktrees: не дозволяйте паралелізму ставати хаосом

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

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

Skills: нарешті не потрібно повторювати свої проєкти

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

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

Ще важливо розмежувати: skill — це формат запису, а plugin — спосіб поширення. Якщо потрібно ділитися skill між репозиторіями або пакувати кілька skill у набір, створюєте plugin. Так працює Codex і так працює Claude Code.

Plugins і connectors: рука циклу, яка торкається ваших справжніх інструментів

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

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

Sub-agents: розділяємо тих, хто робить, і тих, хто перевіряє

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

Codex створює subagent лише за запитом, паралельно виконує їх і повертає один результат. У .codex/agents/ визначаєте своїх агентів у TOML, кожен з яких має name, description, instructions, опційно model і reasoning effort — ваші «сейфи» для безпеки, або швидкі агенти для швидких перевірок. Claude Code використовує .claude/agents/ для тих самих цілей: передає роботу між агентами, наприклад, один — дослідник, інший — виконавець, третій — перевіряє відповідність.

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

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

Об’єднуючи все, один потік стає маленькою панеллю управління. Зазвичай я уявляю його так:

Автоматизація запускається щодня вранці у репозиторії. Вона викликає skill для triage, читає минулі CI, відкриті issues, останні коміти, і записує все у markdown або Linear-дошку. Для кожної знахідки, що варта уваги, створюється ізольований worktree, делегується sub-agent для підготовки рішення, і ще один — для перевірки відповідності проєктним skills і тестам.

Connectors відкривають PR, оновлюють ticket. Все, що не може зробити цикл — потрапляє у triage. Статус — це хребет усього: що зроблено, що ще відкрито, що в процесі. Наступного ранку цикл продовжить з того місця, де закінчився.

Після всього — ви зробили лише один раз. Ні один крок не потребує вашого промпту. Це і є конкретна реалізація слова Стайнбергера. І цей самий цикл працює і у Codex, і у Claude Code, бо компоненти однакові.

Що цикл ще не робить для вас

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

Перевірка — все ще ваша справа. Цикл без контролю — це цикл без помилок. Роль verifier sub-agent — зробити «завершено» значущим; але «завершено» — це лише твердження, а не доказ. Я повторюю слова з статті «code review in the age of AI»: ваша робота — випустити код, який ви особисто підтвердили, що він працює.

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

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

Побудуйте цикл, але залишайтеся інженером

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

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

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

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

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