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

Що таке Higgsfield MCP і як він працює з Claude

Higgsfield — це креативна AI‑платформа, яка вже певний час існує як окремий вебсервіс для генерації зображень, відеокліпів і редагування медіа. Новий елемент — MCP‑конектор (Model Context Protocol), тобто спосіб, яким Claude може «розмовляти» з зовнішніми інструментами від вашого імені.

Схема роботи проста:

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

Жодного коду, API‑ключів чи складних конфігурацій — усе зводиться до одноразового додавання URL‑адреси конектора та авторизації через безкоштовний акаунт Higgsfield.

Налаштування конектора: від нуля до готовності за хвилину

Процес підключення MCP‑конектора до Claude виглядає так:

1. Відкрити Claude в браузері
   Зайти на claude.ai та натиснути на іконку профілю внизу ліворуч, далі — «Settings».

2. Перейти до розділу Connectors
   У меню налаштувань зліва обрати «Connectors».

3. Додати кастомний конектор
   Натиснути «Add custom connector» — з’явиться невелике вікно з двома полями.

4. Заповнити поля

5. Name: Higgsfield

6. URL: https://mcp.higgsfield.ai/mcp

7. Підтвердити додавання
   Натиснути «Add». На цьому технічна частина завершена.

Під час першого використання Claude попросить авторизувати доступ до Higgsfield — потрібно увійти або швидко зареєструвати безкоштовний акаунт. Після цього конектор залишиться активним, а в списку з’явиться перемикач Higgsfield зі статусом «On».

Моделі зображень і відео: Nano Banana, GPT Image 2 та Cance 2.0

Higgsfield надає Claude доступ до кількох моделей для зображень і відео. Користувач може:

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

Генерація зображень

Для базового тесту достатньо простого запиту на кшталт:

«Згенеруй зображення невеликого фасаду пекарні на тихій вулиці восени. Тепле світло зсередини. Фотографічний стиль.»

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

Якщо потрібна конкретна модель, наприклад GPT Image 2, можна сформулювати запит так, щоб:

• вказати, що слід використовувати саме Higgsfield MCP;
• назвати модель у тексті.

Приклад підходу:

«Використовуючи Higgsfield MCP, згенеруй те саме зображення пекарні, але цього разу використай GPT Image 2.»

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

Ітерації та доопрацювання

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

«Візьми версію GPT Image 2. Зроби, щоб була пора сутінок замість полудня, і додай людину, яка читає на лавці зовні.»

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

Відеогенерація: детальний промпт як ключ до якості

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

Higgsfield підтримує відеомодель Cance 2.0 (Seedance 2.0), здатну генерувати кліпи до 15 секунд і працювати з кількома планами в одному ролику.

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

Для 10‑секундного «кінематографічного» кліпу з пекарнею використовується промпт приблизно на 1200 символів. У ньому детально описано:

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

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

Вибір моделі для відео

Як і з зображеннями, можна:

• дозволити Claude автоматично обрати модель (у прикладі це Clang 3.0);
• або явно вказати Cance 2.0, додавши до запиту формулювання на кшталт «використовуючи Higgsfield MCP… з Cance 2.0».

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

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

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

Послідовність роботи виглядає так:

1. Планування
   У чаті формулюється запит: допомогти спланувати пост, запропонувати концепцію, формат зображення, тривалість відео, тональність підпису. Claude пропонує ідею (наприклад, «повільна субота на висоті»), описує кадри, пропонує текст для підпису.

2. Уточнення деталей
   Модель ставить уточнювальні запитання:

3. який саме напій показати;
4. який фон — інтер’єр чи вид на гори;
5. чи є фірмові елементи (чашки, логотип, декор);

6. який настрій має передавати картинка.
   Власник кав’ярні відповідає, додаючи деталі (наприклад, латте, вид з вікна на гори, дерев’яні столи, тепле освітлення).

7. Генерація медіа
   Після узгодження плану достатньо вказати, що слід використати Higgsfield. Claude генерує кілька варіантів зображень (наприклад, на базі Nano Banana), пропонує обрати один, а потім створює короткий відеокліп за допомогою Cance 2.0.

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

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

Обмеження та вартість: що варто врахувати

Попри зручність, є кілька важливих нюансів:

• Непередбачуваність генеративного AI
  Результати не завжди ідеальні з першого разу. Ітерації — нормальна частина процесу, особливо у відео, де дрібні відхилення (світло, рух, деталі сцени) помітніші.

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

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

Джерело

YouTube: Generate Images and Videos Inside Claude (Higgsfield MCP Setup)

Від найкращого транскрайбера до «кишенькових» LLM: як досвід ElevenLabs формує нову хвилю локальних моделей

У світі генеративного ШІ більшість історій починаються з хмарних дата-центрів, сотень GPU і мільярдів параметрів. Але є й інша траєкторія — від прикладних, жорстко обмежених задач до маленьких, але добре продуманих моделей, які можна тренувати на звичайному ноутбуці. Саме так виглядає шлях Ангелоса Періволаропулоса, керівника команди speech‑to‑text в ElevenLabs, який відповідає за одну з найсильніших систем транскрипції на ринку — Scribe v2 — і паралельно показує інженерам, як із нуля зібрати власну мовну модель локально.

У межах практичного воркшопу на каналі AI Engineer він демонструє, що «тренувати LLM з нуля» — це не обов’язково про кластери в хмарі. Це може бути про PyTorch, ноутбук із 16 ГБ пам’яті, невеликий датасет і дуже чітке розуміння того, які компоненти моделі справді важливі. І цей погляд напряму виростає з досвіду побудови Scribe v2 — системи, яку в ElevenLabs описують як найкращу транскрипційну модель на популярних публічних бенчмарках на момент проведення воркшопу.

