У свіжому епізоді подкасту 20VC with Harry Stebbings гість ділиться доволі жорсткою, але послідовною позицією: справді сильні фахівці майже не потребують наставництва, регулярних one-on-one зустрічей і формальних performance-оглядів. Такий підхід контрастує з популярною культурою «турботливого менеджменту» в технологічних компаніях і ставить незручні запитання про те, як насправді працюють команди з «А-плеєрів».

Мінімум формальностей: як виглядає управління «сильними»

Ключова ідея проста: «дуже хороші люди знаходять спосіб» — вони самі розбираються з проблемами, вчаться на ходу і не потребують постійного супроводу.

Звідси випливають кілька управлінських практик:

• Жодних one-on-one: керівник свідомо не проводить регулярних індивідуальних зустрічей з прямими підлеглими.
• Без формальних рев’ю: немає циклічних performance-оглядів, які часто перетворюються на бюрократію.
• Зворотний зв’язок — тільки в реальному часі: якщо щось не так, людина дізнається про це одразу, через чат. Немає накопичення проблем до «квартального» чи «річного» обговорення.
• Похвала не є обов’язковою: якщо робота подобається, додаткове підтвердження нібито не потрібне — професіонал і так знає, що його поважають і цінують.

У центрі такого підходу — припущення, що сильні фахівці самостійні, внутрішньо мотивовані й не потребують «няньки» у вигляді менеджера.

Хто не вписується в модель «А-команди»

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

Логіка така:

• Ті, хто потребує багато розвитку, потребують і багато часу менеджера.
• Команда має складатися з «А-плеєрів», які цього не потребують.

Фактично, це відмова від ролі менеджера як «коуча для зростання» для широкого кола співробітників. Натомість робиться ставка на відбір людей, які вже працюють на високому рівні й здатні самі закривати свої прогалини.

Що означає такий підхід для культури в компанії

Подібна модель управління формує специфічну культуру:

• Висока автономія: очікується, що кожен сам організовує свою роботу, шукає рішення і не чекає інструкцій.
• Прямий, іноді жорсткий фідбек: помилки обговорюються миттєво й без «обгортки» у вигляді формальних процедур.
• Фокус на результаті, а не на процесі розвитку: важливі те, що людина робить зараз, а не те, як вона може вирости за рік за допомогою менеджера.

Це може бути привабливо для досвідчених фахівців, які цінують свободу і не хочуть витрачати час на формальні зустрічі. Водночас для тих, хто очікує структурованого менторства й кар’єрного супроводу, така культура може виявитися надто жорсткою.

Джерело

Good People Don’t Need Mentorship — 20VC with Harry Stebbings

Штучний інтелект, здатний знаходити вразливості в програмному забезпеченні, уже отримує ярлик «надто небезпечного для публічного доступу». Водночас риторика про «світовий кінець» від керівників найбільших AI-компаній підживлює рекордні настрої на Уолл-стріт. Відео Axios про модель Mythos слугує відправною точкою для розмови про те, чому інвестори в захваті, а звичайні користувачі — дедалі більш роздратовані.

Mythos: ШІ, який шукає дірки в безпеці

Mythos описують як модель штучного інтелекту, спеціально створену для виявлення вразливостей у програмному забезпеченні. Її головна функція — знаходити слабкі місця в коді, які можуть стати входом для хакерів або інструментом для кібератак.

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

Це піднімає одразу кілька питань:

• де проходить межа між корисним інструментом для кіберзахисту та зброєю;
• хто має контролювати доступ до таких моделей;
• як суспільству оцінювати ризики, якщо воно не може побачити технологію в дії.

Апокаліптичний наратив від AI-гігантів

Керівники найбільших компаній у сфері штучного інтелекту активно просувають ідею, що їхні технології — одночасно «неймовірні» й потенційно «світозмінні» в найтемнішому сенсі. У риториці з’являються порівняння з ядерною зброєю, причому з акцентом на тому, що ситуація може бути навіть небезпечнішою.

Один із ключових меседжів — ми нібито входимо в «офенсивно-домінантну» епоху, коли можливості для нападу значно випереджають можливості для захисту. У такій логіці:

• потужні моделі на кшталт Mythos можуть радикально посилити кіберзагрози;
• традиційні механізми контролю та регулювання виглядають запізнілими;
• суспільство має готуватися до якісно нового рівня ризиків.

Цей «думсдей»-наратив покликаний одночасно привернути увагу до небезпек і підкреслити унікальність технологій, які створюють великі гравці.

Розрив між Уолл-стріт і «Мейн-стріт»

Попри драматичні попередження, реакція різних аудиторій виявляється діаметрально протилежною.

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

• акції AI-компаній оновлюють історичні максимуми;
• штучний інтелект стає одним із головних драйверів фондових індексів;
• пенсійні накопичення (на кшталт американських 401(k)) опосередковано виграють від зростання AI-сектору.

Для пересічних користувачів — умовної «Мейн-стріт» — картина інша. Постійні розмови про «кінець світу», надто небезпечні моделі й загрози безпеці викликають радше втому й роздратування, ніж захоплення. Люди бачать:

• гучні обіцянки та страхи;
• відсутність прозорості щодо реальних ризиків;
• обмежений контроль над тим, як і де застосовують нові моделі.

У підсумку формується відчуття, що виграють насамперед інвестори й великі корпорації, тоді як ризики та невизначеність лягають на всіх.

Бум чи бульбашка?

На тлі цього контрасту постає головне питання: нинішній AI-сплеск — це стійкий технологічний бум чи спекулятивна бульбашка, яка ось-ось лусне?

Можливі сценарії, які окреслює дискусія навколо Mythos та подібних моделей:

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

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

Джерело

The “Scariest” AI model of the year 🤖⚠️ — Axios

Пошук першої роботи в ІТ часто впирається в замкнене коло: компаніям потрібен досвід, але щоб його здобути, треба спочатку десь попрацювати. Канал Marina Wyss – AI & Machine Learning пропонує іншу оптику: замість нескінченного конвеєра GitHub‑проєктів варто цілеспрямовано створювати собі реальний, «бойовий» досвід — навіть без формального працевлаштування.

Чому «просто будувати проєкти» — слабка стратегія

Типова порада для новачків у техніці — «роби більше проєктів». Люди слухають, пишуть код, викладають репозиторії на GitHub, додають їх у резюме — і все одно отримують тишу у відповідь.

Ключова причина — розрив між тим, що демонструють такі проєкти, і тим, що насправді шукає роботодавець.

Що хоче бачити найм менеджер:

• не просто «чи вміє людина писати код»;
• а чи здатна вона стабільно доставляти цінність бізнесу.

Код — лише частина картини. У реальній роботі важливіше:

• визначити правильну проблему й те, що взагалі варто будувати;
• працювати з «брудними» даними та неоднозначними вимогами;
• приймати компромісні рішення, коли немає очевидно правильного варіанту;
• довести рішення до продакшену й підтримувати його в робочому стані.

Типовий to‑do‑додаток або черговий pet‑проєкт, яким ніхто не користується, показує лише одне: людина може писати код «у вакуумі». Це не відповідає на головне запитання: чи зможе вона взяти реальну проблему й довести її до робочого результату для реальних користувачів.

Саме це й мається на увазі під «досвідом» у вакансіях — не обов’язково роки в компанії чи диплом, а доказ того, що ви вже проходили через реальну, «брудну» версію роботи.

Як перетворити проєкти на справжній досвід

Ключова ідея — змінити саме визначення «проєкту». Не «щось, що я написав для GitHub», а робота, яка має наслідки для реальних людей чи організацій.

1. Волонтерські й локальні ініціативи

Один із найпростіших способів створити собі досвід — знайти проблему в реальній організації й безкоштовно її вирішити.

Типові можливості:

• місцеві відділення Червоного Хреста;
• продовольчі банки;
• притулки для тварин;
• громадські центри та інші неприбуткові організації.

Більшість із них:

• працюють на застарілих інструментах;
• мають купу ручних, рутинних процесів;
• не мають бюджету на розробників і часто навіть не знають, що їхні проблеми можна автоматизувати.

Що можна зробити:

• автоматизувати перенесення даних між системами;
• побудувати простий data pipeline;
• створити внутрішній чат‑бот для відповідей на типові запитання;
• допомогти з прогнозуванням попиту, завантаження чи ресурсів.

Як це оформити:

• звернутися напряму: листом, повідомленням, особисто;
• чітко сказати, що ви волонтерите / працюєте безкоштовно;
• говорити мовою користі: «Я розробник, можу допомогти автоматизувати X / зекономити вам час на Y».

Якщо рішення реально використовується й економить, наприклад, 10 годин роботи на тиждень — це вже професійний досвід, який цілком коректно описувати в резюме як волонтерську позицію (data engineer, data analyst, software developer — залежно від задачі).

2. Допомога малому бізнесу та знайомим

Не обмежуйтеся неприбутковим сектором. Майже в кожному оточенні є:

• знайомі з невеликим бізнесом, які живуть у Google Sheets;
• репетитори чи тренери, які ведуть запис на заняття вручну або через месенджери;
• невеликі магазини, що рахують склад «на око» чи в зошиті.

Кожен із цих кейсів — шанс:

• запропонувати просту CRM;
• зробити систему бронювання;
• автоматизувати облік товарів;
• побудувати дашборд для базової аналітики.

Знову ж таки, ключ не в складності коду, а в тому, що:

• є реальний замовник;
• є конкретний біль;
• є вимірюваний ефект (час, помилки, зручність).

Від pet‑проєкту до продукту: робота з реальними користувачами

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

1. Нішеві інструменти замість абстрактних демо

Приклади напрямів:

• утиліта для гравців у Dungeons & Dragons;
• застосунок для бюджетування фрилансерів;
• трекер тренувань із функцією, якої бракує популярним аналогам.

Ключові кроки:

1. Обрати конкретну нішу й реальний біль (не «щось для всіх»).
2. Зібрати мінімальний функціонал, який вирішує цю проблему.
3. Вивести продукт до людей:
4. опублікувати в App Store / Google Play;
5. поділитися в тематичних сабреддітах;
6. запостити в профільних Discord‑спільнотах.

Як тільки з’являються реальні користувачі, ваш проєкт перестає бути «портфоліо» й стає продуктом. А це вже:

• продакшен‑досвід;
• робота з фідбеком;
• підтримка й розвиток системи.

2. Що починає відбуватися, коли з’являються користувачі

З моменту, коли люди починають користуватися вашим застосунком, ви стикаєтеся з тим самим, що й у компаніях:

• застосунок падає о 2‑й ночі — треба розбиратися з логами й моніторингом;
• користувачі просять нові фічі — доводиться пріоритезувати й казати «ні»;
• база даних не витримує навантаження — потрібна оптимізація;
• спливають edge cases, про які ви не думали — потрібні додаткові тести й переробка логіки.

Це і є той самий досвід, про який питають на співбесідах:

• як ви діагностували проблему;
• які компроміси обрали;
• як організували релізи й оновлення;
• як збирали й використовували фідбек.

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

Як це все перетворюється на ефективний нетворкінг

Багато хто знає, що «нетворкінг важливий», але сприймає його як незручні заходи й холодні повідомлення в LinkedIn. Підхід із реальними проєктами радикально змінює цю картину.

1. Нетворкінг як побічний ефект роботи

Коли ви:

• автоматизуєте процес у неприбутковій організації;
• будуєте інструмент для малого бізнесу знайомих;
• співпрацюєте з локальними ініціативами;

ви автоматично:

• знайомитеся з людьми, які бачать вашу роботу в дії;
• отримуєте теплі контакти, а не «холодні» звернення;
• маєте конкретні кейси, про які можна згадати в листах і на співбесідах.

Фраза на кшталт:

«Я побудував(ла) інструмент автоматизації для місцевого відділення Червоного Хреста, який щотижня економить їм N годин»

сприймається зовсім інакше, ніж:

«Я зробив(ла) to‑do‑додаток і виклав(ла) його на GitHub».

Люди, для яких ви зробили корисну річ:

• можуть дати рекомендації;
• познайомити з кимось у своїй мережі;
• згадати про вас, коли дізнаються про вакансію.

2. «Спочатку будуєш — нетворкінг приходить сам»

Замість того, щоб спершу «нетворкати», а потім шукати, що показати, цей підхід працює навпаки:

1. Ви робите реальну роботу для реальних людей.
2. Вони бачать результат і стають вашими природними «адвокатами».
3. Нетворкінг виникає як наслідок, а не як окрема, штучна активність.

Висновок: досвід можна не чекати — його можна створити

Сучасний ринок техспеціалістів жорсткий, і вимога «реального досвіду» нікуди не зникне. Але це не означає, що єдиний шлях — роками чекати першої офіційної позиції чи стажування.

Альтернатива:

• перестати будувати проєкти в ізоляції;
• шукати реальних людей і організації з конкретними проблемами;
• створювати продукти, якими хтось реально користується;
• дозволити нетворкінгу виникати як природний наслідок цієї роботи.

У підсумку в резюме з’являються не просто «репозиторії на GitHub», а історії про реальні задачі, реальні обмеження й реальну цінність — саме те, що хочуть бачити роботодавці.

Джерело

YouTube: Your Projects Won’t Get You Hired (Here’s What Will)

У новому гайді на YouTube продюсер контенту та офісних інструментів Джефф Су показує, як перетворити Claude Cowork з «розумного чату» на повноцінну операційну систему для роботи. Ключова ідея — організувати все як файлову структуру з правилами, пам’яттю та «робочими станціями», де кожна зона життя має власний контекст, а ШІ вміє наслідувати ваш стиль письма.

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

Три рівні замість одного чату: як організована Claude Cowork OS

Claude Cowork у цьому підході — не просто вікно діалогу, а система з чіткою файловою архітектурою. Вона побудована як трирівнева ієрархія, яка нагадує правову систему з конституцією, законами штатів і локальними правилами.

На верхньому рівні — корінь, або root. Це головна папка, яку автор називає Cowork OS (іноді жартома iClaude OS). У ній лежать два базові файли: claude.md та memory.md, а також папка «00 resources». Саме цей рівень задає універсальні правила поведінки для Claude Cowork, незалежно від того, чим ви займаєтеся — розсилаєте листи, плануєте подорож чи зводите витрати.

Другий рівень — робочі станції. Це підпапки всередині Cowork OS, кожна з яких відповідає за певну сферу: наприклад, Email HQ, Newsletter HQ чи Personal Finances. Кожна така станція має власні версії claude.md, memory.md та власну resources-папку. Їхні правила «накладаються» на кореневі, звужуючи й уточнюючи поведінку Claude під конкретну задачу.

Третій рівень — проєктні папки. Вони опціональні й живуть усередині конкретних робочих станцій. Це може бути, наприклад, окремий проєкт для певного воркшопу, великої поїздки чи серії виступів. Для спрощення налаштування автор зосереджується насамперед на перших двох рівнях, але логіка та сама: чим нижче рівень, тим більш специфічні правила.

У результаті виходить не хаотичний чат з ШІ, а структурована система, де кожен запит автоматично потрапляє в потрібний контекст.

Кореневий рівень: інструкції, пам’ять і ресурси «за запитом»

Серце всієї системи — root claude.md. Це не код, а звичайний текстовий файл, який виконує роль «конституції» для Claude Cowork. Кожна нова сесія починається з того, що Claude читає саме цей файл, а вже потім — інші.

У claude.md зафіксовано кілька ключових механік.

По-перше, правило пам’яті. У верхній частині файлу є інструкція: на початку кожної сесії прочитати memory.md перед тим, як відповідати. Далі йде ще одне правило: коли користувач каже «запам’ятай це» (або аналогічну фразу), Claude має записати відповідну інформацію в memory.md. Саме ці два речення перетворюють Cowork на систему з постійною пам’яттю, а не на «забудькуватий» чат.

