Ринок AI‑інструментів для розробників стрімко зростає, а компанії змагаються за те, щоб першими запропонувати «розумні» агентів для написання коду. Та співзасновник OpenCode Дакс Раад у розмові з каналом The Pragmatic Engineer тверезо оцінює ситуацію: попри хайп, жоден гравець не «ламає гру» завдяки ШІ — і сам ШІ не розв’язує ключові проблеми на ранніх етапах створення продукту.

До product-market fit: ШІ майже не допомагає

Раад підкреслює, що на етапі до product-market fit — коли команда ще шукає, який саме продукт будувати і для кого — штучний інтелект дає обмежену користь. Основна причина проста: головна робота тут відбувається не в коді, а в головах засновників і команди.

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

AI як інструмент, а не магічна перевага

Попри те, що OpenCode працює саме в сегменті «coding agents» — де всі гравці активно інтегрують ШІ, — Раад не відчуває, що хтось отримав недосяжну перевагу завдяки кращому використанню AI.

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

Це свідчить про те, що:

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

Міф про «AI‑розрив», якого поки що немає

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

Це ставить під сумнів популярну тезу про те, що «хто першим опанує ШІ, той забере весь ринок». Натомість формується більш приземлена картина: штучний інтелект стає новим стандартом інфраструктури, подібно до хмарних сервісів чи CI/CD, — важливим, але не єдиним фактором успіху.

Джерело

YouTube: Dax Raad: “None of our competitors are crushing us with AI”

У новому випуску подкасту Security Intelligence від IBM Technology через просту дитячу гру пояснюють одну з ключових проблем сучасної кібербезпеки: вразливості дедалі частіше виникають не в окремих системах, а «між ними» — у взаємодії інструментів та AI‑агентів.

Вразливості в проміжках, а не в коді

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

Як у грі «зіпсований телефон», де початкове слово «crowd» перетворюється на «clown», а потім на «clone», критичні помилки народжуються не в одному місці, а в ланцюгу передавання. Кожен учасник окремо може діяти «правильно», але сукупний результат виявляється спотвореним.

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

AI‑агенти, що працюють разом, — більше шансів для атак

Сучасні AI‑системи дедалі частіше:

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

Кожен перехід між агентами або інструментами — це «шепіт» у грі «телефон». На цих стиках можуть виникати:

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

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

Чому традиційні підходи до безпеки не вистачає

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

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

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

Що це означає для практики кіберзахисту

З огляду на зростання ролі AI‑агентів, організаціям доведеться зміщувати фокус:

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

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

Джерело

Cybersecurity’s Telephone Game Problem📞 — IBM Technology

У новому випуску подкасту Mixture of Experts від IBM Technology ведучий Тім Хван разом із інженерами IBM обговорює один із найнезвичніших сюжетів у сучасному ШІ: повідомлення про те, що модель OpenAI запропонувала розв’язок до 78‑річної задачі з комбінаторної геометрії — так званої planar unit distance problem, або «площинної задачі про одиничні відстані» Пола Ерьоша. На тлі розмови про агентні системи, контрольні площини та операційні ризики, саме цей математичний кейс стає тестом на те, чи здатні передові моделі до справжньої творчості, а не лише до витонченого наслідування патернів.

Що таке planar unit distance problem і чому вона важлива

Площинна задача про одиничні відстані була сформульована Полом Ерьошем ще 1946 року й відтоді залишалася відкритою. Її формулювання звучить deceptively просто: маємо n точок на площині. Яка максимальна кількість пар точок може бути розташована на відстані рівно 1 одиниця одна від одної?

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

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

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

Конфігурація проти квадратної ґратки: що стверджує OpenAI

У подкасті planar unit distance problem з’являється як один із трьох головних сюжетів випуску. На відміну від обговорення корпоративних агентів чи ризиків frontier‑моделей, тут мова йде про чисту математику. OpenAI, за словами учасників дискусії, заявляє, що їхня модель знайшла конфігурацію точок у площині, яка перевершує те, що тривалий час вважалося оптимальним — квадратну ґратку.

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

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

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

Між творчістю та патерн‑матчингом: що саме робить модель

Саме planar unit distance problem у розмові використовується як лакмусовий папірець: чи справді передові моделі демонструють елементи математичної творчості, чи ми маємо справу лише з надзвичайно потужним патерн‑матчингом?

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

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

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

Як ШІ‑конструкції змінюють математичну практику

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

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

По‑друге, змінюється баланс між емпіричним і теоретичним. У випадку з planar unit distance problem модель може спочатку дати «емпіричний» результат: ось конфігурація, ось підрахунок пар на відстані 1. Далі математики можуть спробувати зрозуміти, чому ця конструкція працює, чи можна її узагальнити, чи існує строгий доказ того, що вона оптимальна в певному діапазоні n. Виходить своєрідний цикл: ШІ пропонує приклад, людина формулює гіпотезу, потім або людина, або формальна система доведення намагається цю гіпотезу підтвердити.

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

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

Від теорем до підприємств: спільні можливості одних і тих самих моделей

Один із найцікавіших моментів дискусії — контраст між двома дуже різними сценаріями використання одних і тих самих frontier‑моделей. З одного боку — чиста математика й planar unit distance problem як тест на творчість. З іншого — цілком прагматичні enterprise‑кейси, де ті ж моделі працюють як агенти, що виконують завдання в бізнес‑процесах, і де IBM будує навколо них watsonx agentic control plane.

У корпоративному контексті IBM описує ситуацію, коли в організаціях уже сьогодні працює від 60 до 200 «некерованих» агентів — експериментальних чат‑ботів, автоматизованих помічників, внутрішніх інструментів, розгорнутих різними командами без єдиної системи управління. На це накладається регуляторний тиск, зокрема з боку Європейського акта про штучний інтелект, і зростання витрат на моделі. Відповіддю стає агентна контрольна площина, яку IBM концептуально порівнює з Kubernetes для контейнерів: окремий контрольний шар для ідентичності, політик, спостережуваності та життєвого циклу, і окремий дата‑плейн, де агенти виконують виклики до LLM і інструментів.

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

На перший погляд, це зовсім інший світ, ніж комбінаторна геометрія. Але в обох випадках йдеться про одні й ті самі базові можливості моделей: здатність працювати в складних просторах станів, генерувати нетривіальні рішення й адаптуватися на основі зворотного зв’язку. У planar unit distance problem ця здатність проявляється як пошук нової геометричної конфігурації. В enterprise‑агентах — як уміння оркеструвати інструменти, приймати рішення під невизначеністю й оптимізувати поведінку на основі спостережень.

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

Люди, машини й межі довіри

Обговорення planar unit distance problem природно переходить у розмову про довіру до ШІ‑систем. В enterprise‑контексті IBM наголошує: навіть якщо протоколи на кшталт MCP стандартизують автентифікацію, передачу даних і формати, базова проблема не зникає. Агенти залишаються ймовірнісними машинами, які не можна вважати повністю контрольованими чи достатньо надійними, щоб без обмежень допускати їх до критичних даних.

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

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

Висновок: planar unit distance як пролог до нової епохи математики

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

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

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

Джерело

Mixture of Experts — Agent control planes & OpenAI model solves Erdős

