Китай уперше з 2017 року знову очолив рейтинг найпотужніших суперкомп’ютерів світу. Система LineShine з Національного центру суперкомп’ютерів Китаю продемонструвала продуктивність 2,198 екзафлопса, обійшовши попереднього лідера El Capitan (1,809 екзафлопса), розташованого в Ліверморській національній лабораторії імені Лоуренса у США. LineShine, раніше не заявлена в рейтингу машина, стала першим суперкомп’ютером, який перевищив два екзафлопси «сталої продуктивності з подвійною точністю, використовуючи лише CPU», за даними Top500.org.

Новий китайський суперкомп’ютер зміг обійти американського конкурента попри технологічні ембарго, оскільки не покладається на GPU, як інші флагманські системи. Замість цього він побудований навколо кастомного 304-ядерного процесора, має загалом 13,79 млн ядер із частотою 1,55 ГГц, з’єднаних за допомогою власної системи інтерконекту. Споживання становить близько 42,2 МВт, що дає ефективність 52,07 гігафлопса на ват. «Це вражаюча система», — сказав організатор Top500 доктор Джек Донгарра в коментарі The New York Times. «Вони обійшли нас, розробивши систему, яка не залежить від GPU».

Попри те, що Китай повернув собі перше місце, оновлений рейтинг тепер містить п’ять систем, які перевищують екзашкалу — тобто один екзафлопс продуктивності. Одна з них розташована в Китаї, три — у США і ще одна — в Німеччині. Frontier з Національної лабораторії Оук-Ридж тепер посідає третє місце з 1,353 екзафлопса, а Aurora з Національної лабораторії Аргонн — четверте з 1,012 екзафлопса. Суперкомп’ютер Jupiter Booster у Центрі суперкомп’ютерних обчислень Юліха займає п’яту позицію з показником рівно один екзафлопс.

Top500 відзначає значне різноманіття архітектур у цьогорічному списку: різні моделі суперкомп’ютерів базуються на рішеннях Intel, AMD, NVIDIA та інших виробників. «Немає єдиного домінуючого технологічного шляху до обчислень класу лідерів; натомість вендори використовують різні підходи на базі CPU, GPU, APU та спеціальних акселераторів», — йдеться в огляді Top500.

Китай часто тримає дизайн своїх суперкомп’ютерів у секреті через урядові обмеження. Однак LineShine розробляли без державного фінансування, тож, за даними The New York Times, його творці вважали, що можуть безперешкодно подати систему на тести Top500. При цьому компанія не розкрила низку деталей, зокрема, який виробник випускає ці CPU та яку саме технологію виготовлення чипів використано.

Джерело

Engadget

Після років випуску «розумних» окулярів під брендами Ray-Ban та Oakley Meta нарешті показала власну лінійку (хоч і досі у співпраці з EssilorLuxottica). Компанія представила три моделі AI-окулярів — Fury, Adventurer та Meta Glasses by Kylie (у деяких місцях їх позначають як Starfire). Перші дві стартують з ціни $299, а варіант, створений у співдизайні із знаменитістю Кайлі Дженнер, коштуватиме $399.

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

Що нового

Спершу базові речі. За словами віцепрезидента Meta з носимих пристроїв Мінга Хуа, нові Meta Glasses «представлені Meta та EssilorLuxottica» і побудовані «на тій самій апаратній платформі, що й наші найпродаваніші AI-окуляри». Тут знову використовується багатомікрофонний масив, просторове аудіо та камери з відео 3K. Водночас компанія «суттєво розширила варіанти стилів, кольорів і матеріалів» — загалом доступно 26 комбінацій. З трьох стилів Meta Adventurer описують як більш «класичні» прямокутні оправи, тоді як Meta Fury мають повнішу, квадратну форму й більше кольорових опцій.

Модель Starfire, що нагадує невеликі овальні оправи, які часто носить Дженнер, доступна в чорному та «черепаховому» кольорах і має декоративний «камінчик» на лінзі (про нього нижче). Усі нові Meta Glasses отримали трирівневе регулювання носових упорів, щоб краще сідати на різні типи обличчя. Як і Ray-Ban Meta, вони оснащені шарнірами з великим кутом відгинання й регульованими завушниками для тих, хто любить, щоб окуляри щільно «обіймали» голову.

Разом із новим «залізом» Meta оновлює й ПЗ для окулярів. Додаток-супутник Meta AI запускатиметься вже з оновленням Muse Spark AI, яке раніше цього року отримали й попередні моделі, — воно має покращити якість відповідей асистента. Компанія також додає 14 нових мов для режиму синхронного перекладу, зокрема мандаринську китайську, корейську, японську, арабську та гінді. Загалом тепер підтримується 20 мов.

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

