У новій хвилі генеративного AI частина творців контенту обмежується «поставити запит — отримати відповідь». Інші перетворюють моделі на повноцінну операційну систему для бізнесу. Підприємиця та блогерка Марина Могилко (канал Silicon Valley Girl) і експертка з AI та колишня лідерка напрямку штучного інтелекту в Amazon Еллі Міллер демонструють саме другий підхід: вони будують навколо Claude та багатoагентних систем цілісні, самозапускаючі робочі процеси, які масштабують контент і продуктивність без збільшення команд.

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

Claude як продакшн-середовище: коли LLM стає центром редакції

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

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

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

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

Окремий Claude-проєкт для кожного каналу: чому контекст вирішує все

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

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

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

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

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

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

Від поради до системи: як Claude реалізує стратегію generative engine optimization

Навіть маючи сильну внутрішню AI-інфраструктуру, Могилко не відмовляється від зовнішніх стратегів. Їхня цінність — у свіжому погляді та ідеях, які не завжди народжуються всередині команди чи моделі. Показовий кейс — стратегія GEO, generative engine optimization.

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

Замість того щоб наймати окремого спеціаліста з GEO, команда використала Claude як двигун реалізації. Модель допомогла:

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

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

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

Від реактивного до проактивного AI: як працює система з 36 робочих процесів і сотні агентів

Якщо Claude-проєкти Могилко — це приклад глибокої інтеграції однієї моделі в медіабізнес, то система Еллі Міллер демонструє наступний рівень — багатoагентну архітектуру, де AI не чекає запиту, а сам ініціює роботу.

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

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

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

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

Приклади проактивних агентів: від ранкового брифінгу до «п’ятничного рев’ю» пошти

Щоб зрозуміти, як виглядає така система в повсякденному житті, варто подивитися на конкретні сценарії, які описує Міллер.

Один із них — ранковий брифінг. Поки вона спить, агент збирає й структурує:

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

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

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

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

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

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

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

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

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

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

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

У випадку Могилко відповіддю стали окремі Claude-проєкти з глибоким підключенням до Notion і даних каналу. У випадку Міллер — мережа агентів, запланованих у Claude Co-Work і Claude Code, які працюють за розкладом.

Висновок: AI-системи, а не AI-запити

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

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

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

Джерело

The 8 AI Tools That Will Change How You Make Money — Silicon Valley Girl

Локальні великі мовні моделі (LLM) стають дедалі доступнішими завдяки інструментам, які спрощують їх установку та керування. Один із таких інструментів — OpenClaw. На каналі Tech With Tim показано базовий робочий процес: як підключити модель Gemma 4 до OpenClaw і зробити її доступною локально. Нижче — покроковий розбір цього процесу.

Що таке OpenClaw і навіщо працювати локально

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

Робота з моделлю локально, а не через хмару, дає кілька очевидних плюсів:

• контроль над даними (нічого не йде на сторонні сервери);
• відсутність залежності від зовнішніх API;
• можливість використовувати власне «залізо» (наприклад, Mac mini чи інший домашній сервер).

У цьому прикладі використовується модель Gemma 4, яку OpenClaw може підхопити як локальну.

Базове налаштування: команда openclaw configure

Після встановлення OpenClaw на машину подальші дії виконуються через термінал.

1. Запуск конфігуратора:
   bash
openclaw configure
   Ця команда відкриває інтерактивне меню налаштувань.

2. Вибір моделі:

3. У меню потрібно перейти до пункту model.
4. Навігація здійснюється стрілками на клавіатурі, вибір — клавішею Enter.

5. У списку моделей має з’явитися встановлена модель (зокрема, Gemma 4).

6. Вибір режиму роботи:

7. Серед доступних варіантів важливо обрати local only.

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

9. Налаштування базової URL-адреси:

10. Поле base URL можна залишити без змін — стандартне значення підходить для типового сценарію.
11. Додаткових правок на цьому етапі не потрібно.

Активація моделей Gemma 4 в OpenClaw

У конфігураторі OpenClaw доступний список моделей, які можна активувати.

• У прикладі обираються:
• Alama Gemma 4 latest
• Gemma 4
• Обидві моделі відзначаються у списку, після чого підтверджується вибір (кнопка confirm або Enter).

Для більшості користувачів основною буде саме Gemma 4, але можна активувати кілька варіантів одночасно. Після підтвердження обрані моделі стають «увімкненими» в конфігурації OpenClaw.

Далі потрібно:

• переконатися, що у полі моделі обрано саме встановлену Gemma 4 (або ту, яку ви інсталювали);
• натиснути Enter, щоб зафіксувати вибір;
• перейти до завершення налаштування, натиснувши continue.

Перезапуск gateway: щоб модель стала доступною

Щоб зміни в конфігурації набули чинності, необхідно перезапустити gateway OpenClaw. Це робиться окремою командою в терміналі:

openclaw gateway restart

Після виконання:

• gateway перезапускається з оновленими налаштуваннями;
• обрані моделі (наприклад, Alama Gemma 4 latest і Gemma 4) стають доступними для використання;
• їх можна викликати безпосередньо через OpenClaw у ваших застосунках або інструментах, які інтегруються з цим шлюзом.

Фактично, на цьому етапі локальна LLM-модель уже інтегрована в інфраструктуру OpenClaw і готова до роботи.

Джерело

YouTube: Watch till the end… — Tech With Tim

Як перетворити хаотичну ідею на чіткий технічний опис: AI‑моделі та диктування як новий етап у проєктуванні застосунків

У 2026 році створення застосунку з допомогою штучного інтелекту може бути або майже безболісним, або повним провалом. Розробник і ютубер Tech With Tim у своєму детальному гайді про дев’ятиетапний процес побудови AI‑додатків показує, що ключова різниця — не в інструментах, а в тому, наскільки структуровано ви плануєте продукт до того, як починаєте писати код. Один із найцікавіших аспектів його підходу — використання поєднання AI‑асистента (на прикладі Claude) та голосового диктування (через Wispr Flow), щоб за 30–45 хвилин перетворити «сиру» ідею на повноцінну специфікацію застосунку.

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

Від «хочу щось зробити» до чіткого бачення: навіщо витрачати 45 хвилин до першого рядка коду

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

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

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

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

Claude як технічний редактор: як AI збирає специфікацію Creator Circle

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

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

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

Коли достатньо контексту зібрано, модель генерує структурований документ: «Creator Circle MVP Specification». У ньому з’являються розділи на кшталт огляду, опису основного користувача, «job to be done», переліку фіч, нецілей (тобто того, що свідомо не входить у першу версію), а також пропозиції щодо технологічного стека для фронтенду, бекенду, бази даних і розгортання.

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

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

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

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

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

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

чи будуть публічні й приватні профілі;

чи потрібні коментарі, репости, прямі повідомлення;

який очікуваний обсяг користувачів і як це вплине на вибір інфраструктури.

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

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

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

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

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

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

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

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

У поєднанні з Claude це створює цікавий робочий цикл: людина говорить — Wispr Flow перетворює це на структурований текст — Claude ставить уточнювальні питання й формує специфікацію — людина знову відповідає голосом. У результаті за відносно короткий час виходить документ, який зазвичай народжується через кілька днів листування в таск‑трекері чи довгих сесій у Google Docs.

Планування як запобіжник проти «нічного vibe‑кодування»

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

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

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

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

Висновок: AI як прискорювач дисципліни, а не заміна інженера

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

Рекомендація витратити 30–45 хвилин на таку сесію перед першим рядком коду виглядає скромною, але в контексті сучасних AI‑інструментів це може бути найважливіша інвестиція часу в усьому проєкті. Claude у ролі технічного співрозмовника й Wispr Flow як швидкий канал введення думок дозволяють зробити цей етап не лише ефективним, а й природним — ближчим до того, як люди насправді обговорюють ідеї вголос, а не як вони змушені їх формалізувати в документах.

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

Джерело

YouTube: How to Make an App With AI – 9 Steps

У глобалізованому візуальному середовищі, де бренди, сайти й афіші дедалі більше нагадують одне одного, питання оригінальності стає не примхою, а професійною необхідністю. На сцені TEDNext 2025 дизайнер Лопе Гутьєррес-Руїс поділився трьома підходами, які допомагають його студії системно виходити за межі шаблонів і створювати роботи, що справді вирізняються.

1. Команда з радикально різним досвідом

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

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

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

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

2. Шукати рішення в суміжних, а не очевидних сферах

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

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

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

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

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

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

3. Бути «адитивним»: будувати сміливі рішення одне на одному

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

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

Приклад — виставка Hundred Points, найбільший незалежний проєкт студії. Це експозиція графічного дизайну з чотирьох міст: Остіна, Сан-Паулу, Каїра та Гельсінкі. Виставка займає близько 4000 квадратних футів і включає 50 проєктів, але важливі не масштаби, а принципи, за якими її побудовано.

Куратори свідомо пішли проти звичних музейних підходів до показу графічного дизайну:

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

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

Оригінальність як результат системних рішень

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

Потрібні системні зміни:

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

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

Джерело

3 Ways to Create a Truly Original Design | Lope Gutierrez-Ruiz | TED

GitHub за останній рік перетворився на один із найважливіших майданчиків для експериментів з Model Context Protocol (MCP) — інтерфейсом, через який агенти LLM отримують доступ до зовнішніх сервісів і даних. Компанія відкрила локальний MCP‑сервер у квітні 2024 року, а нещодавно проєкт відсвяткував перший рік існування. Сам Морроу, який очолює розробку MCP‑сервера GitHub, на конференції AI Engineer Europe у Лондоні розповів, як команда пройшла шлях від «інструментального перегріву» до значно більш ощадливого та передбачуваного інтерфейсу для агентів.

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