IBM продовжує розкривати деталі своєї стратегії навколо керування AI‑агентами в підприємствах. У подкасті Mixture of Experts інженери IBM, зокрема головний архітектор watsonx Orchestrate Міхай Кріветі, обговорюють, як компанія намагається звести докупи розрізнені агентні фреймворки, гібридні інфраструктури та нові відкриті стандарти. У центрі цієї стратегії — платформа watsonx Orchestrate та агентний control plane, які мають зробити з «випадкових актів AI» керовану, інтероперабельну систему.

Від «легко зібрати» до «важко керувати»: чому платформа важливіша за окремих агентів

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

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

У такій ситуації головне завдання зміщується з «як швидко зібрати агента» до «як керувати сотнями агентів, не втрачаючи контроль над безпекою, даними та витратами». Саме тут IBM позиціонує watsonx Orchestrate та агентний control plane як інфраструктурний рівень, що має стати для агентів тим, чим Kubernetes став для контейнерів.

Control plane для агентів: аналог Kubernetes, але для ймовірнісного ПЗ

IBM прямо проводить аналогію: агентний control plane для AI‑агентів — це концептуальний двійник control plane Kubernetes для контейнерів. Як колись Docker породив хаос із контейнерами, розгорнутими «де завгодно», так сьогодні підприємства опинилися в ситуації з «60–200 випадковими актами AI», розкиданими по організації.

Архітектурно IBM розділяє два ключові шари.

Перший — control plane. Тут зосереджені ідентичність агентів, політики доступу та безпеки, інлайнова перевірка політик, спостережуваність, життєвий цикл, а також механізми на кшталт детермінованих «kill‑switches» для зупинки небажаної поведінки. Саме цей шар відповідає за те, щоб агент не виходив за межі дозволеного: не забирався до заборонених джерел даних, не порушував політики щодо PII/PHI, не генерував неконтрольовані витрати.

Другий — data plane. Тут агенти безпосередньо виконують виклики до LLM, звертаються до інструментів, працюють із протоколами на кшталт Model Context Protocol (MCP), формують структуровані відповіді, викликають зовнішні сервіси. Усе, що стосується «роботи» агента, відбувається саме тут, але під постійним наглядом control plane.

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

Гібридність як норма: air‑gapped, on‑prem, multi‑cloud через OpenShift

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

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

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

По‑третє, підтримується гібридний режим і multi‑cloud через OpenShift. Завдяки використанню OpenShift як базового шару оркестрації, watsonx Orchestrate може бути розгорнутий поверх різних гіперскейлерів і приватних кластерів, забезпечуючи єдину модель керування агентами незалежно від того, чи працюють вони в AWS, Azure, Google Cloud чи в приватній хмарі. Для багатьох глобальних компаній це критично: різні регіони можуть мати різні вимоги до розміщення даних, а бізнес‑підрозділи — різні хмарні стратегії.

Такий підхід дозволяє не лише задовольнити регуляторні вимоги, а й уникнути «vendor lock‑in» на рівні як інфраструктури, так і моделей. Агенти можуть використовувати різні LLM‑постачальники, але при цьому залишатися під єдиним control plane з однаковими політиками, логуванням і спостережуваністю.

Від LangGraph до власних сервісів: як Orchestrate підтягує зовнішніх агентів

Ще одна принципова ставка IBM — не змушувати клієнтів переписувати вже створених агентів під власний фреймворк. watsonx Orchestrate задуманий як платформа, що вміє працювати з агентами, побудованими в інших екосистемах, і при цьому підпорядковувати їх єдиному control plane.

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

По‑друге, платформа підтримує підключення до зовнішньо розміщених агентів через кілька типів інтерфейсів. Це можуть бути шлюзи (gateway), які виступають проксі‑шаром між внутрішнім середовищем і зовнішнім агентом, Model Context Protocol (MCP) як стандартний спосіб опису інструментів і контексту, а також ендпоінти, сумісні з OpenAI‑API. Останнє особливо важливо, оскільки багато сучасних агентних систем уже орієнтуються на OpenAI‑сумісний протокол як де‑факто стандарт.

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

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

Відкриті стандарти як стратегія: MCP, OpenAI‑API та OpenTelemetry

IBM окремо виділяє підтримку відкритих стандартів як одну з ключових відмінностей свого control plane. Йдеться не лише про технічну зручність, а й про довгострокову стратегію уникнення закритих, несумісних стеків.

Model Context Protocol (MCP) розглядається як один із центральних елементів майбутньої інтероперабельності. У дискусії навколо проєкту Context Forge, архітектором якого є Міхай Кріветі, постає типове запитання: якщо є MCP, чи не вирішить він «усе» сам по собі? Відповідь обережна, але оптимістична: MCP справді має потенціал стандартизувати низку критичних аспектів — від автентифікації до формату даних.

IBM очікує, що з часом MCP уніфікує:

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

способи передачі даних між агентами та інструментами;

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

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

Паралельно IBM робить ставку на підтримку OpenAI‑сумісних API. Це дозволяє підключати до control plane інструменти й агенти, які вже вміють працювати з цим протоколом, без додаткових «перекладачів». У світі, де багато стартапів і open‑source‑проєктів орієнтуються саме на цей API, така сумісність стає практично обов’язковою.

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

У сукупності підтримка MCP, OpenAI‑сумісних API та OpenTelemetry формує для watsonx Orchestrate роль «відкритого» control plane, який не намагається замкнути екосистему в межах одного вендора, а навпаки — прагне стати точкою зшивання різних стандартів.

Чому контроль залишиться назавжди: ймовірнісні агенти й «хто стежить за наглядачами»

Окрема лінія аргументації IBM стосується фундаментальної природи агентів. На відміну від класичного детермінованого ПЗ, де однаковий вхід завжди дає однаковий вихід, агенти, побудовані на LLM, є ймовірнісними. Вони можуть поводитися по‑різному за однакових умов, і це не тимчасова вада, а властивість самої технології.

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

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

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

кожен доступ можна відстежити й пояснити;

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

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

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

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

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

Ключові елементи цієї відповіді — гібридні розгортання від air‑gapped до multi‑cloud через OpenShift, здатність імпортувати агентів із зовнішніх фреймворків на кшталт LangGraph, підключення до зовнішніх агентів через gateway, MCP і OpenAI‑сумісні ендпоінти, а також ставка на відкриті стандарти MCP, OpenAI‑API й OpenTelemetry.

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

Джерело

Agent control planes & OpenAI model solves Erdős — IBM Technology

У корпоративному світі AI‑агенти вже не футуристична обіцянка, а повсякденна реальність — і дедалі частіше проблема. Компанії запускають десятки й сотні агентів у різних бізнес‑підрозділах, але втрачають контроль над тим, де вони працюють, які дані бачать і скільки це коштує. На подкасті IBM Mixture of Experts про це говорили Мігай Кріветі, головний архітектор watsonx Orchestrate, Олівія Бужек, Staff AI Engineer, та Акаш Срівастава, директор і техлід з AgentOps в IBM Core AI. На цьому тлі IBM формує власну відповідь: AgentOps як продовження класичного життєвого циклу розробки ПЗ (SDLC), але для ймовірнісних агентних систем.

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

Від детермінізму до ймовірності: чому SDLC більше не вистачає

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

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

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

