Інструменти на кшталт Claude Code поступово перетворюються на повноцінні робочі середовища для розробників. У свіжому огляді від каналу KODARIK показано, як організована робота із сесіями в Claude Code і як швидко повертатися до попередніх завдань без втрати контексту.

Продовження останньої сесії: команда claude continue

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

claude continue

Після її виконання відкривається остання (найсвіжіша) сесія. Це зручно, коли ви:

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

Фактично, claude continue працює як «продовжити там, де зупинився», без додаткових запитань і вибору.

Повернення до будь-якої старої сесії: команда claude resume

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

claude resume

Після її запуску Claude Code:

1. Виводить список усіх ваших сесій.
2. Дає змогу обрати потрібну з цього списку.
3. Відкриває вибрану сесію для подальшої роботи.

Такий підхід корисний, коли:

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

Навіщо це розробнику

Підтримка сесій у Claude Code дозволяє:

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

Дві прості команди — claude continue та claude resume — закривають основні сценарії: миттєве продовження останньої роботи та усвідомлений вибір потрібної сесії з історії.

Джерело

YouTube: Повний огляд Claude Code – Частина 23 #аі #python #вайбкодинг

Ринок курсів з AI‑інжинірингу вибухово росте, але разом із кількістю зростає й хаос: програми змішують теорію з практикою, машинне навчання з продакшн‑розробкою, а маркетинг — з реальними навичками. Канал Tech With Tim проаналізував 20 курсів і виділив п’ятірку, яка найкраще закриває запит саме на AI‑інжиніринг — тобто побудову продакшн‑застосунків на базі вже навчених моделей, а не дослідження в галузі ML.

Що таке AI‑інжиніринг і чим він відрізняється від ML‑досліджень

AI‑інжиніринг у цьому контексті — це:

• робота з великими мовними моделями (LLM) через API (OpenAI, Anthropic тощо);
• побудова AI‑агентів і систем для їх оцінювання;
• промпт‑інжиніринг;
• інтеграція MCP‑серверів та інших інструментів;
• LLM‑ops: моніторинг, деплой, оновлення моделей у продакшні.

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

При відборі курсів враховувалися п’ять критеріїв:

1. Практичність — чи будуються реальні застосунки, а не лише пояснюється теорія.
2. Кредибільність — хто створює курс, чи має досвід продакшн‑AI.
3. Інтерактивність — наявність вправ, коду, практичних завдань, а не лише відео.
4. Глибина — чи заходить курс у продакшн‑рівень, а не обмежується поверхневим оглядом.
5. Цільова аудиторія — новачки, мідли чи просунуті спеціалісти.

DeepLearning.AI та Coursera: стартовий майданчик безкоштовно

Короткі курси DeepLearning.AI

Платформа DeepLearning.AI пропонує велику кількість коротких курсів, зокрема «AI Python for beginners». Основні риси:

• Формат: короткі модулі, орієнтовно ~10 годин на курс.
• Рівень: є програми для початківців (чітко позначений рівень).
• Модель доступу: відео — безкоштовні, інтерактивні компоненти — за підпискою.
• Плюс: висока довіра до автора платформи (Andrew Ng) та компанії.
• Мінус: надто багато курсів — легко загубитися, складно обрати маршрут.

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

Generative AI with Large Language Models (DeepLearning.AI x AWS на Coursera)

Щоб компенсувати розпорошеність окремих курсів, є більш структурований варіант — спільна програма DeepLearning.AI та AWS на Coursera:

• Структура: три модулі, розбиті на тижні.
• Тематика: fine‑tuning, generative AI, reinforcement learning, ключові теми для AI‑інженера.
• Рівень: підходить тим, хто вже знає Python і має базовий досвід.

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

DataCamp: інтерактивний шлях у продакшн‑AI

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

Associate AI Engineer for Developers

Трек для розробників орієнтований на тих, хто вже володіє Python і хоче перейти в AI‑інжиніринг без занурення в зайву теорію.

Що покриває:

• робота з OpenAI API;
• промпт‑інжиніринг;
• інтеграція з Hugging Face;
• LLM‑ops — тема, яку часто ігнорують інші курси;
• embeddings, topic analysis;
• практичні проєкти.

Особливості платформи:

• Максимальна інтерактивність: код пишеться прямо в браузері, без налаштування середовищ чи ноутбуків;
• Орієнтація на продакшн: менше теорії, більше реальних сценаріїв використання;
• Кредибільність: серед клієнтів — великі компанії на кшталт Bank of America, Pfizer, Uber.

Цей трек адресований практикуючим розробникам, які вже комфортно почуваються з Python і хочуть швидко додати до стеку AI‑інструменти.

Associate AI Engineer for Data Scientists

Другий трек DataCamp орієнтований на тих, хто приходить з боку аналітики та дата‑саєнсу.

Програма включає:

• supervised learning з scikit‑learn;
• unsupervised learning у Python;
• роботу з Hugging Face;
• intermediate deep learning з PyTorch;
• тренування й fine‑tuning сучасних моделей (зокрема Llama 3) для продакшну.

Цей маршрут:

• глибше заходить у ML‑частину, ніж трек для девелоперів;
• краще підходить тим, хто вже працює з pandas, sklearn та іншими інструментами аналізу даних;
• орієнтований на data scientists / analysts, які рухаються в бік AI‑інжинірингу.

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

Hugging Face та Full Stack LLM Bootcamp: глибина й просунутий рівень

Hugging Face LLM Course: глибоке занурення в open‑source

Безкоштовний курс від Hugging Face — один із найглибших ресурсів у добірці, особливо якщо йдеться про open‑source‑моделі.

Основні теми:

• трансформери;
• fine‑tuning моделей;
• робота з датасетами;
• NLP‑задачі;
• публікація та шаринг моделей.

Особливості:

• Дуже велика глибина: значно детальніше, ніж більшість безкоштовних ресурсів.
• Обмежена інтерактивність: є тести й базові інтерактивні елементи, але немає повноцінного середовища для написання коду в браузері — часто доведеться копіювати приклади й працювати локально.
• Фокус на екосистемі Hugging Face: менше уваги до інших інструментів, які використовуються в AI‑інжинірингу.

Це хороший вибір для тих, хто:

• хоче працювати з open‑source та self‑hosted моделями;
• планує займатися fine‑tuning;
• прагне розуміти, що відбувається «під капотом», а не лише викликати API.

Full Stack LLM Bootcamp: концентрований курс від Berkeley‑алумні

Full Stack LLM Bootcamp від fullstackdeeplearning.com створений у партнерстві з UC Berkeley й орієнтований на практичний продакшн‑рівень.

Ключові теми:

• prompt engineering;
• LLM‑ops;
• augmented language models;
• основи LLM;
• UX для мовних інтерфейсів;
• запуск LLM‑застосунку за годину (з розбором архітектури).

Формат:

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

Цей буткемп орієнтований на просунутих слухачів:

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

Як обрати курс залежно від вашого рівня

З урахуванням різних форматів і аудиторій, добірка розкладається на кілька типових сценаріїв:

• Повний новачок, потрібен безкоштовний старт
  Почати з коротких курсів DeepLearning.AI, а потім додати Full Stack LLM Bootcamp для розуміння продакшн‑підходів.
• Потрібна структурована, hands‑on програма з сертифікатом
  Обрати DataCamp:
• трек для розробників, якщо ви бекенд‑/софткер‑інженер;
• трек для data scientists, якщо вже працюєте з pandas, sklearn та ML‑моделями.
• Фокус на open‑source та глибокому розумінні моделей
  Вибрати курс від Hugging Face — він дає найбільшу глибину в роботі з трансформерами та fine‑tuning.
• Ви вже шипите AI‑застосунки й хочете «апгрейд»
  Подивитися Full Stack LLM Bootcamp як концентрований набір продакшн‑практик і архітектурних підходів.

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

Джерело

https://www.youtube.com/watch?v=HFmoNVx6vTA

Короткий, але щедрий: як влаштований воркшоп з human‑in‑the‑loop автоматизації в n8n

На конференції AI Engineer розробники й продакт-люди збираються не лише послухати про нові інструменти, а й спробувати їх у реальній роботі. Один із таких форматів — практичний воркшоп з human‑in‑the‑loop автоматизації на базі n8n, який веде Liam McGarrigle, developer advocate у n8n. Сесія побудована як короткий, інтенсивний практикум: учасники з нуля збирають простого агента для керування Gmail і Google Calendar, отримують рік n8n Cloud Pro безкоштовно та встигають закласти фундамент для власних, значно складніших автоматизацій.

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