Модель Kylie / Starfire

Найбільше часу я провела з чорною версією стилю Дженнер, яка дуже нагадує котячі оправи від Gentle Monster, Prada та Chanel. Чесно кажучи, мене здивувало, наскільки форма мені пасувала, і я справді відчувала, ніби трохи приміряла на себе образ Кайлі.

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

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

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

Хоч це й не суто нова фіча, приємно, що тут є регульовані завушники й шарніри з великим кутом відгинання. Я зазвичай не ношу окуляри (зробила LASIK близько 16 років тому), тож погано знайома з усіма проблемами, які мають звичайні користувачі оправ. Але в порівнянні з ранніми (і не дуже ранніми) моделями окулярів із відеозйомкою, нові окуляри Meta виявилися напрочуд зручними для багатогодинного використання.

Ще одна особливість Starfire порівняно з Fury та Adventurer: ви зможете обрати голос Дженнер для ШІ-асистента й усіх озвучених елементів, від інструкцій під час першого налаштування до повідомлень про рівень заряду. У парі, яку я носила більшість сесії, ця опція ще не працювала, але в окремій демозоні для Starfire я спробувала інший екземпляр і можу підтвердити, що зі мною говорив голос, схожий на штучно згенеровану Кайлі. Я наполовину чекала, що він заспіває варіацію на тему її колишнього вірусного «rise and shine», але цього не сталося.

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

Навряд чи це варто сприймати надто серйозно, але за приблизно годину використання батарея Starfire впала з 96 до близько 66 відсотків. Однак робити висновки щодо автономності зарано, поки не буде можливості протестувати фінальні серійні зразки — у демо-сценаріях надмірне споживання енергії можуть спричиняти десятки факторів.

Підтримка нових мов перекладу

Як уже згадувалося, функція перекладу Meta тепер підтримує мандаринську китайську, корейську, японську та ще приблизно 11 мов (на додачу до початкових шести). Я мала коротку розмову з продакт-менеджером Meta Емерсоном Ціном про сичуаньську кухню в Нью-Йорку. Він говорив зі мною мандаринською, окуляри перекладали його слова англійською в мої вуха, а я відповідала англійською. Мої репліки з’являлися на його екрані вже мандаринською, і як людина, що володіє обома мовами, я могла оцінити точність перекладу.

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

Довелося перервати розмову, щоб не зголодніти надто сильно. Це була єдина нова програмна функція Meta, яку я встигла перевірити особисто на заході. «Динамічні фото» я ще не тестувала, але з продемонстрованих Meta прикладів було видно, що ШІ впевнено розпізнає багато об’єктів і сцен.

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

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

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

Та хоча разом із запуском нових AI-окулярів Meta не показала чогось справді проривного, сам підхід до ширшої аудиторії видається вдалим. Окуляри стали більш кастомізованими й доступними в різних стилях, а ще — приблизно на $100–200 дешевшими за актуальні Ray-Ban Meta. Водночас усі нові програмні фічі з’являться й там, а частину ціни ви платите за бренд Ray-Ban. Особисто я пішла з заходу переважно задоволеною новим регульованим носовим упором (який простіше налаштовувати, ніж змінні вставки в Ray-Ban-версії) і трохи одержимою стилем Starfire.

Джерело

Engadget

Anthropic анонсувала Claude Tag (@Claude), який наразі перебуває у статусі research preview і з часом може фактично перебрати на себе роль Slackbot. У компанії описують його як «завжди ввімкненого» Claude з єдиною ідентичністю, до якої можуть звертатися всі учасники каналу в Slack. Кожен у каналі може викликати його, ввівши @Claude, бачити, над чим працює спільний асистент, і підхоплювати розмови з того місця, де їх залишили інші.

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

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

Спочатку Claude Tag буде доступний у режимі research preview у Slack для клієнтів Claude Enterprise та Claude Team, але Anthropic планує розширити його доступність у майбутньому.

Джерело

Engadget

Netflix представила нову гру від команди, яка створила серію Oxenfree. Проєкт має зірковий акторський склад і використовує нестандартні можливості смартфона, щоб зробити занурення максимально глибоким. Хорор називається Unhinged, головну героїню Аву озвучує Зої Кравіц. За сюжетом вона опиняється заблокованою у своєму будинку під час урагану. Але вона там не одна.

