Інструменти на кшталт 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…

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

Що таке команда BTW і навіщо вона потрібна

Команда BTW (скорочення від by the way) дозволяє поставити агенту додаткове запитання, яке:

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

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

BTW дає змогу цього уникнути.

Як працює BTW на практиці

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

1. Користувач задає основне завдання агенту Claude Code.
   Наприклад: «Створи лендінг для продажу годинників».

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

3. Замість звичайного повідомлення використовується спеціальний формат:
   text
BTW <пробіл> ваше запитання
   Наприклад:
   text
BTW яка година

4. Агент паралельно:

5. продовжує працювати над основним завданням (створенням лендінгу);
6. відповідає на запит, позначений BTW.

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

Чому це економить токени

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

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

Команда BTW вирішує цю проблему:

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

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

• підтримувати «чистий» робочий контекст;
• ставити додаткові запитання без страху «роздути» сесію;
• оптимізувати витрати на використання Claude Code.

Коли варто використовувати BTW

Команда BTW доречна, коли:

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

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

Джерело

YouTube: Як економити в Claude Code – Метод 12

У 2026 році продакт-менеджмент одночасно переживає найстресовіший і, можливо, найкращий період за всю свою історію. Про це говорить Нікхіл Сінгал — колишній топ-продакт Meta, Google та Credit Karma, серійний фаундер і засновник спільнот Skip та Skip Coach для керівників продукту й техфахівців. У розмові на подкасті Lenny’s Podcast він описує найближчі 12–24 місяці як час «масового скидання баласту» в індустрії: компанії звільнятимуть десятки тисяч людей, паралельно наймаючи нову хвилю AI‑first талантів — і саме це, на його думку, запускає справжній ренесанс продакт-менеджменту.

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

Від «перекладачів інформації» до будівничих: як змінилася суть продакт-ролі

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

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

Сьогодні ситуація різко інша. Інструменти на кшталт великих мовних моделей, код-асистентів і no‑code/low‑code платформ дозволяють продактам напряму втілювати ідеї, тестувати гіпотези й бачити результат без багатотижневих циклів узгоджень. З’явився прямий зв’язок між продакт-інстинктами й впливом на продукт.

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

• компенсації для топових «білдерів» — на історичних максимумах;
• кількість оферів для них — рекордна;
• кар’єрні траєкторії виходять далеко за межі класичного продакт-шляху: від фаундерства до ролей CEO чи інших C‑level позицій.

Але цей ренесанс має високу ціну — і вона стосується не лише навичок, а й структури всієї індустрії.

Як нульові ставки зламали баланс «люди проти результату» — і чому рахунок виставлять саме зараз

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

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

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

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

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

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

30 000 проти 8 000: як виглядатиме хвиля скорочень і AI‑найму

На тлі цієї переоцінки Сінгал малює доволі конкретний сценарій: упродовж наступних 12–24 місяців окремі великі гравці можуть звільняти десятки тисяч людей і паралельно наймати нову хвилю спеціалістів.

Він наводить орієнтир: компанія може «скинути» близько 30 000 співробітників і водночас найняти приблизно 8 000 нових. Ключова деталь — усі ці 8 000 будуть AI‑first.

AI‑first у цьому контексті — не модний ярлик, а принципова характеристика:

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

Це означає кілька речей для ринку праці.

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

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

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

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

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

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

Є кілька шарів цієї напруги.

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

те, що ще вчора було стандартом (наприклад, класичні PRD), сьогодні вже можуть вважати анахронізмом.

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

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

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

«Будівничі матимуть час свого життя»: хто виграє в новій хвилі найму

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

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

Для продакт-менеджерів це означає, що:

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

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

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

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

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

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

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

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

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

Цей період він описує як одночасно хаотичний і формотворчий. Саме в найближчі 12–24 місяці закладатимуться нові стандарти продакт-роботи, нові кар’єрні траєкторії й нові очікування від ролі. Ті, хто зможе адаптуватися в цей час, отримають непропорційно великі дивіденди в наступне десятиліття.

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

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

Це створює парадоксальну картину.

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

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

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

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

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

