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

Засновник tldraw Стів Руїз, який розвиває стартап у Лондоні, показує, як проста безкоштовна візуальна дошка перетворилася на гнучкий canvas‑рушій, вбудований у Replit, Luba AI, Stitch та інші сервіси. І чому «хакований» canvas на React-компонентах виявився ідеальним середовищем для експериментів з агентами та новими інтерфейсами.

Від безкоштовної онлайн-дошки до лондонського продуктового стартапу

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

Але за цією простою оболонкою стоїть повноцінний продуктовий стартап, що базується в Лондоні. Команда не лише підтримує публічну дошку, а й розвиває tldraw як платформу: ядро продукту — це не стільки сам веб‑додаток, скільки canvas‑SDK, який можна вбудовувати в інші сервіси.

Це важливий зсув фокусу. Замість того, щоб конкурувати лише як ще один інструмент для візуальної колаборації, tldraw позиціонує себе як інфраструктуру для будь-яких продуктів, де потрібен інтерактивний, нескінченний, керований кодом canvas. Особливо це виявилося актуальним у контексті AI‑інструментів, яким потрібен простір для візуальної роботи моделей — від генерації UI до складних агентних сценаріїв.

Canvas як продукт: SDK, який вбудовують інші

Ключ до впливу tldraw — це його SDK. По суті, компанія «упаковує» свою дошку як бібліотеку, яку можна інтегрувати в інші веб‑додатки. Розробники отримують не просто компонент для малювання, а повноцінний canvas‑рушій із підтримкою форм, шарів, взаємодій і стану, який можна глибоко налаштовувати.

Цей підхід уже дав помітні інтеграції в AI‑екосистемі.

Replit, один із найпомітніших гравців у сфері AI‑розробки, використовує canvas tldraw у своєму агентному інтерфейсі. Їхній «agent canvas» — це не власноруч написаний рушій, а вбудований tldraw. На цьому полотні агенти Replit можуть будувати структури, візуалізувати ідеї чи інтерфейси, а користувачі — взаємодіяти з ними в реальному часі. Для Replit це спосіб швидко отримати надійний, гнучкий візуальний шар, не витрачаючи роки на розробку власного.

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

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

Вбудований у чужий UI: кейс Stitch та Angular‑додатків

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

Це важливий нюанс: tldraw не нав’язує повний перехід на свій стек чи дизайн‑систему. Його можна вбудувати як окремий режим або інструмент усередині вже існуючого продукту. У випадку Stitch це зроблено всередині Angular‑додатку — тобто React‑орієнтований canvas‑рушій живе в екосистемі іншого фреймворку.

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

Факт, що tldraw працює всередині Angular‑додатку, підкреслює його роль як незалежного canvas‑runtime, який можна «вмонтувати» практично в будь-який фронтенд‑стек.

Хакований runtime на React: чому це подобається AI‑інженерам

Технічна основа tldraw — це canvas‑runtime, побудований на React‑компонентах. Уся дошка — це, по суті, дерево компонентів: кожна форма, шар, інструмент — React‑компонент, який можна розширювати, перевизначати або підміняти.

Для розробників це означає кілька речей.

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

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

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

Саме ця комбінація — React‑компоненти, відкритий runtime‑API й орієнтація на візуальну структуру, а не на пікселі — робить tldraw привабливим для AI‑інженерів, які будують нові інтерфейси поверх моделей.

Від Make Real до агентів: чому canvas став природним середовищем для AI

Щоб зрозуміти, чому tldraw так добре «зчепився» з AI‑екосистемою, варто подивитися на один із ранніх експериментів — застосунок Make Real.

Make Real з’явився у 2023 році, коли тільки виходили перші vision‑моделі. Ідея була простою, але на той момент радикальною: користувач малює на canvas приблизний макет інтерфейсу, надсилає його моделі — і отримує працюючий прототип.

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

Користувачі могли не лише отримати HTML‑прототип, а й анотувати його прямо поверх canvas: змінювати кольори, вказувати правки, фактично будуючи складний prompt на основі вже згенерованого інтерфейсу. Це був ранній приклад того, як візуальний canvas може стати мовою спілкування між людиною та моделлю.

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

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

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

Canvas як спільний простір для людей і агентів

Сьогодні tldraw — це вже не просто місце, де люди малюють, а середовище, де одночасно працюють люди й агенти. На одному й тому ж canvas можуть співіснувати ручні замітки, автоматично згенеровані діаграми, прототипи інтерфейсів і дії AI‑агентів, які видно й зрозумілі користувачеві.

Це важливо з кількох причин.

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

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

По-третє, масштабованість. Оскільки canvas tldraw уже використовується в продуктах на кшталт Replit чи Luba AI, ці сервіси можуть будувати власні агентні сценарії поверх спільного рушія. Це створює ефект платформи: поліпшення в самому canvas (наприклад, у способах представлення об’єктів, керуванні станом чи інтеграції з моделями) автоматично відкривають нові можливості для всіх, хто його вбудував.

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

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

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

Лондонський стартап не обмежився створенням ще одного інструменту для спільної роботи, а перетворив свій canvas на SDK, який уже лежить в основі агентного інтерфейсу Replit, нового canvas Luba AI та режиму анотацій у Stitch, навіть усередині Angular‑додатка.

