Смертельна аварія у вихідні, коли електромобіль Tesla протаранив цегляний будинок у місті Кейті, штат Техас, убивши 76-річну жінку, знову викликала занепокоєння щодо фірмових систем допомоги водієві компанії. Уже до понеділка вдень Tesla почала публічно спростовувати таке трактування подій.

Аварія сталася в п’ятницю ввечері, коли Tesla Model 3 під керуванням Майкла Батлера з’їхала з дороги та влетіла в будинок Марти Авіли. Жінку доправили гелікоптером до лікарні, де вона згодом померла. Батлер повідомив заступникам шерифа округу Гарріс, що на момент аварії автомобіль їхав у режимі Autopilot. Ця деталь швидко розійшлася в медіа, і вже до вихідних історія стала черговим епізодом у тривалій дискусії навколо систем Autopilot та Full Self-Driving (Supervised) від Tesla.

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

Ашок Елусвамі, віцепрезидент Tesla з розробки ПЗ на базі ШІ та перший інженер, найнятий у команду Autopilot ще у 2014 році, опублікував у X (колишній Twitter) зовсім іншу версію подій, спираючись на дані автомобіля. «У цьому випадку водій вручну перевів авто з режиму самокерування, натиснувши педаль акселератора до 100% у житловому районі», — написав він. — «На момент зіткнення автомобіль розігнався до 73 миль/год (понад 115 км/год), а педаль газу залишалася натиснутою навіть після удару».

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

Ілон Маск невдовзі підсилив тезу Елусвамі у власному акаунті в X. «Це звинувачення не має сенсу. FSD їде повільно в житлових кварталах, а тут сталася аварія на великій швидкості!» — написав він.

У січні Tesla припинила використання назви Autopilot для своєї базової системи допомоги водієві після рішення суду в Каліфорнії, який визнав цю назву такою, що вводить споживачів в оману. Система Full Self-Driving (Supervised), доступна за підпискою $99 на місяць, може виконувати маневри на кшталт навігації маршрутом, кермування, зміни смуг і паркування, але все одно вимагає від водія постійного активного нагляду.

Попри заяви компанії, федеральні регулятори налаштовані дійти власних висновків. Національна адміністрація безпеки дорожнього руху США (NHTSA) у понеділок підтвердила TechCrunch, що відкриває спеціальне розслідування цієї аварії. За повідомленнями, це вже понад сороковий подібний кейс, який відомство досліджує у зв’язку з можливим використанням розширених систем допомоги водієві в автомобілях Tesla за останні роки.

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

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

Джерело

TechCrunch

OpenAI у понеділок оголосила про нову ініціативу, спрямовану на допомогу спільноті open source в підвищенні рівня кібербезпеки та боротьбі з багами.

Програма Patch the Planet (прозорий натяк на «Hack the Planet» — культову фразу з фільму 1995 року «Хакери») передбачає співпрацю OpenAI з компанією з кібербезпеки Trail of Bits для допомоги мейнтейнерам відкритих проєктів у захисті їхнього коду.

За словами OpenAI, фахівці з безпеки Trail of Bits працюватимуть безпосередньо з мейнтейнерами open source, щоб переглядати потенційні проблеми в коді. У процесі будуть задіяні інструменти безпеки OpenAI — зокрема Codex Security.

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

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

Open source-проєкти є цифровим фундаментом, на якому тримається індустрія комерційного ПЗ. Водночас через децентралізовану та слабо контрольовану структуру цієї екосистеми значна частина такого ПЗ лишається вразливою. Баги в open source-проєктах можуть переростати у великі проблеми для комерційних кодових баз. Прикладом є історія з log4j кількарічної давнини, коли серйозна вразливість була виявлена в широко використовуваній утиліті з відкритим кодом.

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

OpenAI намагається перевернути цю логіку, застосовуючи ШІ для допомоги спільноті open source краще захищати себе. Це важко не сприймати як конкурентний випад у бік Anthropic, але водночас очевидно, що таким інструментам open source-спільнота гостро потребує.

Джерело

TechCrunch

У новому епізоді подкасту Confluent Developer провідний інженер Confluent і учасник PMC Apache Kafka Ендрю Скофілд говорить не лише про черги чи окремі фічі, а про те, як сьогодні живе й змінюється сам проєкт Kafka. Зсередини спільноти він бачить масштаб контриб’юторів, динаміку складних KIP-ів (Kafka Improvement Proposal), суперечки довкола multi‑tenancy та загальну мету — зробити Kafka більш загального призначення.

155 людей над одним релізом: як виглядає масштаб спільноти Kafka

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

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

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

Як проходить KIP: мінімум три голоси й пошук «дірок» у дизайні

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

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

Той, хто голосує за KIP, не просто читає текст — він активно шукає «дірки». Скофілд описує це як перевірку на те, «чого ви не сказали». Чи є незакриті сценарії відмов? Чи визначено поведінку при крешах? Як це працюватиме при оновленнях?

Характерний приклад з обговоренням Diskless Kafka: одна з критичних тем — як надійно збирати сміття (garbage collection) в об’єктному сховищі. Дані з брокера потрапляють у cloud storage блоками, які потім позначаються координатами. Якщо посеред цього процесу брокер падає, у системі можуть з’явитися «загублені» об’єкти. Виявити й коректно прибрати їх — нетривіальна задача, яка повинна бути чітко описана ще на рівні KIP-а, задовго до того, як код потрапить у main.

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

KIP-и з «колективним авторством»: коли один вендор — замало

В Apache Kafka традиційно чимало KIP-ів мають одного автора. На цьому тлі деякі нові ініціативи виділяються масштабом співробітництва.

Скофілд звертає увагу на KIP, в якому відразу шість авторів — рідкісна ситуація для проєкту. Йдеться про проєкт cluster mirroring (новий вбудований механізм disaster recovery) — приклад того, як кілька вендорів і користувачів із різних сторін узгоджують дизайн складної, багаторелізної функції.

Схожа історія й з Diskless Kafka. Тут перший, фундаментальний KIP‑1150 уже пройшов голосування, причому з дев’ятьма голосами committers — суттєво більше мінімально необхідних трьох. Такий результат означає не просто формальний кворум, а широку підтримку ідеї з боку різних учасників екосистеми: спільнота фактично сказала, що хоче саме такого напрямку руху.

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

