Ринок AI‑асистентів стрімко рухається від «розумних чатів» до повноцінних агентів, які можуть працювати з реальними сервісами — від Gmail і Google Drive до Salesforce, Slack чи Figma. У новому туторіалі на каналі Tech With Tim демонструється практичний сценарій: як за допомогою платформи Composio підключити Claude Co-Work до десятків і навіть сотень зовнішніх застосунків, налаштувати безпечний доступ і навчити модель ланцюжити дії між різними інструментами.

Цей матеріал розбирає саме практичний бік: як працює on‑demand discovery інструментів у Composio, як відбувається інтеграція з Claude, як виглядає реальний сценарій з Gmail і Google Drive, що відбувається з безпекою, логами та тарифами — і чому все це критично для тих, хто хоче будувати на базі LLM не просто чат, а робочий інструмент.

On‑demand discovery: як не «вбити» модель сотнями інструментів

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

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

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

Composio пропонує іншу архітектуру — on‑demand tool discovery. Замість того, щоб одразу показувати моделі сотні конкретних інструментів, платформа спочатку відкриває для Claude лише один або кілька мета‑інструментів. Ключовий серед них — функція пошуку інструментів.

Сценарій виглядає так. Користувач формулює запит, наприклад: «Надішли команді підсумковий лист про сьогоднішній стендап». Claude, замість того щоб гортати список з сотень дій, спершу викликає єдину функцію search tools, яку надає Composio. Далі вже Composio, використовуючи власну семантичну пошукову систему, підбирає невеликий, цільовий список інструментів, які відповідають запиту: скажімо, «Gmail: надіслати лист», «Slack: надіслати повідомлення в канал» тощо.

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

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

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

Єдиний шар інтеграцій: як працює дашборд і автентифікація

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

Після реєстрації користувач потрапляє в інтерфейс, де можна переглядати доступні інтеграції — від Instagram, YouTube, Slack, Reddit, Monday і Twitter до Salesforce, HubSpot, Gmail, Google Drive, LinkedIn, DocuSign та десятків інших. Заявлено підтримку до приблизно тисячі різних застосунків, і пошук по каталогу відкритий безкоштовно.

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

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

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

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

Ключовий момент: усі ці налаштування виконуються один раз у Composio, після чого їх можна використовувати з різними AI‑платформами — Claude, Codeex, Gemini та іншими. Замість того щоб підключати Gmail, Slack чи HubSpot окремо в кожному інструменті, користувач просто вказує їм один і той самий MCP‑конектор Composio, який уже містить усю конфігурацію.

Інтеграція з Claude Co‑Work: один конектор, кілька мета‑інструментів

З технічного погляду підключення Composio до Claude Co‑Work виглядає досить просто, але важливо розуміти, що саме відбувається «під капотом».

У налаштуваннях Claude Co‑Work є розділ Connectors, де можна додати власний MCP‑конектор. Composio надає спеціальний URL, який потрібно вставити в поле «Custom connector». Користувач задає назву, наприклад «Composio», вставляє URL і натискає «Add».

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

У налаштуваннях конектора в Claude можна побачити, що насправді відкрито лише невеликий набір інструментів. Це, зокрема, manage connections, multi‑execute tool, remote bash tool, remote workbench, wafer connection, search tool і get tool schemas. Саме ці мета‑інструменти й потрібні, щоб керувати всією екосистемою інтеграцій, не розкриваючи моделі сотні конкретних дій.

Окремо налаштовуються дозволи. Claude дозволяє вказати, які дії можна виконувати завжди, а які — лише з підтвердженням користувача. У прикладі read‑only операції (наприклад, читання листів) позначаються як «always allow», тоді як дії запису чи видалення (надсилання листів, зміна файлів, видалення об’єктів) вимагають явного схвалення. Це створює додатковий рівень безпеки: агент може вільно досліджувати доступні інструменти, але не зможе змінювати дані без участі людини.

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

Практика: від Gmail до Google Docs і Drive в одному ланцюжку

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

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

Далі починається типовий для Composio процес. Claude викликає search tools, щоб знайти інструменти, пов’язані з Gmail. Composio повертає список, де, зокрема, є функція на кшталт «Gmail: fetch emails». Claude обирає її, викликає з параметрами «останні три листи у вхідних», отримує обрізаний результат і на його основі формує текстовий підсумок для користувача.

На цьому ланцюжок не закінчується. У тому ж середовищі можна продовжити завдання: попросити агента створити Google Doc з цим підсумком, зберегти його на Google Drive і повернути посилання. Для цього в Composio мають бути підключені Google Docs і Google Drive, але з погляду Claude це все ще той самий конектор Composio.

Модель знову звертається до search tools, цього разу шукаючи інструменти для створення документа і збереження файлу на диску. Composio повертає відповідні функції, Claude викликає їх у потрібній послідовності, а користувач на виході отримує не лише текстовий підсумок листів, а й посилання на документ у Google Drive, створений автоматично.

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

