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

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

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

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

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

Назва формується просто зараз у публічному просторі. Репозиторій GitHub cobusgreyling/loop-engineering набрав понад 9,600 зірок протягом двох місяців після першої публікації (станом на липень 2026 року) під гаслом "Stop prompting. Design the loop. Get a score.". У ньому цей перехід описано через шість будівельних блоків: планування, worktrees, навички, плагіни та конектори, субагенти й постійна пам’ять, що зберігається поза межами розмови.

У репозиторії наведено цитату Boris Cherny, який керує Claude Code в Anthropic:

I don't prompt Claude anymore. I have loops running that prompt Claude.

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

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

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

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

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

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

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

Найпростіший тригер — timer. На Linux-сервері systemd timer кращий за cron, оскільки він веде журнал, повторює запуск за заданими правилами й не запускає другу копію unit, якщо попередній запуск ще триває. Остання властивість усуває найпоширенішу помилку перекриття в циклах 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 важливіший, ніж може здаватися: agent, який завис в очікуванні введення, інакше утримуватиме unit активним безстроково, а timer більше не спрацює. Переглянути запуск можна за допомогою 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, якщо lock уже утримується. Тому другий запуск тихо припиняється й не конкурує з першим. Та сама схема налаштування service і timer systemd застосовується до будь-якого довготривалого завдання на сервері — незалежно від того, чи є воно agent.

Межа: окрема копія для кожного запуску

Агент, який редагує вашу робочу директорію, може втратити незакомічені зміни. 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 видаляє директорію, а git worktree prune очищає записи, для яких директорію вже видалено. Паралельні цикли на цьому етапі стають безпечними, оскільки два агенти у двох гілках і двох директоріях не можуть перезаписати зміни один одного.

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

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

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

#!/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 помилка в імені змінної розгортається в порожній рядок, після чого очищення виконується для неправильного шляху замість явного завершення з помилкою.

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

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

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

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

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

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

Репозиторій loop-engineering описує сім production-патернів. Їх варто читати як перелік варіантів, а не як маніфест. Щоденний triage. Помічник для pull request, який відстежує коментарі під час review і відповідає на них. Засіб для перевірки continuous integration, який підбирає збірки з помилками. Засіб для перевірки залежностей. Генератор чернетки changelog. Очищення після merge. Triage issues.

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

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

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

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

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

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

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

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

FAQ

Чи відрізняється loop engineering від prompt engineering?

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

Чи потрібен framework для побудови agent loop?

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

Що таке codebase harness?

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

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

Встановіть ліміти у трьох місцях. Задайте TimeoutStartSec для systemd unit, щоб примусово завершувати завислий запуск. Обмежте кількість повторних спроб у script, а не запускайте цикл до досягнення успіху. Встановіть жорсткий ліміт витрат для API account, оскільки це єдина межа, яку агент не може обійти переконливими аргументами. Також записуйте в журнал вартість кожного запуску: якщо вартість циклу подвоюється, це зазвичай означає, що його область застосування непомітно розширилася.

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

Виберіть завдання з умовою успішного виконання, яку можна прочитати програмно, і невеликим радіусом впливу. Виправлення невдалого build, оновлення dependency та повторна генерація changelog відповідають цим критеріям, оскільки test suite або diff можуть підтвердити результат. Відкриті завдання, як-от refactoring або design, поки що не підходять: gate не має що перевіряти, а loop без gate — це дорогий спосіб накопичувати борг на review.