Хакований runtime на React‑компонентах робить дошку не просто візуальним віджетом, а платформою, де можуть працювати люди, моделі й агенти, які пишуть код проти відкритого API. У світі, де AI усе частіше виходить за межі текстових чатів, саме такі «невидимі» інфраструктурні шари визначатимуть, як виглядатимуть інтерфейси майбутнього.

Джерело

Agents on the Canvas in tldraw — Steve Ruiz, tldraw

Чому AI-стартапи ламають класичну SaaS-модель ціноутворення

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

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

Гіперзростання AI проти стабільного SaaS: різні швидкості, різні ризики

Stripe за останні два роки зібрав великий масив даних про компанії, що монетизують продукти на базі AI. Один із найяскравіших сигналів: топ-100 AI-компаній, які використовують Stripe, у середньому виходять на $20 млн річного повторюваного доходу (ARR) приблизно за 20 місяців. Для порівняння, топ-100 традиційних SaaS-компаній досягали тієї ж позначки за 65 місяців.

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

Історично SaaS-компанії жили в комфортній зоні відносно передбачуваної економіки: валова маржа на рівні 80–85% була нормою, а собівартість одиниці послуги змінювалась повільно. Інфраструктурні витрати були стабільними, а моделі ціноутворення — простими: фіксована підписка, тарифні плани за кількістю місць чи функцій.

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

Коли 10% користувачів спалюють 80% GPU: асиметрія, що вбиває підписки

Ключова структурна відмінність AI-бізнесів — у розподілі навантаження. За даними Stripe, у типового AI-продукту 5–10% користувачів можуть споживати близько 80% обчислювальних ресурсів. Це радикально відрізняється від класичного SaaS, де витрати на одного користувача були відносно рівномірними й добре прогнозованими.

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

Це не теоретична загроза. Третина AI-компаній, які аналізує Stripe, прямо називають непередбачувані витрати на обчислення однією з головних проблем. 33% AI-бізнесів у вибірці Stripe вказують, що саме непередбачувана вартість compute є для них суттєвим занепокоєнням. У практичному вимірі це означає: фінансові команди не можуть упевнено прогнозувати валову маржу, а кожен квартал може принести сюрпризи в собівартості.

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

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

Чому «місця» й ліцензії більше не описують цінність AI-продуктів

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

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

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

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

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

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

Цінова інерція як новий антиресурс: коли продукт біжить швидше за прайс

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

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

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

Stripe проаналізував, як частота змін ціноутворення корелює з темпами зростання. Серед компаній із гіперзростанням — понад 100% рік до року — значна частка змінювала прайс три й більше разів за останні два роки. У сегменті високого зростання таких 49%. Серед низькоростучих компаній лише 22% наважилися на три й більше переглядів ціноутворення за той самий період.

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

Кінець ери «чистого» SaaS-прайсингу: чому підписки й usage поодинці не працюють

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

За даними Stripe, частка компаній, які використовують гібридні моделі ціноутворення, за короткий час зросла приблизно з 6% до 41%. Якщо дивитися лише на лідерів серед AI-компаній, зростання ще різкіше: використання гібридного прайсингу збільшилося приблизно в сім разів, і нині 56% керівників AI-бізнесів говорять, що застосовують саме гібридні моделі.

Паралельно падає частка бізнесів, що покладаються виключно на підписку або виключно на usage-based підхід. Stripe прямо формулює висновок: чиста підписка й чиста оплата за використання в сучасних AI-продуктах рідко бувають достатніми.

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

Гібридні моделі намагаються поєднати сильні сторони обох підходів: базовий фіксований платіж як «якір» відносин плюс змінна частина, що масштабується з використанням або результатом. Саме такі конструкції нині будують на Stripe компанії на кшталт Intercom, Lovable, ElevenLabs, OpenAI та Anthropic. Показово, що навіть традиційні SaaS-провайдери, які додають LLM-функціональність до своїх продуктів, починають планувати перехід до гібридних моделей, оскільки класичний SaaS-прайсинг починає роз’їдати їхню маржу.

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

Як AI змушує переосмислити саму логіку монетизації

Усе це разом означає, що AI не просто додає новий тип продуктів до ландшафту SaaS. Він змушує переосмислити базові принципи монетизації.

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

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

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

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

Висновок: AI вимагає нової дисципліни ціноутворення

AI-економіка сьогодні — це поєднання гіперзростання й високої невизначеності. Компанії виходять на $20 млн ARR утричі швидше, ніж класичний SaaS, але роблять це в умовах, де 5–10% користувачів можуть споживати 80% обчислень, а третина бізнесів не може передбачити власні compute-витрати. У такому середовищі моделі підписок і тарифікації «за місце», які десятиліттями були стандартом, втрачають свою надійність.

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

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

Джерело

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

AI‑інструменти на кшталт Claude Code обіцяють будь‑кому — навіть без технічної освіти — можливість зібрати справжній продукт. Підприємець Остін Марчезе, який працює з неінженерними засновниками, демонструє це на практиці: разом із фаундером BDG Ніком, що не мав жодного досвіду програмування, він перебудував комерційний застосунок за 45 днів, поклавшись на Claude Code для кожної сторінки й кожної фічі.

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

