У світі, де великі мовні моделі вже вміють писати код, відповідати на листи й аналізувати документи, одна проблема досі залишалася дивно «ручною»: взаємодія з реальним вебом. Канал Tech With Tim у великому туторіалі розбирає Browserbase — платформу для віддалених браузерів під керуванням ШІ — і показує, як її SDK Stagehand та Model Gateway перетворюють браузер на інструмент, яким можна керувати звичайною мовою, без крихких CSS?селекторів і зоопарку API?ключів.

Цей матеріал зосереджений саме на двох ключових складових Browserbase — Stagehand та Model Gateway — і на тому, як вони змінюють підхід до веб?скрейпінгу, автоматизації та інтеграції LLM у бекенд?сервіси.

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

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

Stagehand, SDK від Browserbase, пропонує інший рівень абстракції. Замість того, щоб вручну вказувати page.click('button[data-id="login"]'), розробник формулює намір природною мовою: «натисни кнопку входу», «заповни поле email значенням X», «витягни заголовок першої новини». Далі вже LLM, підключена через Stagehand, аналізує сторінку, знаходить відповідні елементи й виконує дії.

Цей підхід дає дві помітні переваги.

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

По?друге, знижується поріг входу. Розробнику не потрібно бути експертом у внутрішній структурі кожного сайту, з яким працює агент. Достатньо описати завдання на рівні бізнес?логіки, а не DOM?деталей. Це робить Stagehand привабливим не лише для інженерів, які втомилися від Selenium, а й для команд, що хочуть швидко прототипувати AI?агентів без глибокого занурення в браузерну автоматизацію.

Чотири операції Stagehand: act, extract, observe, execute

Попри те, що Stagehand працює з природною мовою, його інтерфейс не розмитий. SDK формалізований навколо чотирьох базових операцій, які покривають більшість сценаріїв взаємодії з вебом: act, extract, observe та execute.

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

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

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

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

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

JSON?схеми та «чистий» скрейпінг: як витягувати структуру, а не текст

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

Stagehand вирішує це через підтримку JSON?схем. Розробник заздалегідь описує, яку саме структуру даних очікує отримати: наприклад, об’єкт із полями title, url, score та commentsCount. Ця схема передається разом із інструкцією до LLM, і модель повертає результат уже у вигляді валідного JSON, що відповідає заданому типу.

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

Показовий приклад — витягування топ?історії з головної сторінки Hacker News. У традиційному підході це вимагало б аналізу HTML?структури, пошуку класів, які відповідають заголовкам, посиланням, рейтингу, а також написання логіки для вибору саме першого елемента. У Stagehand достатньо однієї природномовної інструкції на кшталт «знайди топ?історію на головній сторінці Hacker News» у поєднанні з JSON?схемою очікуваного результату. LLM розуміє, як виглядає список історій, і повертає вже готовий структурований об’єкт.

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

Мультистековість і локальний режим: Stagehand без прив’язки до хмари

Ще одна важлива риса Stagehand — відсутність жорсткої прив’язки до конкретної мови програмування чи до хмарної інфраструктури Browserbase. SDK доступний для кількох популярних мов: TypeScript, Python, Java, Go та Ruby. Це означає, що його можна вбудувати як у сучасні TypeScript?бекенди, так і в Python?скрипти для дата?інженерії, Java?сервіси у великих підприємствах чи мікросервіси на Go.

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

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

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

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

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

Model Gateway: один інтерфейс для OpenAI, Anthropic та інших

Якщо Stagehand відповідає за «руки» в браузері, то Model Gateway — за «мозок», який керує цими руками. Browserbase пропонує єдиний шлюз для доступу до різних LLM?провайдерів, що дозволяє обирати моделі на кшталт OpenAI чи Anthropic без необхідності окремо керувати кожним API?ключем і SDK.

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

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

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

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

Висновок: браузер як сервіс, інструкції як код

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

Можливість використовувати Stagehand у різних мовах програмування й запускати його як із хмарними браузерами Browserbase, так і з локальними сесіями, робить цей підхід придатним як для швидких експериментів, так і для серйозних продакшн?навантажень. А приклади на кшталт витягування топ?історії з Hacker News однією інструкцією показують, що «високорівневий» скрейпінг — це вже не теоретична можливість, а практичний інструмент.

У міру того як LLM?агенти все частіше виходять за межі чат?інтерфейсів і починають взаємодіяти з реальним вебом, подібні SDK і шлюзи можуть стати стандартним шаром інфраструктури — таким самим звичним, як сьогодні HTTP?клієнти чи ORM.

Джерело

AI Web Scraping Is Insanely Good | Browserbase Full Tutorial