IBM формулює це як розширення SDLC, а не його заміну. Юніт‑тести, CI/CD, рев’ю коду залишаються необхідними, але «недостатніми». До них додається новий шар: систематичні оцінки агентів, які враховують їхню ймовірнісну природу. Саме тут народжується дисципліна AgentOps.

Три стовпи AgentOps: спостереження, оцінка, оптимізація

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

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

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

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

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

OpenTelemetry як нервова система агентних систем

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

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

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

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

PII та PHI під мікроскопом: спостерігати, не зливаючи дані

Один із найменш помітних, але критично важливих аспектів AgentOps у виконанні IBM — це фільтрація PII (персонально ідентифікованої інформації) та PHI (медичних даних) у контурах спостережуваності. У традиційних системах моніторингу вже давно відомо, що «сирі логи» можуть містити чутливу інформацію. З агентами ризики зростають: вони працюють із природною мовою, документами, внутрішніми базами, і все це може опинитися в телеметрії.

IBM прямо наголошує: спостережуваність не повинна перетворюватися на канал витоку даних до всіх, хто має доступ до моніторингових інструментів. Тому в контурах AgentOps PII/PHI‑фільтрація — не опція, а базова вимога. Дані, що потрапляють у OpenTelemetry‑потік, мають проходити через фільтри, які видаляють або маскують чутливу інформацію до того, як вона стане доступною широкому колу інженерів, аналітиків чи сторонніх сервісів.

Це особливо важливо на тлі регуляторного тиску, зокрема з боку ЄС через AI Act. Якщо агенти працюють із персональними даними громадян, компанія має не лише контролювати їхню поведінку, а й довести, що канали спостереження не створюють нових векторів ризику. AgentOps у трактуванні IBM — це не лише про якість і надійність, а й про відповідність нормам захисту даних.

watsonx Orchestrate, як платформа, тут відіграє роль «конструктора політик». Клієнти можуть приносити власні правила, метрики й фільтри, включно з кастомними PII‑фільтрами, які відповідають їхнім внутрішнім стандартам ризик‑менеджменту та комплаєнсу. Це дозволяє не покладатися на універсальні «чорні скриньки», а вбудовувати AgentOps у вже існуючі політики безпеки.

AgentOps без нових армій інженерів: інструменти, а не окремі відділи

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

Причина проста: ядро AgentOps — це спеціалізовані інструменти й методи, а не принципово нова організаційна структура. Оцінювання агентів — це не класичне тестування, але воно може бути вбудоване в ті самі CI/CD‑пайплайни. Оптимізація агентів використовує нові підходи, але працює поверх уже знайомих систем розгортання й моніторингу. Спостережуваність базується на OpenTelemetry, який DevOps‑команди й так використовують.

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

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

watsonx Orchestrate: власні метрики, власні запобіжники

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

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

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

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

Агентний контрольний план: Kubernetes‑логіка для світу LLM

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

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

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

Водночас критичні рішення залишаються під контролем явних людських політик. Kill‑switch’і, фільтрація PII/PHI, ліміти витрат, правила доступу до даних — усе це має бути детермінованим, прозорим і підзвітним. Агент може порадити, але не має права самостійно змінювати фундаментальні обмеження. Такий баланс — «агенти допомагають, люди визначають рамки» — виглядає центральним для IBM‑івського бачення безпечних агентних систем.

Чому навіть із MCP агенти потребують контрольного шару

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

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

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

Звідси й наполягання IBM: контрольований, аудиторований доступ до даних і маршрутизація запитів — це не тимчасова перехідна міра, а постійна вимога. MCP може стандартизувати «дроти», але не замінить політики, спостережуваність і AgentOps‑петлі, які визначають, хто, коли й як може використовувати ці дроти.

Хто стежить за наглядачами: агенти, що допомагають керувати агентами

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

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

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

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

Висновок: AgentOps як нова грамотність для епохи агентів

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

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

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

Джерело

Agent control planes & OpenAI model solves Erdős — IBM Technology

У корпоративному світі генеративного AI з’явився новий клас проблем: не як створити агентів, а як ними керувати. На подкасті IBM Mixture of Experts інженери IBM — зокрема головний архітектор watsonx Orchestrate Міхай Кріветі, директор з AgentOps Акаш Срівастава та інженерка Олівія Бужек — обговорюють, як компанії вже потопають у «випадкових актах AI» і чому IBM відповідає на це розробкою watsonx agentic control plane, контрольної площини для агентів.

Коли «випадкові акти AI» стають системною загрозою

Сценарій, який описують інженери IBM, дедалі частіше виглядає однаково. Велика організація за рік‑два експериментів накопичує десятки, а іноді й сотні агентів: чат‑боти для підтримки клієнтів, внутрішні помічники для юристів, автоматизовані аналітики для фінансів, агенти для DevOps, маркетингу, HR.

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

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

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

Усе це створює типову картину: будувати агентів виявилося відносно легко, але керувати ними на рівні підприємства — надзвичайно складно. Саме цю прірву IBM намагається закрити за допомогою watsonx agentic control plane.

Kubernetes для агентів: як виглядає контрольна площина

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

Kubernetes розв’язав цю проблему, розділивши світ на дві площини: control plane і data plane. Control plane зберігає знання про те, які сервіси мають існувати, які політики до них застосовуються, як вони масштабуються й оновлюються. Data plane — це власне виконання контейнерів на вузлах кластера.

IBM пропонує застосувати той самий підхід до AI‑агентів. У їхній архітектурі watsonx agentic control plane виконує роль «мозку», який:

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

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

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

Проблема ймовірнісної поведінки: чому контроль — не тимчасовий костиль

Класичне корпоративне ПЗ є детермінованим: за однакових вхідних даних воно дає однаковий результат. Це дозволяє будувати навколо нього звичний SDLC — юніт‑тести, CI/CD, регресійне тестування, формальні верифікації критичних компонентів.

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

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

Це має два важливі наслідки для архітектури підприємства.

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

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

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

Детерміновані «kill switch» і політики: що саме не можна віддати агентам

Один із ключових елементів дизайну watsonx agentic control plane — чітке розмежування того, що може бути агентним і ймовірнісним, і того, що має залишатися детермінованим і політично керованим.

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

Але є категорії функцій, які принципово не можна віддавати на відкуп ймовірнісним системам. Серед них IBM виділяє:

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

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

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

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

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

Регуляції як каталізатор: роль EU AI Act у формуванні нової інфраструктури

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

IBM прямо вказує на EU AI Act як один із головних драйверів попиту на контрольні площини. Європейське законодавство вимагає від організацій:

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

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

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

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

Висновок: агенти не зникнуть, тож має з’явитися інфраструктура для них

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

IBM фактично пропонує інший шлях: прийняти, що агенти — це новий клас ймовірнісного програмного забезпечення, і побудувати для нього таку саму інфраструктуру, яку свого часу побудували для контейнерів і мікросервісів. watsonx agentic control plane у цій картині виступає аналогом Kubernetes‑control plane: не місцем, де відбувається вся робота, а мозком, який знає, що існує, як це має поводитися, які обмеження й політики застосовуються, і як усе це спостерігати й вимірювати.

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

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

Джерело

Agent control planes & OpenAI model solves Erdős — IBM Technology