Сейді Сінк, відома за «Дивними дивами», грає Клер — подругу Ави, яка живе в будинку навпроти. Клер може бачити, що відбувається в квартирі Ави, і підказувати їй телефоном. Відомий актор відеоігор Трой Бейкер озвучує домоуправителя будинку, де мешкає Ава. Попри зірковий каст, найцікавіше в Unhinged — це те, як студія Night School (перший ігровий розробник, якого купив Netflix) працює з мобільним контролером.

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

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

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

Джерело

Engadget

Марк Цукерберг доручив Meta створити застосунок для ринку прогнозів, повідомляє The New York Times. Експериментальний застосунок має робочу назву Arena і потенційно може конкурувати з платформами на кшталт Polymarket та Kalshi. Де виникають тренди, туди невдовзі приходить Meta.

Інсайдери в компанії стверджують, що це один із головних пріоритетів для Цукерберга та Meta. За їхніми словами, компанія планує нарощувати аудиторію Arena за рахунок свого гігантського користувацького базису у Facebook та Instagram. Polymarket і Kalshi працюють уже понад п’ять років і майже повністю домінують у цій ніші, тож Meta доведеться надолужувати відставання.

За даними The New York Times, Arena, ймовірно, базуватиметься на системі балів, подібній до ігрової, а не на реальних грошах. Якщо це так, виникає питання, для кого саме призначений продукт. Чи зможуть користувачі вигравати, наприклад, стікери або значки? Люди користуються подібними платформами, бо розраховують заробити, роблячи ставки на події – від погоди в Парижі до напівлегального «інсайдерського трейдингу». Значки тут навряд чи стануть мотивацією, тому ті ж інсайдери кажуть, що Meta не відкидає у майбутньому використання справжніх грошей.

Meta вже експериментувала з власними ринками прогнозів. У 2020 році компанія запустила застосунок Forecast, який працював до 2022 року. Він дозволяв користувачам робити прогнози щодо світових подій і також використовував систему балів замість реальних грошей. Проєкт так і не набув популярності.

Це також не перший випадок, коли Meta та Цукерберг запускають сервіси, натхненні успіхом інших гравців. Instagram Stories з’явилися після злету Snapchat, а Facebook Reels — після TikTok. Facebook Dating вийшов на ринок уже після успіху Tinder та інших сервісів знайомств. Threads з’явився значно пізніше за Twitter. Схема зрозуміла.

Джерело

Engadget

Усередині кожного такого кабелю набагато більше складних технологій, ніж здається. Наприклад, Thunderbolt 5 підтримує до 80 Гбіт/с двонаправленої передачі даних і може передавати до 120 Гбіт/с (при одночасному прийомі на швидкості 40 Гбіт/с) у режимі boost. Це достатньо швидко, щоб перекинути 1 ТБ даних за лічені хвилини. Для порівняння, з USB 2.0 цей процес може тривати кілька годин. Попередній стандарт Thunderbolt 4 забезпечує (все ще дуже швидкі) 40 Гбіт/с в обидва боки.

Сертифіковані кабелі Thunderbolt 5 можуть забезпечувати заряджання потужністю до 140 Вт, а деякі підтримують до 240 Вт завдяки USB Power Delivery. Кабелі Thunderbolt 4 зазвичай підтримують до 100 Вт заряджання.

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

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

У порівнянні з цим більшість ваших звичайних USB-C-кабелів — справжні «динозаври». Багато з них підтримують лише швидкість USB 2.0. Навіть USB 3.2 Gen 2 обмежується 10 Гбіт/с. Цього достатньо, щоб передавати документи, музику, фото чи працювати з дисплеєм нижчої роздільної здатності. Thunderbolt же — це «стероїди» для передачі даних та загальної підключуваності.

Thunderbolt 5 може виводити зображення на кілька 8K-дисплеїв або монітори для ігор з надвисокою частотою оновлення (до 540 Гц). Він підтримує DisplayPort 2.1 і PCI Express Gen 4 — останнє є ідеальним для зовнішніх відеокарт (eGPU). Також він чудово підходить для високошвидкісних SSD. І, на відміну від базових кабелів, Thunderbolt дозволяє об’єднувати кілька пристроїв у «ланцюжок» (daisy chain). Частину вартості становить саме ця складна технологія.

Ситуацію ускладнює те, що існує USB4, частково заснований на технологіях Thunderbolt 3. USB4 може досягати 40 Гбіт/с — стільки ж, скільки Thunderbolt 4. А USB4 V2 розганяється до 80 Гбіт/с, як і Thunderbolt 5. У чому ж різниця? Це підводить до наступного моменту.