З іншого — ніколи ще не було настільки високого ризику для тих, чия роль тримається на координації, а не на створенні. Масові скорочення, перегляд headcount після ZIRP-ери, перехід до AI‑first моделей роботи — усе це означає, що «просто бути продактом» більше недостатньо.

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

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

чи хочу я — і чи вмію — будувати в новому світі, де AI не замінює мене, а множить мою продуктивність?

Від відповіді на нього залежить, у якій частині рівняння «мінус 30 000, плюс 8 000» ви опинитеся.

Джерело

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

Фінансова термінологія часто звучить як чужа мова, а розмови про гроші роками вважалися «нескромними». У виступі на TED фінансова освітниця та колишня трейдерка Волл-стріт Вівіан Ту (канал YourRichBFF) пропонує просту, але структуровану відповідь: змінити власне ставлення до фінансів, спільноти й інструментів, якими ми користуємося.

1. Вивчити «мову грошей» і не соромитися питати

Фінанси справді нагадують вивчення нової мови. Скорочення й абревіатури на кшталт 401k, IRA, 529, FICO, APY, AGI для багатьох виглядають як набір випадкових літер. Це створює відчуття, що фінансовий світ — закритий клуб для «посвячених».

Ключова порада — дозволити собі виглядати «недосвідченими», щоб стати обізнаними:

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

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

2. Ламати табу на розмови про гроші й будувати власну фінансову спільноту

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

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

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

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

3. Використовувати сучасні інструменти для сучасних фінансових реалій

Фінансова реальність змінилася радикально порівняно з поколінням батьків:

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

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

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

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

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

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

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

Фінанси перестають бути «іншою мовою», коли:

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

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

Джерело

Finance doesn’t have to feel like a foreign language, says @YourRichBFF #TEDTalks

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

Що таке MCP‑сервери і навіщо вони потрібні

MCP (Model Context Protocol) — це новий стандарт для агентів, який дозволяє підключати зовнішні інструменти до моделі. Через MCP можна інтегрувати, наприклад:

• Figma
• Supabase
• Telegram

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

У Claude Code список MCP‑серверів можна переглянути через команду MCP. У цьому списку видно:

• які сервери встановлені;
• які з них активні;
• які деактивовані.

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

Як MCP‑сервери «з’їдають» контекст і токени

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

На старті кожної сесії в Claude Code в контекст автоматично записуються:

• системний prompt;
• системні інструменти;
• описання MCP‑інструментів (MCP Tools) усіх активних серверів.

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

Це добре видно в команді context. Там відображається:

• максимальний обсяг пам’яті агента в токенах (наприклад, 200 000);
• поточне заповнення (наприклад, 38 000 токенів).

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

Практична порада: вимикайте зайві MCP‑сервери

Ключова рекомендація для економії токенів у Claude Code:

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

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

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

Джерело

https://www.youtube.com/watch?v=5y6ktp-hnFU

Генеративний ШІ вже вийшов далеко за межі «фанових» картинок і чат-ботів для планування відпусток. Тепер ті самі технології — великі мовні моделі (LLM), retrieval‑augmented generation (RAG) та агентний ШІ — починають системно змінювати роботу критично важливої інфраструктури, зокрема мейнфреймів. У новому відео IBM Technology пояснюють, як саме ці підходи підвищують точність, автоматизацію та продуктивність у мейнфреймових і гібридних хмарних середовищах.

Мейнфрейм як невидимий «бекенд» повсякденного життя

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

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

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

На цьому тлі ШІ виглядає природним інструментом для підвищення продуктивності. Але «з коробки» він працює далеко не ідеально.

Чому «чистий» LLM не підходить для мейнфрейм‑операцій

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

Типові проблеми:

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

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

RAG: як зробити відповіді ШІ точнішими та релевантнішими

Retrieval‑augmented generation (RAG) — це підхід, що поєднує можливості LLM з цільовою базою знань. Ідея проста: перед тим як згенерувати відповідь, система спершу «витягує» (retrieval) релевантні документи, а потім використовує їх як основу для генерації.

