Що таке loop engineering: визначення терміна

Що означає проєктування циклу

Проєктування циклу — це розроблення повторюваного циклу роботи AI-агента: що його запускає, до чого він може отримувати доступ, як перевіряється його результат і що його зупиняє. Prompt engineering формує одне повідомлення для моделі. Loop engineering формує процес, який надсилає тисячі повідомлень, поки ви спите. Одиницею роботи стає не prompt, а loop.

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

Чому цей термін з’явився у 2026 році

Назва просто зараз закріплюється в публічному просторі. Репозиторій GitHub cobusgreyling/loop-engineering набрав 9,600 зірок протягом двох місяців після першої появи (станом на липень 2026 року), а 2026-10-27 мав близько 11,600 зірок. Його опис супроводжувався рядком: «Припиніть писати промпти. Проєктуйте цикл. Отримуйте оцінку». У липні 2026 року його README об’єднував цей підхід у шість будівельних блоків: планування, worktrees, skills, plugins і connectors, sub-agents та надійну пам’ять, що зберігається поза розмовою. У поточному README цього списку вже немає (перевірено 2026-10-27), але стан циклу й далі зберігається у файлі поза розмовою.

У репозиторії серед джерел натхнення вказано Boris Cherny, який очолює Claude Code в Anthropic. Йому широко приписують таку фразу:

Я більше не пишу промпти для Claude. У мене працюють цикли, які пишуть промпти для Claude.

Другий репозиторій, AI-Builder-Club/skills, має близько 1,300 зірок (станом на 2026-10-27) і прямо називає дві ролі: «codebase harness», який робить репозиторій безпечним для запуску агентом тестів і розгортань, та «loop engineer», який створює робочі процеси, що запускаються тригером, виконують роботу й записують отримані знання у спільний файл, щоб наступний цикл міг їх прочитати.

Жоден із цих репозиторіїв не винайшов цю практику. Кожен, хто запускав нічну збірку, linter у continuous integration або cron job, що створює ticket, уже знає її структуру. Новим є те, що worker усередині циклу тепер недетермінований. Через це змінюються вимоги до всієї навколишньої інфраструктури.

Чотири складові циклу

Кожен робочий цикл має ці чотири складові. Цикл, у якому однієї з них немає, може розбудити вас о 3am.

• Тригер. Подія, яка запускає виконання: таймер, webhook, новий pull request або alert.
• Межі. Файли, облікові дані та мережа, до яких агент може отримати доступ під час цього виконання.
• Перевірка. Перевірка з кодом завершення, який визначає, зберегти результат виконання чи відкинути його.
• Бюджет. Обмеження на кількість токенів, час і кошти, яке завершує виконання незалежно від того, чи було воно успішним.

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

Тригер: що запускає агента

Таймер — найпростіший тригер. На Linux-сервері systemd timer у цьому випадку кращий за cron, бо він веде журнал, повторює запуск за заданими правилами й не запускає другу копію unit, якщо попередня ще працює. Остання властивість усуває найпоширенішу помилку накладання в циклах агента: два запуски редагують одну гілку.

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

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Потім створіть unit у /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

А timer — у /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

У systemctl list-timers має відображатися стовпчик NEXT із часом у майбутньому та стовпчик LEFT зі зворотним відліком. Порожній результат означає, що timer не ввімкнено, оскільки enable без --now запланує його лише на наступне завантаження системи. TimeoutStartSec=1800 важливіший, ніж здається. Сервіс Type=oneshot вважається запущеним, доки його скрипт не завершиться. За замовчуванням systemd вимикає timeout запуску для unit типу oneshot. Тому без цього рядка агент, який завис в очікуванні введення, назавжди залишає unit у стані activating, а кожен наступний запуск timer виявляє, що unit усе ще працює, і нічого не запускає. Із цим рядком systemd завершує запуск через 30 хвилин і позначає його як невдалий. Якщо ви зміните unit на типовий Type=simple, TimeoutStartSec більше не обмежуватиме сам запуск, а саме RuntimeMaxSec= встановлюватиме його максимальну тривалість. Переглянути запуск можна за допомогою journalctl -u agent-loop.service -n 50.

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

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n негайно завершується зі статусом 1, якщо блокування вже встановлено. Тому другий запуск тихо завершується, не створюючи конкуренції з першим. Та сама конфігурація systemd service і timer застосовна до будь-якого довготривалого завдання на сервері — незалежно від того, використовує воно агента чи ні.