Коли «більше інструментів» робить агентів гіршими

Публічний MCP‑шлях GitHub стартував із гучного запуску: репозиторій локального сервера швидко став одним із найзірковіших на GitHub за тиждень, а спільнота почала масово додавати нові інструменти. Платформа GitHub за своєю природою величезна, тож MCP‑поверхня швидко розрослася: репозиторії, issues, pull requests, GitHub Actions, проєкти та інші сутності — для всього з’являлися окремі тули.

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

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

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

«Tool sets» і динамічний вибір: елегантні рішення, якими майже ніхто не користується

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

Наприклад, окремий набір для роботи з pull requests, інший — для issues, ще один — для GitHub Actions. Користувачі могли конфігурувати ці групи у JSON‑налаштуваннях, вмикаючи тільки потрібні. Це мало зменшити обсяг початкового контексту, який отримує модель, і водночас зберегти доступ до повного спектра можливостей для тих, хто готовий їх явно вмикати.

Другим кроком стала динамічна селекція інструментів. Замість того, щоб одразу завантажувати всі tool sets, GitHub реалізував механізм, за якого агент може «відкривати» групи інструментів порціями. Спочатку агент бачить лише базовий набір, а потім, за потреби, може «відкрити» додаткові групи. Це дозволяє уникнути ситуації, коли весь опис 100+ тулів опиняється в контексті ще до того, як агент зрозумів, що йому взагалі потрібно робити.

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

Однак на практиці всі ці елегантні рішення вперлися в людський фактор. Переважна більшість користувачів GitHub MCP продовжила користуватися дефолтними налаштуваннями, не витрачаючи час на ручну конфігурацію tool sets. Формально можливість тонкого налаштування існувала, але реальна поведінка користувачів показала: якщо щось вимагає редагування JSON, цим скористається лише невелика меншість.

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

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

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

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

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

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

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

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

Від економії на описах до економії на вихідних токенах

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

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

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

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

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

Як підвищити успішність викликів: інтенція агента і серверні багатокрокові операції

Оптимізація контексту — лише одна сторона задачі. Інша — зробити так, щоб агенти рідше помилялися у виборі й використанні інструментів. GitHub окремо сфокусувався на зменшенні кількості невдалих викликів MCP‑тулів, і нині успішність викликів перевищує 95 відсотків.

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

Йдеться про те, що один виклик MCP‑тулу насправді може приховувати за собою кілька API‑запитів до GitHub. Замість того, щоб змушувати агента поетапно викликати кілька інструментів (наприклад, спочатку знайти репозиторій, потім перевірити права, потім виконати дію), сервер бере на себе цю багатокрокову логіку. Якщо для надійного виконання операції потрібно зробити п’ять API‑запитів, GitHub робить їх на сервері, а не делегує це агенту.

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

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

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

Чому навіть «простий» режим read‑only вимагає підтримки на рівні клієнтів

Окремий пласт дискусії навколо MCP‑поверхні GitHub — це режими доступу й те, як вони відображаються в інтерфейсі інструментів. Команда додала до сервера режим read‑only, який напряму мапиться на анотацію read‑only hint у специфікації MCP. Приблизно 17 відсотків користувачів GitHub MCP сьогодні використовують цей режим.

Для багатьох організацій це очевидний варіант: дозволити агентам читати дані з GitHub, але не давати їм можливості змінювати репозиторії, issues чи pull requests. З точки зору MCP‑поверхні це означає, що набір доступних інструментів і їхня семантика змінюються залежно від режиму.

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

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

Висновок: дизайн MCP‑поверхні як окрема інженерна дисципліна

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

Початковий підхід «експонуємо все, що можемо» швидко привів до перевантаження агентів і неефективного використання контексту. Спроба перекласти оптимізацію на користувачів через tool sets і динамічний вибір інструментів виявилася надто оптимістичною: більшість людей залишилася на дефолтних налаштуваннях. У відповідь GitHub почав агресивно оптимізувати MCP‑поверхню на боці сервера: скоротив початковий контекст майже вдвічі, згрупував CRUD‑операції, звузив дефолтний набір до приблизно 40 тулів і радикально урізав вихідні токени для окремих інструментів, зокрема для переліку pull requests.

Паралельно команда підвищила успішність викликів до понад 95 відсотків, кодує інтенцію агента в інтерфейс інструментів, виконує багатокрокові API‑послідовності на сервері й запускає eval‑тести, щоб інструменти не «конкурували» між собою за увагу моделі. Режим read‑only і його помірне, але відчутне використання (близько 17 відсотків користувачів) показують, що навіть прості режими доступу можуть стати важливими для підприємств — за умови, що клієнти навчаться їх коректно відображати.

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