У третьому епізоді серії Builders Unscripted від OpenAI продукт-лідер Alchemy Матіас Кастелло розповідає, як будує власні AI-нативні інструменти поверх Codex App Server і GPT. Попри те, що він не інженер за освітою, Кастелло створив цілу екосистему особистих продуктів: від автономних агентів, які працюють над його проєктами, поки він офлайн, до кросплатформеного асистента для письма на macOS та iOS. У центрі цієї історії — практичний погляд на те, як виглядає «робочий стіл майбутнього», де AI не просто підказує, а реально виконує роботу.

agent.md: як навчити агента працювати «по-людськи», а не з нуля щоразу

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

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

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

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

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

Саме завдяки agent.md Codex може не лише генерувати плани, а й виконувати їх. У його Linear-проєктах агент створює задачі, бере їх у роботу, оновлює статуси, переходить від «in progress» до «review» і «done» без ручного мікроменеджменту. Людина залишається власником візії та якості, а агент — виконавцем, який уже «знає правила гри».

Mac‑асистент для письма: глобальний шорткат, GPT і голос

Одним із найпоказовіших прикладів того, як Кастелло мислить «AI-нативно», став його Mac‑додаток для письма. Це не черговий чат-клієнт до GPT, а системний інструмент, який вбудовується безпосередньо в щоденну роботу за комп’ютером.

Базова ідея проста: будь-де в macOS — у пошті, Slack, браузері, редакторі — користувач виділяє текст, натискає глобальне поєднання клавіш (у нього це Command + Shift + пробіл), і поверх з’являється невелике вікно асистента. Далі Codex App Server, підключений до його платної GPT-підписки, переписує виділений фрагмент у потрібному стилі.

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

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

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

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

Усе це працює поверх Codex App Server, який виступає як інфраструктурний шар: керує викликами моделей, маршрутизує запити, дозволяє підключати різні GPT‑версії та конфігурації. Для користувача це виглядає як один простий шорткат, але під капотом — повноцінний AI‑бекенд.

Модель як налаштування: чому в асистенті з’явився GPT 5.5

Ще одна деталь, яка видає в Кастелло продукт-лідера, — ставлення до вибору моделей. У його письмовому асистенті є вбудований «model picker» — користувач може сам обрати, яку модель GPT використовувати для конкретного завдання.

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

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

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

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

Для Кастелло це ще й спосіб робити власні «евали» моделей у реальних сценаріях. Він уже відомий тим, що любить перебудовувати свій проєкт Snapcat під кожну нову модель, щоб відчути різницю на практиці. Письмовий асистент із model picker дає йому ще один полігон для порівнянь: як GPT 5.5 поводиться в реальних робочих листах, Slack‑повідомленнях, технічній документації.

iOS‑версія й кастомна клавіатура: AI прямо в полі введення

Після успіху Mac‑версії Кастелло переніс ту ж концепцію на мобільні пристрої. Він створив iOS‑версію свого асистента, але не обмежився окремим застосунком. Ключовим елементом стала кастомна клавіатурна розкладка.

Ідея така сама, як на Mac: AI має бути там, де користувач уже пише, а не в окремому вікні. На iPhone це означає — безпосередньо в полі введення, через клавіатуру. Користувач друкує або вставляє текст у будь-якому застосунку — месенджері, пошті, нотатках — і може викликати функцію переписування прямо з клавіатури.

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

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

Тут знову працює той самий бекенд: Codex App Server, GPT‑підписка, agent.md як джерело стилю. Різниця лише в оболонці. На Mac це глобальний шорткат і невелике вікно. На iOS — клавіатура, яка поводиться як будь-яка інша, але вміє ще й переписувати текст у потрібному тоні.

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

Linear як полігон для автономних агентів

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

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

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

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

Кастелло описує, як він може перед сном попросити Codex дослідити його застосунок, подивитися на конкурентів, сформувати топ‑10 потенційних фіч, реалізувати їх як експерименти з feature‑flag’ами й до ранку отримати готові перемикачі, які можна вмикати й вимикати. Людина залишається в ролі редактора й куратора, а не єдиного виконавця.

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

Alchemy між людьми й агентами: інфраструктура для двох типів девелоперів

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

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

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

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

У певному сенсі особисті проєкти Кастелло — це мікромодель того, що може відбуватися на рівні індустрії. Він уже живе в світі, де агент може:

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

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

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

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

Файл agent.md перетворює розрізнені промпти на послідовну систему вподобань, яку можуть використовувати всі агенти. Mac‑та iOS‑асистенти для письма показують, як AI може стати частиною операційної системи, а не окремого сервісу. Модельний селектор із GPT 5.5 робить інструмент готовим до майбутніх поколінь моделей. Інтеграція з Linear демонструє, як агенти можуть не лише підказувати, а й реально виконувати роботу, рухаючи задачі по всьому життєвому циклу.

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

Джерело

Builders Unscripted: Ep. 3 – Matias Castello, Product Leader at Alchemy

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

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

Від прототипу на копіпасті до “тиждень на V1”

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

Саме так будував свій попередній стартап Матіас. Він самотужки зібрав перший прототип, фактично на “копіпасті”, і лише після цього зміг залучити кошти, щоб запросити у команду трьох–чотирьох інженерів. Далі — кілька місяців спільної роботи над MVP, який нарешті можна було показати користувачам. Це вимагало помітного бюджету, командної координації й довгого циклу ітерацій.

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

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

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

Коли комп’ютер працює без тебе: особиста система автономних агентів

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

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

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

генерує план реалізації;

розбиває роботу на кроки;

імплементує зміни в коді;

запускає тести;

повідомляє, коли завдання виконано.

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

Це змінює й психологічну динаміку. Замість провини за те, що він “не працює”, коли виходить на прогулянку чи йде на вечерю, він знає, що в цей час його агенти продовжують рухати проєкти вперед. Людський час звільняється для стратегічного мислення, відпочинку й тих рішень, які AI поки що не може прийняти за нього.

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

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

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

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

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

аналізують ринок і конкурентів;

формують перелік фіч;

пишуть код;

інтегрують його в проєкт;

обгортають кожну зміну фічефлагом.

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

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

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

Дванадцять проєктів одночасно: як AI тримає все в русі

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

Різниця в тому, що значна частина роботи в цих проєктах виконується не ним особисто, а Codex. У Linear багато задач і майлстоунів створюються й виконуються агентами. Вони ж автоматично рухають тікети між статусами — “in progress”, “review”, “done” — у міру виконання кроків.

Фактично AI виступає не лише як виконавець, а й як диспетчер процесу. Він:

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

розбиває їх на підзадачі;

починає роботу над ними;

оновлює статуси в трекері;

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

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

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

Важливо, що йдеться не про демонстраційні “іграшкові” проєкти. Серед них — реальні застосунки, включно з macOS та iOS-апками, які він продовжує розвивати. Один із прикладів — інструмент для письма, що викликається глобальним шорткатом і використовує Codex App Server та GPT-підписку за лаштунками, аби допомагати йому писати краще під час роботи за комп’ютером. Це вже не просто експерименти, а корисні інструменти, які самі стають частиною його продуктивного стеку.

Як навчити агента працювати “по-людськи”: роль особистих преференцій

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

У його системі це оформлено як окремий документ із описом того, як він любить планувати, писати код, структурувати проєкти, які компроміси прийнятні, а які — ні. Цей файл стає своєрідним “мануалом” для Codex, який дозволяє планувати й виконувати роботу в його улюбленому стилі, а не в абстрактному “середньому” варіанті.

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

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