Від Scribe v2 до локальних LLM: що дає бекграунд у транскрипції

Поточна роль Ангелоса в ElevenLabs — це не просто «ML-інженер у команді продукту». Він очолює команду, яка займається перетворенням мовлення в текст, і значну частину часу проводить у режимі дослідника: тренує нові моделі, оптимізує інференс, а також частково відповідає за продуктову сторону — від вимог клієнтів до того, як модель поводиться в реальних сценаріях.

Саме його команда тренувала Scribe v2 — модель, яку в компанії позиціонують як найкращу на ринку за результатами популярних публічних бенчмарків для транскрипції. Це не просто маркетингова вивіска: щоб вийти на рівень «state‑of‑the‑art» у speech‑to‑text, доводиться роками відточувати інженерні інстинкти — від вибору токенайзера до побудови пайплайнів інференсу в реальному часі.

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

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

Воркшоп без магії: PyTorch, ноутбук і GitHub замість «чорних скриньок»

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

Ціль — з нуля натренувати невелику мовну модель у стилі GPT‑2, не використовуючи жодних попередньо натренованих ваг і не покладаючись на високорівневі бібліотеки на кшталт Hugging Face Transformers. Усе будується безпосередньо на PyTorch і кількох базових Python‑бібліотеках. Це навмисне обмеження: воно змушує розібратися, як саме влаштований трансформер, а не просто викликати готовий клас.

Код воркшопу викладений у публічному GitHub‑репозиторії, посилання на який учасники отримують через QR‑код. Далі кожен може обрати свій шлях: тренувати модель локально або піти в хмару.

Локальний сценарій розрахований на доволі реалістичну конфігурацію: ноутбук із приблизно 16 ГБ оперативної пам’яті. За таких умов невелика модель тренується досить швидко, щоб побачити результат у межах сесії. Якщо ж ресурси слабші або немає можливості довго навантажувати локальну машину, передбачений варіант із Google Colab: безкоштовні GPU цілком вистачають для такого масштабу експерименту.

Технічні вимоги залишаються помірними: Python 3.12, базове розуміння мови (хоча за потреби можна й «копіпастити»), підтримка Apple Silicon через MPS, CUDA або просто CPU. Для керування залежностями використовується інструмент UV, який автоматично створює віртуальне середовище й синхронізує пакети. Код можна писати як у локальному редакторі, так і в Colab‑ноутбуці, де одна команда встановлює все необхідне — від PyTorch до NumPy.

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

Чому досвід Scribe v2 важливий для дизайну маленької LLM

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

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

Цей спосіб мислення переноситься й у воркшоп:

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

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

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

Тому навіть маленький проєкт на Shakespeare‑корпусі стає майданчиком для відпрацювання тих самих принципів, які лежать в основі Scribe v2: уважний вибір представлення даних, продуманий тренувальний цикл, реалістичні обмеження інференсу.

Токенайзер як серце моделі: чому 65 символів кращі за 200 тисяч токенів

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

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

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

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

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

Водночас у такого рішення є очевидні обмеження. Символьні токенайзери погано масштабуються на складніші задачі: модель має вчитися розуміти кореляції між окремими літерами, а не між осмисленими одиницями на кшталт слів чи субслів. Фраза «the sky is blue» у вигляді слів дає моделі чіткі, семантично насичені токени, тоді як у вигляді символів — це довга послідовність, де зв’язки між «s», «k», «y» і пробілами стають набагато менш очевидними.

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

Архітектура без прикрас: GPT‑2 як навчальний полігон

Ще одна принципова риса воркшопу — вибір архітектури. Замість того щоб гнатися за найновішими моделями, Ангелос свідомо зупиняється на GPT‑2‑подібному трансформері. Це «старіша» архітектура, але її фундаментальні частини залишаються актуальними: декодер‑only, каузальна self‑attention, MLP‑блоки, layer norm.

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

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

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

Розмір ембеддингів обрано на рівні 384. Для словника з 65 токенів це дає приблизно 25 тисяч параметрів у таблиці ембеддингів — дуже скромну цифру, яка добре вписується в обмеження локального тренування. Для порівняння, якби взяти типовий GPT‑2‑словник із 50 тисяч токенів і той самий розмір ембеддингів, кількість параметрів у таблиці зросла б до близько 19 мільйонів. І це лише один шар моделі.

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

Навіщо інженерам локальні LLM, якщо є хмара

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

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

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

По‑третє, це місток між різними доменами ШІ. Досвід, накопичений у speech‑to‑text і реальному часі, як у випадку Scribe v2, виявляється напрочуд корисним у світі LLM. Питання про те, як кодувати текст, як організувати інференс на обмежених ресурсах, як будувати тренувальні цикли, — універсальні. І воркшоп показує, як ці принципи можна застосувати в компактному, але повністю прозорому проєкті.

Висновок: маленькі моделі як школа великого ШІ

Історія Ангелоса Періволаропулоса — це приклад того, як робота над високоточними прикладними системами на кшталт Scribe v2 може стати фундаментом для зовсім іншого типу проєктів — освітніх, відкритих, локальних. Керуючи командою speech‑to‑text в ElevenLabs і тренуючи модель, яку вважають найкращою на публічних бенчмарках, він паралельно демонструє, що розуміння ШІ починається не з API до гігантських LLM, а з базових рішень: як ми кодуємо текст, яку архітектуру обираємо, як організуємо тренування.

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

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