Хто веде сесію: роль developer advocate у світі low‑code автоматизації

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

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

Саме під таку аудиторію й налаштована сесія. Вона не вимагає вміння писати код, але не обмежує тих, хто хоче «зануритися глибше». McGarrigle наголошує: n8n — візуальний інструмент, де можна зібрати робочий процес без жодного рядка коду, але за потреби в будь-якому полі можна вписати невеликий JavaScript‑вираз. Це дозволяє не розривати логіку між «no‑code» і «full‑code» підходами: більшість дій робиться візуально, а дрібні трансформації — прямо в полях вузлів.

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

Формат воркшопу: одна година, один агент і акцент на основах

Сесія свідомо коротка — приблизно година. За цей час учасники мають:

• зареєструватися в n8n Cloud або підготувати власний інстанс;
• отримати доступ до матеріалів у Notion;
• зібрати базовий агент для керування Gmail і Google Calendar;
• зрозуміти, як додати human‑in‑the‑loop елементи;
• побачити, як продовжити роботу самостійно після воркшопу.

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

Щоб не залишити нікого позаду, у Notion також викладено JSON готового workflow. Його можна скопіювати однією кнопкою й вставити прямо в canvas n8n. Це своєрідна «страхувальна сітка»: навіть якщо хтось не встигає повторювати всі кроки в реальному часі, він все одно виходить із воркшопу з робочим агентом, який можна розібрати й адаптувати пізніше.

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

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

Щедрий бонус: рік n8n Cloud Pro безкоштовно

Один із найбільш відчутних для учасників аспектів — доступ до n8n Cloud Pro. Усі, хто проходить воркшоп, отримують рік підписки на Pro‑план безкоштовно. У грошовому вимірі це близько 600 доларів.

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

По‑перше, немає бар’єру входу. Щоб почати, достатньо зареєструватися в n8n Cloud і отримати стандартний 14‑денний безкоштовний період. Уже цього вистачає на сам воркшоп. Але McGarrigle просить учасників активувати спеціальні коди протягом дня‑двох, оскільки планує їх швидко відкликати. Це створює чітке вікно можливостей: є конкретний дедлайн, після якого щедра пропозиція зникає.

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

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

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

Для кого цей воркшоп: від «завжди початківця» до power user

Аудиторія сесії — строката. Є ті, хто вперше чує про n8n, є ті, хто вже використовує його на роботі чи для особистих проєктів, є power users, які приносять інструмент у свої компанії. Формат воркшопу намагається врахувати всі ці рівні одночасно.

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

Це класична low‑code модель, яка була в n8n ще з 2019 року, задовго до появи ChatGPT. Тоді платформа позиціонувалася як інструмент інтеграцій: візуальний спосіб «зшивати» API різних сервісів. Саме в цю модель сьогодні вбудовуються AI‑агенти, і воркшоп показує, як це робиться без втрати прозорості.

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

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

Для power users є ще один вимір — робота з n8n у компаніях. У залі виявляються люди, які вже приносять інструмент на роботу, будують на ньому внутрішні процеси. McGarrigle прямо звертається до них: якщо потрібна допомога в тому, як «продати» n8n менеджменту, у кімнаті є колеги, які спеціалізуються саме на цьому — на бізнес‑аргументах, ліцензуванні, впровадженні. Це ще один шар воркшопу: технічна сесія стає точкою входу в більш широкий діалог про використання платформи в організаціях.

Як побудована практична частина: від тригера до агента з людиною в циклі

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

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

У canvas додається Chat Trigger, який одразу відкриває невелике вікно чату внизу інтерфейсу. Це зручно для налагодження: можна надсилати повідомлення й дивитися, як workflow реагує, навіть якщо AI‑частина ще не підключена. Далі в налаштуваннях тригера є опція «Make available in ChatHub». Якщо її увімкнути й опублікувати workflow, у боковій панелі n8n з’являється окремий розділ ChatHub — повноцінний чат‑інтерфейс усередині платформи.

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

Наступний ключовий вузол — AI Agent. Його додають до workflow після чат‑тригера. Візуально він відрізняється від звичайних вузлів: має «ніжки» знизу, що підкреслює його особливу роль у системі. Для базової роботи йому потрібна щонайменше одна річ — чат‑модель. n8n дозволяє підключати різних постачальників LLM; якщо конкретного сервісу немає в списку, часто можна використати OpenAI‑сумісний вузол і змінити base URL на адресу іншого провайдера.

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

Фінальний штрих — додавання human‑in‑the‑loop елементів. У межах години це робиться в найпростішому вигляді: агент не просто автономно керує Gmail і Calendar, а працює в режимі, де людина може бачити його дії, перевіряти, що відбувається, і за потреби втручатися. Саме це й відрізняє воркшоп від багатьох демонстрацій «магічних агентів», які працюють як чорна скринька.

Чому короткий воркшоп може бути ефективнішим за довгий курс

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

По‑перше, чітко окреслений обсяг. Завдання — зібрати одного конкретного агента для Gmail і Google Calendar, а не охопити всі можливості n8n. Це дозволяє уникнути поверхневого «огляду всього» й натомість пройти повний цикл: від створення workflow до тестування в чаті.

По‑друге, сильна опора на матеріали після воркшопу. Notion‑сторінка з покроковими інструкціями, JSON готового workflow, «домашка» з ідеями для розширення — усе це перетворює годинну сесію на старт довшого процесу навчання. Учасники не виходять із залу з відчуттям «було цікаво, але що далі?».

По‑третє, усунення фінансового бар’єру. Рік n8n Cloud Pro безкоштовно означає, що немає потреби одразу переконувати керівництво виділяти бюджет чи платити з власної кишені. Можна спокійно будувати прототипи, показувати їх колегам, поступово перетворюючи експерименти на робочі інструменти.

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

Висновок: воркшоп як модель відповідальної AI‑автоматизації

Воркшоп Liam’а McGarrigle з human‑in‑the‑loop автоматизації в n8n — це не просто демонстрація чергового AI‑агента. Це показова модель того, як сьогодні можна навчати інженерів, аналітиків і продакт‑менеджерів будувати корисні, але не «чорні» автоматизації.

Короткий формат змушує концентруватися на головному: прозорості, керованості, можливості спостерігати за діями агента й втручатися, коли це потрібно. Щедрий бонус у вигляді року n8n Cloud Pro знімає бар’єри для продовження роботи після сесії. А продумана логістика — від Notion‑матеріалів до готового JSON workflow — робить воркшоп доступним як для повних новачків, так і для power users, які вже будують складні системи на базі n8n.

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

Джерело

Human-in-the-Loop Automation with n8n — Liam McGarrigle

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

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

Фіктивний застосунок, реальні проблеми: навіщо агент тріажу підтримки

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

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

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

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

Усередині пайплайна: п’ять етапів, які можна вимірювати окремо

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

Перший етап — збирання контексту. Агент не повинен відповідати, спираючись лише на текст звернення користувача. Йому потрібні дані про акаунт, історію замовлень, попередні тікети, можливо — статус платежів чи поїздок (у реальному застосунку на кшталт Trainline це критично). На цьому кроці система викликає локальні інструменти або API, щоб зібрати все, що може знадобитися для коректної відповіді.

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

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

Четвертий етап — чернетка відповіді. Лише після того, як зібрано контекст, виконано тріаж і перевірено політики, агент формує текст, який потенційно отримає користувач. Тут важлива не лише коректність змісту, а й тон, структура, зрозумілість. У реальних командах цей крок часто стає полем для A/B-тестів і тонкого тюнінгу промптів.

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

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

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

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

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

Саме навколо такого пайплайна й побудовано практичну частину воркшопу.

Інфраструктура воркшопу: Slack, Braintrust, OpenAI та GitHub

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

Перший крок — комунікація. Учасників просять приєднатися до організації AI Engineer у Slack і зайти в публічний канал ai-engineer-europe-2026-braintrust-workshop. Саме там пропонують ставити запитання, ділитися проблемами з налаштуванням середовища й отримувати допомогу від команди Braintrust і Trainline. Для живого воркшопу це критично: коли десятки людей одночасно намагаються запустити один і той самий стек, завжди знаходяться ті, у кого щось не працює через локальні особливості.

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

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

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

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

Node.js 22, pnpm і make: чому стек має значення

Окремої уваги заслуговує вибір технологічного стека. Кодова база воркшопу побудована навколо Node.js версії 22. Це сучасна гілка платформи, яка дає змогу використовувати актуальні можливості JavaScript і водночас достатньо стабільна для серйозних застосунків.

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