Новий профіль засновника: менше людей, більше систем

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

Це має кілька наслідків для екосистеми стартапів.

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

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

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

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

Висновок: час будувати системи, а не лише продукти

Якщо раніше ключовим питанням для засновника було “як найняти потрібних людей”, то сьогодні дедалі частіше воно звучить як “як побудувати правильну систему з AI”. Досвід Матіаса Кастелло показує, що:

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

AI може бути не лише “автодоповненням коду”, а повноцінним учасником продакт-процесу — від дослідження конкурентів до реалізації фіч як експериментів;

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

одна людина може тримати в русі десяток проєктів, якщо AI інтегрований у таск-менеджмент і бере на себе рутину планування та виконання.

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

Джерело

Builders Unscripted: Ep. 3 – Matias Castello, Product Leader at Alchemy

У третьому епізоді серії Builders Unscripted від OpenAI продакт-лідер Alchemy Матіас Кастелло розповідає, як команда криптоінфраструктурної компанії інтегрувала Codex у свої щоденні процеси. Від перших експериментів зі Slack до повноцінного «AI‑колеги» в рев’ю коду та спільного репозиторію навичок для продакт-менеджерів — історія Alchemy показує, як швидко AI може стати базовим шаром інженерної культури.

Перший крок: Codex у Slack замість локального запуску документації

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

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

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

Цей крок важливий не лише як зручність. Він показав кілька принципових речей.

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

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

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

Ретроспективне рев’ю коду: момент, коли AI довів свою цінність

Справжній перелом у ставленні до AI в Alchemy стався тоді, коли Codex уперше застосували до коду, що вже спричинив інцидент у продакшені.

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

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

Codex знайшов ту саму race condition.

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

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

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

Codex як колега в pull request: нова соціальна динаміка в код-рев’ю

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

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

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

Такий сценарій змінює одразу кілька речей.

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

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

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

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

Від Datadog до GPT 5.5: як AI‑рев’ю змінює картину інцидентів

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

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

Ця цифра — понад 20% — задає важливу планку. Вона показує, що навіть на відносно ранніх етапах розвитку моделей AI‑рев’ю здатне істотно знизити кількість продакшен‑збоїв. Для компаній, які працюють із критичною інфраструктурою, це безпосередньо конвертується в менше простоїв, менше SLA‑порушень і нижчі операційні витрати.

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

Це має кілька наслідків для інженерних організацій.

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

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

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

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

Спільний репозиторій навичок Codex: як AI стає інструментом не лише для інженерів

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

Матіас описує внутрішню практику створення «навичок» Codex — налаштованих сценаріїв, які допомагають виконувати типові задачі продакт‑менеджера. Серед них — написання PRD (product requirement documents), аналіз зворотного зв’язку від клієнтів, підготовка різних робочих документів.

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

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

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

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

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

Розробник як людина й як агент: як Alchemy переосмислює свою платформу

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

Матіас описує дві паралельні трансформації.

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

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

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

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

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

Висновок: AI як новий базовий шар інженерної культури

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

Почалося все з невеликого, але болючого фрагмента рутини — правок у документації через Slack. Потім був ретроспективний експеримент із продакшен‑інцидентом, який довів, що модель здатна знаходити реальні, складні помилки в коді. Далі — інтеграція Codex у повсякденне рев’ю pull request’ів, де AI став сприйматися як ще один «колега» в команді.

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

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

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

Джерело

Builders Unscripted: Ep. 3 – Matias Castello, Product Leader at Alchemy

OpenAI розширила можливості Codex на Windows: тепер агент може самостійно працювати з десктопними застосунками, поки користувач відійшов від комп’ютера, а також приймати команди зі смартфона через застосунок ChatGPT.

Що таке Computer Use і навіщо він потрібен

Функція Computer Use у Codex для Windows дозволяє агенту керувати будь‑яким застосунком на комп’ютері та виконувати завдання від імені користувача. Агент отримує контроль над екраном і курсором, візуально змінюючи вигляд робочого столу, щоб було зрозуміло, що зараз працює саме він.

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

Ідея проста: користувач може залишити ноутбук на столі, поки Codex виконує рутинну роботу, а сам — відійти на зустріч, зробити перерву чи займатися плануванням “на папері”.

Як увімкнути Computer Use у застосунку Codex

Щоб запустити нові можливості на Windows, потрібно кілька кроків у налаштуваннях:

1. Відкрити застосунок Codex на Windows.
2. Перейти до розділу Settings (Налаштування).
3. Увімкнути опцію Computer Use.

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

• у вікні створення нового діалогу використати опцію Add computer, щоб дозволити Codex працювати безпосередньо на вашому ПК;
• у повідомленнях можна @згадувати конкретні встановлені застосунки, підказуючи агенту, з якими програмами слід працювати.

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

Мобільний доступ: керування Codex із ChatGPT

Ще одна нова можливість — віддалений контроль Codex на Windows через мобільний застосунок ChatGPT для iOS та Android. Це дозволяє:

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

Налаштування мобільного доступу виглядає так:

1. У застосунку Codex на Windows натиснути іконку мобільного пристрою внизу екрана
   або зайти в Settings → Connections.
2. Переконатися, що ви ввійшли у свій обліковий запис ChatGPT.
3. Відсканувати QR‑код зі смартфона.
4. У застосунку ChatGPT авторизуватися в Codex; Windows‑пристрій має автоматично з’явитися в списку доступних.

Після цього зі смартфона можна:

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

Це фактично перетворює Windows‑машину на віддаленого “робочого агента”, яким можна керувати з будь‑якого місця.

Навіщо це бізнесу та окремим користувачам

Поєднання Computer Use і мобільного доступу робить Codex на Windows інструментом для сценаріїв, де раніше потрібна була фізична присутність за комп’ютером:

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

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

Джерело

Windows Computer Use and mobile access for Codex — OpenAI

У 2026 році, коли ринок AI‑продуктів здається перенасиченим, історія Granola виглядає майже парадоксально. Стартап, який з’явився в категорії, де Zoom і Google вже роками пропонували автоматичні нотатки, за три роки виріс до оцінки в $1,5 млрд. CEO та співзасновник Granola Кріс Педрегал будує не чергового «бота на дзвінку», а AI‑нотатник, яким користувач керує сам: інтерфейс, схожий на Apple Notes, реальний час, можливість спілкуватися з транскриптами зустрічей за останні два роки.

Ключ до цього стрибка — не агресивний маркетинг, а продумана стратегія виходу на ринок: закрита бета, мінімалістичний публічний запуск, продукт‑first філософія та «знизу вгору» модель зростання, подібна до Slack і Dropbox.

Закрита бета як зброя проти «AI‑шуму»

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

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

Пул ранніх тестувальників складався приблизно зі 150 активних користувачів — друзів і друзів друзів, але з чітким профілем: тех‑саві knowledge workers, люди, які живуть у Slack, Linear, Superhuman, Gmail, звикли платити за інструменти продуктивності й працюють у стартапах різних розмірів. Granola будували «для себе» — і «свої» ж стали першими критиками.

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

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

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

GIF, один твіт і 500 інсталяцій без бюджету

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

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