Thunderbolt контролюється і розвивається компанією Intel. Вона створила цей стандарт разом з Apple, а перший споживчий кабель з’явився у 2011 році. За правилами Intel, кабель не може використовувати назву Thunderbolt або логотип (так, це стилізована блискавка), якщо він не пройшов сувору процедуру сертифікації. Вартість цієї сертифікації закладена в роздрібну ціну.

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

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

Джерело

Engadget

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

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

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

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

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

До моменту публікації компанія не відповіла на додаткові електронні листи щодо інциденту.

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

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

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

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

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

Klue не повідомила, чи мала вона контакт із хакерами та чи планує виконувати їхні вимоги.

Джерело

TechCrunch

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

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

Джерело

Engadget

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

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

Заснований у 2020 році, Aampe розробляє програмне забезпечення, яке призначає окремого ШІ-агента кожному користувачу. Це дає змогу брендам персоналізувати повідомлення, спираючись на індивідуальну поведінку, а не на традиційні сегменти аудиторії та правила кампаній. За словами співзасновника та генерального директора MoEngage Равітеджі Додди, у стартапу понад 30 клієнтів у США, Європі та Азійсько-Тихоокеанському регіоні, а річний регулярний дохід за останній рік виріс на 150%.

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

“Велика частина нашого зростання забезпечується за рахунок переходу корпоративних клієнтів із Salesforce Marketing Cloud та Adobe Experience Cloud”, – сказав Додда.

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

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

Технології Aampe використовують такі бренди, як Swiggy, Grab і Taxfix, деякі з яких також користуються платформою MoEngage для залучення клієнтів.

Придбання відбулося більш як через шість місяців після того, як MoEngage залучила 280 млн доларів завдяки комбінації первинних і вторинних угод. Близько 20 співробітників Aampe перейдуть до штату MoEngage, збільшивши чисельність команди до приблизно 820 людей.

Заснована у 2020 році, Aampe залучила близько 28 млн доларів у трьох інвестиційних раундах. Серед її інвесторів – Peak XV Partners, Z47 і Theory Ventures.

Джерело

TechCrunch

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

Про те, як галузь прийшла до ідеї платформних команд і внутрішніх developer‑порталів, розповідає Роберт Ерез, principal engineer в Octopus Deploy і експерт із CI/CD та систем розгортання. Колись він працював над великими релізами в Skype, а вже понад десятиріччя допомагає різним компаніям будувати процеси доставки ПЗ.

Від «кинути через стіну» до DevOps — і назад

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

Колись типовий процес виглядав просто й жорстко поділено: «In the old days, you’d write a bit of code and you’d throw it over the wall to the ops team… dev teams and ops teams». Розробники писали код, операційники його розгортали. Відповідальність була розділена, зворотний зв’язок — повільний, а конфлікти між «девами» і «опсами» — системними.

DevOps мав це зламати. Ідея була в тому, щоб інженерні команди брали участь не лише у створенні коду, а й у його роботі в продакшені: «you get faster feedback loops… you fix it, you ship it». Команди почали володіти повним циклом: від коміту до продакшену.

Але зі зростанням організацій DevOps у багатьох місцях переродився у знайому тінь старих структур: «As things start to scale up… there would end up being like a DevOps team again… and there’d be this separation of development and DevOps… it kind of goes against some of the principles of what DevOps was trying to destroy». Тобто Dev і Ops знову опинилися по різні боки — цього разу з проміжною «DevOps‑командою».

Коли кожна команда винаходить свій CICD

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

Роберт описує це так: «There was just this this large number of different ways of doing things… and that becomes difficult at scale… you can’t really move between teams». Коли в компанії десятки команд, а в кожної — свій стек інструментів, свої шаблони пайплайнів, свій спосіб параметризувати розгортання, з’являються дві проблеми.

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

До цього додається ще один дискомфорт: більшість розробників не горять бажанням ставати напівадмінами й напів‑build‑інженерами. «Dev teams rarely want to configure the deployment scripts and test them… it’s now a different job». У реальних командах це виглядає так, як згадує Ерeз: у невеликій мобільній команді з п’яти людей «one of us had to kind of specialize in Jenkins configurations», і це часто було більше примусом, ніж покликанням.

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

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

На цьому тлі з’являється й швидко закріплюється нова організаційна модель: платформні команди. «Platform teams are kind of… in the past several years, they’ve become this sort of new standard organizational structure to help teams manage their… deployment workflows.»

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