Джерело

Training an LLM from Scratch, Locally — Angelos Perivolaropoulos, ElevenLabs

iOS 26.5 у тестовій версії отримала змінений список оновлень, у якому йдеться про нові засоби захисту текстових повідомлень. Операційна система для смартфонів додасть наскрізне шифрування для RCS-повідомлень між пристроями на iOS та Android.

«Наскрізно зашифровані RCS-повідомлення (бета) в Messages доступні з підтримуваними операторами й поступово розгортатимуться», — так Apple описує нововведення. Налаштування буде ввімкнене за замовчуванням, але власники iPhone зможуть перевірити його в розділі Settings у меню RCS Messaging секції Messages після оновлення до iOS 26.5.

За даними 9to5Google, в застосунку Messages на iPhone з’являтиметься значок замка, коли чати з пристроями Android використовують шифрування. На боці Android у Google Messages чати з iOS виглядатимуть так само, як і спілкування з іншими користувачами із зашифрованими RCS.

Джерело

Engadget

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

Чіткий підхід ще не визначено, однак Times припускає, що модель може наслідувати те, що зараз відбувається у британському уряді, де кілька рівнів нагляду перевіряють, чи відповідають моделі ШІ стандартам безпеки. (Хоча у Великої Британії останнім часом також вистачає суперечок навколо регулювання ШІ.) Водночас є ймовірність, що ідея взагалі не буде реалізована.

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

Джерело

Engadget

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

Уряд США повідомляє, що баг, названий CopyFail, уже експлуатується «в полі», тобто активно використовується в зловмисних хакерських кампаніях.

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

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

На сайті CopyFail зазначається, що один короткий скрипт на Python «отримує root‑доступ на кожному дистрибутиві Linux, випущеному з 2017 року». За даними компанії з кібербезпеки Theori, яка виявила CopyFail, вразливість підтверджено на кількох широко використовуваних версіях Linux, зокрема Red Hat Enterprise Linux 10.1, Ubuntu 24.04 (LTS), Amazon Linux 2023, а також SUSE 16.

Інженер DevOps і розробник Йорейн Схрейверсхоф у блозі написав, що експлойт працює також на версіях Debian і Fedora, а також у Kubernetes, який використовує ядро Linux. Схрейверсхоф описав баг як такий, що має «незвично великий радіус ураження», оскільки працює «майже на кожному сучасному дистрибутиві» Linux.

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

У разі експлуатації помилка особливо небезпечна, оскільки дозволяє звичайному користувачеві з обмеженими правами отримати повний адміністраторський доступ (root) на ураженій системі Linux. Успішна компрометація сервера в дата‑центрі може дозволити зловмиснику отримати доступ до всіх застосунків, серверів і баз даних численних корпоративних клієнтів, а також потенційно дістатися інших систем у тій самій мережі або дата‑центрі.

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

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

Джерело

TechCrunch

Стартап у сфері геотермальної енергетики Fervo Energy у понеділок повідомив, що розраховує залучити до $1,3 млрд під час первинного публічного розміщення акцій (IPO).

Компанія може отримати оцінку до $6,5 млрд, якщо її акції продаватимуться за верхньою межею цінового діапазону у $21–24 за папір. Це більш ніж удвічі перевищує суму, яку, за повідомленнями, Fervo прагнула отримати раніше цього року, коли конфіденційно подала документи до Комісії з цінних паперів і бірж США (SEC), щоб розпочати процес IPO.

Акції Fervo будуть торгуватися на біржі Nasdaq під тикером FRVO.

Ціновий діапазон Fervo з’являється на тлі успішного IPO компанії X-energy. Ядерний енергетичний стартап залучив $1 млрд під час збільшеного за обсягом розміщення. Коли компанія встановлювала ціновий діапазон для IPO, вона орієнтувалася на оцінку близько $7 млрд. Нині ринкова капіталізація X-energy перевищує $8 млрд.

І Fervo, і X-energy отримують вигоду від стрімкого зростання попиту на електроенергію з боку технологічних компаній, які змагаються за довгострокові контракти на постачання для живлення своїх дата-центрів штучного інтелекту. Ця гонка підштовхнула ціни на будівництво нових газових електростанцій вгору на 66% за останні два роки.

Fervo стверджує, що її електростанція Cape Station — перший великомасштабний проєкт компанії — вироблятиме електроенергію за собівартістю близько $7 000 за кіловат встановленої потужності. Мета стартапу — знизити цей показник до $3 000 за кіловат, після чого геотермальна генерація зможе конкурувати за вартістю з електроенергією з природного газу.

Джерело

TechCrunch

AI‑агенти дедалі частіше працюють не лише з текстом, а й із реальними системами розробників — файлами, Git‑репозиторіями, веб‑сервісами. Канал IBM Technology розбирає, як саме агенти взаємодіють із зовнішнім світом через два підходи — класичний CLI та новий протокол MCP — і де кожен із них має сенс.

Два шляхи для агентів: CLI та MCP

CLI (Command Line Interface) — це знайомий розробникам термінал: ls, cat, grep, curl, git, docker та десятки інших утиліт. AI‑модель, навчена на мільйонах прикладів з мануалів, Stack Overflow і документації, зазвичай уже «знає», як ними користуватися: які прапорці існують, як будувати пайплайни, як комбінувати команди.

MCP (Model Context Protocol) працює інакше. Це стандартизований протокол, у якому спеціалізовані сервери надають набір «інструментів» із чітко описаними:

• назвою (наприклад, read_file, search_files);
• текстовим описом призначення;
• JSON‑схемою вхідних параметрів (типи, обов’язковість, опис).

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