Спроби під’єднати AI-агента до браузера давно стали синонімом болю для розробників: крихкі селектори, Selenium-скрипти, блокування, CAPTCHA, відсутність нормального браузера на сервері. У новому туторіалі на каналі Tech With Tim розбирають Browserbase — платформу, яка пропонує керовані віддалені браузерні сесії для AI-агентів і веб-автоматизації та намагається системно вирішити ці проблеми.

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

Чому класична веб-автоматизація ламається на реальному світі

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

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

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

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

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

Віддалені браузери як сервіс: як працює Browserbase

У центрі платформи — керовані віддалені браузерні сесії. Ідея проста: замість того, щоб намагатися змусити AI-агента керувати локальним браузером (якого може й не бути), розробник піднімає сесію в Browserbase і дає агенту доступ до неї через API чи SDK.

Ця сесія — повноцінний «живий» браузер у хмарі, який може:

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

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

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

Ще один важливий аспект — модель використання. Browserbase пропонує щедрий безкоштовний рівень, на якому можна створити акаунт, отримати API-ключ у дашборді та почати експериментувати. Для інтенсивніших навантажень передбачені платні кредити. Така схема дозволяє спочатку протестувати ідею, налаштувати прототип, а вже потім масштабуватися, не переписуючи код під іншу інфраструктуру.

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

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

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

«Знайди елемент із селектором .btn-login і клікни по ньому»,

розробник або агент може сформулювати:

«Натисни кнопку входу на сторінці».

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

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

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

Хмара чи локально: однакові інструменти для різних середовищ

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

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

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

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

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

Прозорість для розробника: живий перегляд, реплеї та мережеві логи

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

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

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

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

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

Масштабування без болю: від безкоштовних експериментів до тисяч сесій

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

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

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

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

Висновок: від крихких скриптів до інфраструктури для AI-агентів

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

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

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

Джерело

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

У червні 2026 року Apple виходить на черговий великий рубіж: на WWDC 8 червня компанія покаже першу бету iOS 27. Український техноблогер Іван Лучков у своєму випуску на каналі «Канал Лучкова» розбирає, чому це оновлення може стати для iPhone тим самим «Snow Leopard-моментом» — релізом, який не стільки додає нові фішки, скільки нарешті приводить систему до тями. На тлі проблемної iOS 26, яку багато хто сприймає як один із найневдаліших релізів останніх років, очікування від iOS 27 виявилися незвично прагматичними: менше хаосу, більше порядку, плюс — глибока інтеграція штучного інтелекту.

WWDC 8 червня: бета iOS 27 як шанс «перезавантажити» iPhone

WWDC 2026 офіційно стартує 8 червня, і саме там Apple представить першу бету iOS 27. За таймлайном, озвученим у відео, до анонсу залишалося майже три тижні, а отже, тестова версія системи з’явиться приблизно через цей самий проміжок часу після запису. Для частини користувачів це буде звичайний розробницький реліз, для інших — довгоочікуваний вихід із «пастки» iOS 26.

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

Цю ідею підкріплює й характеристика від Марка Гурмана, одного з найуважніших спостерігачів за Apple. Він описує iOS 27 як оновлення рівня Snow Leopard — тієї самої версії macOS, яка свого часу стала символом «чистки»: мінімум нових функцій, максимум роботи з багами, оптимізацією та видаленням зайвого коду. Для багатьох користувачів Mac саме Snow Leopard залишився еталоном стабільності та швидкості. Якщо Apple справді повторює цей підхід на iPhone, це означає зміну пріоритетів: замість нескінченного нарощування функцій — спроба знову зробити систему передбачуваною і надійною.

Перезапуск Siri: з голосового помічника до повноцінного AI-чату

Центральна тема iOS 27 — радикальна еволюція Siri. Те, що роками залишалося напівкорисним голосовим помічником, перетворюється на повноцінного текстового асистента з власним застосунком. Це не просто косметичне оновлення, а зміна парадигми взаємодії з системою.

У iOS 27 з’явиться окремий застосунок Siri, побудований за логікою сучасних чат?ботів. Користувачі зможуть вести з асистентом чат?спілкування, переглядати історію діалогів, шукати по попередніх розмовах. Структурно це нагадує iMessage, але замість переписки з людьми — діалог із AI. Такий підхід вирішує одразу кілька давніх проблем Siri: фрагментованість, відсутність контексту і неможливість повернутися до попередніх запитів.

Ключова зміна — розширення можливостей самої Siri. У новій версії вона зможе:

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

по?друге, аналізувати файли, які користувач завантажує на iPhone, — від документів до, потенційно, медіа;

по?третє, генерувати зображення через інструмент Image Playground.

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

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

Extensions і вибір AI?моделей: Siri як оболонка, а не монополіст

