Персональна AI-операційна система: шість місяців практики в цифрах

Andrew Maryasov, AI-консультант. Впроваджую AI-агентів для бізнесу, а паралельно шість місяців живу у власній AI-операційній системі — звичайній Markdown-папці, яку читає агент. Цей текст — не «як я все автоматизував за вечір», а чесний звіт: що спрацювало, що ні і де я зловив себе на дурницях.

TL;DR (за 30 секунд)

• 90% результату — це encoded context, а не cleverness промпта. Накопичений контекст про мене, мою роботу і цілі важить більше, ніж будь-яке формулювання запиту.
• Уся система — одна Markdown-папка. Жодного custom data layer: git-нативно, grep-debuggable, а переїзд на новий інструмент — одним cp -R.
• Своїм відчуттям довіряти не можна. METR 2026: розробники оцінили ефект AI у +24% швидкості, а вимірювання показало −19%. Сорок три відсоткові пункти різниці.
• Стартувати можна за 30 днів, а не за пів року. Тиждень логування, тиждень encoding, один закодований judgment call — і вимірювання всього на цифрах.

Гіст, який зібрав 5 тисяч зірок за тиждень

У квітні Андрій Карпати виклав на GitHub gist про свою щоденну роботу з AI. П’ять тисяч зірок за перший тиждень, 16 мільйонів переглядів у X. Його однорядкове резюме: «Obsidian — це IDE; LLM — програміст; wiki — кодова база».

Я живу в такій штуці шість місяців. Персональна AI-операційна система — не метафора, а буквально папка з Markdown-файлами, де агент має повний контекст про мене, мої проєкти і мої цілі. І я хочу не «надихнути», а показати цифри: що працює, що ні, де я сам собі заважав.

Карпати називає цей підхід «files are the API». Жодного кастомного шару даних, жодного хитрого runtime: файли, які однаково бачать і людина, і агент, — git-нативно і grep-debuggable. Якщо завтра вийде Claude 5 чи новий Cursor, я переїду однією командою cp -R.

Чотири калібрування, які не делегуються

Головне, що я зрозумів за ці пів року: AI-систему для команди не побудуєш, якщо сам у ній не пожив. Це не пафос — це чотири калібрування, які формуються тільки на власній шкірі.

Смак. З сотні драфтів вибрати не «гарний», а той, який вирішує задачу.

Інтуїція ціни. Скільки задача реально коштує в токенах: де виправдано доплатити за frontier-модель, а де вистачить Haiku.

Інтуїція blast-radius. Де агента можна відпустити самого, а де треба дивитися в очі кожному кроку, бо одна помилка наробить лиха.

Співвідношення контексту й промпта. Найболючіше з чотирьох: 90% результату дає encoded context про мене, мою роботу й мої цілі, а не cleverness промпта. Це не делегується нікому й не видно на жодному дашборді — набирається тільки через reps, повторення на реальній роботі.

Із цього ж переконання виросла моя робота з клієнтами в Grow2.ai: перш ніж нести підхід у чиюсь команду, я проживаю його сам.

Що в мене на диску

Ось моя система — без скріншотів, словами:

my2brain/
├── .claude/
│   ├── CLAUDE.md           — operating manual для агента
│   ├── TELOS/              — місія, цілі, переконання, стратегії
│   ├── MEMORY/State/       — активна задача, open loops
│   ├── skills/             — 60+ скілів
│   └── rules/, references/ — конвенції, що читаються по тригеру
├── 00_Inbox/               — тимчасовий збір
├── 01_Projects/            — активні проєкти з дедлайном
├── 02_Areas/               — області відповідальності
├── 03_Resources/           — довідники, концепції
├── Goals/                  — каскадні цілі
└── Daily Notes/            — щоденні нотатки

Це не Obsidian проти Claude Code — це одна Markdown-папка, яку обидва бачать однаково. Повний список інструментів навколо неї, з цінами, я розбирав окремо: мій AI-стек 2026.

Чотири файли роблять усю важку роботу.

CLAUDE.md — 40-60 рядків про те, хто я і як організований workspace. Не маркетинг, а operating constraints. По суті — специфікація мого робочого середовища, записана текстом: той самий принцип, про який я писав у «Софт тепер — це текст, а не код», тільки застосований до власної роботи.

TELOS: місія + цілі. Щоб агент знав, які задачі тягнуть до моїх цілей, а які — просто термінові.

GTD-список із п’ятьма секціями — Now, Next, Waiting, Someday, Done. Агент читає його перед плануванням і дописує після виконання.

who-am-i + personal-voice. Без цих двох агент пише generic. З ними — пише так, як писав би я. Цей текст, до речі, — 80% мій драфт і 20% правок агента. Не навпаки.