Multi-tenancy: усі розуміють, що воно буде, але не як саме

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

При цьому скепсис стосується не самої ідеї multi‑tenancy, а поточного формату її реалізації. Скофілд прямо говорить, що майбутнє Apache Kafka майже напевно включатиме multi‑tenancy. Однак він не впевнений, що саме теперішній KIP у нинішньому вигляді стане тією реалізацією, яка врешті-решт буде прийнята. Можливо, документ еволюціонує, переформулюється, розіб’ється на кілька, змінить модель — це попереду.

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

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

«Зробити Kafka більш загального призначення»: що за цим стоїть

Якщо піднятися над конкретними ініціативами — Diskless Kafka, cluster mirroring, multi‑tenancy — простежується спільний вектор. Скофілд формулює його як прагнення зробити Kafka більш general purpose.

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

У цьому контексті:

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

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

Висновок: повільні дискусії, швидкі зрушення

Картина, яку описує Ендрю Скофілд, не виглядає як «мовчазна еволюція» ядра Kafka. Це радше постійний діалог між кількома спільнотами одночасно: великими внутрішніми користувачами, комерційними постачальниками, мейнтейнерами та авторами KIP-ів.

Частина ініціатив іде швидко — як cluster mirroring, що за місяць від публікації KIP-а вийшов на стадію «готового до серйозного аудиту» дизайну. Інші, як multi‑tenancy, буксують у дискусіях, але при цьому мають майже гарантоване майбутнє в якомусь оновленому вигляді.

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

Джерело

155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield | Ep. 34 | Confluent Developer

Apache Kafka продовжує еволюціонувати під тиском хмарної економіки. Один із найпомітніших напрямків зараз — ініціатива Diskless Kafka, яку в спільноті веде компанія Aiven. Про неї детально говорить Ендрю Скофілд, principal engineer у Confluent і учасник PMC Apache Kafka, у розмові про те, куди рухається проєкт.

Йдеться не про окрему фічу, а про цілу сім’ю KIP‑ів, що радикально переосмислюють зберігання даних у Kafka: відмову від локальних дисків брокерів на користь об’єктного хмарного сховища та зміну моделі реплікації заради економії на мережі.

Чому Kafka в хмарі виявилася дорогою

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

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

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

Diskless Kafka з’являється як відповідь саме на цей клас проблем.

Ідея Diskless: об’єктне сховище замість локальних дисків

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

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

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

Технічно в Diskless Kafka брокер накопичує дані й пакетно вивантажує їх в object storage, зберігаючи «хендл» — координати партії в об’єктному сховищі. У KIP‑ах це описується як batch coordinates, тобто вказівник на блок записів. Локальне сховище при цьому перестає бути довгостроковим джерелом істини.

Сімейство KIP‑ів замість одного «магічного» дизайну

На відміну від деяких попередніх великих змін у Kafka, Diskless одразу замислюється як сімейство KIP‑ів, а не як один монолітний KIP зі слідом із десятків доповнень.

Скофілд нагадує історію з KIP‑500 (CRAFT): тоді було опубліковано досить загальний KIP, який проголошував мету — замінити ZooKeeper власним консенсус-протоколом, але не давав усіх деталей. Потім роками з’являлися супутні KIP‑и, а обговорення розтягнулося на тривалий період.

У випадку Diskless підхід інший. Уже сьогодні це позиціонується як «family of KIPs». Перший з них, KIP‑1150, пройшов голосування і отримав схвалення спільноти як фундаментальний. Скофілд підкреслює, що підтримка була незвично широкою: на дискусійному треді було дев’ять голосів від коміттерів, значно більше мінімально необхідних трьох. Це сигнал про те, що ідея Diskless викликає консенсус серед різних вендорів та учасників проєкту.

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

Важливо й те, що до моменту, поки ці KIP‑и не будуть затверджені, жоден рядок коду Diskless не потрапить до Apache Kafka. Спочатку — узгоджений дизайн у відкритому процесі, потім реалізація. Це класична для Kafka модель: публічна дискусія, скрупульозна перевірка, потім багаторелізна реалізація.

Головний виклик: як збирати сміття в об’єктному сховищі

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

У Diskless-сценарії брокер накопичує дані й час від часу пакує їх у великі об’єкти в storage. Далі Kafka оперує не окремими файлами на локальному диску, а координатами цих батчів в об’єктному сховищі. Проблема починається там, де вступає в гру реальний світ: збої, падіння процесів, неповні операції.

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

Саме тому питання надійної «garbage collection» для хмарного сховища стало одним із ключових сюжетів у Diskless‑KIP‑ах. Треба дати відповідь на запитання: як, не покладаючись на ручні інструменти адміністрування, надійно виявляти й прибирати такі осиротілі об’єкти, щоб не накопичувати приховане сміття й не платити за нього роками.

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

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

Багаторелізна еволюція, а не «великий вибух»

І Diskless, і нещодавні великі зміни в Kafka демонструють спільний підхід: великі функціональні блоки впроваджуються через кілька мажорних релізів із чіткою поетапною стратегією. Скофілд згадує черги для Kafka як приклад: там теж був великий базовий KIP, а потім у наступних версіях з’являлися додаткові KIP‑и, які закривали конфігураційні прогалини або уточнювали поведінку.

Те саме очікується й від Diskless: спочатку фундамент (KIP‑1150), потім ще кілька великих технічних KIP‑ів, згодом — дрібніші доповнення. При цьому кожен крок супроводжуватиметься ретельним рецензуванням, де, за словами Скофілда, головний фокус — не стільки на тому, що добре виписано, скільки на тому, «чого не сказали». Особливо це стосується відмовостійкості та управління станом при збоях.

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

Висновки: дорожня карта для «бездіскової» Kafka

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

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

Скофілд однозначно розглядає Diskless як великий, багаторелізний проєкт. Його успіх залежатиме не лише від дизайну KIP‑ів, а й від того, наскільки рано і ретельно спільнота «прожує» всі складні кути — від моделі реплікації до garbage collection у хмарі.

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