Одна фраза без «і»: як змусити продукт сфокусуватися

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

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

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

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

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

Інженер проти пірата: де можна ламати, а де — ні

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

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

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

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

Щоб це розділення працювало й для AI‑асистента, Марчезе пропонує прямо навчити Claude Code відрізняти ці зони. Для цього він використовує файл Claude MD — свого роду технічну «пам’ять» про проєкт, яку модель отримує з кожним запитом. Спеціальний промпт оновлює цей файл, позначаючи критичні робочі потоки й додаючи інструкцію: попереджати перед будь‑якими змінами в цих ділянках.

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

Вивчити слова, а не синтаксис: чому словник важливіший за курс з JavaScript

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

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

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

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

Цей приклад Марчезе називає уроком, отриманим «по‑жорсткому». І робить із нього висновок: неінженерам не потрібно сідати за підручник з програмування, але їм варто інвестувати час у базову технічну лексику. Ті ж «web sockets», «modal», «card», «toast notification», «happy path» і «unhappy path», «responsive design» — це не жаргон для посвячених, а інструменти точного спілкування з моделлю.

Щоб знизити поріг входу, Марчезе підготував промпт, який, за його словами, охоплює близько сорока ключових технічних термінів. Його можна вставити в Claude Code, і модель сформує пояснення цих понять у контексті конкретного проєкту. Це не замінює системної освіти, але дає засновнику мінімальний словник, достатній для того, щоб AI‑інструмент перестав «вгадувати» і почав виконувати завдання так, як задумано.

AI‑коуч і ритуали безпеки: як вбудувати контроль якості в Claude Code

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

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

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

Другий рівень — автоматизований код‑рев’ю. У BDG команда створила в Claude Code дві обов’язкові команди: code review і prepare to deploy. Перша аналізує зміни в коді, виявляє потенційні проблеми, друга перевіряє, чи все готово до продакшн‑деплою: чи немає помилок, чи узгоджені міграції з фактичною схемою бази, чи не торкнулися випадково чутливих зон на кшталт автентифікації або платежів.

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

Третій рівень — зовнішній AI‑аудит. Щоб допомогти засновникам, які не впевнені в архітектурі свого проєкту, Марчезе створив безкоштовний плагін Claude Code на buildpartner.ai. Одна з його навичок — Claude coach — аналізує весь кодовий репозиторій і видає персоналізовані рекомендації: від технічних ризиків до слабких місць у ціннісній пропозиції продукту. Інша навичка, expert advice, оцінює саме value proposition, допомагаючи зрозуміти, чи не розмивається початкове «речення без “і”».

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

Як не грати в «битву з багами»: повторне використання замість копіювання

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

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

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

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

Висновок: AI як інженер, а не чарівна паличка

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

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

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

Джерело

YouTube — How I Built a $481k App With Claude Code (Beginner Strategy)

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

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

Чому «воно працює в демо» — ще не інженерія AI

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

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

На воркшопі прямо артикулюють кілька типових пасток:

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

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

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

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

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

Сесія в Лондоні побудована як покроковий практичний маршрут для інженерів, які хочуть не просто «погратися» з LLM, а навчитися їх шипити. Учасники підключаються до Slack-організації AI Engineer та публічного каналу «ai-engineer-europe-2026-braintrust-workshop», де отримують підтримку під час вправ. Для роботи потрібні безкоштовний акаунт у Braintrust і ключ OpenAI API.

Технічна основа — репозиторій на GitHub з усіма активами, Node.js v22, pnpm і make як обгортка для команд. Кожен етап воркшопу позначений окремим Git-тегом, тож учасники можуть у будь-який момент зробити checkout на конкретний чекпоінт і запустити робочу версію коду. Для тих, хто відстає, є детальний «cheat sheet» з покроковими інструкціями.

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

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

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

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

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

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

Від логів до спостережуваності: чому «бачити що» замало без «розуміти чому»

Один із центральних меседжів сесії — чітке розрізнення між базовим логуванням і повноцінною спостережуваністю (observability) для AI-систем.

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

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

Спостережуваність у такому контексті означає можливість:

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

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

пов’язувати зміни в промптах, конфігураціях або версіях моделей із конкретними змінами в поведінці системи;

виявляти системні режими відмов, а не лише поодинокі інциденти.

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

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

Flywheel AI-інженерії: як побудувати безперервний цикл покращень

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

Цей цикл складається з кількох повторюваних кроків.

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

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

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

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

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

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

Вигаданий агент сапорту як полігон для реальних проблем

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

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

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

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

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

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

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

Чому інженерія важливіша за «ідеальний» промпт

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

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

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

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

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

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

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

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

Джерело

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

Публічні технологічні компанії дедалі частіше стикаються з різкими обвалами капіталізації, і саме в такі моменти особливо гостро постає питання: як мотивувати засновника-CEO залишатися й боротися за розворот бізнесу. У подкасті 20VC with Harry Stebbings один із засновників публічної компанії розповів, як радикально перебудував власний пакет компенсації, щоб прив’язати свій дохід виключно до відновлення вартості акцій. Цей кейс оголює ширшу проблему — застарілу логіку оплати праці керівників-засновників.

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