По-друге, роутинг. У claude.md є секція routing map — таблиця, яка описує, яку робочу станцію слід підвантажувати для того чи іншого типу завдань. Коли ви просите розібрати кредитну виписку, система дивиться в цю карту й розуміє, що потрібно активувати, наприклад, папку Personal Finances. Якщо йдеться про листи, запит спрямовується в Email HQ. Таким чином, кореневий рівень виступає диспетчером, який автоматично відправляє запити в правильний контекст.

По-третє, посилання на ресурси. У claude.md є розділ references, де перераховані файли з папки «00 resources». Це можуть бути, наприклад, voice_principles.md або інші довідкові документи. Важливий момент: Claude не завантажує їх щоразу, а читає лише тоді, коли це прямо потрібно. Такий підхід зменшує витрати токенів і робить роботу системи ефективнішою.

Файл memory.md доповнює цю картину. Він складається щонайменше з двох секцій: «Active projects» та «Memory». У розділ «Memory» Claude автоматично додає записи, коли ви просите щось запам’ятати. У «Active projects» потрапляють поточні завдання та їхній прогрес. Пізніше можна почати нову сесію й поставити запитання на кшталт «що я казав про відволікання останнім часом?» — Claude прочитає memory.md і відтворить відповідь на основі попередніх записів.

Папка «00 resources» на кореневому рівні — це сховище довідкових матеріалів. Сюди поміщають voice_principles.md та інші документи, які не потрібні в кожній сесії, але критично важливі, коли йдеться про тон, стиль чи специфічні знання. Вони підвантажуються лише за потреби, що знову ж таки економить ресурси.

Робочі станції: універсальні проти спеціалізованих

Як тільки кореневий рівень налаштований, система починає розростатися за рахунок робочих станцій. Це окремі папки всередині Cowork OS, кожна з яких має власний claude.md, memory.md і resources. Їхні правила не замінюють кореневі, а «накладаються» поверх, звужуючи поведінку Claude до конкретної сфери.

Автор пропонує мислити робочими станціями як «областями життя». Вони бувають двох типів: універсальні та спеціалізовані.

Універсальні робочі станції обслуговують завдання, що перетинають багато сфер. Найочевидніший приклад — Email HQ. Листування стосується роботи з командою, бухгалтерією, партнерами, друзями. Правила того, як ви пишете листи, мають бути однаковими, незалежно від того, чи це фінанси, подорожі чи публічні виступи. Тому Email HQ — це універсальна станція, яка застосовується в різних контекстах, але з єдиним набором інструкцій щодо структури, тону та обробки пошти.

Спеціалізовані робочі станції відповідають за одну конкретну сферу. Наприклад, Personal Finances. Усередині неї зосереджені завдання, пов’язані з витратами, заощадженнями, податковими дедлайнами. Тут свій claude.md описує, як саме аналізувати виписки, як структурувати звіти, які категорії витрат важливі. Memory.md фіксує поточні фінансові проєкти та контекст, а resources може містити шаблони бюджетів чи довідкові документи.

Коли користувач просить, скажімо, «обробити минуломісячну кредитну виписку» або «порахувати, скільки пішло на підписки», роутинг-карта в кореневому claude.md спрямовує запит у Personal Finances. Там уже діють локальні правила, які уточнюють, як саме Claude має працювати з числами, категоріями витрат і форматами звітів.

Універсальні та спеціалізовані станції співіснують. Наприклад, лист, що стосується податкових питань, може використовувати як правила Email HQ (структура й тон листа), так і контекст Personal Finances (цифри, дедлайни, попередні рішення). Завдяки ієрархії й роутингу Claude Cowork не плутається, а комбінує потрібні шари правил.

Голос користувача як файл: як працює voice_principles.md

Окремий елемент цієї системи — файл voice_principles.md. Він зберігається в кореневій папці «00 resources» і описує те, як ви пишете: тон, структура, улюблені формулювання, ставлення до гумору, рівень формальності. Claude Cowork використовує цей файл, щоб генерувати тексти, які звучать максимально схоже на вас.

У claude.md є правило, яке в секції, присвяченій контенту, наказує перед створенням тексту прочитати voice_principles.md. Саме тому чернетка розсилки чи листа може перетворитися на фінальний текст, який виглядає так, ніби його писала та сама людина, що й попередні матеріали.

Побудова voice_principles.md відбувається автоматично. Якщо Claude Cowork підключений до Gmail через конектор, можна використати спеціальний промпт, який змушує систему проаналізувати останні 30 надісланих листів. На основі цих прикладів Claude витягує повторювані патерни: чи ви пишете тепло й прямо, чи уникаєте надмірної офіційності, як структуруєте абзаци, чи часто додаєте жарти. Усе це оформлюється у вигляді маркдаун-файлу з переліком принципів.

Якщо Gmail не підключений, є альтернативний шлях: взяти п’ять зразків текстів, які вам подобаються (це можуть бути ваші власні матеріали або чужі, стиль яких ви хочете наслідувати), вставити їх у Claude Cowork разом з іншим промптом і дати системі побудувати голос на цій основі. Механіка та сама: аналіз патернів і формування списку правил.

З часом voice_principles.md розростається. У автора цей файл перевищує 150 рядків. Це означає, що Claude накопичує дедалі більше нюансів: як ви звертаєтеся до читача, як пояснюєте складні речі, як реагуєте на помилки, які слова уникаєте. Кожне нове уточнення робить майбутні тексти ще ближчими до вашого реального стилю.

Важливо, що voice_principles.md не завантажується в кожній сесії автоматично. Він підтягується тоді, коли це потрібно для створення контенту. Такий підхід дозволяє зберігати детальний профіль голосу, не перевантажуючи кожну взаємодію зайвим контекстом.

Стартові шаблони: як запустити систему без програмування

Попри складність описаної логіки, технічно вся система побудована на звичайних текстових файлах у форматі Markdown. Автор підкреслює: це не код, а простий текст, який можна відкрити в будь-якому нотатнику. Щоб знизити поріг входу, він пропонує три готові шаблони: claude.md, memory.md і voice_principles.md, які повторюють його власну структуру.

Рекомендований порядок дій простий. Спочатку потрібно створити папку Cowork OS у файловій системі. Далі — завантажити шаблони у форматі Markdown, використовуючи опцію «Download → Markdown», щоб уникнути проблем із форматуванням. Після цього claude.md і memory.md слід помістити безпосередньо в кореневу папку Cowork OS, а voice_principles.md — у підпапку «00 resources», яку потрібно створити всередині кореня.

Потім у Claude Cowork потрібно вибрати цю папку як робочий каталог і дозволити системі завжди мати до неї доступ. Так Cowork отримує можливість читати й оновлювати файли claude.md, memory.md і voice_principles.md, а також будь-які майбутні робочі станції.

Для зручнішого перегляду файлів автор радить встановити безкоштовний застосунок Obsidian і відкрити Cowork OS як «vault». Це дозволяє бачити claude.md, memory.md і voice_principles.md у більш читабельному вигляді, без необхідності вивчати сам Obsidian чи його розширені функції. По суті, Obsidian тут виступає як зручний переглядач Markdown, а не як повноцінна база знань.

Завдяки шаблонам користувачеві не потрібно самостійно прописувати складні інструкції. Claude Cowork може навіть дописувати й розширювати ці файли сам, коли ви даєте йому відповідні вказівки. У підсумку налаштування системи зводиться до кількох кроків: створити папку, завантажити шаблони, розкласти їх по місцях і підключити до Claude.

Навіщо вся ця архітектура: контекст, що не губиться

Уся описана структура — від трирівневої ієрархії до voice_principles.md — служить одній меті: забезпечити релевантний контекст для кожного завдання без необхідності щоразу пояснювати ШІ, хто ви, над чим працюєте й як любите формулювати думки.

Кореневий рівень з claude.md і memory.md відповідає за загальні правила й довгострокову пам’ять. Робочі станції додають доменно-специфічні інструкції для пошти, фінансів, контенту чи інших сфер. Проєктні папки, якщо вони створені, дозволяють ще точніше налаштувати поведінку Claude під окремі ініціативи. Voice_principles.md гарантує, що всі тексти — від листів до розсилок — звучатимуть як продовження вашого власного стилю.

З технічного погляду це всього лише набір текстових файлів і папок. Але в поєднанні з механізмами роутингу й вибіркового завантаження ресурсів вони перетворюють Claude Cowork на щось значно більше, ніж чатбот: на персональну операційну систему, яка пам’ятає ваші проєкти, розуміє ваші пріоритети й говорить вашим голосом.

Джерело

https://www.youtube.com/watch?v=0_dSWLOHKng

Графічні процесори, створені колись для відеоігор, сьогодні стали ключовою інфраструктурою для генеративного штучного інтелекту. Відео від IBM Technology пояснює, чому саме GPU, а не традиційні CPU, лежать в основі сучасних LLM-моделей, і в яких випадках справді потрібні дорогі обчислювальні ресурси.

Чому апаратне забезпечення так само важливе, як і алгоритми

Успіх генеративного AI зазвичай пов’язують із проривами в алгоритмах — насамперед із появою трансформерної архітектури. Але без стрибка в апаратному забезпеченні ці моделі не могли б масштабуватися до нинішніх розмірів.

Типова аналогія — звичайний офісний ноутбук, який «падає» від Excel-файлу з тисячами рядків. У машинному навчанні масштаби інші: йдеться про обсяги даних і обчислень, достатні, щоб «покласти» десятки тисяч таких ноутбуків одночасно. Саме тут у гру входять GPU, які дозволяють тренувати й запускати моделі з сотнями мільярдів і навіть трильйонами параметрів.

Як влаштовані CPU та GPU: різні ролі в одному комп’ютері

Щоб зрозуміти, чому GPU краще підходять для AI, варто розібратися в базовій архітектурі чипів.

Будь-який процесор — CPU чи GPU — складається з десятків мільярдів транзисторів, згрупованих у блоки з різними функціями:

• Compute (обчислення) — виконання математичних операцій.
• Cache (кеш) — короткострокова пам’ять для «робочих» даних і інструкцій.
• Control (керування) — декодування інструкцій, планування й координація порядку виконання операцій.
• Memory (пам’ять) — зберігання вхідних даних і, у випадку AI, ваг моделі; важлива не лише ємність, а й пропускна здатність (швидкість доступу).

CPU: універсальний «диригент» для різнорідних задач

Центральні процесори проєктуються як загального призначення. Вони мають:

• відносно менший акцент на обчисленнях (менше паралельних математичних операцій),
• середній рівень кешу — достатній для типових задач,
• високий рівень контролю — складна логіка гілок, планування, перемикання між різними типами навантажень,
• обмежену власну пам’ять — зазвичай CPU використовує оперативну пам’ять системи, а не окремий великий пул на самому чипі.

Це робить CPU ідеальними для серверів, які одночасно обслуговують веб-сервіси, бази даних, аналітику та інші різнорідні задачі, але не оптимальними для масових однотипних обчислень.

GPU: спеціаліст із масового паралелізму

Графічні процесори створені для виконання великої кількості однакових операцій паралельно. Їхня архітектура інша:

• Високий рівень compute — багато математичних операцій одночасно.
• Середній кеш — достатній для підтримки масових обчислень.
• Менше контролю — менше складної логіки, оскільки більшість операцій однотипні.
• Високий обсяг і швидкість пам’яті (VRAM) — необхідні для зберігання великих масивів даних.

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

Від відеоігор до LLM: чому пам’ять GPU стала критичною

Історично GPU розроблялися для швидкого рендерингу графіки в іграх. Велика й швидка пам’ять була потрібна для:

• текстур,
• освітлення,
• тіней,
• фізичних ефектів.

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

• Одна з перших відкритих LLM — BERT (2018) — мала близько 110 млн параметрів.
• Сучасні моделі вже сягають понад трильйон параметрів.

Чим більше параметрів, тим більше пам’яті потрібно, і тим важливішою стає пропускна здатність пам’яті — швидкість, з якою процесор може читати й записувати ці дані. GPU поєднують у собі і великий обсяг VRAM, і високу швидкість доступу, що робить їх придатними для тренування й запуску таких моделей.

Фактично, без вимог індустрії відеоігор до графіки високої якості сучасні LLM могли б виглядати зовсім інакше — або бути значно меншими.

Чи завжди потрібен GPU для роботи з AI

Популярний міф: будь-який серйозний AI-проєкт вимагає власного «суперкомп’ютера» з десятками GPU. Насправді потреби залежать від типу задачі, розміру моделі та очікуваного навантаження.

Тренування моделей

• Тренування LLM майже завжди потребує GPU, незалежно від розміру моделі.
• Навіть відносно невеликі моделі під час навчання створюють значно більші навантаження, ніж під час простого запуску (інференсу).

Тюнінг (налаштування) моделей

• Великі моделі зазвичай вимагають GPU для тюнінгу.
• Малі моделі також зазвичай тюнінгують на GPU, але можливі винятки:
• дуже компактна модель,
• використання параметроефективних методів тюнінгу,
• застосування стиснених (compressed) моделей.

У таких поодиноких випадках тюнінг може бути здійсненний і на CPU, але це радше виняток, ніж правило.

Запуск (інференс) моделей

Тут усе гнучкіше й більше залежить від сценарію використання.

1. Особисті або внутрішні застосунки з низьким навантаженням
2. Один запит або невелика кількість запитів.
3. Невелика модель.

4. У таких умовах CPU може бути достатнім, особливо якщо швидкість відповіді не критична.

5. Особисті застосунки з великими моделями

6. Якщо модель має понад 10 млрд параметрів, навіть для персонального використання GPU зазвичай потрібен, щоб досягти прийнятної швидкості.

7. Клієнтські, публічні або масштабні застосунки

8. Орієнтовані на багатьох користувачів.
9. Виконують великі або численні задачі.
10. Для великих моделей GPU практично обов’язкові.
11. Навіть із меншими моделями GPU часто потрібні, щоб уникнути високої затримки (latency) при великій кількості запитів.

Ключовий висновок: не кожен AI-проєкт потребує дата-центру, заповненого GPU. Для багатьох сценаріїв достатньо CPU або обмеженої кількості графічних процесорів, особливо якщо йдеться про невеликі моделі й помірне навантаження.

Чому апаратна частина має значення для майбутнього AI

Розвиток генеративного AI — це не лише історія про нові архітектури моделей, а й про еволюцію чипів, пам’яті та обчислювальної інфраструктури. GPU стали критичною технологією завдяки поєднанню:

• масового паралелізму,
• великого обсягу та швидкості пам’яті,
• здатності ефективно працювати з однотипними математичними операціями у величезних масштабах.

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

Джерело

What is a Supercomputer for AI? How GPUs Drive Machine Learning — IBM Technology

У свіжому випуску технологічного шоу «УТ‑2» ведучі розбирають одну з найцікавіших і водночас найнебезпечніших фішингових атак останніх років — злам екосистеми безпеки Robinhood. Американський трейдинговий застосунок, який свого часу став символом «демократизації» доступу до біржі, виявився вразливим до витонченої схеми, де зловмисники використали і особливості Gmail, і помилки в обробці HTTP‑заголовків на боці самого сервісу.

Результат — користувачі отримували абсолютно легітимні, технічно «чисті» з погляду SPF та інших перевірок листи безпеки від Robinhood, але всередині цих листів на них чекав ідеально замаскований фішинг.

Від «демократизації» біржі до гейміфікованого беттінгу

Robinhood у США часто подають як історію успіху: застосунок, що зламав бар’єри входу на фондовий ринок, відкривши торгівлю акціями та деривативами для мільйонів роздрібних інвесторів. Відсутність комісій, простий інтерфейс, миттєва реєстрація — усе це зробило платформу привабливою для новачків, які раніше навіть не думали про біржу.

Але в цієї «демократизації» був і темний бік. Інтерфейс Robinhood, з його анімаціями, пушами, миттєвими підтвердженнями угод і легким доступом до маржинальної торгівлі, дедалі частіше порівнюють не з класичним брокером, а з казино. Торгівля перетворюється на гру, де користувачі натискають кнопки, не завжди усвідомлюючи ризики, а механіки гейміфікації підштовхують до частіших і ризикованіших операцій.