Джерело

Confluent Developer Podcast — 155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield

Apache Kafka традиційно сприймається як платформа для стримінгу подій, а не як класична система черг. Але з виходом Apache Kafka 4.2 у проєкті з’явилася можливість, яка суттєво наближає Kafka до повноцінної моделі черг — без введення нового примітиву «queue». Про те, як до цього прийшли й що саме змінилося, розповів Andrew Schofield, principal engineer у Confluent та коммітер/PMC-учасник Apache Kafka, у розмові на подкасті Confluent Developer.

Коли Kafka намагалися використовувати як чергу — і чому це боліло

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

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

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

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

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

Чому рішенням став не новий тип «queue», а новий тип групи

Поворотним моментом у роботі Andrew над Queues for Kafka став концептуальний вибір: не винаходити у Kafka новий об’єкт «черга».

Розглядався різний досвід і різні API, зокрема традиційні JMS-підходи, проводилися експерименти. Зрештою висновок був радикально простим: усе має лишитися навколо тем. Дані вже організовані в topics, саме на них спираються схеми, Kafka Connect та інші інструменти. Ламати цю парадигму заради окремого примітиву «queue» означало б ламати екосистему.

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

Центральне запитання, яке довелося собі поставити: «Що є сутністю черги, якщо не оголошувати її окремим типом об’єкта?» Відповідь сформувалася навколо двох ключових вимог до API.

По-перше, потрібна поведінка «record-at-a-time», тобто сталі, чіткі операції над окремими записами. Пакетна обробка не заборонена, але система зобов’язана дозволяти консюмеру мислити окремими повідомленнями, а не лише послідовністю офсетів.

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

Саме тут проявляється фундаментальна проблема старої моделі consumer group у ролі черги. Традиційно консюмер «комітить офсет» — фіксує позицію, з якої він продовжить читання. Якщо намагатися перетворити цей механізм на аналог per-message ack, доводиться комітити для кожного окремого запису. Andrew підкреслює: це не те, заради чого спочатку проєктували consumer groups, і в режимі черги це відчувається як незручність та обмеження.

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

Три етапи запуску: від early access до GA в AK 4.2

Щоб таке глибоке перетворення моделі споживання не зламало екосистему, Kafka-спільнота пішла на поетапну поставку. Andrew описує Queues for Kafka як «трьохетапну доставку».

Перший етап — early access у версії 4.0. Це був старт для найперших користувачів та розробників, які могли спробувати новий тип групи, відчути семантику роботи «як черга» та дати зворотний зв’язок ще до формалізації інтерфейсу.

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

Третій етап — general availability (GA) у Apache Kafka 4.2. Саме із цієї версії Queues for Kafka офіційно вважаються загальнодоступними: AK 4.2 «has GA of queues». На цей момент основні прогалини в поведінці були закриті, а архітектурні рішення усталені, зокрема й завдяки кільком додатковим KIP-ам, що виплили вже з досвіду реалізації первісної специфікації KIP‑932.

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

Dead-letter черги: відповідь на «отруйні» повідомлення в 4.4

Однак навіть із GA-підтримкою черг у 4.2 залишилася проблема, яку користувачі називали однією з головних: що робити з повідомленнями, які не вдається обробити?

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

Рішення «забрати» проблемний запис із шляху споживача знімає блокування, але відкриває інше питання: як його потім знайти і розібратися, що пішло не так? Саме тут з’являється наступний великий крок у розвитку черг — dead-letter queues.

Andrew описує це як наступну важливу фічу, яку планують доставити в Kafka 4.4. Над нею уже ведеться інженерна робота, є затверджений KIP, але в реліз 4.3 вона не встигає.

Dead-letter queues запропонують відповідь на запит «чорної скриньки» для помилкових повідомлень. Механіка, яку окреслює Andrew, проста: якщо повідомлення не вдалося доставити успішно, воно копіюється в окрему тему — dead letter queue topic. Цю тему можна розглядати як журнал усіх невдач, куди оператор або інший сервіс може заглянути, щоб дослідити проблеми, перезапустити обробку чи зробити додаткові перетворення.

Таким чином, AK 4.2 розв’язує базову задачу «чергового» споживання з явною долею кожного запису, а AK 4.4 має принести повноцінну модель роботи з помилками, якої користувачі очікували з самого початку.

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

Queues for Kafka змінюють не тільки можливості самої платформи, а й роль розробників, які будували «чергову» поведінку самотужки. Там, де раніше доводилося конструювати складні надбудови поверх стандартних consumer groups — перехоплювати винятки, крутити власні лічильники повторних спроб, організовувати обхід «отруйних» повідомлень, — тепер більша частина логіки переходить у Kafka.

Shared groups і новий API дають змогу мислити кожним записом окремо, не спираючись на грубий механізм offset commit як універсальний важіль керування. Система сама координує state-machine для кожного повідомлення, знімаючи з розробників частину відповідальності за «ручне» моделювання черги.

Поетапне введення можливостей — від early access у 4.0 до GA в 4.2 і dead-letter черг у 4.4 — показує також, як у Kafka намагаються балансувати між еволюцією та сумісністю. Черги тут не як окремий світ, а як ще один спосіб працювати з уже знайомими topics. У цьому й полягає сутність обраного підходу: замість ламати базові примітиви, проєкт додає новий режим їх використання.

Висновок

Queues for Kafka роблять Apache Kafka ближчою до класичних систем повідомлень, але без відмови від її логової природи. Новий тип групи споживачів, можливість задавати долю кожного запису і плановані dead-letter черги у версії 4.4 поступово закривають прогалини, через які раніше доводилося будувати складні власні рішення поверх брокера.

AK 4.2 уже приносить GA-підтримку черг, а наступні релізи мають добудувати навколо неї повноцінну екосистему інструментів для роботи з помилками і складними сценаріями обробки. Для Kafka це не просто ще одна фіча, а новий спосіб думати про те, які саме задачі платформа може брати на себе «рідним» способом.

Джерело

155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield | Confluent Developer

