Американський підприємець і розробник Остін Маркезе у своєму детальному гіді про побудову самооптимізуючих систем на базі Claude Code пропонує досить приземлений погляд на “автономний” AI. Замість модної риторики про повністю самостійну систему він розкладає по поличках ризики такої автономії й показує, як організувати безпечний контур змін через один центральний скіл improve system і трирівневий bucket‑ревʼю.
У центрі його підходу — проста, але важлива теза: “self‑improving” не означає “людина більше не потрібна”. І саме від того, де провести межу між автоматичними змінами й людським контролем, залежить, чи стане ваша система кращою, чи почне тихо ламатися.
Міф про “справжню” self‑improving систему
На четвертому кроці свого B.U.I.L.D‑фреймворку Маркезе переходить до головного — improvement loop. Він формулює типове хибне уявлення: більшість людей вважає, що якщо система самооптимізується, то вона має працювати “повністю сама по собі”, без будь‑якого людського втручання.
Такий підхід справді можливий технічно: можна налаштувати ланцюжок, у якому Claude сам збирає дані, сам оновлює скіли, сам змінює структуру knowledge base і нікого ні про що не питає. Але Маркезе акцентує, що тут ховається головна загроза — системний дрейф, коли зсуви в поведінці й структурі накопичуються непомітно, поки одного дня результат уже радикально відрізняється від початкового задуму.
Щоб пояснити це інтуїтивно, він звертається до фітнес‑аналогії. Уявімо систему, яка “автоматично покращує вашу фізичну форму”.
Перша версія — повністю автономна. Вона “тренує вас” без жодного зусилля з вашого боку: ви нічого не робите, але стаєте “качком”. Звучить ідеально, поки не з’являється деталь: ця система тренує тільки груди. Через пів року — величезна грудна клітка й “ноги‑сірники”. З точки зору алгоритму, показник “об’єм грудей” впевнено зростає, “fitness improved”. З точки зору людини — тіло поламане дисбалансом.
Друга версія — augmented‑підхід. Система формує план тренування й пропонує його на затвердження. Людина дивиться, схвалює або коригує, і тільки потім “автоматичний тренажер” виконує програму вже без її участі.
В обох випадках важка робота автоматизована. Але в першому сценарії повністю зникає людське судження, а саме воно, наголошує Маркезе, інколи критично важливе. Те саме стосується й LLM‑систем: якщо дозволити їм безконтрольно правити скіли й базу знань, немає гарантій, що “покращення” не будуть однобокими або просто хибними.
Один скіл для всіх змін: improve system як центр самооптимізації
Щоб контролювати розвиток системи, Маркезе пропонує не розпорошуватися по десятках дрібних сценаріїв, а винести всю логіку самооптимізації в один скіл — improve system. Саме він аналізує нові дані, поведінку системи й пропонує зміни. Головна ідея: будь‑яке “покращення”, яке система збирається внести, має спершу пройти через категоризацію за трьома “кошиками”.
Через improve system проходить усе — від дрібних правок у wiki до створення нових скілів. Це дозволяє уніфікувати процес: немає хаотичних змін у різних місцях, усі ініціативи спочатку маркуються за рівнем ризику.
Сам скіл, за описом Маркезе, спроєктований так, щоб на виході завжди був структурований список пропозицій, уже розкладений по bucket‑ам. Далі питання лише в тому, як ви обходитесь з кожним із трьох типів змін.
Bucket 1: auto approve — дрібні правки й “сміття” без вашої участі
Перший кошик — auto approve. Сюди потрапляє те, що Маркезе прямо називає low‑risk: прибирання “жиру” у даних, усунення “data bloat”, додавання очевидних лінків між файлами, технічні або косметичні виправлення, які не змінюють суті процесів.
Усе, що потрапляє в цей bucket, Claude застосовує автоматично в рамках самого скіла improve system. Людина про ці зміни може навіть не знати: система просто вносить правки й паралельно веде change log. Якщо потрібно, до цього журналу можна повернутися й подивитися, що саме відбулося, але за замовчуванням він не вимагає уваги.
Таким чином повсякденна “гігієна” системи повністю віддана на відкуп AI. Ідея в тому, щоб звільнити людині час і ментальний ресурс: якщо правка настільки дрібна, що не несе ризику деградації якості, її краще взагалі не виносити на ручний ревʼю.
Bucket 2: need signoff — зміни, які можуть зламати якість
Другий кошик — need signoff. Це зона підвищеного ризику, яку Маркезе описує як “higher stake stuff”: редагування скіла, створення нового скіла, будь‑яка дія, де неправильне рішення здатне погіршити якість вихідних результатів.
Для таких змін використовується чітка процедура. Claude не застосовує їх одразу, а записує в окремий файл у директорії output/re з датою в назві. Усередині файлу кожна пропозиція оформлена як блок із чекбоксом і трьома можливими варіантами вибору: “схвалити”, “відхилити” або “схвалити й більше не питати”.
Саме останній варіант перетворює частину “високоризикових” змін на щось ближче до bucket 1. Якщо користувач кілька разів підтверджує один і той самий тип правок, систему можна навчити сприймати їх як безпечні та надалі виконувати без запиту. Таким чином межа між кошиками поступово зсувається в бік більшої автоматизації там, де вона дійсно виправдана.
Це ключовий елемент моделі Маркезе: не фіксована жорстка політика, а динамічна еволюція правил, яку все ж контролює людина.
Bucket 3: more context required — коли AI не вистачає інформації
Третій кошик — more context required. Сюди потрапляють ситуації, коли improve system щось проаналізував, бачить потенційну можливість покращення, але не може самостійно вирішити, що саме робити.
Маркезе описує цей bucket як “просто речі, де вам потрібно надати більше інформації”. Це не обов’язково високо ризикові зміни, радше ті, де бракує доменної експертизи або бізнес‑контексту, який не очевидний з даних.
Важливий нюанс: пропозиції з bucket 2 і bucket 3 об’єднуються в один і той самий файл для ревʼю. Тобто користувач отримує єдину точку входу для всіх змін, що потребують уваги — як для тих, що вимагають “так/ні”, так і для тих, де потрібно дописати контекст. Це зменшує фрикцію: замість того, щоб стрибати по різних місцях, достатньо періодично відкривати один документ і проходити його “чек-листом”.
Від повної автономії до тотального контролю: де зупинитися
Після опису трьох bucket‑ів Маркезе формулює ту саму “вісь рішень”, на якій і розташовується його модель.
На одному кінці спектра — повна автоматизація. Система сама себе змінює, усі пропозиції фактично еквівалентні auto approve. Це вимагає мінімум роботи від людини, але найбільше наражає на ризик дрейфу. Система може поступово “з’їхати” від вашого початкового бачення, і ви помітите це занадто пізно.
На іншому кінці — ревʼю кожної зміни. Ніщо не застосовується без людського схвалення. Такий підхід безпечний, але, як чесно визнає Маркезе, у реальній роботі він просто не життєздатний: надто багато ручних дій, які неминуче почнуть пропускатися.
Bucketing‑стратегія, яку він пропонує, свідомо займає середину. AI автоматично бере на себе “легкі” рішення — все, що вважається низькоризиковим. Людина залишає за собою “важкі” судження й розрулювання неоднозначних випадків. З часом, у міру накопичення досвіду, система може зміщувати дедалі більше типів змін з категорії “потрібен підпис” у “автоапрув”, але завжди через зрозумілий і контрольований процес.
Таким чином, самооптимізуюча система на Claude не перетворюється на “чорну скриньку”, що живе власним життям, але й не вимагає від розробника постійно сидіти над кожною дрібницею. Баланс — у чіткому розділенні відповідальності: AI займається рутинною гігієною, людина — стратегічними рішеннями.
Висновок: self‑improving як співпраця, а не заміна людини
Модель bucket‑ревʼю, яку описує Остін Маркезе, пропонує практичну відповідь на головний страх розробників і продактів: “А що, якщо система сама себе зламає?” Замість того щоб або повністю віддати кермо Claude, або ж завалити себе нескінченними ревʼю, він радить поставити один скіл improve system у центрі всієї еволюції й навчити його чітко сортувати зміни за рівнем ризику.
Самоооптимізація в його трактуванні — це не режим “AI замість людини”, а радше “AI плюс людина”, де модель бере на себе масу дрібних, але необхідних рішень, а людина зберігає право остаточного слова там, де на кону якість і сенс системи.
Для тих, хто будує складні LLM‑проєкти на базі Claude Code й побоюється дрейфу якості при автоматичному редагуванні скілів чи бази знань, цей підхід дає зрозумілий і відтворюваний фреймворк. Він не обіцяє магії, зате чітко окреслює, де саме варто залишати людину “в контурі” — і як при цьому не перетворитися на вузьке місце у власній самооптимізуючій системі.