Цей підхід добре помічають і в інших фінтех‑екосистемах. Один із топ‑менеджерів бізнесу, схожого на індійський Paytm, свого часу називав Robinhood і Freedom Finance втраченими можливостями для запуску «беттінг‑стайл» продуктів. Логіка проста: якщо люди вже звикли сприймати торгівлю як гру, чому б не довести цю гру до кінця, додавши ще більше механік, притаманних ставкам і азартним іграм.

На цьому тлі стає ще тривожніше, коли виявляється, що платформа з мільйонами користувачів і гейміфікованим підходом до грошей має критичні діри в безпеці. Адже аудиторія, яку привчили до «легкої» торгівлі, часто менш підготовлена до складних атак, ніж професійні трейдери.

Gmail як зброя: як варіанти адреси відкрили двері атаки

Ключовим елементом схеми став спосіб, у який Gmail обробляє адреси електронної пошти. Для користувачів це зручно, для зловмисників — золота жила.

Gmail ігнорує крапки в локальній частині адреси. Тобто всі листи на адреси на кшталт ivan.petrenko@gmail.com, ivanpet.renko@gmail.com чи i.v.a.n.petrenko@gmail.com потрапляють в одну й ту саму скриньку. Додатково сервіс підтримує так звані плюс‑теги: усе, що після знака «+» до символу «@», Gmail відкидає. Наприклад, ivanpetrenko+trading@gmail.com і ivanpetrenko+spam@gmail.com теж приходять у ту ж саму поштову скриньку, що й базова адреса ivanpetrenko@gmail.com.

Зловмисники використали цю особливість як стартову точку атаки. Схема починалася з реєстрації нового акаунта Robinhood на варіант Gmail‑адреси жертви з крапками або плюс‑тегами. Для самого Robinhood це виглядало як абсолютно новий користувач з унікальною адресою. Для Gmail — як ще один варіант тієї ж поштової скриньки, якою реально користується жертва.

Таким чином, усі службові листи, пов’язані з новим акаунтом, потрапляли в ту ж саму пошту, де людина звикла отримувати справжні повідомлення від Robinhood. Це створювало ідеальне тло для подальшої маніпуляції: користувач бачив у себе в інбоксі легітимні листи від реального домену сервісу, підписані справжніми сертифікатами, з коректними SPF‑записами. На цьому фундаменті можна було будувати будь‑яку фішингову надбудову.

User‑Agent як троянський кінь: критична помилка в шаблоні листів

Другий, ще більш вражаючий компонент атаки — те, як Robinhood обробляв HTTP‑заголовок User‑Agent у своїх внутрішніх системах безпеки.

Коли користувач логіниться в застосунок або веб‑версію, клієнт надсилає на сервер низку заголовків, зокрема User‑Agent. У нормальній ситуації це просто текстовий рядок, який описує браузер, операційну систему та інші технічні деталі: наприклад, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7).... Ці дані часто використовують для логів, аналітики, іноді — для формування тексту службових сповіщень на кшталт «Ви увійшли з нового пристрою Chrome на macOS».

У випадку з Robinhood цей рядок потрапляв ще глибше — у HTML‑шаблон службових листів про безпеку. Сервери компанії вставляли сирий User‑Agent із запиту логіну без будь‑якого екранування прямо в HTML‑код листа. З погляду веб‑безпеки це класичний приклад того, як не можна робити: будь‑які дані, що надходять від клієнта, мають вважатися потенційно небезпечними і проходити фільтрацію або екранування перед тим, як потрапити в HTML.

Зловмисники це помітили й перетворили User‑Agent на троянського коня. Замість звичайного тексту вони почали надсилати в цьому заголовку фрагменти HTML‑коду. Оскільки сервер Robinhood бездумно підставляв отриманий рядок у шаблон листа, браузер одержувача інтерпретував його як частину розмітки.

У результаті легітимний лист безпеки, який реально відправляли сервери Robinhood, відображав не той текст, який задумали розробники, а підроблене повідомлення про «нерозпізнану активність» із яскравою кнопкою «Review activity». З погляду користувача все виглядало бездоганно: правильний відправник, правильний домен, коректні DKIM/DMARC/SPF, звичний дизайн листа — і тривожне попередження, що хтось щойно увійшов у його акаунт.

Це вже не класичний фішинг, де зловмисники намагаються підробити домен або дизайн. Тут сам сервіс, своїми ж руками, формував і розсилав шкідливий контент, просто тому, що довірився даним із клієнта.

Ідеальний фішинг: клонований сайт і справжні облікові дані

Кульмінацією атаки стала кнопка в листі, яка вела на клонований сайт Robinhood. Оскільки HTML‑код формувався з User‑Agent, зловмисники могли вказати будь‑який URL у атрибуті href. Вони створили сторінку, максимально схожу на офіційний сайт: логотип, кольори, верстка, форма логіну — все повторювало оригінал.

Користувач, який отримував такий лист, бачив повідомлення про «нерозпізнану активність» і логічну пропозицію «переглянути активність» або «підтвердити, що це були ви». Натискаючи кнопку, він потрапляв на фішинговий клон, але в умовах стресу й довіри до бренду рідко звертав увагу на дрібниці на кшталт точного написання домену в адресному рядку.

Далі все відбувалося за класичним сценарієм: користувач вводив свої справжні облікові дані — логін, пароль, можливо, навіть одноразові коди, якщо фішингова сторінка була достатньо продуманою. Зловмисники перехоплювали ці дані в реальному часі й могли або авторизуватися в акаунті жертви, або продати доступ на чорному ринку.

Особливо небезпечно те, що жертви були впевнені: вони взаємодіють із офіційним сервісом. Лист прийшов із правильного домену, пройшов SPF та інші перевірки автентичності, не потрапив у спам, а інтерфейс сторінки входу виглядав звично. Для багатьох користувачів це повний набір сигналів «усе гаразд».

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

Чому SPF і «зелений замок» більше не рятують

Один із найважливіших висновків із цієї історії — класичні маркери безпеки електронної пошти вже не гарантують захисту від складних атак.

Листи, які використовували зловмисники, проходили SPF та інші перевірки автентичності, оскільки надсилалися реальними серверами Robinhood. З погляду будь‑якого поштового провайдера це був еталонний трафік: домен збігається, IP‑адреси авторизовані, DKIM‑підпис валідний, DMARC‑політика дотримана. Немає жодних підстав маркувати такі повідомлення як підозрілі.

Це принципово відрізняє атаку від звичайного фішингу, де головна боротьба точиться навколо підроблених доменів і неавторизованих серверів розсилки. Тут проблема не в тому, що хтось «прикинувся» Robinhood, а в тому, що сам Robinhood став каналом доставки шкідливого контенту через власну вразливість.

Для користувачів це означає, що звичні поради «перевіряйте відправника» і «дивіться на зелений замок у браузері» вже не достатні. Якщо сервіс має XSS‑подібні діри у своїх листах або веб‑інтерфейсі, зловмисники можуть використовувати його інфраструктуру як таран проти власних клієнтів.

Для компаній висновок ще жорсткіший. Безпека — це не лише про шифрування, двофакторну автентифікацію чи складні паролі. Це також про банальну гігієну роботи з даними користувача: жоден рядок, що надходить із клієнта, не має потрапляти в HTML без екранування. Особливо якщо йдеться про шаблони листів безпеки, які користувачі сприймають як останню лінію оборони.

Висновки: коли UX, азарт і безпека сходяться в одній точці

Історія з фішинговою атакою на Robinhood показує, як кілька на перший погляд не пов’язаних факторів можуть скластися в ідеальну бурю.

По‑перше, гейміфікована природа застосунку, який перетворив торгівлю на щось дуже схоже на азартні ігри, притягує аудиторію, що не завжди має достатню кіберграмотність. Люди звикають натискати кнопки швидко, емоційно, не заглиблюючись у деталі.

По‑друге, технічні особливості інфраструктури — як‑от поведінка Gmail із крапками та плюс‑тегами в адресах — створюють неочевидні вектори атаки. Те, що для одного сервісу є просто зручністю, для іншого може стати критичною вразливістю, якщо він не враховує ці нюанси в моделі загроз.

По‑третє, базові помилки у веб‑безпеці, на кшталт вставляння сирого User‑Agent у HTML‑шаблон листа, перетворюють легітимну інфраструктуру на інструмент зловмисників. У такій конфігурації навіть найкращі системи автентифікації пошти не допомагають: вони лише підтверджують, що шкідливий лист справді прийшов від того, за кого себе видає.

Для ринку фінтеху це серйозний сигнал. Коли платформи, які вже межують із беттінгом за своєю поведінковою економікою, ще й виявляються вразливими до подібних атак, ризики для користувачів зростають у геометричній прогресії.

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

Джерело

Тім Кук на пенсію: 15 років без інновацій. Robinhood роздає гроші хакерам. mvc #26

Управління невеликою компанією часто означає бути одночасно маркетологом, бухгалтером, логістом і техпідтримкою. Засновниця британського сервісу оренди та повернення весільних квітів The Floral Hire розповідає в ролику OpenAI, як інтегрувала ChatGPT у щоденну роботу й фактично перетворила його на «третього члена команди».

Від ідеї до масштабування: де ШІ додає впевненості

The Floral Hire спеціалізується на оренді весільних композицій: арки, класична зелень, ніжно-рожеві відтінки, лілії — усе це їздить на події по всій Великій Британії, а потім повертається, обслуговується й готується до наступного весілля. Для засновниці, яка від початку мала ідеї, але через дислексію відчувала бар’єр у тому, щоб «перекласти» їх на папір, поява інструменту на кшталт ChatGPT стала наступним кроком після підтримки родини.

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

Стратегія зростання: аналіз варіантів і поради «пригальмувати»

Один із ключових сценаріїв використання ChatGPT у The Floral Hire — стратегічне планування. Бізнес, який уже працює по всій країні, розглядав вихід на європейський ринок і поставив перед собою питання: «Ми хочемо франшизу. З чого взагалі почати? Як перейти від поточного стану до присутності в Європі?».

ШІ допоміг розкласти це завдання на конкретні моделі:

• Франчайзинг — передача бренду й моделі роботи партнерам у різних країнах.
• Створення хабу в Європі — власний центр, з якого обслуговуються замовлення.
• Обслуговування Європи з Великої Британії — розширення логістики без фізичної присутності на континенті.

Для кожного варіанту ChatGPT сформував приблизний ціновий розклад: скільки може коштувати реалізація, які витрати варто очікувати й наскільки життєздатним є кожен сценарій. Важливий момент — інструмент не просто перелічив опції, а й запропонував утриматися від негайної експансії: спершу варто стати впізнаваним брендом на домашньому ринку, «домашнім ім’ям», а вже потім рухатися далі. Цю стратегію в компанії й обрали.

Таким чином, ШІ виконує роль аналітичного «третього ока», яке допомагає подивитися на бізнес не лише зсередини, а й з позиції довгострокової доцільності.

Від «не друкує принтер» до щоденних рішень

Ще один пласт застосування ChatGPT — вирішення дрібних, але критичних для щоденної роботи задач. У невеликій компанії немає окремого IT-відділу, і навіть банальна проблема на кшталт «принтер не друкує» може зупинити частину процесів.

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

ШІ як ментор і «додатковий співробітник»

У The Floral Hire ChatGPT описують як:

• «ментор» — джерело знань, яке допомагає розібратися в незнайомих темах;
• «третій член команди» — постійно доступний співрозмовник для перевірки ідей;
• «третє око в бізнесі» — інструмент, що пропонує інші ракурси й змушує подивитися на рішення під новим кутом.

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

Джерело

ChatGPT Helps Runs Small Business | The Floral Hire — OpenAI

Інженер Cursor Ерік Закаріассон працює на стику продукту й developer experience і відкрито говорить: повністю автономної «темної фабрики» ПЗ ще немає, але окремі її конвеєри вже працюють. Cursor, який кілька років тому стартував як «пікантний автодоповнювач» у VS Code, сьогодні перетворюється на середовище, де тисячі агентів паралельно пишуть, тестують і перевіряють код. Ключ до цього — не лише моделі, а й інфраструктура: ізольовані хмарні віртуальні машини, повноцінний віддалений UI‑інтерфейс Glass та автоматизовані петлі зворотного зв’язку навколо pull‑реквестів.

Ця стаття розбирає, як саме Cursor масштабує роботу агентів до рівня фабрики: від архітектури хмарних агентів до системи Bugbot, «agentic code owner» та автоматизацій, які вчать агентів на реальних помилках.

Від одного агента до тисяч: чому спільний dev‑env більше не працює

Поки більшість розробників живе в парадигмі «я + один AI‑пейр», Cursor уже щодня запускає «множинні тисячі» хмарних агентів на копіях свого основного репозиторію. Це не просто масштабування кількості запитів до LLM — це масштабування повноцінних робочих середовищ.

Класичний підхід до агентів у розробці виглядає так: є один dev‑environment — локальний або віддалений, — у ньому по черзі працюють люди й агенти. Поки агентів мало, це терпимо. Але щойно з’являється десяток чи сотня паралельних процесів, спільне середовище стає джерелом хаосу. Файлова система засмічується тимчасовими артефактами, конфігурації роз’їжджаються, залежності конфліктують, а відтворити конкретний збій стає майже неможливо.

Cursor відповідає на це радикально: оновлені хмарні агенти запускаються кожен у власній віртуальній машині. Замість того, щоб ділити один dev‑env, кожен агент отримує окремий, відтворюваний простір, де він може:

• розгорнути копію кодової бази;
• встановити залежності;
• запустити dev‑сервер;
• виконати тести;
• залишити артефакти для аналізу.

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

Ерік прямо рекомендує: коли мова заходить про «багато агентів», варто відмовитися від ідеї спільного dev‑середовища. Спільний простір неминуче «псується» — і для людей, і для моделей. Ізольовані хмарні VM перетворюють кожен агентський запуск на контрольований експеримент, а не на ще один крок у бік ентропії.

Відтворювані середовища як основа фабрики ПЗ

Ізольована VM — лише контейнер. Справжня цінність з’являється тоді, коли всередині неї можна швидко й надійно відтворити робоче середовище. Cursor будує хмарних агентів так, щоб кожен із них умів самостійно підняти повноцінний dev‑env у хмарі.

Це означає, що агент не просто читає код і генерує патчі. Він:

• клонує або отримує копію репозиторію;
• орієнтується в структурі проєкту;
• знаходить стандартні точки входу, на кшталт package.json із start‑скриптом;
• запускає сервер розробки;
• виконує тести, включно з end‑to‑end, якщо вони є.

У демонстраційному музичному проєкті з інтерфейсом на кшталт Ableton агент самостійно читає package.json, знаходить start‑скрипт і піднімає локальний сервер на localhost:3000. Це показовий приклад того, що Ерік називає «бути в дистрибуції моделей»: якщо проєкт дотримується поширених патернів (типові скрипти, стандартні структури), агентам набагато легше його зрозуміти й запустити.

Відтворюваність середовища тут критична. Якщо кожен агентський запуск — це окрема VM з однаковим способом старту, можна:

• паралельно запускати тисячі агентів без конфліктів;
• відтворювати будь-який сценарій, який привів до бага;
• будувати на цьому автоматизовані конвеєри, де агенти не просто пишуть код, а й самі його тестують.

Фактично, Cursor перетворює «запуск агента» на аналог CI‑джоби, але з набагато ширшим діапазоном дій: від рефакторингу до UI‑регресії.

Glass: повноцінний віддалений комп’ютер під контролем агентів

Навіть добре налаштовані тести не завжди покривають поведінку інтерфейсу. Особливо, коли йдеться про складні UI‑взаємодії: анімації, лоадери, drag‑and‑drop, гарячі клавіші. Для людини очевидно, чи «відчувається» інтерфейс правильно. Для агента, який бачить лише DOM і API, це вже складніше.