Саме тут і виникає суперечка: чи не є MCP зайвою складністю, якщо модель і так чудово володіє CLI‑командами?

Коли CLI виглядає переконливіше

Простий кейс: робота з файлами

У базовому сценарії — прочитати файл notes.md і знайти певне слово в кількох Markdown‑файлах — агент може:

• через CLI:
• виконати cat notes.md для виведення вмісту;
• використати grep -n для пошуку слова в обох файлах;
• через MCP:
• викликати інструмент read_file на MCP‑сервері файлової системи;
• викликати search_files із рядком пошуку.

Результат однаковий, але є нюанси:

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

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

Git і «податок» MCP на контекст

Git — ще один показовий приклад. Через CLI агент може:

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

Альтернатива — GitHub MCP‑сервер із приблизно 80 інструментами. Кожен має:

• назву;
• опис;
• повну JSON‑схему параметрів.

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

Це означає:

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

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

Де MCP починає вигравати

Веб‑сторінки та «прірва» між сирими даними й корисним результатом

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

Через MCP:

• агент викликає MCP‑сервер Fetcher, побудований на headless‑браузері;
• використовує інструмент fetch_url із посиланням;
• сервер:
• запускає браузер;
• завантажує сторінку;
• чекає на виконання JavaScript;
• конвертує результат у читабельний текст;
• повертає його агенту.

Витрати — близько 250 токенів і кілька секунд.

Через CLI:

• старт із curl -s <URL> | head -n 200:
• замість контенту — майже суцільний JavaScript‑бандл, оскільки сайт працює на Next.js і віддає JS‑додаток, а не готовий HTML;
• далі агент:
• пробує фільтрувати HTML‑теги й відкидати JS через текстові утиліти — безуспішно;
• шукає вбудовані JSON‑фрагменти з даними — знаходить лише частини;
• пише Python‑скрипт, щоб реверс‑інжинірити внутрішній формат даних Next.js, яким фреймворк стрімить контент у браузер.

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

• витрачає понад 2 000 токенів;
• працює кілька хвилин;
• навантажує локальну машину додатковою обробкою.

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

Аутентифікація, доступи й аудит

Ще одна зона, де MCP має системну перевагу, — інтеграції з сервісами на кшталт Slack, Notion чи баз даних.

Через CLI агент змушений:

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

Через MCP:

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

На рівні організації це ще важливіше:

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

Усе це важко «прикрутити» до CLI постфактум, тоді як MCP закладає такі можливості в сам протокол.

Комбінований підхід: не «або‑або», а «і‑і»

Зіставлення сценаріїв показує чіткий патерн:

• CLI виграє, коли:
• команда майже один‑в‑один відповідає задачі (файли, Git, текстова обробка, запуск скриптів);
• модель добре знає інструмент із тренувальних даних;
• важлива компактність і дешевизна в токенах;
• корисна можливість будувати пайплайни через пайпи (|) і комбінувати кілька утиліт в один рядок.
• MCP виграє, коли:
• між «сирим» інтерфейсом (HTTP, CLI‑утиліта) та потрібним результатом є значний розрив (рендеринг JavaScript‑сторінок, складні API);
• потрібне централізоване керування аутентифікацією й доступами;
• важливі аудит, пер‑юзерні права й корпоративне управління;
• доцільно винести складну логіку на сервер, щоб агент працював із нею як із високорівневим інструментом.

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

• використовувати CLI там, де це прямий, дешевий і давно відпрацьований шлях;
• звертатися до MCP, коли потрібна додаткова абстракція, headless‑браузер, інтеграція з SaaS‑сервісами або корпоративне управління доступами.

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

Джерело

CLI vs MCP: How AI Agents Choose the Right Tool for the Job — IBM Technology

AI, скорочення і «золотий вік підприємництва»: як Shopify перебудовує роботу

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

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

7 500 людей, але в 100 разів продуктивніші: як Shopify уявляє собі майбутнє

Сьогодні в Shopify працює приблизно від 7 500 до 8 000 людей. Для компанії з мільйонами мерчантів по всьому світу це вже зрілий масштаб. Але амбіція Лютке на наступні п’ять років звучить парадоксально: він хоче бачити приблизно ту саму кількість співробітників — але з продуктивністю, яка зросте орієнтовно у 100 разів.

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

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

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

Коли 50% коду пише AI: що відбувається з інженерами

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

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

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

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

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

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

Скорочення в техі: чому AI став зручним цапом-відбувайлом

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

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

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

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

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

Які роботи зникнуть першими: «робити те, що сказали», проти реальної агенції

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

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

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

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

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

Підприємництво як найстійкіша до AI робота

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

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

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

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

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

Довга гра, публічний ринок і AI як тест на лідерство

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

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

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

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

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

Висновок: AI не кінець роботи, а кінець поганих робіт

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

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

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

Джерело

Shopify CEO on How AI is a Scapegoat for Mass Layoffs & Trump Derangement Syndrome in Canada — 20VC

Швидкий перехід користувачів від пошуку в Google до запитів у ChatGPT, Gemini чи Perplexity змінює правила цифрового маркетингу. Канал Futurepedia показує, як бізнесам адаптуватися до цієї реальності через Answer Engine Optimization (AEO) — оптимізацію під «відповідальні» системи штучного інтелекту.

Від SEO до AEO: що змінюється

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

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

• SEO — про те, щоб з’явитися в результатах пошуку.
• AEO — про те, щоб стати частиною згенерованої відповіді ШІ.

ШІ може:

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

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