Логи, SDK і тарифи: що відбувається за лаштунками

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

Окремо згадується SDK для побудови й керування AI‑агентами поверх Composio. Деталі його використання залишаються за межами конкретного туторіалу, але сам факт наявності SDK означає, що платформу можна інтегрувати не лише з готовими інтерфейсами на кшталт Claude Co‑Work, а й із власними застосунками, де LLM виступає як бекенд‑агент, що керує зовнішніми сервісами через Composio.

Фінансовий бік виглядає досить помірковано. Є безкоштовний тариф із лімітом у 20 000 викликів інструментів на місяць. Автор туторіалу зазначає, що, попри активне використання Composio в кількох акаунтах, йому жодного разу не вдалося перевищити цей ліміт. Для більш інтенсивних сценаріїв передбачений платний план за 29 доларів на місяць із 200 000 викликів, а також вищий рівень із 2 мільйонами викликів на місяць і окремими enterprise‑опціями.

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

Висновок: інфраструктура для агентів, а не ще один конектор

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

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

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

Джерело

Connect Claude to ANY Tool | Full Tutorial

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

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

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

Чому варто перестати друкувати й почати говорити з AI

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

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

Голосовий промпт дозволяє:

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

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

Whisper Flow як міст між мовами

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

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

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

Trent: як перетворити живу мову на контент

Другий елемент голосового контуру — Trent. Якщо Whisper Flow допомагає краще промптити AI, то Trent працює з довгими аудіо‑форматами: подкастами, виступами на конференціях, записами з годинника.

Сценарій виглядає так: під час подкасту або виступу авторка вмикає запис, а потім проганяє аудіо через Trent, який допомагає перетворити сказане на готовий пост для LinkedIn чи інший соціальний канал. Те, що раніше вимагало ручної транскрипції, відбору цитат і редагування, тепер стає напівавтоматичним процесом.

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

Анти‑AI файл: як не перетворити контент на безликий текст моделі

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

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

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

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

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

Від хмари до десктопа: як Claude Projects і Co‑Work змінюють роль агента

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

Claude Projects у браузері: глибоке розуміння без дій

У браузерній версії Claude Projects користувач створює окремі проєкти під конкретні задачі або канали. Наприклад, для LinkedIn можна завантажити:

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

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

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

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

Claude Co‑Work: структура папок як інструкція для агента

Щоб перетворити Claude з радника на учасника продакшн‑процесу, команда тестує десктопний застосунок Claude Co‑Work разом із YouTube‑відділом. Тут ключову роль відіграє не стільки сам AI, скільки структура файлів і інструкцій.

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

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

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

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

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

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

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

По суті, Claude Co‑Work перетворює файлову структуру компанії на інтерфейс для агента. Не людина щоразу формулює повний контекст, а агент сам його читає з папок і файлів, які команда підтримує в актуальному стані.

Higgsfield MCP: коли Claude отримує «руки» для повного продакшну

Якщо голосові промпти й десктопні агенти допомагають краще думати й структурувати роботу, то MCP‑конектор Higgsfield додає ще одну якість — здатність AI не лише генерувати текст, а й одразу створювати готові креативи у файловій системі.

Підключення за 30 секунд і повний цикл за чотири хвилини

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

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

Показовий тестовий кейс виглядав так. Моделі дали посилання на останні п’ять випусків розсилки й один промпт: знайти найсильніший хук і перетворити його на три відео‑акти. Далі Claude:

• прочитав усі п’ять постів;
• обрав той, де хук найсильніший;
• написав три сценарії;
• через Higgsfield MCP згенерував три 15‑секундні відео;
• зберіг їх у вихідну папку.

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

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

Доступ до GPT Image 2 і Sense 2.0

Ще одна деталь, яка важлива для якості візуального контенту: саме через Higgsfield Claude отримує агентний доступ до моделей GPT Image 2 і Sense 2.0. Це наразі єдине місце, де така зв’язка доступна в агентному режимі.

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

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

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

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

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

Комбінація голосових промптів, транскрипційних сервісів на кшталт Whisper Flow і Trent, структурованих проєктів у Claude, десктопного агента Claude Co‑Work і MCP‑конектора Higgsfield показує, як із цих дрібниць складається цілісний контур. У ньому:

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

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

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

Джерело

Build a Self-Running AI Company in 16 Minutes (Move 75% Faster)

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

Цей текст — про те, як «гігабітні дата‑центри» стають інструментом спекуляції на землі в США, чому український 4G раптом виявився швидшим за дротовий інтернет, як Київ роками не мав мобільного зв’язку в метро, а європейські містечка живуть на 5G замість оптики. І головне — чому будь‑які гучні історії про інфраструктуру варто пропускати через фільтр скепсису.

Дата‑центр як привід: як працює земельна спекуляція в американських містечках

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

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

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

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

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

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

