Perplexity запустила Personal Computer — програмного AI‑агента для macOS, який може читати файли, відкривати застосунки, надсилати повідомлення й виконувати багатокрокові завдання у фоновому режимі. Канал Teacher’s Tech показує, як це працює на практиці, скільки коштує сервіс і для яких сценаріїв він дійсно має сенс.

Що таке Perplexity Personal Computer і як він працює

Personal Computer — це не «залізо», а софт для Mac, який переносить агент Perplexity з хмари безпосередньо на ваш комп’ютер.

Ключові відмінності:

• Працює на вашій машині
  Агент бачить реальні файли, може відкривати програми, взаємодіяти з вікнами й виконувати дії у вашому звичному робочому середовищі.
• «Операційна система цілей»
  Замість покрокових інструкцій користувач формулює завдання («знайди всі квитанції за місяць і зроби таблицю»), а агент сам обирає, які програми й дії використати.
• Постійний фоновий режим
  Якщо запустити Personal Computer на Mac mini, пристрій може працювати 24/7: агент виконує задачі, навіть коли ви не за комп’ютером.

Технічні вимоги:

• macOS 14 Sonoma або новіша;
• рекомендований форм‑фактор — Mac mini: компактний, тихий, розрахований на постійну роботу.

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

• Accessibility (для керування інтерфейсом і кліків);
• Full Disk Access (для читання файлів).

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

Інтерфейс, що «розуміє» застосунки

Personal Computer викликається поєднанням двох клавіш Command (ліва + права). Головна особливість — контекстна обізнаність про активний застосунок.

Контекстні інструменти

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

• Notes
  – створення нотаток
  – перегляд нотаток
  – пошук по папках тощо
• Mail
  – написання листів
  – читання вхідних
  – пошук по пошті

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

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

Приклад: створення файлу з промпту

У Finder можна дати завдання на кшталт:

«Напиши історію про собаку й кота та збережи її на робочому столі».

Агент:

1. Створює текст;
2. Формує файл;
3. Розміщує його на Desktop.

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

Де Personal Computer справді економить години

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

Натомість справжня цінність з’являється на:

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

Сценарій 1: автоматичне збирання квитанцій з пошти

Завдання:

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

Що робить агент:

1. Сканує вхідні за вказаний період.
2. Визначає листи з квитанціями/рахунками.
3. Витягує потрібні поля (дата, vendor, сума, опис).
4. Формує електронну таблицю.
5. Пропонує зберегти її як Excel або в Google Drive.

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

Сценарій 2: фото‑квитанції, таблиця й діаграма витрат

Багато витрат не потрапляють у пошту — це паперові чеки, які користувач фотографує. У прикладі всі такі фото лежать у папці March receipts на Desktop.

Завдання:

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

Що відбувається:

1. Агент проходить усі зображення (PNG тощо).
2. Розпізнає текст на чеках.
3. Витягує потрібні дані.
4. Формує таблицю з:
5. назвами чеків,
6. датами,
7. продавцями,
8. сумами,
9. категоріями.
10. Додає підсумки за категоріями.
11. Створює кругову діаграму витрат.
12. Експортує результат, наприклад, у Google Drive.

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

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

Уся операція зайняла близько 4,5 хвилин очікування без активної участі користувача.

Керування Mac з телефона

Якщо встановити застосунок Perplexity на смартфон, можна:

• надсилати завдання зі свого телефона;
• агент виконуватиме їх на Mac, який лишився вдома чи в офісі.

Приклад:

«Знайди три найбільші за сумою квитанції й створи таблицю».

Навіть якщо інструкція надіслана з черги в супермаркеті, агент:

1. Підключається до Personal Computer на Mac;
2. Виконує пошук і обробку;
3. Формує таблицю з потрібними записами.

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

Обмеження, безпека та ціна

Не автономний співробітник

Personal Computer:

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

Як і інші сучасні агенти (зокрема, рішення Anthropic), він:

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

Обробка даних і приватність

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

Водночас передбачені запобіжники:

• Підтвердження чутливих дій (наприклад, надсилання листів).
• Повний журнал сесій (audit trail).
• «Kill switch» — миттєве вимкнення агента.

Вартість і цільова аудиторія

Personal Computer доступний лише в тарифі Perplexity Max:

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

План Perplexity Pro за $20/місяць:

• не включає Personal Computer;
• дає доступ до веб‑версії Perplexity Computer (хмарний агент без глибокої інтеграції з macOS).

Для більшості користувачів, які:

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

логічнішим вибором залишається саме Pro.

Personal Computer має сенс там, де:

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

Куди рухається індустрія

Модель, яку демонструє Perplexity Personal Computer, показує напрямок розвитку робочих середовищ:

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

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

Джерело

Perplexity Personal Computer – Your Mac Just Became an AI Agent — Teacher’s Tech

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

Від депресії до «поведінко-цетиків»

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

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

«Траст-фондові щури» проти тих, хто працює

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

Результат:

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

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

Щури за кермом: від відчуття контролю до дослідження радості

Історія з «водінням» почалася як вивчення агентності — відчуття контролю над подіями — та набуття навичок. Щурів навчили керувати спеціальними «rodent-operated vehicles» (ROV) і рухатися до дерева з Froot Loops. Після публікації перших результатів проект перетворився ще й на інструмент наукової популяризації: тварини стали «зірками» документальних фільмів, новин та подкастів.

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

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

Антидепресант очікування: протокол UPER

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

Це лягло в основу протоколу «unpredictable positive event responses» (UPER) — «непередбачувані позитивні події». Протягом п’яти тижнів щури щодня отримували три приємні події, але в різний час і в різному порядку. Серед них:

• LEGO-блок + Froot Loop: тварина бачить блок, але мусить чекати 15 хвилин до появи ласощів;
• соняшникове насіння: потрібно терпляче лущити, перш ніж з’їсти;
• «Rat Park»: щура саджають у транспортну клітку, везуть у інше приміщення, де він може вільно бігати й досліджувати простір; перед цим — три хвилини очікування в клітці.

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

Як виглядає «щуряча передрадість»

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

Проміжні результати:

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

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

Від щурів до людей: надія, «vorfreude» і культура провини за задоволення

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

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

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

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

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

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

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

Чи люблять щури водити? Поведінкове опитування без слів

Питання, яке Ламберт чує найчастіше: чи подобається щурам водити? Анкету їм не даси, але можна поставити вибір.

У новому експерименті тваринам запропонували два маршрути до дерева з Froot Loops:

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

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

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

Джерело

Kelly Lambert — I Taught Rats to Drive. They Taught Me to Enjoy the Ride | TED

Штучний інтелект став стандартним інструментом у роботі розробників, але разом із прискоренням рутини він приносить і нові пастки продуктивності. Канал Tech With Tim звертає увагу на одну з найпоширеніших — так званий «just fix it loop», коли взаємодія з AI для виправлення коду перетворюється на безкінечний обмін помилками та патчами.

Що таке «just fix it loop» і чому він небезпечний

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

Цей цикл виглядає приблизно так:

1. AI генерує код або «фікс».
2. Код падає з помилкою.
3. Розробник копіює помилку в підказку: «ось error, виправ».
4. AI генерує нову версію.
5. Помилка змінюється, але не зникає — або з’являються нові.
6. Кроки 3–5 повторюються десятки разів.

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

Як AI перетворює дрібну помилку на годинник втраченої роботи

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

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

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

Коли варто зупинитися й перейти до ручного кодування

Головна порада — не дозволяти «циклу виправлень» розкрутитися. Є кілька простих орієнтирів, коли варто натиснути на гальма:

• Час перевищив очікування. Якщо на виправлення дрібної задачі вже пішло більше, ніж ви б витратили на ручну реалізацію (наприклад, 10–15 хвилин), це сигнал зупинитися.
• Промпти звелися до «ось помилка, просто виправ». Коли взаємодія з AI перетворюється на механічне пересилання error message без осмислення, продуктивність падає.
• Помилки змінюються, але не зникають. Якщо кожна нова відповідь AI породжує інший стек-трейс, але проблема не вирішується, це ознака, що модель «блукає» без чіткого розуміння контексту.

У таких випадках раціональніше:

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

Часто це займає менше часу, ніж ще одна серія запитів до AI.

Як використовувати AI, не потрапляючи в пастку

AI-помічники залишаються корисними інструментами, але їх варто застосовувати усвідомлено:

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

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

Source

DO not get stuck in this LOOP — Tech With Tim

У світі AI-агентів зараз формується новий підхід до інтеграції з реальними системами. Замість того, щоб змушувати великі мовні моделі (LLM) викликати десятки й сотні JSON-інструментів, інженери починають дозволяти їм писати й виконувати код. Одним із найпослідовніших експериментаторів у цьому напрямку став Sunil Pai — розробник AI-агентів у Cloudflare та автор open source-інструмента для реального часу Partykit. На конференції AI Engineer він розповів про «Code Mode» — підхід, у якому LLM генерує виконуваний JavaScript, що працює поруч із API Cloudflare, і таким чином радикально спрощує архітектуру агентів та зменшує витрати токенів.

Коли tool calling ламається: масштаб як головний ворог

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

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

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

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

Cloudflare зіткнувся з цією проблемою в особливо концентрованому вигляді. Публічний API компанії — це приблизно 2 600 endpoint’ів. Якщо наївно перетворити кожен endpoint на окремий інструмент для LLM, доведеться передати в перший виклик моделі опис усієї цієї поверхні. За оцінками інженерів, це близько 1,2–1,5 мільйона токенів лише на стартову інструкцію. Для більшості практичних систем це просто неприйнятно — як з точки зору вартості, так і з точки зору затримок.

На цьому тлі стає зрозуміло, чому в Cloudflare почали шукати радикально інший підхід.

Code Mode: замість тисячі інструментів — один JavaScript

Ідея Code Mode в Cloudflare виглядає на диво простою: замість того, щоб змушувати LLM повертати JSON-виклики інструментів, їй пропонують написати програму. Зазвичай це JavaScript, який запускається в контрольованому середовищі поруч із API.

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

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

Ключова перевага Code Mode полягає в тому, що вся складність переноситься з рівня діалогу з моделлю на рівень виконання коду. Замість десятка раундів взаємодії з LLM система робить один виклик, отримує програму, запускає її в середовищі, де вже є всі потрібні примітиви для роботи з API, і чекає результату.

Це не просто косметична зміна формату. Код дає моделі те, чого бракує традиційному tool calling: повноцінні програмні конструкції. У Code Mode агент може використовувати цикли для пагінації, зберігати проміжний стан між викликами, будувати складні послідовності дій, паралелізувати запити до різних endpoint’ів. Усе це — в одному фрагменті JavaScript, який виконується як звичайна програма.

Як стиснути 1,5 мільйона токенів до тисячі: два інструменти замість 2 600

Найяскравіший приклад того, як Code Mode змінює масштабованість, — експеримент Cloudflare з власним API. Замість того, щоб експонувати для моделі тисячі окремих інструментів, команда побудувала API для агентів, який складається лише з двох «tool’ів»: search і execute.