«Platform teams… more sort of define best practices and they provide a… self-service mechanism where application teams can… use an IDP an internal development portal.» Внутрішній developer‑портал (IDP) стає інтерфейсом між платформою та продуктами. Замість того щоб руками збирати пайплайн, підбирати образи, шаблони конфігурації чи n‑тий раз налаштовувати інтеграції, команда обирає затверджений шаблон, створений платформою, і запускає його в роботу.

Це дає одразу кілька ефектів.

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

По‑друге, зберігається те, що DevOps обіцяв із самого початку: відповідальність за роботу сервісу залишається в продуктової команди. Вони все ще «ship it and fix it», але не з нуля конфігурують Jenkins, GitHub Actions, Kubernetes‑манифести чи що б там не було в конкретній організаційній реальності.

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

Внутрішні портали як інтерфейс платформи

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

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

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

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

Кому взагалі потрібна платформна команда — і коли

Привабливість цієї моделі не означає, що вона універсальна. Ерeз прямо наголошує: «That’s not to say that every company everywhere should have a platform team… if you’re a smaller company… you’ve just got the apps team and they sort of are doing… DevOps.»

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

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

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

І саме в цьому сенсі «platform teams are kind of… this sort of new standard organizational structure». Не тому, що це модний тренд, а тому, що без якогось варіанта платформи великі організації неминуче впадають у DevOps‑хаос із десятками несумісних способів робити одне й те саме — деплоїти код.

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

Історія, яку окреслює Роберт Ерeз, показує еволюцію галузі: від жорсткого поділу Dev/Ops через DevOps‑ентузіазм до більш прагматичної моделі платформи як продукту для внутрішніх користувачів — інженерних команд.

Платформні команди виникли не як теоретична концепція, а як відповідь на дуже практичну проблему: «this large number of different ways of doing things» стає непідйомним у масштабі. Внутрішні developer‑портали й стандартизовані шаблони дають організаціям змогу тримати під контролем безпеку, надійність і швидкість доставки, не забираючи у команд автономію.

Водночас платформа — не панацея й не обов’язкова вимога для кожного стартапу. Для невеликих команд DevOps підхід «ми самі все робимо» залишається цілком працездатним. Але коли організація виростає настільки, що CI/CD і розгортання займають дедалі більшу частину уваги інженерів, які хотіли б писати продукт, а не налаштовувати Jenkins, саме платформа стає тим механізмом, що повертає фокус на бізнес‑цінність, а не на боротьбу з інфраструктурною ентропією.

Джерело

CI/CD with Robert Erez — The Pragmatic Engineer

Новий MiniMax M3 стрімко з’явився в інструментарії розробників як надзвичайно дешевий, але доволі сильний AI‑помічник для коду. Блогер Tech With Tim, який регулярно працює з різними моделями в IDE Cursor, вирішив порівняти MiniMax M3 з Composer 2.5 — своїм звичним “робочим конем” для щоденного програмування. Він прогнав обидві моделі через три різні сценарії: створення вебдодатку з нуля, складний бекенд на Rust і доопрацювання великого продакшн‑коду.

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

Базовий розклад сил: швидкий Composer проти “довгого” MiniMax

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

MiniMax M3, навпаки, одразу показує інший характер. Вбудований у Cursor через сумісний з OpenAI API інтерфейс, він працює помітно повільніше, зате агресивно використовує величезне контекстне вікно, постійно викликає інструменти, аналізує результати й переписує власний код. Це не просто “модель для автодоповнення”, а щось ближче до автономного агента, який спочатку думає, потім багато разів перевіряє, а вже після цього завершує задачу.

Щоб побачити, як це відчувається в реальній розробці, автор “прогнав це через три різні типи промптів… побудова з нуля, системний код і великий рефактор”.

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

Перший тест — класика для AI‑кодера: побудувати URL‑shortener з нуля в одному проєкті на Node.js з API‑ендпоінтами, дашбордом і чистим сучасним UI.

Обидві моделі впоралися із завданням: вебдодаток запускається, посилання скорочуються, кліки рахуються, є світла та темна теми, базова валідація URL. На рівні демо обидва рішення виглядають “готовими”. Але внутрішня картина радикально різна.

MiniMax M3 “реально написав значну кількість коду… в нас тут 21 файл… воно навіть написало повні тести”. Код розбитий на конфігурацію, базу, обробку помилок, різні маршрути, сервіси, утиліти. Файли невеликі, логіка рознесена, до того ж — згенероване тестове покриття для застосунку.