Штучний інтелект у розробці ПЗ обіцяє блискавичне написання коду, але очікуваний «10x приріст продуктивності» так і не настає. Канал IBM Technology розбирає, чому одних лише AI‑кодерів замало, і як реальні виграші з’являються лише тоді, коли переосмислити весь життєвий цикл розробки (SDLC), а не окрему його фазу.

Швидший код, повільніший продукт

Поширене уявлення: якщо модель пише код у кілька разів швидше, то й продукт виходитиме швидше. Проте контрольне дослідження на open source‑розробниках показало інше: ті, хто вважав себе на 20% продуктивнішими завдяки AI‑інструментам, насправді стали приблизно на 20% повільнішими.

Причина — в тому, як організовано типовий SDLC:

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

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

• очікування, поки продакт підтвердить чи уточнить вимоги;
• затримки між девелопментом, QA та операційними командами;
• розсинхрон серед інструментів і середовищ (dev, staging, prod).

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

Пастки «переделегування» та «недоделегування» ШІ

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

1. Надмірна делегація: «збудуй мені маркетплейс»

Один із підходів — передати великій моделі розмитий запит: «створи e‑commerce платформу», сподіваючись на автономний прохід через увесь SDLC.

Проблеми очевидні:

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

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

2. Недостатня делегація: «ШІ, напиши мені одну функцію»

Протилежний полюс — коли старший інженер робить майже всю інтелектуальну роботу сам:

• самостійно продумує архітектуру;
• власноруч дробить задачу на дрібні таски;
• використовує ШІ тільки точково: «напиши цю функцію», «перевір на SQL‑ін’єкції».

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

SDLC, спроєктований навколо ШІ

Справжні зміни з’являються, коли не «прикручують» ШІ до старого процесу, а перебудовують сам SDLC під роботу з агентами.

Інтелектуальні вимоги й дизайн

На ранніх етапах в організаціях накопичується масив неструктурованих даних:

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

AI‑агенти можуть:

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

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

Spec‑driven development та малі задачі для агентів

Під час кодування ключовим стає не general‑запит на «створи мені систему», а робота зі специфікаціями:

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

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

Додаткову роль відіграють механізми на кшталт agents.markdown та навичок (skills), які:

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

Тестування: від ручних сценаріїв до генерації даних

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

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

Так зменшується час між виявленням збоїв і їх усуненням.

Релізи, експлуатація та модернізація легасі

У фазі розгортання та підтримки ШІ вже вміє працювати з інфраструктурою як кодом:

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

Окремий кейс — модернізація легасі‑систем:

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

Роль розробника змінюється, метрики теж

Ключовий висновок: приріст продуктивності дає не «кращий кодер‑бот», а перерозподіл ролей у SDLC.

• Людина менше «друкує» код, а більше валідуює, ставить запитання, формує специфікації й координує роботу команд.
• ШІ знижує тертя між фазами SDLC — там, де раніше були паузи між продактом, девом, QA та операціями.
• Змінюються метрики успіху: важливими стають не «рядки коду», а:
• здоров’я системи (стабільність, інциденти);
• підтримуваність і складність коду;
• час внесення змін і доставки нових фіч.

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

Джерело

AI in the SDLC: Rethinking AI Coding Tools & AI Agents — IBM Technology

Нову модель MiniMax M3 нині активно тестують розробники, насамперед як дешевшу альтернативу топовим AI-моделям для кодування. Автор каналу Tech With Tim прогнав її через кілька практичних задач у середовищі Cursor — від вебдодатку до роботи з великою кодовою базою. Окремий, найбільш нетривіальний експеримент стосувався написання трасувальника променів на Rust — завдання далеко за межами звичного для моделей веб‑стека.

Незручне завдання: трасувальник променів без залежностей

Другий тест у відео принципово відрізнявся від класичних «зроби мені вебапку». Мета була навмисно амбітною: змусити модель написати ray tracer на Rust з нуля. Умови — без зовнішніх залежностей, із виводом результату у форматі PPM і рендерингом сцени з чотирьох-п’яти сфер на картатій підлозі.

Сам промпт для задачі був згенерований іншим AI, про що автор прямо говорить як про «повний disclosure» — йому важливіше було не сам формулювання, а перевірка того, «що ці моделі можуть» у такому класі задач. Далі однакове завдання отримали дві моделі: MiniMax M3 та Composer 2.5, які працювали в окремих вікнах Cursor на чистому контексті.

Це одразу зміщує акцент з традиційних веб-прикладів на більш «системне» програмування. Rust у ролику прямо названий «more challenging language», а сам ray tracing — очевидно складнішим, ніж типовий CRUD або простий API.

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

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

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

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

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

Як виглядав код: Rust без магії, але з різним підходом

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

Різниця виявилася не в кількості, а в якості організації. У версії MiniMax M3 файли описуються як «відносно чисті» та «гарно прокоментовані». Код не надто роздутий, коментарі пояснюють логіку, а структура виглядає акуратною.

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

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

Межа можливостей: обидві моделі виходять за межі «простих веб‑тасків»

Попри те що MiniMax M3 у цьому тесті виглядає переконливішою, розрив не виглядає як «програш у нуль» для Composer. Автор окремо наголошує, що «обидві моделі здатні на щось складніше з Rust», і це важливо в контексті первинної гіпотези: більшість моделей сильні саме у веб‑розробці, але «suck at anything else».

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

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

Довші рани, глибший аналіз

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

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

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

Висновки: Rust‑тест як індикатор глибини моделі

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

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

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

На фоні цього тесту загальний висновок звучить стримано, але показово: обидві моделі «capable of something a little bit more complicated using Rust», але MiniMax M3 у таких завданнях дає «overall a higher quality, better result». Для розробників, які дивляться на AI‑інструменти не лише як на генератор шаблонних вебдодатків, це важливий сигнал про реальну глибину моделі.

Джерело

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

Серед розробників, які активно використовують AI-IDE, з’явився новий сценарій економії: залишити звичний інструмент — але замінити дорогу модель на дешевшу без зміни робочого процесу. Саме це демонструє автор каналу Tech With Tim у свіжому експерименті з моделлю MiniMax M3, яку він інтегрує в Cursor замість стандартного OpenAI API.

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