Компанія вийшла на біржу у 2021 році. Акції піднялися до приблизно 40 доларів, а ринкова капіталізація виглядала вражаюче. Але вже у 2022-му ситуація кардинально змінилася: падіння приблизно на 92% і курс трохи нижче 4 доларів.

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

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

Радикальне вирівнювання інтересів: компенсація тільки за зростання

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

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

• базовий рівень: акція має піднятися щонайменше до 9 доларів, щоб узагалі почали діяти умови пакета;
• перший реальний поріг: приблизно 38–40 доларів за акцію — лише після подолання цього рівня CEO починає отримувати будь-яку компенсацію;
• подальші рівні: загалом 5–6 щаблів, що передбачають поступове зростання виплат у міру подальшого підвищення курсу;
• фінальна ціль: повернення до 80 доларів за акцію — ціни IPO — у визначений термін.

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

Чому логіка «засновник уже заробив» не працює

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

Автор кейсу називає таку логіку «повністю хибною» з кількох причин:

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

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

Як інвесторам варто переосмислити пакети для CEO-засновників

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

• Компенсація має бути умовною, але реально досяжною. Пороги на кшталт 38–40 доларів після падіння до 4 доларів — це амбітно, але не фантастично, якщо вірити в потенціал бізнесу.
• Структура з кількома рівнями краще за «все або нічого». Кілька щаблів (5–6 рівнів) дозволяють поступово винагороджувати прогрес, а не лише ідеальний результат.
• Важливий чіткий горизонт досягнення цілей. Наявність терміну, за який CEO має повернути акції до ціни IPO, створює зрозумілий таймлайн як для керівника, так і для інвесторів.
• Головний принцип — повне вирівнювання інтересів. Модель, де керівник «отримує тільки якщо зростає акція», знімає більшість питань щодо справедливості винагороди в очах ринку.

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

Джерело

YouTube: Investors need to give CEOs better comp packages

Штучний інтелект уже не виглядає як закрита територія для інженерів із Кремнієвої долини. У розмовах, які веде блогерка та підприємниця Марина Могилко (канал Silicon Valley Girl) з інвесторами, засновниками стартапів і топменеджерами на кшталт Ріда Гоффмана, постійно спливає одна й та сама думка: найцікавіші можливості сьогодні — це не абстрактні «AI‑стартапи майбутнього», а дуже конкретні, прикладні ролі. Одна з них — стати вузькоспеціалізованим AI‑консультантом для певної функції бізнесу або галузі.

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

AI як «співзасновник у кишені» і чому це відкриває нішу консультантів

За останні роки поріг входу в технологічний бізнес різко впав. Те, що в 2011‑му вимагало команди розробників і бюджету, сьогодні можна зробити за допомогою кількох AI‑сервісів. Марина згадує, як для найпростішого лендингу тоді потрібні були програмісти. Тепер же у підприємця буквально «в кишені» є умовний співзасновник, юрист, бухгалтер, вебдизайнер і маркетолог — у вигляді моделей на кшталт ChatGPT, Claude та інших.

Це не теоретичний тренд, а вже вимірюваний ефект. Показовий приклад — компанія Vise, що працює у фінансовій сфері. Її CEO Самір Васавада розповідає, що за три роки компанія скоротила штат із приблизно 150–160 людей до близько 40, при цьому ключові метрики бізнесу покращилися приблизно вдесятеро. Тобто менша команда, підсилена AI, показує результат, який раніше вимагав у кілька разів більше людей.

Паралельно інфраструктура для AI‑продуктів вибухово розвивається. Лише за один квартал Y Combinator інвестував близько 36 мільйонів доларів у стартапи AI‑агентів, а приблизно 60% кожного нового набору акселератора вже складають «AI‑native» компанії. Вони створюють інструменти — від агентів, що автоматизують бек‑офіс, до сервісів для аналітики й маркетингу.

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

Вузька спеціалізація замість «AI‑генераліста»: логіка Ріда Гоффмана

Рід Гоффман, співзасновник LinkedIn і один із найвідоміших інвесторів у Кремнієвій долині, формулює це дуже прагматично. Якщо людина сьогодні заробляє умовні 60–80 тисяч доларів на рік (або еквівалент у своїй країні) і хоче подвоїти дохід, найраціональніша стратегія — стати дуже сильною саме в застосуванні AI до конкретної сфери.

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

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

Ключова ідея — не просто навчитися користуватися AI‑інструментами, а:

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

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

«Бути знаходжуваним»: чому 30 днів кейсів у LinkedIn важливіші за холодні листи

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

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

Марина пропонує дуже конкретну тактику, яка, по суті, перетворює LinkedIn на вітрину вашої практики: 30 днів поспіль публікувати реальні кейси впровадження AI. Не абстрактні поради, а покрокові історії з цифрами й скриншотами.

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

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

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

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

Чому ця модель доступна без коду, офісу й капіталу

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

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

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

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

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

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

Як виглядає шлях спеціалізованого AI‑консультанта на практиці

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

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

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

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

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

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

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

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

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

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

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