Над усім цим — make як обгортка для типових команд. Замість того, щоб кожен учасник запам’ятовував довгі рядки з npm-скриптами або параметрами CLI, організатори пропонують прості цілі на кшталт make install, make run чи make test (конкретні назви в інструкції). Це вирівнює досвід між різними операційними системами й shell-середовищами: незалежно від того, чи працює людина на macOS, Linux або Windows, вона викликає ті самі make-команди.

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

Git-теги як чекпойнти: як не загубитися в багатокроковому флоу

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

Для навчання це вирішує одразу кілька проблем.

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

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

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

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

Воркшоп як модель продакшену: від локального коду до спостережності

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

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

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

Важливо й те, що воркшоп не обмежується лише кодом. Slack-канал для підтримки, покроковий cheat sheet, Git-теги як чекпойнти, вимога мати акаунт у Braintrust і ключ OpenAI — усе це моделює реальну екосистему, у якій працюють сучасні AI-команди. Вони не існують у вакуумі одного репозиторію, а взаємодіють із платформами спостережності, інфраструктурою, внутрішніми чатами підтримки й зовнішніми API.

Висновок: навчальний агент, який вчить думати як AI-інженер

Фіктивний агент тріажу підтримки, побудований на воркшопі Braintrust і Trainline, — це значно більше, ніж просто приклад коду. Це концентрована модель того, як сьогодні виглядає робота AI-інженера, який намагається довести систему з LLM від демо до продакшену.

Багатоступеневий пайплайн із чіткими стадіями, можливість інструментувати й оцінювати кожен крок окремо, використання сучасного стека на Node.js 22 із pnpm і make, Git-теги як навчальні чекпойнти, інтеграція з Braintrust і OpenAI, підтримка через Slack і детальний cheat sheet — усе це разом формує практичний шаблон, який можна перенести у власні проєкти.

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

Джерело

https://www.youtube.com/watch?v=ZdheJTfLu-s

Head of Product Notion Макс Шьонінг — людина, яку складно втиснути в одну роль. У минулому він був продакт-менеджером у Google, очолював дизайн у Heroku, був дизайн-лідером і одночасно інженером у GitHub за Ната Фрідмана, двічі запускав власні стартапи. Сьогодні він керує продуктом у Notion і системно ламає кордони між ролями: дизайнери й продакт-менеджери там не лише малюють макети, а й прототипують у коді та, до певної міри, комітять у продакшн.

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

Від Figma до термінала: як у Notion з’явився «дизайн у коді»

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

У Notion ця схема почала ламатися з дуже конкретної проблеми: команда будувала багато чат-інтерфейсів для AI-функцій, але статичні макети в Figma виявилися майже безпорадними для такого типу продукту. Статичний скрін чату — це «мертва риба»: він не дає відчути поведінку моделі, динаміку діалогу, відгук системи на різні типи запитів.

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

Цей playground став альтернативою Figma саме для чат-інтерфейсів. Замість того, щоб малювати черговий статичний екран, дизайнери й PM почали працювати з живою системою: змінювати промпти, структуру діалогу, поведінку відповіді. Важливо, що це відбувалося не в основному коді Notion, а в окремому, «безпечному» середовищі, де важко щось зламати й легко експериментувати.

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

• термінал не лякав людей, які ніколи не працювали з ним;
• більшість дій можна було виконати «в один постріл» — одна команда, одна зміна, один результат;
• AI-інструменти могли ефективно допомагати з кодом, бо структура репозиторію була «LLM-friendly».

Результат: люди, які раніше жили виключно в Figma чи документах, почали працювати з реальним кодом — спочатку для прототипів, а потім, поступово, і в напрямку продакшн-змін.

Культура «drive Notion like it’s stolen»: агентність як норма

Технічні інструменти самі по собі не змінюють культуру. Те, що сталося в Notion, — це наслідок іншого очікування, яке Шьонінг формулює дуже прямо: «drive Notion like it’s stolen». Метафора з автокультурою означає стиль поведінки, коли людина поводиться з компанією й продуктом не як з чимось далеким і бюрократичним, а як із власним інструментом, який можна й треба активно «крутити» під себе.

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

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

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

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

AI як каталізатор: коли перші 10% проєкту стають безкоштовними

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

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

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

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

Чому важливо, щоб дизайнери й PM розуміли код — але не обов’язково шипили його

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

Для класичного UI це означає розуміння обмежень і можливостей фронтенд-стека. Для AI-продуктів — ще важливіше: розуміння того, як працюють агентні петлі (agent loops), як система приймає рішення, як вона взаємодіє з користувачем у динаміці.

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

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

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

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

Межі, що розмиваються: швидкість проти глибокої спеціалізації

Зі сторони може здатися, що така модель неминуче веде до зникнення глибоких спеціалістів. Якщо всі трохи дизайнери, трохи PM, трохи інженери, хто тоді будує складні, надійні системи? Сам Шьонінг не ідеалізує повне злиття ролей і прямо говорить, що є ризик втратити сильних інженерів і дизайнерів як окремі професії.

Ще одна його тривога — «vibe coding»: коли AI дозволяє дуже швидко збирати працюючий на вигляд софт, але загальна надійність продуктів від цього не росте. За його оцінкою, за останні 12 місяців кількість софту вибухово збільшилася, а от якість і стабільність — не дуже. Прототипи стають схожими на готові продукти, але під капотом часто лишаються «3D-друкованими» моделями, які не витримують навантаження.

Щоб пояснити цю різницю, Шьонінг використовує апаратну метафору: 3D-друкований прототип і масово вироблений продукт — це різні світи. Перший дозволяє швидко перевірити форму й базову функцію, другий вимагає інженерної дисципліни, матеріалознавства, виробничих процесів. Те саме відбувається й у софті: те, що легко зібрати в playground, ще не означає, що воно готове до мільйонів користувачів.

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

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

Як це змінює темп: від ідеї до тесту — за дні, а не місяці

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

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

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

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

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

Висновок: майбутнє продукту — за тими, хто переходить межі

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

Культура високої агентності — «drive Notion like it’s stolen» — у поєднанні з продуманими інструментами на кшталт LLM-дружнього playground’у робить те, що ще кілька років тому здавалося екзотикою: дизайнери й PM не просто «впливають на продукт», а безпосередньо працюють із його кодом. Вони не обов’язково стають інженерами, але стають глибокими знавцями матеріалу, з якого зроблений сучасний софт — особливо там, де йдеться про AI й агентні системи.

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

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

Джерело

Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Notion)

Шоу Mixture of Experts від IBM Technology цього разу зібрало дослідників і архітекторів IBM, аби поговорити про те, що відбувається на справжньому «залізному» фронті штучного інтелекту: від вартості токенів і вибору моделей в ентерпрайзі до того, як нові методи на кшталт DiLoCo від Google DeepMind можуть перелаштувати саму географію дата-центрів. На тлі запуску нової лінійки спеціалізованих моделей Granite 4.1 і системного асистента IBM Bob панель обговорює ширший зсув: великі універсальні моделі стають комодіті, а справжня диференціація зміщується в бік системного дизайну, інфраструктури та спеціалізації.

Коли «великий LLM» стає комодіті

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

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

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

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

Плюралістичний ентерпрайз: малі спеціалісти проти одного «суперагента»

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

Це видно навіть на прикладі нових продуктів IBM. Granite 4.1 виходить не як один «флагманський» LLM, а як сімейство: мовні моделі трьох розмірів (від 3 до 30 мільярдів параметрів), окремі візуальні моделі, сфокусовані на розумінні таблиць і графіків, компактні моделі мовлення для транскрипції й перекладу, нове покоління embedding-моделей. Усі вони спроєктовані не як «конкурент одному гіганту», а як набір функцій, які можна вбудовувати в більші агентні чи робочі потоки.

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

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

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

DiLoCo: як розв’язати AI від гігаватних дата-центрів

Якщо на рівні застосунків відбувається перехід до множинних спеціалізованих моделей, то на рівні інфраструктури назріває не менш радикальний зсув. Google DeepMind запропонувала підхід до розподіленого навчання під назвою DiLoCo — Distributed Low Communication, який напряму кидає виклик нинішній парадигмі «один гігантський кластер для frontier-моделі».

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

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

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

DiLoCo, за тими ж умовами, демонструє близько 88% goodput. Це означає, що система зберігає левову частку своєї теоретичної продуктивності навіть тоді, коли частина вузлів виходить із ладу або працює нестабільно. Для індустрії, яка витрачає мільярди доларів на GPU й енергію, така різниця — не косметична, а стратегічна.

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