Щоб скоротити цей розрив, Cursor дає хмарним агентам доступ до повноцінного віддаленого комп’ютерного інтерфейсу під назвою Glass. Це не абстрактний headless‑браузер, а керований агентом «десктоп», де він може:

• відкривати застосунок або веб‑інтерфейс;
• клікати по елементах;
• вводити текст;
• взаємодіяти з UI так, як це робить людина.

Ключова деталь — Glass уміє записувати відео цих сесій. У результаті кожен автономний прогін агента може залишати не лише логи й результати тестів, а й візуальний артефакт: як саме агент клікав, що бачив, як поводився інтерфейс.

Це вирішує одразу кілька проблем.

По‑перше, верифікація змін. Якщо агент вніс правки в UI, запустив застосунок у Glass і «проклікав» сценарій, команда отримує відео, де видно, чи справді кнопка тепер працює, чи з’явився лоадер, чи не зламався флоу.

По‑друге, дебаг поведінки агентів. Коли агент «робить щось дивне» у UI, це важко зрозуміти лише з текстових логів. Відеозапис взаємодії в Glass дозволяє побачити, де саме він «заблукав»: не впізнав кнопку, неправильно інтерпретував стан, зациклиться на кроці.

По‑третє, це ще один рівень автоматизованої перевірки. У поєднанні з unit‑, інтеграційними та e2e‑тестами Glass додає шар «людиноподібної» взаємодії, яку можна запускати масово й паралельно, не залучаючи реальних користувачів.

У музичному проєкті, який Ерік зібрав повністю через агентів, UI‑перевірки виконуються за допомогою Playwright‑тестів: агенти перевіряють, чи працює кнопка Play, чи можна редагувати ноти. Glass розширює цей підхід до повноцінного віддаленого комп’ютера, де агент може не лише запускати тести, а й самостійно «програвати» сценарії.

Автоматизований рев’ю‑конвеєр: Bugbot і «agentic code owner»

Якщо агенти пишуть і тестують код у тисячах ізольованих середовищ, наступне вузьке місце — рев’ю. Людський час обмежений, а фабрика ПЗ втрачає сенс, якщо кожен дрібний PR блокується на ручному перегляді.

Cursor будує навколо цього окремий автоматизований конвеєр. Один із його елементів — Bugbot, внутрішній інструмент, який переглядає GitHub‑pull‑реквести й повертає фідбек. Bugbot виступає як перший фільтр якості: аналізує зміни, шукає потенційні проблеми, формує коментарі.

Але справжня інженерія починається далі — з системи, яку в Cursor називають «agentic code owner». Вона поєднує ідею класичних code owners із агентською автономією.

Система оцінює ризик кожного PR. Якщо зміни невеликі, локалізовані й не торкаються критичних ділянок, PR може бути автоматично затверджений без участі людини. Це дозволяє пропускати через фабрику велику кількість низькоризикових змін, не перевантажуючи команду рев’ю.

Якщо ж PR зачіпає складні або чутливі частини кодової бази, «agentic code owner» маршрутизує його до конкретних людей — тих, хто раніше редагував відповідні файли. Це важливий нюанс: замість абстрактного «хтось із команди має подивитися», система знаходить найрелевантнішого експерта за історією комітів.

У підсумку виходить багаторівневий конвеєр:

• агенти генерують зміни в ізольованих VM, тестують їх і формують PR;
• Bugbot робить первинний автоматизований рев’ю;
• «agentic code owner» оцінює ризик і або автоапрувить PR, або відправляє його на таргетований людський перегляд.

Це не «темна фабрика» в чистому вигляді — люди залишаються в ланцюгу для високоризикових змін. Але для великого класу задач рев’ю вже перетворюється на автоматизований сервіс, а не на вузьке місце.

Особисті автоматизації: як агенти беруть на себе статус‑трекінг і навчання

Фабрика ПЗ у Cursor — це не лише про кодову базу компанії. Ерік активно використовує ті самі механізми для власної роботи, фактично делегуючи агентам частину особистого менеджменту.

Один із прикладів — щоденний огляд активності. Автоматизація в Cursor збирає інформацію з Slack і GitHub, підсумовує, над чим він працював, які PR створював або переглядав, які обговорення вів. Агент формує з цього дайджест, який замінює ручне ведення статус‑нотаток. Це звільняє когнітивний ресурс: замість того, щоб згадувати, що саме робив учора, можна просто прочитати зведення.

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

Це підводить до ще одного важливого елемента фабрики — «continue learning»‑автоматизації. Cursor регулярно проглядає минулі транскрипти роботи агентів, шукає в них місця, де люди виправляли помилки або уточнювали інструкції, і перетворює ці корекції на нові правила. Фактично, кожен промах агента стає сировиною для покращення:

• агент зробив щось неправильно;
• людина втрутилася, пояснила, як треба;
• автоматизація витягла цю корекцію;
• на її основі сформовано нове правило або уточнення;
• наступні агенти вже стартують із урахуванням цього досвіду.

Це замкнений цикл: виконання → фідбек → екстракція знань → оновлення правил → нове виконання. На відміну від класичного ML‑тренування, тут не потрібно чекати великого релізу моделі — поведінка агентів еволюціонує разом із кодовою базою й процесами команди.

Від правил до середовищ: як усе це замикається в одну систему

Усі описані елементи — ізольовані VM, Glass, Bugbot, «agentic code owner», особисті автоматизації — працюють лише в поєднанні з більш базовими речами, про які Ерік говорить окремо: структурою кодової бази, правилами для агентів і можливістю верифікувати їхню роботу.

Cursor використовує файл agents.md у репозиторії як джерело правил для агентів. Це не статичний набір директив, а живий документ, який еволюціонує разом із проєктом. Ерік підкреслює: правила краще додавати реактивно, коли агенти «з’їжджають з рейок», а не намагатися встановити всі можливі з колекції Cursor Directory наперед. У цьому сенсі «continue learning»‑автоматизація — просто систематизація того, що й так відбувається в зрілих командах: помилки перетворюються на політики.

Не менш важливе питання — середовище, в якому агенти працюють. Якщо проєкт не можна запустити однією командою, якщо немає стандартних скриптів, якщо тести відсутні або ненадійні, жодна кількість агентів і VM не перетворить його на фабрику. Саме тому в демонстраційному музичному проєкті так багато уваги приділено стандартним патернам: package.json із start‑скриптом, Playwright‑тести, зрозуміла структура.

На цьому тлі Glass і хмарні VM виглядають не як «магія», а як логічне продовження: якщо код структурований, середовище відтворюване, а правила чіткі, агенти можуть не лише писати й тестувати код, а й самостійно запускати повноцінні UI‑сценарії, залишаючи відео й логи для людей і наступних агентів.

Висновок: фабрика ПЗ вже працює — але як набір конвеєрів

Cursor ще не живе в світі повністю «темної фабрики», де люди лише задають наміри, а агенти невидимо будують і розгортають системи. Але окремі конвеєри вже функціонують: тисячі хмарних агентів щодня працюють у копіях основного репозиторію, тестують свої зміни в ізольованих VM, взаємодіють із UI через Glass, проходять через Bugbot і «agentic code owner», а їхні помилки перетворюються на нові правила через автоматизовані петлі навчання.

Ключовий урок із цього досвіду — фабрика ПЗ починається не з моделі, а з інфраструктури й процесів. Ізольовані середовища, відтворювані dev‑конфігурації, стандартизовані патерни запуску, автоматизовані рев’ю й систематичне перетворення людського фідбеку на правила — усе це робить можливим світ, де один розробник може керувати не одним агентом‑пейрінгом, а цілим парком агентів, що працюють паралельно.

Для команд, які сьогодні лише експериментують із AI‑помічниками, досвід Cursor дає орієнтир: шлях від «спеційного автодоповнювача» до фабрики лежить через ізоляцію, верифікацію й замкнені цикли навчання. Агенти вже вміють писати код. Завдання інженерів — побудувати для них правильний завод.

Джерело

YouTube: Building your own software factory — Eric Zakariasson, Cursor

Розробник Claude Code Борис Черні демонструє доволі нетиповий підхід до автоматизації: замість сотень «розумних» сценаріїв — кілька ретельно відібраних інструментів, які працюють постійно й без його участі. Автор каналу Austin Marchese розібрав інтерв’ю, треди та конфігурації Черні й показав, як саме організована ця система — і як відтворити її у власній роботі.

«Внутрішній цикл»: що взагалі варто автоматизувати

Ключова ідея — автоматизувати не все підряд, а лише те, що справді повторюється й дає відчутний виграш.

Черні використовує простий «inner loop»-тест, перш ніж перетворити дію на skill (умовну «слеш-команду» у Claude Code):

1. Ви робите це 2–3 рази на тиждень або частіше.
2. Дія завжди йде за одним і тим самим шаблоном.
3. Попередній контекст (налаштування, інструкції, структура) реально допомагає.

Якщо відповідь «так» на всі три пункти — це кандидат на skill. Якщо ні — краще залишити як разовий промпт.

Цей фільтр дозволяє уникнути двох крайнощів:

• Взагалі не створювати skills і щодня переписувати одні й ті самі промпти.
• Створювати skills на все, перетворюючи робочий простір на хаотичний каталог команд, більшість з яких ніхто не використовує.

За публічною інформацією, у Черні задокументовано лише близько семи skills — але кожен із них «заробив» своє місце частотою використання й чіткістю задачі.

Приклад: /commit-push- як еталон корисного skill

Один із найуживаніших skills Черні — /commit-push-. Він:

• комітить код;
• пушить його на GitHub;
• створює pull request.

Це добре визначений, вузький сценарій із прозорою назвою. Саме такі skills дозволяють підтримувати високий темп роботи: Черні говорить про 10–30 pull request’ів на день, повністю згенерованих Claude Code без ручного редагування.

Інші його skills — запуск тестів, пошук багів у коді, прибирання після сесії. Усі вони проходять той самий фільтр: регулярні, шаблонні, з вигодою від попереднього контексту.

Практичний стартовий крок для будь-кого: попросити Claude Code проаналізувати історію сесій і виявити повторювані задачі, які варто перетворити на skills.

Як «розкрутити» skills: агенти, hooks, loops і розклад

Навіть корисні skills часто залишаються недовикористаними: користувачі забувають про них або не встигають запускати в потрібний момент. Черні вирішує це за допомогою чотирьох механізмів: агенти, hooks, loops, schedule.

Агенти: «співробітники», які знають, коли що запускати

Агент у Claude Code — це роль, яка:

• знає, які skills існують;
• розуміє, коли їх застосувати;
• працює як експерт у вузькій сфері.

Skills — це «як робити», агент — «коли й навіщо робити».

У Черні шість агентів, кожен із яких має одну чітку функцію. Показовий приклад — «staff reviewer»: скептичний «старший інженер», який:

• оцінює план роботи;
• виносить вердикт: «approve», «request changes» або «needs to rethink»;
• нічого не будує сам, лише рецензує.

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

Базовий шаблон для створення агента:

• визначити роль («хто це?»),
• контекст («у чому експерт?»),
• кут огляду («з якого боку оцінює роботу?»),
• формат фідбеку (прямий, структурований, з вердиктом).

Hooks: автоматичні тригери всередині Claude Code

Hooks — це події, які автоматично запускають дію, коли в Claude Code щось відбувається. Користувач не вводить промпт — все працює у фоні.

У Черні є щонайменше три типи hooks:

1. Post tool use
   Спрацьовує після використання інструменту.
   Приклад: якщо Claude записав щось у файл через write, автоматично запускається автоформатер коду. Це «останній 10%» роботи — чистове доведення до стандарту.

2. Stop
   Спрацьовує, коли Claude «зупиняється» після діалогу.
   Налаштований так, щоб примусово продовжувати роботу, якщо завдання ще не завершене. Умовно — автоматична відповідь «так, продовжуй, працюй далі».

3. Session start
   Запускається при старті нової сесії.
   Використовується для автоматичного завантаження контексту — потрібних файлів, інструкцій, знань — ще до першого запиту користувача.

Hooks можна застосовувати не лише для продуктивності, а й для накопичення знань. Наприклад:

• створити папку /knowledge із тренувальними даними;
• налаштувати post-tool hook на подію write;
• якщо новий файл з’явився в /knowledge, автоматично запускати skill ingest source, який правильно індексує й «заливає» його в систему.

У результаті робочий простір поступово «розумнішає» сам по собі, без додаткових ручних кроків.

Loops і schedule: найпотужніші, але недооцінені функції

Черні прямо називає loop і schedule двома найпотужнішими можливостями Claude Code — і водночас тими, якими майже ніхто не користується.

• Loop (/loop) — запускає skill через певний інтервал часу в межах конкретної сесії.
  Наприклад: /loop 5 minutes /bsit — кожні 5 хвилин Claude перевіряє, чи є щось, що потребує уваги.

• Schedule (/schedule) — схожий на cron: запускає skill у заданий час або за розкладом, але вже в хмарі, поза локальним проєктом.

Це дозволяє будувати постійно працюючі системи. Один із прикладів:

• skill /buildpartner:improve system за розкладом:
• переглядає проєкт;
• пропонує покращення;
• готує зміни, які можна вмерджити.

У поєднанні з агентами й hooks це перетворює Claude Code на напівавтономну інфраструктуру, де skills працюють не лише «за запитом», а й за ініціативою самої системи.

Менше — краще: як уникнути «боргу за skills»

Найпарадоксальніший висновок із підходу Черні — не варто будувати забагато skills.

Кожен skill — це:

• логіка, яку потрібно підтримувати;
• інструкції, які старіють разом зі зміною робочого процесу;
• потенційні конфлікти з іншими skills.

Це створює те, що можна назвати «боргом за skills»: що більше їх у системі, то більше часу йде на оновлення, чистку та виправлення.

Черні постійно видаляє й переписує свої інструменти. За його словами, у Claude Code немає частин, які б залишалися незмінними шість місяців: усе регулярно оновлюється.

Практичний висновок:

• питання не в тому, скільки skills можна створити;
• питання в тому, скільки з них ви реально здатні підтримувати.

Для більшості користувачів це 5–10 добре зроблених skills, а не 50.

Skills як інструменти, а не інструкції

Ще один важливий зсув мислення: skills варто сприймати не як «команди для Claude», а як інструменти, якими Claude може користуватися сам.

Приклад Черні — skill /commit:

• він запускає його вручну;
• але модель також може викликати його самостійно, коли це логічно.

Це дозволяє ділити логіку між людиною й моделлю: один і той самий skill працює і як ручний інструмент, і як автоматичний крок у складнішому сценарії.

Корисний підхід до ревізії:

1. Переглянути всі skills.
2. Позначити ті, що:
3. не оновлювалися понад місяць;
4. дублюють або суперечать іншим;
5. легко замінюються одноразовим промптом.
6. Для тих, що залишаються:
7. переписати їх так, щоб Claude міг сам викликати їх у потрібний момент, без ручного тригера.

Так skills перетворюються з набору «інструкцій для моделі» на повноцінний набір інструментів, які масштабують вашу роботу.

Висновок: система без зайвого шуму

Підхід Бориса Черні до Claude Code можна звести до кількох принципів:

• Чіткий фільтр частоти: skill лише для того, що трапляється регулярно й за шаблоном.
• Одна роль — одна задача: як для skills, так і для агентів.
• Hooks, loops і schedule використовуються, щоб вичавити максимум із кожного skill, а не створювати нові.
• Skills — це інструменти, якими можуть користуватися і людина, і модель, а не просто заскриптовані промпти.
• Постійна чистка й переписування замість накопичення «мертвих» автоматизацій.

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

Джерело

YouTube: How Claude Code’s Creator ACTUALLY Automates his work

У світі агентів на кшталт Claude чи Cursor під капотом усе частіше працює протокол MCP (Model Context Protocol), який з’єднує AI‑клієнтів із десятками корпоративних сервісів — від Figma до Notion. Але разом із цим приходять нескінченні OAuth‑консенти, довгоживучі токени й «сліпі зони» для IT‑відділів.