Composer 2.5 підійшов до задачі інакше: “composer дав сім файлів… просто напхав усе в ці файли… не створив гарної структури, як Miniax”. Основна логіка сервера зосереджена в одному великому файлі, стилі — в одному ж великим блоком, база — без додаткової модульності. Жодних тестів, мінімум валідації. Зовні задача виконана, але всередині це радше прототип, ніж каркас продакшн‑додатку.

Ціна структурованості — час. “Miniax зайняв значно більше часу… composer відпрацював приблизно за дві хвилини, а Miniax — десь за 15”. MiniMax спочатку спроєктував код на рівні текстового чернеткового плану, лише потім почав створювати файли, активно відкривав браузер, запускав тести, багато разів викликав інструменти й самокритично правив власні рішення. При цьому він використав лише частину свого гігантського контексту.

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

Системний код на Rust: коли важливий не лише результат, а й шлях до нього

Другий тест вивів моделі з комфортної веб‑зони. Обидві отримали завдання написати трасувальник променів на Rust з нуля, який рендерить сцену з кількома сферами на шаховому полі в PPM‑файл, без залежностей.

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

Зображення, яке породив MiniMax M3, виявилося значно ближчим до очікуваного: правильна орієнтація сцени, логічне розміщення об’єктів, відчуття об’ємності. Воно теж не було ідеальним, але саме розподіл світла, розміщення куль і вигляд поверхні більше відповідали типовому результату трасування променів.

При цьому обсяг коду у двох моделей вийшов приблизно подібний — кілька файлів, відносно чиста структура. MiniMax додавав більше коментарів та пояснень, Composer — майже нічого не коментував. Головна відмінність знову ж таки в процесі: “було схоже, як і раніше: composer відпрацював значно швидше, але не дав нам такої хорошої віддачі, а Miniax працював набагато довше, але дав щось значно більш придатне”.

Саме тут особливо помітно, як “з тим, як MiniAAX спроєктований, він реально розрахований на довготривалі завдання… повністю використовує контекстне вікно, робить багато аналізу”. У ланцюжку повідомлень MiniMax видно довгу низку кроків, проміжних міркувань і корекцій. Composer натомість поводиться як класичний код‑генератор: бере промпт, обчислює найвірогідніший шаблон коду, виводить і зупиняється.

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

Великий продакшн‑код: хто краще “вбудовується” в існуючий проєкт

Третій сценарій наближений до того, з чим розробник стикається в реальній роботі: не зелений field‑проєкт, а складний, уже існуючий продукт з бекендом на Python, великим фронтендом на TypeScript і чималою кількістю неідеального, “живого” коду.

Завданням було додати нову фічу — “daily streak” для студентського дашборду. Система мала відстежувати, скільки поспіль днів студент розв’язав хоча б одне DSA‑завдання, з відповідними бекенд‑ендпоінтами, сервісною логікою та UI‑компонентами. Тобто моделі мали спочатку розібратися в архітектурі, потім обережно увійти в наявні файли, додати нові, не поламавши те, що вже працює.

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

В UI від Composer з’явився новий компонент для streak, однак змін небагато: один основний блок, прості інтеграції, менше тестів і коментарів. MiniMax, за спостереженнями автора, змінив більше частин системи, додав розлогіший код, детальніші коментарі та тести, зробивши функцію більш органічною частиною продукту. У студентському дашборді, згенерованому MiniMax, з’явився, наприклад, показник “best streak” — ознака того, що модель не просто додала лічильник, а спробувала розширити саму концепцію функції.

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

Висновок: дві філософії AI‑кодування — і коли яку обирати

Непряме порівняння MiniMax M3 і Composer 2.5 в трьох сценаріях задає зрозумілу рамку для розробників, які підбирають собі AI‑модель в IDE.

Composer 2.5 — це про швидкість та “досить добре” рішення. Він миттєво відповідає, видає робочий код, не обтяжує себе зайвою структурою, валідацією чи тестами. Для невеликих завдань, експериментів, чернеток і задач, де людина планує одразу вручну переробити код, це зручний інструмент.

MiniMax M3 будує іншу цінність. Він охоче витрачає час і токени на роздуми: проєктує структуру, пише тести, переглядає власні рішення, повноцінно використовує велике контекстне вікно й активно працює з інструментами. З відносно простої задачі URL‑shortener він робить невеликий, але вже схожий на продакшн‑додаток; на Rust‑тестах видає якісніший результат, а в реальному репозиторії поводиться як уважний колега, а не просто автогенератор.