Енергетичні межі AI: коли дата-центр потребує власної підстанції

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

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

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

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

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

Від монолітів до систем: нова стратегія масштабування AI

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

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

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

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

У цьому контексті навіть такі, на перший погляд, «вузькі» речі, як підтримка COBOL і mainframe-коду в IBM Bob, перетворюються на стратегічний актив. Для банків і великих фінансових інститутів, де в продакшені працюють трильйони рядків коду на старих мовах, можливість залучити AI до модернізації без повної заміни інфраструктури — це не просто фіча, а реальний місток між минулим і майбутнім.

Висновок: AI входить у епоху інфраструктурного реалізму

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

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

DiLoCo від Google DeepMind у цій картині — один із перших явних сигналів, що індустрія готується до життя в умовах жорстких інфраструктурних обмежень. А тренд на спеціалізовані моделі й системи оркестрації на кшталт IBM Bob показує, як цей зсув уже змінює архітектуру корпоративних AI-рішень.

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

Джерело

Granite 4.1, IBM Bob & building a quantum ecosystem — IBM Technology

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

Голос у терміналі «з коробки»

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

Основна логіка роботи:

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

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

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

Мовні обмеження за замовчуванням

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

Щоб зробити голосову взаємодію придатною для україномовних користувачів, потрібно змінити мовні налаштування в конфігурації Claude Code.

Як увімкнути українську мову розпізнавання

Перемикання мови відбувається через конфігураційне меню інструменту:

1. Викликати команду config у терміналі Claude Code.
2. Прокрутити список налаштувань до параметра language.
3. У полі language вручну ввести значення Ukrainian з клавіатури.

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

Навіщо це розробникам

Голосовий режим у термінальному інструменті для роботи з ШІ-агентом може стати корисним доповненням до звичного робочого процесу:

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

За умови правильно налаштованої мови розпізнавання українські розробники можуть повноцінно використовувати цей режим без втрати якості транскрипції.

Джерело

Повний огляд Claude Code – Частина 24 #аі #python #вайбкодинг

У світі, де «зробити агента» вже не проблема, а проблема — зрозуміти, що саме він робить, питання керованості й прозорості виходять на перший план. На воркшопі AI Engineer розробник-евангеліст n8n Ліам МакҐарріґл показує це на практиці, збираючи візуальний агент для керування Gmail і Google Calendar з людиною в циклі ухвалення рішень. За лаштунками красивого чату — дуже конкретні технічні рішення: як під’єднати різні LLM, як зберігати контекст діалогу, як дати моделі доступ до інструментів і водночас не перетворити її на «чорну скриньку».

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

Від OpenAI до OpenRouter: як n8n працює з різними LLM

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

AI Agent вимагає щонайменше одного обов’язкового параметра — чат‑моделі. І тут n8n поводиться радше як інфраструктурний шар, ніж як прив’язка до одного вендора. Інтерфейс дозволяє під’єднатися до кількох провайдерів LLM, а список підтримуваних сервісів не є жорсткою межею.

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

У демонстраційному воркшопі Ліам використовує OpenRouter як провайдера LLM. Це сервіс‑агрегатор, який дає змогу з однієї точки доступу обирати різні моделі. Для AI Agent він підбирає Claude Sonnet 4.6 — модель, яка виступає «мозком» агента, що спілкується з користувачем і викликає інструменти.

Щоб учасники могли швидко повторити конфігурацію, на супровідній сторінці в Notion тимчасово викладено API‑ключ OpenRouter. Це не жест безумовної щедрості, а радше практичний компроміс: ключ дозволяє всім стартувати без додаткових реєстрацій, але Ліам одразу попереджає, що після події він його відкличе. Такий підхід добре ілюструє загальний принцип роботи з LLM‑інфраструктурою: швидкий доступ для експериментів — так, але довгострокове використання має спиратися на власні облікові дані й контроль.

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

Пам’ять агента: від простого контексту до Postgres і Redis

Модель сама по собі — лише частина історії. Щоб агент поводився як послідовний співрозмовник, йому потрібна пам’ять. У n8n це не абстрактна «магія контексту», а чітко налаштований компонент AI Agent.

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

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

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

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

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

Інструменти під контролем: як n8n обмежує повноваження AI

Ще один критичний аспект керованого агента — інструменти. У n8n будь‑який звичайний вузол, наприклад Gmail чи Google Calendar, може стати AI‑інструментом, який агент викликає автономно. Саме так у демонстраційному прикладі модель отримує можливість читати листи, створювати події й керувати розкладом.

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

Це рішення здається дрібницею, але воно кардинально змінює модель ризиків. Наприклад, у вузлі Gmail можна дозволити моделі заповнювати тему й тіло листа, але заборонити змінювати список одержувачів або прапорці важливості. У вузлі Google Calendar — дозволити вибір дати й опису події, але не дати змоги моделі чіпати календар керівника компанії чи змінювати налаштування нагадувань.

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

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

Вирази та JavaScript: де low‑code зустрічається з повноцінним кодом

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

Система виразів підтримує зручні хелпери. Наприклад, функція now повертає поточну дату й час, що корисно для тайм‑стемпів, дедлайнів або логування. Доступні й стандартні функції JavaScript, зокрема Math.random, яку можна використати для генерації ідентифікаторів, випадкового розподілу навантаження чи A/B‑тестів усередині воркфлоу.

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

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

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

Керований агент замість «чорної скриньки»

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

Підтримка кількох LLM‑провайдерів і OpenAI‑сумісних API знімає залежність від одного вендора й дозволяє експериментувати з моделями без переписування воркфлоу. Пам’ять, винесена в окремий шар, дає змогу масштабуватися від простого контексту до інтеграції з існуючими базами даних. Система прав на рівні полів інструментів перетворює AI‑агента з потенційно небезпечного «суперскрипта» на керованого виконавця з чітко окресленими повноваженнями. А вирази з JavaScript дозволяють додати рівно стільки коду, скільки потрібно, не руйнуючи low‑code‑парадигму.

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

Джерело

Human-in-the-Loop Automation with n8n — Liam McGarrigle

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

Засновник tldraw Стів Руїз на прикладі кількох проєктів показує, як змінюється сама модель взаємодії людини з AI: від «чорної скриньки» в сайдбарі до прозорих, видимих агентів, чия логіка, стан і дії розгортаються прямо на канвасі.

Make Real: коли намальований макет стає працюючим прототипом

Поворотним моментом для tldraw став 2023 рік, коли з’явилися перші масові візійні моделі. Саме тоді команда показала Make Real — застосунок, що дозволяв користувачам намалювати інтерфейс на канвасі, надіслати цей малюнок моделі й отримати у відповідь працюючий прототип.

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

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

Сьогодні, у 2026‑му, подібні можливості вже не виглядають революційними. Але в 2023‑му ще не існувало ані популяризованого терміну «vibe coding», ані масових інструментів, які б дозволяли «накинути вайб» застосунку й отримати працюючу версію. Make Real став одним із ранніх прикладів того, як AI може зняти бар’єр між ідеєю й прототипом для людей без технічного бекграунду.

Важливо й те, що Make Real був побудований на канвасі tldraw, який сам по собі є «хакованим» рантаймом на React‑компонентах. Це означало, що будь-яка дія моделі — від розпізнавання намальованого до генерації коду — могла бути інтегрована безпосередньо в середовище, де працює користувач. Саме ця гнучкість згодом дозволила перейти від одноразової генерації до більш складних агентних сценаріїв.

Від «намалюй кота» до агентного циклу: AI як співробітник на канвасі

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

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

Цей підхід вирішував кілька проблем, характерних для візійних моделей, коли йдеться про структуровані дані. По‑перше, якісних датасетів для навчання візійних моделей значно менше, ніж текстових. По‑друге, візуальні й текстові уявлення про структуру часто конфліктують. Класичний приклад — вісь Y: у математичному графіку значення зростають угору, тоді як у веб‑координатах Y збільшується вниз від верхнього лівого кута. Додаємо сюди різні системи відліку «ліворуч‑праворуч», «stage left» тощо — і стає зрозуміло, чому моделі важко стабільно відтворювати складні діаграми лише з картинки.

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

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

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

Цей агентний loop виявився корисним не лише в експериментах tldraw, а й у сторонніх продуктах, побудованих на їхньому SDK. У дизайні його використали, зокрема, застосунки Love Art і Magic Path, де AI допомагає будувати композиції, структурувати контент і допрацьовувати макети. В освіті агентний цикл став основою для сценаріїв «тютора на канвасі»: модель може допомагати з домашніми завданнями, заповнювати форми чи, наприклад, автоматично завершувати аркуш персонажа для настільної гри на кшталт Dungeons & Dragons, орієнтуючись на вже внесені дані.

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