Найцікавіша системна зміна iOS 27 — поява механізму extensions для штучного інтелекту. Йдеться не про класичні розширення браузера, а про систему, яка дозволяє підміняти «двигун» Siri сторонніми AI?моделями для різних типів задач.

Формально користувач продовжує взаємодіяти із Siri — викликає її голосом чи через застосунок. Але всередині, замість єдиної «рідної» моделі Apple, може працювати будь?яка інша мовна модель: умовний Gemini, ChatGPT чи інший хмарний сервіс. Причому iOS 27 дозволить налаштовувати це гнучко: окремо вибирати модель для тексту, окремо — для зображень, окремо — для голосових запитів.

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

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

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

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

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

Камера, календар, клавіатура: як AI проникає в базові застосунки

Окрім Siri, iOS 27 приносить низку змін у повсякденні інструменти, якими користуються мільйони людей щодня. Спільний знаменник цих оновлень — глибша інтеграція AI та розширена кастомізація.

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

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

Окремо згадується розширене налаштування ефекту Liquid Glass. Цей візуальний ефект — частина нового дизайну iOS, і в 27?й версії користувачі отримають «дуже тонке» керування ним. Це може означати можливість змінювати інтенсивність, прозорість, поведінку анімацій — загалом, підганяти візуальний стиль системи під власні вподобання. Для Apple, яка роками тримала дизайн у жорстких рамках, це ще один крок до більш гнучкої персоналізації.

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

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

«Snow Leopard?оновлення»: ставка на чистку, а не на шоу

Найважливіший аспект iOS 27 — не перелік нових можливостей, а загальна філософія релізу. Марк Гурман називає його «Snow Leopard?оновленням», і це формулювання добре пояснює очікування.

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

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

менше випадкових зависань і перезавантажень;

швидший запуск застосунків;

кращу роботу батареї за рахунок оптимізації фонових процесів;

менше конфліктів між новими AI?функціями та старими компонентами системи.

На цьому тлі нові можливості Siri, AI?календар, оновлена камера чи клавіатура виглядають не як самоціль, а як «бонус» до головної задачі — зробити iOS знову надійною. Власне, саме так автор формулює суть: iOS 27 — це «нормальний реліз iOS 26», той, заради якого користувачі «терпіли весь цей рік».

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

Висновок: iOS 27 як тест на дорослість для AI?епохи Apple

iOS 27 виглядає як перша спроба Apple по?справжньому інтегрувати штучний інтелект у iPhone без руйнування базового досвіду користувача. Замість того, щоб нав’язувати одну «правильну» модель, компанія будує систему, де Siri стає єдиним інтерфейсом до різних AI?двигунів, а extensions дозволяють підбирати найкращий інструмент для кожного типу задач.

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

Якщо iOS 27 справді поєднає в собі глибоку AI?інтеграцію, гнучкість вибору моделей і відчутний приріст надійності, цей реліз має всі шанси стати одним із найважливіших для iPhone за останні роки. А перша бета, яка має з’явитися вже за кілька тижнів після WWDC 8 червня 2026 року, покаже, чи готова Apple до такого «дорослого» підходу в епоху штучного інтелекту.

Джерело

YouTube — «iOS 27 готує “ЧИСТКУ” iPhone – вона стане ЛЕГЕНДОЮ.»

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

Сейф, сертифікат і медвежатник

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

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

«Ану-ка взламай мені і покажи, як ти це зробив».

Результат дає не папірець, а практичне розуміння:
– чи вдалося зламати сейф;
– скільки часу це зайняло;
– якими методами це зроблено;
– де саме виявилися слабкі місця конструкції.

Це вже не формальна оцінка, а реальний тест безпеки.

Як це стосується адвокатів і «курсів у хакерів»

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

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

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

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

Практичне знання проти формальної безпеки

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

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

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

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

Джерело

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

Anthropic активно просуває концепцію «skills» (навичок) у Claude Code — і це радикально відрізняється від звичного підходу до промптів. Автор відео на каналі Austin Marchese систематизував те, як самі інженери Anthropic будують ці навички, і з цього вимальовується чотири чіткі правила роботи з Claude, які можна застосувати навіть без технічного бекграунду.

Від промптів до навичок: зміна мислення

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

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

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

Anthropic пропонує дивитися на це як на тришарову архітектуру:

1. Модель — сам Claude.
2. Агенти та промпти — звичний рівень взаємодії.
3. Навички (skills) — «аплікаційний» шар, де й відбувається справжня автоматизація.

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

Навички — це більше, ніж просто промпт

Формально створити навичку нескладно: достатньо попросити Claude «створи навичку для X». Але щоб вона працювала стабільно й масштабувалася, важливо розуміти її внутрішню структуру. Інженери Anthropic мислять навичкою як трирівневою системою:

1. Опис (description)
   Це те, що Claude читає першим, коли вирішує, чи варто застосовувати навичку. Якщо опис розмитий, модель не знатиме, коли її викликати. Якщо конкретний — зможе автоматично підключати навичку без явного запиту користувача.

2. Інструкції (instructions)
   Детальний покроковий план: як саме виконати задачу. Це «плейбук», якому Claude слідує після того, як обрав навичку.

3. Інструменти (tools)
   Найчастіше недооцінений шар: скрипти, API-виклики, референсні файли. Саме тут навичка стає чимось більшим за «розумний промпт». Інженери Anthropic наголошують: користувачі часто витрачають багато часу на «красивий» текст промпту, але залишають інструменти сирими — без документації, з абстрактними параметрами на кшталт a і b. У результаті навіть людина-інженер не змогла б ефективно цим скористатися, не кажучи вже про модель.

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

Компоновані навички замість «монолітів»

Ще один принцип Anthropic — компонуємість (composability). Навички мають бути:

• невеликими,
• сфокусованими,
• багаторазово придатними.

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

• дослідження ідей для YouTube,
• написання сценарію,
• підготовка посту для LinkedIn тощо.

Це дає три практичні переваги:

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

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

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

Патерн 1: зберігати скрипти всередині навичок

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

Результат:

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

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

Патерн 2: контроль, хто може викликати яку навичку

У Claude skills передбачені два важливі прапорці доступу:

• user_invocable
  Якщо встановити false, навичка зникає з меню слеш-команд. Її можуть викликати лише агенти, а не людина напряму. Це зручно для внутрішніх технічних інструментів, про які користувачеві не потрібно думати.

• disable_model_invocation
  У цьому випадку навичку може запускати лише користувач, а модель — ні. Такий режим підходить для ризикових дій: відправлення повідомлень, деплой коду в продакшн тощо.

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

Навички, які розумнішають з кожною сесією

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

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

Практичний цикл виглядає так:

1. Користувач запускає навичку.
2. Отримує результат і оцінює: він задовільний чи ні.
3. Якщо відповідь неідеальна, ставить собі запитання:
   це разова ситуація чи правило, яке варто закласти в навичку назавжди?
4. Якщо це повторюваний патерн — оновлює навичку: додає правило, приклад, обробку edge case.

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

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

Підсумок: мислити як інженер, не будучи інженером

З чотирьох правил Anthropic вимальовується цілісний підхід до роботи з Claude Code:

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

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

Джерело

How Anthropic Engineers ACTUALLY Prompt Claude Code — YouTube

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

Як працює зв’язка «смартфон — Codex — комп’ютер»

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

Ключові моменти:

• Ніяких окремих інсталяцій: якщо на смартфоні вже є офіційний застосунок ChatGPT, у меню з’являється новий пункт Codex.
• Початкове налаштування:
• на комп’ютері має бути запущений десктопний Codex;
• мобільний застосунок просить «авторизувати цей телефон» на комп’ютері (пароль або Touch ID);
• використовується той самий акаунт, що й у десктопному додатку; якщо ввімкнена 2FA, її також потрібно пройти.
• Синхронізація проєктів:
• у мобільному інтерфейсі з’являються всі активні проєкти;
• підтягуються не лише проєкти з десктопного Codex, а й ті, з якими працювали через Codex CLI (термінал).
• Критичне обмеження: якщо комп’ютер вимкнений або заснув, мобільний Codex не працює. Застосунок лише керує тим, що запущено на машині користувача.

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

Окремий плюс — підтримка підключень не лише до локального комп’ютера, а й до віддалених серверів через SSH. Якщо на VPS встановлено Codex CLI і виконано вхід тим самим акаунтом, мобільний застосунок може керувати сесією на сервері так само, як і на локальному MacBook.

Codex проти Claude: різні підходи до мобільних агентів

Anthropic кілька місяців тому запустила можливість керувати агентом для розробки зі смартфона через функцію Dispatch. Але є важлива відмінність:

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

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

Інтерфейс і можливості: від чатів до SSH-сесій

Структура та навігація

У мобільному Codex користувач бачить:

• список усіх проєктів (як із десктопного Codex, так і з CLI);
• окремий блок чатів;
• хмарні гілки (cloud branches), якщо ними користуються;
• архівовані чати;
• список підключень (локальний комп’ютер, інші машини, SSH-сервери).

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

• прив’язати чат до конкретного проєкту;
• або працювати без проєкту («Не використовувати проект»).

Чати, створені на смартфоні, синхронізуються з десктопним Codex у реальному часі: те, що почато на мобільному, одразу видно на комп’ютері, і навпаки.

Підключення до серверів

Через розділ «Підключення» можна:

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

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

Моделі, голос і рівень «мислення»

У чаті доступні:

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

Рівні доступу до файлів і команд