Про те, як це змінює новий підхід Cross-App Access (XAA) на базі специфікації Identity JWT Authorization Grant (ID‑JAG), розповідає Ґаррет Ґалоу, керівник продукту в WorkOS. Він понад десять років будував enterprise‑платформи для розробників у Microsoft Azure та Cloudflare, а нині WorkOS забезпечує автентифікацію для Anthropic, Cursor, OpenAI та інших, роблячи додатки й AI‑агентів «enterprise‑ready».

Ця стаття зосереджена на безпеці, адмініструванні та підтримці екосистемою Cross-App Access: як працюють короткоживучі токени, як централізовано відкликати доступ, що можуть налаштувати IT‑адміни в IdP, які вендори вже підтримують XAA і що потрібно MCP‑клієнтам та серверам, аби вписатися в цю модель.

Короткоживучі токени як базовий запобіжник

Класичний OAuth у зв’язці з MCP створює знайому картину: користувачі постійно проходять через consent‑екрани, а в результаті на локальних машинах накопичуються довгоживучі access і refresh токени до чутливих сервісів. Якщо обліковий запис або пристрій скомпрометовано, такі токени можуть залишатися дійсними днями чи навіть тижнями, а IT‑відділ часто не має прямого способу побачити й відкликати їх усі.

Cross-App Access пропонує іншу модель життєвого циклу токенів. У ній MCP‑сервер (наприклад, Figma) видає access‑токени, які навмисно робляться дуже короткоживучими — орієнтовно близько п’яти хвилин. Це не випадковий параметр, а свідоме обмеження «blast radius» у разі компрометації.

Якщо зловмисник отримає такий токен, часовий горизонт його корисності мінімальний. Навіть без додаткових дій з боку адміністратора, через кілька хвилин цей токен просто перестане працювати. На відміну від традиційних сценаріїв із refresh‑токенами, які можуть «жити» місяцями, тут кожен access‑токен — це тимчасовий пропуск, який швидко втрачає силу.

Важливий нюанс: для самого користувача це не означає, що йому доведеться логінитися кожні п’ять хвилин. Короткий строк життя стосується лише токенів доступу до конкретних MCP‑серверів. Під капотом XAA використовує активну SSO‑сесію в Identity Provider (IdP), щоб без участі користувача постійно оновлювати ці короткі токени.

Як одна SSO‑сесія живить безліч MCP‑токенів

У моделі Cross-App Access організаційний Identity Provider — наприклад, Okta — стає посередником довіри між MCP‑клієнтом (Claude, Cursor) і MCP‑сервером (Figma). Обидва додатки вже довіряють IdP для SSO, і XAA використовує цю довіру, щоб автоматично видавати токени доступу без додаткових consent‑екранів.

Після того як користувач один раз проходить SSO‑логін у IdP, MCP‑клієнт отримує від IdP ID‑токен і refresh‑токен. Далі вступає в гру специфікація Identity JWT Authorization Grant (ID‑JAG). Вона дозволяє клієнту звернутися до IdP з цими обліковими даними й отримати спеціальний ID‑JAG‑токен, який можна обміняти на access‑токен у MCP‑сервері.

Ключовий момент: поки SSO‑сесія в IdP активна, MCP‑клієнт може повторювати цей цикл скільки завгодно разів — отримувати нові ID‑JAG‑токени й обмінювати їх на свіжі короткоживучі access‑токени до різних MCP‑серверів. І все це без будь-якої додаткової взаємодії з користувачем.

З точки зору UX це виглядає як «магія»: користувач один раз увійшов через Okta, а Figma‑сервер у Claude чи Cursor уже «сам по собі» підключений, без жодного нового вікна з дозволами. З точки зору безпеки це означає, що:

• довготривалою сутністю стає лише SSO‑сесія в IdP, яка вже контролюється корпоративною політикою;
• усі доступи до MCP‑серверів похідні від цієї сесії й реалізуються через короткі токени, що постійно оновлюються.

Така архітектура переносить центр ваги з локально збережених OAuth‑токенів на керовану IdP‑сесію, яку IT‑відділ може контролювати й відкликати.

Централізоване відкликання доступу: коли IdP стає єдиною точкою правди

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

У традиційній MCP‑моделі на базі OAuth, навіть якщо IT‑відділ виявив компрометацію пристрою чи облікового запису й розлогінив користувача з Okta або Microsoft Entra, на локальній машині могли залишатися дійсні access і refresh‑токени до Figma, Notion та інших сервісів. Вони не були безпосередньо прив’язані до поточного стану SSO‑сесії, і IdP не мав повного огляду, де й які токени ще живуть.

У Cross-App Access усе інакше. Сценарій виглядає так:

поки SSO‑сесія в IdP активна, MCP‑клієнт може продовжувати отримувати ID‑JAG‑токени й обмінювати їх на короткі access‑токени до MCP‑серверів. Це забезпечує безперервну роботу агентів без повторних логінів.

якщо ж IdP‑сесію відкликано — наприклад, користувач звільнився, пристрій скомпрометовано або IT‑відділ примусово завершив усі сесії — MCP‑клієнт більше не може отримувати нові ID‑JAG‑токени.

після того як поточний короткоживучий access‑токен (ті самі приблизно п’ять хвилин) спливає, клієнт втрачає можливість звертатися до MCP‑сервера. Жодних довгоживучих «залишкових» прав не лишається.

Таким чином, IdP стає єдиною точкою правди щодо того, чи має агент право діяти від імені користувача. Якщо доступ у IdP втрачено, доступ до всіх пов’язаних MCP‑серверів автоматично «висихає» після закінчення короткого строку дії останнього токена.

Для IT‑команд це означає:

• немає потреби вручну шукати й відкликати розрізнені токени в кожному окремому сервісі;
• ризик «забути» про якийсь локальний credential суттєво знижується;
• політики безпеки (наприклад, обов’язковий re‑auth раз на день чи тиждень) реалізуються на рівні IdP й автоматично поширюються на всі MCP‑інтеграції.

Автентифікація, а не авторизація: чого XAA поки що не робить

Попри те що Cross-App Access суттєво змінює спосіб, у який MCP‑клієнти отримують доступ до серверів, важливо розуміти обмеження поточної реалізації. XAA, як вона описана зараз, фокусується на автентифікації, а не на зміні моделі авторизації в самих додатках на кшталт Figma.

Коли Figma виступає MCP‑сервером і приймає ID‑JAG‑токен, вона, по суті, підтверджує: «Це той самий користувач, якого я знаю з Okta, і він має доступ до мого застосунку». Після цього Figma видає звичайний OAuth‑access‑токен, і далі діють ті самі права, які користувач має у Figma як додатку.

XAA не вводить нових, більш дрібних scope‑ів чи окремих «агентських» ролей. Поточна специфікація ID‑JAG не визначає scoped або reduced‑permission grants для cross‑app доступу. Це означає, що відносини доступу залишаються на рівні «повний доступ додатку від імені користувача», а не «обмежений набір дій, дозволених лише агенту».

Практичний наслідок:

• якщо користувач у Figma має право читати й редагувати певні файли, агент, який діє через XAA, матиме ті самі можливості;
• XAA не дозволяє, наприклад, видати Claude лише «read‑only» доступ до Figma, якщо сама Figma не підтримує таку модель ролей на своєму боці.

Інакше кажучи, Cross-App Access сьогодні вирішує проблему «хто ти і чи маєш ти право зайти», але не додає нових механізмів «що саме тобі дозволено робити всередині додатку». Для більш тонкого контролю прав усе ще потрібні зміни в самих MCP‑серверах і, потенційно, подальша еволюція ID‑JAG.

ID‑JAG як універсальний міст між OIDC і SAML

Ще один важливий аспект Cross-App Access — сумісність із різними типами корпоративних SSO‑налаштувань. У реальному світі організації використовують як OIDC, так і SAML‑провайдерів, і XAA має працювати поверх обох моделей.

Специфікація ID‑JAG тут відіграє ключову роль. Вона дозволяє клієнту подати до IdP один із кількох типів облікових даних, щоб отримати ID‑JAG‑токен:

• refresh‑токен;
• ID‑токен;
• SAML‑assertion.

Це означає, що незалежно від того, чи організація використовує OIDC‑підключення, чи SAML‑федерацію, той самий базовий XAA‑флоу може працювати поверх наявної інфраструктури. Для MCP‑клієнта важливо лише, щоб його SSO‑з’єднання було XAA‑сумісним і могло запитувати та обробляти ID‑JAG‑токени.

На практиці це знімає з розробників агентів необхідність підтримувати окремі, несумісні механізми для різних IdP. ID‑JAG виступає уніфікованим шаром, який абстрагує різницю між OIDC і SAML, але при цьому зберігає можливість використовувати обидва типи підключень.

Як IT‑адміни керують XAA: політики в IdP

Cross-App Access не лише змінює технічний флоу токенів, а й переносить важливу частину контролю в руки IT‑адміністраторів, які керують IdP. Саме вони визначають, які додатки можуть запитувати доступ одне до одного.

У випадку з Okta це виглядає як політика, яка явно описує, що, наприклад, Cursor має право запитувати доступ до Figma. Адміністратор конфігурує в IdP зв’язок між двома застосунками:

• «додаток‑клієнт» (MCP‑клієнт, такий як Cursor або Claude);
• «додаток‑ресурс» (MCP‑сервер, наприклад Figma).

Коли MCP‑клієнт звертається до IdP по ID‑JAG‑токен, IdP перевіряє не лише особу користувача, а й те, чи дозволена така cross‑app взаємодія політиками. Okta може перевірити, що користувач є членом обох застосунків і що політика дозволяє видачу токенів для цієї пари «клієнт–ресурс».

Це дає IT‑відділам кілька важливих важелів:

• вони можуть дозволяти або блокувати конкретні зв’язки між агентами й сервісами;
• можуть бути впевнені, що навіть якщо користувач спробує підключити «небажаний» агент до чутливого сервісу, IdP просто не видасть ID‑JAG‑токен;
• мають централізований огляд того, які додатки в принципі можуть взаємодіяти через XAA.

На відміну від поточної MCP‑реальності, де користувач може локально додати будь-який MCP‑сервер або клієнт, минаючи IdP, XAA повертає контроль у корпоративний perimeter: без відповідної політики в IdP cross‑app доступ просто не відбудеться.

Підтримка вендорів: Okta попереду, Entra — в очікуванні

Успіх будь-якої нової моделі автентифікації залежить від того, наскільки швидко її підхоплюють ключові гравці ринку Identity. На момент виступу Ґаррета Ґалоу картина виглядає так.

Okta вже підтримує Cross-App Access для OIDC‑підключень. Це означає, що організації, які використовують Okta як IdP і мають OIDC‑інтеграції з додатками на кшталт Cursor, Claude або Figma, можуть почати впроваджувати XAA без фундаментальної перебудови SSO‑інфраструктури. Okta також планує додати підтримку XAA для SAML‑підключень, що розширить охоплення на ті організації, де історично домінує саме SAML.

Microsoft Entra (колишній Azure AD) на цей момент Cross-App Access ще не підтримує. Для величезної кількості підприємств, які покладаються на Entra як основний IdP, це означає, що XAA поки що залишається перспективною, але недоступною опцією. Поки Entra не реалізує підтримку ID‑JAG або аналогічного флоу, агенти в таких середовищах будуть змушені працювати через традиційні OAuth‑моделі з усіма їхніми обмеженнями.

Ця асиметрія створює цікавий ландшафт: компанії на Okta можуть експериментувати з новою моделлю доступу для MCP‑агентів уже зараз, тоді як екосистема навколо Entra, ймовірно, чекатиме офіційної підтримки з боку Microsoft.

Що потрібно MCP‑клієнтам і серверам, щоб увійти в XAA‑екосистему

Cross-App Access — це не лише про IdP. Щоб модель запрацювала, і MCP‑клієнти, і MCP‑сервери мають навчитися працювати з ID‑JAG‑токенами й новим флоу.

Для MCP‑клієнтів ключові вимоги такі. По-перше, їхні SSO‑підключення мають бути XAA‑сумісними, тобто вміти запитувати ID‑JAG‑токени в IdP, використовуючи refresh‑токени, ID‑токени або SAML‑assertions. По-друге, клієнти повинні реалізувати логіку обміну ID‑JAG‑токена на короткоживучий access‑токен у MCP‑сервері й оновлювати його по мірі спливу строку дії.

WorkOS уже реалізував підтримку отримання ID‑JAG‑токенів і виконання цього обміну від імені MCP‑клієнтів, які використовують WorkOS для SSO. Це означає, що розробники агентів, інтегрованих із WorkOS, можуть делегувати складну частину XAA‑флоу інфраструктурному провайдеру, а не будувати її самостійно.

Cursor і Anthropic (Claude) якраз належать до таких клієнтів: вони використовують WorkOS для своїх SSO‑з’єднань і покладаються на WorkOS для XAA‑пов’язаних потоків. Для кінцевого користувача це проявляється у вигляді «одного логіну» через корпоративний IdP і автоматично підключених MCP‑серверів без додаткових consent‑екранів.

На боці MCP‑серверів вимоги інші. Вони мають навчитися приймати новий тип JWT‑bearer‑токена, який представляє ID‑JAG‑токен. Авторизаційний компонент сервера повинен уміти:

• перевірити цей ID‑JAG‑токен у IdP;
• переконатися, що токен дійсний і відповідає очікуваному клієнту й користувачу;
• після валідації видати стандартний OAuth‑access‑токен для подальшого спілкування MCP‑клієнта з API.

Важливо, що з точки зору самого MCP‑протоколу на останньому етапі нічого не змінюється: клієнт і сервер продовжують працювати зі звичайним OAuth‑access‑токеном. Уся «магія» XAA відбувається до того, як цей токен з’являється, у взаємодії між клієнтом, IdP і авторизаційним сервером MCP‑додатку.

Висновок: безпека й контроль без втрати зручності

Cross-App Access на базі ID‑JAG пропонує відповідь на одразу кілька болючих питань, які виникли, коли MCP‑агенти почали масово підключатися до корпоративних сервісів. Короткоживучі access‑токени обмежують наслідки потенційної компрометації. Активна SSO‑сесія в IdP стає єдиним довготривалим «якорем» доступу, який IT‑відділ може централізовано відкликати.

Адміністратори отримують можливість явно визначати, які додатки можуть запитувати доступ одне до одного, а ID‑JAG забезпечує єдиний флоу поверх як OIDC, так і SAML. Водночас важливо усвідомлювати межі поточної моделі: XAA сьогодні вирішує задачу автентифікації й делегування довіри між додатками, але не вводить нових, більш дрібних рівнів авторизації всередині самих сервісів.

Підтримка з боку Okta й реалізація XAA‑флоу у WorkOS означають, що для частини ринку ця модель вже не теоретична, а практична. Для решти, зокрема екосистеми Microsoft Entra, це поки що вектор розвитку. Але загальний напрямок очевидний: у світі, де AI‑агенти стають повноцінними учасниками корпоративної інфраструктури, контроль доступу має повертатися до Identity Provider, а не розпорошуватися по десятках локальних токенів.

Джерело

One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

У короткому фільмі-пародії «LLMento» від Confluent Developer, стилізованому під «Memento» Крістофера Нолана, головний герой — ReAct‑агент Віктор — розслідує падіння «вартості для акціонерів». За сюжетом ховається дуже приземлена й знайома інженерам історія: як обхід правил сумісності схем у Kafka та сліпа довіра до LLM можуть зламати критичний стрімінговий пайплайн.

Коли пайплайн «прокидається» вже зламаним

Герой опиняється в ситуації, знайомій будь‑якому інженеру підтримки: ти «прокидаєшся» в системі, яка вже працює — або, точніше, вже зламана.

Є Iceberg‑таблиця, є пайплайн, є схема. Таблиця порожня, але існує. Продажі відбувалися, події пішли в Kafka — «immutable, in order» — але дані не доходять до таблиці. На поверхні це виглядає як «drop in shareholders’ value», але технічна причина — у споживачі.