Межа: кожен запуск отримує власну копію

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

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list виводить по одному рядку для кожного дерева із зазначенням його шляху, коміту та гілки. Після завершення запуску git worktree remove /srv/agent/work/triage-01 видаляє worktree, але лише якщо він чистий. Якщо дерево містить невідстежувані файли, змінені відстежувані файли або субмодулі, git відмовляється виконувати видалення, доки ви не додасте --force. Саме тому наведений нижче gate script примусово видаляє лише worktree, шлях до якого використовується для завершення запуску. git worktree prune очищає записи, для яких директорія більше не існує. На цьому етапі паралельні цикли стають безпечними: два агенти, що працюють у двох гілках і двох директоріях, не можуть перезаписати дані один одного.

Межа стосується також облікових даних. Цикл, який виконується без нагляду, зберігає довгоживучі токени, а кожен запуск створює можливість випадково записати токен у журнал, коміт або контекст моделі. Обмежте токен одним репозиторієм, до якого звертається цикл. За можливості не передавайте його в середовище, доступне власній оболонці агента. Перш ніж надати циклу доступ до production, прочитайте як не допустити потрапляння секретів до AI-агентів. Для надійнішої ізоляції розмістіть увесь цикл у одноразовій VM, яку можна знищувати після кожного запуску. Інструмент, який ви запускаєте, також частково визначає межу ізоляції ще до написання коду. Тому перед вибором рівня ізоляції, який потрібно реалізувати самостійно, варто прочитати як керований sandbox Cowork порівнюється з Claude Code на вашій власній машині.

Перевірка: gate, який робить цикл безпечним

Саме це відрізняє цикл від cron job, який лише вводить команди. Вивід агента — це пропозиція. Рішення приймає gate.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail виконує реальну роботу в цьому скрипті. Без -e помилка git fetch ігнорується, і виконання триває зі застарілим origin/main. Без -u помилка в імені змінної розгортається в порожній рядок, після чого очищення виконується для неправильного шляху замість негайного завершення з помилкою. В останньому рядку навмисно немає --force: якщо після виконання в дереві залишилися непідстежувані або незакомічені файли, git відмовляється їх видаляти, а -e завершує виконання з помилкою після push, не видаляючи мовчки роботу, яку ніхто не закомітив.

Блок if ! npm test містить усю ідею. Код завершення перевірки, якій ви вже довіряєте, — test suite або type checker — визначає, чи буде branch опубліковано або видалено. Цикл без gate створює роботу, яку нікому перевіряти, і це гірше, ніж відсутність роботи. Цикл із gate створює branch, який уже пройшов той самий поріг, що й branch людського контриб’ютора. Успішний gate нічого не говорить про обсяг коду, який агент змінив для досягнення результату. Тому варто поєднати перевірку з постійною інструкцією, наприклад правилом, яке змушує агента вносити найменшу працездатну зміну, щоб diff залишався достатньо малим і його було недорого перевіряти.

Оберіть gate, який чесно повідомляє про помилки. Test suite, що проходить для порожнього diff, навчає цикл сприймати бездіяльність як успіх. Репозиторії зі слабкими тестами породжують слабкі цикли. Саме тому популярні репозиторії ставлять завдання «зробити codebase готовим для агента» перед завданням «написати цикл». Якщо ви хочете знати, чи справді ваша suite виявить регресію, а не лише виконає відповідні рядки, відповідь дає mutation testing. А агент, який повертає звіт із доказами, придатний для повторного запуску, замість того щоб просити вас читати його diff, перетворює цей результат на те, що ви можете самостійно перевірити.

Бюджет: що зупиняє виконання

Агент, який повторює спроби без кінця, створює необмежені витрати. Для кожного циклу встановіть граничний час виконання, контрольований через TimeoutStartSec вище; ліміт кількості повторних спроб у скрипті; і максимальну суму витрат, задану в обліковому записі провайдера. Потім записуйте в журнал вартість кожного виконання, щоб виявити відхилення циклу ще до появи рахунку. У розділі Контроль витрат для постійно активного агента на VPS описано облік витрат, а в розділі керування контекстом, який агент переносить між ходами — найбільший окремий чинник вартості одного виконання. Цикл, який кожні 30 хвилин повторно читає той самий репозиторій, оплачує це кожні 30 хвилин.

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