Мобільний Codex підтримує ті самі режими дозволів, що й десктопний:

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

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

Плагіни та планування

У чаті доступні:

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

Нижче відображаються встановлені плагіни Codex. На локальній машині це може бути цілий набір (Google Sheets, Browser, Hyperframes тощо), на сервері — лише ті, що встановлені там (наприклад, GitHub plugin).

На момент запуску мобільного застосунку спостерігаються дрібні візуальні баги (іконки деяких плагінів не підтягуються), але функціонально вони працюють.

Скіли та MCP: є, але «за кадром»

Один із найчутливіших моментів для активних користувачів Codex — скіли та MCP-сервери:

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

Водночас:

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

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

Реальні сценарії: від проєктів до керування роутером

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

Робота з локальними проєктами

Приклад: проєкт prozoro track system, з яким раніше працювали на MacBook.

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

Таким чином, можна:

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

Керування роутером через SSH

Більш показовий кейс — агент Router Agent, який має інструменти для підключення до домашнього роутера по SSH.

Сценарій:

1. У проєкті заздалегідь налаштовано скрипт із дозволеними командами для роутера.
2. Агент із мобільного застосунку підключається до роутера через SSH.
3. Для кожної команди запитує дозвіл (можна схвалювати по одній або «завжди схвалювати»).
4. Після виконання формує звіт:
5. список підключених пристроїв;
6. переадресацію портів;
7. інші параметри стану мережі.

Теоретично в такій конфігурації можна:

• перезавантажувати роутер;
• відкривати/закривати порти;
• виконувати інші заздалегідь дозволені дії — усе зі смартфона, через агента.

Показово, що спочатку в цьому проєкті виникали помилки (ймовірно, через те, що він створювався в CLI), але повторні спроби показали, що мобільний Codex коректно працює і з такими сесіями.

Вердикт: мобільний Codex закриває критичний пробіл

Поява мобільного інтерфейсу для Codex суттєво змінює сценарії використання агентів для розробки:

• Раніше доводилося вигадувати обхідні шляхи — наприклад, прокидати Codex у Telegram-бота, щоб мати доступ зі смартфона.
• Тепер є нативний застосунок, який:
• напряму керує десктопним Codex і Codex CLI;
• підтримує роботу з локальними машинами та віддаленими серверами;
• синхронізує чати й проєкти між усіма середовищами.

На тлі Claude:

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

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

Джерело

Codex на смартфоні: AI-агент для розробки у кишені | Апдейт ChatGPT

Штучний інтелект уже не просто допомагає писати фішингові листи чи генерувати deepfake?відео. На новому етапі він безпосередньо бере участь у повному циклі кібератак — від пошуку вразливостей до їх експлуатації. У подкасті Mixture of Experts від IBM Technology, де говорили про безпеку AI?агентів, консалтингові стратегії OpenAI та нові нульові дні, експерти IBM X?Force та IBM Research окреслили, як саме AI змінює і наступ, і оборону в кіберпросторі — і чому це не історія про «кінець гри» на користь однієї зі сторін, а про нову рівновагу.

Нульовий день від Google: коли AI шукає й одразу ламає

Ключовий сигнал для ринку прозвучав від Google: компанія розкрила нульову вразливість, де AI нібито використовувався і для її виявлення, і для експлуатації. Це не просто ще один «zero?day» у довгому списку CVE. Вперше на великій публічній сцені зафіксовано кейс, де модель штучного інтелекту стала інструментом повного наступального ланцюжка.

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

Цей кейс накладається на ще один важливий маркер: Anthropic раніше публічно демонструвала використання своєї моделі Opus 4.6 для пошуку вразливостей у програмному забезпеченні. Про це йшлося на конференції Unprompted у Сан?Франциско. Тобто провідні лабораторії не просто теоретизують, а вже експериментують з AI як інструментом дослідницького пентесту.

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

«Patch apocalypse»: коли машини знаходять десятирічні баги швидше, ніж люди встигають оновлюватися

У IBM X?Force Offensive Research для поточної ситуації вже з’явився власний термін — «patch apocalypse». Йдеться про лавиноподібну хвилю вразливостей, які виявляються та закриваються за допомогою AI?інструментів настільки швидко, що традиційні процеси управління патчами просто не встигають.

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

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

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

AI на захисті: верифікація патчів, раннє виявлення й «шумні» атаки

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

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

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

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

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

Pwn2Own Berlin: AI?патчі проти AI?експлойтів

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

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

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

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

Від deepfake?фішингу до автоматизованого пошуку багів: AI у кібербезпеці не почався вчора

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

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

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

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

Нова рівновага: чому AI не «перемагає» ні наступ, ні оборону

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

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

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

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

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

Політика frontier?AI: від заборон до прискорення оборони

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

