Американський підприємець і розробник Остін Марчезе, відомий своїми практичними гайдами з побудови AI‑систем навколо Claude від Anthropic, пропонує дивитися на роботу з моделями не як на разові промпти, а як на систему лупів. У його підході вісім взаємопов’язаних циклів перетворюють Claude на інфраструктуру, що збирає дані, будує продукти й постійно самопокращується.
![]()
У центрі концепції — проста, але жорстка дефініція: «луп» — це не макрос і не один запит, а процес, який «працює безперервно або за заданим розкладом, доки завдання не буде виконане». Звідси народжується цілісна архітектура для SaaS‑продуктів і внутрішніх інструментів, яку Марчезе розбиває на три великі блоки.
Що таке лупи Claude і навіщо вони взагалі потрібні
Базова ідея лупів у тому, що AI‑процеси повинні бути не разовими, а повторюваними, керованими й вимірюваними. Замість того, щоб «кидати» в модель окремі задачі, користувач вибудовує сталі контури, які:
- підхоплюють нові дані,
- перетворюють їх на корисні інсайти й артефакти,
- оцінюють результати,
- коригують систему без постійної ручної участі.
Марчезе підкреслює, що луп — це саме процес, який живе в часі: він може крутитися постійно, а може запускатися «по будильнику», наприклад раз на тиждень. Ключова риса — націленість на завершення конкретного завдання або досягнення чіткого порога якості чи метрики.
У цьому відео він проходить «перший із восьми Claude‑лупів» і одразу ставить їх у ширший контекст: це не розрізнені трюки, а «вісім Claude‑код‑лупів», що «допоможуть будувати швидше й ефективніше». Сукупно вони складають архітектуру, яка має замінити хаотичні промпти на керований стек.
Три групи лупів: інжест, білд, самопокращення
Уся система, за задумом Марчезе, спирається на чітку класифікацію. «Для всіх восьми цих лупів я групую їх у три категорії», — пояснює він.
Перша категорія — це лупи, які «допомагають інжестити дані й отримувати кращі відповіді». Йдеться про цикли, що автоматично підтягують інформацію з інструментів, якими реально користується команда, очищують її від «фону» й складають у єдине інформаційне поле, з яким Claude уже може працювати далі. Саме сюди потрапляє data‑ingest loop та external і internal alpha farming, які формують унікальний «моат» з даних і патернів.
Друга категорія — лупи, які «допомагають будувати швидше». Вони атакують болючу зону розробників і продактів: як перетворити розмиті цілі й backlog на код, зміни в продукті чи оптимізовані механізми. Optimization loop і code‑build loop змінюють сам спосіб взаємодії з AI — від «код на замовлення» до тривалих циклів «план → виконання → вимірювання → корекція».
Третя категорія — «серія лупів, що допомагають створити систему, яка автоматично покращується з часом». Improve‑system loop, ecosystem monitoring loop і фінальний north star loop переносять акцент із продуктивності окремих задач на еволюцію всієї екосистеми. Це горизонт, де AI‑стек перестає бути статичним і стає живою системою зі своєю пам’яттю, логуванням і механізмами самонагляду.
Саме ця тришарова структура дозволяє інтегрувати Claude не як «ще один чат», а як ядро процесів.
Коли зворотний зв’язок не мусить бути миттєвим
Окремий інсайт, який Марчезе ставить в центрі розуміння лупів, стосується часу. Він зізнається: «Коли я тільки почав думати про лупи, я вважав, що весь зворотний зв’язок має відбуватися майже миттєво… Зробив зміну — виміряв результат тощо». Та згодом прийшло усвідомлення, що «це не обов’язково має бути так».
Це важлива зміна парадигми. Часто AI‑лупи уявляють як щось на кшталт real‑time‑систем: будь-яка модифікація відразу «відстукується» в метриках, і на основі цього система коригує свій курс. Марчезе ж показує, що луп діє так само ефективно, якщо його цикл розтягнутий у часі.
Як приклад він наводить оптимізацію конверсії сайту. Замість миттєвих A/B‑реакцій, луп може «запускатися, перевіряти конверсію за перший день, робити правку, перевіряти її за другий день тощо», і весь цей цикл зворотного зв’язку розтягується на «24 години». Для нього «це абсолютно нормально», і саме це відкриває «цілий простір можливостей». Раніше йому здавалося, що такий повільний фідбек робить систему непридатною, але тепер повільні, проте стійкі лупи перетворюються на потужний інструмент для складних, лінивих метрик.
Наслідок: розробники та продакти можуть вибудовувати Claude‑лупи навколо реальних бізнес‑циклiв — денного трафіку, щотижневих звітів, місячних кампаній — не намагаючись втиснути усе в миттєву реактивність.
«Лупсепшн»: коли один луп керує іншими
На етапі сьомого лупа архітектура переходить у режим, який Марчезе сам називає «loopception». Ecosystem monitoring loop — це луп, що «керує іншими лупами», контролюючи їхню роботу, шукаючи повторну логіку і стежачи за станом усієї системи.
На перший погляд, зізнається він, це може виглядати абсурдно: «Перш ніж ви скажете, що це смішно й ми просто спалюватимемо токени, є кілька ключових рис, чому це насправді може економити токени, водночас запускаючи ефективнішу систему». Архітектура з надбудовою у вигляді моніторингового лупа дає одразу кілька ефектів.
По‑перше, вона виявляє можливості композиційності: коли різні лупи дублюють однакові шматки логіки, їх можна винести в окремі скіли й перевикористовувати. Це знижує ризики «гри в крота», коли виправлення в одному місці «вилазить» у кількох інших.
По‑друге, моніторинговий луп виконує роль «health check» по всьому стеку. За умови, що кожен луп коректно логуює свої результати, стає очевидно, які цикли дають користь, а які просто спалюють ресурси. Марчезе прямо каже, що, на його думку, сьогодні «є, мабуть, мільйони людей, які зараз запускають лупи й навіть не знають про це, просто спалюючи токени». Системний моніторинг дозволяє вчасно відключати непотрібне.
По‑третє, такий луп сам себе оновлює й «знімає операційний борг», оскільки автоматично підхоплює нові лупи за єдиною схемою найменування. Це важливий момент: складність системи росте, але зусилля на її підтримку — ні.
У підсумку «лупсепшн» виявляється не даниною моді, а спробою інженерно розв’язати дуже реальну проблему масштабування AI‑стеку й витрат на нього.
North Star loop як компас для всієї AI‑екосистеми
Фінальний, восьмий луп Марчезе називає тим, що «може зробити найбільшу різницю». Якщо попередні сім — це «інструменти», то «цей луп — це компас». Його завдання — «моніторити вашу активність і стежити, щоб ви справді рухалися до своїх цілей».
Логіка north star loop проста й жорстка. Насамперед потрібно «зафіксувати north star» — сформулювати конкретні, відчутні цілі: від кількості підписників до числа нових клієнтів чи запущених продуктів. Це не абстрактне «бути кращими в AI», а те, що можна однозначно інтерпретувати в термінах дій і результатів.
Далі луп «аналізує траєкторію». Він читає історію сесій із Claude, дані, які інжестяться, результати інших лупів — «усе, над чим ви працювали» — щоб зрозуміти, куди фактично рухається система. Після цього відбувається «резюмування» з «forward extrapolation»: по суті, будується сценарій «якщо нічого не зміниться, ось де ви опинитеся».
Марчезе визнає, що саме цей етап зазвичай працює як найсильніший «ляпас реальністю»: коли AI спокійно показує, в якій точці ви будете «через шість місяців», якщо продовжите діяти так само, мотивація змінювати курс різко зростає.
Четвертий крок — «пропонування змін напряму». Якщо виявлено дрейф, луп «висвітлює, що саме тягне вас у цей бік» і пропонує альтернативи: що слід переробити, відчепити, підсилити. Це вже не просто інформаційна панель, а інструмент, що намагається перевести розбалансований стек назад у режим, орієнтований на реальні бізнес‑цілі.
Саме тому Марчезе вважає, що це «той тип лупа, який, відверто кажучи, усім потрібно почати використовувати». Без нього навіть найдосконаліша конфігурація інжест‑лупів, білд‑лупів і самопокращення ризикує працювати в холосту — оптимізуючи другорядне й ігноруючи ключове.
Від промптів до архітектури
У фіналі Марчезе зводить усю систему до одного речення: це «вісім лупів, які вам потрібно збудувати, згруповані в три різні блоки: лупи, що допомагають інжестити дані, будувати швидше й створювати систему, яка компаундується та може підтримуватися з часом».
Це зміна масштабу мислення. Замість того щоб щоразу вигадувати новий промпт і сподіватися на вдалу відповідь, він пропонує вбудовувати Claude у регулярні процеси — із розкладом, логуванням, спільними скілами, моніторингом і, головне, чітко визначеною north star.
Така архітектура не обіцяє миттєвої магії. Вона радше нагадує поетапне будівництво виробничої лінії: спочатку канали постачання даних, потім — конвеєр створення продукту, потім — механізми перевірки якості й самопокращення, і нарешті — система навігації, що не дає всій цій машині забути, заради чого вона існує.
У добу, коли взаємодія з LLM часто зводиться до «ще одного чату», саме такий підхід — від мислення лупами до мислення стеком — може стати різницею між яскравим демо й реально працюючою AI‑інфраструктурою.