Джерело

Lessons from Scaling GitHub’s Remote MCP Server — Sam Morrow, GitHub

Коли технологічні медіа рознесли заголовки про те, що CEO AppLovin Адам Форугі отримав $83 млн компенсації у 2023 році й увійшов до списку найбільш високооплачуваних керівників США, історія виглядала простою: ще один технічний мільярдер, який «заробив космічні гроші». Але якщо розібратися в тому, як саме був влаштований його пакет, картина виявляється майже протилежною до стереотипу про гарантовані бонуси топменеджерів.

Форугі — співзасновник і CEO AppLovin, публічної adtech-компанії, яка вийшла на біржу у 2021 році, сягнула близько $40 млрд ринкової капіталізації, а потім у 2022‑му впала приблизно на 92% — до менш ніж $4 млрд. Саме на дні цього обвалу він уперше за багато років погодився на великий компенсаційний пакет. Але зробив це так, що фактично поставив власну винагороду на ставку «або 10x для акціонерів, або нічого».

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

Від «майже нуль» до першого великого пакета: чому 2022 рік став переломним

До 2022 року Форугі фактично не отримував компенсації як публічний CEO у звичному для Уолл-стріт сенсі. Його економічний інтерес в AppLovin складався з двох компонентів: засновницького пакета акцій і тієї частини капіталу, яку він купив власними грошима на ранніх етапах. Зарплата — лише мінімум, необхідний для медичного страхування та базових бенефітів.

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

Саме тому рішення 2022 року — вперше попросити про суттєву компенсацію — варто розглядати в іншому світлі. Воно не було спробою «забрати своє» після падіння. Навпаки, це був момент, коли компанія вже публічна, ринкова капіталізація впала з приблизно $40 млрд до менше ніж $4 млрд, а перед керівником стояло завдання розвороту в умовах публічного ринку, тиску інвесторів і щоденного спостереження за котируваннями.

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

Як працює «екстремальний» план: поріг у $9, сходинки до $80 і вимога 10x

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

Базова логіка виглядала так. Після падіння приблизно на 92% ринкова капіталізація AppLovin опинилася нижче $4 млрд, а акції торгувалися на рівні, з якого до IPO‑ціни було близько десятикратного зростання. Саме в цій точці було сформовано багаторівневий пакет:

• перший ключовий поріг — приблизно $9 за акцію. Нижче цього рівня план просто не працював: жодних виплат, жодного вестингу;
• наступний суттєвий рівень — близько $38–40 за акцію. Саме тут починали реалізовуватися перші частини пакета, але й цього було недостатньо для повної реалізації;
• верхній, максимальний рівень — близько $80 за акцію, тобто повернення до орієнтовної ціни IPO.

Між цими крайніми точками було ще кілька сходинок — загалом близько п’яти-шести рівнів, кожен з яких відкривав додаткову частину потенційної винагороди. Але принцип залишався незмінним: без подолання нижнього порогу в районі $9 — нуль, без руху вгору — нуль, без повернення до IPO‑рівня — немає повного вестингу.

Це означало, що для повної реалізації пакета ринок мав фактично переоцінити AppLovin у десять разів від мінімуму 2022 року. Після падіння на 92% саме так виглядає шлях назад до колишньої капіталізації: з приблизно $4 млрд до близько $40 млрд.

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

Чому $83 млн — це наслідок структури, а не «золота зарплата»

Коли у 2023 році загальна компенсація Форугі склала близько $83 млн, це автоматично вивело його до верхівки рейтингів найбільш високооплачуваних CEO США. У публічному просторі така цифра часто сприймається як синонім «гігантського кеша» або «золотого парашута». Але в цьому випадку механіка була іншою.

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

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

По-третє, важливо, що до 2022 року Форугі фактично не монетизував свою роль CEO через компенсаційні пакети. Його економічний результат був пов’язаний з тим, що він як засновник володів значною часткою бізнесу. Тому $83 млн у 2023‑му — це не кульмінація багаторічної ескалації зарплат, а радше концентрований ефект від одного, дуже специфічно спроєктованого плану.

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

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

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

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

Звідси й логіка: «я буду отримувати гроші лише тоді, коли ви, акціонери, вже повернули значну частину втраченої вартості». Поріг у районі $9 за акцію — це не просто технічний рівень, це психологічна межа між «компанія в кризі» і «компанія, яка почала відновлення». Наступні сходинки до $38–40 і далі до $80 — це вже зона, де ринок визнає не просто виживання, а відновлення й новий етап зростання.

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

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

Темний бік посади CEO: чому «менше платити» не завжди справедливо

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

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

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

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

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

Висновок: кейс AppLovin як тест для ринку й регуляторів

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