Це включає кілька практичних вимірів.

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

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

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

Операційний вузол: 30 днів, які вирішують усе

Попри всі розмови про frontier?AI, zero?day та «patch apocalypse», реальний рівень кіберризику сьогодні часто визначається дуже приземленим показником: чи здатна організація закрити критичну вразливість протягом 30 днів.

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

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

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

Висновок: AI як каталізатор, а не «чарівна паличка»

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

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

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

Джерело

Mixture of Experts — AI skills security, Open AI Deployment Company & zero days (IBM Technology)

OpenAI відкриває новий фронт у боротьбі за корпоративний ринок штучного інтелекту. Паралельно з розвитком моделей на кшталт GPT компанія запускає окремий бізнес-напрям — Deployment Company, орієнтований на консалтинг та інтеграцію AI в роботу великих підприємств. У подкасті Mixture of Experts від IBM Technology цю стратегію обговорюють фахівці IBM, порівнюючи її з підходами Anthropic та власною моделлю IBM, яка робить ставку на «суверенітет» моделей та інфраструктури.

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

10 мільярдів за інтеграцію: що означає поява OpenAI Deployment Company

Запуск Deployment Company — це не просто ще один продукт у лінійці OpenAI, а окремий бізнес, сфокусований на тому, щоб допомагати великим підприємствам впроваджувати AI у свої операції. У розмові цей підрозділ оцінюють приблизно в 10 млрд доларів — сума, яка сама по собі є сигналом для ринку.

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

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

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

Вертикальна інтеграція: OpenAI хоче бути «розумом» корпоративних рішень

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

При цьому визнається, що в реальному світі неможливо замкнутися в одному вендорі. Deployment Company очікувано буде змушена працювати в середовищі, де вже присутні інші AI-провайдери — Google, Anthropic, різні open-source моделі — а також складні інфраструктурні стеки на кшталт AWS, Azure, Snowflake та інших корпоративних платформ.

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

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

Партнерство з McKinsey та Bain: як OpenAI заходить у кабінети топ-менеджерів

Щоб швидко зайти в корпоративні акаунти, OpenAI не обмежується власною командою. Deployment Company, за повідомленнями, будує партнерства з великими консалтинговими гравцями — McKinsey, Capgemini, Bain & Company.

Це логічний крок з кількох причин.

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

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

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

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

Anthropic і тренд «вендорських» консалтингових рук

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

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

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

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

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

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

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

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

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

Суть підходу полягає в тому, що для кожного клієнта підбираються ті моделі й ті інфраструктурні платформи, які найкраще відповідають його потребам, а не просувається один «обов’язковий» стек. Це може бути поєднання власних моделей IBM, рішень від інших великих провайдерів, open-source моделей, а також різних хмарних і on-premise інфраструктур.

Такий підхід має кілька важливих наслідків.

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

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

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

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

Чому консалтинг не «з’їсть» AI, а AI не «з’їсть» консалтинг

На тлі буму генеративного AI часто звучить питання: чи не замінять моделі самих консультантів? У дискусії навколо Deployment Company відповідь радше негативна: AI змінить консалтинг, але не зробить його зайвим.

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

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

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

Битва за корпоративний AI: хто стане головним інтегратором майбутнього

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

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

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

Джерело

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

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

На подкасті Mixture of Experts від IBM Technology IBM Fellow Куш Варшні та його колеги розповіли про підхід IBM Research до цієї проблеми — про MELLEA, нову парадигму «генеративних обчислень» і компілятор навичок, який перетворює розмиті текстові описи агентних skills на детерміновані Python?програми з вбудованими захисними механізмами.

Від «магічних» промптів до генеративних обчислень

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

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

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

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

Як працює MELLEA: skills.mmd перетворюються на Python

Ключовий інструмент у цьому підході — MELLEA skills compiler. Він бере на вхід natural?language опис навички у файлі skills.mmd і перетворює його на структуровану Python?програму.

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

Компілятор проходить кілька етапів:

спершу аналізує skills.mmd, виокремлюючи структуру навички, очікувані вхідні й вихідні дані, необхідні інструменти та зовнішні виклики;

далі будує детермінований каркас Python?програми, де чітко прописані кроки виконання, перевірки, обробка помилок;

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

Результат — звичайний Python?файл, який можна запускати з командного рядка, вбудовувати в більші системи, покривати тестами, переглядати в код?рев’ю, відслідковувати через Git. Навичка перестає бути «чорною скринькою» з промптів і перетворюється на програму, яку можна інспектувати й валідувати так само, як будь?який інший продакшн?код.

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

Детермінізм як відповідь на хаос маркетплейсів

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

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

У MELLEA?підході навичка — це детермінована програма, яка лише в окремих, явно визначених місцях викликає невеликі мовні моделі. Це дозволяє:

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

