Американський підприємець і розробник Остін Марчезе, відомий своїми практичними гайдами з побудови AI-стеків на Claude, пропонує не просто використовувати модель як черговий «чат», а перетворювати її на систему, що сама себе вдосконалює. У новому розборі він показує, як два ключові лупи — improve-system та ecosystem monitoring — дають змогу AI-інфраструктурі жити власним життям, при цьому не «розповзаючись» у хаос і не спалюючи зайві токени.
Це не загальна теорія автономних агентів, а доволі приземлена операційна концепція: регулярні цикли аналізу, зміни й моніторингу, побудовані на Claude, які підхоплюють уже існуючі скіли, логи й лупи, та зшивають їх у самопокращувану систему.
Improve-system loop: регулярний «сервіс» для всього AI-стеку
Марчезе називає improve-system loop своїм улюбленим із усіх восьми описаних ним лупів і стверджує, що саме він «один у полі» трансформував його бізнес. Суть підходу — у регулярному, заздалегідь запланованому саморев’ю всієї AI-системи.
Він запускає improve-system loop двічі на тиждень — наприкінці дня у вівторок і п’ятницю. Такий ритм робить AI-екосистему по-справжньому самопокращуваною: система постійно замикає зворотний зв’язок між тим, як вона працює зараз, і тим, якою має стати.
У лупа є два рівні.
Перший — це сам improve system skill. Це не просто промпт для разової відповіді, а скіл, який цілеспрямовано «дивиться» на вашу AI-систему і шукає шляхи її покращення. Він читає сесії, знаходить повторювані патерни, пропонує зміни. Ідеться саме про аналіз робочих журналів і поведінки системи, а не про абстрактні поради.
Другий рівень — це вже власне луп, який обгортає цей скіл у регулярний процес. У цій обгортці Марчезе робить критично важливу річ: кожну зміну, яку луп вносить до системи, він логує у файл change_log.md. Такий глобальний журнал змін стає єдиним джерелом правди, що наочно показує, «що насправді відбувається в моїй системі», як він формулює.
Це ключ до прозорості: самопокращувана система без історії змін перетворюється на чорну скриньку. З change_log.md можна відкотитися, порівняти періоди, вловити деградацію чи навпаки стрибок якості.
Три кошики рішень: як не дати якості повільно розповзтися
Ще одна важлива деталь improve-system loop — те, як він класифікує запропоновані зміни. Усі пропозиції розкладаються в три кошики, і саме ця трирівнева схема дає змогу поєднати автоматизацію з людським «смаком».
Перший кошик — auto approve. Тут опиняються всі низькоризикові зміни, які можна застосовувати без дискусій. Це дрібні покращення, що очевидно не зіпсують якість виходу, а лише чинять дрібний тюнінг. Саме цей кошик відповідає за «самопокращення» в буквальному сенсі: система тихо поліпшує себе без участі людини.
Другий кошик — need sign off. Сюди потрапляють зміни з високими ставками: редагування скілів, додавання нових кандидатів у скіли, структурні зміни. Усе, де неправильний вибір може реально погіршити результати. Такі пропозиції записуються у файл рецензії у форматі чекбоксу: біля кожної — варіант «схвалити», «відхилити» або «схвалити й більше не питати». Через цю механіку користувач поступово «навчає» систему своїм пріоритетам, і з часом луп краще розуміє, що можна автоматизувати, а що завжди вимагатиме підпису.
Третій кошик — more context needed. Тут опиняється все, з чим луп не може впевнено розібратися самостійно. Марчезе наводить простий приклад: у системі кілька разів згадується певна людина, але з наявних даних незрозуміло, це новий ключовий клієнт чи разова взаємодія. Такі кейси також записуються в той самий файл рецензії, що й елементи другого кошика, але подають сигнал: без додаткових пояснень від людини логічного рішення тут не буде.
Ця трирівнева система, за його оцінкою, — «ефективний компроміс», що дозволяє будувати автоматизовану систему, здатну покращуватися без участі власника, але при цьому:
по-перше, спрощує маркування покращень;
по-друге, залишає людину «тестьмейкером», завдяки чому система не скочується в поступову деградацію якості й не віддаляється від того, що насправді потрібно.
Фактично тут закладено простий, але дієвий принцип: машина відповідає за інерційний прогрес, людина — за смислові повороти.
Ecosystem monitoring loop: коли лупи починають керувати лупами
Як тільки з’являється кілька окремих лупів, AI-екосистема зіштовхується з новою проблемою — операційним боргом. Кожен новий луп додає навантаження: його треба моніторити, оновлювати, перевіряти, чи не конфліктує він з іншими. Ecosystem monitoring loop стає «лупом, який керує іншими лупами», і Марчезе прямо визнає: це «loopception».
Звучить як рецепт для вибуху витрат на токени, але він аргументує протилежне. Правильно налаштований monitoring-loop, за його задумом, навпаки зменшує марнотратство, оптимізуючи спільну логіку та вимикаючи непотрібні процеси.
У цього лупа три ключові функції.
Пошук спільної логіки й composability
Перша функція — виявлення можливостей для composability між лупами. У міру зростання системи розробник часто несвідомо повторює одну й ту саму логіку в різних місцях. Наприклад, два різні лупи можуть мати однаковий блок коду для отримання даних зі Slack.
Ecosystem monitoring loop сканує бібліотеку лупів, знаходить такі повтори й пропонує винести загальну частину в окремий композабельний скіл, який потім викликатимуть усі лупи, що потребують цієї функціональності. Саме за таким принципом, зазначає Марчезе, працював plan verification skill: його створили один раз, а потім використовували в інших лупах, які вимагали перевірки плану реалізації.
Як наслідок, знижується ризик «гри в крота» — ситуації, коли баг у логіці виправляють в одному місці, а той самий баг лишається в іншому, де код був продубльований. Перенесення повторюваної логіки в один скіл перетворює її на аналог «функції, що повторно використовується», добре зрозумілої будь-якому програмісту.
Health-check усього стека й економія токенів
Друга функція ecosystem monitoring loop — «health-check» усього AI-стека. Ідея в тому, щоб перетворити результати роботи кожного лупа на уніфіковані логи й піднятися над ними ще одним рівнем аналізу.
Щоб це працювало, усі лупи мають грамотно логувати свої результати. Для цього Марчезе додає окремий utility-skill — write-log, який записує все в одну папку. Спеціальний промпт не лише створює цей скіл, а й «одночасно покращує всі існуючі лупи», щоб вони почали писати логи в єдиному форматі через одну точку входу.
Перевага такого підходу очевидна: якщо в певний момент оновити сам write-log skill, зміни автоматично поширюються на всі лупи, що його викликають. Таким чином health-check отримує одноманітні дані, які легко аналізувати.
Ключовий ефект — оперативне виявлення того, що працює, а що ні. Марчезе впевнений, що зараз «мільйони людей» запускають лупи й навіть не підозрюють, що ті все ще крутяться, спалюючи токени без відчутної користі. Наявність прозорого моніторингу дозволяє швидко вимкнути непотрібні процеси, і саме тут з’являється прямий економічний ефект від ecosystem monitoring loop.
Самооновлення без операційного боргу
Третя функція ecosystem monitoring loop — динамічне оновлення власного переліку й усунення операційного боргу. Використовується проста, але дисциплінована домовленість: кожен луп у системі має єдиний неймінг-патерн name-loop.
На кожному запуску monitoring-loop сканує всі скіли й відшукує ті, що відповідають цьому шаблону. Таким чином він автоматично включає у свою орбіту будь-які нові лупи, які з’являються в системі. Людині не потрібно кожного разу вручну додавати їх до списку спостереження.
Це означає, що сам ecosystem monitoring loop фактично «сам себе обслуговує»: він адаптується до змін у стеку, не створюючи нового операційного боргу. Якщо структура імен дотримується, монітор же не застаріє тільки через те, що в систему додали новий луп і забули про нього сказати «головному наглядачу».
Коли AI-стек починає працювати «за тебе», а не «з тобою»
У звичайному сценарії роботи з AI-кодом і лупами саме людина виступає драйвером кожної зміни: вона запускає процес, аналізує результат, придумує, що покращити, і руками оновлює систему. Підхід, який описує Остін Марчезе, зсуває акцент: improve-system loop бере на себе роль постійного рев’юера, а ecosystem monitoring loop — роль архітектора, який слідкує за структурою й станом екосистеми.
При цьому обидва лупи навмисне побудовані так, щоб не усунути людину з контуру прийняття рішень. Трирівнева схема з auto approve, need sign off і more context needed залишає за людиною стратегічний контроль і смисловий «редагувальний пензель». Monitoring-loop, у свою чергу, дає прозорість і можливість вимикати те, що лише спалює ресурси.
У результаті з’являється те, що Марчезе описує як AI-систему, яка «самопокращується», але не відривається від реальних цілей і не перетворюється на непрозорий хаос із десятків лупів.
Для всіх, хто вибудовує на Claude власні продукти чи внутрішні інструменти, ці два лупи стають не стільки «просунутими фішками», скільки новою базовою гігієною: без них AI-екосистема неминуче обростає боргом і повторною логікою, а з ними — отримує шанс розвиватися майже автономно, але під наглядом людини.