Споживач Kafka намагається читати події, очікуючи одні типи даних (integers), а отримує інші (strings). Десеріалізація ламається, консьюмер падає, і ланцюжок доставки цінності обривається. Дані є, але бізнес їх не бачить.

Схемний реєстр як запобіжник — і як його обійшли

Ключ до розгадки — у тому, як працює Schema Registry. У типовій архітектурі саме API реєстру схеми виконує перевірку сумісності перед тим, як прийняти нову версію:

• backward compatible
• forward compatible
• усе це конфігурується й виступає «guardrail» — запобіжником проти руйнівних змін.

Якщо нова схема несумісна з уже розгорнутими споживачами, API не дасть її зареєструвати. Це той самий рівень захисту, який мав би не допустити ситуації, коли консьюмер очікує цілі числа, а отримує рядки.

У фільмі з’являється «лиходій» на ім’я Clawy — уособлення шкідливого патерну. Він не вимикає запобіжник, а просто обходить його: замість використання API Schema Registry напряму записує схему в службову тему _schemas.

Технічно це працює: схема з’являється в реєстрі, все «виглядає нормально». Але саме в API живе логіка перевірки сумісності. Обійшовши API, Clawy обійшов і всі правила. Результат — продакшн‑пайплайн із несумісною схемою, що валить споживачів.

LLM як порадник без правил: небезпека «найшвидшого шляху»

Особливий акцент зроблено на ролі великої мовної моделі. Clawy «запитав LLM про найшвидший спосіб зареєструвати схему» — і отримав відповідь: писати безпосередньо в _schemas topic.

З технічної точки зору це може бути коректною, але надто низькорівневою порадою. З точки зору продакшн‑практик — це шлях без жодних правил і перевірок. LLM показала маршрут, де немає guardrails, а інженер (чи агент) просто пішов ним.

Цей сюжет підсвічує кілька важливих моментів:

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

Пам’ять, стейт і сенс дій AI‑агентів

Фільм обігрує ще одну важливу тему — «stateless mind» агента. ReAct‑агент Віктор щоразу наче прокидається в новій реальності пайплайна, не пам’ятаючи попередніх кроків. Він змушений покладатися на зовнішні «дзеркала» — артефакти системи, схеми, таблиці, логи — щоб зрозуміти, що сталося і хто винен.

Це художній, але показовий образ для сучасних AI‑агентів:

• без надійного стану та історії дій агент не може оцінити наслідки власних кроків;
• без прозорих правил (як‑от перевірка сумісності схем) агент легко «ламає» систему, навіть не усвідомлюючи цього;
• інженерам потрібні «дзеркала» — спостережуваність, аудит, логування — щоб відстежувати, що роблять як люди, так і агенти.

Фінальна фраза героя про те, що «ми всі потребуємо дзеркал, щоб пам’ятати, хто ми», у технічному контексті читається як нагадування: складні стрімінгові системи та AI‑агенти потребують не лише потужних інструментів, а й дисципліни, правил і прозорості.

Висновок: guardrails важливіші за «хитрі шляхи»

Пародія на «Memento» перетворює досить суху тему — сумісність схем у Kafka та роботу зі Schema Registry — на історію про пам’ять, відповідальність і наслідки. Головний технічний меседж простий:

• використовуйте офіційні API, а не обхідні шляхи;
• не вимикайте й не обходьте перевірки сумісності схем;
• сприймайте поради LLM критично, особливо коли йдеться про продакшн‑інфраструктуру;
• будуйте системи так, щоб і люди, і агенти мали чіткі межі та «дзеркала» для своїх дій.

У світі, де AI‑агенти дедалі частіше взаємодіють із реальними продакшн‑системами, один «швидкий хак» може коштувати дуже дорого — і для пайплайна, і для «shareholder value».

Source

If Memento was about AI Agents — Confluent Developer

Phil Hetzel, керівник напрямку solutions engineering у Braintrust і колишній лідер глобального підрозділу Databricks у Slalom Consulting, останні роки працює на стику enterprise‑аналітики та генеративного AI. Braintrust позиціонує себе як платформу якості агентів, що зосереджена на двох стовпах — evals та observability. У центрі їхнього підходу — доволі радикальна теза: вимірювання якості агентів до й після продакшену — це не про красивий інтерфейс, а про важку інженерію даних для гігантських, напівструктурованих трейсів.

Цей погляд змушує по‑новому подивитися на те, як мають виглядати платформи для роботи з AI‑агентами, і чому багато «простих» рішень на кшталт Postgres‑таблиці чи кастомного DSL швидко впираються в стелю.

Evals до релізу, observability після: одна й та сама задача під капотом

Braintrust формулює свою місію максимально вузько: це не загальна MLOps‑платформа і не ще один «playground» для LLM, а саме платформа якості агентів. У цій рамці evals і observability — два боки однієї медалі.

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

Observability — це продовження тієї ж роботи, але вже після релізу. Агент живе у продакшені, обробляє реальний трафік, і завдання команди — зберегти й перевіряти ту саму впевненість: чи поводиться система так, як очікували під час розробки, чи не деградує якість, чи не з’являються нові класи помилок.

Ключовий момент у тому, що Braintrust не розділяє ці два світи на рівні інфраструктури. З їхнього погляду, і evals, і observability — це одна й та сама системна задача: збір, зберігання, індексація й аналіз великих трейсів агентів.

Саме так з’явилася їхня нинішня архітектура. Три роки тому Braintrust стартував як платформа лише для evals. Observability з’явилося пізніше — не як окремий продукт, а як еволюція. Один із клієнтів просто почав прокачувати весь продакшен‑трафік через систему evals і безперервно ганяти оцінки поверх реальних запитів. Це фактично перетворило eval‑платформу на систему спостереження за агентом у бойових умовах.

Звідси й стратегічний висновок: якщо клієнти все одно намагаються звести evals і observability в один контур, платформа має бути спроєктована як єдина дата‑система, а не як два різні продукти, зшиті API.

Внутрішній flywheel: як продакшен‑трафік підживлює офлайн‑evals

У Braintrust для цього є власний термін — «flywheel». Йдеться про замкнений цикл, у якому дані з продакшен‑observability безперервно підживлюють офлайн‑evals, а результати evals, у свою чергу, впливають на поведінку агента в продакшені.

У спрощеному вигляді цей цикл виглядає так. Агент працює з реальними користувачами, кожна взаємодія породжує трейс: промпти, відповіді, виклики інструментів, проміжні стани. Ці трейси потрапляють у спільне сховище. Далі команда може:

• вибирати з продакшен‑трафіку репрезентативні приклади для нових наборів тестів;
• запускати офлайн‑evals на історичних даних, порівнюючи різні конфігурації агента;
• виявляти патерни помилок і формувати таргетовані сценарії для регресійного тестування.

У результаті observability перестає бути лише «панеллю моніторингу», а evals — лише «тест‑раннером». Обидва стають частинами одного конвеєра, який постійно перетравлює напівструктуровані трейси й повертає команді сигнали про якість.

Щоб цей flywheel працював, потрібна не стільки вишукана UI‑оболонка, скільки потужний бекенд, здатний витримувати обсяги та характер даних, притаманних агентам.

Чому трейси агентів ламають звичні інструменти спостереження

У класичному світі observability — це метрики, логи, трейси. Багато команд звикли до APM‑інструментів, де трейс — це набір відносно невеликих спанів: HTTP‑запити, виклики БД, внутрішні сервіси. Дані структуровані, обсяги кожного спану — кілобайти, у гіршому разі сотні кілобайт.

З агентами картина інша. Hetzel описує кілька ключових відмінностей:

По‑перше, трейси напівструктуровані або взагалі неструктуровані. Усередині — довгі текстові промпти, відповіді моделей, JSON‑фрагменти, результати викликів інструментів, іноді вкладені один в один. Структура може змінюватися від релізу до релізу, від агента до агента.

По‑друге, вони текстоцентричні. На відміну від класичних трейсів, де головне — часові мітки, статус‑коди й лейбли, тут основна цінність — у самих текстах. Командам потрібно шукати по вмісту промптів, аналізувати відповіді, будувати евристики поверх природної мови.

По‑третє, вони великі. Hetzel говорить про спани розміром 10–20 мегабайт — і це не виняток. Якщо агент працює з довгими документами, складними ланцюжками інструментів або багатокроковими діалогами, один трейс легко роздувається до сотень мегабайт. У крайніх випадках окремі трейси можуть сягати гігабайта.

По‑четверте, це високошвидкісний потік. У продакшені агент може обробляти тисячі запитів на хвилину, кожен із яких породжує такий важкий трейс. Система має не лише прийняти ці дані, а й зробити їх придатними для запитів у реальному часі та аналітики.

У такій реальності спокуса «просто скласти все в Postgres» швидко обертається проблемами. Hetzel прямо попереджає: якщо зберігати гігантські трейси, скажімо, обсягом у гігабайт, безпосередньо в рядках Postgres, продуктивність неминуче просідає. База, розрахована на типові OLTP‑навантаження, погано поводиться, коли окремі записи перетворюються на монолітні блоби тексту.

Це підштовхує платформи до спеціалізованих стратегій зберігання та індексації: розділення «гарячих» і «холодних» даних, окремі сховища для великих payload‑ів, індекси для повнотекстового пошуку, шардинґ, компресія. І все це має працювати прозоро для користувача, який очікує, що зможе за секунди знайти потрібний трейс або побудувати агрегацію по мільйонах взаємодій.

Від BTQL до «нормального SQL»: еволюція дата‑шару Braintrust

Історія самої платформи Braintrust добре ілюструє, наскільки непросто знайти правильну архітектуру для таких даних. На ранньому етапі команда пішла шляхом, який виглядав логічно: поєднати швидке сховище для оперативних запитів з аналітичним дата‑вейрхаусом.

Під капотом це виглядало так. Для низької затримки використовувалося окреме low‑latency‑сховище, поверх якого можна було швидко діставати окремі трейси чи останні взаємодії. Паралельно всі дані прокачувалися в open‑source‑сховище даних, оптимізоване під аналітичні запити й агрегації.

Щоб зшити ці два світи, Braintrust створив власну мову запитів — BTQL. Вона мала абстрагувати користувача від деталей того, де саме лежать дані, і дозволяти писати єдині запити, які під капотом розподіляються між low‑latency‑шаром і дата‑вейрхаусом. Для додаткових агрегацій прямо в браузері використовувався DuckDB, який забирав на себе частину обчислень на стороні клієнта.

На папері це виглядало елегантно. На практиці — ні користувачам, ні самій команді Braintrust BTQL не сподобалася. Власний DSL означає, що кожному інженеру, який приходить у продукт, доводиться вчити ще одну мову запитів. Інструменти BI, аналітики, інтеграції — усе це «з коробки» розуміє SQL, але не розуміє BTQL. Навіть для внутрішньої розробки це створює тертя: будь‑який аналіз даних вимагає контекст‑перемикання між звичним SQL і кастомним синтаксисом.

Цей досвід став для Braintrust аргументом на користь іншого підходу: замість того, щоб будувати складні абстракції поверх двох різних сховищ і власної мови, краще інвестувати в дата‑шар, який із самого початку добре підтримує «серйозний» SQL і різноманітні патерни читання.

Нова архітектура, до якої рухається команда, має відповідати кільком вимогам одночасно.

По‑перше, підтримка суттєвої підмножини SQL. Це відкриває двері до стандартних інструментів аналітики, дозволяє інженерам використовувати знайомі підходи до побудови запитів, спрощує інтеграції.

По‑друге, різні режими читання. Потрібні як низьколатентні lookup‑и для конкретних трейсів чи користувацьких сесій, так і важкі аналітичні запити по великих масивах даних: агрегації, фільтрації, порівняння експериментів.

По‑третє, повнотекстовий пошук по великих трейсах. Для клієнтів на кшталт Notion критично важливо мати змогу шукати по вмісту промптів і відповідей: знаходити всі випадки певного типу помилки, відстежувати, як агент поводиться з конкретними формулюваннями запитів, виявляти небажані патерни.

По‑четверте, підтримка headless‑сценаріїв. Частина клієнтів взаємодіє з Braintrust переважно через код — агенти, що самі викликають evals, CI/CD‑пайплайни, автоматизовані регресійні тести. Для них UI — другорядний, а іноді й взагалі необов’язковий. Платформа має поводитися як «головний мозок» для evals та observability, доступний через API й SDK, а не як суто візуальний інструмент.

Усі ці вимоги знову повертають до вихідної тези: головна складність побудови платформи якості агентів — у дата‑системі, а не в інтерфейсі.

Чому це не про UI: бекенд для напівструктурованих трейсів

Hetzel прямо формулює це: вимірювання якості агентів через evals і observability — це насамперед задача системи даних, а не UI. Інтерфейс важливий для залучення різних ролей — від інженерів до доменних експертів, — але він не вирішує головної проблеми: як ефективно працювати з величезними, текстоцентричними, напівструктурованими трейсами у високошвидкісному потоці.

Щоб така система була життєздатною, бекенд має одночасно:

• приймати й зберігати великі об’єми даних без деградації продуктивності;
• дозволяти гнучко індексувати й шукати по тексту;
• підтримувати як точкові запити, так і масові аналітичні обчислення;
• бути достатньо відкритим, щоб клієнти могли будувати власні пайплайни поверх нього.

У цьому сенсі досвід Braintrust показує, що спокуса «швидко зробити UI поверх Postgres» або «написати свій DSL, який усе сховає» працює лише на ранніх стадіях. Щойно агенти виходять у продакшен і починають генерувати реальні трейси, платформа неминуче перетворюється на повноцінну дата‑систему з усіма притаманними їй викликами: вибір сховищ, компроміс між latency і вартістю, індексація, шардінг, оптимізація запитів.

І саме в цій точці стає очевидно, чому Braintrust об’єднує evals і observability в один продукт. Розділяти їх означало б дублювати всю цю складну інфраструктуру двічі — для «дотестових» і «післярелізних» даних. Натомість єдиний дата‑шар дозволяє будувати безперервний цикл покращення якості, де кожен новий трейс — це водночас сигнал для моніторингу й потенційний приклад для наступних експериментів.

Висновок: якість агентів як інженерія даних

Коли говорять про якість AI‑агентів, дискусія часто зводиться до метрик, промпт‑інжинірингу чи UX‑патернів. Досвід Braintrust додає до цієї картини ще один, менш помітний, але критичний шар: інженерію даних для трейсів.

Якщо сприймати evals як «те, що робимо до продакшену», а observability як «те, що робимо після», легко опинитися з двома розрізненими системами, які дублюють одна одну й не діляться даними. Якщо ж подивитися на них як на єдину задачу — збір, зберігання й аналіз напівструктурованих, текстових, великих і швидких трейсів — стає зрозуміло, чому платформи на кшталт Braintrust інвестують саме в дата‑шар, а не в ще один playground.

У міру того як агенти стають «обличчям» компаній у взаємодії з користувачами, питання їхньої якості перестає бути суто дослідницьким. Це вже не тільки про те, як написати кращий промпт, а про те, як побудувати інфраструктуру, здатну перетворювати хаотичний потік трейсів на систематичні сигнали для прийняття рішень. І в цій грі перемагають не ті, хто має найяскравіший UI, а ті, хто найкраще розв’язує базову задачу дата‑систем.

Джерело

Why building eval platforms is hard — Phil Hetzel, Braintrust

Інженер Cursor Ерік Закаріассон працює на стику продукту та developer experience й описує себе як розробника, який уже більшість типових проєктів веде на рівні «автономії 4»: максимально делегує роботу агентам і переважно перевіряє не код, а результат. У межах воркшопу AI Engineer він розповів, що потрібно зробити з кодовою базою, аби вона стала справді «агент‑френдлі» — від системи правил до тестів, які дозволяють агентам самостійно підтверджувати свою роботу.