Підходи, які формалізують популярні репозиторії

Репозиторій loop-engineering перелічує вісім production-підходів (станом на 2026-10-27), і їх варто сприймати як набір варіантів, а не як маніфест. Щоденний triage. Тонкий цикл, який запускається як GitHub Action і не зберігає файл стану. Pull-request babysitter, який відстежує review comments і відповідає на них. Continuous-integration sweeper, який обробляє збірки з помилками. Dependency sweeper. Засіб підготовки чернеток changelog. Очищення після merge. Triage issues.

Їх об’єднує вузьке завдання з очевидною умовою проходження. «Виправити збірку з помилкою» має умову успішного завершення, яку машина може прочитати. «Покращити codebase» такої умови не має, тому це завдання ніколи не стає циклом. Воно перетворюється на безлад із розкладом.

Їх також об’єднує письмовий запис. Обидва репозиторії виносять стан із розмови у файли в репозиторії: що запускалося, що було виявлено, яке рішення ухвалено. Цей файл є пам’яттю циклу. Саме він дає змогу другому циклу продовжити роботу першого, а не повторно шукати вже знайдене. Це також спосіб перевірити дії агента постфактум, оскільки контекст моделі зникає одразу після завершення запуску. Оперативна координація відбувається через окремий канал, і одна сесія Claude Code може передати роботу іншій на тому самому хості, поки обидві ще працюють. Проте ніщо в цьому обміні не зберігається після завершення будь-якої з сесій, тому згодом ви перечитуєте саме файл.

Де цикли дають збій

Причини збоїв типові й повторюються в різних командах.

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

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

Початок роботи без спеціальної термінології

Вам не потрібен фреймворк. Невеликий постійно доступний Linux-сервер, git-репозиторій, набір тестів якого коректно завершується помилкою, один таймер systemd і один shell-скрипт із if утворюють повний цикл. Саме з цього варто почати більшості користувачів, оскільки питання проєктування вирішуються під час запуску системи, а не вибором інструмента. Коли один цикл працює стабільно, запуск другого здебільшого зводиться до додавання ще одного таймера та ще одного worktree. Див. як запустити coding AI agent на VPS для базового налаштування та актуальні варіанти self-hosted AI agent, якщо ви хочете запускати самого агента на обладнанні, яке контролюєте.

FAQ

Чи відрізняється проєктування циклу від проєктування prompt?

Проєктування prompt оптимізує одне повідомлення: формулювання, приклади та формат виводу. Проєктування циклу оптимізує процес навколо повідомлення: тригер, який запускає виконання, sandbox, у якому воно працює, перевірку, що приймає або відхиляє результат, і бюджет, після вичерпання якого цикл завершується. Усередині циклу все одно потрібен якісний prompt. Але prompt перестає бути основним об’єктом щоденного налаштування, оскільки gate і тригер сильніше впливають на результат.

Чи потрібен framework для створення циклу агента?

Ні. systemd timer, окремий git worktree для кожного запуску, shell script, який завершується тестовою командою, і обмеження витрат в обліковому записі провайдера охоплюють усі частини цього визначення. Framework додає інтерфейси планування, формати спільної пам’яті та маршрутизацію між агентами. Це корисно, коли ви запускаєте кілька циклів. Але framework не є обов’язковою умовою для першого циклу.

Що таке codebase harness?

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

Як не допустити, щоб цикл агента створив великий рахунок?

Встановіть обмеження у трьох місцях. Задайте TimeoutStartSec для unit systemd типу Type=oneshot, як у прикладі вище, щоб завислий запуск було примусово завершено. Для сервісу типу Type=simple еквівалентом є RuntimeMaxSec. Обмежте кількість повторних спроб усередині скрипту, а не запускайте цикл до успішного завершення. Встановіть жорсткий ліміт витрат для API-облікового запису, оскільки лише це обмеження агент не може обійти переконливими аргументами. Також записуйте в журнал витрати для кожного запуску. Якщо вартість циклу подвоюється, це зазвичай означає, що область його роботи непомітно розширилася.

Які завдання першими варто перетворити на цикл?

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