Джерело

YouTube: 6 Profitable AI business ideas for 2026

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

Макс Шьонінг, head of product у Notion, колишній PM у Google, керівник дизайну в Heroku, дизайн‑лідер і частковий інженер у GitHub, а також дворазовий фаундер, пропонує радикальний зсув оптики: у світі, де навички дедалі легше «орендувати» в штучного інтелекту, справжнім кар’єрним «ровом» стає не скілсет, а агентність — внутрішня здатність діяти, ініціювати, змінювати середовище, а не просто працювати в його межах.

Коли всі навички «під рукою», скілсет перестає бути перевагою

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

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

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

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

Агентність як новий кар’єрний «ров»

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

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

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

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

«Drive Notion like it’s stolen»: як виглядає висока агентність

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

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

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

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

«Світ зроблений людьми не розумнішими за тебе»: ментальний злам, що відкриває двері

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

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

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

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

Агентність як щоденна практика, а не вроджена риса

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

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

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

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

Чому в епоху AI пасивність стає особливо небезпечною

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

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

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

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

Висновок: кар’єра як проєкт, а не як посада

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

Агентність у цій рамці — це:

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

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

Джерело

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

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

На відміну від модної гонитви за одним універсальним «супер-LLM», Granite 4.1 подається як сімейство моделей, що покриває мову, зір, мовлення та ембеддинги. У центрі — не «магія» генерації, а контрольованість, вартість і здатність вбудовуватися в складні робочі процеси підприємств.

Від моноліту до сімейства: що таке Granite 4.1

Granite 4.1 — це не одна велика модель, а ціла лінійка спеціалізованих компонентів. У реліз входять:

• мовні моделі трьох розмірів (від 3 до 30 млрд параметрів),
• візуальні моделі,
• моделі мовлення,
• нове покоління моделей ембеддингів.

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

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

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

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

Мовний блок Granite 4.1 — це три моделі від 3 до 30 млрд параметрів. Для ринку, де заголовки часто забивають моделі на сотні мільярдів параметрів, такі цифри можуть виглядати скромно. Але саме в цьому й задум: ці моделі мають бути достатньо потужними для більшості корпоративних задач, але при цьому відчутно дешевшими в інференсі.

Фокус налаштування — інструкційне слідування та виклик інструментів (tool calling). Тобто Granite 4.1 не намагається бути «творчим співрозмовником», а радше дисциплінованим виконавцем, який:

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

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

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

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

Зір без феєрверків: таблиці, графіки й документи замість «сай-фай» картинок

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

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

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

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

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

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

Мовлення на дієті: транскрипція й переклад у малому форм-факторі

Ще один блок Granite 4.1 — моделі мовлення, орієнтовані на транскрипцію та переклад. Тут IBM робить ставку на мінімізацію розміру моделей при збереженні високої якості.

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

• точній транскрипції аудіо,
• якісному перекладі,
• компактності й ефективності.

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

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

Ембеддинги як клей для корпоративного ІІ

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

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

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

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

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

Плюралістичні навантаження й кінець «ери одного гіганта»

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

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

У цьому контексті Granite 4.1 подається як відповідь на дві тенденції.

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

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

На цьому тлі Granite 4.1 і пов’язаний з ним стек IBM позиціонуються як інструменти для «token squeezing» чи «right sizing» — тобто для того, щоб використовувати токени ефективно, з правильним співвідношенням «вартість/користь». Спеціалізовані моделі беруть на себе рутину, а дорогі «фронтирні» моделі залучаються лише там, де їхня унікальна потужність справді потрібна.

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

Composable-архітектура: Granite 4.1 як будівельний блок

Хоча детальний розбір IBM Bob — агентного кодового асистента й системного партнера для розробки — виходить за межі цього матеріалу, у розмові Granite 4.1 постійно фігурує поруч із ним. Це показує, як IBM бачить свою ІІ-архітектуру загалом.

Bob описується як система мультимодальної оркестрації, яка маршрутизує задачі до різних моделей залежно від вартості й можливостей. Для складного міркування можуть використовуватися моделі на кшталт Mistral чи Granite у більшому розмірі, для дешевих завершень — менші чи спеціалізовані моделі, для безпекового аналізу — окремі fine-tuned фахівці. Granite 4.1 у цій картині — саме така сім’я фахівців.

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

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

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

У цьому сенсі Granite 4.1 — не просто «ще одна модель на ринку», а крок до більш зрілої, сервісно-орієнтованої фази розвитку корпоративного ІІ.

Висновок: Granite 4.1 як симптом дорослішання enterprise AI

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

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

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

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

Джерело

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

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

Стрибок у розробці: від підказок до повноцінних задач

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

Йдеться про сценарії на кшталт:

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

GPT 5.5 у таких випадках:

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

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

Пошук по документах без «догадок»

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

Ключові можливості:

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

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

Комп’ютер як сервіс: кліки, дашборди, робочі процеси

Ще один напрямок — computer use, тобто вміння моделі керувати застосунками та інтерфейсами від імені користувача.

GPT 5.5 може:

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

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

Єдине відчуття «іншої моделі» в усіх інтерфейсах