Обидва ці інструменти працюють не з окремими endpoint’ами, а з кодом. Вони приймають на вхід рядок JavaScript, який виконується в спеціальному середовищі.

У випадку search вхідною змінною для цього коду є повний OpenAPI JSON-специфікація всього API Cloudflare. Модель отримує можливість написати функцію, яка переглядає цю специфікацію, фільтрує, шукає потрібні маршрути, аналізує параметри. Іншими словами, замість того, щоб заздалегідь розписувати кожен endpoint як окремий інструмент, Cloudflare просто дає агенту програмний доступ до «карти» всього API.

Після того як search знаходить релевантні endpoint’и, у гру вступає execute. Цей інструмент повертає функції, які можна викликати проти знайдених endpoint’ів. Модель знову ж таки генерує JavaScript, який використовує ці функції для виконання конкретних дій: отримання списків, створення ресурсів, оновлення налаштувань.

У результаті опис усієї поверхні API, який у наївній схемі займав би 1,2–1,5 мільйона токенів, вдалося стиснути приблизно до 1 000 токенів. Це скорочення на порядку 99,9%. Замість гігантського JSON-опису тисяч інструментів агент бачить лише два: search і execute, плюс короткий опис того, як ними користуватися.

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

DDoS як приклад: один запуск замість восьми раундів

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

У традиційній моделі з MCP-сервером і tool calling агенту довелося б виконати низку послідовних кроків: отримати метрики, знайти підозрілу активність, витягнути списки IP, створити правила блокування, застосувати їх. Кожен крок — окремий tool call, окремий раунд взаємодії з LLM. Навіть не враховуючи проблему 1,2 мільйона токенів на опис усіх endpoint’ів, це перетворюється на приблизно вісім раундів запитів до моделі.

У Code Mode сценарій виглядає інакше. Агент отримує завдання у вигляді природної мови, після чого генерує один JavaScript-файл, який:

аналізує доступні через API метрики трафіку,
знаходить IP-адреси, що відповідають патерну атаки,
формує правила блокування,
застосовує їх через відповідні endpoint’и.

Цей код запускається безпосередньо поруч із API Cloudflare. Немає необхідності повертатися до моделі після кожного кроку, немає багатократних раундів tool calling. Уся логіка виконується «в один постріл», у межах одного запуску програми.

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

«Міфічний сервер»: як агент сам знаходить потрібний endpoint

Ще один показовий приклад — демо, яке в Cloudflare називають «mythical server». У ньому агенту дають завдання: «список моїх Workers». Для демонстрації йому надають лише read-only доступ.

Агент не отримує наперед список усіх можливих endpoint’ів. Замість цього він використовує search, щоб знайти в OpenAPI-специфікації Cloudflare API всі маршрути, які відповідають запиту «list workers» або подібним формулюванням. Це робиться через згенерований JavaScript, який переглядає JSON-опис API, фільтрує його за ключовими словами, параметрами, схемами.

Після того як потрібний endpoint знайдено, агент генерує ще один фрагмент JavaScript, який викликає цей endpoint через execute. У демо це виглядає як один запит до API, який повертає список усіх Workers акаунта. Далі код може, наприклад, пагінувати результати, обробляти помилки, форматувати вивід.

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

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

Від інтерфейсів для програмістів до інтерфейсів для всіх

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

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

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

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

Чому безпечне виконання коду стає критичною умовою

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

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

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

Для реалізації такого середовища Cloudflare використовує V8 isolates — ізольовані контексти JavaScript-движка V8. Вони стартують дуже швидко й мають за плечима близько десяти років «бойового» загартування в плані безпеки. Цей вибір добре лягає на філософію Code Mode: якщо агент генерує JavaScript, логічно виконувати його в середовищі, яке вже оптимізоване для цього й добре вивчене з точки зору загроз.

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

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

Висновок: Code Mode як новий рівень абстракції для AI-агентів

Перехід від JSON-based tool calling до Code Mode в Cloudflare показує, як швидко змінюється архітектура AI-систем, коли моделі починають сприйматися не як чат-боти, а як універсальні генератори програм. Там, де раніше доводилося будувати сотні інструментів і підтримувати гігантські контексти, тепер достатньо двох entrypoint’ів — search і execute — і можливості писати JavaScript.

Стиснення опису API з 1,2–1,5 мільйона токенів до приблизно тисячі — це не просто інженерний трюк. Це демонстрація того, що LLM можуть працювати з великими системами не через статичні переліки можливостей, а через динамічне дослідження й програмування поверх них. Приклади з DDoS-мітигацією й «міфічним сервером» показують, як один згенерований фрагмент коду може замінити багатокрокові діалоги з агентом.

Водночас Code Mode підкреслює, що майбутнє AI-агентів неможливе без серйозної роботи над середовищами виконання. Harness Cloudflare, побудований на V8 isolates і принципі «нульових можливостей за замовчуванням», — це відповідь на питання, як дозволити моделям писати й запускати код, не жертвуючи безпекою.

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

Джерело

Code Mode: Let the Code do the Talking – Sunil Pai, Cloudflare

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

Увага як новий базовий актив

Фраза «attention is more valuable than capital» у цьому контексті звучить не як гучний слоган, а як робоча гіпотеза сучасного венчурного ринку.

Ключові елементи цієї логіки:

• Увага — дефіцитний ресурс. Користувачі перевантажені контентом, продуктами й сервісами. Пробитися крізь цей шум стає складніше, ніж залучити черговий раунд фінансування.
• Капітал commoditized. Грошей на ринку багато: фонди, family offices, ангели, корпоративні інвестори. Конкуренція за угоди змушує капітал шукати додану вартість — і увага аудиторії стає одним із найсильніших «адонів».
• Інфлюенсер як «медіа-компанія в одній особі». Людина з мільйонною аудиторією фактично володіє власним каналом дистрибуції — незалежно від того, чи це YouTube, TikTok чи інші платформи. Для стартапу це може бути еквівалентом багатомільйонного маркетингового бюджету.

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

