Підприємець і розробник Остін Маркезе, відомий своїми практичними гайдами з побудови AI‑проєктів на базі Claude Code, пропонує п’ятиетапний фреймворк для створення «self‑improving» систем. Завершальний, п’ятий етап — DRIVE — взагалі майже не про інструменти. Це про мислення людини, яка керує вже побудованою системою. Саме тут вирішується, чи стане ваш Claude‑проєкт справжнім робочим «двигуном», чи залишиться ще одним «ідеальним, але мертвим» сетапом на GitHub.
«Run it. Don’t overengineer it»: навіщо взагалі потрібен окремий крок про мислення
Маркезе формулює п’ятий крок дуже жорстко: «Step five, drive. Run it. Don’t overengineer it. This step is the mindset you need to actually run the system you just built». Ідея проста: можна налаштувати базу знань, скіли, пайплайни, лупи покращень — і все одно зламати собі продуктивність, якщо ставитися до системи як до крихкого артефакту, а не як до інструмента, який має працювати під навантаженням і змінюватися разом із вами.
Саме тому він виділяє чотири конкретні принципи, без яких self‑improving‑архітектура перестає бути «self» і перетворюється на ще одну форму паралічу перфекціонізмом. Це не абстрактна мотивація, а практичні запобіжники від типових помилок продактів, фаундерів і соло‑розробників, які будують собі AI‑лупи й потім бояться ними користуватися.
Принцип №1: «Slow is smooth, smooth is fast» — чому не можна робити все одразу
Перший принцип він формулює максимально прямолінійно: «The first is slow is smooth, smooth is fast. Don’t try and do everything at once. Move slow, move methodical… Just go one step at a time and don’t be discouraged».
У контексті Claude‑системи це означає відмову від спокуси зібрати «ідеальний сетап» за один вечір. До цього моменту у фреймворку вже з’явилися:
- базова структура проєкту з knowledge base;
- скіли для типових операцій;
- пайплайни даних;
- improvement‑loop з bucket‑рев’ю.
На етапі DRIVE дуже легко вирішити «дотягнути» все до теоретично ідеального стану: відшліфувати кожен скіл, довести пайплайни до максимальної автоматизації, рознести по поличках усі папки. Маркезе пропонує радикально іншу стратегію: рухатися повільно, але послідовно, заходячи в експлуатацію проєкту вже зараз, а не після чергової «ревізії архітектури».
Це своєрідна відповідь на типове питання «чи не зарано це запускати?». У його логіці — навпаки, зарано майже ніколи не буває. Занадто рано буває лише переінженерення, коли замість реальних ітерацій людина тижнями полірує структуру raw‑папок або схемку в блокноті.
Принцип №2: «You’re the leader. The system serves you» — як не стати заручником власної архітектури
Другий принцип — про субординацію між людиною і системою: «Two is you’re the leader. The system serves you. If a piece of the system isn’t actively making you better, just get rid of it».
Це особливо болюче місце для фахівців, які люблять складні технічні конструкції. Як тільки з’являється достатньо скілів, пайплайнів і рутин, виникає спокуса ставитися до них як до чогось «священного»: якщо вже зроблено — треба берегти, підтримувати, рефакторити. Маркезе пропонує іншу норму: будь-який елемент, який не підсилює вас тут і зараз, — кандидат на видалення.
Він підкріплює це тезою: «If you added a skill and you don’t like it, just delete it. You don’t have to wait for someone’s permission to do something. Just do it». Для індивідуальних розробників та засновників це влучний удар по внутрішньому «change control board», який часто сидить у голові й блокує прості зміни.
У практичному сенсі це означає, що:
- не потрібно тримати «на майбутнє» скіли, якими ви не користуєтеся;
- не обов’язково підтримувати кожну вигадану папку чи pipeline, якщо вони не дають відчутної користі;
- система не має перетворюватися на музей ваших минулих рішень.
Цей підхід знімає невидимий психологічний борг: більше не потрібно «бути послідовним» заради послідовності. Курс задає користь для вас, а не краса схеми.
Принцип №3: «Compress your feedback loops» — чому не варто чекати, поки система «сама покращиться»
Третій принцип прямо пов’язаний із суттю self‑improving‑підходу: «Three, compress your feedback loops… Self-improving systems are valuable because they compress feedback loops. But the loops only learn if you’re actually using the tools».
Маркезе наголошує: навіть якщо у вас уже є автоматизовані improvement‑лупи, покладатися лише на «автопілот» — помилка. Він пропонує активну тактику: якщо якийсь скіл видав поганий результат, і ви вже пройшли з Claude кілька кроків, поки доводили відповідь до потрібного вигляду, не варто чекати, поки черговий запланований раунд оптимізації випадково зачепить цю проблему.
Конкретна порада звучить так: «If a skill didn’t work the way you wanted and you already went back and forth with Claude to actually fix the final output, just say based on this conversation, improve this skill». Іншими словами, кожен живий діалог із моделлю — це не тільки шлях до правильного разового результату, а й навчальний приклад для самої системи.
Тут закладена важлива інверсія: не «система покращує себе час від часу, коли я запускаю improve‑loop», а «я використовую кожен контакт із системою, аби притиснути петлю зворотного зв’язку до мінімуму». Такий підхід додає додаткову «вісь розвитку»: паралельно з регулярними автоматичними рев’ю працює мікрорівень постійного дрібного самонавчання.
Принцип №4: «It is not that serious. Bias to action» — війна з дрібним перфекціонізмом
Четвертий принцип спрямований проти ще однієї пастки — нескінченного обговорення незначних рішень: «Four, it is not that serious. Bias to action… People always ask me, ‘What tools should I use? Should I make it raw/inputs? Should I make it raw/ sessions folder? Should I run these things at 6:00 a.m. or 9:00 a.m.?’ The honest answer for any of those smaller things, it just doesn’t matter».
Ці питання знайомі будь-кому, хто запускав свій AI‑процес: дрібні нюанси структури папок, точний час запуску рутин, вибір між двома схожими тулінгами. На тлі всієї системи це деталі, але саме вони часто паралізують рух. Маркезе пропонує жорсткий критерій: єдиний справді неправильний вибір — це «overthinking it».
У його формулюванні: «AI is really good, so just use it and build things. These systems sharpen through reps, not whiteboard sessions». Ключові слова тут — «репи» проти «whiteboard». Система стає кращою через багаторазове застосування, а не через ідеально прорахований дизайн.
Він підкріплює цю установку цитатою засновника великої криптокомпанії: «One of my favorite quotes of all time is from Brian Armstrong… He said, ‘Action produces information.’… These systems sharpen through reps, not whiteboard sessions». Це не просто красивий слоган: у контексті self‑improving‑архітектури «дія як джерело інформації» означає, що кожен запуск скіла, кожна помилка, кожна корекція — це нові дані для того самого improvement‑loop, який ви вже заклали в систему.
Як це виглядає на практиці:
- не знаєте, чи потрібна окрема папка raw/sessions чи raw/inputs — оберіть будь‑який варіант і почніть працювати;
- не впевнені, коли краще запускати ingestion‑рутину — поставте будь-який час і подивіться, чи заважає це вам через тиждень;
- не можете вирішити між двома невеликими змінами в склі — реалізуйте одну й подивіться на результат.
У логіці Маркезе відповідь на більшість дрібних питань не можна отримати теоретично. Вона народжується тільки внаслідок декількох циклів «запустив — подивився — відкоригував».
Коли mindset важливіший за архітектуру
П’ятий крок DRIVE завершує технічний фреймворк на диво «немайстерно» з точки зору інженерії: жодних нових тулів чи складних схем. Натомість він змінює режим мислення: від уважного конструювання — до регулярної експлуатації і безжальної корекції.
У підсумку Маркезе зводить self‑improving‑систему до дуже простої формули:
- вона має працювати повільно, але стабільно, без спроб «охопити все відразу»;
- вона завжди залишається підконтрольною людині, а не навпаки;
- вона вчиться через стиснуті петлі зворотного зв’язку;
- вона еволюціонує завдяки діям, а не завдяки безкінечному проєктуванню.
Це не тільки порада для роботи з Claude Code. Це загальний рецепт, як не перетворити будь-яку AI‑ініціативу на вічний «pet project», що ніколи не виходить у реальну роботу. У цій логіці справжня «self‑improvement» починається не з фреймворку, а з готовності власника системи часто натискати кнопку «run», видаляти зайве і не боятися помилкових рішень, якщо вони прийняті в дії, а не на білих дошках.
Джерело
How to Build A Self-Improving System with Claude Code — Austin Marchese