На фінальному етапі автор підсумовує: модель “дуже продуктивна. Це не найшвидша модель у світі”, але завдяки такій архітектурі та великим лімітам вона добре працює саме на довготривалих завданнях, де треба аналізувати великі обсяги коду й не боятися лімітів. “З тим, як MiniAAX спроєктований, він реально розрахований на довготривалі завдання… повністю використовує контекстне вікно, робить багато аналізу”.

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

Джерело

YouTube: I Built the Same App With MiniMax M3 and Composer

У подкасті «УТ‑2» розробники й ведучі Саня, Ілля та Юрко обговорюють одну з найяскравіших нинішніх фігур в open‑source — Мітчелла Хашімото. Співзасновник HashiCorp, який пішов з операційки й тепер розважається «інженерними іграшками рівня мільярдера», паралельно будує новий термінал Ghostty і фінансує мову Zig. Обидва проєкти опинилися в центрі дискусій про те, як співіснувати з AI‑кодом і вайп‑кодингом, не перетворюючи core‑репозиторії на смітник з автогенерованих PR.

Термінал мільярдера і заборона на PR від ботів

Хашімото робить Ghostty у складі свого нового проєкту Agent MD і демонстративно вбудовує в нього власну етику роботи з AI. Ведучі описують це сухо й з помітною симпатією: у терміналі прямо зашито правило для інтегрованих ботів і асистентів:

«В терміналі, який він робить… написано: “Ніколи не роби, не відкривай issue, ніколи не відкривай PR’ів”».

Це не дрібна стилістична примха, а технічне обмеження: якщо користувач все ж просить модель створити issue чи pull request у Ghostty, термінал змушує бота зробити окремий файл із чітким маркуванням:

«Якщо користувач попросив тебе відкрити issue або PR, зроби файлік, в якому напиши: “Я топорилий бот, будь ласка, не приймайте цей PR”».

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

Для Хашімото це спосіб захистити себе й проєкт від безвідповідального вайп‑кодингу: Ghostty влаштований так, аби AI‑асистенту було незручно й соромно лізти в core‑репозиторій напряму.

«Перечитай, що ти там наробив»: відповідальність залишається на людині

У подкасті акцентують, що Мітчелл не бореться з самою ідеєю використання AI. Навпаки, він активно ним користується:

«Тема в тому, що він же ж не луддит, він користується AI… його поінт не в тому, що не можна користуватися AI’єм… але будь ласка, перед тим, як присилати код, подивись, що ти там [__]».

Тут важливий саме «reasoning», як його переказують ведучі:

«Його reasoning, чого він так робить: “Ну, людина ж відповідальна за те, що вона присилає, правильно? Нехай перечитає і розбереться, що там вообще нароблено. Не треба оце attended гамно”».

У перекладеній на програмістську мову етиці це виглядає так:

• AI може допомагати писати код, розбиратися в чужих змінах, пояснювати нетривіальні місця.
• Але момент, коли патч летить у публічний issue чи PR, має проходити через людську голову та очі.
• Мейнтейнер не зобов’язаний розгрібати «неосмислені» автогенеровані патчі. Той, хто тисне «Create PR», відповідає за вміст так само, як і десять років тому без AI.

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

$400 000 для Zig: підтримка радикально консервативної спільноти

Паралельно Мітчелл з’явився в новинах ще раз — уже як донор. Ведучі згадують:

«Ще одна новина про нього… він задонейтив 400 000 баксів в Zig Software Foundation на користь Zig».

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

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

Тобто мейнтейнерів Zig влаштовує, що розробник може в побуті користуватися будь‑якими моделями, вайп‑кодити скільки завгодно, але:

• AI‑генерований код не повинен потрапляти в core‑репозиторій Zig.
• Рішення, дизайн, API й реалізація — сфера людського контролю й відповідальності.

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

«Хтось його спитав: “А що ж за AI’єм?” А він каже: “Те, що у нас розходяться погляди на те, як тим треба користуватися чи не треба, не значить, що вони чимось гірші… вони роблять ахуєнну штуку”».

Таким чином, пожертва в Zig Software Foundation виглядає не як ідеологічна заява проти AI, а радше як підтримка альтернативної школи мислення. З одного боку — Ghostty, де AI‑асистент присутній, але жорстко обмежений у правах; з іншого — Zig, де AI фактично не допускають до ядра проєкту, але не намагаються заборонити його в житті розробників.

Zig як мова без AI‑ядра і з дорогим правом на помилку

У подкасті окремо згадують, що погляди Zig‑спільноти щодо AI справді «радикальні». Це мова, яка свідомо ламає зворотну сумісність новими релізами, активно переписує великі шматки інфраструктури (від компілятора до лінкера) і не ховає це за стабільними API.

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

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