Зміни в GPT 5.5 відчуваються не лише в одному продукті. Оновлення поширюється на:

• ChatGPT — для звичайних користувачів;
• інструменти для коду (Codex);
• API — для розробників, які вбудовують модель у власні сервіси.

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

Джерело

GPT 5.5 Just Dropped and It’s a Different Kind of Upgrade — Tech With Tim

Штучний інтелект уже не просто «допомагає писати код» — він змінює саму суть професії розробника. Про це говорить Луї Найт-Вебб, засновник стартапу Vibe Canvas і лондонського осередку спільноти AI Tinkers, який встиг очолити SweeBench verified leaderboard навіть попереду OpenAI. У своїх експериментах з код-агентами він бачить чіткий тренд: люди все менше пишуть код руками і все більше займаються плануванням та перевіркою того, що генерує AI.

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

Коли «писати код» означає планувати й перевіряти

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

Поява GitHub Copilot змінила баланс, але не миттєво. Спочатку це були автодоповнення на рівні рядків, які економили хвилини, а не години. Потім з’явилися інструменти на кшталт ранніх версій Cursor, здатні дописувати цілі файли. Далі — більш потужні агенти на кшталт Claude Code, які можуть виконувати складніші зміни в кодовій базі.

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

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

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

Дві стратегії роботи з код-агентами: план проти рев’ю

У цій новій реальності Найт-Вебб виділяє два базові підходи до взаємодії з AI-агентами: план-орієнтований і рев’ю-орієнтований.

Перший можна описати як «спочатку думаємо, потім запускаємо». Другий — як «спочатку запускаємо, потім розгрібаємо».

План-орієнтований підхід: більше думати, менше виправляти

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

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

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

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

Рев’ю-орієнтований підхід: швидкий старт, довге виправлення

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

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

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

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

Фронтенд проти бекенду: де потрібен «людина в циклі»

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

Фронтенд-фічі: хаотичний світ, де плану мало

Фронтенд-фічер-девелопмент — це, за його спостереженнями, найменш придатна сфера для жорстко план-орієнтованого підходу. Причина — у природі фронтенду.

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

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

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

Бекенд, рефакторинги й міграції: територія плану й тестів

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

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

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

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

П’ять хвилин проти тридцяти: економіка уваги розробника

Ключова теза, яку він пропонує запам’ятати, звучить майже як правило великого пальця: п’ять хвилин планування економлять тридцять хвилин рев’ю AI-коду.

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

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

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

формулювати вимоги так, щоб їх міг зрозуміти як комп’ютер, так і людина;

бачити edge cases ще до того, як вони вистрілять у продакшені;

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

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

Коли агент працює довше за п’ять хвилин: нова логіка робочого дня

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

GitHub Copilot доповнює рядок за секунди. Ранні версії Cursor могли генерувати файл за кілька десятків секунд. Claude Code спочатку працював хвилину-дві, а тепер, за його словами, дає хороші результати при виконанні завдань протягом п’яти-десяти хвилин.

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

Це створює нову дилему: що робити розробнику, поки агент «думає»?

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

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

Паралельні агенти й нові інтерфейси для «менеджера AI»

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

У такій моделі робочий цикл виглядає інакше. Інженер:

запускає кілька агентів на різних задачах;

перемикається в режим рев’ю там, де агент уже закінчив;

поки він перевіряє одну задачу, інші агенти продовжують працювати;

щойно рев’ю завершено, наступний агент, імовірно, уже теж готовий до перевірки.

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

Саме з цієї логіки виріс проєкт Vibe Kanban, який Найт-Вебб почав будувати близько 14 червня 2025 року. Його мета була простою: зробити паралелізацію агентів тривіальною.

Інтерфейс Vibe Kanban пропонував бічну панель із кількома робочими просторами, кожен з яких міг запускати різні код-агенти — від Codex до інших популярних інструментів. Для кожного воркспейсу можна було дивитися дифи, залишати коментарі у стилі GitHub, відкривати прев’ю, змінювати дрібні деталі інтерфейсу.

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

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

Що означає «бути розробником», коли AI «з’їдає середину»

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

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

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

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

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

здатність мислити системно й наперед;

вміння будувати чіткі, машинно-читабельні спеки;

дисципліна в тестуванні й роботі з інваріантами;

організація власного часу й уваги в умовах паралельних агентних процесів.

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

Джерело

YouTube: Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban

Сучасні великі моделі штучного інтелекту вже демонструють вражаючі здібності до міркування, але все ще часто помиляються — і роблять це впевнено. Канал IBM Technology пропонує дивитися на проблему не як на «слабкий ШІ», а як на брак правильного контексту. Саме контекст‑інженерія, RAG, GraphRAG і точне (precision) отримання даних стають ключем до більш надійних, керованих і корисних систем.

Контекст як головний «вузький місце» ШІ

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

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

Різниця не в «розумності» моделі, а в тому, що вона отримала релевантний, дозований і керований контекст.

Контекст‑інженерія тут — це не просто «кращий промпт», а практика проєктування систем, які:

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

Чотири стовпи контекст‑інженерії