Менше трафіку, але більше «теплих» лідів

Зміна поведінки користувачів не обов’язково означає падіння продажів. Навпаки, добре налаштована AEO може давати:

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

Типовий сценарій взаємодії з ШІ:

1. «Які найкращі інструменти для [моє завдання]?»
2. «Який із них краще для маленької команди?»
3. «Які недоліки в кожного варіанту?»
4. «Який ти порекомендуєш?»

До моменту переходу на сайт користувач уже:

• порівняв опції;
• відкинув частину конкурентів;
• зрозумів компроміси;
• сформував довіру до рекомендації.

За наявними даними, ліди з AI-відповідей можуть конвертуватися у 3–5 разів краще, якщо бренд «правильно» присутній у цих відповідях.

Як ШІ формує відповіді: джерела, фан-аут і нові можливості

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

Багатоджерельність і «query fanout»

Сучасні LLM (ChatGPT, Gemini, Perplexity тощо):

• не обмежуються топ-10 результатами Google;
• часто розбивають один запит на десяток і більше підзапитів (query fanout);
• збирають інформацію з великої кількості сторінок;
• синтезують персоналізовану відповідь.

За оцінками, 60–80% джерел, які використовують такі системи, знаходяться поза першою сторінкою Google. Це відкриває вікно можливостей для менших брендів, яким важко пробитися в класичному SEO.

Які джерела реально впливають

Під час аналізу відповідей ChatGPT на запит про «найкращі сайти з AI-інструментами» виявляється:

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

У різних систем (ChatGPT, Gemini, Perplexity) — різні:

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

Це означає, що:

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

AEO як процес: що саме варто відстежувати

AEO — це не просто «ще один вид SEO», а окремий шар роботи з контентом і репутацією.

Три ключові питання AEO

1. Як ШІ описує ваш бренд?
2. У яких контекстах згадує?
3. Які сильні та слабкі сторони підкреслює?

4. Для якої аудиторії вважає вас релевантними?

5. На які джерела він спирається?

6. Які домени найчастіше цитуються?
7. Які типи контенту (лістикли, блоги, відео, FAQ, огляди)?

8. Які сторінки вашого сайту реально впливають на відповіді?

9. Що можна змінити?

10. Який контент створити, щоб краще відповідати на часті запитання?
11. До яких сторонніх майданчиків варто потрапити?
12. Де потрібно оновити або уточнити інформацію про бренд?

Від ключових слів до повних запитань

У класичному SEO бізнеси працюють із:

• ключовими словами;
• короткими фразами.

В AEO фокус зміщується на:

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

Приклади типових AEO-запитів:

• «Як каталоги AI-інструментів допомагають порівнювати сотні варіантів?»
• «Який найкращий каталог AI-інструментів для продуктивності?»
• «Який каталог містить відгуки користувачів і рейтинги?»

Завдання бренду — стати частиною відповіді, а не просто «ранжуватися за ключем».

Це добре описує формула B2B-to-bot-to-consumer (B2BTOC):
бізнес → впливає на бота → бот впливає на споживача.

Як автоматизувати AEO: приклад HubSpot AEO

Ручний моніторинг десятків запитів у різних AI-системах швидко стає непідйомним. Для цього з’являються спеціалізовані інструменти, один із яких — HubSpot AEO, що автоматизує:

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

Налаштування: від бренду до промптів

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

• аналізує сайт;
• пропонує список конкурентів, які можуть з’являтися в тих самих відповідях ШІ;
• формує перелік продуктів/послуг;
• визначає цільові аудиторії (ICP) та стадії buyer journey.

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

Користувач може:

• редагувати, видаляти або додавати власні запитання;
• фокусуватися на певних стадіях воронки (наприклад, етап «розгляду»).

Аналіз відповідей: видимість, тональність, прогалини

Для кожного запиту інструмент показує:

• повну відповідь ChatGPT, Gemini, Perplexity;
• де й як згадується бренд;
• де він не згадується взагалі;
• які джерела процитовано.

Якщо бренд не з’являється в певних відповідях, система:

• пояснює, які типи контенту домінують у цитуваннях (наприклад, 50% — лістикли);
• показує конкретні сторінки, на які посилається ШІ;
• пропонує точні рекомендації — наприклад, створити лістикл із заданою темою, заголовком, аудиторією та ключовими словами або спробувати потрапити в уже існуючі списки.

Окремий сценарій — коли промпти прямо містять назву бренду. У такому разі:

• «видимість» не показова (бренд гарантовано згадується);
• зате корисний аналіз тональності: як ШІ формулює сильні сторони, для кого вважає бренд корисним, які формулювання повторюються.

Цитування: що реально впливає на відповіді

У розділі з цитуваннями HubSpot AEO агрегує:

• типи контенту:
• лістикли (часто найбільша частка),
• мультимедіа (відео),
• блоги,
• домашні сторінки,
• продуктові сторінки,
• документація, FAQ, help-центри;
• канали:
• peer (інші продуктові/сервісні компанії, не прямі конкуренти),
• review-сайти,
• власні ресурси бренду,
• earned-медіа,
• UGC (Reddit, YouTube тощо — залежно від ніші).

Це дозволяє побачити:

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

Важливий висновок: оптимізація лише домашньої та продуктових сторінок — недостатня. ШІ активно використовує:

• лістикли,
• огляди,
• відео,
• спільноти,
• FAQ та довідкові центри.

Рекомендації та дашборд

На основі зібраних даних формується:

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

Окремо підкреслюється роль YouTube:

• автоматично згенеровані й проіндексовані транскрипти;
• 10-хвилинне відео ≈ 2000 слів природної мови;
• сильні сигнали довіри (перегляди, коментарі, реакції).

У результаті YouTube дуже часто з’являється серед топ-джерел, які цитують AI-системи.

Що це означає для бізнесу

Перехід від «бути знайденим у пошуку» до «стати відповіддю ШІ» змінює пріоритети:

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

AEO вимагає:

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

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

Джерело

How to Get ChatGPT to Recommend Your Business | AEO in 2026

У розмові з циклу TED Intersections, опублікованій на каналі TED, візуальний ефектник Роб Бредоу (Industrial Light & Magic, Lucasfilm) та кураторка Нора Аткінсон (проєкт Burning Man у Смітсонівському інституті) обговорюють, як допитливість і ризик змінюють технології, кіно та сучасне мистецтво.

Коли «а що, як…» стає рушієм інновацій

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

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

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

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

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

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

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

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

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

Кураторство як полювання за власною цікавістю

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

Ключові елементи цього підходу:

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

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

Ризик, який додає сенсу роботі

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

Це проявляється в кількох вимірах:

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

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

Джерело

Even the galaxy far, far away runs on curiosity #TEDTalks

У новому технічному експерименті розробник і ютубер Tech With Tim показує, як перетворити потужну, але незручну в ручному використанні модель зображень Nano Banana 2 на повністю автоматизований «двигун» візуалів усередині Claude Code. Ключем стає зв’язка з двох навичок (skills): JSON‑промптера для детальних структурованих запитів і кастомного інструмента, що напряму викликає Gemini 3.1 Image API. Результат — багатосторінковий сайт із десятками унікальних картинок, згенерований за кілька хвилин без ручного промптингу.

Від «зайти на сайт і щось написати» до повністю керованого пайплайна

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

У продемонстрованому підході Claude Code стає «диригентом», який:

1. Приймає від людини високорівневий запит на кшталт «зроби стильний сайт з чотирма чистими, мінімалістичними зображеннями».
2. Перетворює цей запит у детальний JSON‑опис кожного кадру через спеціальний промптер‑skill.
3. Передає ці JSON‑специфікації в інший skill, що звертається до Nano Banana 2 через Gemini API та повертає готові зображення.
4. Вбудовує отримані картинки безпосередньо в макет сайту.

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

Показовий кейс — демо‑сайт, який Тим створив під час запису: він просто дав Claude Code загальний опис бажаного вигляду, а система самостійно спроєктувала лейаут, згенерувала всі зображення через Nano Banana і розмістила їх на сторінці. На все пішли лічені хвилини.

JSON‑промптинг як «мовний протокол» для Nano Banana

Серцем цього підходу є JSON‑промптер — спеціальна навичка Claude Code, яка перетворює звичайні текстові запити на структуровані JSON‑схеми. Замість розмитого «зроби красиву картинку з парфумом» модель отримує формалізований опис сцени з десятками параметрів.

Схема, яку використовує Nano Banana JSON Prompter, орієнтована на маркетингові зображення, UI‑макети, інфографіку та подібні типи візуалів. Вона включає низку полів, що задають композицію та стиль:

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

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

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

Саме ця структурованість дає Nano Banana 2 змогу стабільніше видавати передбачувані, візуально цілісні результати. Замість того, щоб покладатися на інтерпретацію короткого тексту, модель отримує чітку технічну специфікацію сцени.

Як встановлюється JSON‑prompter у Claude Code

Щоб підключити цей промптер до Claude Code, Тим використовує MCP Market — каталог навичок, які можна додавати до агентів. Обраний ним skill — Nano Banana JSON Prompter — уже містить опис поведінки та JSON‑схеми, тож не потрібно розробляти все з нуля.

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

npx skillfish add <username>/claude-code-nano-banana-skills

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

Після цього в інтерфейсі Claude Code з’являється новий skill, який можна викликати через слеш‑команду. Достатньо обрати «JSON prompting for Nano Banana» і сформулювати завдання природною мовою — далі Claude Code сам використає навичку, щоб побудувати потрібний JSON.

Цей підхід не обмежується готовим skill’ом з MCP Market. За бажанням розробник може створити власну схему, адаптовану під конкретний бренд, стиль або домен, і навчити Claude Code працювати саме з нею. Але навіть базовий промптер уже дає відчутний приріст якості порівняно з ручним промптингом.

Другий елемент ланцюга: кастомний skill для Gemini Image API

JSON‑промптер вирішує лише половину задачі — він формує структурований опис зображення. Щоб перетворити цей опис на реальну картинку, потрібен другий skill, який звертається до Nano Banana 2 через Gemini 3.1 Image API.

Цей кастомний skill обгортає Python‑скрипт, що викликає відповідний endpoint Gemini. Саме через нього Claude Code передає JSON‑промпти й отримує назад згенеровані зображення. Навичка підтримує низку важливих параметрів:

• reference images — можливість передати посилання або файл існуючого зображення, яке слугує відправною точкою для редагування чи стилістичної узгодженості;
• resolution — контроль роздільної здатності вихідного зображення;
• aspect ratio — вибір співвідношення сторін, наприклад 16:9 для відео‑прев’ю або 1:1 для квадратних карток.

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

Для роботи цього skill’а потрібен API‑ключ Gemini. Його отримують у Google AI Studio, де користувач створює новий ключ, вмикає білінг і, за рекомендацією, встановлює ліміт витрат — наприклад, 10 доларів — щоб уникнути несподіваних рахунків. Оскільки розширена генерація зображень — платна послуга, без налаштованого білінгу Nano Banana 2 через API працювати не буде.