У центрі цієї розмови — не черговий «чарівний» інструмент, а дуже приземлені, але критично важливі речі: структура репозиторію, стандарти запуску, guardrails і автоматизована валідація. Саме вони визначають, чи зможе ваш умовний «софтверний завод» працювати без постійної ручної опіки.

Правила як операційний мануал для агентів

Cursor підтримує систему правил, яка конфігурується через файл agents.md у репозиторії. Це не просто ще один README, а фактично операційний мануал для агентів: як поводитися в цьому конкретному коді, що дозволено, що заборонено, які патерни вважати канонічними.

Ці правила діють поверх загальних можливостей моделей і стають локальним «законом» для кожної кодової бази. Агент, який працює в Cursor, читає agents.md так само, як новий розробник читає CONTRIBUTING.md чи внутрішній онбординг‑док.

Щоб знизити поріг входу, Cursor підтримує публічний «cursor directory» — каталог прикладів правил, заточених під конкретні технологічні стеки. Там можна знайти, наприклад, набір правил для Next.js‑проєктів і використати їх як шаблон або відправну точку. Це особливо корисно командам, які тільки починають будувати агентні процеси й не хочуть вигадувати структуру правил з нуля.

Однак підхід «взяти все й одразу» тут працює погано. Поширена інтуїція: якщо є каталог готових правил, варто просто встановити всі, що відповідають вашому стеку. На практиці це перетворюється на перевантажений, суперзарегульований простір, у якому агенту складно орієнтуватися, а команді — розуміти, що взагалі діє.

Закаріассон радить протилежну стратегію: додавати правила реактивно, у відповідь на конкретні збої поведінки агентів. Якщо агент «з’їжджає з колії» в певному сценарії — саме це і є сигналом сформулювати нове правило. Так agents.md еволюціонує як жива SOP‑документація: не теоретичний ідеал, а зафіксований досвід реальних помилок і виправлень.

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

Guardrails: чому деякі файли мають бути недоторканними

Навіть найкращі правила не скасовують базового факту: є частини системи, де помилка агента може коштувати надто дорого. Йдеться про шифрування, аутентифікацію, платіжні модулі, критичні безпекові шари. Тут «трохи не так» означає не просто фейл тесту, а витік даних, фінансові втрати або серйозні вразливості.

Тому в системі правил Cursor важливу роль відіграють саме жорсткі guardrails — явні заборони на редагування певних директорій, файлів або типів логіки. У agents.md це може бути сформульовано як пряма інструкція: не змінювати код, пов’язаний із криптографією, токенами доступу, платіжними шлюзами, або робити це лише за участі людини.

Такі обмеження не суперечать ідеї автономії, а радше визначають її межі. Агент може вільно рефакторити UI, додавати нові фічі, писати тести, але не має права торкатися фундаментальних безпекових блоків. Це дуже схоже на реальний завод: робот може збирати корпус, але не перепрограмовувати систему безпеки цеху.