Феї на канвасі: коли агент стає персонажем

Радикальніша зміна відбулася, коли tldraw перетворила абстрактних агентів на візуальних персонажів — маленьких фей, які живуть безпосередньо на канвасі. Цей експеримент отримав окремий майданчик fairies.tldraw.com і став демонстрацією того, як може виглядати багатoагентна співпраця в середовищі, де все видно й людині, й самим агентам.

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

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

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

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

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

Лідер і команда: як працює багатoагентна координація

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

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

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

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

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

На fairies.tldraw.com цей підхід демонструється на реалістичних завданнях. Один із прикладів — великий текстовий опис застосунку, схожий на бриф для e‑book чи сервісу. Користувач виділяє фей, дає інструкцію «зробіть вайрфрейми для цього застосунку» й відпускає їх «у роботу». Далі можна спостерігати, як агенти розкладають опис на частини, створюють екрани, розміщують елементи інтерфейсу, узгоджуючи свої дії через лідера.

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

Освіта, дизайн і межі безпеки: де агентам можна дати більше влади

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

У дизайні, як уже згадувалося, його використовують застосунки на кшталт Love Art і Magic Path. Там AI допомагає структурувати композиції, будувати складні сцени, доповнювати макети, працюючи в тому ж середовищі, що й дизайнер. Агент може, наприклад, завершити діаграму, яку людина почала вручну, або запропонувати варіанти розміщення елементів.

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

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

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

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

Висновок: від магії до механіки співпраці з AI

Історія tldraw від Make Real до фей — це не лише про нові фічі в онлайн‑дошці. Це про зміну парадигми взаємодії з AI.

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

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

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

Джерело

Agents on the Canvas in tldraw — Steve Ruiz, tldraw

У час, коли демократичні інститути слабшають під тиском популізму, втоми та дезінформації, досвід малих країн із великими травмами стає особливо показовим. На сцені TED2026 шоста президентка Республіки Косово Вйоса Османі-Садріу поділилася тим, як історія її країни висвітлює ключові виклики для демократії — від геополітики до штучного інтелекту — і чому правда залишається головною технологією її виживання.

Від дитини війни до лідерки миру

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

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

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

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

Маленька держава в «великих кімнатах» рішень

Косово — країна з населенням менше двох мільйонів, але за останні роки воно досягло помітних політичних результатів: отримало безвізовий режим із ЄС та подало заявку на вступ до Євросоюзу. Це дало його лідерам доступ до переговорних столів, де ухвалюються рішення, що впливають не лише на Балкани, а й на глобальну безпеку.

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

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

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

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

ШІ, фейки й «кисень демократії»

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

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

Звідси — два ключові завдання для суспільств у добу ШІ:

1. Цифрова освіта громадян. Люди мають навчитися розрізняти:
2. контент, створений або змінений за допомогою ШІ;

3. достовірні свідчення та реальні історії тих, хто ухвалює рішення від їхнього імені.

4. Регулювання без «задушення» інновацій. Потрібні системи, які:

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

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

Технології, релігія й «беса»: коли людяність сильніша за режим

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

Кілька фактів, які підкреслює Османі-Садріу:

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

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

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

Демократія як нескінченний процес захисту

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

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

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

Джерело

What Kosovo Can Teach the World About Freedom | Vjosa Osmani Sadriu | TED

Особисті AI-агенти вже давно вийшли за межі «чат-бота в Telegram». Один із розробників OpenClaw, Radek Sienkiewicz, кілька місяців послідовно розширював повноваження свого агента — від простого чату до системи, яка читає пошту, керує файлами, оновлює себе вночі, стежить за власним «здоров’ям» і готує робочі відповіді клієнтам. Його досвід показує, як виглядає життя, коли «ключі від комп’ютера» віддають ШІ — але роблять це не стрибком, а десятками дрібних кроків.

Інкрементальний підхід: від одного каналу до «ключів від життя»

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

• старт з одного каналу (спочатку WhatsApp, потім Telegram, зараз Discord) — просто чат;
• додавання однієї простої задачі поверх цього каналу;
• ще один маленький workflow, ще одна автоматизація — і так далі.

Такий підхід дає дві важливі переваги:

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

Цей же інкрементальний принцип спрацював і на рівні участі в проєкті: від користувача — до людини, що час від часу надсилає pull request, а потім до мейнтейнера.

Знання в Obsidian як ядро: коли ШІ бачить усе

Переломний момент — підключення особистої бази знань. У цьому випадку це Obsidian з приблизно 3 000 markdown-нотаток:

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

Усе це стає доступним агенту через кілька рівнів пошуку й пам’яті:

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

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

Автоматичне збагачення закладок

Один із показових прикладів — робота з посиланнями, які раніше просто «гнили» в закладках:

1. Користувач кидає в «inbox» посилання — це може бути твітер-тред, стаття чи відео.
2. Агент:
3. аналізує вміст;
4. додає теги;
5. прописує контекст;
6. шукає, що вже є в базі знань на цю тему;
7. створює зв’язки з іншими нотатками.

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

Нічна зміна: що робить агент, поки ви спите

Між приблизно 3:00 і 6:00 ранку агент працює в «фоновому режимі», готуючи систему до нового дня. Серед типових задач:

• індексація всього вмісту (зокрема Obsidian і QMD-індексів);
• бекапи, щоб у разі збою втратити максимум кілька годин роботи;
• оновлення OpenClaw із власними скриптами:
• що можна оновлювати автоматично;
• що може зламатися і чому;
• як перевірити систему перед перезапуском;
• як гарантувати, що gateway повернеться онлайн.

У підсумку вранці користувач отримує:

• оновлену систему;
• свіжі індекси;
• готові дайджести пошти й календаря (якщо вони налаштовані).

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

Три типи роботи агента: фон, фільтрація уваги й виконання

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

1. Ambient operations: технічна «сантехніка» системи

Це все, що:

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

Сюди входять:

• оновлення;
• резервні копії;
• реіндексація;
• технічні перевірки «здоров’я» системи.

LLM тут часто взагалі не потрібна — достатньо скриптів «якщо сталося X — зроби Y».

2. Фільтрація уваги: що справді важливо просто зараз

Один із найпрактичніших шарів — attention filtering. Агент має доступ до:

• пошти;
• календаря;
• бази знань в Obsidian (де зберігається контекст про проєкти, дедлайни, домовленості).

Це дозволяє йому:

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

Конкретні приклади:

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

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

3. Execution: коли агент не лише радить, а й діє

Третій тип роботи — виконання задач. Тут агент:

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

Для цього використовується набір Discord-каналів, кожен із яких відповідає певному типу роботи:

• #general — стартові розмови, з яких часто народжуються нові окремі канали;
• #inbox — посилання для поповнення бази знань;
• #consulting — робота з клієнтами, проєктами, комерційними пропозиціями, дедлайнами й наступними кроками;
• #video-research — дослідження YouTube-контенту для наступних епізодів;
• #briefing — ранкові брифінги;
• #instagram — підготовка постів для соцмереж;
• #youtube — допомога у створенні відео;
• #openclaw — задачі мейнтейнера;
• #playground — полігон для експериментів з моделями, workspace’ами й конфігураціями пам’яті.

Якщо експеримент у #playground виявляється вдалим, його «підвищують» до постійної частини системи. Якщо ні — просто відкидають.

Архітектура: LLM для судження, скрипти для дій, пам’ять як вузьке місце

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

LLM як «мозок» для судження

Модель використовується там, де потрібні:

• розуміння тексту (листи, нотатки, статті);
• побудова зв’язків між сутностями;
• прийняття рішень, що робити далі.

Приклади:

• визначити, чи лист терміновий;
• знайти релевантні нотатки в Obsidian;
• сформулювати чернетку відповіді.

Скрипти як «м’язи» для дій

Скрипти відповідають за:

• конкретні дії без потреби в «розумінні»;
• повторювані процедури (бекапи, оновлення, перевірки).

Формула проста: «якщо сталося X — зроби Y». У таких випадках LLM можна взагалі не залучати.

Пам’ять: soulm, agents.md і critical-rules.md

Окремий пласт роботи — оптимізація пам’яті:

• soulm — файл із «душею» агента (довгострокові установки й контекст);
• agents.md — опис агентів і їхніх ролей;
• critical-rules.md — файл із критичними правилами, які не можна ігнорувати.