Ключ передається в середовище як змінна GEMINI_API_KEY. Це дозволяє Python‑скрипту звертатися до Gemini без того, щоб явно «світити» секрет у коді або логах. Тим окремо застерігає: вставляти API‑ключ прямо в чат Claude Code небезпечно, оскільки він потрапляє до Anthropic; якщо так і зробити, ключ варто одразу ж відкликати.

Ланцюг із двох навичок: від тексту до сайту з десятками картинок

Справжня сила цієї конфігурації проявляється тоді, коли обидва skills працюють у зв’язці. Claude Code спочатку викликає JSON‑промптер, щоб перетворити загальний опис на детальний JSON, а потім передає цей JSON у Nano Banana‑skill, який звертається до Gemini API.

У демонстрації цей ланцюг використовується для створення повноцінного сайту. Користувач дає Claude Code завдання: зробити «супер стильний» сайт із чотирма різними зображеннями, які мають бути «sleek» і «clean». Далі відбувається кілька кроків, уже без участі людини:

Claude Code розбиває завдання на окремі візуальні блоки сторінки — наприклад, hero‑банер, картки продуктів, секцію з відгуками. Для кожного блоку викликається JSON‑промптер, який формує структурований опис сцени з урахуванням типу зображення, композиції, освітлення, матеріалів і середовища. Потім Claude Code викликає Nano Banana‑skill, передаючи отриманий JSON у Gemini 3.1 Image API. Nano Banana 2 генерує зображення, які повертаються назад у Claude Code. Нарешті, Claude Code інтегрує отримані картинки в HTML/CSS‑макет сайту.

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

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

Багатоетапне редагування зображень через reference images

Окремий аспект, який робить цю зв’язку цікавою для практичного використання, — підтримка багатоетапного редагування зображень. Nano Banana‑skill у Claude Code вміє працювати з reference images, тобто брати існуючу картинку як основу й вносити в неї зміни.

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

Claude Code, використовуючи Nano Banana‑skill, відправляє reference image і оновлений JSON у Gemini 3.1 Image API. Nano Banana 2 генерує нову версію, де змінено лише логотип, а композиція, кольори, фон і типографіка залишаються максимально близькими до оригіналу.

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

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

Комбінація Claude Code, JSON‑промптингу та Nano Banana 2 через Gemini API показує, як інструменти генерації зображень поступово переходять від «іграшкових» веб‑інтерфейсів до повноцінних автоматизованих конвеєрів.

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

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

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

Усе це не скасовує потреби в людському контролі якості й креативному баченні, але суттєво знижує поріг входу в складні візуальні задачі. Там, де раніше доводилося вручну «крутити» промпти в окремому генераторі, тепер можна описати бажаний результат один раз і дозволити Claude Code керувати Nano Banana 2 як частиною ширшого пайплайна.

Висновок

Зв’язка Claude Code і Nano Banana 2 через Gemini 3.1 Image API демонструє, як інструменти генерації зображень виходять за межі окремих веб‑сервісів і стають керованими компонентами в автоматизованих робочих процесах. Два ключові елементи — JSON‑промптер із чіткою схемою для маркетингових візуалів та кастомний skill для виклику Gemini — перетворюють Nano Banana 2 на «двигун» зображень, яким можна керувати з коду або з інтерфейсу Claude Code.

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

Джерело

Claude Code + Nano Banana 2 = This Changes Everything

У новому епізоді Confluent Developer Podcast продакт-менеджер Келеб Ґрілло розповідає про свій шлях від перших підробітків у школі до ролі product lead лінійки Warpstream у Confluent. Його історія — це не лише про Kafka, хмарні сервіси й BYOC-архітектуру, а й про те, як людина з нетехнічним стартом входить у високотехнологічну індустрію та вчиться жити з тим, що продакт-менеджер «майже завжди неправий» — але в правильному напрямку.

Нелінійний старт: від вікон і Toyota Land Cruiser до технологій

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

Першою «серйозною» позицією після університету стала робота в міжнародній неурядовій організації, що займалася проєктами розвитку для USAID, агенцій ООН та інших донорів. Там Ґрілло відповідав за бюджетування заявок: рахував, скільки коштує Toyota Land Cruiser в Уганді, як закласти витрати в кошторис, як звести воєдино технічну частину проєкту й фінансову реальність.

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

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

Перший контакт із Kafka: конкурентна розвідка в e-commerce

Справжній вхід у світ стрімінгу даних для Ґрілло стався в e-commerce-компанії, яка «не Amazon», але працює на великому ринку онлайн-торгівлі. Там він отримує одну з перших продакт-ролей, пов’язану зі стрімінговими даними.

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

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

Інжест-пайплайн для цього проєкту будувався на Apache Kafka. Це були 2017–2018 роки — час, коли Kafka вже стала стандартом для стрімінгу подій, але ще не була настільки «обгорнута» сервісами, як сьогодні. Для Ґрілло це був перший практичний досвід із технологією, яка згодом визначить його подальшу кар’єру.

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

Перехід у Confluent: від користувача Kafka до продакт-менеджера платформи

У травні 2019 року Келеб Ґрілло приєднується до Confluent як продакт-менеджер. На той момент він уже має за плечима досвід побудови Kafka-пайплайнів у промисловому середовищі, розуміння потреб аналітичних і data science-команд, а також навички роботи з бюджетами й складними організаційними структурами.