• до 2022 року він фактично не отримував значущої компенсації як CEO, обмежуючись мінімальною зарплатою для бенефітів;
• перший великий пакет був повністю побудований на відновленні ціни акцій після падіння на 92%;
• план починав працювати лише після подолання порогу близько $9 за акцію й передбачав кілька сходинок до приблизно $80 — рівня IPO;
• для повної реалізації пакета ринок мав оцінити компанію приблизно в 10 разів вище від мінімуму 2022 року;
• $83 млн у 2023 році — це не «нова норма» грошових виплат, а наслідок того, що акції подолали частину цих порогів.

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

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

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

Джерело

YouTube: $160B Market Cap, $5.48B Revenue, $10M EBITDA Per Head: Inside AppLovin’s Profit Engine

Компанія ASUS вивела на український ринок новий ноутбук ROG Zephyrus Duo (GX651) з двома 16-дюймовими екранами. Модель орієнтована на ігри та роботу з графікою, але ключова її особливість — саме формфактор із двома дисплеями.

Два 16-дюймові OLED-дисплеї

Ноутбук отримав одразу два сенсорні OLED-екрани з однаковими характеристиками:

• роздільна здатність 3K
• частота оновлення 120 Гц
• час відгуку 0,2 мс
• підтримка G-SYNC
• пікова яскравість до 1100 кд/м²
• 100% DCI-P3
• точність кольорів Delta E < 1

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

П’ять режимів використання

Конструкція дозволяє використовувати ноутбук у кількох сценаріях:

• класичний режим ноутбука
• режим двох екранів із від’єднаною клавіатурою
• режим “книги” (вертикальна орієнтація)
• режим спільної роботи (розкриття на 180°)
• режим перегляду у формі “намету”

Шарнір відкривається до 320°, а підставка дозволяє змінювати кут нахилу.

Знімна клавіатура

Клавіатура тут від’єднується і може працювати через Bluetooth. Її можна або закріпити на корпусі, або використовувати окремо.

Основні параметри:

• товщина — 5,1 мм
• хід клавіш — 1,7 мм
• RGB-підсвічування
• збільшений тачпад із підтримкою жестів

Продуктивність

У максимальній конфігурації ноутбук отримав:

• процесор Intel Core Ultra 9 386H
• відеокарту NVIDIA GeForce RTX 5090 (Laptop)

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

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

Корпус і підсвічування

Ноутбук виконаний у алюмінієвому корпусі, виготовленому на ЧПК-верстатах. Доступний у кольорі Stellar Grey.

Передбачене декоративне підсвічування Slash Lighting з 35 зонами.

Ціна

В Україні модель уже доступна за ціною від 399 999 грн за версію з:

• 64 ГБ оперативної пам’яті
• SSD на 2 ТБ

Технічні характеристики ASUS ROG Zephyrus Duo (GX651)

У корпоративному світі багатокомпонентні агенти й інструменти на базі великих мовних моделей дедалі частіше будуються навколо MCP (Model Context Protocol) — відкритого стандарту, створеного в Anthropic. Проте, попри тисячі доступних MCP‑серверів у офіційному реєстрі, більшість підприємств фактично не здатні використовувати більше ніж кілька з них.

Про те, чому так відбувається, розповідає Карана Сампат, forward deployed engineer в Anthropic і перший інженер у цій ролі поза США. Він працює безпосередньо з великими компаніями над впровадженням MCP та внутрішніми кейсами Anthropic. Його досвід показує: проблема не в самому стандарті MCP, а в тому, як підприємства намагаються його «операціоналізувати» — тобто зробити частиною масштабованої, безпечної інфраструктури.

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

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

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

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

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

Чому реєстрів недостатньо: де закінчується зручність і починається хаос

Офіційний реєстр MCP‑серверів — важливий елемент екосистеми. Він дає огляд доступних серверів, спрощує пошук і повторне використання вже створених інструментів. Anthropic цілком відверто пишається тим, що допомогла його створити.

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

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

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

По-третє, спостережуваність. Реєстр не відповідає на питання: хто, коли і як використовує конкретний MCP‑сервер у межах організації. Він не дає цілісної картини навантаження, помилок, «гарячих» інструментів, які реально несуть бізнес‑цінність. Для команд безпеки, SRE й продукту це означає роботу в темряві.

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

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

Коли кожен MCP живе за своїми правилами: фрагментація безпеки й інфраструктури

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP як спільна інфраструктура, а не колекція інтеграцій

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

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

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

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

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

Єдина «благословенна» платформа як кореневий центр довіри

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

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

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

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

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

MCP‑шлюз як практична форма цього контрольного шару

Практичним втіленням цієї «благословенної» платформи Anthropic бачить MCP‑шлюз — проміжний шар між MCP‑клієнтами (агентами, інтерфейсами на кшталт Claude.ai чи внутрішніми інструментами) та численними MCP‑серверами.

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

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

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

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

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

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

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

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