4G проти DSL: як Україна раптово «перестрибнула» дротовий інтернет

На іншому полюсі — історія українського мобільного інтернету. Запуск 4G в Україні став тим рідкісним випадком, коли нова технологія не просто додала зручності, а реально переграла існуючу дротову інфраструктуру.

Ведучі згадують, що після запуску 4G швидкість мобільного інтернету в багатьох випадках виявилася вищою, ніж у застарілого DSL від «Укртелекому». Для тих, хто роками сидів на мідних парах із теоретичними «до 20 Мбіт/с», які в реальності часто перетворювалися на кілька мегабіт, це було відчутним стрибком.

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

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

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

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

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

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

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

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

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

Європейські містечка без оптики: коли 5G стає не доповненням, а основою

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

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

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

Це ще один приклад того, як маркетинговий образ («Європа з гігабітною оптикою») розходиться з реальністю на рівні конкретних населених пунктів. Так, у великих містах дійсно є розгалужені FTTH‑мережі, конкуренція провайдерів, акції й пакети. Але варто від’їхати вбік — і виявляється, що «цифрова Європа» тримається на кількох вежах 5G, які одночасно обслуговують і смартфони, і домашні роутери.

Цей контраст важливий не лише для того, щоб «зняти рожеві окуляри» щодо ЄС. Він показує, що навіть у розвинених країнах інфраструктура розподілена дуже нерівномірно. І коли хтось говорить про «суцільний 5G» як про досягнуту реальність, варто запитати: де саме, у яких містах, на яких вулицях?

Чому «гігабітні дата‑центри» й «суцільний 5G» треба фільтрувати

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

Коли інвестор у США піднімає шум про «гігабітний дата‑центр», його мета може бути не в тому, щоб побудувати об’єкт, а в тому, щоб створити інформаційний тиск і продати землю дорожче. Коли оператори говорять про «суцільний 5G», це може означати лише те, що на карті покриття немає «білих плям», але якість сервісу в конкретних місцях далека від рекламних цифр. Коли провайдери звітують про «широкосмуговий доступ», це може бути старий DSL, який програє мобільному 4G.

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

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

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

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

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

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

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

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

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

Джерело

Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28

Українське техношоу «УТ‑2» у свіжому випуску розбирає одну з найгучніших історій безпеки JavaScript‑світу останніх місяців: компрометацію екосистеми TanStack, коли зловмисник зумів підмінити понад 80 npm‑пакетів через маніпуляцію кешем у GitHub Actions. На перший погляд це ще один «supply chain» інцидент, але деталі роблять його показовим кейсом про те, наскільки крихкою стала сучасна культура JavaScript‑залежностей і CI‑інфраструктури.

Злам ланцюжка постачання TanStack: не код, а кеш

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

Ключовий момент: зловмисник не починав із класичного зламу репозиторію з кодом. Поворотним кроком стало викрадення npm‑токена з правами запису в репозиторій. Маючи цей токен, атакувальник отримав можливість впливати не лише на публікацію пакетів, а й на те, як працює CI‑процес, зокрема кешування залежностей у GitHub Actions.

Саме через цей вектор і відбулася підміна понад 80 npm‑пакетів TanStack. Замість того, щоб безпосередньо змінювати вихідний код у репозиторії, зловмисник отруїв кеш pnpm, який використовувався в GitHub Actions. У результаті CI‑система збирала й публікувала пакети, що містили шкідливий код, навіть якщо сам репозиторій виглядав «чистим» для огляду.

Це важливий зсув у розумінні supply chain‑ризиків. Раніше основна увага була на захисті вихідного коду, прав доступу до репозиторію, рев’ю pull‑реквестів. Інцидент із TanStack показує, що CI‑інфраструктура, кеші та токени публікації стають не менш критичними елементами ланцюжка довіри.

Отруєний кеш pnpm: як CI сам собі підклав вірус

Механіка атаки обертається навколо однієї з найпопулярніших практик оптимізації CI — агресивного кешування залежностей. У JavaScript‑проєктах це особливо актуально: десятки й сотні дрібних пакетів, які при кожній збірці тягнуть гігабайти даних із реєстру. pnpm, як і інші менеджери пакетів, активно використовує кеш, а GitHub Actions дозволяє зберігати його між запусками workflow.

У випадку TanStack саме цей кеш став точкою ін’єкції. Маючи npm‑токен із правами запису, зловмисник зміг записувати отруєний кеш pnpm і підсовувати його CI‑процесам. Далі все відбувалося автоматично:

CI запускає збірку пакета.

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

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

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

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

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

Що шукав вірус: від AWS‑ключів до systemd‑персистентності

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

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

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

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

Така поведінка наближає атаку до повноцінного malware‑класу, а не до «разового» supply chain‑інциденту. Вона показує, що зловмисник мислив не категоріями «погратися з npm», а прагнув побудувати стійку інфраструктуру доступу до машин розробників і серверів.

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