Як інфлюенсери стають інвесторами — і навпаки

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

Чому VCs йдуть у публічність

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

Чому інфлюенсерам складніше в інвестиціях

Перехід у венчур вимагає:

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

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

Стартап як бізнес — від Америки до creator economy

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

Політика як управління «компанією»

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

Ця логіка перегукується з тим, як будуються й бізнеси в creator economy: персональний бренд, аудиторія, монетизація, операційна ефективність. Креатор із сильною аудиторією фактично керує власною міні-компанією, де кожне рішення — від контенту до партнерств — впливає на P&L.

Від YouTube до інвестицій: коли креатор змінює трек

Окремий пласт розмови — емоційне вигорання та зміна фокусу. Пряме зізнання «YouTube, like I was done with it. I didn’t like it anymore» показує, що довгострокова ставка лише на одну платформу чи формат контенту виявляється вразливою.

Звідси кілька висновків для креаторів і технологічних підприємців:

• Диверсифікація активів. Перехід від чисто контентної діяльності до інвестицій — спосіб конвертувати тимчасову увагу в довгострокові частки в компаніях.
• Контроль над монетизацією. Формулювання «I take home like nearly 100%» підкреслює важливість моделей, де креатор максимально контролює дохід, а не віддає значну частину платформам чи посередникам.
• Пошук нових ролей. Від «ютубера» до інвестора, від інфлюенсера до партнера фонду — це не просто зміна ярлика, а спроба побудувати більш стійку кар’єру в межах ширшої технологічної екосистеми.

На цьому тлі навіть питання на кшталт «Do you think Trump is doing a good job?» звучать не як політичний офтоп, а як продовження дискусії про те, хто має право управляти великими системами — медійні фігури, бізнесмени чи кар’єрні політики.

Джерело

YouTube: Jake Paul: Attention is more valuable than capital

У промові на каналі AI Engineer інженер Anthropic Девід Сорія Парра окреслює наступний крок еволюції протоколу Model Context Protocol (MCP). Якщо раніше MCP сприймали переважно як спосіб підключати інструменти й API до агентів, тепер мова йде про повноцінні додатки з власним інтерфейсом, які «приходять» разом із сервером MCP і однаково працюють у хмарі, ChatGPT, VS Code чи Cursor. Це не плагіни, не SDK‑віджети й не UI, який модель імпровізує на клієнті, а застосунки, що реально сервляться з MCP‑сервера.

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

Від інструментів до повноцінних застосунків

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

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

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

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

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

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

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

Одна з найбільш практичних властивостей MCP‑додатків — можливість запускати один і той самий застосунок у різних клієнтах без змін у коді. Сервер MCP, який постачає UI й інструменти, можна підключити до хмарного середовища, до ChatGPT, до VS Code, до Cursor — і він «просто працює».

Це означає, що розробник:

не пише окремий плагін для кожного редактора коду чи чат‑клієнта;

не підтримує різні UI‑фреймворки під кожну платформу;

не дублює логіку інтеграцій у кількох SDK.

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

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

Сьогодні MCP‑пов’язані пакети сумарно мають близько 110 мільйонів завантажень на місяць. Ця цифра включає використання в SDK агентів OpenAI, SDK Google, LangChain та багатьох інших фреймворках і інструментах, які підтягують MCP як залежність. Для порівняння, одна з найуспішніших фронтенд‑бібліотек — React — виходила на подібний рівень завантажень приблизно вдвічі довше.

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

Чому потрібен семантичний шар, а не просто «ще один протокол»

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

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

Багато існуючих підходів в екосистемі агентів цього не дають. Вони дозволяють:

оголошувати інструменти з простими сигнатурами;

викликати REST‑ендпоінти;

описувати схеми параметрів.

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

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

ресурсів, з якими працює агент;

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

elicitation — керованого збору додаткової інформації;

авторизації та політик управління;

і, в експериментальному режимі, MCP‑додатків як структурованих UI.

Щоб MCP‑додаток міг однаково працювати в хмарному клієнті, у ChatGPT, у VS Code чи Cursor, усі ці клієнти мають розуміти одні й ті ж семантичні конструкції. Саме це робить можливим сценарій, коли один сервер MCP «постачає» застосунок, а різні клієнти лише відображають його відповідно до своїх можливостей, не змінюючи сам застосунок.

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

MCP як «UI‑транспорт» у стосунку до інших способів підключення

У баченні Anthropic 2026 рік має стати роком, коли агенти масово підуть у продакшн. Якщо 2024‑й був роком демонстрацій, а 2025‑й — роком «кодингових» агентів, то далі очікується перехід до загальних агентів для знаннєвої роботи: фінансового аналізу, маркетингу, роботи з кількома SaaS‑сервісами й спільними сховищами.

У такому світі підключення стає головною проблемою. Але, як підкреслює Сорія Парра, не існує єдиного способу підключення, який підходив би для всього. Замість цього формується стек із трьох основних компонентів: skills, MCP і CLI/computer use. Кожен із них має свою нішу.

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

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

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

У корпоративному контексті це означає, що:

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

агенти можуть працювати з тими ж системами, що й люди, через один і той самий MCP‑сервер;

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

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

Людина й агент в одному застосунку: подвійний інтерфейс MCP‑додатків

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

постачати UI, з яким працює користувач;

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

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

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

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

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

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

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

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