Чому взагалі варто запускати MiniMax M3 в Cursor

Автор одразу пояснює, чому обирає саме Cursor як полігон для тестів MiniMax M3. На його думку, Cursor — найкраще місце для «сирих» coding tasks, тому що їхній coding harness він вважає найкращим на ринку. У практиці це означає, що інструмент добре працює з багатокроковими завданнями, інтегрованими тулколами та складними сценаріями генерації й перевірки коду.

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

По‑перше, стає зрозуміло, як MiniMax M3 поводиться в реальних dev‑циклах: через інтерфейс агента, з тулколами, автозапусками тестів та довгими сесіями.

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

Токен‑плани MiniMax: що потрібно, перш ніж лізти в налаштування Cursor

Перед тим як відкривати налаштування Cursor, розробнику потрібно вирішити питання з доступом до MiniMax M3. Є два способи: токен‑плани або оплата за API‑тарифами.

Автор наголошує: для роботи через Cursor «вам потрібно мати якийсь token plan або просто платити по API pricing». На платформі MiniMax є окремий блок із ціною за токени та окремо — перелік токен‑планів. На його досвіді, токен‑плани будуть найкращим value, якщо планується активна робота моделі в IDE.

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

Структура процесу виглядає так:

Спершу на сайті MiniMax обирається й оформлюється один із токен‑планів (або приймається рішення платити напряму за API‑виклики). Після оформлення можна перейти в консоль MiniMax, відкрити розділ із підпискою й знайти subscription key — саме цей ключ потрібен для інтеграції з Cursor та іншими сторонніми інструментами. Без нього Cursor не зможе користуватися токен‑планом.

Лише маючи цей ключ під рукою, має сенс переходити до конфігурації всередині Cursor.

Перезапис OpenAI base URL: MiniMax під маскою знайомого API

Cursor орієнтований на OpenAI‑сумісний API, тому інтеграція MiniMax M3 відбувається через перехоплення саме цього інтерфейсу. Логіка проста: IDE думає, що працює з OpenAI, але запити йдуть на інший endpoint.

У документації MiniMax для інтеграції з Cursor схема описана доволі чітко. Потрібно:

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

Після переходу в Cursor він демонструє реальні кроки: у settings знаходить Models, йде до секції OpenAI API key, вмикає використання цього ключа («я збираюсь увімкнути OpenAI API key») і перезаписує OpenAI base URL. Стандартний URL просто видаляється, замість нього вставляється базова адреса MiniMax.

Тут важливо не переплутати потрібний endpoint. MiniMax надає різні base URL залежно від регіону. Автор пояснює це окремо: «якщо ми international, використовуємо ось це», а для користувачів з Китаю є інший URL. У його прикладі використовується саме міжнародна адреса, яку він вставляє замість дефолтного OpenAI endpoint.

Далі у відповідне поле OpenAI API key він вставляє свій subscription key із консолі MiniMax. Фактично Cursor «вірить», що отримав ключ від OpenAI, хоча насправді працює з токен‑планом MiniMax.

У підсумку, в секції API ключів тепер вказані два критичні параметри: новий base URL, який веде на MiniMax, та subscription key, що дозволяє Cursor списувати токени з обраного плану.

Додавання MiniMax M3 як окремої моделі в Cursor

Після того як API‑шар переналаштований, модель MiniMax M3 ще потрібно «представити» Cursor як конкретну модель, яку можна вибирати у списку.

Процес зводиться до кількох кроків. У налаштуваннях моделей автор переходить до списку всіх моделей — «view all models». Далі прокручує донизу та обирає опцію додати нову власну модель — «add custom model».

Ключовий момент — назва моделі. У документації MiniMax цей параметр вказаний явно: «для model name… просто додати назву Miniax-M3». Автор повертається до документації, знаходить саме таке написання і вносить його в поле model name у Cursor. Важливо не вигадувати власних ідентифікаторів, а використовувати точну назву, яку очікує API, інакше запити не будуть коректно маршрутизуватися.

Після натискання на «add» модель з’являється в списку доступних. Cursor якийсь час обробляє додавання, після чого MiniMax M3 стає доступною для вибору в інтерфейсі агента поряд з іншими моделями.

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

Перевірка підключення: простий «hello world» замість сліпої віри

Останній крок — перевірити, що вся ця конфігурація працює в реальній сесії, а не тільки на рівні налаштувань.

Автор відкриває агент‑вікно в Cursor, прокручує список моделей і обирає щойно додану MiniMax M3. Після цього він надсилає елементарний запит — щось на кшталт «hello world», — щоб переконатися, що є відповідь.

У підсумку MiniMax M3 відповідає, і це підтверджує, що:

• base URL коректно вказаний;
• subscription key працює й має доступ до токен‑плану;
• ідентифікатор моделі (Miniax-M3) правильний і розпізнається API;
• Cursor успішно спрямовує запити на сервера MiniMax під маскою OpenAI‑сумісного інтерфейсу.

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

Висновки: як MiniMax M3 вписується в робочий стек Cursor

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

Cursor залишається головним робочим середовищем, яке він називає найкращим місцем для запуску «сирих» coding tasks завдяки сильному coding harness. MiniMax M3 у цій схемі — це просто інший рушій за знайомим OpenAI‑сумісним API.

Практична інтеграція зводиться до трьох основних кроків: оформити токен‑план або погодитися на API‑тарифи, отримати subscription key в консолі MiniMax, а потім у Cursor перезаписати OpenAI base URL на адресу MiniMax, додати ключ і створити кастомну модель з ім’ям Miniax-M3. Після швидкого тесту через простий запит можна повертатися до звичних dev‑циклів, але вже з іншою економікою використання токенів.

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

Джерело

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

На каналі Tech With Tim вийшов великий розбір MiniMax M3 — нової моделі від китайської AI-лабораторії MiniMax, орієнтованої на кодування, довгі сесії та інтенсивне використання інструментів у стилі агентів. Ключовий акцент — не стільки на абсолютній якості моделі, скільки на співвідношенні “можливості / ціна” та тих сценаріях, де це співвідношення кардинально змінює вибір інструменту для розробника.