Новий клас цілей: AI‑токени, Claude Code, VS Code

Окрема деталь, яка робить атаку на TanStack симптоматичною для 2025–2026 років, — це інтерес зловмисника до інструментів розробки з підтримкою AI. Шкідливий код містив хуки для інструментів на кшталт Claude Code та VS Code і збирав токени доступу до AI‑API.

Це важливий сигнал: токени до AI‑сервісів стають новим класом цінних цілей. Якщо раніше основна увага була на AWS, GCP, Azure, GitHub, GitLab, то тепер у цьому списку з’являються OpenAI, Anthropic, інші провайдери моделей і AI‑IDE.

Причин кілька.

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

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

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

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

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

Культура npm: мікрозалежності, автоматична довіра і «злі» пакетні менеджери

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

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

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

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

Фраза «package managers are evil» у цьому контексті звучить не як буквальне звинувачення, а як констатація: інструменти, покликані спростити життя розробникам, одночасно створили величезну й слабо контрольовану поверхню атаки. І поки екосистема не перегляне свої базові практики, подібні інциденти будуть повторюватися.

Чому JavaScript‑стек вразливіший: порівняння з pip, Rust, Go, Zig

Щоб зрозуміти, наскільки специфічною є ситуація з npm, ведучі порівнюють її з іншими екосистемами — Python (pip, uv), Rust, Go, Zig. У кожної з них є свої проблеми, але JavaScript‑світ виглядає особливо вразливим через поєднання кількох факторів.

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

По‑друге, модель розповсюдження. Go за замовчуванням тягне залежності з їхніх репозиторіїв, Rust використовує crates.io з досить прозорою моделлю, Python‑світ поступово рухається в бік більш контрольованих інструментів на кшталт uv. У JavaScript‑світі npm став де‑факто єдиним центром, через який проходить усе, і будь‑яка компрометація в цьому ланцюжку миттєво б’є по величезній кількості проєктів.

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

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

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

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

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

По‑перше, чи достатньо уваги приділяється захисту токенів? npm‑токен із правами запису виявився ключем до всієї атаки. Це означає, що політика зберігання, ротації й обмеження прав таких токенів має стати пріоритетом. Мінімально необхідні привілеї, окремі токени для CI, жорсткі обмеження на те, де вони можуть використовуватися, — усе це вже не «best practice», а базова гігієна.

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

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

По‑четверте, чи готові ми сприймати AI‑інструменти як повноцінний об’єкт безпеки? Токени до моделей, плагіни IDE, інтеграції з Claude Code чи VS Code — усе це має потрапити в поле зору security‑команд. Інакше наступні атаки будуть націлені не лише на AWS‑ключі, а й на AI‑інфраструктуру компаній.

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

Висновок: час переосмислити довіру в JavaScript‑світі

Компрометація понад 80 npm‑пакетів TanStack через отруєний кеш pnpm у GitHub Actions — це не випадковість і не «дивна аномалія». Це логічний результат того, як побудована сучасна JavaScript‑екосистема: мікрозалежності, автоматичні оновлення, агресивне кешування, широка довіра до сторонніх пакетів і сервісів.

Зловмисник, який викрав npm‑токен із правами запису, зумів використати саму інфраструктуру CI проти її власників. Шкідливий код, що полює за AWS‑креденшалами, SSH‑ключами, AI‑токенами й закріплюється через systemd‑сервіс, показує, наскільки цінними стали машини розробників і наскільки привабливою мішенню є їхній стек інструментів.

Порівняння з іншими екосистемами — від pip і uv до Rust, Go та Zig — лише підкреслює: JavaScript‑світ опинився в особливо вразливій позиції. Вихід із неї потребує не лише патчів і ротації токенів, а й переосмислення самої культури залежностей, кешування й довіри до інструментів.

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

Джерело

Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28

Українське техношоу «УТ‑2» давно перетворилося на майданчик, де новини зі світу штучного інтелекту, венчурного капіталу й податкових схем мільярдерів розбирають без зайвого пафосу. В одному з останніх випусків ведучі обговорюють одразу кілька сюжетів, які добре показують, як сьогодні влаштований великий AI‑ринок: від стартапу Міри Мураті з мільярдними раундами до «неадекватного» зростання виручки Anthropic, угод xAI навколо дата‑центрів і девелоперських інструментів, а також податкових трюків на кшталт трастів Дженсена Хуанга. На цьому тлі особливо контрастно виглядають українські miltech‑компанії, що заробляють реальні гроші, але оцінюються в рази скромніше, ніж їхні американські аналоги.

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

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

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

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

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

Anthropic і «неадекватна швидкість» зростання

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

Anthropic, творці моделі Claude, за кілька років пройшли шлях від нішевого гравця до одного з головних конкурентів OpenAI. Компанія активно продає доступ до своїх моделей через API, інтегрується в корпоративні продукти й отримує великі контракти від хмарних гігантів. Усе це виливається в експоненційне зростання річного доходу, яке й називають «неадекватним».