Висновок: MCP‑додатки як наступний рівень агентних платформ

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

MCP‑додатки пропонують кілька важливих властивостей:

вони дозволяють серверам MCP постачати повноцінні застосунки з UI, а не лише інструменти;

вони не є плагінами, SDK‑віджетами чи імпровізованим UI від моделі, а сервляться безпосередньо з MCP‑сервера;

один і той самий MCP‑додаток може працювати в різних клієнтах — хмарі, ChatGPT, VS Code, Cursor — без змін у коді;

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

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

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

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

Джерело

The Future of MCP — David Soria Parra, Anthropic

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

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

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

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

Щоб OpenClaw працював як багатомодельний агент, доводиться:

налаштовувати маршрутизацію між моделями на кшталт Gemini, Opus тощо, вирішуючи, що відповідає за ресерч, що — за планування, що — за написання коду;

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

окремо додавати «скіли» для коду, Git, веб‑доступу, деплою, інтеграцій.

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

Perplexity Computer пропонує протилежний підхід. Це повністю хмарний сервіс, який працює на інфраструктурі Perplexity, без жодного локального сетапу. Користувачеві достатньо оформити підписку Max за 200 доларів на місяць, яка включає 10 000 кредитів Computer, і можна одразу запускати завдання. Замість окремих API‑ключів — єдина кредитна система; замість ручної маршрутизації моделей — модель‑агностичний оркестратор, що сам вирішує, коли використати Grok, коли Gemini, коли Opus 4.6 чи інші «фронтирні» моделі.

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

підбирає моделі;

запускає паралельні субагенти;

використовує вбудовані скіли;

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

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

Вісім з половиною хвилин до готового продукту: конкурентний аналіз як веб‑додаток

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

Perplexity Computer отримує один промпт і далі працює автономно. Результат — повноцінна веб‑сторінка, яку сервіс автоматично деплоїть і надає як URL. Усередині — не просто статичний текст, а структурований звіт:

порівняння для різних типів користувачів — розробників, «knowledge workers», power‑юзерів, інженерних команд;

інтерактивний «head‑to‑head» аналіз, де можна перемикати інструменти і бачити їхні сильні сторони у вигляді графів навичок;

цінові таблиці та зрозумілий розклад по тарифах;

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

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

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

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

Дванадцять хвилин до фінансового дашборду: «AI Titans» як приклад глибшої інтеграції

Другий показовий кейс — фінансовий дашборд «AI Titans», присвячений Nvidia, Microsoft та Anthropic. Завдання складніше: потрібно не лише зібрати новини, а й витягнути фінансові дані, розділити публічні та приватні компанії, побудувати графіки, оцінити аналітичний сентимент і зібрати все це в єдиний інструмент.

Промпт включає вимогу:

дослідити три компанії;

витягнути останні новини;

зробити аналіз настроїв аналітиків;

знайти фінансові події й показники;

побудувати «комплексний дашборд», придатний для використання.

Perplexity Computer знову працює як оркестратор. У деталях завдання видно, що він піднімає кілька субагентів паралельно, завантажує вбудовані скіли «research assistant», «finance and markets», «website building», а потім запускає серію підзадач: збір фінансових даних, аналіз новин, побудова інтерфейсу. Частина роботи виконується моделлю Opus 4.6, про що сервіс явно повідомляє в логах.

Готовий дашборд містить:

поточні ціни акцій Nvidia та Microsoft;

порівняння останніх звітних кварталів;

графіки квартальної виручки для публічних компаній;

окрему траєкторію для Anthropic як приватної компанії;

блоки з аналітичним сентиментом — «bull case» і «bear case»;

стрічку останніх новин із датами, включно з подіями на кшталт GTC 2026.

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

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

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

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

Perplexity Computer робить ставку на багатий базовий набір. Уже в демо видно, що без додаткової конфігурації доступні:

дослідницький асистент для роботи з вебом і джерелами;

модуль «finance and markets» для збору ринкових і фінансових даних;

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

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

Важливо, що користувач не обмежений лише вбудованими можливостями. У Perplexity Computer є окремий «create skill» — скіл для створення скілів. Він генерує markdown‑опис нового інструменту, який можна переглянути, скопіювати й адаптувати. Це зберігає гнучкість, знайому користувачам OpenClaw, але переносить її на вищий рівень абстракції: замість редагування низькорівневих конфігів — робота з декларативними описами.

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

Slack, Gmail і щоденний брифінг: як інтеграції змінюють операційні сценарії

Там, де OpenClaw традиційно вимагав окремих інтеграцій і скриптів, Perplexity Computer пропонує готові конектори до популярних сервісів. У демо особливу увагу приділено зв’язці Slack + Gmail, яка перетворює AI‑комп’ютер на операційного асистента.

Сценарій виглядає так:

Perplexity Computer автентифікується в Slack і Gmail;

користувач налаштовує щоденний брифінг вхідних листів на 9:00 за бангкокським часом;

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

формує стислий огляд у Slack;

пропонує чернетки відповідей на ключові листи.

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

У контексті OpenClaw подібний сценарій теоретично можливий, але на практиці вимагав би:

налаштувати доступ до Gmail API;

написати логіку тріажу листів;

інтегруватися зі Slack через бот або вебхуки;

забезпечити безпечне зберігання токенів і доступів;

підтримувати все це в актуальному стані.

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

Автодеплой як нова норма: чому миттєві URL важливіші за «ідеальний» сервер

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

У випадку з OpenClaw типовий процес виглядає так:

агент генерує код;

розробник запускає його на VPS;

налаштовує доступ (локальний тунель, проксі, домен, SSL);