Коли він приходить у Confluent, Confluent Cloud ще далеко не схожий на сучасний керований сервіс «у стилі AWS». Існували два різні світи. Перший — «серйозний» хмарний бізнес із виділеною інфраструктурою, де Confluent фактично просто хостив Kafka-брокери для клієнтів. Другий — окремий self-serve продукт на мультиорендних кластерах, де можна було зареєструватися, додати картку й почати користуватися сервісом.

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

Ґрілло з перших днів опиняється в центрі цієї трансформації. Його завданням стає побудова єдиної consumption-based системи білінгу, яка могла б об’єднати різні типи кластерів, різні продукти (Kafka, Kafka Connect, ksql) і різні метрики використання — від пропускної здатності до обсягу зберігання. Це окрема велика історія, яку розбирає інша частина серії, але для розуміння кар’єрного шляху важливо інше: Ґрілло переходить від «споживача» Kafka в e-commerce до людини, яка формує комерційні й продуктові основи глобальної стрімінгової платформи.

Цей досвід — робота на перетині інженерії, фінансів, аналітики й бізнес-моделей — стане критично важливим, коли він згодом очолить продуктову лінійку Warpstream.

Warpstream і BYOC: новий етап, нова відповідальність

У грудні 2023 року Келеб Ґрілло приєднується до Warpstream, яка на той момент ще працює як окремий стартап, а згодом стає частиною Confluent. Сьогодні він — product lead для лінійки Warpstream у Confluent і очолює продакт-менеджмент цього напряму.

Warpstream позиціонується як BYOC-продукт — bring your own cloud. Це означає, що дані й обчислення живуть у хмарному середовищі клієнта, а не в акаунтах постачальника сервісу. Для корпоративних користувачів це критично: контроль над VPC, безпекою, IAM-політиками, мережевими кордонами залишається в їхніх руках.

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

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

BYOC-модель додає ще один вимір складності. Дані-плейн Warpstream працює у VPC або дата-центрі клієнта, без перехресних IAM-привілеїв для Confluent. Із середовища клієнта виходить лише метадані, які потрапляють у контрольну площину Confluent. Це створює іншу динаміку довіри, безпеки й операційної відповідальності, ніж у класичних керованих сервісах, де постачальник контролює й обчислення, і зберігання.

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

Бути «неправим у правильному напрямку»: продакт-менталітет

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

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

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

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

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

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

Нелінійні кар’єри як норма для продакт-менеджменту

Історія Келеба Ґрілло — показовий приклад того, як у сучасному продакт-менеджменті все рідше зустрічаються «прямі» кар’єрні траєкторії. Він не починав як інженер, не писав код у великих технологічних компаніях, не йшов класичним шляхом «junior dev → senior dev → tech lead → PM». Замість цього — миття вікон, міжнародний розвиток, бюджетування, бізнес-операції, e-commerce, і лише потім — продукти в стрімінгу даних.

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

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

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

Висновок: продакт-менеджмент як марафон помилок і корекцій

Кар’єра Келеба Ґрілло — це історія про те, як нетехнічний старт може привести до керівної ролі в одній із найцікавіших лінійок продуктів у світі стрімінгу даних. Від миття вікон і підрахунку вартості Land Cruiser в Уганді до побудови білінгових систем у Confluent Cloud і керування Warpstream як BYOC-продуктом — усі ці кроки складаються в цілісну траєкторію.

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

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

Джерело

Being Wrong in the Right Direction with Caleb Grillo | Ep. 29 | Confluent Developer Podcast

Заборона смартфонів у класі може бути не тією панацеєю, на яку розраховують уряди та адміністрації шкіл. Про це йдеться в нещодавно оприлюдненому дослідженні. Як повідомляє The New York Times, Національне бюро економічних досліджень США готує до публікації роботу під назвою The Effects of School Phone Bans: National Evidence From Lockable Phones («Вплив шкільних заборон телефонів: національні дані з шкіл із блокуванням телефонів»). У ній зроблено висновок, що заборони на мобільні телефони мали «стабільно майже нульовий» ефект на результати тестів.

У дослідженні проаналізували дані про розташування телефонів більш ніж із 40 000 шкіл у період із 2019 по 2026 рік. Воно показало тимчасове зростання кількості дисциплінарних інцидентів і короткочасне падіння рівня добробуту учнів, що пов’язали з початковими порушеннями звичного укладу. Втім, у наступні роки самопочуття учнів поліпшувалося, а дисциплінарні стягнення в довгостроковій перспективі зменшувалися.

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

Джерело

Engadget

Майже за тиждень після того, як розробники популярного програмного забезпечення для керування вебсерверами cPanel і WebHost Manager (WHM) попередили користувачів про критичну помилку, хакери масово зламують тисячі сайтів, які покладаються на вразливе ПЗ.

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

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

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

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

У четвер Агентство з кібербезпеки та безпеки інфраструктури США (CISA) попередило, що вразливість, якій присвоєно ідентифікатор CVE-2026-41940, уже активно експлуатується, і додало її до свого каталогу відомих експлуатованих вразливостей (Known Exploited Vulnerabilities, KEV). CISA закликало урядові установи встановити оновлення до неділі. Агентство не надало негайної відповіді на запит щодо того, чи може воно підтвердити, що урядові організації вже виправили свої сервери.

Атаки на вебсервери з cPanel і WHM, імовірно, тривали задовго до офіційного розкриття вразливості. За словами CEO хостинг-провайдера KnownHost Деніела Пірсона, його компанія фіксує такі атаки щонайменше з 23 лютого.

Неназваний представник cPanel підтвердив отримання запиту TechCrunch про коментар, але не надав розгорнутої відповіді.

Оновлено після отримання відповіді від cPanel.

Джерело

TechCrunch