Ця «неадекватність» насправді є логічним наслідком кількох факторів.

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

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

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

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

xAI між Colossus і Cursor: як Маск купує екосистему навколо моделей

На тлі Anthropic і OpenAI окрему траєкторію вибудовує xAI Ілона Маска. Ведучі згадують одразу дві важливі деталі: домовленість xAI з Anthropic щодо використання дата‑центру Colossus і інвестицію в IDE Cursor із правом подальшого викупу.

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

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

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

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

У сукупності угода з Colossus і інвестиція в Cursor демонструють, що xAI намагається будувати не просто модель, а цілу вертикаль: від «заліза» й дата‑центрів до інструментів, у яких працюють розробники. Це дзеркалить підхід великих хмарних провайдерів, але з акцентом на власні моделі й більш агресивну M&A‑стратегію.

Трасти Дженсена Хуанга: як платити 3–4% податків

На іншому кінці цієї екосистеми — люди, які вже встигли капіталізувати AI‑бум. Ведучі обговорюють податкову стратегію CEO Nvidia Дженсена Хуанга й зазначають, що він використовує шість траст‑фондів, завдяки чому ефективно сплачує лише близько 3–4% податків зі свого багатства.

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

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

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

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

Жити з кредитів під акції: як працює «класична» схема

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

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

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

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

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

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

Український miltech: великі доходи, малі оцінки

На тлі мільярдних раундів Мураті, гіперзростання Anthropic і податкових схем Хуанга ведучі порівнюють ситуацію з українськими miltech‑компаніями. Зокрема згадують UARs та інші бізнеси, які мають високі реальні доходи, але значно нижчі формальні оцінки, ніж подібні компанії у США.

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

Натомість ринок оцінює їх набагато скромніше. Причин кілька.

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

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

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

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

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

Висновок: AI‑ринок між гіперзростанням і асиметрією

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

Над усім цим — фігури на кшталт Дженсена Хуанга, які завдяки трастам і кредитам під акції живуть у податковій реальності з ефективною ставкою 3–4%. Внизу — українські miltech‑компанії, що мають реальні доходи й вплив на хід війни, але залишаються недооціненими в глобальній грі капіталів.

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

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

Джерело

Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28

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

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

Мікросервіс для UUID: коли параноя стає фічею

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

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

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

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

2,7 квінтильйона UUID: де закінчується ризик і починається міфологія

Щоб зрозуміти абсурдність страху перед колізіями UUID, варто подивитися на цифри. Для того, щоб отримати приблизно 50% ймовірності хоча б однієї колізії UUID, потрібно згенерувати порядку 2,7 квінтильйона ідентифікаторів.

Це число важко навіть уявити. Для порівняння, якщо система генерує мільйон UUID на секунду безперервно, 24/7, то для досягнення такого обсягу знадобляться мільйони років. Жоден реальний продукт, жодна бізнес‑система не наблизиться до цих масштабів у межах свого життєвого циклу.

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

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

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

JWT, ревокація і вбивство безстанового бекенду

Інший бік тієї ж проблеми — мода на «правильні» патерни без розуміння, навіщо вони взагалі існують. Один із найяскравіших прикладів — популярні схеми роботи з JWT (JSON Web Token), де кожен запит з токеном перевіряється по базі даних на предмет ревокації.

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

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

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

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

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

Як міфи про ризики народжують абсурдні архітектури

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

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

У результаті з’являється мікросервіс, який:

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

І все це — заради захисту від події, для якої потрібні 2,7 квінтильйона спроб, щоб отримати хоча б 50% шанс колізії. У більшості бізнесів ризик того, що компанія помре від відсутності product‑market fit, зміни ринку чи банального браку грошей, на кілька порядків вищий, ніж ризик колізії UUID. Але саме останній чомусь стає об’єктом інженерної одержимості.

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

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

Парадокс днів народження як анти‑патерн для інженерного мислення

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

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

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

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

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

Чому «заробіток на UUID» — це не бізнес, а втрачені можливості

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

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

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

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

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

Як не проєктувати бекенд: кілька висновків без чек‑лістів

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

Головні уроки тут радше філософські, ніж технічні.

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

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

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

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

Джерело

Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28

Південнокорейський чиповий гігант Samsung Semiconductor опинився в центрі конфлікту, який може стати показовим для всієї глобальної індустрії високих технологій. Профспілка працівників підрозділу вимагає, щоб 15% прибутку компанії розподілялися між співробітниками, і попереджає: якщо вимогу не буде виконано, з 21 травня стартує 18‑денна страйкова акція. На тлі цього порівнюють практики конкурента SK Hynix, який, за оцінками, віддає близько 10% прибутку на бонуси персоналу, а також ширше обговорюють, як узагалі має виглядати «справедлива» модель мотивації в техбізнесі.

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