вирішує, чи варто відкривати сервіс у публічний інтернет.

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

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

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

Коли спонсорство не скасовує висновків: роль Perplexity Computer у створенні самого огляду

Важливий нюанс цього кейсу — прозорість щодо спонсорства. Tech With Tim прямо говорить, що відео створене у партнерстві з Perplexity, а компанія надала йому додаткові кредити Computer понад стандартні 10 000, які входять у Max‑план.

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

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

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

Висновок: менше DevOps, більше продукту

Історія переходу від OpenClaw до Perplexity Computer — це не лише про конкретні сервіси. Вона відображає ширшу тенденцію в AI‑інструментах: від «зроби собі фреймворк» до «отримай готовий робочий простір».

OpenClaw залишається потужним вибором для тих, хто хоче повного контролю над інфраструктурою, моделями й безпекою. Але для багатьох розробників і команд, які хочуть швидко отримувати робочі дашборди, веб‑звіти, інтеграції зі Slack і Gmail без занурення в DevOps, аргументи на користь Perplexity Computer виглядають переконливо:

він робить усе те саме, що раніше вимагало локального сетапу й VPS, але без конфігурації;

перетворює один промпт на готовий, задеплоєний продукт за лічені хвилини;

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

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

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

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

Джерело

YouTube: I Replaced OpenClaw With Perplexity Computer…

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

Що таке кешування промптів і чому воно важливе

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

Кешування промптів дає два ключові ефекти:

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

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

Глобальна змінна disable_prompt_caching: маленький прапорець, велика проблема

У проєктах Claude Code може використовуватися глобальна змінна disable_prompt_caching. Її значення напряму впливає на те, чи працює кешування промптів:

• disable_prompt_caching = 1 — кешування вимкнено.
• disable_prompt_caching = 0 або відсутність змінної — кешування увімкнено (поведінка за замовчуванням).

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

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

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

Як перевірити налаштування і що робити

Щоб уникнути зайвих витрат, варто включити перевірку disable_prompt_caching у стандартний чекліст налаштувань проєкту.

Рекомендований підхід:

1. Переглянути конфігурацію проєкту
   Переконатися, що глобальна змінна disable_prompt_caching:
2. або взагалі відсутня,

3. або явно має значення 0.

4. Прибрати зайві перевизначення
   Якщо змінна встановлена в 1 і немає поточної потреби в тестуванні без кешу, її варто:

5. або видалити,

6. або змінити значення на 0.

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

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

Чому це критично для економії

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

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

Тому контроль за disable_prompt_caching — це не дрібна технічна деталь, а базовий елемент економії в роботі з Claude Code.

Source

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

У 2026 році роль продакт-менеджера змінюється не лише всередині продуктових команд. Продакт-мислення, орієнтація на експерименти та «builder»-навички починають переформатовувати інші функції компаній — від HR до внутрішніх операцій. На це звертає увагу Нікхіл Сінгал, колишній топменеджер Meta, Google і CPO Credit Karma, засновник спільноти для керівників продукту Skip. Спираючись на свій досвід роботи з сотнями CPO та Head of Product, він описує, як AI та продакт-підхід стають новим стандартом лідерства в організаціях.

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

Вибух попиту на продакт-лідерів: що показує Skip community

Один із найпомітніших індикаторів зсуву — динаміка самої спільноти Skip, яку веде Сінгал. Ще близько року тому це була відносно компактна група: приблизно 60–70 учасників і лише один фаундер серед них. За останні 12 місяців картина різко змінилася: зараз у спільноті вже близько 125 людей, і серед них — 14 засновників компаній.

Це не просто зростання «клубу за інтересами». Це сигнал про те, що попит на сеньйорних продакт-лідерів — Head of Product, VP Product, CPO — не просто зберігається, а трансформується. Все більше людей із продакт-бекграундом переходять у ролі фаундерів, CEO або керівників інших функцій. Продакт-досвід стає валютою, яка конвертується в ширший спектр лідерських позицій.

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

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

Коли HR мислить як продакт: чому компанії ставлять CPO на роль CHRO

Один із найяскравіших маркерів зміни епохи — новий тип призначень у HR. Деякі компанії вже почали наймати Chief Human Resources Officer (CHRO) з продакт-менеджерським бекграундом. Мета — привнести в HR те, що традиційно асоціюється з сильними продакт-лідерами: judgment, builder-майндсет і вміння працювати з системами, а не лише з процесами.

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

По-перше, HR перестає бути суто сервісною функцією, яка обслуговує запити бізнесу. В епоху AI, масових скорочень і одночасного агресивного найму «AI-first» спеціалістів HR перетворюється на продукт: із користувачами (кандидати, менеджери, співробітники), метриками (time-to-hire, retention, engagement), гіпотезами й експериментами.

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

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

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

Внутрішні AI-агенти: як продакт-лідери автоматизують власну роботу

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

На регулярних зустрічах Skip у Сан-Франциско, де збираються близько 125 Head of Product, дедалі більше учасників демонструють не зовнішні продукти, а те, що вони створюють «для себе» й своїх команд. Це внутрішні системи, які беруть на себе те, що ще кілька років тому вважалося невід’ємною частиною роботи продакт-менеджера.

Насамперед ідеться про автоматизацію трьох ключових ритуалів:

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

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

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

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

Коли CPO автоматизує себе: повністю AI-ведені рев’ю та стендапи

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

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

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

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

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

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

Водночас це створює й нові вимоги. Щоб повністю автоматизувати рев’ю та стендапи, CPO має:

розуміти можливості й обмеження AI-моделей;

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

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