обмежувати повноваження LLM, не даючи їй прямого доступу до інструментів, API чи критичних систем без проміжних перевірок у коді;

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

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

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

Вбудовані «guardian hooks»: безпека за замовчуванням

Окремий вимір MELLEA — безпека виконання. Компілятор не просто транслює текст у Python, а й автоматично вставляє в скомпільовану програму так звані guardian hooks — захисні гачки, які забезпечують контроль під час роботи навички.

Ці guardian?механізми виконують кілька функцій.

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

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

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

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

A2A?сумісність без прив’язки до одного стандарту

Ще один важливий аспект MELLEA — сумісність із протоколами взаємодії агентів. У розмові згадується A2A (agent?to?agent) як один із таких протоколів, який використовується в польових проєктах IBM.

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

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

впроваджувати MELLEA?навічки в уже наявні агентні фреймворки;

експериментувати з різними протоколами без необхідності переписувати логіку skills;

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

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

Від лабораторії до GitHub: MELLEA відкриває код

На відміну від багатьох корпоративних дослідницьких проєктів, MELLEA не залишається суто внутрішньою технологією. Інформація про проєкт і код, включно з компілятором навичок, доступні публічно через сайт melia.ai та пов’язаний із ним GitHub?репозиторій.

Це відкриває кілька можливостей.

По?перше, зовнішні розробники й дослідники можуть експериментувати з MELLEA, пробувати компілювати власні skills.mmd, інтегрувати скомпільовані навички у свої агентні системи, перевіряти, як працюють guardian hooks у реальних сценаріях. Це створює зворотний зв’язок, який важко отримати в суто лабораторних умовах.

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

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

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

Що це означає для майбутнього агентних систем

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

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

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

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

Висновок

MELLEA — це спроба повернути дисципліну в епоху «магічних» LLM. Замість того, щоб покладатися на непрозорі промпти, IBM Research пропонує розглядати навички агентів як детерміновані програми, які лише точково використовують генеративні моделі. Компілятор skills.mmd у Python, вбудовані guardian hooks, сумісність із A2A без прив’язки до одного протоколу та відкритий код на melia.ai і GitHub роблять цей підхід не просто теоретичною концепцією, а практичним інструментом.

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

Джерело

AI skills security, Open AI Deployment Company & zero days — Mixture of Experts, IBM Technology

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

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

Фінансові Excel?моделі еволюціонують місяцями й роками: їх редагують різні люди, додають нові вкладки, змінюють структуру. У результаті:

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

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

ChatGPT для Excel: перевірка моделі там, де відбувається робота

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

• Finance model Q&A — запитання й відповіді щодо логіки моделі;
• Model audit tie?out — звірка показників між вкладками та пошук невідповідностей.

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

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

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

Безпечне «механічне» прибирання без зміни фінансової логіки

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

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

При цьому всі дії документуються. Інструмент додає до файлу нові вкладки, зокрема:

• QA issue log — журнал виявлених проблем;
• Fixes applied — список застосованих виправлень;
• Remaining risks — перелік залишкових ризиків і питань, які потребують уваги людини.

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

Менше ризику перед виходом на рівень керівництва

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

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

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

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

Таким чином, ChatGPT для Excel не замінює фінансових аналітиків, а бере на себе рутинну частину перевірки, дозволяючи людям зосередитися на змісті, а не на пошуку зламаних клітинок.

Джерело

Update and audit a finance model in Excel with ChatGPT — OpenAI

AI?агенти вже вміють писати тексти, розшифровувати аудіо й планувати пости, але в більшості компаній люди досі виступають «кур’єрами» між цими інструментами. Випуск подкасту Silicon Valley Girl про «AI?native» бізнес показує, як новий підхід — так званий «інтернет агентів» — намагається вирішити цю проблему за допомогою відкритої інфраструктури.

Коли людина — «клей» між інструментами

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

Приклад із продакшену контенту:

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

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

Інтернет агентів: безлюдний ланцюжок завдань

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

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

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

Ключові моменти:

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

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

Технічна основа: A2A, MCP та open source

Інтернет агентів спирається на вже наявні протоколи:

• A2A (agent?to?agent) — для безпосередньої взаємодії між агентами;
• MCP (Model Context Protocol) — для стандартизованого доступу моделей до зовнішніх інструментів і даних.

Це дозволяє:

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

Відкрите ядро цієї ініціативи — проєкт agency.org, який працює під егідою Linux Foundation. Над ним вже працюють понад 80 учасників, а Outshift by Cisco виступає одним із співзасновників.

Що це означає для AI?native бізнесів

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

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

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

Джерело

AI Agents Now Work Without You, If You’re Still Moving Files Manually – Stop Doing This