15% для людей: чому страйк Samsung Semiconductor важливий далеко за межами Кореї

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

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

Ця вимога — 15% прибутку — не взята зі стелі. У дискусії постійно фігурує порівняння з SK Hynix, іншим південнокорейським виробником пам’яті. Там, за оцінками, близько 10% прибутку йде на бонуси співробітникам. Ця цифра стає неформальним «бенчмарком» у суперечці про те, що вважати справедливим розподілом.

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

SK Hynix як орієнтир: коли 10% прибутку стають аргументом у переговорах

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

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

У ширшому контексті це піднімає питання: чи мають техкомпанії фіксувати якусь «норму» розподілу прибутку між акціонерами й працівниками? Чи це завжди предмет торгу, де сильніша сторона диктує умови? Коли профспілка Samsung Semiconductor називає цифру 15%, вона фактично пропонує новий стандарт, вищий за «орієнтир» SK Hynix. І якщо їй вдасться його вибити, це може стати прецедентом для інших гравців галузі.

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

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

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

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

Третій компонент — довгострокові стимули: опціони, RSU (restricted stock units), акції. Вони прив’язують працівника до довгострокового успіху компанії. Якщо бізнес зростає, капіталізація збільшується, вартість цих пакетів може перевищити всі отримані зарплати й бонуси разом узяті. Якщо ж компанія падає, паперове багатство тане.

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

Twitter і «збитки на папері»: як акції співробітників спотворюють картинку

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

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

У випадку Twitter це створювало дивну ситуацію. З одного боку, співробітники отримували значні пакети акцій, що робило їх співвласниками майбутнього успіху компанії. З іншого — публічна звітність демонструвала збитки, що підживлювало наративи про «неприбуткові соцмережі» і «бульбашки». Для інвесторів, які розуміють природу stock-based compensation, це не було сюрпризом. Але для широкої аудиторії — так.

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

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

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

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

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

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

Довгострокова мотивація: чому інженерам потрібні опціони, а не лише премії

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

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

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

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

У цьому сенсі вимога профспілки Samsung Semiconductor про 15% прибутку може бути лише частиною картини. Не менш важливо, яку частку капіталу компанія готова віддати тим, хто будує її технологічну перевагу. І чи будуть ці інструменти доступні не лише топ-менеджменту, а й широкому колу інженерів і науковців.

Між страйком і стратегією: що показує кейс Samsung про майбутнє техкомпенсацій

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

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

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

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

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

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

Джерело

Обговорення базується на розмові у випуску «Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28» на каналі «УТ‑2»:
https://www.youtube.com/watch?v=dzgqFquAcus

Попит на віддалену роботу в ІТ залишається високим, але ринок різко змінився: за останній рік зникла щонайменше третина повністю віддалених технічних вакансій. На цьому тлі поради з пошуку роботи від Senior Applied Scientist Twitch/Amazon Марини Вісс допомагають тверезо подивитися на ситуацію: віддалені позиції ще є, але вони майже не перетинаються з тим, що більшість кандидатів бачить у LinkedIn.

Ринок віддаленої роботи: тренд на згортання

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

Паралельно великі корпорації агресивно повертають людей в офіси:

• Amazon змусила близько 350 тис. працівників повернутися в офіс п’ять днів на тиждень.
• JP Morgan скасувала гібридний формат для понад 300 тис. співробітників.
• Google прив’язала відвідуваність офісу до performance review — від цього залежать бонуси й підвищення.

Дослідження показують, що 42% компаній із жорстким поверненням в офіс зіткнулися з вищою, ніж очікувалось, плинністю кадрів, а 29% — із труднощами найму заміни. Попри це, керівництво все одно проштовхує RTO (return-to-office). Це сигнал: відмова від повної «віддаленки» — свідоме, дороге, топдаун-рішення, а не тимчасова примха. Очікувати швидкого відкату тренду не варто.

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

Чому LinkedIn майже не показує віддалені вакансії

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

Ключова причина — в економіці платформи:

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

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

Де насправді ховаються віддалені технічні ролі

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

Кілька ключових майданчиків і каналів:

Стартап-борди та спільноти

• Wellfound (колишній AngelList)
  Один із найсильніших ресурсів для інженерних і ML-ролей у стартапах. Має прямий фільтр за «remote» і помітно тяжіє до ранніх стадій — саме там найчастіше зустрічаються distributed-first команди.

• Hacker News — «Who’s Hiring»
  На початку кожного місяця на Hacker News виходить тред «Who’s Hiring». Значна частина постів — від розподілених компаній, які прямо в заголовку пишуть «remote». Це прямий канал до технічних команд, минаючи рекрутингові відділи.

• Work at a Startup (Y Combinator)
  Офіційний джоб-борд Y Combinator. Багато YC-компаній із самого старту будуються як розподілені, тому віддалений формат тут часто «за замовчуванням».

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