Щоб зняти «вузьке місце» контексту, системі потрібно вирішити одразу кілька інфраструктурних задач. Дані розкидані по базах, документ‑сховищах, SaaS‑платформах, хмарі й on‑premise, мають різну структуру, різну «свіжість» і різні права доступу. На цьому тлі контекст‑інженерія спирається на чотири ключові елементи.

1. Під’єднаний доступ (connected access)

ШІ має «бачити» весь дата‑ландшафт організації, не копіюючи все в один монолітний сховище. Підхід zero‑copy federation означає:

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

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

2. Шар знань (knowledge layer)

Сирі дані рідко є корисним контекстом самі по собі. Потрібен шар, який:

• виконує розв’язання сутностей (entity resolution) між системами;
• будує ієрархії та зв’язки між об’єктами;
• додає семантику, «інституційну пам’ять» і сліди прийняття рішень.

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

3. Точне отримання (precision retrieval)

Більше контексту не означає кращий контекст. Надмір даних перетворюється на шум і погіршує відповіді. Точне отримання означає:

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

Ідея проста: максимум сигналу, мінімум шуму.

4. Керування на етапі виконання (runtime governance)

Політики доступу мають застосовуватися не лише «на папері», а в реальному часі:

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

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

Від базового RAG до GraphRAG та контекст‑компресії

Перший досвід інтеграції зовнішніх даних у ШІ зазвичай починається з класичного RAG (Retrieval‑Augmented Generation). Але для складних сценаріїв цього вже недостатньо.

Базовий RAG: стартова точка

Стандартний RAG працює так:

1. Документи розбиваються на фрагменти (chunking).
2. Кожен фрагмент перетворюється на вектор (embedding).
3. Під час запиту виконується пошук за схожістю у векторному просторі.
4. Найбільш релевантні фрагменти додаються до промпту моделі.

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

Agentic RAG: ітеративний пошук контексту

У agentic RAG з’являється «агентність» — система не обмежується одним запитом до сховища:

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

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

GraphRAG: контекст через граф зв’язків

GraphRAG додає до картини графову структуру знань. Замість запитання «які документи семантично схожі на мій запит?» система може питати:

• «які сутності пов’язані з цим клієнтом?»;
• «які документи стосуються цих сутностей?».

Граф:

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

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

Контекст‑компресія: менше шуму, більше користі

Навіть із великими контекстними вікнами моделей залишається обмеження: надто багато даних погіршує якість відповіді. Контекст‑компресія вирішує це:

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

Мета — доставити моделі «худий, але поживний» контекст, який максимально відповідає запиту.

Коли модель упирається не в «інтелект», а в контекст

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

Система з «контекстуальним інтелектом»:

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

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

Джерело

How RAG, GraphRAG, and Context Engineering Improve AI Performance — IBM Technology

У світі, де “зробити агента на LLM” стало майже тривіальним завданням, справжнім викликом стає контроль над тим, що саме цей агент робить. На цьому тлі цікаво виглядає n8n — платформа, яка з’явилася ще у 2019 році як інструмент для інтеграцій та автоматизації, задовго до ChatGPT та нинішньої хвилі захоплення великими мовними моделями. Сьогодні n8n позиціонує себе як візуальний, low‑code оркестратор, де AI — лише один із потужних інструментів, а не вся історія.

Про те, як влаштований n8n, як працює його візуальна модель workflow’ів і чому проєкти та керування обліковими даними стають критично важливими, розповідає розробник‑євангеліст n8n Ліам МакҐарріґл у воркшопі на каналі AI Engineer. На прикладі простого агента для Gmail та Google Calendar він показує не стільки “магію AI”, скільки фундамент платформи, що дозволяє будувати керовані, прозорі автоматизації.

Витоки до ChatGPT: n8n як інтеграційний конструктор

Сьогодні n8n часто асоціюють із AI‑агентами, але платформа народилася в зовсім іншому контексті. У 2019 році, коли про ChatGPT ще не йшлося, n8n стартував як класичний інтеграційний workflow‑інструмент: low‑code спосіб з’єднати різні сервіси за принципом “якщо сталося X — зроби Y, потім Z”.

Базова модель виглядала просто й знайомо для всіх, хто працював з інтеграціями: є три ключові типи елементів — тригери, дії та вузли керування потоком. Тригери запускають workflow: це може бути відправлена форма, вебхук, запланований час, вхідний API‑запит чи подія в сторонньому сервісі. Далі йдуть дії — створити контакт у Google Contacts, надіслати лист, записати ліда в Salesforce тощо. Між ними — контроль потоку: розгалуження “якщо/інакше”, умови, гілки для різних типів даних.

Фактично це була абстракція над API‑викликами: замість писати код, користувачі “малювали” логіку на полотні, з’єднуючи вузли. Саме ця прозорість і керованість — можливість бачити, що саме відбувається на кожному кроці, — стала тим, за що багато хто полюбив n8n ще до ери генеративного AI.

Коли ж великі мовні моделі стали масовим інструментом, n8n не довелося вигадувати себе заново. Платформа вже була оркестратором подій та інтеграцій. Додавання AI‑вузлів стало логічним продовженням: тепер замість простої логіки “якщо/то” можна було вбудовувати в ті ж самі workflows агентів, які приймають рішення, працюють з текстом і викликають інші інструменти.