На практиці виявилося, що:

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

Система пам’яті еволюціонувала:

• від одного великого memory-файла;
• до цілого memory-фолдера;
• із додаванням механізмів на кшталт «dreaming» — просування важливих спогадів.

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

Слабкі місця: погана пам’ять, крихкі автоматизації й «шумні» нотатки

Чим складніша система, тим більше в ній потенційних проблем. Серед головних викликів:

Погана пам’ять, що накопичує помилки

Якщо:

• пам’ять налаштована невдало;
• кількість нотаток і спогадів зростає до тисяч;

— помилки починають накопичуватися й підсилюватися. Це вимагає:

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

Крихкі автоматизації

Особливо небезпечні багатокрокові (10+ кроків) сценарії:

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

Рекомендації:

• ділити складні сценарії на простіші;
• додавати ефективні guardrails (перевірки, валідації, fallback-логіку).

«Шумні» нотатки

З часом у базі знань накопичуються:

• застарілі;
• дубльовані;
• малокорисні записи.

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

Слабкі межі й правила

Якщо:

• правила розмиті;
• файли на кшталт soulm і critical-rules.md не продумані;

— агент може:

• робити зайве;
• не робити критично важливого.

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

Оптимізація під «майбутнього себе»

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

Мислення виглядає так:

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

Завдання агента — стати союзником майбутнього «я»:

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

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

Джерело

YouTube: I Gave an AI Agent the Keys to My Life (Here’s What Happened)

Штучний інтелект росте швидше, ніж встигають змінюватися прайс-листи. За даними Stripe, топ‑100 AI‑компаній досягають позначки у 20 млн доларів ARR в середньому за 20 місяців — тоді як провідним SaaS‑гравцям для цього історично потрібно близько 65 місяців. На конференції AI Engineer фахівець Stripe з білінгових рішень Майянк Пант розповів, як платіжна платформа бачить нову епоху монетизації AI‑продуктів і чому гібридні моделі, кредити та чіткі метрики цінності стають стандартом.

Stripe протягом двох років досліджує ціноутворення AI‑компаній і паралельно будує для них інфраструктуру білінгу. На її рішення вже спираються Intercom, Lovable, ElevenLabs, OpenAI та Anthropic. З цього масиву даних і практики Stripe сформував п’ятиетапний фреймворк AI‑ціноутворення, в центрі якого — не собівартість GPU і не «місця» в інтерфейсі, а те, як клієнт сприймає цінність продукту.

Чому AI‑ціни більше не можуть бути «як у SaaS»

Класичний SaaS десятиліттями жив на передбачуваних 80–85% валової маржі. Витрати були стабільними, а моделі «плата за користувача» чи фіксована підписка добре працювали для софту з відносно рівномірним використанням.

В AI‑бізнесі картина інша. Собівартість безпосередньо залежить від інференсу моделей, а отже — від поведінки користувачів. За даними Stripe, 5–10% користувачів здатні «з’їдати» до 80% обчислювальних ресурсів. Для компанії це означає різкі коливання маржі, які важко закласти в просту підписку.

До цього додається ще кілька системних проблем. Третина AI‑бізнесів, які аналізує Stripe, прямо вказує на непередбачувані витрати на обчислення як на ключовий ризик. 41% зізнаються, що їм складно навіть чітко сформулювати, яку саме цінність вони доставляють клієнту. А 84% говорять, що встигають випускати нові AI‑функції швидше, ніж оновлювати під них ціни.

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

Саме тому Stripe фіксує різкий розворот ринку. Частка гібридного ціноутворення серед AI‑компаній зросла приблизно з 6% у 2024 році до близько 41%. Серед лідерів галузі використання гібридних моделей збільшилося приблизно у сім разів: 56% вже працюють за схемою, де базова фіксована плата поєднується з масштабованою платою за використання. Паралельно падає частка класичних seat‑ і subscription‑моделей, а outcome‑pricing поки залишається нішевим — близько 5% компаній.

П’ять кроків Stripe: починати з цінності, а не з токенів

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

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

Stripe пропонує дивитися на AI‑продукти через чотири базові типи цінності.

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

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

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

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

Stripe показує, що саме чітке формулювання такої цінності корелює з успіхом. 53% компаній з гіперзростанням (100%+ рік до року) мають прозоре value‑based ціноутворення, яке клієнт розуміє. Серед низькорослих компаній таких лише 26%. Іншими словами, здатність пояснити, за яку саме користь бере гроші AI‑продукт, виявляється не косметичною деталлю, а фактором зростання.

Від абстрактного «AI» до рахунку: charge‑метрики та кредити

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

Споживча (consumption‑based) метрика — це класичні для інфраструктурних сервісів API‑виклики, токени, хвилини аудіо, гігабайти оброблених даних. Вона добре корелює з витратами самої компанії: більше викликів — більше витрат на GPU. Для внутрішньої економіки це зручно, але для клієнта така метрика часто малоінформативна. Тисяча API‑викликів нічого не говорить про те, скільки презентацій, звітів чи згенерованих відповідей він отримає.

Метрика робочих процесів (workflow‑based) ближча до продуктового рівня. Це може бути кількість згенерованих зображень, підсумованих документів, створених презентацій, оброблених заявок. Вона краще відображає те, що користувач реально робить у продукті, і легше сприймається як «одиниця користі».

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

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

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

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

Гібридне ціноутворення як новий стандарт AI‑ринку

Коли цінність і charge‑метрика визначені, постає питання загальної моделі: як поєднати передбачуваність доходів, захист маржі та стимул до зростання використання? Досвід Stripe показує, що чисті моделі — лише підписка або лише usage — поступово відходять у минуле, а ринок переходить до гібридних схем.

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

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

Stripe фіксує, що саме гібридні моделі стають маркером зрілих AI‑бізнесів. Частка компаній, які використовують такий підхід, зросла з приблизно 6% до близько 41% за короткий період, а серед лідерів ринку — до 56%. Компанії, які роками жили на класичному SaaS‑прайсингу, але додають LLM‑функціональність, також змушені переглядати моделі: як тільки в продукті з’являється дорога інференс‑складова, фіксована підписка починає розмивати маржу.

Показово, що саме гнучкість у ціноутворенні корелює з високими темпами зростання. Stripe порівняв поведінку компаній з гіперзростанням (100%+ рік до року) та низькорослих гравців. У першій групі більшість змінювали ціни три й більше разів за останні два роки. У другій так робили лише 22%. Висновок Stripe однозначний: перша версія прайсу — це гіпотеза, а не догма, і здатність швидко її перевіряти та коригувати стає конкурентною перевагою.

Саме тому Stripe активно просуває usage‑based білінг як інфраструктуру, яка дозволяє AI‑компаніям запускати продукти швидко й безболісно міняти моделі. Intercom, Lovable, ElevenLabs, OpenAI, Anthropic — усі вони будують білінг на Stripe, використовуючи можливість комбінувати базові тарифи, usage‑компоненти, кредити й різні charge‑метрики без переписування всього стеку.

Як не спалити довіру: ліміти, нотифікації та rate‑limit

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

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

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

Другий інструмент — автоматичні нотифікації про використання. Stripe рекомендує інформувати клієнта, коли він досягає 50%, 70% і 90% від свого ліміту. Це не лише знижує ризик конфліктів через «неочікувані» рахунки, а й будує відчуття партнерства: сервіс не намагається «підловити» користувача, а допомагає йому керувати витратами. На цьому ж екрані можна запропонувати опції: разовий топ‑ап, автоматичне поповнення або пауза до наступного місяця.

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

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

Ціни як продукт: чому успішні AI‑компанії постійно їх змінюють

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

Це добре видно з даних про частоту змін цін. Серед компаній з гіперзростанням більшість переглядали моделі три й більше разів за два роки. Серед низькорослих — лише 22%. У світі, де AI‑функції, які сьогодні продаються як преміум, через пів року стають стандартом, фіксований прайс‑лист перетворюється на баласт.

Stripe фактично закликає AI‑компанії будувати інфраструктуру, яка дозволяє швидко тестувати нові моделі: змінювати charge‑метрики, перетасовувати кредити, додавати або прибирати usage‑компоненти, вводити нові guardrails. Саме для цього платформа розвиває usage‑based білінг як сервіс: щоб Intercom, Lovable, ElevenLabs, OpenAI, Anthropic та інші могли експериментувати з монетизацією так само швидко, як з моделями.

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

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

Висновок: монетизація AI — це про мову цінності, а не про токени