Фактично, це вже не просто «використання AI в роботі». Це перебудова самої операційної системи продакт-функції.

AI-first організація: коли продакт-мислення стає загальнокорпоративним стандартом

Усі ці зрушення — від зростання Skip community до появи CHRO з продакт-бекграундом і повної автоматизації продуктових ритуалів — складаються в цілісну картину AI-first лідерства.

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

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

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

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

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

Висновок: продакт-лідери як архітектори нової корпоративної ОС

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

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

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

Джерело

YouTube: Why half of product managers are in trouble | Nikhyl Singhal (Meta, Google)

У 2026 році розмови про штучний інтелект у продуктовому менеджменті вже давно вийшли за межі модних слайдів. Один із тих, хто бачить цю трансформацію зсередини, — Нікхіл Сінгал, колишній продуктовий керівник Meta, Google та Credit Karma, засновник спільноти The Skip для CPO та голів продукту. Спираючись на десятиліття роботи з масштабними споживчими продуктами та щоденний контакт із сотнями продуктових лідерів, він описує найближчі два роки як момент, коли зміниться не лише ринок праці, а й сама природа продуктової роботи.

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

AI як «облітератор» рутини: що саме стане зайвим

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

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

AI-агенти зможуть самостійно збирати дані з аналітики, сапорту, досліджень, логів та CRM, агрегувати їх, будувати гіпотези й пропонувати варіанти змін у продукті.

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

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

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

Вибух змін: коли AI робить кожен експеримент дешевим

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

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

AI-агенти можуть:

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

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

автоматично запускати A/B-тести, відслідковувати метрики, знімати результати й формувати рекомендації.

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

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

«Судження» як нова суперсила продакт-лідера

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

Під «judgment» він має на увазі кілька взаємопов’язаних речей.

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

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

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

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

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

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

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

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

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

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

знайти й виправити критичні баги можна за години, а не тижні;

переписати незручний інтерфейс, спираючись на реальні патерни поведінки користувачів, — справа днів;

оптимізувати продуктивність, безпеку, доступність — завдання, яке AI може виконувати постійно у фоновому режимі,

— стає дедалі важче виправдовувати існування відверто слабких продуктів.

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

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

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

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

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

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

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

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

Новий контракт для продакт-лідерів

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

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

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

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

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

Висновок: коли AI знімає обмеження, людина стає вузьким місцем

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

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

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

Джерело

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

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

Проблема: нова фіча — нове вікно, нова сесія

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

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

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

Рішення: субагенти як «внутрішні» сесії

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

Ключові риси субагентів:

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

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

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

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

Чому це економить токени і зменшує «тупняк»

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

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

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

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

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

Коли варто переходити на субагентів

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

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

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

Джерело

Як економити в Claude Code – Метод 11 — KODARIK

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

Суть «правила Титаніка»

«Титанік» триває приблизно три години — саме це й стає мірилом прийнятної затримки відповіді. Логіка така:

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

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

Чому погана відповідь = поганий працівник

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

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

Фактично, «правило Титаніка» перетворює швидкість реакції на чіткий критерій професійної придатності.

Як відрізнити нормальну затримку від токсичної тиші

У цьому підході важлива не стільки швидкість, скільки прозорість. Є два принципово різні сценарії:

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

• Неприйнятна поведінка:
  Повна відсутність будь-якого сигналу понад три години в денний час, без попередження й без спроби позначити, коли буде відповідь.

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

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

«Правило Титаніка» можна розглядати як жорсткий, але дуже конкретний стандарт:

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

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

Джерело

The Titanic Rule Every Leader Should Follow — 20VC with Harry Stebbings

Ринок продакт-менеджменту входить у найстресовіший, але водночас найцікавіший період за всю свою історію. Про це говорить Нікхіл Сінгал — колишній продукт-лідер Meta, Google та Credit Karma, серійний засновник і засновник спільноти The Skip для senior-продактів. Спираючись на десятки років досвіду та постійний діалог із керівниками продукту по всьому світу, він описує різкий розлом усередині професії: між тими, хто «рухає інформацію», і тими, хто реально будує продукти.

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

Як продакт-менеджери перетворилися на «перекладачів» між рівнями оргструктури

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

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

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

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

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

Ренесанс для білдерів: чому будувати знову стало цікаво

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

Кілька факторів змінили гру.

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

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

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

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

«Information movers» як зникаючий вид

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

За його оцінкою, приблизно половина нинішніх продакт-менеджерів — це саме ті самі «information movers». Люди, чия щоденна робота історично полягала в тому, щоб:

перекладати цілі керівництва в задачі для команд,

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

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

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

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

«Білдери wanted»: кого насправді шукають компанії

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

Він описує майбутні 12–24 місяці як період «масового скидання» й одночасного «масового найму». За його прогнозом, окремі компанії можуть скоротити, умовно, 30 тисяч людей і при цьому найняти 8 тисяч нових. Ключова відмінність цих 8 тисяч — вони всі будуть «AI-first» і, по суті, білдерами.

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

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

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

«Якщо ви не любите будувати — ви в біді»: новий відбір у професії

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

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

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

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

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

Два роки «вогню в животі»: чому темп стає критичним

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

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

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

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

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

Чому попри хаос білдери «мають час свого життя»

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

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

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

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

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

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

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

Висновок: професія роздвоюється — і вибір доведеться зробити кожному

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

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

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

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

Джерело

Why half of product managers are in trouble | Nikhyl Singhal (Meta, Google)

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

Хмарний «AI‑комп’ютер» без налаштувань: що саме пропонує Perplexity

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

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