Коли засновник Box Аарон Леві говорить про штучний інтелект, це не теоретичні міркування. Його хмарна платформа, якою користуються близько 64% компаній зі списку Fortune 500, уже роками працює в серці корпоративних робочих процесів. Сьогодні Леві активно експериментує з AI?агентами — системами, які не просто генерують текст чи код, а виконують послідовності дій замість людини. І попри ентузіазм щодо їхніх можливостей, він залишається принципово обережним: у більшості важливих процесів, вважає він, на початку й у кінці все одно має стояти людина.

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

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

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

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

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

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

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

Межа у 2% помилок: коли автономія стає неприйнятною

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок: автономія як міф, співпраця як норма

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

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

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

Джерело

YouTube: $4B Founder: The Next 3 Years Will Make 100 New Founders Rich

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

Це відбувається на тлі помітного зростання кількості мови ненависті в X після придбання Twitter (пізніше перейменованого на X) Ілоном Маском. Дослідження Каліфорнійського університету в Берклі показало, що щотижневий рівень мови ненависті зріс на 50 відсотків, зокрема через активність ботів.

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

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

Ofcom щокварталу протягом наступного року аналізуватиме показники ефективності X. Регулятор також продовжує розслідування щодо ШІ Grok Ілона Маска через генерацію дитячого сексуального контенту та інтимних зображень без згоди людей. У березні Ofcom оштрафував скандально відомий іміджборд 4chan майже на 700 тисяч доларів за порушення закону про онлайн-безпеку. Адвокат 4chan у відповідь надіслав зображення хом’яка, згенероване ШІ.

Джерело

Engadget

Видавець 2K готується вилучити зі sprzedaжу аркадні перегони Lego, які вийшли три роки тому. На сторінках гри в різних цифрових магазинах з?явилося повідомлення, що Lego 2K Drive буде знято з продажу 19 травня. Мережеві сервери залишаться онлайн до травня 2027 року, після чого всі онлайн-функції припинять роботу.

Чому саме 2K прибирає гру, достеменно невідомо. З огляду на те, що це відбувається рівно через три роки після релізу Lego 2K Drive, цілком імовірно, що причина в завершенні дії ліцензій. У будь-якому разі кожне таке зникнення — це удар по збереженню ігор як культурної спадщини, адже тайтл стає недоступним для придбання.

Lego 2K Drive створена студією Visual Concepts, яка найбільше відома серіями NBA та WWE від 2K. Проєкт має схожу структуру з Forza Horizon та Mario Kart World: це гра з відкритим світом, у якому розкидані перегони, челенджі та інші завдання.

Джерело

Engadget

Президент Дональд Трамп і делегація американських посадовців у п’ятницю залишили Пекін після двох днів переговорів на високому рівні з урядом Китаю на чолі з головою КНР Сі Цзіньпіном.

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

«Нічого з Китаю не дозволено брати на борт», — написала Емілі Гудін, кореспондентка Білого дому видання New York Post, у дописі на X.

На фото з поїздки видно кількох людей з американської урядової делегації, серед них Трампа, директора з комунікацій Білого дому Стівена Чена, генерального директора Apple Тіма Кука, керівника Nvidia Дженсена Хуана та агентів Секретної служби США — усі вони носять значки на лацканах піджаків.

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

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

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

Джерело

TechCrunch

Якщо сьогодні у вас виникають проблеми із застосунком Nest, ви не одні. Попри запевнення на офіційній сторінці статусу Nest, що «все працює справно», насправді це не так. Судячи з власного досвіду, повідомлень на Reddit і карти збоїв Downdetector, у розумній домашній екосистемі Google щось пішло не так.

Користувачі почали повідомляти про проблеми з Nest на Downdetector приблизно о 3:30 ночі за східним часом США у п’ятницю. Приблизно через годину користувач r/Ok-Influence-164 створив тред на Reddit, де описав свою проблему. (Зараз у гілці вже понад 400 коментарів, і багато користувачів підтверджують збій.) Я також не можу отримати доступ до застосунку Nest із самого ранку, і жодні виходи з акаунта чи перезапуски застосунку не допомогли. Якщо ви спробуєте ним скористатися, будьте готові довго дивитися на завантажувальний екран, як на фото вище.

Google визнала інцидент і повідомила, що працює над виправленням, а також публікує оновлення на Reddit. Остання заява компанії звучить так: «Ми розгорнули виправлення проблеми, що впливала на роботу застосунку Nest, і досі працюємо над усуненням проблеми, яка зачіпає деякі сервіси застосунку Google Home». Тож якщо у вас досі нічого не працює, найближчим часом ситуація має покращитися.

Оновлення, 15 травня 2026 року, 15:56 за східним часом США: матеріал оновлено з урахуванням останньої інформації від Google щодо збою.

Джерело

Engadget