GIF опублікували з особистого акаунта Кріса в X (Twitter). Без таргетингу, без промо‑бюджету. Але в аудиторії, де сидять засновники, оператори стартапів і люди, які постійно шукають нові інструменти продуктивності, влучний візуальний демо може зробити більше, ніж будь‑який лендинг.

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

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

Продукт веде, маркетинг доганяє: модель Slack і Dropbox

Замість класичної B2B‑стратегії з довгими сейлз‑циклами Granola обрала шлях, який свого часу спрацював для Slack і Dropbox: продукт‑led growth, що починається з індивідуального користувача.

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

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

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

Саме так Granola вийшла на дуже великі компанії, які сьогодні сидять на enterprise‑планах. Часто все починалося або з «партизанського» використання окремими співробітниками, або з того, що сам CEO особисто підсаджувався на інструмент і вже з позиції першої особи просував його далі в організації.

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

Вірусність без спаму: чому Granola не женеться за «growth‑хаками»

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

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

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

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

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

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

Як Granola вирізняється в світі, де «всі можуть вибкодити софт»

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

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

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

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

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

Висновок: у переповненому AI‑ринку перемагає не гучність, а турбота

Історія Granola показує, що в епоху, коли «будь‑хто може стати AI‑фаундером», справжнім дефіцитом стає не код, а увага до якості. Закрита бета замість поспішного публічного релізу, GIF замість дорогого маркетингу, bottoms‑up adoption замість холодних продажів, сервіс користувачу замість агресивних growth‑лупів — усе це виглядає майже консервативно на фоні хайпу навколо AI.

Але саме така стратегія дозволила Granola не загубитися серед десятків AI‑нотейкерів від великих корпорацій, а стати інструментом, який органічно проростає всередині компаній — від окремого співробітника до enterprise‑контракту.

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

Джерело

YouTube: $1.5B AI Founder: The ONE Rule for Building an AI Startup in 2026

У 2026 році говорити про «новий AI‑стартап» означає виходити на ринок, де вже є Zoom, Google та десятки нішевих гравців із власними нотатерами й асистентами. Попри це, Granola — AI‑нотатник і інструмент для конспектування зустрічей, яким керує співзасновник і CEO Кріс Педрегал, — за три роки виріс до оцінки в $1,5 млрд. Його команда зробила ставку не на гучний запуск, а на майже старомодну дисципліну: ручні прототипи, тестування «віч‑на‑віч» і рік закритої роботи до першого публічного релізу.

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

Від перших LLM‑експериментів до ідеї AI‑нотатника

Ключова відмінність Granola почалася задовго до першого користувача. Педрегал уперше серйозно зіткнувся з великими мовними моделями у 2022 році — приблизно за вісім–дев’ять місяців до запуску ChatGPT. Це був момент, коли LLM ще не стали масовим інструментом, але вже було зрозуміло, що вони змінять робочі процеси.

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

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

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

Прототипи на HTML і JavaScript: як виглядає «vibe‑coding» до ери vibe‑coding

Сьогодні модно говорити про «vibe‑coding» — коли засновник за допомогою AI‑інструментів швидко збирає напівживий прототип, щоб перевірити ідею. Коли Granola тільки народжувалася, таких інструментів ще не було, але підхід був дуже схожим.

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

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

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

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

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

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

Granola будувалася «для себе» — для технічних і тех‑саві knowledge workers, які живуть у Slack, Linear, Superhuman, Gmail, постійно сидять у дзвінках і вже платять за інструменти продуктивності. Тому перші приблизно 150 активних користувачів — це друзі, колеги й друзі друзів, які працювали в стартапах різного розміру, у технологічних компаніях, у ролях, де час у зустрічах і обсяг інформації критично високі.

Це не просто «зручно дістати» людей зі свого кола. Такий підхід дає дві важливі переваги.

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

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

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

Рік «ручної роботи»: по одному користувачу на день, без публічного запуску

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

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

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

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

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

Dot‑plot як рентген залученості: як Granola вимірювала, чи продукт «живий»

Попри сильний акцент на якісних спостереженнях, Granola не відмовилася від кількісних сигналів. Щоб зрозуміти, чи продукт справді вбудовується в робочі процеси людей, команда створила просту, але показову візуалізацію — dot‑plot.

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

Цей інструмент давав кілька важливих інсайтів.

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

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

По‑третє, така візуалізація допомагала відрізнити «ефект новизни» від реальної цінності. Багато інструментів отримують сплеск використання в перші дні, але швидко «вигорають». Якщо через кілька місяців dot‑plot для значної частини користувачів залишався щільно заповненим, це вже нагадувало справжній product‑market fit, а не короткочасний хайп.

У підсумку Granola поєднувала інтуїтивні спостереження («очі світяться чи ні») з дуже конкретним питанням: чи люди повертаються до продукту щодня на своїх реальних зустрічах.

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

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

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

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

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

Чому Педрегал радить будувати в приваті: нове правило для AI‑стартапів

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

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

Його аргументація проста.

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

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

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

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

Як цей підхід вписується в епоху «будь‑хто може все закодити»

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

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

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

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

Уроки Granola для AI‑засновників

Історія Granola дає кілька чітких уроків для тих, хто сьогодні намагається запустити AI‑продукт.

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

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

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

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

П’ятий — вимірювати не лише «очі, що світяться», а й реальну поведінку. Простий dot‑plot, де кожен день використання позначений точкою, може стати набагато чеснішим індикатором product‑market fit, ніж будь‑які vanity‑метрики.

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

Висновок: якість як єдина стратегія в перенасиченому AI‑ринку

Granola вийшла на ринок, де AI‑нотатери існували вже сім–вісім років, а великі гравці на кшталт Zoom і Google мали власні рішення. Попри це, продукт Кріса Педрегала зумів не просто вижити, а й вирости до оцінки в $1,5 млрд за три роки. Ключовим фактором став не маркетинг і не першість, а безкомпромісний фокус на якості досвіду — від перших HTML‑прототипів до року закритого тестування з 150 користувачами.

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

Джерело

YouTube: $1.5B AI Founder: The ONE Rule for Building an AI Startup in 2026

У 2026 році важко здивувати когось ще одним «AI‑асистентом для зустрічей». Zoom, Google та десятки стартапів роками пропонують автоматичні конспекти дзвінків. Попри це, Granola — «AI‑нотатник» під керівництвом CEO та співзасновника Кріса Педрегала — за приблизно три роки виросла до оцінки $1,5 млрд. Вона зайшла на ринок, де великі гравці вже сім–вісім років мали схожі функції, і все ж змогла вирватися вперед.

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

Не ще один бот на дзвінку: що таке «особистий AI‑нотатник»

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

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

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

Ця філософія відображається в кількох принципових рішеннях.

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

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

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

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

Інтерфейс як Apple Notes, але з «двигуном» AI під капотом

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

Інтерфейс Granola спеціально зроблений максимально схожим на Apple Notes. Це знайомий формат: порожня сторінка, курсор, текст. Ніяких «AI‑порталів», жодних футуристичних UI‑експериментів.

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

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

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

Реальний прорив: живий AI‑нотатник під час зустрічі

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

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

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

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

Це добре ілюструє головну ставку Granola: не на гучні обіцянки, а на відчутну різницю в досвіді використання.