• Idealist
  Орієнтований на «mission-driven» та «AI for good» проєкти. Оплата часто нижча, зате гнучкість і віддалений формат — значно кращі. Для тих, хто хоче поєднати технічну кар’єру з соціальною місією, це окремий сегмент ринку.

Контракти й фриланс як прихований канал

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

• чітко окреслені проєкти;
• коротко- чи середньострокові контракти;
• часткову зайнятість.

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

Нетворкінг і «теплі» інтродукції

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

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

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

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

Знайти правильні майданчики — лише половина задачі. Друга половина — переконати розподілену команду, що вам можна довірити роботу без фізичного контролю.

Маленький remote-first стартап наймає зовсім не так, як корпорація на кшталт Amazon:

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

Робочі артефакти як доказ, а не слова

Більшість кандидатів намагаються «продати» себе фразами в стилі:

• «Я самомотивований»;
• «Я добре комунікую»;
• «Я чудово працюю самостійно».

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

У технічних і ML-ролях такими артефактами можуть бути:

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

Для віддаленого роботодавця це відповідь на ключове питання: чи здатна людина:

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

Письмова комунікація як «репетиція» роботи

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

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

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

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

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

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

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

Джерело

YouTube: Your LinkedIn Search Won’t Find Remote Tech Jobs in 2026 (Here’s What Will)

OpenAI показала, як нова функція computer use у застосунку Codex перетворює ШІ‑агента на повноцінного «співробітника», здатного самостійно керувати локальними програмами на Mac — від віртуальних машин до Spotify та нагадувань.

Від коду до будь‑яких задач на комп’ютері

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

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

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

Багатозадачність: кілька курсорів і кілька застосунків одночасно

Один із показових сценаріїв — автоматизація рутинних технічних дій. Наприклад, створення нової віртуальної машини macOS в UTM зазвичай вимагає десятків кліків і проходження майстра встановлення. Тепер достатньо ввести запит на кшталт «створи нову Mac VM в UTM» — Codex відкриває застосунок, запускає процес, клікає по інтерфейсу, завантажує macOS і може навіть пройти початкове налаштування системи.

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

Більше того, Codex здатен:

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

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

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

Як Codex «бачить» інтерфейс: скріншоти плюс accessibility

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

Це дає кілька важливих ефектів:

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

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

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

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

Безпека: доступ до застосунків — лише за дозволом

Можливість для ШІ‑агента клікати по будь‑яких вікнах і вводити текст на комп’ютері природно викликає питання безпеки. Розробники роблять акцент на гранульованих дозволах:

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

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

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

Від особистих сценаріїв до «надлюдської» швидкості

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

З технічного боку важливо, що можливості комп’ютерного керування інтегровані в основні GPT‑моделі, доступні через API. Раніше для таких задач тренували окремі спеціалізовані моделі, тепер же ті самі базові моделі, які використовують розробники, можуть отримати доступ до computer use й будувати власні агенти з керування комп’ютером.

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

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

Джерело

Computer use in Codex — OpenAI на YouTube

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

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

Закритий AI‑loop як новий стандарт вартості бізнесу

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

У такій моделі:

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

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

Рівень 1: знання як інфраструктура, а не побічний продукт

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

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

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

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

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

Це й є фундамент закритого AI‑loop: не «один розумний бот», а стійка інфраструктура даних, до якої можна під’єднувати різні «мізки».

Голос замість клавіатури: як змінюється шар введення даних

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рівень 2: агенти на вершині знань, а не поверх хаосу

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

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

Щоб піти глибше, команда тестує десктопний застосунок Claude Co‑Work разом із YouTube‑відділом. Тут архітектура вже більше схожа на справжню виробничу систему. Продюсери підтримують «мастер‑папку» з підпапками для кожного етапу продакшну: заголовки, прев’ю, сценарії, дистрибуція, дослідження гостей.

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

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

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

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

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

У соцмережевій компанії засновниці такі агенти вже працюють у кількох критичних точках. Щопонеділка о 9:00 один агент запускає повне дослідження трендів контенту й формує документ із десятьма ідеями відео для каналу Silicon Valley Girl. До того, як команда відкриє ноутбуки, у них уже є список тем, зібраний на основі актуальних даних.

О 10:00 інший агент збирає найважливіші новини в галузях AI, технологій і бізнесу за останні сім днів і зводить їх в один підсумковий огляд. Щодня ще один агент моніторить згадки бренду Silicon Valley Girl у медіа й надсилає оновлення, якщо з’являються помітні згадки в технологічних чи бізнес‑виданнях.

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

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

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

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

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

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

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

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

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

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

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

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

Джерело

YouTube: Build a Self-Running AI Company in 16 Minutes (Move 75% Faster)

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

Класичний спосіб: тимчасова змінна і три рядки

У багатьох мовах програмування обмін значень двох змінних виглядає так:

temp = a
a = b
b = temp

Тут створюється додаткова змінна temp, яка тимчасово зберігає значення a. Підхід працює, але:

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

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

Пайтонічний обмін: один рядок через розпакування

У Python те саме можна записати в один рядок:

a, b = b, a

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

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

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

Переваги такого підходу:

• менше коду;
• немає ризику «забути» очистити або не так використати тимчасову змінну;
• чітко видно намір — саме обмін значень.

Обмін кількох значень і робота з елементами масивів

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

a, b, c = c, a, b

Аналогічно працює й з елементами масивів (списків):

arr[0], arr[1] = arr[1], arr[0]

Тут відбувається обмін значень між arr[0] та arr[1] без додаткових змінних. Python дозволяє комбінувати змінні та індекси в одному присвоєнні:

a, arr[2] = arr[0], a

У цьому прикладі:

• a отримує значення arr[0];
• arr[2] отримує попереднє значення a.

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

Менше коду — більше ясності

Однорядковий обмін значень через конструкцію a, b = b, a — типовий приклад «пайтонічного» стилю: мінімум синтаксису, максимум виразності. Він:

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

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

Джерело

YouTube: https://www.youtube.com/watch?v=my5TOaiJVX0

AI-агенти на кшталт Claude, Codeex, Cursor чи Windsurf стають справді корисними лише тоді, коли вміють працювати з реальними робочими інструментами — від Gmail і Google Drive до Salesforce, HubSpot чи Slack. Канал Tech With Tim показує це на практиці, використовуючи сервіс Composio як єдиний MCP‑конектор, що під’єднує штучний інтелект до десятків і навіть сотень зовнішніх застосунків.

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

Коли нативних конекторів стає забагато

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

Перше обмеження — один обліковий запис на сервіс. Нативні конектори Claude сьогодні дозволяють прив’язати лише один акаунт Gmail, один Google Drive, один Salesforce тощо. Для багатьох користувачів це не відповідає реальності: окремі поштові скриньки для особистих листів, роботи, фрилансу; кілька робочих просторів у Google Drive; різні інстанси CRM для різних проєктів. Якщо таких акаунтів п’ять, доводиться обирати один, а решту просто ігнорувати.

Друге — так званий context bloat, або роздуття контексту. Щоразу, коли Claude отримує запит, у системний промпт моделі передається опис усіх доступних інструментів. Якщо користувач підключив десять конекторів, а кожен із них експонує по 50 окремих функцій, модель бачить уже 500 інструментів.

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

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

Composio як єдиний MCP‑шлюз до тисячі застосунків

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

Через цей єдиний конектор можна під’єднати приблизно тисячу різних застосунків. Серед них — Instagram, YouTube, Slack, Reddit, Monday, Figma, Salesforce, HubSpot, Gmail, Google Drive та багато інших. Користувач працює з ними через веб‑дашборд Composio: обирає потрібний сервіс, проходить OAuth‑авторизацію, а далі всі сесійні токени та оновлення доступу бере на себе Composio, а не Claude чи інша AI‑платформа.

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

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

Як Composio бореться з context bloat і підвищує точність інструментів

Найцікавіша частина архітектури Composio — це on‑demand tool discovery, або пошук інструментів на вимогу. Замість того щоб «засипати» Claude сотнями описів інструментів, Composio експонує до моделі лише невеликий набір метаінструментів.

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

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

Claude вже працює не з сотнями можливостей, а з кількома релевантними. Модель обирає потрібний інструмент — наприклад, «Gmail send email» — викликає його через Composio, отримує результат і формує відповідь користувачеві. Якщо потрібно, може бути задіяний multi‑execute: спочатку отримати дані, потім створити чернетку листа, потім надіслати його.

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

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

Єдина конфігурація для Claude, Codeex, Gemini та інших

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

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

Це особливо важливо для команд, які експериментують із різними моделями або використовують кілька агентів для різних задач. Замість того щоб повторювати одну й ту саму роботу — підключати Gmail, Google Drive, Slack, CRM у кожній платформі окремо — достатньо один раз пройти OAuth‑флоу в Composio. Далі кожна нова платформа просто «вказує» на вже готову конфігурацію.

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

Досвід користувача: від дашборда до прав доступу

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

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

Інтеграція з Claude Co‑Work відбувається через додавання кастомного конектора. У налаштуваннях Claude користувач створює новий конектор, вставляє URL, який надає Composio, і підтверджує підключення в браузері. Після авторизації Claude бачить лише невеликий набір метаінструментів Composio, а не повний список усіх підключених сервісів.

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

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

Висновок: інфраструктура, а не просто «ще один конектор»

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

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

по‑друге, зменшує context bloat завдяки on‑demand tool discovery й обрізанню результатів, що економить токени й підвищує точність виклику інструментів;

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

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

Джерело

YouTube: Connect Claude to ANY Tool | Full Tutorial