AI‑економіка росте швидко, але разом із нею росте й складність монетизації. Дешеві GPU закінчуються, «важкі» користувачі вибивають маржу, а клієнти не хочуть розбиратися в токенах і типах моделей. На цьому тлі Stripe пропонує просту, але вимогливу зміну оптики: починати не з внутрішніх витрат і не з копіювання SaaS‑шаблонів, а з того, як клієнт бачить цінність.

Чотири типи цінності — автоматизація, аугментація, розширений сервіс і покращені результати — дають мову, якою можна описати користь AI‑продукту. Charge‑метрики, кредити й гібридні моделі дозволяють перекласти цю користь у рахунки, які одночасно захищають маржу й зрозумілі клієнту. Guardrails — ліміти, нотифікації, rate‑limit — не дають цій гнучкості перетворитися на хаос.

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

Джерело

Mastering AI Pricing: Flexible & Agile Monetization — Mayank Pant, Stripe

У Лондоні на спільному воркшопі AI Engineer, Braintrust і Trainline розбиралися з тим, що насправді означає “довести AI до продакшену”. Не просто показати ефектний демо‑бот, а запустити складні багатокрокові агентні пайплайни з інструментами, реальними користувачами й усією притаманною цьому невизначеністю. У центрі цієї розмови — Braintrust, платформа спостережуваності та оцінювання AI, яку заснував Анкур Гоел, колишній засновник Impira (стартапу з витягання даних із документів, що згодом придбав Figma).

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

Платформа‑агностик: чому Braintrust не хоче замінити ваш стек

Сучасні AI‑команди дедалі рідше живуть у світі “однієї моделі й одного фреймворку”. У продакшені одночасно можуть працювати OpenAI, Anthropic, локальні LLM, спеціалізовані векторні бази, власні мікросервіси, а поверх цього — LangChain, LlamaIndex, власні агентні оркестратори чи внутрішні фреймворки. У такому середовищі будь‑який інструмент, який намагається “стати всім одразу”, швидко перетворюється на вузьке місце.

Braintrust принципово обирає іншу роль. Платформа описується як “platform‑agnostic” — вона не вимагає відмовлятися від наявних агентних фреймворків чи LLM‑провайдерів і не намагається їх замінити. Натомість Braintrust вбудовується поруч як шар спостережуваності та оцінювання, який:

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

Це важливий зсув у мисленні. Якщо класичні APM‑системи (на кшталт Datadog чи New Relic) стали стандартом для мікросервісів, то Braintrust намагається стати аналогом для AI‑додатків: не ще одним runtime, а шаром, який дозволяє бачити, що відбувається всередині агентів, і порівнювати різні конфігурації моделей, промптів та інструментів.

Для компаній на кшталт Trainline, Lovable чи Doctolib, які будують реальні, а не лабораторні AI‑сервіси, це означає можливість еволюціонувати стек без втрати контролю: змінювати LLM‑провайдера, додавати нові інструменти, перебудовувати агентні флоу — і при цьому зберігати єдину “панель приладів” для всієї системи.

Трейси до рівня токена: як побачити, що насправді робить агент

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

У класичному підході до логування AI‑систем розробники часто бачать лише “вхід‑вихід”: промпт, відповідь моделі, можливо, кілька метаданих. Цього достатньо для дебагу простих чат‑ботів, але абсолютно недостатньо, коли мова йде про агентів, які:

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

Braintrust розкладає цей “чорний ящик” на кроки. Для кожного запиту можна побачити:

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

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

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

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

Керовані промпти й інструменти: централізація того, що раніше “жило в коді”

Ще одна роль Braintrust у стеку — стати місцем, де живуть промпти та описані інструменти, якими користуються агенти. Платформа пропонує так звані “managed prompts” і “managed tool calls”, які можуть хоститися безпосередньо в інфраструктурі Braintrust.

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

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

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

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

Аналогічно з інструментами: замість того, щоб кожен сервіс по‑своєму описував, як агент має викликати той чи інший API чи внутрішній сервіс, Braintrust дозволяє оголосити “керовані tool calls” і хостити їх у себе. Це створює єдине джерело правди для того, як агенти взаємодіють із зовнішнім світом.

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

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

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

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

Щоб ефективно працювати з такими даними, Braintrust побудував власну спеціалізовану базу даних — Brainstorm. Вона оптимізована саме під зберігання й запити по трейсах у великому масштабі.

Це не просто технічна деталь, а відповідь на реальну проблему. Коли компанії намагаються зберігати AI‑трейси в загальних інструментах — від класичних лог‑сховищ до data warehouse — вони швидко впираються в обмеження:

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

Brainstorm, за задумом Braintrust, має закрити ці прогалини. Спеціалізація під трейс‑дані дозволяє:

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

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

Від Impira до Braintrust: досвід applied ML і enterprise‑воркфлоу

Історія компанії частково пояснює, чому Braintrust так фокусується на продакшен‑реаліях, а не на “іграшкових” демо. Засновник Анкур Гоел до цього будував Impira — стартап, що займався витяганням даних із документів і працював на перетині машинного навчання та корпоративних процесів. Зрештою Impira придбав Figma.

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

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

Це також пояснює, чому компанія від самого початку орієнтується на реальні продакшен‑кейси. Партнерство з Trainline, а також клієнти на кшталт Lovable і Doctolib у Європі — це не просто логотипи на слайдах, а приклади організацій, де AI‑системи мають працювати в умовах високих очікувань користувачів, регуляторних вимог і складної інфраструктури.

Серія B, $80 млн і європейський вектор

Попри відносно молодий вік — близько трьох років — Braintrust уже встиг пройти шлях до раунду Series B. Нещодавно компанія залучила 80 мільйонів доларів при оцінці 800 мільйонів. Серед інвесторів — Iconiq, a16z та Greylock, фонди, які традиційно роблять ставку на інфраструктурні компанії з потенціалом стати стандартом де‑факто у своїй категорії.

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

Окремий акцент — розширення присутності в Європі. На воркшопі в Лондоні Braintrust підкреслював, що активно будує локальну команду й працює з європейськими клієнтами. Trainline, Lovable, Doctolib — це компанії, які оперують у різних галузях (транспорт, споживчі сервіси, охорона здоров’я), але мають спільну потребу: запускати AI‑функції не як експерименти, а як частину основного продукту.

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

Чому саме зараз потрібен “спостережуваний” шар для агентів

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

Класична інженерна інтуїція — “додати логів” — у світі LLM і агентів виявляється недостатньою. Логи показують, що сталося, але не дають відповіді на питання “як” і “чому” на рівні внутрішньої логіки агента. Саме тут з’являється потреба в повноцінній спостережуваності:

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

Braintrust намагається закріпитися саме в цій ніші. Платформа‑агностик, яка не змушує переписувати стек, але дає можливість побачити й виміряти те, що раніше залишалося “магією” всередині LLM‑викликів. Керовані промпти й інструменти, власна база Brainstorm для трейсів, фокус на реальних продакшен‑кейcах — усе це елементи однієї стратегії: зробити складні агентні системи не лише можливими, а й керованими.

У міру того як компанії переходять від експериментів до масштабних впроваджень, питання “яку модель обрати” поступово відходить на другий план. Натомість на перший виходить інше: як побудувати інфраструктуру, яка дозволить змінювати моделі, інструменти й логіку без втрати контролю над системою. Braintrust претендує на роль такого інфраструктурного шару — невидимого для кінцевого користувача, але критично важливого для всіх, хто відповідає за якість і надійність AI‑продуктів.

Висновок: від демо до інфраструктури

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

Braintrust будує себе як “хребет” для таких систем: платформу спостережуваності й оцінювання, яка не прив’язана до конкретних моделей чи фреймворків, але дає глибоке розуміння того, що відбувається всередині агентних воркфлоу. Трейси до рівня токена, керовані промпти й інструменти, спеціалізована база Brainstorm, фокус на продакшен‑кейcах і підтримка інвесторів рівня Iconiq, a16z і Greylock — усе це вказує на те, що спостережуваність AI стає окремим, повноцінним шаром інфраструктури.

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

Джерело

Shipping complex AI applications — Braintrust & Trainline

Як з’являється новий SEO: генеративні пошукові системи змінюють гру для локального бізнесу

У 2026 році пошук клієнтів для малого бізнесу вже не обмежується Google. Контент-креаторка та підприємиця Марина Могилко (канал Silicon Valley Girl), яка веде подкаст про AI та бізнес, обговорює з топ-менеджерами Google та іншими інсайдерами, як штучний інтелект змінює те, як люди знаходять послуги — від стоматологів до подкастів. На цьому тлі народжується новий ринок: оптимізація під генеративні пошукові системи, або GEO (Generative Engine Optimization).