Візуальний low‑code: як працює модель workflow’ів n8n

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

У центрі цієї моделі — три типи вузлів.

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

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

По‑третє, контроль потоку. Тут n8n виходить за межі простого “з’єднувача” API. Умовні вузли дозволяють будувати розгалуження: наприклад, якщо контакт особистий — створити його в Google Contacts, якщо бізнесовий — відправити в Salesforce. Можна будувати складні сценарії з кількома гілками, перевірками, циклами. Для розробників це виглядає як візуалізований код із умовами та логікою, але для нетехнічних користувачів — як зрозуміла блок‑схема.

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

Low‑code, але не no‑code: де в n8n з’являється JavaScript

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

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

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

Такий підхід знімає типову напругу між “no‑code” та “для розробників”. n8n не змушує всіх вчити JavaScript, але й не обмежує тих, хто хоче вичавити з платформи максимум. У результаті одна й та сама система може бути корисною як для бізнес‑користувачів, так і для інженерів, які будують складні інтеграції.

Від особистого простору до команд: проєкти, доступи й облікові дані

Коли автоматизація виходить за межі особистих експериментів і потрапляє в корпоративне середовище, питання безпеки та розмежування доступів стають критичними. Саме тут у гру вступає концепція проєктів у n8n Cloud та Enterprise.

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

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

По‑перше, ізоляція облікових даних. Якщо одна команда працює з маркетинговими інтеграціями, а інша — з внутрішніми фінансовими системами, їхні креденшали не повинні перетинатися. У межах проєкту можна тримати власний набір доступів до Google, CRM, баз даних тощо, не ризикуючи випадково використати “чужий” ключ у невідповідному workflow.

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

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

Важливий нюанс полягає в тому, як саме працюють облікові дані в цьому контексті. У n8n Cloud існує поняття глобальних креденшалів — це облікові дані, які створюються на рівні акаунта, а потім можуть бути вибірково “розшарені” в конкретні проєкти. На домашньому екрані є розділ Credentials, де користувач може керувати цими глобальними доступами й вказувати, в які проєкти вони мають бути видимі.

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

UX дрібниць: як працює інтерфейс керування креденшалами

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

У розділі Credentials кожен запис — це конкретний набір доступів: наприклад, OAuth‑підключення до Google, API‑ключ до OpenRouter чи токен до Slack. Якщо користувач натискає на назву вже існуючого креденшалу, n8n відкриває його в режимі редагування. Це логічно: клік по імені означає, що ви хочете змінити або переглянути саме цей запис.

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

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

Від тригерів до агентів: як n8n інтегрує AI у свою модель

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

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

Окремо існує ChatHub — повноцінний чат‑інтерфейс усередині n8n. Щоб зробити workflow доступним у ChatHub, у налаштуваннях чат‑тригера достатньо поставити галочку “Make available in ChatHub” і опублікувати workflow. Після цього в боковій панелі з’являється іконка чату, а в ChatHub можна обрати потрібний workflow і спілкуватися з ним як із окремим агентом. Для продакшн‑сценаріїв чат можна винести в зовнішні системи на кшталт Slack, але для розробки вбудований інтерфейс спрощує життя.

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

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

У воркшопі як провайдер використовується OpenRouter, а серед моделей обрано Claude Sonnet 4.6. Але з точки зору n8n це лише один із варіантів: платформа виступає як шар оркестрації, який дозволяє підміняти моделі, не змінюючи загальну логіку workflow.

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

Контроль замість “чорної скриньки”

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

n8n, завдяки своїм витокам як інтеграційного інструменту, підходить до AI з іншого боку. Тут агенти — це ще один тип вузлів у вже знайомій моделі workflow’ів. Кожне виконання можна відкрити в розділі Executions і побачити, які кроки пройдено, які дані передавалися між вузлами, де логіка розгалужувалася. Для чат‑тригерів видно навіть конкретні повідомлення, які запустили workflow.

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

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

Висновок: платформа оркестрації в епоху AI

Історія n8n показує, як інструмент, створений для “нудних” інтеграцій, може виявитися особливо доречним у часи AI‑гіпу. Стартувавши у 2019 році як low‑code платформа для зв’язування сервісів, n8n поступово еволюціонував у візуальний оркестратор, де AI‑агенти — лише один із типів вузлів, а не центр всесвіту.

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

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

Джерело

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

Інструменти на базі штучного інтелекту поступово змінюють не лише програмування, а й дизайн-процеси. Один із таких прикладів — робота з зображеннями в Claude Code, про можливості якого розповідає канал KODARIK. Мова не про генерацію картинок з нуля, а про більш практичний сценарій: використання готових референсів для створення нових рішень у тому ж стилі.

Робота із зображеннями: простий вхід у візуальний контекст

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

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

AI як помічник для дизайнерів

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

1. Зробити скріншот потрібного дизайну.
2. Завантажити його в Claude Code.
3. Сформулювати запит на кшталт: «Створи схожий».

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

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

Від натхнення до технічного завдання

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

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

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

Джерело

Повний огляд Claude Code – Частина 25 — YouTube