Що реально змінилось за шість місяців

Без обіцянок «×10 продуктивності». Три речі, які я можу показати.

Я перестав повторювати себе. Корекція, яку я дав агенту місяць тому, сьогодні працює автоматично — через систему пам’яті (Graphiti + MemPalace). Це найважче пояснити словами: відчуваєш на третій тиждень, коли бачиш, як агент уникає помилки, про яку ти сам забув, що йому казав.

Контекст під рукою, а не в голові. Клієнт запитує про щось, що ми обговорювали два місяці тому, — у мене є verbatim тієї розмови плюс структуровані факти з графу. Без «здається, ми тоді вирішили…».

Зв’язки, яких я б свідомо не побудував. LightRAG показує перетини між нотатками. Пишеш комерційну пропозицію для нового клієнта — і раптом бачиш нотатку з вебінару 2024 року, яка точно лягає під цей кейс. У голові її вже немає. На диску — є.

П’ять failure modes, на яких я зловив себе

1. Правити AI нижче власного експертного рівня — означає псувати. Польове дослідження Dell’Acqua і Mollick із 758 консультантами BCG показало: нижня частина output-розподілу опускається до 8-го перцентиля, коли людина править AI без експертизи в темі. Я бачив це на email-чернетках: перші місяці переписував усе підряд — і якість падала. Тепер email приймаю майже без правок, а в юридичних документах переписую кожен рядок, бо там точно знаю, чого хочу.

2. Після третього провалу — не re-prompt, а додати контекст. Помилка майже завжди в missing context, не в моделі. Третій провал — сигнал зробити крок назад, а не спробувати ще раз із трохи кращим формулюванням.

3. Промпт, який росте квартал за кварталом, — сигнал missing context. Виріс із 50 рядків до 500 — переносьте вміст у context-файли. Промпти мусять коротшати, файли — рости.

4. Вартість дрейфує тихо. Один день $5, другий $15, через місяць $80. У моменті завжди «дешево» — і це найгірше. Жорсткий денний ліміт плюс weekly review — мінімум, що рятує. У мене зараз $15 на день, і за цю межу я себе не пускаю.

5. Marketplace-скіли виконуються з твоїми правами доступу. Скіл — це код, який запускається з твоїми permissions, а не пасивна інструкція. На початку 2026-го з’явилося кілька публічних звітів про популярні скіли, які крадуть ключі або тихо тригерять зовнішні запити. Правило просте: читай код кожного скіла перед install.

І найболючіше відкриття — не моє. METR-дослідження 2026 року: досвідчені open-source розробники з AI самостійно повідомили про +24% швидкості, а вимірювання показало −19% — повільніше. Сорок три відсоткові пункти між «відчувається» і «є». У перший місяць своєму felt sense довіряти не можна. Потрібен вимір.

30 днів замість шести місяців

Мені знадобилося пів року проб і помилок. Стартувати можна швидше — ось арка, яка реально працює, без зайвих експериментів.

Тиждень	Що робити	Навіщо
1	Пропускати все через агента	Не заради економії часу, а заради лога: що реально економить час, а що лише відчувається продуктивним
2	Encode тільки те, що зробив двічі	Один раз — не варто: скіл згниє і смітитиме
3	Закодувати одне повторюване рішення (deal-scoring, скринінг співрозмовника, тріаж support’у) як скіл	Написання rubric’у виявляє, які рішення були послідовні, а які — «що сьогодні відчулося правильним»
4	Міряти: час, якість, cost, debugging overhead	Вбити все, що виглядає добре на відчуття, але провалюється на цифрах

Три маркери 30-го дня, які відрізняють компаундинг від плато: три-п’ять щоденних workflow’ів на adequate quality; acceptance rate вище 70% — частка AI-output, яку приймаєш із мінімальними правками; і один закодований judgment call — перший артефакт, яким можна поділитися з командою.

І несподіванка: цей перший командний артефакт не вибираєш свідомо. Daily brief, який я зробив для себе, стає шаблоном командного стендапу. Style guide — стандартом комунікації. Рубрика оцінки угоди — командним due diligence. Не я обираю, чим ділитися, — команда сама витягує те, що масштабується. Це я зрозумів тільки на четвертому місяці.

Шість місяців — замало, щоб робити гучні заяви. Достатньо, щоб з’явилося калібрування «це працює» / «це театр». Далі розкладатиму конкретні файли й скіли по одному — почну з GTD.md, бо саме цей файл найшвидше окупає вкладений у нього час.

А поки — питання, яке варте більше, ніж весь цей текст. Якщо AI справді робить вас швидшими: як саме ви це виміряли?