Йдеться не про черговий модний термін, а про практичну відповідь на просте запитання: як зробити так, щоб саме ваш бізнес з’являвся в відповідях ChatGPT, Gemini чи Perplexity, коли користувач питає «найкращий стоматолог у моєму місті»?

Від Google до ChatGPT: 33 мільйони бізнесів на роздоріжжі

У США близько 33 мільйонів малих бізнесів залежать від Google, щоб отримувати клієнтів. Десятиліттями це означало одне: працювати з SEO, локальними картами, відгуками, іноді — з Google Ads. Але поведінка користувачів змінюється.

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

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

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

Що таке GEO і чому воно не скасовує класичне SEO

Ідея GEO як бізнесу проста: використовувати вже доступні AI-пошукові інструменти — ChatGPT, Gemini, Perplexity — щоб зрозуміти, які бізнеси вони рекомендують, і допомагати локальним компаніям потрапити до цих відповідей.

На перший погляд може здатися, що це радикально нова гра, де старі правила SEO більше не працюють. Але віцепрезидент Google Search з продукту Роббі Стайн пояснює, що поведінка AI у ранжуванні насправді дуже схожа на людську логіку.

AI-моделі, які стоять за новими «AI Overview» та іншими функціями, фактично самі роблять пошук у Google як інструмент. Вони шукають сайти та матеріали, які виглядають корисними, зрозумілими й релевантними до запиту, а потім використовують їх у своїх відповідях.

Стайн підкреслює кілька важливих моментів.

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

По-друге, стандартні SEO-практики нікуди не зникають. Чіткий, корисний контент на сайті, оптимізований під запити користувачів, як і раніше, важливий. Різниця в тому, що тепер цей контент читає не тільки людина, а й модель, яка вирішує, що показати в AI-відповіді.

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

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

Reddit, LinkedIn, YouTube: нова «тріада» для AI-пошуку

Ще один важливий пласт GEO — це платформи, з яких AI-моделі найчастіше беруть інформацію. Серед топових джерел для багатьох споживчих чат-ботів і AI-пошукових інструментів виділяються три: Reddit, LinkedIn і YouTube.

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

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

Для локальних компаній це означає зміну стратегії. Бути лише в Google Maps і мати сайт уже недостатньо. Важливо з’являтися в контексті, який AI вважає авторитетним: у тематичних тредах на Reddit, у професійних постах на LinkedIn, у відеооглядах або освітніх роликах на YouTube.

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

Практика GEO: кейс подкасту та якість трафіку з LLM-пошуку

Те, що описує Google, уже підтверджується на практиці. Марина Могилко наводить приклад власного медіабізнесу. Кілька місяців тому її подкаст практично не з’являвся в пошуковій видачі. Замість того, щоб наймати дорогих SEO-консультантів, вона використала Claude — одну з провідних мовних моделей — для розробки стратегії SEO.

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

Цей кейс показує одразу кілька трендів.

По-перше, AI вже може виступати не лише об’єктом оптимізації, а й інструментом для її розробки. Моделі на кшталт Claude здатні аналізувати поточний стан сайту чи контенту, пропонувати структуру матеріалів, ключові теми й навіть формулювання, які краще відповідають пошуковим намірам.

По-друге, поріг входу в GEO та сучасне SEO загалом знижується. Людина без спеціальної освіти може, маючи базову дисципліну й доступ до AI-інструментів, реалізувати робочу стратегію.

По-третє, змінюється якість трафіку, який приходить через LLM-пошук. У випадку Могилко це особливо помітно на прикладі email-розсилки. Частина підписників почала приходити після того, як її ньюзлетер рекомендував ChatGPT. І ці люди поводяться інакше: їхній рівень відкриття листів сягає близько 80%, тоді як середній показник по базі — 40–50%.

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

GEO як сервіс: нова ніша для консультантів і агентств

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

Суть послуги може виглядати так. Спочатку аналізується поточна видимість бізнесу в генеративних системах: у ChatGPT, Gemini, Perplexity ставляться типові запитання на кшталт «найкращий стоматолог у [місто]» або «найкращий подкаст про [тема]». Якщо компанія не з’являється у відповідях, це стає відправною точкою.

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

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

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

Висновок: пошук стає розмовою, а GEO — необхідністю

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

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

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

Джерело

https://www.youtube.com/watch?v=gwsaC3WiCqs

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

Персоналізація під роль користувача

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

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

Імпорт проєктів і робочого контексту

Далі Codex дозволяє перенести вже наявні робочі процеси з інших сервісів. Ідеться про:

• проєкти з продуктивних або кодерських інструментів
• наявні робочі сесії чи історію взаємодії з іншими ШІ‑асистентами (зокрема згадується Claude)

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

Підключення календаря, пошти та робочих застосунків

Ключовий етап — налаштування плагінів і доступів. Codex можна дозволити:

• створювати документи, таблиці та презентації
• використовувати браузер і локальний комп’ютер
• працювати з календарем і електронною поштою
• інтегруватися зі Slack
• отримувати доступ до Google Drive

У описі продукту також згадуються Google Calendar, Gmail, Drive, Slack, Figma, Notion та інші популярні робочі сервіси. Після підключення Codex може взаємодіяти з усіма цими системами як єдиним середовищем — без ручного перемикання між вкладками й застосунками.

Перший практичний сценарій: бриф до зустрічі

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

Codex отримує завдання:

• знайти відповідну подію в Google Calendar
• підняти пов’язані листи в Gmail
• переглянути релевантні обговорення в Slack

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

За рахунок такого підходу Codex перетворює розрізнений робочий контекст на цілісну картину й дозволяє почати користуватися «повністю підключеним» середовищем буквально за 60 секунд.

Джерело

Bring your work into Codex in a few clicks — YouTube

У розмові на подкасті Lenny’s Podcast керівник продукту Notion Макс Шьонінг, колишній PM Google, очільник дизайну Heroku, дизайн‑лідер і інженер GitHub та дворазовий фаундер, формулює просту, але радикальну тезу: «перші 10% будь‑якого проєкту тепер безкоштовні». Йдеться не про знижки, а про те, як генеративний ШІ практично обнулив вартість старту — від перших прототипів до чорнових концепцій.

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

Що означає «перші 10% безкоштовні» на практиці

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

Сьогодні цю порожнечу заповнює ШІ. Моделі здатні за лічені хвилини видати:

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

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

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

Падіння бар’єру входу: більше спроб, менше відмовок

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

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

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

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

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

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

Як тільки людина робить перший крок і бачить, що може «керувати» новим матеріалом (у цьому випадку — кодом плюс ШІ), бар’єр зникає. Далі починається вже не питання «чи можу я це зробити», а «що саме варто робити».

Коли старт дешевий, головне — що продовжувати, а що вбивати

Як тільки перші 10% стають майже безкоштовними, змінюється місце, де виникає справжнє «тертя». Воно зміщується з етапу створення до етапу відбору й поглиблення.

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

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

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

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

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

Планування без довгих ТЗ: коли легше спробувати, ніж сперечатися

Більшість традиційних продуктово‑інженерних ритуалів будувалися на припущенні, що старт дорогий. Якщо кожна спроба — це тижні роботи, природно витрачати багато часу на:

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

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

Коли ж перші 10% безкоштовні, ця логіка ламається. Якщо можна за день зібрати кілька живих прототипів, довгі цикли написання ТЗ втрачають сенс. Легше:

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

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

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

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

Нове вузьке місце: не створити, а довести до надійного масштабу

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

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

Щоб пояснити цю різницю, Шьонінг використовує апаратну метафору. Є 3D‑друкований прототип — швидкий, дешевий, крихкий. І є масове виробництво — з точними допусками, перевіреними матеріалами, контрольованими процесами. Вони можуть виглядати схоже, але це різні світи.

Те саме відбувається й у софті:

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

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

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

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

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

Як змінюється роль людей: від скілів до судження й «агентності»

Коли ШІ робить базові скіли доступними «за запитом», природно постає питання: що тоді відрізняє тих, хто проривається вперед, від тих, хто лишається на узбіччі?

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

У корпоративному контексті він описує це фразою «drive Notion like it’s stolen» — керувати компанією, продуктом, своїм середовищем так, ніби ти маєш повне право на радикальні дії.

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

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

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

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

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

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

У підсумку нова продуктова формула виглядає так:

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

Джерело

Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Notion)