Ідентичність агентів і майбутнє MCP в enterprise‑середовищі

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

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

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

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

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

Але практичний досвід великих компаній, із якими працює Карана Сампат як forward deployed engineer Anthropic, показує інше: більшість організацій не здатні вийти за межі кількох MCP‑серверів. І причина не в протоколі, а в тому, як саме вони намагаються його впроваджувати.

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

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

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

Джерело

Bringing MCPs to the Enterprise — Karan Sampath, Anthropic

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

Від хаотичного беклогу до керованої системи

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

Сучасні моделі на кшталт ChatGPT можуть допомогти перетворити цей хаос на систему:

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

Ключовий момент у фразі «create a system» — не просто «допоможи мені з цими справами», а саме запит на побудову стійкого процесу, який можна повторювати й масштабувати.

ChatGPT як простір для зосередженої роботи

Опис відео визначає його як «простір для фокусованої роботи з ChatGPT». Це важливий зсув у сприйнятті ШІ: не як «чарівної кнопки», а як робочого середовища, де можна:

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

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

Від одноразової допомоги до довгострокової стратегії

Запит «очистити беклог» зазвичай виникає в кризовий момент, коли справ уже надто багато. Але системний підхід із використанням ШІ дозволяє:

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

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

Джерело

https://www.youtube.com/watch?v=2TGHO4apQ5I

У гонитві за новими AI‑інструментами легко загубитися в переліку «крутих» сервісів і пропустити головне: як саме топові засновники реально вбудовують моделі на кшталт ChatGPT, Gemini, DeepSeek і Claude у щоденну роботу й ухвалення рішень. В інтерв’ю на каналі Silicon Valley Girl підприємці, які будують компанії з десятками мільйонів користувачів, показують зовсім інший рівень використання AI: не як «розумний пошук» чи генератор текстів, а як постійного співрозмовника, панель експертів і навіть додаткові «80 пунктів IQ».

Ця стаття розбирає, як CEO Opus Clip Ян Сяо, колишній керівник Google X Мо Ґавдат і команда Workera використовують загальні мовні моделі як стратегічних партнерів — і що це означає для будь‑якої компанії, яка хоче працювати не просто швидше, а розумніше.

Від «задати питання» до «вести діалог»: як CEO Opus Clip використовує ChatGPT як мислячого партнера

Opus Clip — AI‑компанія для відео, яка за два з половиною роки виросла з нуля до 50 мільйонів користувачів і оцінки в 215 мільйонів доларів. Її CEO Ян Сяо при цьому називає своїм головним інструментом не складний парк агентів, а «звичайний» ChatGPT. Але спосіб, у який він його використовує, радикально відрізняється від того, як з моделлю працює більшість користувачів.

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

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

Він підкреслює два принципи, без яких AI не перетворюється на справжнього партнера.

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

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

Результат, за його словами, — відчуття «mindblowingly enlightened»: не тому, що AI «знає істину», а тому, що він змушує мислити глибше, ніж це зазвичай відбувається в голові засновника чи в короткій розмові з радником.

Щомісячний «рев’ю рішень» із ChatGPT: як документування підсилює пам’ять і якість стратегій

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

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

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

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

– нагадати про рішення, щодо яких сам засновник раніше висловлював сумніви;

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

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

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

Панель експертів замість одного «оракула»: як Мо Ґавдат змушує AI‑моделі сперечатися між собою

Колишній chief business officer Google X Мо Ґавдат підходить до AI ще більш радикально. Він відверто не довіряє жодній окремій моделі як «джерелу істини» і будує власну систему роботи з кількома AI, які фактично виконують роль панелі експертів.

Ґавдат нагадує, як у 2016 році пошук Google видавав «мільйон і пів відповідей» і чесно казав: «Я не знаю, що з цього правда, вирішуй сам». Сучасні LLM, на кшталт ChatGPT, поводяться інакше: формулюють одну відповідь упевненим тоном, створюючи ілюзію однозначності. При цьому, якщо заперечити моделі, вона легко «погоджується» й змінює позицію. Для Ґавдата це сигнал: відповідальність за пошук істини все одно залишається на людині.

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

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

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

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

«Позичені 80 пунктів IQ»: що означає віддати обчислення AI, але залишити собі мислення

Мо Ґавдат проводить ще одну важливу паралель — із появою наукових калькуляторів. Коли він навчався на інженера, використання таких калькуляторів на іспитах було заборонене. Коли заборону зняли, час розв’язання задач скоротився приблизно на 50%. Більшість студентів використали це, щоб швидше закінчити роботу й піти відпочивати. Сам Ґавдат витрачав вивільнений час на те, щоб розв’язати задачі вдруге й перевірити себе.

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

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

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

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