Замість цього система працює як керований сервіс: достатньо мати активну підписку, відкрити вкладку Computer в застосунку Perplexity, ввести завдання — і сервіс сам обирає моделі, навички (skills), стратегію виконання та спосіб розгортання результату. У демонстраціях це виглядає як повністю готові веб‑додатки, які можна одразу відкрити в браузері та передати колегам посиланням.

Важливий нюанс: Perplexity Computer не обмежується лише генерацією тексту. Сервіс уміє писати код, досліджувати веб, використовувати вбудовані навички для досліджень, фінансового аналізу чи побудови сайтів, а також створювати нові кастомні skills через спеціальну можливість «create skill», яка видає markdown‑визначення навички. Усе це працює без ручного підключення окремих API чи інструментів.

Модель оркестрації: як Perplexity автоматично керує різними AI‑моделями

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

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

Perplexity Computer забирає цей шар складності на себе. Сервіс може звертатися до різних frontier‑моделей, включно з Grok та Gemini, не вимагаючи від користувача жодного ручного вибору. Якщо для частини завдання краще підходить одна модель, а для іншої — інша, оркестратор розподіляє роботу автоматично. У фінансовому дашборді, наприклад, у телеметрії завдання видно, що для певного етапу використовувалася модель Opus 4.6 — це рішення прийняла сама система.

Такий підхід змінює саму логіку взаємодії з AI‑інфраструктурою. Замість того, щоб думати категоріями «яку модель обрати» і «як її підключити», користувач формулює бізнес‑завдання: дослідити конкурентів, зібрати фінансові дані, побудувати інтерактивний звіт. Вибір моделей, їх комбінація, паралелізація та повторні спроби (self‑healing) стають внутрішньою справою Perplexity Computer.

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

Ізольоване середовище як керований VPS, який неможливо зламати конфігурацією

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

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

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

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

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

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

На відміну від більшості AI‑платформ, де користувачі платять за кожен токен або окремий виклик API, Perplexity Computer працює за моделлю кредитів. Доступ до функції наразі прив’язаний до тарифу Max, який коштує 200 доларів на місяць. У межах цієї підписки користувач отримує 10 000 кредитів Perplexity Computer за замовчуванням.

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

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

Важливо, що на момент запуску доступ до Perplexity Computer обмежений саме планом Max. Компанія планує розширити доступ і на інші тарифи — Pro та Enterprise, але наразі користувачам, які хочуть протестувати функцію, доводиться оформлювати найдорожчу підписку. Для корпоративних клієнтів це може бути прийнятним порогом входу, тоді як для індивідуальних розробників і невеликих команд питання ціни залишається суттєвим фактором.

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

Прозора телеметрія: як подивитися, що саме зробив AI‑«комп’ютер»

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

У вікні завдання можна побачити:

• які субагенти запускалися й скільки їх було;
• які навички (skills) використовувалися — наприклад, research assistant, finance and markets, website building;
• які моделі були задіяні на різних етапах, включно з конкретними версіями, як‑от Opus 4.6;
• скільки часу тривало виконання завдання.

У випадку з конкурентним аналізом Perplexity Computer не лише згенерував веб‑додаток, а й показав, що на це пішло близько 8 хвилин 25 секунд. У фінансовому дашборді, де аналізувалися Nvidia, Microsoft і Anthropic, завдання тривало приблизно 12 хвилин. У телеметрії видно, як система паралельно збирала фінансові дані, аналізувала новини, будувала графіки й формувала аналітичні блоки з bull‑ і bear‑сценаріями.

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

Окремо варто відзначити роботу зі skills. Perplexity Computer має набір вбудованих навичок, серед яких дослідницький асистент, інструменти для фінансів і ринків, а також конструктор сайтів. Користувач може створювати власні навички через вбудовану можливість «create skill», яка генерує markdown‑опис. Це дозволяє формалізувати повторювані сценарії роботи й перетворити їх на окремі модулі, які система зможе викликати як інструменти.

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

Від презентацій до дашбордів: що показують реальні сценарії

Хоча головний фокус Perplexity Computer — інфраструктура й оркестрація, показові саме конкретні сценарії, які демонструють, що означає «AI‑комп’ютер» на практиці.

Один із таких прикладів — створення конкурентного аналізу AI‑агент‑інструментів. Користувач сформулював завдання: дослідити п’ять популярних рішень, зібрати дані про ціни, позиціонування, сильні й слабкі сторони, а потім оформити це як інтерактивний веб‑звіт для керівництва. Perplexity Computer:

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

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

Другий показовий сценарій — фінансовий дашборд для «AI Titans» Nvidia, Microsoft і Anthropic. Завдання включало збір останніх новин, аналіз аналітичних оцінок, витяг фінансових показників і побудову інтерактивної панелі. У результаті Perplexity Computer:

• зібрав дані про поточні ціни акцій Nvidia та Microsoft;
• побудував порівняльні графіки виручки за кварталами;
• окремо обробив Anthropic як приватну компанію, показавши радше траєкторію, ніж біржові метрики;
• сформував блоки з аналітичним sentiment‑аналізом (bull case, bear case);
• додав стрічку останніх новин із датами й ключовими подіями;
• згенерував повноцінний веб‑інтерфейс із інтерактивними елементами.

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

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

Висновки: новий рівень абстракції для роботи з AI‑інфраструктурою

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

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

Водночас поріг входу залишається відчутним: наразі доступ до Perplexity Computer прив’язаний до плану Max за 200 доларів на місяць. Компанія планує розширити доступ на Pro й Enterprise‑тарифи, але на старті це рішення радше для тих, хто готовий платити за зручність і зняття інфраструктурних турбот.

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

Джерело

YouTube: I Replaced OpenClaw With Perplexity Computer…