Важливий нюанс: guardrails працюють краще, коли вони конкретні й прив’язані до структури репозиторію. Заборона «не ламати безпеку» мало що означає для моделі, натомість «не редагувати файли в src/auth/**» — чіткий, машинно‑інтерпретований сигнал. У поєднанні з дедалі кращою здатністю моделей слідувати інструкціям це дозволяє суттєво знизити ризики.

«Ін‑дистрибуція» для агентів: стандартні патерни як ключ до автономії

Ще один фундаментальний принцип, на якому наголошує Закаріассон, — робити проєкти «in distribution» для агентів. Під цим мається на увазі не щось абстрактне, а дуже конкретна річ: використовувати ті патерни, які моделі вже добре знають із тренувальних даних.

Класичний приклад — package.json у JavaScript‑проєктах. Для сучасних моделей це один із найзнайоміших артефактів: вони «очікують» побачити його в корені репозиторію, знають, що там є scripts, і вміють шукати start чи dev, щоб запустити локальний сервер. Якщо проєкт дотримується цього патерну, агенту не потрібно вигадувати, як його запускати: достатньо прочитати package.json і виконати знайомий сценарій.

У демонстраційному музичному проєкті з інтерфейсом, схожим на Ableton, саме так і відбувається. Агент відкриває репозиторій, знаходить package.json, бачить start‑скрипт, запускає його й піднімає dev‑сервер на localhost:3000. Ніяких спеціальних інструкцій, лише стандартна структура, яка добре «лягає» в розподіл, на якому тренувалися моделі.

Цей принцип виходить далеко за межі JavaScript. У будь‑якому стеку варто запитати себе: чи відповідає мій проєкт типовим очікуванням інструментів і моделей? Чи є зрозумілий спосіб запустити застосунок однією командою? Чи логічно організовані модулі? Чи є очевидні точки входу для тестів?

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

Самоперевірка: чому агенти мають доводити, що їхній код працює

Як тільки агенти починають писати значущу частину коду, виникає очевидне питання: хто гарантує, що все це працює? Якщо відповідь — «людина, яка все вручну перевіряє», — це швидко стає вузьким місцем. Масштабування агентів без масштабування валідації перетворюється на пастку.

Закаріассон пропонує дивитися на це як на окремий клас систем — verifiable systems, у яких агенти можуть самі підтверджувати правильність своїх змін. Для цього потрібна не магія, а дисципліна тестування: юніт‑тести, інтеграційні тести й, особливо для фронтенду, UI‑тести.

Для бекенду все відносно просто: є чіткі контракти, API, очікувані відповіді. Агент може внести зміну, запустити тестовий набір, побачити, що всі тести зелені, і зробити висновок, що не зламав існуючу поведінку. Якщо ж тести падають, він має шанс самостійно локалізувати проблему й виправити її, перш ніж людина взагалі побачить PR.

З фронтендом складніше: тут важлива не лише логіка, а й поведінка інтерфейсу — чи з’являється лоадер, чи працює кнопка «Play», чи можна редагувати ноти в таймлайні. Саме для таких сценаріїв у музичному демо‑проєкті використовуються end‑to‑end тести на Playwright. Вони описують очікувану поведінку UI: натиснути кнопку, перевірити, що почалося відтворення, змінити ноту, переконатися, що зміна відображається.

Агенти в цьому проєкті не просто пишуть код інтерфейсу, а й запускають Playwright‑тести, щоб підтвердити, що все працює як задумано. Якщо тест проходить, це сильний сигнал, що зміна коректна. Якщо ні — агент отримує конкретний фідбек у вигляді впалого сценарію й може спробувати виправити проблему.

Ключова ідея тут у тому, що тести стають не лише інструментом контролю якості для людей, а й API валідації для агентів. Чим повніше покриття, тим більше завдань можна делегувати без страху, що кожну дрібницю доведеться вручну проганяти в браузері чи через Postman.

Як поєднати правила, структуру й тести в одну «фабрику»

Окремо взяті agents.md, стандартні start‑скрипти чи Playwright‑тести ще не роблять із проєкту «софтверний завод». Але разом вони формують середовище, у якому агенти можуть працювати майже як окремі співробітники з чіткими інструкціями, доступом до інструментів і можливістю самостійно перевіряти свою роботу.

Правила в agents.md задають рамки: куди можна лізти, а куди ні, які патерни вважати еталонними, як поводитися з чутливими зонами. Вони еволюціонують реактивно, у відповідь на реальні помилки, і з часом перетворюються на концентрат досвіду взаємодії з агентами саме в цьому репозиторії.

Стандартизована структура проєкту — від package.json до зрозумілих директорій — робить кодову базу «ін‑дистрибуційною» для моделей. Агенту не потрібно гадати, де шукати точку входу чи як запустити сервер: він слідує знайомим патернам, які вже «вшиті» в його тренувальний досвід.

Система тестів, від юніт‑рівня до UI‑енд‑ту‑енд, перетворює валідацію з ручної рутини на автоматизований протокол. Агенти можуть не лише писати код, а й самі доводити, що він працює, зменшуючи навантаження на людей і відкриваючи шлях до справжньої паралельної роботи багатьох агентів.

На цьому тлі guardrails для критичних зон виглядають не обмеженням, а необхідною страховкою. Вони дозволяють сміливо розширювати автономію агентів у «безпечних» частинах системи, не ризикуючи ключовими бізнес‑функціями.

У підсумку виходить не «темна фабрика», де людина взагалі нічого не бачить, а радше добре організований цех: менеджер формулює намір і цілі, агенти виконують більшість рутинної роботи, а система правил і тестів забезпечує передбачуваність і контроль.

Висновок: фабрика починається з дисципліни, а не з магії

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

Різниця лише в тому, що тепер ці практики потрібні не тільки для людей, а й для агентів. agents.md стає новим типом документації, «ін‑дистрибуція» — новим критерієм якості архітектури, а тести — каналом зворотного зв’язку не лише для розробників, а й для моделей.

Ті команди, які вже сьогодні починають будувати такі агент‑френдлі кодові бази, отримують не просто зручнішу інтеграцію з Cursor чи іншими інструментами. Вони закладають фундамент для того, щоб у найближчі роки перейти від «гострого автодоповнення» до справді автономних, масштабованих софтверних фабрик — із чіткими правилами гри й мінімумом сюрпризів.

Джерело

Building your own software factory — Eric Zakariasson, Cursor (YouTube)

У популярному ролику «Claude Cowork for Beginners: Build Your Own Jarvis» автор і продактівіті‑блогер Джефф Су показує, як зробити з Claude не просто чат‑бота, а повноцінну операційну систему для роботи — свого роду «AI‑другий мозок». Ключ до цього — правильно спроєктований кореневий рівень робочого простору, де все тримається на кількох простих markdown‑файлах і чіткій структурі пам’яті.

Цей матеріал розбирає саме цей базовий, але критично важливий шар — root‑рівень Claude Cowork OS: як він влаштований, чому побудований саме так і як завдяки йому AI починає пам’ятати ваші проєкти, звички та стиль роботи.

Від чат‑бота до операційної системи: що таке Cowork OS на кореневому рівні

Більшість користувачів взаємодіє з великими мовними моделями в режимі «одноразової сесії»: поставив запитання, отримав відповідь, закрив вкладку. Claude Cowork пропонує іншу парадигму — AI як постійний робочий середовище, яке «живе» разом із вами, пам’ятає попередні сесії, знає ваші активні проєкти й адаптується під ваш стиль.

Це досягається не якоюсь прихованою магією, а дуже прозорою файловою архітектурою. У центрі — батьківська папка, яку автор називає «Cowork OS» (у нього — з жартівливою назвою iClaude OS). Саме вона є коренем усієї системи: сюди підключається Claude, звідси він читає правила, сюди ж записує пам’ять.

На цьому root‑рівні все тримається на двох ключових markdown‑файлах:

• claude.md — глобальний інструктаж, «конституція» для всієї системи.
• memory.md — постійна пам’ять, спільна для всіх сесій і всіх задач.

Разом вони перетворюють модель з інструмента «поставив запит — отримав відповідь» на щось значно ближче до персональної операційної системи для роботи.

Claude.md: інструктаж, що перетворює хаотичний чат на керовану систему

Кореневий файл claude.md — це не код і не конфігурація в технічному сенсі, а звичайний текстовий документ у форматі markdown. Проте саме він визначає, як поводиться Claude у вашому робочому просторі.

У цьому файлі задається кілька фундаментальних правил.

По‑перше, тут явно прописано, що на початку кожної сесії Claude має прочитати файл пам’яті:

«На початку кожної сесії прочитай memory.md перед тим, як відповідати».

Це критичний момент. Без цього правила кожен новий діалог був би «чистим аркушем». Завдяки йому модель щоразу підтягує контекст: які проєкти зараз у роботі, що ви просили запам’ятати раніше, які уподобання вже зафіксовані.

По‑друге, у claude.md описана система пам’яті, яка працює на природній мові. Там є правило на кшталт:

«Коли я кажу “запам’ятай це”, запиши відповідну інформацію в memory.md».

Це перетворює звичайну розмову з AI на керований процес накопичення знань. Користувачеві не потрібно вручну відкривати файли, копіювати текст чи думати про структуру — достатньо в потрібний момент сказати «запам’ятай це», і система сама допише новий запис у файл пам’яті.

По‑третє, claude.md виконує роль диспетчера контексту. У ньому є розділ «routing map» — таблиця, яка пояснює Claude, які робочі «станції» (workstations) потрібно підключати для різних типів задач. Хоча детальна робота зі станціями — тема окремої розмови, саме на root‑рівні задається логіка маршрутизації: куди йти, якщо мова про email, куди — якщо про фінанси, а куди — якщо про контент.

Нарешті, у claude.md є блок посилань на додаткові ресурси — наприклад, файл із принципами тону голосу користувача. Ці посилання не завантажуються автоматично в кожну сесію, а лише коли це потрібно. Такий підхід дозволяє тримати під рукою багатий контекст, не перевантажуючи модель зайвими токенами.

У підсумку claude.md — це не просто «опис правил», а ядро, яке:

• визначає, що таке пам’ять у системі;
• вказує, коли й як її читати;
• пояснює, як підключати інші «модулі»;
• і робить усе це у звичайному текстовому форматі, доступному будь‑якому користувачеві.

Memory.md: як працює постійна пам’ять між сесіями

Якщо claude.md — це конституція, то memory.md — це щоденник, у якому фіксується все, що має значення в довгостроковій перспективі. Саме цей файл перетворює разові діалоги на безперервну історію співпраці з AI.

Структура memory.md навмисно проста, але продумана. Вона складається з двох основних розділів:

Перший — «Active projects». Тут зберігається перелік поточних проєктів користувача разом із коротким описом і, за потреби, статусом прогресу. Це можуть бути підготовка воркшопу, написання розсилки, обробка витрат чи будь‑які інші завдання, які не вкладаються в одну сесію.

Саме завдяки цьому розділу Claude «знає», чим ви живете зараз. Коли користувач у новій сесії запитує: «Що ми сьогодні маємо робити?» — модель, прочитавши memory.md, бачить список активних проєктів і може одразу видати релевантний перелік задач, а не ставити уточнювальні запитання з нуля.

Другий розділ — «Memory». Це загальна довгострокова пам’ять: факти про користувача, його вподобання, думки, які варто зберегти, або контекстні нотатки. Сюди автоматично додаються записи, коли користувач у діалозі каже щось на кшталт: «Поточні події відволікають усіх від важливого списку. Запам’ятай це».

У такому випадку Claude, керуючись правилами з claude.md, створює новий запис у розділі «Memory». Надалі, у новій сесії, можна поставити запитання: «Що я казав нещодавно про відволікання?» — і система, перечитавши memory.md, відтворить відповідну думку.

Цей механізм демонструє ключову ідею: пам’ять у Cowork OS не є «чорною скринькою» десь на сервері. Вона прозора, редагована й фізично існує у вигляді текстового файлу, який можна відкрити в будь‑якому редакторі. Це дає користувачеві контроль і розуміння того, що саме «знає» про нього AI.

«Cowork OS» як файловий корінь: структура, ресурси та інструменти

Щоб ця система працювала, потрібна чітка організація на файловому рівні. Базовий крок — створити в локальному сховищі (наприклад, у папці «Документи») кореневу директорію з назвою на кшталт Cowork OS. Саме її Claude використовуватиме як робочий простір.

Усередині цієї папки розміщуються два головні файли:

• claude.md — глобальні правила.
• memory.md — глобальна пам’ять.

Далі створюється папка 00 resources — кореневий каталог ресурсів. У ньому зберігаються довідкові матеріали, які Claude підвантажує лише за потреби. Один із ключових таких файлів — voice_principles.md.

Цей документ описує тон, стиль і мовні патерни користувача. Він будується автоматично: якщо до Claude підключено Gmail, система може проаналізувати останні 30 надісланих листів і на основі цього сформувати початковий профіль голосу. Якщо ж інтеграції немає, можна вставити п’ять зразків тексту й використати альтернативний промпт. У будь‑якому випадку результатом стає розлогий файл (у автора — понад 150 рядків), де зафіксовано, наприклад, що користувач пише «теплим, прямим і професійним тоном без зайвої офіційності».

На кореневому рівні voice_principles.md лежить саме в 00 resources. У claude.md є правило, яке каже Claude перед створенням контенту для конкретного користувача прочитати цей файл. Завдяки цьому чернетки розсилок, листи чи інші тексти звучать не як «узагальнений AI», а максимально наближено до реального стилю людини.

Ще один практичний елемент — використання Obsidian. Автор пропонує відкрити папку Cowork OS як «vault» у цьому безкоштовному застосунку. Це не обов’язкова частина системи, але суттєво спрощує перегляд і редагування markdown‑файлів. Обмежуватися знанням Obsidian не потрібно: достатньо вміти відкрити папку як сховище й переглядати claude.md, memory.md та інші документи в зручному форматі.

Важливий нюанс: усі ці файли — звичайний текст. Їх можна завантажити як готові шаблони, відкрити в будь‑якому нотатнику, змінити під себе. Це знімає бар’єр входу: щоб побудувати власний Cowork OS, не потрібно програмувати, достатньо працювати з текстом.

Як працює «другий мозок» на практиці: від пам’яті до відповідей

Коли кореневий рівень налаштований, взаємодія з Claude починає нагадувати роботу з дуже уважним асистентом, який пам’ятає попередні розмови й контекст.

Сценарій виглядає приблизно так. Користувач відкриває нову сесію. Claude, згідно з правилом у claude.md, спершу читає memory.md. У розділі «Active projects» він бачить, що зараз у роботі, наприклад, фіналізація воркшопу, підготовка вечері, написання розсилки та обробка витрат. У розділі «Memory» — що користувач, скажімо, легко відволікається через поточні новини й хоче це враховувати в плануванні.

Після цього можна просто запитати: «Що ми маємо зробити сьогодні?» — і Claude, спираючись на пам’ять, видасть список завдань, а не загальні поради. Якщо попросити: «Скільки я витратив минулого місяця?» — система знатиме, що це пов’язано з фінансовим трекінгом, і зможе опрацювати відповідні дані. Якщо сказати: «Фіналізуй наступну розсилку в моєму тоні й дай посилання на сторінку в Notion», — Claude, знову ж таки, спираючись на voice_principles.md і активні проєкти, згенерує текст, який звучить як користувач, а не як абстрактний бот.

Ключовий момент: усі ці «чарівні» можливості базуються на дуже конкретних механізмах:

• читання memory.md на старті кожної сесії;
• структурована пам’ять із розділенням на активні проєкти й загальні спогади;
• явні правила запису пам’яті через фрази на кшталт «запам’ятай це»;
• і можливість у будь‑який момент поставити запитання про минулі сесії, на які Claude відповідає, перечитавши власні попередні записи.

Таким чином, Cowork OS не намагається «вгадати» минулий контекст, а відтворює його з прозорого текстового джерела, яке сам же й веде.

Висновок: сила в простій, але послідовній архітектурі

Кореневий рівень Claude Cowork OS показує, що перетворити AI‑чат на повноцінну операційну систему для роботи можна без складної інфраструктури. Достатньо:

• мати одну батьківську папку Cowork OS;
• покласти в неї два ключові файли — claude.md як глобальний інструктаж і memory.md як постійну пам’ять;
• створити 00 resources з файлами на кшталт voice_principles.md;
• і прописати в claude.md прості, але жорсткі правила: читати пам’ять на старті, записувати нові факти за командою «запам’ятай це», підключати потрібні ресурси лише тоді, коли вони справді потрібні.

У результаті Claude перестає бути «розумною, але забудькуватою» моделлю й перетворюється на керовану систему, яка пам’ятає ваші проєкти, стиль, вподобання й може відповідати на запитання про минулі сесії, спираючись на власні записи.

Це не магія й не закритий корпоративний стек, а прозора текстова архітектура, яку можна відкрити, зрозуміти й адаптувати під себе. Саме з такого кореневого рівня починається побудова справжнього AI‑«другого мозку» для роботи.

Джерело

Claude Cowork for Beginners: Build Your Own Jarvis — Jeff Su

У 2026 році великі мовні моделі перестали бути лише «розумними автодоповнювачами» коду. Все частіше вони працюють як повноцінні агенти, які самі створюють, змінюють і аналізують бази даних. На каналі Tech With Tim показано, як Claude Code, підключений до AI‑орієнтованого сервісу Ghost.build через MCP‑сервер, отримує власні бази даних, форкає їх, оптимізує запити й тестує міграції — практично без ручного втручання розробника.

Ця стаття зосереджується на практичних робочих процесах: від швидкого прототипування невеликих застосунків до агресивної оптимізації продуктивності й паралельних експериментів з міграціями. Усі приклади виконуються всередині Claude Code, який керує Ghost.build як «бекендом» для даних.

Від «читального щоденника» до аналітики: як Claude сам собі створює бази

Перший рівень можливостей Claude + Ghost.build — це миттєве створення невеликих, але корисних баз даних, які одразу стають інструментом для аналізу.

Показовий приклад — база reading_log. Всередині Claude формулюється проста інструкція: створити нову базу з такою назвою і задати схему для відстеження прочитаних книжок. У таблиці з’являються поля для назви, автора, дати завершення читання та оцінки за п’ятибальною шкалою. Далі Claude, використовуючи інструменти Ghost MCP, не лише створює таблицю SQL, а й самостійно «засіває» її даними — приблизно десятьма книжками про штучний інтелект і машинне навчання.

Ключовий момент у тому, що розробнику не потрібно відкривати окремий клієнт для бази даних, налаштовувати підключення чи писати SQL вручну. Усі команди — створення бази, виконання SQL, вставка даних — виконуються як MCP‑виклики, які Claude ініціює й контролює. Користувач бачить лише результат: готову базу, з якою можна працювати природною мовою.

Далі починається аналітика. На запит про середню оцінку книжок Claude формує й виконує відповідний SQL‑запит, повертаючи середнє значення — близько 4,44 з 5. На прохання відсортувати книжки за рейтингом модель знову звертається до Ghost.build, витягує записи й групує їх за оцінками, показуючи п’ятизіркові, чотиризіркові та тризіркові позиції.

Це виглядає як «розмовний» інтерфейс до бази даних, але під капотом працює цілком реальний SQL‑движок. Ghost.build бере на себе інфраструктуру, а Claude — генерацію запитів і інтерпретацію результатів. Для розробника це означає, що навіть прості особисті інструменти — на кшталт журналу читання — можна підняти за хвилини, не торкаючись конфігурацій БД.

«Movie Night» як прототип: від схеми до Next.js‑дашборду

Другий сценарій показує, як Claude використовує Ghost.build не лише для зберігання даних, а й як основу для швидкого прототипування інтерфейсів.

Створюється нова база Movie Night зі схемою movies, де є поля для назви фільму, режисера, року, жанру, тривалості, а також рейтингу за десятибальною шкалою. Claude отримує завдання засіяти цю таблицю сотнею фільмів, розподілених по різних жанрах і десятиліттях. Знову ж таки, усі операції — створення бази, визначення схеми, вставка сотні записів — виконуються через Ghost MCP без ручного написання SQL.

Далі починається те, що особливо цікавить фронтенд‑розробників: Claude має побудувати простий дашборд на Next.js, використовуючи компоненти shadcn/ui, і підключити його безпосередньо до бази Movie Night. Вимоги до інтерфейсу мінімальні, але показові: одна сторінка з таблицею всіх фільмів, фільтром за жанром і трьома картками зі статистикою — загальна кількість фільмів, середній рейтинг та найпоширеніший режисер.

Claude генерує код Next.js‑сторінки, компоненти інтерфейсу й логіку підключення до бази Ghost.build. Хоча Ghost MCP в першу чергу орієнтований на те, щоб AI‑агент працював із базою безпосередньо, з нього можна витягнути й рядок підключення до underlying‑БД, щоб використовувати її в будь‑якому застосунку.

Результат — робочий, хоч і мінімалістичний дашборд: таблиця з фільмами, можливість сортувати й фільтрувати, базові агрегати зверху. Це не інструмент для продакшн‑аналітики, але як прототип чи внутрішній тул — більш ніж достатньо. Важливо, що весь цикл — від ідеї до UI — проходить у межах одного середовища Claude Code, без ручного налаштування БД, без окремого ORM і без довгих конфігурацій.

Ще одна деталь, яка змінює правила гри: бази Ghost.build зберігаються навіть після того, як сесію Claude Code закрито. Коли інструмент запускається знову, Claude може попросити перелік доступних баз Ghost — і побачить reading_log, Movie Night та інші. Потім їх можна видалити, очистити або форкнути для нових експериментів. Таким чином Ghost.build фактично додає Claude «постійну пам’ять» на рівні даних, якої йому бракує за замовчуванням.

Оптимізація продуктивності: три стратегії, три форки, одна база

Найцікавіші можливості з’являються тоді, коли Claude починає працювати не з іграшковими, а з великими, навмисно повільними базами. Для цього створюється shop_analytics — умовна e‑commerce‑БД, яка має таблиці customers, orders, order_items, products і categories. База відразу наповнюється великим обсягом даних: 100 тисяч клієнтів, 500 тисяч замовлень і 1 мільйон позицій замовлень. При цьому свідомо не додається жодних індексів, окрім первинних ключів, щоб зробити запити повільними.

На цій базі запускається показовий аналітичний запит: знайти топ‑10 клієнтів за сумарними витратами за останні 90 днів, разом із кількістю їхніх замовлень і середнім чеком. Claude формує SQL, виконує його через Ghost MCP і фіксує час: приблизно 1,8 секунди. Для локального експерименту це не катастрофа, але для продакшн‑аналітики — вже відчутна затримка, особливо якщо таких запитів багато.

Далі починається те, що в ручному режимі зазвичай займає години: систематичний перебір стратегій оптимізації. Claude отримує інструкцію:

по‑перше, форкнути базу shop_analytics тричі, причому робити це паралельно, не чекаючи завершення одного форку, щоб почати наступний;

по‑друге, застосувати до кожного форку окрему стратегію оптимізації, не торкаючись базової БД: на одному форку — цільові індекси, на другому — матеріалізований вигляд, на третьому — денормалізована підсумкова таблиця;

по‑третє, на кожному форку повторно виконати той самий запит, заміряти час виконання й порівняти результати.

Ghost.build тут виступає як «лабораторія» для експериментів: форки створюються й видаляються без додаткових витрат на конфігурацію, а Claude керує всім процесом через MCP‑інструменти. Для розробника це означає, що можна дозволити AI‑агенту вільно «ламати» клоновані бази, не ризикуючи продакшном.

Після того як усі три стратегії протестовано, Claude порівнює час виконання запиту на кожному форку й обирає найефективнішу. Далі ця стратегія — наприклад, конкретний набір індексів або схема денормалізованої таблиці — застосовується вже до базової shop_analytics через ті ж MCP‑команди Ghost.build. Тимчасові форки, які використовувалися для експериментів, видаляються, щоб не захаращувати простір і не витрачати ресурси.

Такий підхід змінює саму культуру оптимізації: замість того, щоб інженер вручну вигадував і тестував одну‑дві гіпотези, AI‑агент може паралельно прогнати кілька стратегій на реалістичних даних і повернути не лише «кращу ідею», а й конкретні виміряні прискорення. Ghost.build, зі своєю можливістю створювати й форкати необмежену кількість баз у межах безкоштовного тарифу, робить цю тактику практично безкоштовною.

Паралельні міграції: десять форків для очищення телефонних номерів

Якщо оптимізація продуктивності — це одна сторона роботи з даними, то друга — міграції та очищення. Тут Claude + Ghost.build демонструють ще один потужний сценарій: масові паралельні експерименти з різними стратегіями міграції.

Для цього створюється база users_base з 500 фейковими користувачами. Особливість у тому, що колонка phone_number навмисно «зламана»: приблизно 3% значень — NULL, ще близько 2% — відверто некоректні, а решта — формально валідні, але записані в різних форматах. Це типовий кейс для реальних систем, де телефонні номери накопичуються роками з різних джерел.

Замість того, щоб одразу вирішувати, як саме чистити дані в продакшн‑таблиці, Claude отримує інструкцію форкнути users_base десять разів паралельно, створивши бази migration_test_1 до migration_test_10. На кожному форку можна випробувати окрему стратегію:

на одному — просто видалити всі рядки з некоректними номерами;

на іншому — спробувати заповнити пропуски на основі інших полів;

на третьому — застосувати регулярні вирази для нормалізації форматів;

на четвертому — винести проблемні записи в окрему «карантинну» таблицю, а в основній зберігати лише гарантовано валідні значення;

і так далі, комбінуючи підходи, поки не знайдеться оптимальний баланс між чистотою даних і мінімальними втратами.

Claude, керуючи Ghost MCP, виконує всі ці міграції паралельно, аналізує результати на кожному форку й порівнює, які стратегії дають найкращий компроміс. У підсумку найуспішнішими виявляються підходи, реалізовані в migration_test_5 і migration_test_3. Їх комбінують і застосовують уже до базової users_base, знову ж таки через MCP‑команди до Ghost.build.

Після цього всі десять тестових форків видаляються. У продакшн‑базі залишається лише одна, але вже очищена й нормалізована колонка phone_number, а історія експериментів — у вигляді знань, які Claude може використати в майбутніх міграціях.

Такий підхід до міграцій кардинально відрізняється від традиційного. Замість одного‑двох обережних прогонів на staging‑середовищі з’являється можливість одночасно прогнати десяток варіантів, виміряти їхні наслідки й обрати найкращий. Ghost.build тут знову виступає як «пісочниця» для AI‑агента, де можна безпечно ламати, чистити й перетворювати дані.

Що це означає для розробників і команд

У всіх описаних сценаріях — від reading_log до shop_analytics і users_base — повторюється одна й та сама схема: Claude виступає як «мозок», який генерує SQL, стратегії оптимізації й міграції, а Ghost.build — як «тіло», що забезпечує інфраструктуру баз даних, форки, виконання запитів і зберігання.

Для індивідуальних розробників це означає, що:

можна швидко піднімати невеликі бази для особистих проєктів, нотаток, журналів чи прототипів, не заморочуючись із розгортанням Postgres або MySQL;

можна доручити AI‑агенту не лише писати код, а й повністю керувати життєвим циклом БД — від створення схеми до аналізу даних.

Для команд, які працюють із продакшн‑системами, цікавішими виглядають сценарії з форками:

оптимізація складних аналітичних запитів може перетворитися на систематичний процес, де AI‑агент паралельно тестує індекси, матеріалізовані вигляди й денормалізацію на реалістичних копіях даних;

міграції та очищення даних можна проганяти в десятках варіантів на форках, перш ніж обрати одну‑дві стратегії для застосування до основної бази.

Важливо, що Ghost.build надає безкоштовний тариф із 100 годинами обчислень на місяць, 1 ТБ сховища й необмеженою кількістю баз і форків. Це робить описані експерименти доступними навіть для невеликих команд і фрилансерів, які не готові платити за повноцінні керовані БД лише заради тестів.

У підсумку поєднання Claude Code й Ghost.build демонструє, як AI‑агенти можуть вийти за межі «асистентів програміста» і стати повноцінними операторами даних. Вони не просто пишуть SQL, а будують робочі процеси: створюють бази, форкають їх, тестують стратегії, вимірюють результати й застосовують найкращі рішення до основних систем.

Висновок

Практичні демо з reading_log, Movie Night, shop_analytics і users_base показують, що коли великій мовній моделі дати власну, спеціально спроєктовану для AI базу даних, вона починає працювати зовсім в іншому режимі. Claude не просто відповідає на питання про дані — він сам створює ці дані, структурує їх, оптимізує доступ і проводить міграції, використовуючи Ghost.build як гнучку, безпечну лабораторію.

Для розробників це відкриває новий клас робочих процесів: від швидкого прототипування застосунків до серйозної оптимізації продуктивності й паралельних експериментів із міграціями. І все це — без необхідності вручну керувати інфраструктурою баз даних.

Джерело

YouTube: I gave Claude its own database, here’s what happened