Claude як інженерний співробітник: як Workera кодує процеси в «скили» і знімає навантаження з маркетингу

Якщо Ян Сяо й Мо Ґавдат показують, як AI може підсилювати індивідуальне мислення засновника, то приклад Workera демонструє, як моделі стають повноцінними учасниками командних процесів. Компанія позиціонує себе як «Anthropic‑heavy shop» — усередині активно використовуються моделі Claude, зокрема Claude Code Max для інженерної роботи.

Claude Code Max у цьому контексті — не просто інструмент автодоповнення коду. Інженери Workera працюють із ним як із потужним співавтором, який допомагає писати, рефакторити й перевіряти код. Але ще цікавіше те, як компанія використовує концепцію «skills» — скілів, які Anthropic описує як файли, що задають спосіб виконання певного процесу.

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

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

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

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

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

Від особистого радника до інфраструктури рішень: що об’єднує ці підходи

На перший погляд, практики Яна Сяо, Мо Ґавдата й Workera відрізняються: один використовує ChatGPT як особистого радника, другий — будує «панель AI‑експертів», третя — кодує процеси в Claude. Але в основі всіх трьох підходів лежить одна спільна ідея: загальні мовні моделі перестають бути інструментом «разового запиту» й перетворюються на довгострокових партнерів у мисленні та операціях.

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

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

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

Висновок: стратегічний AI — це не про інструмент, а про спосіб мислення

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

– поверхневими помічниками, які відповідають на запити й генерують тексти;

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

Різниця між цими двома сценаріями — у глибині інтеграції й готовності людей залишатися в центрі мислення, а не віддавати його повністю машинам. Ян Сяо показує, як перетворити ChatGPT на особистого радника засновника. Мо Ґавдат — як не дозволити жодній моделі монополізувати істину й використати AI як множник інтелекту, а не його заміну. Workera — як зробити Claude частиною операційної тканини компанії, щоб кожен інженер міг діяти в рамках бренд‑стандартів без постійного контролю.

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

Джерело

The 8 AI Tools That Will Change How You Make Money — Silicon Valley Girl

У 2026 році створення застосунку з використанням штучного інтелекту може бути або майже безболісним, або повністю некерованим процесом. Канал Tech With Tim, відомий практичними гайдами для розробників, пропонує жорстко структурований підхід: дев’ятиетапний роадмап, який має відділити продуктивну роботу від хаотичного «vibe coding» о другій ночі. Цей підхід охоплює шлях від першої ідеї до розгортання продукту, включно з плануванням, вибором стеку технологій, тестуванням і реальним релізом.

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

Від «vibe coding» до процесу: чому без чіткої структури AI лише заважає

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

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

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

Етап 1: що саме ви будуєте і коли це «готово»

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

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

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

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

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

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

Етап 2: планування застосунку та вибір стеку — від ідеї до специфікації

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

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

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

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

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

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

У результаті з’являється структурований документ на кшталт «Creator Circle MVP Specification». У ньому фіксуються основні розділи: огляд, первинний користувач, основна задача, нецілі (тобто те, що свідомо не входить до першої версії), список функцій, а також рекомендований стек для фронтенду, бекенду, бази даних і розгортання. Якщо розробник має досвід, він може критично оцінити ці пропозиції, поставити моделі зустрічні запитання: чому обрано саме цю мову, чи варто використовувати окремий бекенд, чи підходить PostgreSQL, чи краще взяти Supabase тощо.

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

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

Етап 3: таймлайн як інструмент проти прокрастинації та нескінченного «MVP»

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

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

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

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

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

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

Етап 4: no‑code/hosted платформи проти власної розробки з AI‑кодерами

Четвертий етап роадмапу — критичне розгалуження: як саме будувати застосунок. У 2026 році існує дві основні траєкторії: використання no‑code або hosted AI‑платформ і розробка власноруч із допомогою AI‑кодерів.

Перший варіант — no‑code або хостингові AI‑платформи. Серед прикладів згадуються Lovable, Bolt, Replit, Mocha, VZero. Такі сервіси беруть на себе значну частину технічної складності: вони можуть згенерувати й розгорнути сайт, налаштувати інфраструктуру, забезпечити хостинг. Для простих проєктів, на кшталт лендінгових сторінок чи сайтів без складної логіки, це часто найшвидший і найраціональніший шлях. Користувачеві не потрібно розбиратися в бекенді, базах даних чи деплої; платформа робить усе за нього.

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

Другий варіант — будувати застосунок самостійно, використовуючи AI‑інструменти для написання коду. Тут згадуються такі рішення, як Cursor, Claude Code, Codex та інші просунуті AI‑кодери. Вони дають значно більше контролю над архітектурою, дозволяють гнучко налаштовувати бекенд, працювати з будь-якими базами даних і деплоїтися туди, де це потрібно саме вам. Але цей шлях вимагає хоча б базових знань програмування й розуміння бекенд‑розробки.

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

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

