Американський підприємець і розробник Остін Маркізі будує власні self‑improving системи навколо Claude Code й детально документує цей процес на своєму YouTube‑каналі. В одному з останніх розборів він переходить від абстрактних «штук з ШІ» до дуже приземленої теми: як налаштувати реальні data pipelines — від історії сесій з Claude до листів з розсилок — так, щоб модель постійно жила на свіжих даних, а не на разовому дампі.
Йдеться не про класичну MLOps‑інфраструктуру, а про персональну «озерну» систему даних, яку можна зібрати силами одного інженера чи ноу‑код‑розробника. Центр цієї конструкції — skill‑driven data ingestion: кожен потік даних входить у систему лише через тестований скіл, який гарантовано обробляє raw‑контент так, як потрібно саме вам.
Від «озера» до «річок»: навіщо системі постійний інфлоу
Ключова метафора, яку використовує Маркізі, — «система як озеро». На попередньому кроці він заповнює це озеро історичними даними: імпортом старих сесій з AI, особистих файлів, електронної пошти й життєвої історії. Але без приток це озеро швидко «випарується» в практичному сенсі.
Він прямо порівнює: на етапі bulk‑upload ми «напоунили» озеро, а далі виникає проблема — якщо не буде нової води, це озеро перестане бути корисним. Тому наступний крок — inflow: створення data pipelines, які працюють як річки й постійно живлять систему новою інформацією.
Саме тут, за його словами, «ламаються 99% людей»: вони або зупиняються на разовому імпорті, або намагаються автоматизувати все без чіткого контролю того, як необроблені дані потрапляють усередину. Відповідь на цю проблему — skill driven data ingestion.
Суть підходу проста, але принципова. Кожен пайплайн у системі має входити через окремий скіл, який:
- чітко описує, як обробляти певний тип сирих даних;
- пройшов перевірку на реальних прикладах;
- працює однаково, незалежно від того, чи викликає його людина, чи рутина.
Тільки після цього поверх скілів будуються автоматичні improvement‑loops. Без надійних скілів автоматизація перетворюється на джерело хаосу.
Пайплайн 1: синхронізація історії сесій з Claude
Перший тип пайплайна, який Маркізі вважає базовим, — це власні AI‑взаємодії. Він називає це «your own inputs» і робить доволі жорстку заяву: немає кращого тренувального датасету, ніж ваша історія розмов з Claude.
Аргументація проста. Це буквально ваші питання, формулювання, задачі й спосіб мислення всередині терміналу. Якщо система претендує на те, щоб бути «другим мозком», то саме ці діалоги найточніше відображають, як ви мислите й що намагаєтеся будувати.
На етапі bulk‑ingest ця історія вже аналізувалася як разовий дамп. Однак для self‑improving системи цього мало: потрібна безперервна обробка нових сесій. Для цього вводиться окремий скіл — sync claude sessions.
За описом Маркізі, цей скіл виконує просту, але критичну функцію: бере історію минулих розмов, затягує їх у проєкт і інжестить у спеціальну папку для обробки. Після створення такого скіла він наполягає на практиці, яка проходить наскрізною лінією: кожен новий скіл потрібно реально прогнати на своїх даних і впевнитися, що він працює на конкретній машині, а не лише «на папері».
Таким чином, перший пайплайн перетворює короткострокові чати з LLM на довгостроковий навчальний матеріал для тієї ж самої системи.
Пайплайн 2: персональна екосистема — дзвінки, Slack, YouTube
Другий клас пайплайнів охоплює те, що Маркізі називає personal ecosystem data capture. Йдеться про всі місця, де ви регулярно залишаєте цифровий слід: дзвінки, робочі чати, публічний контент.
На власному прикладі він зводить це до трьох основних джерел: клієнтські та командні дзвінки, Slack‑повідомлення і YouTube‑відео.
Для дзвінків він орієнтується на Granola — інструмент, який записує зустрічі у фоновому режимі без окремого «AI‑бота» в дзвінку. Важливий для нього момент — відсутність відчуття вторгнення на стороні співрозмовників. Далі він використовує MCP‑інтеграцію Granola, щоб підтягувати повні транскрипти зустрічей і інжестити їх у свій проєкт як сирі ресурси.
Slack‑канал вирішується через пряме підключення: Claude отримує доступ до історії чатів і «claw» (як він висловлюється) цю історію, щоб витягти її в систему. YouTube‑відео він публікує з увімкненими транскриптами, щоб потім мати змогу посилатися не на «чернетки» ідей, а на фінальний опублікований продукт. Саме цей фінальний текст він і затягує до своєї бази знань.
Важливий принцип, який Маркізі підкреслює на цьому етапі, — не зациклюватися одразу на ідеальній інтеграції. Головне — переконатися, що контент стабільно десь зберігається: транскрипти дзвінків записуються, Slack‑історія не зникає, відео мають текстову версію. Якщо пряме API‑підключення поки що не налаштоване, це не критично: з часом його можна добудувати поверх уже накопичених сирих даних.
Для уніфікації цієї логіки вводиться ще один скіл — sync ecosystem data. Він, за задумом, проходиться по кожному зовнішньому джерелу, витягує лише нову інформацію й одразу ж обробляє її в структурованому вигляді всередині проєкту.
Пайплайн 3: curated‑контент через email‑аліаси
Третій пайплайн суттєво відрізняється від двох перших. Якщо там система працює поверх власного досвіду, то тут йдеться про curated‑контент ззовні: книжки, блоги, YouTube‑ролики. Маркізі виділяє один формат, який, на його думку, найкраще масштабується для будь‑якої ніші, — тематичні email‑розсилки.
Мотивація проста: майже в кожній спеціалізації вже є люди, які пишуть розгорнуті аналітичні листи з високою щільністю користі. І в кожного користувача вже є email — тобто не потрібно вигадувати новий канал.
Щоб не перетворити основну скриньку на смітник з розсилок, Маркізі пропонує використовувати email‑аліас. У прикладі з умовним «Brad» це виглядає як brad+newsletter@gmail.com, де частина +newsletter фактично створює фільтрований псевдонім. Під цей аліас підписуються на потрібні теми — наприклад, розсилки про AI‑практики — а далі система працює вже з окремим потоком листів.
Тут теж центр ваги — у скілі. У цьому випадку це sync curated content. Він підключається до alias‑інбоксу, витягує листи, видобуває з кожного ключові твердження й заносить це у wiki‑частину системи. Формат для email‑розсилок, але логіка та сама підходить і для інших джерел на кшталт блогів чи відео — достатньо змінити шар підключення.
Окремий акцент Маркізі робить на суворій селективності. Він попереджає, що спокуса «загнати туди все» лише шкодить: у такій системі «менше — це більше». Інгестити варто лише високосигнальні ресурси, які реально впливають на ваші рішення й вихідні артефакти. Інакше озеро даних перетворюється на болото.
Пайплайн 4: періодичні «дампи» досвіду наприкінці дня й тижня
Четвертий тип пайплайна повертає фокус до особистого досвіду, але вже не як разового «лайфсторі», а як регулярної практики. Маркізі описує її як periodic data dumps: наприкінці дня чи тижня він просто проговорює вголос уроки, які засвоїв, і тим самим вивантажує lived experience в Claude.
Технічно це виглядає як «rant into Claude code» за допомогою voice‑to‑text інструментів, які він згадує — Hex або Whisper Flow. Голос перетворюється на текст, а далі в гру вступає вже знайомий базовий скіл add new resource, налаштований ще на старті системи. Саме він відповідає за те, щоб будь‑який raw‑файл потрапив у RAW‑частину проєкту й був відреферений з wiki в потрібному контексті.
У підсумку четвертий пайплайн закриває ту частину інформації, яка зазвичай губиться: дрібні інсайти з робочого дня, невеликі зсуви в мисленні, швидкі висновки з помилок. У звичайному робочому циклі вони рідко оформлюються в документи, але в цій архітектурі стають повноцінними даними для навчання системи.
Skill‑оркестрація замість хаотичної інтеграції
Коли всі чотири пайплайни описані й реалізовані через скіли, Маркізі зводить їх разом одним рухом. Він показує єдиний промпт, який створює одразу три синхронізаційні скіли — для сесій Claude, персональної екосистеми та curated‑контенту — і тим самим формує «постійний потік» в data lake.
Цей рівень абстракції важливий, тому що далі самі скіли стають компонентами orchestration‑скілів і рутин. Маркізі послідовно тримає рамку: будь‑яка автоматизація має запускати вже перевірені скіли, а не безпосередньо чіпати сирі дані. Тоді оновлення логіки обробки відбувається централізовано — через редагування одного скіла, а не через переписування десятків окремих інтеграцій.
Результат такої конфігурації — система, яку реально можна назвати self‑improving: вона не просто зберігає статичну базу, а постійно й структуровано підживлюється новими шарами вашого досвіду, контенту й зовнішніх знань.
Висновок: self‑improving починається з дисципліни даних
На словах «self‑improving система» легко уявити собі магічний автономний ШІ, який «сам усе робить». У підході Маркізі магія приземляється на дуже конкретну дисципліну роботи з даними.
Поки «озеро» наповнюють вручну з випадкових джерел, система приречена старіти. Тільки тоді, коли для кожного ключового потоку — власні сесії, робочі інструменти, curated‑контент, щоденні рефлексії — створено окремий, перевірений скіл, можна безпечно вводити автоматизацію й очікувати, що алгоритм справді ставатиме розумнішим з кожним тижнем.
У результаті self‑improving виявляється не стільки про саму модель, скільки про інженерію інфлоу. Там, де більшість намагається будувати складні «лупи», Маркізі починає з простого: зробити так, щоб жодна важлива крапля інформації не проходила повз і завжди потрапляла в систему через чітко описаний, керований скіл.
Джерело
How to Build A Self-Improving System with Claude Code — Austin Marchese