«Продукт, який просто працює»: як вирватися з перенасиченого AI‑ринку

Сьогодні створити AI‑продукт технічно легше, ніж будь-коли. Можна «vibe‑кодити» інтерфейси, збирати прототипи на готових моделях, запускати сервіси соло‑засновником. Це призвело до вибуху кількості інструментів — і до того, що значна їх частина відверто посередня.

На цьому тлі Granola зробила ставку на, здавалося б, банальну річ: продукт має реально працювати й відчуватися краще за альтернативи. Не на 10 разів, не революційно — але помітно краще в щоденному використанні.

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

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

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

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

Від нотаток до живої пам’яті: чат з двома роками зустрічей

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

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

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

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

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

Чому «піклуватися більше» працює навіть проти Zoom і Google

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

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

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

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

Granola відповідає на це по‑своєму: знайомий інтерфейс, повний контроль користувача, реальний час, інтерактивна пам’ять зустрічей, відсутність нав’язливих growth‑механік. У сукупності це створює продукт, який відчувається «своїм» — і саме це дозволило йому вирости до оцінки $1,5 млрд у категорії, де, здавалося б, усе вже давно розподілено.

Висновок: у перенасиченому AI‑світі перемагає не той, хто голосніше, а той, хто кращий

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

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

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

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

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

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

Джерело

YouTube: $1.5B AI Founder: The ONE Rule for Building an AI Startup in 2026

У новому випуску каналу Tech With Tim автор, який протестував понад сотню Claude Code Skills, зупиняється на двох навдивовижу практичних інструментах. Обидва розширюють можливості Claude Code далеко за межі стандартного браузера й типового «AI-стилю» тексту. Firecrawl перетворює Claude на стійкого веб-скрейпера, здатного працювати з сотнями сторінок за один прогін, а Humanizer — на стиліста, який переписує відповіді так, щоб вони звучали як живе людське письмо.

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

Вузьке місце вбудованого браузера Claude: чому з’явився Firecrawl

Claude Code уже вміє виходити в інтернет, шукати інформацію й відкривати сторінки. Але щойно завдання виходить за межі кількох URL — починаються проблеми. Типовий сценарій знайомий будь-кому, хто пробував автоматизувати веб-дослідження через LLM: модель відкриває кілька сторінок, потім натикається на ліміт запитів, блокування IP, CAPTCHA чи інші захисти, і сесія розвалюється.

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

• обходить rate limit-и;
• працює з блокуваннями й IP-фільтрами;
• справляється з CAPTCHA, які зазвичай зупиняють вбудований доступ Claude до вебу.

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

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

Веб-скрейпінг у масштабі: як Firecrawl працює на практиці

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

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

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

У демонстрації Firecrawl отримав завдання пройтися по сторінках AI-стартапів Y Combinator. Мова йшла не про десяток посилань, а про понад 300 сторінок. Firecrawl впорався з цим за приблизно десять хвилин, витративши 312 кредитів. Для користувача це виглядає як один запит у Claude Code, але під капотом відбувається повноцінний краулінг сайту з обробкою всіх технічних перешкод.

Після завершення скрейпінгу Claude отримав доступ до масиву HTML-документів і зміг зробити те, що вміє найкраще: перетворити сирі дані на осмислений результат. На основі зібраної інформації було сформовано markdown-файл із добіркою приблизно двадцяти найцікавіших компаній з усієї вибірки YC AI-стартапів. Тобто Firecrawl відповідав за масштабований збір, а Claude — за аналітику й редактуру.

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

Кредити, ліміти й установка: що потрібно знати про Firecrawl

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

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

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

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

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

Від сирих даних до людського тексту: навіщо Claude потрібен Humanizer

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

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

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

У Claude Code Humanizer викликається спеціальною командою /humanizer. Після встановлення skill користувач може взяти будь-яку відповідь Claude, пропустити її через Humanizer і отримати версію, яка краще підходить для живої комунікації.

Як встановити Humanizer і де він особливо корисний

Установка Humanizer у Claude Code побудована так, щоб не вимагати від користувача глибокого занурення в конфігураційні файли. У репозиторії Humanizer на GitHub наведено дві рядки для інсталяції. Їх достатньо скопіювати в Claude і попросити встановити skill. Після цього команда /humanizer стає доступною в середовищі, і Claude може використовувати її як частину звичайного воркфлоу.

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

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

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

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

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

Коли Firecrawl і Humanizer працюють разом

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

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

1. Запускає Firecrawl на списку релевантних сайтів або каталозі на кшталт YC.
2. Чекає, поки Firecrawl пройде сотні сторінок, збере повний HTML і поверне Claude масив документів.
3. Просить Claude виділити ключові компанії, порівняти їхні підходи, ціни, позиціонування, сформувати підсумковий огляд.
4. Пропускає цей огляд через Humanizer, щоб отримати текст, який можна надіслати команді, інвесторам чи опублікувати як блог-пост.

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

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

Висновок: Claude Code як платформа, а не просто чат

Firecrawl і Humanizer демонструють, як змінюється роль Claude Code у щоденній роботі розробників, аналітиків, маркетологів і засновників. Перший розв’язує проблему надійного доступу до великого масиву веб-даних, другий — проблему довіри й сприйняття тексту, який генерує AI.

Firecrawl робить з Claude інструмент для масштабного веб-скрейпінгу, здатний обходити rate limit-и, блокування й CAPTCHA, збирати повний HTML сотень сторінок і передавати його назад у сесію для подальшого аналізу. При цьому кредитна модель із приблизно тисячею безкоштовних кредитів на місяць дозволяє почати без додаткових витрат і поступово масштабуватися до платних сценаріїв.

Humanizer, у свою чергу, дає можливість перетворювати типові AI-відповіді на тексти, які звучать природно в листах, чатах і соцмережах. Просте встановлення через дві інсталяційні команди з GitHub і виклик через /humanizer роблять його ще одним інструментом у звичному робочому середовищі Claude Code.

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

Джерело

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

У новому випуску каналу Tech With Tim розробник і ютубер Тім показує, як перетворити Claude Code з просто «розумного редактора» на інструмент, що реально керує інфраструктурою: створює VPS, купує домени, налаштовує DNS і деплоїть сайти без виходу з інтерфейсу Claude. Ключовий елемент цієї схеми — інтеграція Hostinger MCP, серверу Model Context Protocol, який відкриває для Claude 118 інструментів керування хостингом.

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

Claude як DevOps: що насправді дає Hostinger MCP

Hostinger MCP — це MCP-сервер, який підключається до Claude Code і надає моделі доступ до повноцінного API Hostinger. Після налаштування в середовищі Claude з’являється окремий підключений сервер із 118 інструментами, які можна викликати прямо з чату.

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

керувати VPS-інстансами — створювати нові віртуальні сервери, керувати їхнім життєвим циклом, використовувати знімки;

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

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

налаштовувати DNS — змінювати записи, прив’язувати домени до потрібних серверів і сервісів;

деплоїти сайти — розгортати веб-додатки безпосередньо з Claude, не заходячи в веб-інтерфейс Hostinger.

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