У мейнфреймових операціях RAG працює як шар «заземлення» для LLM:

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

Результат: коли оператор ставить запитання (наприклад, щодо певного CICS‑повідомлення), система не просто покладається на загальні знання LLM, а звертається до актуальної, спеціалізованої документації. Це підвищує:

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

Агентний ШІ: від порад до автоматизованих дій

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

Що таке агент у цьому контексті

Агент — це програмний компонент, який:

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

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

Які завдання можуть виконувати агенти

У межах мейнфреймових операцій агентний підхід відкриває широкий спектр сценаріїв:

• Автоматизація рутинних процесів:
• відкриття тікетів у сервіс‑деску;
• отримання статусу з моніторингових систем;
• виконання типових операцій з обслуговування.
• Операційні health‑checks:
• регулярні перевірки стану систем;
• виявлення потенційних проблем до того, як вони вплинуть на бізнес.
• Оптимізація продуктивності:
• аналіз навантаження;
• пошук можливостей для ефективнішого розподілу ресурсів;
• рекомендації щодо налаштувань для кращої роботи робочих навантажень.

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

Синергія: LLM + RAG + агенти в операціях мейнфрейма

Найбільша цінність з’являється, коли всі три компоненти працюють разом:

1. Користувач формулює запит природною мовою.
   Наприклад: «Перевір стан ключових сервісів і підкажи, чи є проблеми з продуктивністю».

2. LLM інтерпретує запит.
   Модель розуміє намір користувача й формує план дій.

3. RAG підтягує релевантні знання.
   Система звертається до внутрішньої документації, best practices та специфічних інструкцій організації, щоб забезпечити коректний контекст.

4. Агенти виконують дії та повертають «живі» дані.
   Вони можуть:

5. зібрати поточні метрики;
6. зробити health‑check;

7. ініціювати тікети або інші процеси.

8. Користувач отримує відповідь, що поєднує:

9. перевірену, задокументовану інформацію;
10. актуальні дані з систем;
11. конкретні кроки або вже виконані дії.

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

Навіщо це все: продуктивність і довіра

У підсумку роль ШІ в мейнфреймових операціях зводиться до кількох ключових цілей:

• Підвищення продуктивності.
  Швидші відповіді, менше ручної роботи, швидший перехід від проблеми до рішення.

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

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

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

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

Джерело

How AI, RAG, and Agents Transform Mainframe Operations — IBM Technology

Сучасні генеративні моделі часто сприймають як «чарівну скриньку», яку треба лише правильно запитати. Однак, як показує пояснення від автора каналу Jeff Su, якість відповіді значно більше залежить не від ідеального формулювання запиту, а від того, яку інформацію й у якому вигляді отримує модель. Ключові поняття тут — grounding, RAG та контекстна інженерія.

Grounding: коли AI спирається на реальні дані

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

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

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

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

RAG (Retrieval Augmented Generation) — це підхід, за якого модель спочатку шукає релевантні джерела, а вже потім генерує відповідь. Умовно: студент пише есе. Без RAG він пише все з голови. З RAG — спершу йде в бібліотеку, добирає потрібні книжки, а потім пише текст, спираючись на них.

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

RAG особливо корисний, коли:

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

Контекстна інженерія проти «ідеального промпта»

Популярна порада «вчися писати кращі промпти» часто зводиться до гри з формулюваннями: змінити тон, додати роль («ти — експерт…»), уточнити завдання. Це й є класична prompt engineering: зібрати в одному запиті завдання, контекст і тон.

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

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

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

Як змінити підхід до роботи з AI

З урахуванням grounding, RAG та контекстної інженерії, стратегія роботи з генеративними моделями виглядає так:

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

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

Source

YouTube: Stop perfecting your prompt. Do this instead

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

Від технічного боргу до боргу «невідомості»

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

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

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

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

Як народжується AI-борг: швидкий успіх, повна непрозорість

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

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

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

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

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

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

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

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

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

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

Як працювати з AI і не потонути в боргу

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

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

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

Джерело

YouTube: Do you have this DEBT? — Tech With Tim