Відкрита китайська лабораторія й філософія “все викладаємо”

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

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

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

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

Мільйон токенів контексту й автономні довгі ран-и

Одна з найбільш помітних характеристик MiniMax M3 — гігантське контекстне вікно. Максимальний розмір сягає 1 мільйона токенів, причому гарантовано доступно щонайменше 512 000 токенів незалежно від режиму використання.

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

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

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

Мультимодальність із нуля, а не “прикручена збоку”

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

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

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

Ціна, яка радикально змінює поведінку розробника

Ключовий аргумент на користь MiniMax M3 — його вартість у порівнянні з флагманськими моделями на кшталт Opus та різних варіантів Claude.

За 20 доларів на місяць у MiniMax можна отримати приблизно 1,7 мільярда токенів. Для порівняння, в екосистемі Claude ці ж 20 доларів дають зовсім інші обсяги:

• близько 11,1 мільйона токенів у тарифі Claude Haiku;
• близько 3,7 мільйона токенів у Claude Sonnet 4.6;
• близько 2,2 мільйона токенів у Opus 4.8.

Якщо приводити це до множника, виходить, що за однакові 20 доларів MiniMax M3 дає приблизно у 765 разів більше токенів, ніж Opus 4.8. Навіть з урахуванням інших типів підписок у Claude різниця у відчутті “скільки можна собі дозволити” — колосальна.

Це напряму впливає на стиль роботи розробника:

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

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

Не найкраща модель, але вкрай вигідна

У технічному плані MiniMax M3 — дуже сильна модель, особливо для кодування, але не абсолютний чемпіон. Прямо зазначається: це не найкраща модель, що існує зараз. У багатьох задачах Opus 4.8 і подібні флагмани все ще показують кращу якість.

Проте саме співвідношення якості до вартості робить MiniMax M3 унікальним інструментом. Модель демонструє:

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

Йдеться саме про “достатньо хорошу” якість, помножену на майже абсурдно низьку вартість кожного токена. У підсумку для переважної більшості щоденних задач — понад дев’ять із десяти — логічніше використати MiniMax M3, ніж витрачати дорогі виклики Opus чи інших топових моделей, які на практиці дадуть лише помірно кращий результат за кратно вищу ціну.

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

Висновок: модель для тих, хто хоче “лупити по максимуму” без страху за рахунок

MiniMax M3 виявляється не просто ще однією LLM-моделлю в перенасиченому полі, а інструментом із дуже конкретним профілем: відкриті ваги, величезний контекст, вбудована мультимодальність і радикально низька вартість токенів.

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

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

Джерело

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

Минулої п’ятниці, посилаючись на невизначені міркування національної безпеки, Білий дім наказав Anthropic обмежити експорт її потужних моделей штучного інтелекту Fable та Mythos будь‑кому за межами США, а також іноземцям усередині країни. Невдовзі після цього ІТ‑гігант поспіхом вимкнув обидві моделі, які вже тиждень недоступні для будь‑кого.

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

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

Що ж саме спровокувало заборону? За повідомленнями, дві подальші події. Перша: Anthropic надала південнокорейському телеком‑оператору доступ до Mythos у межах своєї обмеженої партнерської програми, а чиновники США занепокоїлися, виявивши компанію, яку підозрювали в зв’язках із Китаєм. (Ця компанія, про яку широко повідомляють як про SK Telecom, заперечує будь‑які зв’язки з Китаєм.) Крім того, гендиректор Amazon Енді Джессі начебто попередив адміністрацію після того, як дослідники Amazon, за його словами, знайшли спосіб обійти захисні механізми Fable 5. Anthropic заперечує, що це був «джейлбрейк», називаючи інцидент вузькою, вже виправленою вразливістю, а не повною поразкою системи безпеки моделі.

Результат виявився однаковим: Міністерство торгівлі США видало директиву про експортний контроль, і Anthropic довелося в терміновому порядку обмежити доступ до своїх продуктів — приблизно за 90 хвилин після отримання повідомлення, за деякими даними.

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

Саме уряд США стояв за, мабуть, найбільш показковим провалом такого підходу в історії — на початку та в середині 1990‑х. Тоді комп’ютерні науковці розробляли технології шифрування для захисту даних під час передачі через інтернет. Одним із таких продуктів було Pretty Good Privacy, або PGP, популярне програмне забезпечення, що дозволяло зашифрувати дані й зробити їх практично неможливими для розшифрування навіть у разі перехоплення під час передачі адресатові.

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

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

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

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

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

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

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

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

Попри все, певні перемоги були. Німецький виробник шпигунського ПЗ FinFisher закрився у 2022 році після багаторічного розслідування німецьких прокурорів щодо нібито продажу ПЗ для стеження Туреччині без експортної ліцензії. Раніше слідчі виявили, що FinFisher використовували для зламу телефонів критиків турецького уряду.

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

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

Джерело

TechCrunch

На нещодавньому заході StrictlyVC у Лос-Анджелесі засновник Shinkei Systems Саїф Хаваджа та партнер фонду Founders Fund Делян Аспарухов обговорювали нетипове для венчурних подій питання: як зрозуміти, що риба перебуває у стресі?

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

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

Історія виникнення Shinkei нетипова для апаратного стартапу. Хаваджа в дитинстві часто ходив на риболовлю з родиною на Близькому Сході, але ідея з’явилася вже в коледжі, коли він прочитав есе філософа-правозахисника тварин «Якби риби могли кричати». Основна думка: у риб немає голосових зв’язок, тож біль, який вони переживають, доки потрапляють на тарілку, залишається невидимим.

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

Далі риба надходить на завод площею близько 16 тис. кв. футів (приблизно 1,5 тис. кв. метрів) у Такомі, штат Вашингтон, який Shinkei придбала. Там її розбирають і продають під споживчим брендом Seremoni з позиціонуванням як «церемоніальна риба» — натяк на особливу якість і ритуальність процесу.