У демонстрації Тім прямо в Claude запитує, що саме вміє Hostinger MCP. Модель, використовуючи інструменти MCP, повертає стислий огляд: створення VPS, керування снапшотами, купівля доменів, перевірка їхньої доступності, робота з DNS та інші операції. Цей крок важливий не лише як зручна «довідка», а й як ілюстрація того, що Claude дійсно бачить і розуміє доступні інструменти, а не просто виконує заздалегідь прописаний сценарій.

Що потрібно мати, перш ніж підключати Hostinger до Claude

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

потрібен обліковий запис Hostinger;

потрібен активний VPS або хостинг-план.

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

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

Після оформлення плану Hostinger запускає стандартний онбординг: пропонує вибрати домен, налаштувати перший сайт, пройти базові кроки розгортання. Для інтеграції з Claude цей майстер не обов’язковий. Його можна перервати, залишивши створені ресурси «в очікуванні», а далі вже керувати всім через MCP із Claude Code.

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

зареєстрований;

із заповненою інформацією про власника та контактні дані в інтерфейсі Hostinger.

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

Як саме підключити Hostinger MCP до Claude Code

Технічно інтеграція складається з двох основних кроків: додавання MCP-конфігурації в Claude Code і підключення API-токена Hostinger.

Перший крок відбувається через API-розділ у панелі Hostinger. На сторінці API Hostinger прямо показує готову MCP-конфігурацію, яку потрібно додати до Claude. Це JSON-конфіг, де описано MCP-сервер Hostinger, його адресу, набір інструментів і параметри підключення.

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

Другий крок — автентифікація. MCP-конфігурація, яку надає Hostinger, містить місце для API-токена, але не сам токен. Щоб Claude міг виконувати реальні операції з обліковим записом Hostinger, потрібно:

перейти на ту ж API-сторінку в Hostinger;

створити новий токен, задавши йому назву (у прикладі — «claude code») і строк дії;

згенерувати токен і скопіювати його.

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

Після оновлення конфігурації Claude потрібно перезапустити MCP-сесію. У прикладі це робиться через команди /new і /mcp у Claude Code. Після перезапуску в інтерфейсі з’являється підключений Hostinger MCP із позначкою, що він активний, і з переліком усіх 118 доступних інструментів.

Цей момент — ключовий: саме тут Claude «бачить» Hostinger як ще один набір інструментів, із якими він може працювати так само, як із файловою системою чи Git. Далі будь-які дії з інфраструктурою — це вже звичайні запити в чаті.

Від запиту в чаті до живого сайту: практичний сценарій

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

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

Далі Тім формулює завдання максимально простою мовою: створити дуже простий сайт, який виводить текст «Hi, my name is Tim.», і розгорнути його на домені timmer.com. Для Claude це комбіноване завдання: потрібно згенерувати мінімальний HTML (або інший формат, залежно від обраного стеку), підготувати структуру сайту, а потім, через інструменти Hostinger MCP, розгорнути його на вибраному домені.

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

Фінальна перевірка відбувається вже в браузері: перехід на timmer.com показує сторінку з текстом «Hi, my name is Tim.». Це підтверджує, що деплой дійсно пройшов через Hostinger, DNS налаштовано, і сайт працює як звичайний продакшн-ресурс.

Цей приклад навмисно максимально простий. Він не демонструє складних CI/CD-пайплайнів, контейнеризації чи масштабування. Але саме в цьому й сила демонстрації: вона показує, що Claude може замкнути повний цикл від ідеї до живого ресурсу, використовуючи Hostinger MCP як «руки» в інфраструктурі.

Що це змінює для розробників і чому важливі деталі налаштування

Інтеграція Hostinger MCP із Claude Code змінює звичну межу між «кодом» і «інфраструктурою». Раніше навіть у найзручніших AI-асистентах розробник усе одно мав:

виходити в браузер, щоб купити домен;

заходити в панель керування, щоб налаштувати DNS;

користуватися окремим CLI або SSH, щоб розгорнути застосунок на VPS.

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

Водночас інтеграція вимагає уважності до деталей:

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

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

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

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

З іншого боку, як тільки базова інфраструктура налаштована, Hostinger MCP перетворює Claude Code на щось дуже схоже до універсального DevOps-терміналу, де роль людини зміщується від ручного виконання команд до формулювання завдань і контролю результату.

Висновки: Claude виходить за межі редактора коду

Hostinger MCP показує, як AI-інструменти кодування поступово виходять за межі суто «розумних IDE» і починають керувати реальною інфраструктурою. У демонстрації Tech With Tim Claude не просто допомагає писати код, а:

підключається до облікового запису Hostinger через MCP;

отримує доступ до 118 інструментів керування хостингом;

перевіряє доступні домени;

створює й деплоїть сайт на реальний домен;

робить усе це без участі користувача в панелі керування чи терміналі поза Claude.

Ключовими елементами цієї схеми є правильно підібраний хостинг-план (у прикладі — бізнес-тариф приблизно за 4 долари на місяць із підтримкою до 50 сайтів і безкоштовним доменом), коректно налаштований MCP-конфіг у Claude Code та API-токен Hostinger, а також попередньо зареєстрований домен із заповненими даними власника.

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

Джерело

YouTube: I Tried 100+ Claude Code Skills. These 6 Are The Best.

У спільноті розробників навколо Claude Code поступово формується новий шар інструментів — так звані skills, які розширюють можливості середовища й перетворюють його на повноцінний робочий простір для створення продуктів. У свіжому огляді на каналі Tech With Tim одним із ключових прикладів такого підходу став GStack — репозиторій із 23 навичками Claude Code, який створив Гаррі Тан, президент і CEO Y Combinator.

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

GStack як «операційна система» для засновника

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

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

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

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

Від болю до плану: як працює office_hours і plan

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

У практичному сценарії це виглядає так: користувач відкриває Claude Code у каталозі з проєктом або в новій директорії, запускає команду /office_hours і описує, який продукт або фічу хоче створити. Наприклад, внутрішнє бухгалтерське ПЗ для YouTube-бізнесу з обліком інвойсів, витрат і загального фінансового стану.

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

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

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

CEO_review, review і QA: як AI симулює різні ролі в команді

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

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

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

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

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

Установка за один крок: як GStack інтегрується в Claude Code

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

У репозиторії GStack на GitHub у файлі README наведено великий абзац конфігурації. Саме він є «ключем» до встановлення. Користувач копіює цей текст, відкриває Claude Code у терміналі (наприклад, просто набираючи claude), вмикає автоматичний режим, якщо хоче, щоб система виконувала всі кроки самостійно, і вставляє скопійований абзац у термінал.

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

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

Після встановлення типовий сценарій виглядає так: користувач виходить із початкової сесії, переходить у директорію з реальним проєктом або створює нову, запускає Claude Code вже в цьому контексті й починає з /office_hours. Далі, у міру просування, підключаються /plan, /CEO_review, /review, /QA та інші команди, залежно від стадії роботи.

Стартовий набір для AI-асистованої розробки

У відео, де розглядається понад сотня Claude Code skills, GStack з’являється першим у списку з шести відібраних інструментів. Це не випадковий порядок: бандл подається як базовий шар, на який уже можна нашаровувати інші можливості — на кшталт інфраструктурних або веб-скрейпінгових навичок.

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

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

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

Висновки: AI як дисципліна, а не магія

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

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

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

Джерело

YouTube: I Tried 100+ Claude Code Skills. These 6 Are The Best.