Чи означає це, що Zig перестає бути «радикальним» у своїй політиці? Ні. Спільнота й далі не хоче бачити прямий AI‑код у core, і це чітко артикулюється. Але той факт, що більшість розробників Zig користується LLM у власних проєктах, а сам Мітчелл фінансує мову, демонструє куди складнішу картину, ніж простий поділ на «лудитів» і «AI‑евангелістів».

Гібридний курс open‑source: AI поруч, але не замість

І Ghostty, і Zig у цій розмові стають індикаторами ширшого тренду. Лідери open‑source не заперечують корисність моделей, але намагаються продумати технічні й соціальні запобіжники:

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

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

Для розробників це означає просту, але неприємну істину: ера «натисну кнопку — і хай модель сама відправить PR» у серйозних open‑source‑проєктах навряд чи настане. І Ghostty, і Zig задають інший стандарт: AI може бути поряд, але відповідати за код, який потрапляє в публічний репозиторій, усе ще доведеться самому.

Джерело

YouTube: «Вбивця МРТ за хвилину, Ferrari не для гонок і Steam, який лізе на твій ПК. mvc #31»

Італійська Bending Spoons роками лишалась у тіні власних брендів. На слуху — Evernote, Wetransfer чи Vimeo, але не та команда, яка стоїть за їхнім перезапуском. У подкасті «УТ‑2» ведучі згадують цю компанію не вперше, а зараз повертаються до неї з приводу новини: італійці готуються до IPO й орієнтуються на оцінку близько 1,6 млрд доларів.

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

Як працює «італійська контора, яка скуповує бізнеси»

На «УТ‑2» Bending Spoons згадують як «італійську контору, яка скуповує бізнеси і намагається їх робити ефективними». Це, по суті, фабрика реструктуризації SaaS‑продуктів.

За словами ведучих, у Bending Spoons немає одного універсального сценарію — є кілька підходів, які застосовують залежно від стану активу.

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

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

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

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

IPO з прицілом на 1,6 млрд: навіщо стільки оптимізації

Тепер ця модель виходить на публічний ринок. Bending Spoons «збираються виходити на IPO, шукають… ціляться в оцінку 1,6 млрд доларів». На фоні історій про стартапи без прибутку, які виходять на біржу лише з обіцянками зростання, італійці виглядають майже старомодно.

Ведучі звертають увагу: під підготовку до розміщення в компанії «наводили порядок у портфелі». Якщо в минулому році Bending Spoons були збиткові, то нині — уже в плюсі. Цифри, які згадуються в ефірі: «за 24‑й рік у них плюс 89 млн, а за 25‑й мінус 200 000 баксів».

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

Для IPO це важливий наратив: Bending Spoons іде на біржу не як черговий збитковий «growth story», а як компанія з прибутком і чіткою дисципліною витрат.

Evernote, AOL, Wetransfer, Vimeo: що саме купують і як змінюють

Частина інтересу до Bending Spoons — у списку брендів, які вона встигає поглинути. На «УТ‑2» перелік звучить доволі вражаюче:

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

Тобто в портфелі Bending Spoons опиняються сервіси, які були меседжерами епохи (AOL), робочими інструментами для мільйонів (Evernote), великими файлами для креативників (Wetransfer) та відеоплатформою для професіоналів (Vimeo). Всі вони — продукти пізньої Web 2.0, зі сформованою базою користувачів, але без колишнього хайпу.

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

Vimeo у розмові називають першим «інфраструктурно-затратним бізнесом» Bending Spoons — це крок із зовсім іншого масштабу відповідальності: відеохостинг із глобальною аудиторією, великими рахунками за зберігання та доставку контенту. Разом із Wetransfer і AOL це формує вже не набір нішевих застосунків, а цілу екосистему хмарних сервісів, які треба вміти підтримувати дешево й стабільно.

«Експлуатуєте італійських розробників по 1500 євро»: темний бік ефективності

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

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

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

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

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

Що з цього варто винести українським продуктам і dev‑ам

Для українських команд історія Bending Spoons може бути уроком у кількох напрямках.

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

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

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

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

Висновок: імперія з «чужих» продуктів

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

Звідси й подвійний образ: для користувачів і колишніх команд це може виглядати як цинічна експлуатація «старих імен», для інвесторів — як дуже раціональна машина створення cash‑flow. Оцінка в 1,6 млрд доларів на IPO покаже, наскільки ринок вірить у цю модель.

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

Джерело

Вбивця МРТ за хвилину, Ferrari не для гонок і Steam, який лізе на твій ПК. mvc #31