Як перейти від промптів до «лупів» і змусити AI працювати самостійно

Провідні інженери, що працюють над Claude Code та агентними системами, закликають відмовлятися від постійного ручного промптингу й переходити до так званого loop engineering — проектування «лупів» (циклів), які самі керують ШІ‑агентами. Канал Austin Marchese системно розкладає цю ідею на практичні кроки й показує, як організувати роботу з Claude так, щоб ваша роль змістилася з «того, хто постійно щось дописує в чат», до «того, хто один раз проєктує процес і далі лише наглядає».

Що таке «луп» і чим він відрізняється від звичайного промпта

Класичний промпт — це одноразовий запит: ви написали інструкцію, модель відповіла, на цьому сесія логічно завершена. «Луп» працює інакше: це процес, який запускається й повторюється доти, доки не досягнена конкретна ціль.

Ключова зміна мислення:
замість 100 разів просити AI зробити маленькі кроки, ви один раз описуєте:

• кінцеву мету,
• шлях до неї,
• правила перевірки результату,
• як і де зберігати проміжні кроки.

Далі вже не ви «промптите» модель — це ваш луп, фактично міні‑агент, що промптить її сам і керує всією послідовністю дій.

Коли має сенс будувати луп: 4‑критерійний тест

Щоб не перетворити все життя на «конвеєр з лупів», варто проганяти будь‑яку ідею через простий тест:

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

2. Є чітка «definition of done»?
   Потрібно формально визначити, коли завдання вважається завершеним. Не просто «зробити гарно», а, наприклад:
   – сайт відкривається за конкретним доменом,
   – час завантаження менше 2 секунд,
   – усі вхідні листи мають чернетки відповідей.
   Луп має знати, що таке «готово» й як це перевірити.

3. Чи можете дозволити собі «марнотратство» токенів?
   Лупи автоматично генерують нові виклики моделі, поки не досягнуть мети. Це зручно, але дорого: якщо у вас жорсткі ліміти чи рахунок за API — потрібно обмежувати кількість ітерацій та обсяг контексту.

4. Луп має інструменти для завершення задачі?
   Якщо йдеться про сайт, система має вміти:

5. перевірити, що домен доступний,
6. зробити HTTP‑запит,
7. прочитати відповіді,
8. викликати інші «skills» для правок.
   Без доступу до потрібних інструментів луп перетворюється на красиву, але беззубу концепцію.

Якщо на всі чотири запитання відповідь «так» — це кандидат на повноцінний луп.

Чотири будівельні блоки робочого лупа

Loop engineering автор розкладає на чотири ключові компоненти: тригер, execution skills, ціль із верифікацією та вихід із пам’яттю.

1. Тригер: що запускає луп

Тригер — це точка старту. Без нього луп існує лише як ідея в текстовому файлі. Прості варіанти:

• /loop у Claude
  Дає змогу запускати завдання з певним інтервалом з локальної машини. Наприклад:
  /loop every 6 hours: перевір погоду та повідом, чи потрібно змінити план тренувань за моїм календарем.
  Мінус: якщо ноутбук вимкнений, луп не працює.

• /schedule
  Планування в хмарі за розкладом (наприклад, щодня о 8:00). Такий підхід не залежить від вашого комп’ютера й підходить для регулярних бізнес‑процесів.

• Кастомний orchestration‑skill
  Більш «інженерний» варіант: створити окремий skill, який виконує роль «центру управління польотом» для лупа.
  Наприклад, /check_weather_loop — єдиний виклик, що:

• знає, яка ціль,
• які підзадачі,
• як перевіряти результат,
• куди логувати історію.

Цей orchestration‑skill фактично зашиває всю логіку лупа в одному «ендпойнті», який ви запускаєте вручну, за розкладом або іншим тригером.

2. Execution skills: «мускули» вашого лупа

Якщо тригер — це старт, то execution skills — це виконавчі модулі, кожен із яких робить одну конкретну роботу.

Що важливо:

• Skill — це по суті збережений промпт з чіткою інструкцією, який можна викликати повторно.
• Оркестратор не займається «дрібницею» — він тільки вирішує, який skill викликати і в якій послідовності.
• Один skill — одна спеціалізація: написати e‑mail, перевірити факт, проаналізувати тренування, рецензувати код тощо.

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

Показовий приклад — погода й тренування.
Без окремого /analyze_workout AI може просто сказати: «Йде дощ, скасовуємо пробіжку».
Але якщо у вас є skill, де зафіксовано, що ви любите бігати під дощем, — луп видасть зовсім іншу рекомендацію. Поведінка лупа напряму залежить від того, наскільки якісно описані ваші навички‑skills.

3. Ціль і верифікація: як луп розуміє, що «робота зроблена»

Будь‑який луп тримається на зв’язці:

• Goal — що саме потрібно досягти,
• Verification — як формально підтвердити, що це досягнуто.

Технічний сценарій: запуск сайту

• Ціль:
  «Запустити сайт на домені X та забезпечити час завантаження менше 2 секунд».

• Верифікація:

• Зробити запит на домен X.
• Переконатися, що контент відповідає очікуванням.
• Заміряти час завантаження.
• Пропустити результат через /engineer_review skill, який або схвалює зміни, або відхиляє.

Луп повторює цикл «оновлення — перевірка», доки всі критерії не виконані.

Нетехнічні задачі: як зробити абстрактне — вимірюваним

З нетехнічними задачами складніше: поняття «якісний текст» або «добре написаний лист» не мають чіткої метрики. Тут потрібен «міст» між абстрактним судженням і формальною перевіркою.

Приклад: луп для пошти /draft_emails_loop.

• Ціль:
  Для кожного непрочитаного листа створити чернетку відповіді.

• Верифікація:

• Усі листи без відповіді мають чернетку.
• Кожна чернетка пройшла рев’ю через:
  • /email_review (структура й зміст),
  • /writing_voice (стиль і тон автора),
  • /fact_checker (перевірка фактів).

У цих skills можна додати наприкінці формальне поле:
approved / not approved або оцінку за шкалою 1–10. Це й перетворює суб’єктивні критерії на об’єкт перевірки.

Той самий прийом можна застосувати до будь‑яких абстрактних задач — від контент‑маркетингу до HR‑процесів. Головне — спочатку оформити judgment‑skill, який повертає формальне рішення, а вже потім вбудовувати його в луп.

Корисний підхід — separate agent verification:
верифікацію виконує інший агент або суб‑агент Claude, щоб зменшити «упередженість» моделі до власного результату.

4. Вихід і пам’ять: чому без логів луп «вчорашній день»

Будь‑який луп щось виробляє:
документи, зміни в коді, оновлені сайти, повідомлення в месенджерах тощо. Але цього замало — без пам’яті система щоразу «прокидається з нуля».

Основні принципи:

• Луп має записувати історію запусків: що робив, які були проміжні результати, які помилки виникали, які параметри спрацювали.
• Не потрібні складні системи — достатньо, наприклад, Markdown‑файла з логами.
• Формула з документації Anthropic, яку згадує автор:
  «Agent забуває, репозиторій — ні».

Збереження історії дозволяє:

• не наступати на ті самі граблі,
• аналізувати, на чому «горить» найбільше токенів,
• поступово вдосконалювати як skills, так і лупи.

Технічно це може бути просто оновлення файлу з «lessons learned» кожного разу, коли orchestration‑skill завершує чергову ітерацію.

Як побудувати свій перший луп і не спалити всі токени

Loop engineering звучить складно, але автор пропонує досить приземлений алгоритм старту.

1. Почати з найменшої вже перевіреної задачі

Запитання для старту:
яке найменше завдання ви вже виконували з Claude і задоволені якістю?

Це може бути:

• типова структура листів,
• шаблон аналітичного звіту,
• перевірка коду,
• аналіз тренувань,
• підготовка нотаток за мітингами.

Тепер потрібно прогнати цей кейс через 4‑умовний тест (повторюваність, definition of done, бюджет токенів, доступні інструменти). Якщо все сходиться — це кандидат на перший луп.

2. Використати skill‑driven loop development

Принцип: лупи – надбудова над уже існуючими skills.

• Спочатку створюються й відшліфовуються ключові skills (написання, рев’ю, аналіз, факт‑чек, технічні перевірки).
• Далі orchestration‑skill просто «склеює» їх у послідовний процес:
• Викликати skill А,
• Передати результат у skill B,
• Перевірити через skill C,
• Залогувати результат у пам’ять,
• Повторити, якщо верифікація не пройдена.

Такий підхід мінімізує сюрпризи: ви вже приблизно знаєте, як поводяться окремі skills, і лише комбінуєте їх.

3. Увімкнути «training mode», доки луп не доведений

Важливий запобіжник — режим навчання лупа:

• На перших ітераціях orchestration‑skill робить паузу на кожному кроці й запитує вашого підтвердження:
  «Quick check before I burn the tokens… Продовжувати?»
• Ви бачите хід процесу, втручаєтеся, коли щось йде не так, коригуєте інструкції.
• Тільки після того, як переконаєтеся, що луп поводиться адекватно, вимикаєте training mode, і він працює повністю автономно.

Перевага очевидна:
ви не лише економите токени, а й краще розумієте, як саме AI виконує роботу — це допомагає згодом масштабувати підхід на складніші сценарії.

4. Розбивати нечіткі цілі на етапи з людськими чекпоінтами

Для задач, де результат важко виміряти (події, стратегії, креатив), автор радить ставитися до AI як до інтерна.

Замість «сплануй корпоратив» — послідовність з контрольними точками:

1. Обрати дату — погодити.
2. Запропонувати варіанти локацій — погодити.
3. Запропонувати 3–5 тем вечірки — погодити.
4. Лише потім запускати всю іншу роботу.

Те саме з лупами:
кожен «ключовий розгалужувач» процесу має стати чекпоінтом, де або луп звертається до людини, або окремий verification‑skill дуже жорстко перевіряє відповідність.

Що менш вимірюваний фінальний результат —
то дрібнішими мають бути цілі лупа й частішими — точки верифікації.

Джерело

YouTube — «Stop Prompting Claude. Start Loop Engineering.»