Найпомітнішим підтвердженням успіху наразі є поява продукції Shinkei в меню мережі преміальних магазинів Erewhon у Лос-Анджелесі, популярної серед інфлюенсерів. Erewhon продає рибу Shinkei як Seremoni Grade Miso Black Cod (чорна тріска в місо) у відділі готової їжі, активно просуваючи меседж «сталий вилов, гуманний забій». Поки що це пілотний проєкт у магазині в районі Manhattan Beach; розширення на інші локації залежить від продажів. За словами Хаваджі, компанія вже постачає рибу в ресторани, що разом мають 50 зірок Мішлен, і може похвалитися тим, чого раніше фактично не відбувалося: Японія імпортує рибу, виловлену в США, для продажу на своїх ринках, де традиційно американські морепродукти вважають нижчими за якістю за місцеві.

Чи будуть покупці готові платити премію за «гуманно забиту» рибу, як це вже відбувається зі «щасливою» яловичиною або птицею, — питання поки відкрите. Сам Хаваджа каже, що при поясненні моделі бізнесу це навіть не головний акцент. Для нього ключова перевага — практична: якість та термін зберігання. Улов, який зазвичай зберігається 5–7 днів, можна тримати 12–14 днів, стверджує він, а інколи компанія готує рибу й через три тижні після вилову без проблем. Новітній продукт Shinkei — система сенсорів на заводі — намагається кількісно підтвердити це: вона сканує рибу та прогнозує індивідуальний термін придатності для кожної одиниці.

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

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

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

Усередині галузі вже кілька років триває рух за «повернення» частини цих переробних операцій до США. Його підштовхнули мита й пандемічні збої, які зробили маршрут через Китай менш привабливим. Ставка Shinkei і Founders Fund полягає в тому, що повністю «перешити» весь ланцюг — вилов, забій, переробка й дистрибуція — під одним дахом у Такомі можна достатньо ефективно, щоб конкурувати з глобальною моделлю.

Для Founders Fund ця інвестиція вписується в усталену стратегію: підтримувати засновників, які працюють поза модними категоріями. Аспарухов, який говорить дуже швидко та без особливих фільтрів, прямо заявив аудиторії: практично ніхто інший у світі не хоче присвятити життя будівництву роботів для вбивства риби, і з огляду на запах в офісі Shinkei це зрозуміло. (Зала сміялася, хоча це трохи применшує масштаб ніші. Окрім Shinkei, японська Nichimo продає пристрій, який оглушує рибу й полегшує ручне виконання ike jime, а кілька норвезьких стартапів будують роботизовані системи для більш гуманного забою та переробки риби. Перевага Shinkei наразі в тому, що це єдина компанія, яка запускає повністю автоматизовану версію цієї техніки у масштабі прямо на американських суднах.)

За словами Аспарухова, фонд свідомо обмежує свою експозицію в перенасичених нішах на кшталт «генерального призначення» застосунків ШІ. За його підрахунками, ШІ та оборона разом становлять лише 15–20% вкладеного капіталу фонду — суттєво менше, ніж у більшості інших венчурних гравців. Shinkei стоїть у одному ряду з Halter (нюзеландський стартап, який створює сонячні GPS-нашийники для віддаленого керування стадами) і Ohalo Genetics — компанією в сфері генетики сільгоспкультур, заснованою ведучим подкасту «All-In» Девідом Фрідбергом. Це свідчить, що інтерес фонду до foodtech та агротехнологій не є одиничним випадком.

Водночас найгучніша недавня перемога Founders Fund не має жодного стосунку до риби. Ранні та агресивні інвестиції у SpaceX Ілона Маска — завдяки давнім зв’язкам Пітера Тіля та Маска ще з часів PayPal — принесли фонду, за повідомленнями, десятки мільярдів доларів і стали однією з найбільших венчурних угод в історії. Аспарухов упевнений, що цей успіх пришвидшить ширший зсув венчурного капіталу в бік «заліза» та бізнесів у фізичному світі, адже більшість найбільших компаній із Nasdaq уже давно залежать від складних електромеханічних систем, а не лише від «чистого» софту. Він прогнозує, що частина вихідців із SpaceX, які отримали значний капітал і досвід роботи пліч-о-пліч із Маском, запускатимуть власні амбітні компанії в реальному секторі.

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

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

Попри це, розмова Хаваджі та Аспарухова в Ель-Сегундо змусила аудиторію зрозуміти, чому Founders Fund вбачає в Shinkei привабливу ставку. Фонд вважає, що знайшов засновника, який створює справді нову компанію в дивовижно неефективній індустрії — і яку майже ніхто інший у США просто не наважився б будувати.

Джерело

TechCrunch

Гучним анонсом Apple на цьогорічній WWDC стала повна перебудова Siri на базі штучного інтелекту. Але ширша AI‑стратегія компанії проявляється в низці дрібніших функцій, вбудованих у різні сервіси та застосунки.

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

Окремо ці можливості не такі вражаючі, як Siri, що нарешті розуміє ваш контекст і може діяти від вашого імені. Але разом вони демонструють бачення Apple: AI не як «чат‑бот», а як спосіб зробити саме програмне забезпечення розумнішим і більш здатним.

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

Поділ рахунку

Коли iOS 27 вийде цієї осені, користувачі зможуть ділити ресторанний рахунок за допомогою Apple Cash. Функція працює на базі Apple Intelligence: достатньо сфотографувати чек (або завантажити його фото), після чого з’явиться опція поділити рахунок з іншими.

Apple Intelligence «витягує» ключові дані з рахунку: замовлені позиції та їхню кількість, чайові та підсумкову суму. Ви обираєте свої страви у чеку, а потім надсилаєте запит іншим у груповий чат, щоб вони зробили те саме. Кожен може відмітити свої позиції й кількість — навіть половину (1/2), якщо щось ділили з іншою людиною. Для оплати достатньо подвійного натискання, як і для будь‑якої іншої транзакції Apple Cash.

Опція поділу рахунку не здається складною, адже з’являється тільки тоді, коли потрібна, і працює з уже знайомими сервісами — Повідомленнями (Messages) та Apple Cash. Вона достатньо «розумна», щоб автоматично включити в розрахунок і податок, і чайові разом із вартістю страв.

Автоматичне оновлення паролів