Приклад Creator Circle: як виглядає процес на реальному задумі

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

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

На другому етапі Creator Circle стає основою для діалогу з Claude. Розробник диктує опис платформи, просить модель ставити запитання, допомогти сформувати список функцій, визначити фронтенд, бекенд, базу даних і стратегію розгортання. Після кількох ітерацій з’являється структурований документ «Creator Circle MVP Specification» із чітко розписаними розділами: хто основний користувач, яка головна задача, які функції входять у першу версію, які — ні, який стек рекомендовано.

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

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

Висновок: AI спрощує розробку, але не скасовує дисципліну

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

Четвертий етап — вибір між no‑code/hosted‑платформами й власною розробкою з AI‑кодерами — визначає, наскільки керованим буде ваш проєкт у довгостроковій перспективі. Приклад Creator Circle демонструє, як цей підхід працює на реальній ідеї: від однієї фрази про проблему до повноцінної специфікації й місячного плану розробки.

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

Джерело

How to Make an App With AI – 9 Steps — Tech With Tim

Інвестиційний подкаст 20VC з Гаррі Стеббінгсом опублікував розмову з Адамом Фероджі, засновником і CEO AppLovin. Це компанія, яку сам ведучий ставить у топ-5 найвражаючих бізнесів, з якими він стикався за десятиріччя інтерв’ю з тисячею керівників великих корпорацій. Причина — у поєднанні унікальних фінансових показників і специфічного «менталітету засновника», який визначає культуру компанії.

Фінансові показники, що «не мають сенсу» для ринку

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

• Ринкова капіталізація — близько 160 млрд доларів.
• Виручка — 5,48 млрд доларів.
• EBITDA на одного співробітника — близько 10 млн доларів.

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

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

Менталітет засновника: «гнатися за перемогою», а не за зарплатою

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

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

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

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

Ціна успіху: відсутність присутності в особистому житті

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

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

Страх «вибуху» як рушійна сила

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

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

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

Джерело

There is no company on the planet like AppLovin — 20VC with Harry Stebbings

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

Коли говорять про AppLovin, зазвичай згадують цифри: ринок капіталізації близько $160 млрд, понад $5,4 млрд виручки, близько $10 млн EBITDA на одного співробітника й маржа понад 80%. Але за цими показниками стоїть не лише технологія й бізнес-модель, а й дуже специфічна психологія засновника.

У розмові з ведучим подкасту 20VC Гаррі Стеббінгсом співзасновник і CEO AppLovin Адам Форугі розкриває, що насправді рухає ним як підприємцем, чому гроші давно перестали бути мотивацією, як виглядає страх катастрофічного краху зсередини — і якою ціною для особистого життя дається побудова компанії з такими аномальними показниками. Стеббінгс, який за 10 років узяв інтерв’ю приблизно в тисячі CEO великих компаній, ставить Форугі в свій особистий топ-5 керівників — і це багато говорить про незвичність його мислення та виконання.

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

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

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

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

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

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

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

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

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

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

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

Страх катастрофічного краху як постійний фон

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

Цей страх особливо загострився в 2022 році, коли AppLovin, що вийшла на біржу в 2021-му й досягла приблизно $40 млрд ринкової капіталізації, за рік втратила близько 92% вартості, опустившись до менш ніж $4 млрд. Для публічної компанії такого масштабу це фактично вільне падіння: акція падає майже щодня, а щоб повернутися до стартової точки, потрібно зростати приблизно в 10 разів.

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

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

«Коли цифри не вкладаються в голову, люди думають, що ти мухлюєш»

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

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

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

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

Ціна успіху: відсутність «присутності» в особистому житті

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

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

У 2022 році, на тлі 92-відсоткового падіння капіталізації, цей розрив став настільки відчутним, що Форугі змушений був зупинитися й переглянути власний спосіб життя. Він побачив дві критичні зони руйнування: здоров’я й стосунки.

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

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

Маленькі «вікна присутності» й хобі як інструмент виживання CEO

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

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

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

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

Один із «топ-5» серед тисячі: чому ментальність Форугі виділяється

Оцінка Гаррі Стеббінгса, який називає Адама Форугі одним із п’яти найкращих CEO, з якими він коли-небудь працював, важлива не як комплімент, а як контекст. Ведучий 20VC за десятиліття поспілкувався приблизно з тисячею керівників найбільших компаній світу. На цьому тлі потрапити в його персональний топ-5 означає, що в ментальності й виконанні Форугі є щось нетипове навіть для еліти.

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

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

Висновок: темна сторона великих чисел

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

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

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

Джерело

YouTube: $160B Market Cap, $5.48B Revenue, $10M EBITDA Per Head: Inside AppLovin’s Profit Engine