Завдяки менеджерам паролів — вбудованому застосунку Passwords від Apple чи стороннім на кшталт 1Password, Dashlane або Bitwarden — більшість користувачів уже мають складні паролі, які важко вгадати. Але цього вже недостатньо. Як показали численні витоки, ваші паролі можуть опинитися в руках зловмисників не з вашої вини.

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

Підказки в Повідомленнях у один дотик

Якщо вам подобається функція, яка показує SMS‑коди для входу на сайти прямо над клавіатурою, у iOS 27 має сподобатися і новий механізм підказок у Messages в один дотик.

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

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

Контекст дзвінка

Ще одна малопомітна, але корисна опція в iOS 27 — Call Context — має трохи зменшити стрес під час дзвінків у служби підтримки компаній. Вона показує важливу інформацію, яку оператор може у вас запитати. Наприклад, коли ви телефонуєте щодо авіаквитка, на екрані дзвінка з’явиться код бронювання.

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

Додавання подій у Календар

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

Під «капотом» Apple Intelligence виділяє контакти, локації та формує назву події замість користувача. Це спрощує додавання записів до Календаря Apple — не потрібно думати, у яке поле що вводити.

«Vibe‑кодування» для Команд (Shortcuts)

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

В iOS 27 достатньо просто описати, що ви хочете, щоб iPhone робив. Apple наводить приклади: налаштовувати будильник щоночі залежно від розкладу в календарі на завтра; відкривати улюблені продуктивні застосунки певним чином щоразу, коли ви під’єднуєте Magic Keyboard до iPad. Не обов’язково йти в «хардкор» — Команди можуть виконувати й буденні дії: автоматично писати партнеру повідомлення з орієнтовним часом прибуття, коли ви виходите з роботи, або вмикати світло на ґанку, коли до дому під’їжджає кур’єр з доставкою.

Менше спаму від Дому (Home)

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

З Apple Intelligence в iOS 27 додаток Дім (Home) розумітиме, як пов’язані кілька дій, і надсилатиме одне узагальнене сповіщення: наприклад, що хтось прийшов додому та закрив гараж.

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

Автоматичне впорядкування вкладок у Safari

Ще одна неочевидна AI‑функція — організація вкладок у браузері Safari. Завдяки Apple Intelligence Safari тепер розуміє, які сайти ви переглядаєте, і може групувати вкладки за смисловими темами.

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

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

Джерело

TechCrunch

Anthropic нещодавно відключила свої дві найновіші моделі ШІ через розпорядження про експортний контроль від адміністрації Дональда Трампа. Це спровокувало широку дискусію щодо політики в сфері ШІ та цифрового суверенітету.

У свіжому випуску подкасту Equity від TechCrunch Шон О’Кейн, Ребекка Беллан і я обговорили, що саме стало приводом для дій адміністрації проти Anthropic і що це може означати для ширшої екосистеми ШІ.

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

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

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

Нижче — уривок нашої розмови, відредагований для стислості й ясності.

Ребекка Беллан: Як, певно, багато наших слухачів уже знають, уряд США фактично змусив Anthropic відключити дві найновіші моделі — Fable 5 і Mythos 5. Mythos 5 була доступна чинним користувачам Mythos, тоді як Fable 5 була ширше доступна для публіки.

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

Але, за повідомленнями, Білий дім звернув увагу на це після того, як деякі дослідники Amazon нібито знайшли спосіб обійти системи безпеки Fable 5. Генеральний директор Amazon Енді Джессі доніс ці занепокоєння до Білого дому, і далі все вже розкрутилося.

Шон О’Кейн: Усе відбулося дуже швидко, особливо як для п’ятниці по обіді та вихідних. І паралельно адміністрація, принаймні формально, намагалася домовитися про якусь угоду щодо війни, яку вона сама й почала в Ірані.

Ребекка: П’ятничний вечір для нас у Нью-Йорку. Ідеальний момент для відволікання уваги.

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

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

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

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

Ребекка: З одного боку, усе це справді виглядає як акт помсти. Після того, як уряд визнав Anthropic ризиком для ланцюжків постачання, між ними триває велика судова тяганина, і складається враження, що Білий дім просто шукає будь-який привід, щоб вдарити по Anthropic. Я так думаю не лише тому, що це була моя перша реакція, а й тому, що так кажуть багато дослідників кібербезпеки. Вони стверджують, що ця ситуація взагалі не мала б запускати механізм експортного контролю. Вони підписали відкритого листа з вимогою до Трампа скасувати розпорядження і зазначають, що фактично небезпечно позбавляти американських фахівців із захисту мереж таких передових можливостей. Сама Anthropic заявляє, що подібні «джейлбрейки» можна знайти й у кількох інших моделях ШІ.

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

Водночас я бачила й реакції у стилі: Anthropic сама це спровокувала. Мовляв, «це занадто небезпечно, щоб хтось ще міг цим користуватися, але ми — хороші хлопці, нам можна». Виходить, що вони говорять різні речі одночасно. За тиждень до виходу Fable вони казали: «Гей, нам потрібно уповільнити розвиток ШІ, це вже стає дуже небезпечним». А потім — бац, «ось наша найдивовижніша, надпотужна модель, користуйтеся на повну».

Ентоні: У певному сенсі це мікрокосм ширшої дискусії навколо ШІ, де люди на кшталт Сема Альтмана чи Дженсена Хуанга кажуть: «Гей, давайте знизимо градус, чому всі на нас зляться?» Але ж самі ці компанії кілька років поспіль твердили, що побудували «машину-бога», яка забере в усіх роботу. Не дивно, що люди почуваються не надто комфортно.

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

Мені цікаво: Anthropic явно незадоволена тим, що відбувається. Не хочу перебільшувати потенційні вигоди для компанії. Але ми вже публікували матеріали з аналітикою Ramp, які показували: попереднє велике загострення між Anthropic і адміністрацією Трампа в певному сенсі зіграло компанії на користь. Завантаження Claude різко зросли. Багато людей, які до того сприймали ChatGPT як «той самий» чат-бот або помічник на ШІ, раптом почали дивитися на Claude як на більш відповідальну систему, навіть як на щось на кшталт «асистента опору».

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

Джерело

TechCrunch