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

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

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

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

За словами співзасновника Autnmy AI Роба Ґранта, платформа ШІ не просто «скрейпить» інформацію з інтернету. «Ми ще на початку домовилися, що не будемо займатися скрейпінгом інформації, — каже він. — Якщо дані доступні публічно або за ліцензією Creative Commons, ми їх використовуємо. Також у нас є частина ліцензованих даних, за які ми платимо, і працюємо з ними згідно з домовленостями».

Глобальний підхід індексу дав цікаві результати. Одне з перших спостережень, яке вразило Ґранта, — сильніші позиції Китаю одразу в кількох категоріях.

Станом на п’ятницю лідером у сегменті роботаксі виявилася не Waymo, а китайська програма Baidu Apollo Go — хоча й з невеликим відривом. Waymo посідає друге місце, за нею йдуть китайські Pony.ai та WeRide. Tesla — на п’ятій позиції.

Розширення парків роботаксі в Техасі

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

Станом на 28 травня Waymo мала 577 зареєстрованих у штаті автономних автомобілів. Зараз — уже 620, що означає зростання приблизно на 7,5% менш ніж за місяць. Tesla збільшила свій парк із 42 до 69 автономних авто — приріст 64%. Zoox додала вісім машин: із 35 до 43 зареєстрованих.

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

Інші гравці, як-от Avride, Nuro та MOIA (дочірня компанія Volkswagen), наразі утримують свої позиції на рівні 317, 47 та 12 транспортних засобів відповідно.

Угоди та інвестиції

Cargofy, логістична компанія, що використовує ШІ для автоматизації вантажних перевезень, залучила 11 млн доларів у раунді Series A. Інвестиції очолили фонди u.ventures, Toloka та Movens Capital. До раунду також приєдналися співзасновник Intercom Дес Трейнор та кілька бізнес-ангелів.

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

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

QuantumScape підписала спільну дослідницьку угоду з Honda R&D Co. для прискорення розробки твердотілих акумуляторів і відповідних виробничих процесів.

Автовиробник Stellantis, стартап автономного керування Wayve та сервіс виклику таксі Uber уклали угоду про спільну розробку й запуск сервісу безпілотних роботаксі.

Стартап XDOF, що спеціалізується на даних для тренування роботів, залучив 70 млн доларів від Thrive Capital, Spark Capital, a16z, Lux та WndrCo.

Аварії, експерименти й нові сервіси

У мережі Reddit з’явилося відео, на якому водій не зупинився на знаку «Stop» і врізався в автономний автомобіль у Далласі. TechCrunch підтвердив, що це був роботаксі Avride, який замовили через додаток Uber. Представник Avride заявив, що постраждалих немає, а дані інциденту аналізують «для постійного вдосконалення технологій і процесів у рамках стандартних процедур». На запитання про реакцію системи автономного керування і водія-безпекового оператора у салоні в компанії відповіли, що перевірка триває і подробиці наразі не розголошуються.

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

У сервісі X (колишній Twitter) помітили Tesla з офіційним ліцензійним стікером лімузинного перевізника для округу Сан-Франциско та аеропорту Сан-Франциско (SFO. Представник SFO підтвердив TechCrunch, що Tesla видано дозвіл на роботу як лімузина з водієм: «Це традиційні лімузинні операції, тобто транспортними засобами керують люди. Дозволу на автономні операції в SFO Tesla не отримувала».

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

Uber планує до середини 2027 року запустити преміальний сервіс роботаксі в Г’юстоні. Це буде другий ринок у США в межах партнерства сервісу з виробником електромобілів Lucid та стартапом автономного транспорту Nuro.

Джерело

TechCrunch

Polymarket платив онлайн-креаторам за публікацію оманливих відео, в яких ті демонстрували нібито прибуткові ставки на цій платформі прогнозів, повідомляється в новому розслідуванні Wall Street Journal.

За даними WSJ, видання проаналізувало 1100 відео про Polymarket, а також ознайомилося з інструкціями, які компанія надавала креаторам. Чимало цих роликів, за повідомленням газети, знімалися на «майже ідеальних копіях» сайту Polymarket, де показані угоди та виграші були не справжніми. Згодом ці відео розганяла «армія в соцмережах», яку задіяв маркетинговий підрядник.

WSJ також пише, що компанія просила креаторів не уточнювати, що вони отримують гроші від Polymarket, хоча згодом ті почали додавати в біо позначку «@polymarket partner» після того, як журналісти поставили відповідні запитання.

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

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

Джерело

TechCrunch

Співзасновник французької компанії з розробки відеоігор Ubisoft Клод Гіймо помер у п’ятницю у віці 69 років.

За даними французьких ЗМІ (через Bloomberg), Гіймо загинув внаслідок авіакатастрофи на французькому курорті Ла-Боль. Він був одним із двох людей на борту літака, обидва загинули.

Гіймо заснував Ubisoft разом із чотирма братами у 1986 році. Відтоді компанія видала такі відомі ігрові серії, як Assassin’s Creed, Far Cry, Prince of Persia та Tom Clancy, а також багато інших тайтлів. Родина й надалі контролює Ubisoft, а брат Клода Ів Гіймо досі обіймає посаду генерального директора.

Клод Гіймо також був головою компанії Guillemot Corp., що виробляє ігрові та аудіоаксесуари.

«Ubisoft глибоко засмучена, дізнавшись про смерть Клода Гіймо, співзасновника групи та голови Guillemot Corp., унаслідок нещасного випадку», — йдеться в заяві компанії. «Наші думки з його родиною та близькими в цей складний час. Жодних додаткових коментарів наразі не буде».

Джерело

TechCrunch

У подкасті The Pragmatic Engineer провідний інженер Octopus Deploy Роберт Ерез — фахівець із більш ніж десятирічним досвідом у CI/CD та системах розгортання — розкладає GitOps до базових принципів і акуратно знімає з нього ореол релігії. Його підхід простий: подивитися, що саме стоїть за терміном, які проблеми він реально розв’язує, а де перетворюється на зайву догму для команд, яким просто потрібно надійно й передбачувано постачати софт.

Як з’явився GitOps — і чому Kubernetes тут ключовий

GitOps народився не в теорії, а з дуже практичного спостереження: якщо Kubernetes уже вміє підтримувати заявлений стан кластера, чому б не потягнути цю ідею ще далі — до рівня репозиторію?

Ерез нагадує, що сам термін GitOps запровадила компанія Weaveworks приблизно у 2017 році. І майже одразу він пішов «у парі» з Kubernetes, тому що Kubernetes за своєю природою декларативний. У кластера є контролери, які стежать за тим, щоб бажаний стан системи — описаний у маніфестах — завжди збігався з фактичним. Якщо под помирає, контролер піднімає новий, якщо задано три репліки — система підтримує рівно три.

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

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

Чотири стовпи GitOps — і жодного обов’язкового Git

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

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

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

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

Третій стовп — pull, а не push.
GitOps спирається на модель, де агент всередині цільової системи (наприклад, кластера Kubernetes) сам тягне бажаний стан із джерела правди й застосовує його. Це протилежність push‑сценаріям, коли зовнішній інструмент «натискає» зміни в інфраструктуру. Модель pull зменшує кількість точок довіри та робить інфраструктуру більш самоорганізованою: кластер сам піклується про свою відповідність декларації.

Четвертий стовп — безперервна реконсиляція.
Це природне продовження: агент не просто один раз застосовує конфігурацію, а постійно стежить за дрейфом. Якщо хтось руками видалив deployment через kubectl, GitOps‑агент знову зчитає бажаний стан і відновить ресурс. Так з’являється замкнений контур: декларація → агент → Kubernetes → перевірка → повторне застосування при розбіжності.

Жоден із цих чотирьох принципів не вимагає саме Git. Потрібні декларативні описи, версіоноване й незмінне джерело, pull‑модель та безперервна реконсиляція. І назва «GitOps», на думку Ереза, тут зіграла двояку роль.

Пастка «все має бути в Git»: коли назва створює хибні очікування

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

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

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

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

Де GitOps працює прекрасно, а де починає скрипіти

Популярність Kubernetes автоматично потягнула за собою і популярність GitOps. Багато компаній, які тільки починають працювати з Kubernetes, сприймають GitOps як «де-факто спосіб» управління середовищами: є кластери, є маніфести, значить, має бути GitOps‑агент, який тягне все з репозиторію.

За спостереженнями Ереза, у великих організаціях GitOps уже став майже стандартним підходом до Kubernetes‑кластерів. Але далі починається намагання «протягнути» цю модель і на все інше — наприклад, інтегрувати Terraform через безперервну реконсиляцію зовнішніх ресурсів за описами в репозиторії. Є експерименти, є проєкти, які так роблять, але поки що важливіше інше: у прагненні «описа́ти все декларативно й у Git» команди стикаються з реальністю.

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

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

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

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

GitOps не для всіх: проти «абсолютизму» в інфраструктурі

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

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

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

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

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

Тому Ерез радить дивитися на GitOps як на набір корисних принципів, які можна застосовувати там, де вони природно підходять, а не як на всеохопну догму. Одне середовище може управлятися через GitOps‑агента, інше — через класичний пайплайн, третє — комбінованим способом. Головне — щоби команда чітко розуміла, для чого вона обирає кожен підхід.

Фокус не на термінах, а на постачанні софту

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

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

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

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

GitOps виник як природне продовження декларативної моделі Kubernetes і дуже влучно влучив у потребу: зробити стан інфраструктури видимим, відтворюваним і підконтрольним. Чотири його стовпи — декларативність, версіоноване й незмінне джерело правди, pull‑модель і безперервна реконсиляція — справді дають командам потужну рамку мислення.

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

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

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

Джерело

CI/CD with Robert Erez — The Pragmatic Engineer

У подкасті The Pragmatic Engineer ведучий Ґерґей Орош говорив із Робертом Ерецем, Principal Engineer в Octopus Deploy і фахівцем із CI/CD та систем розгортання. Попри репутацію «cloud‑native» технології, у їхній розмові Kubernetes постає в іншій ролі: не лише як переможець хмарних оркестраторів, а й як де-факто стандарт для on‑prem інфраструктури — від датацентрів до POS‑терміналів і наукових суден у відкритому морі.

Як Kubernetes став «платформою моменту»

Ерец називає Kubernetes «the platform of the moment» і говорить, що він «has become the clear winner in this space». Історія така: Kubernetes прийшов із внутрішніх напрацювань Google і вийшов на ринок у момент, коли було багато конкуруючих рішень для оркестрації контейнерів. Згадуються альтернативи на кшталт інших оркестраторів і навіть окремі платформи, які намагалися вирішити проблему мікросервісів і залежностей власним шляхом.

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

У дискусіях про Kubernetes зазвичай звучать слова «cloud» і «cloud‑native», на конференціях демонструють інтеграції з AWS, Azure чи Google Cloud. Створюється враження, що це інструмент насамперед для публічної хмари. Та картина, яку описує Ерез, інша: значна частина реального використання відбувається далеко від глянцевого «cloud‑native» на слайдах.

On‑prem як норма: від власних VM до керованих кластерів

«The reality is a lot of customers actually use Kubernetes for running on premise», — наголошує Ерез. Йдеться не про поодинокі випадки: «A non-insignificant number of our customers… are running on potentially their own VMs on their own server farms or maybe they’re running VMs in AWS or Azure but they’re maintaining Kubernetes itself.»

Тобто навіть коли інфраструктура фізично розміщена в хмарі, для багатьох це все одно on‑prem‑парадигма: клієнт піднімає власні віртуальні машини, сам розгортає і обслуговує Kubernetes‑кластер, контролює версії, конфігурацію і політики. Причини типові для великих організацій — фінансовий сектор, урядові установи та інші структури з жорсткими вимогами до контролю, відповідності та безпеки. Вони хочуть «fully sort of control the process and manage the whole piece of infrastructure from end to end».

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

Це знімає частину складності, яка традиційно супроводжувала on‑prem інфраструктуру. Команди можуть мислити не в категоріях конкретних серверів, а в термінах «desired state» — кількості реплік, типів сервісів, політик оновлення. І саме цей декларативний підхід, за словами Ереця, став ще одним аргументом на користь Kubernetes у світі, де вже прижилися Terraform, Puppet та інші інструменти інфраструктури як коду.

Kubernetes у POS-терміналі: кластери в кожному магазині

Один із найяскравіших прикладів, які наводить Ерез, стосується ритейлу. «Some of our customers have Kubernetes clusters basically in their point of sale systems… they have hundreds and hundreds of stores and they have little Kubernetes clusters that essentially run in them and each one’s independent.»

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

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

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

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

Кластери посеред океану: коли корабель не в онлайні

Ще один кейс, який згадує Ерез, — наукові дослідницькі судна. «They’ve got Kubernetes clusters running on research vessels… they’ve got Kubernetes clusters out out in the open sea.»

Сюжети з «cloud‑native» світу зазвичай обмежуються датацентрами або, у кращому разі, edge‑локаціями поблизу мегаполісів. Тут же йдеться про кораблі у відкритому морі, де з’єднання з берегом може не бути тижнями чи місяцями. Кластери Kubernetes працюють на борту, обслуговують свої задачі, але для інженерів з’являється новий клас обмежень.

Головна з них — оновлення. «When you want to do a deployment that the ship’s not available. So when that ship comes back into port, it needs to get the update.» Іншими словами, звичні сценарії безперервного деплойменту, де кластери завжди «висять» у хмарі й можуть у будь-який момент витягнути новий маніфест, тут не працюють.

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

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

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

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

«It’s easy to sometimes to get lost in… conferences… everyone’s saying it’s all about cloud… the reality is, you know, everyone’s kind of got their own little problems and they just want to solve them the way they kind of need to solve them.»

Це, мабуть, ключова теза до розуміння того, чому Kubernetes виграв не лише хмару, а й on‑prem. Не тому, що всім знадобилася модна «cloud‑native» архітектура, а тому, що платформа виявилася достатньо гнучкою, щоби вмістити дуже різні реальності:

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

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

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

Якщо судити за розповідями Ереця, Kubernetes уже давно перестав бути просто «cloud‑native» інструментом. Він став універсальним стандартом платформи виконання — і в хмарі, і в on‑prem, і на межі мережі.

Той самий механізм декларативного опису стану, автоматичної «continuous reconciliation» і уніфікованих примітивів однаково добре лягає на приватні серверні ферми, VM у публічній хмарі, магазини з POS‑терміналами та наукові судна.

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

Джерело

CI/CD with Robert Erez — The Pragmatic Engineer

На каналі Tech With Tim вийшов розбір Lemma — платформи від компанії Analemma AI, яка обіцяє «vibe research»: замість тижнів ручної роботи достатньо сформулювати запит, а далі багатoагентна система сама планує експерименти, запускає код, аналізує результати й видає повноцінний дослідницький пейпер. Особливість у тому, що це не просто інструмент для вчених, а «AI for AI» — інфраструктура, де самі AI‑системи досліджують і покращують наступне покоління AI.

«AI для AI»: коли модель досліджує саму себе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Демократизація доступу до «дорогого» ресерчу

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

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

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

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

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

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

Чому «самопосилюваний» AI-ресерч лякає так само, як надихає

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

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

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

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

Висновок

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

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

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

Джерело

YouTube: AI Research Papers Are Here (And They’re Scary Good)

У новому відео на каналі Tech With Tim розробник і контентмейкер Тим демонструє, як платформа Lemma від Analemma AI провела повністю автономне дослідження про галюцинації великих мовних моделей. Центральний епізод — режим FARS (Fully Automated Research System), у якому система сама спланувала експеримент, обрала моделі, запустила код, проаналізувала результати й згенерувала дев’ятисторінковий ресерч-пейпер у класичному академічному форматі.

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

Запит: чи знижує явне визнання невпевненості галюцинації LLM

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

Формулювання промпта було таким: дослідити, «whether asking an LLM to explicitly state uncertainty… reduces hallucinations». До цього додали конкретику: «Design a simple experiment with 20 questions and compare a normal prompt versus an uncertaintyaware prompt. Analyze the expected results and provide the practical recommendations.»

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

Десять кроків експерименту та повна автономія вибору моделей

На етапі експерименту FARS згенерував структурований план роботи, розбитий на кроки й підкроки. «This is the list of to-dos that it came up with. You can see it’s 10 steps. Each step actually has substeps… And you can see that we installed the dependencies and then we ran multiple different prompts on different models.»

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

Система «automatically picked Gwen 2.572 billion as well as GPT 4.0… This is fully on the model. This isn’t me telling it what to do. Like, I just gave it one prompt and then it just ran with everything.»

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

Сам експеримент виявився доволі «важким» за часом і ресурсами. «This experiment took a pretty long time to run. I believe it was 1 or 2 days. It used up 63,000 credits.» Причина — FARS запускає повноцінне віддалене виконання: піднімає середовище, завантажує моделі, проганяє промпти, збирає й аналізує результати. Усе це — у тому самому «vibe research» стилі, коли користувач задає лише дослідницький намір, а не технічну інструкцію.

Готовий пейпер: від abstract до evaluation metrics

Фінальний результат — повноцінна наукова стаття, яку Lemma віддала у вигляді дев’ятисторінкового PDF. Структура відповідає академічним стандартам: «It follows kind of the format that you’re supposed to follow for a professional research paper. So, we have the abstract… the introduction… related work… method… evaluation metrics… all of this kind of stuff.»

У роботі є:

• анотація з підсумком дослідження;
• вступ із постановкою задачі;
• розділ related work, де зібрані попередні роботи;
• методологія з описом промптинг-умов;
• метрики оцінки — coverage, false answer rate, HCE;
• графіки та таблиці з результатами для двох моделей і двох набір-промптів;
• висновки і список використаних джерел.

Методична частина будується навколо порівняння кількох варіантів промптингу: «We have a standard baseline, loose uncertainty, and then strict binary abstension.» На схемі в пейпері показано, як для одного й того самого вхідного запитання Q моделі дають відповіді в різних режимах: звичайному, з «м’яким» вираженням невпевненості й у жорсткому режимі, де від моделі вимагається або відповідь, або чітка відмова.

Далі пейпер переходить до метрик. Згадуються coverage, false answer rate, HCE (hallucination coverage efficiency). На графіках порівнюються показники для двох моделей, двох дата-сетів і двох типів завдань (зокрема structured QA), а в таблицях подаються точні значення кількості неправильних відповідей і ефективності зниження галюцинацій.

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

Binary abstension prompting: нульова вартість, але з межею

Ключова ідея статті — метод, який Lemma називає binary abstension prompting. У висновках сформульовано: «We introduced binary abstension prompting a zerocost intervention that eliminates hedged hallucinations by forcing LLM to either answer or explicitly refuse.»

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

За результатами експерименту, цей підхід справді впливає на кількість помилкових відповідей: «This method reduces the false answer rate by 18 to 51% across two models and two benchmarks achieving nearperfect abstension targeting on structured QA…» Тобто в межах двох використаних моделей і двох бенчмарків false answer rate зменшився в діапазоні від 18% до 51%, а на структурованих завданнях питання‑відповідь вдалося досягти майже ідеального «націлювання» відмов: модель утримується від відповіді саме там, де ризик галюцинацій найвищий.

Однак у пейпері одразу фіксується й межа цього підходу: «However, binary abstension over abstains on knowledge intensive longtail questions revealing a regime boundary.» Іншими словами, на знання-інтенсивних, «довгохвостих» запитаннях модель починає відмовлятися надто часто — навіть тоді, коли мала б шанс дати коректну відповідь. Це й описується як певна «межа режиму» методу.

Сам автор відео підсумовує це так: коли в промпті вимагається, щоб модель або чесно зізнавалася, що не знає, або давала чітку відповідь, «we get a significantly lower hallucination rate and false answers. However, sometimes when it should know the answer, it doesn’t tell us the answer based on us introducing that in the prompt.»

Отже, binary abstension prompting в інтерпретації Lemma не стільки «виправляє» модель, скільки вчить її замовкати там, де ймовірність вигадки надто велика. Ціна — втрата частини корисних відповідей на складних запитаннях.

Дев’ять сторінок «поки ви спите» і що це показує

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

• складає багаторівневий план із десяти основних кроків;
• розгортає віддалене середовище, ставить залежності, завантажує моделі;
• обирає, які саме моделі й дата-сети використовувати;
• формує промпти в різних режимах невпевненості;
• рахує метрики, будує графіки, таблиці, візуалізації;
• збирає все в дев’ятисторінковий текст із abstract, introduction, related work, method, evaluation, conclusion і списком посилань.

За словами Тима, цей звіт «was generated while I was sleeping», і за якістю він перевищив те, що він сам міг би написати під час навчання в університеті чи школі. Важливе уточнення: набір даних і масштаби експерименту були відносно невеликими, тож робота не претендує на статус «остаточної істини» в темі галюцинацій. Проте сам факт, що такий повний цикл — від дослідницького питання до структурованої статті — може виконати багатoагентна система без детального втручання людини, показовий для того, як може виглядати майбутнє AI‑досліджень.

Lemma позиціонується як AI‑for‑AI платформа: її використовують для того, щоб досліджувати й покращувати самі AI-системи. У випадку з FARS це проявляється буквально — автономний дослідницький «ліфт» дозволяє штучному інтелекту вивчати власні обмеження, зокрема галюцинації, і експериментувати з інтервенціями на зразок binary abstension prompting.

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

Джерело

AI Research Papers Are Here (And They’re Scary Good) — Tech With Tim

У новому відео на каналі Tech With Tim автор показує, як платформа Lemma від Analemma AI виходить за межі звичного “чат-бот відповів на запит”. Один із найяскравіших прикладів — повністю автономний експеримент у режимі Code: система сама досліджує задачу, проєктує пайплайн, генерує код, запускає навчання моделі та візуалізує результати для класифікатора, що відрізняє AI‑зображення від реальних фото.

Цей кейс дає рідкісну можливість подивитись крупним планом, як виглядає на практиці “vibe coding” для машинного навчання, коли людині достатньо сформулювати ідею експерименту — а все інше бере на себе багатoагентна система.

Від однієї фрази до повного ML-проєкту

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

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

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

Спочатку ресерч, потім — код

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

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

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

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

Віртуальне середовище замість локального стенду

Ще одна суттєва риса: усі обчислення виконуються не на машині користувача, а у віддаленому віртуальному середовищі, до якого Lemma під’єднується автоматично. Інтерфейс при цьому нагадує знайоме IDE, на кшталт VS Code, але працює всередині самої платформи.

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

У віртуальному середовищі Lemma не лише зберігає код, а й формує артефакти експерименту: сітки зображень, результати класифікації з підписами “AI generated” / “real”, тренувальні криві втрат і точності. Це дає можливість одразу оцінити, як працює модель, без додаткового доопрацювання.

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

Від MobileNet до логів виконання: що саме зібрала Lemma

Після завершення завдання можна переглянути весь список “to-do”, які система поставила сама собі і послідовно виконала. Це не просто “згенеруй модель” і “натисни train”, а багатокроковий план з проміжними задачами.

У звіті фіксується, яку архітектуру в підсумку було обрано та як саме організовано навчання. У цьому випадку Lemma використала MobileNet v3 small 0.5, донавчивши її на 300 зображеннях: 150 реальних і 150 AI‑згенерованих. Також платформа вказує, скільки часу тривало тренування на CPU, наголошуючи, що модель невелика і ресурсів потребувала небагато.

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

У візуальній частині Lemma генерує декілька сіток із зображеннями, де для кожного прикладу зазначено “true label” і “prediction”. Можна побачити, як класифікатор класифікує AI‑картини як “AI generated” і реальні фото як “real”, і швидко оцінити, де він спрацьовує коректно, а де потенційно помиляється. Окремі графіки показують динаміку loss і accuracy протягом навчання.

Попри невеликий розмір датасету, результати в цьому кейсі вийшли “ідеальними” для тренувального набору — але саме як демонстрація, що повний цикл ML‑експерименту може бути автоматизований.

Вихід у продакшен: код на експорт

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

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

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

Що показує цей експеримент про автономію AI‑агентів

Кейс із класифікатором AI‑зображень проти реальних фото важливий не стільки самим завданням (воно відносно просте), скільки масштабом автономії системи. Від однієї фрази на кшталт “побудуй класифікатор, потренуй на невеликому датасеті і покажи, що він бачить” Lemma переходить до:

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

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

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

Джерело

YouTube: AI Research Papers Are Here (And They’re Scary Good)

У новому відео на каналі Tech With Tim розробник і контентмейкер Тим показує платформу Lemma від Analemma AI — багатoагентну систему для «vibe research», де користувач формулює лише дослідницьке питання, а далі все робить ШІ. Центральна ідея — різні режими роботи, від короткого огляду до повністю автоматизованого дослідження з кодом і експериментами.

Для технічної аудиторії ключове не те, що «AI пише пейпери», а як саме влаштована шкала глибини: Explore, Survey, Code та FARS. Вона визначає час, вартість, обсяг обчислень і те, наскільки сильно систему варто залучати у власні R&D-процеси.

Explore: швидкий «скрінінг» теми за кілька хвилин

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

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

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

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

Survey: повноцінний академічний огляд із широю цитатною базою

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

У цьому форматі система генерує довгі академічні огляди з широким покриттям цитувань. Йдеться саме про «long-form academic surveys» з «broad citation coverage» — тобто тексти, які намагаються системно зібрати й переосмислити наявну літературу з теми.

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

Це режим, який логічно використовувати, якщо потрібно:

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

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

Code: коли AI не просто радить, а запускає експерименти

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

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

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

• пошук і читання релевантних методологій, а не миттєвий перехід до коду;
• побудову плану дій («to-do»), де кроки послідовно виконуються автономно;
• генерацію повноцінного проєктного оточення з файлами коду, скриптами, візуалізаціями;
• підняття віртуального середовища виконання — це не локальна машина користувача, а віддалений workspace, до якого Lemma підключається й у якому сама все запускає.

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

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

FARS: повністю автоматизована дослідницька система

Над рівнем Code стоїть FARS — Fully Automated Research System. Це найважчий, найдовший і найдорожчий режим, який поєднує планування, експерименти, написання коду і фінальний ресерч-пейпер у єдину оркестровану послідовність.

FARS — це продовження тієї ж ідеї «vibe research»: користувач формулює дослідницьке питання, далі Lemma піднімає команду агентів, яка:

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

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

• лише research proposal;
• experimental study;
• або повноцінний research paper.

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

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

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

Один із прикладів FARS‑задачі, який демонструється, стосувався впливу явного вираження невпевненості в промптах LLM на галюцинації: пропонувалося порівняти звичайні запити й запити, де модель заохочують заявляти про невпевненість. Ця задача зайняла велику кількість часу (орієнтовно день-два) та витратила десятки тисяч кредитів, оскільки включала завантаження моделей, прогін великої кількості промптів і побудову повного ресерч-документу.

У результаті FARS сформував дев’ятисторінкову статтю зі стандартною академічною структурою: абстракт, вступ, related work, методи, метрики, графіки, таблиці з результатами, обсмоктування експериментів і фінальний висновок плюс список посилань. Усе це — без покрокового керування з боку користувача після стартового промпта й вибору пропозиції.

Кредити та вартість: де проходить практична межа

Ще один вимір, який розділяє режими Lemma, — це платіжна модель. Платформа дозволяє безкоштовно «помацати» короткі завдання, але для довготривалих задач на кшталт Survey, Code або FARS знадобляться кредити.

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

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

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

Як читачеві обрати свій режим

Вертикаль Explore–Survey–Code–FARS у Lemma фактично віддзеркалює етапи класичного наукового процесу — від первинного знайомства з темою до завершеного дослідження з власними експериментами. Але тут ці етапи реалізуються як незалежні режими одного інструменту.

Якщо потрібно:

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

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

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

Джерело

YouTube — “AI Research Papers Are Here (And They’re Scary Good)”

Провідні інженери, що працюють над Claude Code та агентними системами, закликають відмовлятися від постійного ручного промптингу й переходити до так званого loop engineering — проектування «лупів» (циклів), які самі керують ШІ‑агентами. Канал Austin Marchese системно розкладає цю ідею на практичні кроки й показує, як організувати роботу з Claude так, щоб ваша роль змістилася з «того, хто постійно щось дописує в чат», до «того, хто один раз проєктує процес і далі лише наглядає».

Що таке «луп» і чим він відрізняється від звичайного промпта

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

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

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

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

Коли має сенс будувати луп: 4‑критерійний тест

Щоб не перетворити все життя на «конвеєр з лупів», варто проганяти будь‑яку ідею через простий тест:

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

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

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

4. Луп має інструменти для завершення задачі?
   Якщо йдеться про сайт, система має вміти:

5. перевірити, що домен доступний,
6. зробити HTTP‑запит,
7. прочитати відповіді,
8. викликати інші «skills» для правок.
   Без доступу до потрібних інструментів луп перетворюється на красиву, але беззубу концепцію.

Якщо на всі чотири запитання відповідь «так» — це кандидат на повноцінний луп.

Чотири будівельні блоки робочого лупа

Loop engineering автор розкладає на чотири ключові компоненти: тригер, execution skills, ціль із верифікацією та вихід із пам’яттю.

1. Тригер: що запускає луп

Тригер — це точка старту. Без нього луп існує лише як ідея в текстовому файлі. Прості варіанти:

• /loop у Claude
  Дає змогу запускати завдання з певним інтервалом з локальної машини. Наприклад:
  /loop every 6 hours: перевір погоду та повідом, чи потрібно змінити план тренувань за моїм календарем.
  Мінус: якщо ноутбук вимкнений, луп не працює.

• /schedule
  Планування в хмарі за розкладом (наприклад, щодня о 8:00). Такий підхід не залежить від вашого комп’ютера й підходить для регулярних бізнес‑процесів.

• Кастомний orchestration‑skill
  Більш «інженерний» варіант: створити окремий skill, який виконує роль «центру управління польотом» для лупа.
  Наприклад, /check_weather_loop — єдиний виклик, що:

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

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

2. Execution skills: «мускули» вашого лупа

Якщо тригер — це старт, то execution skills — це виконавчі модулі, кожен із яких робить одну конкретну роботу.

Що важливо:

• Skill — це по суті збережений промпт з чіткою інструкцією, який можна викликати повторно.
• Оркестратор не займається «дрібницею» — він тільки вирішує, який skill викликати і в якій послідовності.
• Один skill — одна спеціалізація: написати e‑mail, перевірити факт, проаналізувати тренування, рецензувати код тощо.

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

Показовий приклад — погода й тренування.
Без окремого /analyze_workout AI може просто сказати: «Йде дощ, скасовуємо пробіжку».
Але якщо у вас є skill, де зафіксовано, що ви любите бігати під дощем, — луп видасть зовсім іншу рекомендацію. Поведінка лупа напряму залежить від того, наскільки якісно описані ваші навички‑skills.

3. Ціль і верифікація: як луп розуміє, що «робота зроблена»

Будь‑який луп тримається на зв’язці:

• Goal — що саме потрібно досягти,
• Verification — як формально підтвердити, що це досягнуто.

Технічний сценарій: запуск сайту

• Ціль:
  «Запустити сайт на домені X та забезпечити час завантаження менше 2 секунд».

• Верифікація:

• Зробити запит на домен X.
• Переконатися, що контент відповідає очікуванням.
• Заміряти час завантаження.
• Пропустити результат через /engineer_review skill, який або схвалює зміни, або відхиляє.

Луп повторює цикл «оновлення — перевірка», доки всі критерії не виконані.

Нетехнічні задачі: як зробити абстрактне — вимірюваним

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

Приклад: луп для пошти /draft_emails_loop.

• Ціль:
  Для кожного непрочитаного листа створити чернетку відповіді.

• Верифікація:

• Усі листи без відповіді мають чернетку.
• Кожна чернетка пройшла рев’ю через:
  • /email_review (структура й зміст),
  • /writing_voice (стиль і тон автора),
  • /fact_checker (перевірка фактів).

У цих skills можна додати наприкінці формальне поле:
approved / not approved або оцінку за шкалою 1–10. Це й перетворює суб’єктивні критерії на об’єкт перевірки.

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

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

4. Вихід і пам’ять: чому без логів луп «вчорашній день»

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

Основні принципи:

• Луп має записувати історію запусків: що робив, які були проміжні результати, які помилки виникали, які параметри спрацювали.
• Не потрібні складні системи — достатньо, наприклад, Markdown‑файла з логами.
• Формула з документації Anthropic, яку згадує автор:
  «Agent забуває, репозиторій — ні».

Збереження історії дозволяє:

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

Технічно це може бути просто оновлення файлу з «lessons learned» кожного разу, коли orchestration‑skill завершує чергову ітерацію.

Як побудувати свій перший луп і не спалити всі токени

Loop engineering звучить складно, але автор пропонує досить приземлений алгоритм старту.

1. Почати з найменшої вже перевіреної задачі

Запитання для старту:
яке найменше завдання ви вже виконували з Claude і задоволені якістю?

Це може бути:

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

Тепер потрібно прогнати цей кейс через 4‑умовний тест (повторюваність, definition of done, бюджет токенів, доступні інструменти). Якщо все сходиться — це кандидат на перший луп.

2. Використати skill‑driven loop development

Принцип: лупи – надбудова над уже існуючими skills.

• Спочатку створюються й відшліфовуються ключові skills (написання, рев’ю, аналіз, факт‑чек, технічні перевірки).
• Далі orchestration‑skill просто «склеює» їх у послідовний процес:
• Викликати skill А,
• Передати результат у skill B,
• Перевірити через skill C,
• Залогувати результат у пам’ять,
• Повторити, якщо верифікація не пройдена.

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

3. Увімкнути «training mode», доки луп не доведений

Важливий запобіжник — режим навчання лупа:

• На перших ітераціях orchestration‑skill робить паузу на кожному кроці й запитує вашого підтвердження:
  «Quick check before I burn the tokens… Продовжувати?»
• Ви бачите хід процесу, втручаєтеся, коли щось йде не так, коригуєте інструкції.
• Тільки після того, як переконаєтеся, що луп поводиться адекватно, вимикаєте training mode, і він працює повністю автономно.

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

4. Розбивати нечіткі цілі на етапи з людськими чекпоінтами

Для задач, де результат важко виміряти (події, стратегії, креатив), автор радить ставитися до AI як до інтерна.

Замість «сплануй корпоратив» — послідовність з контрольними точками:

1. Обрати дату — погодити.
2. Запропонувати варіанти локацій — погодити.
3. Запропонувати 3–5 тем вечірки — погодити.
4. Лише потім запускати всю іншу роботу.

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

Що менш вимірюваний фінальний результат —
то дрібнішими мають бути цілі лупа й частішими — точки верифікації.

Джерело

YouTube — «Stop Prompting Claude. Start Loop Engineering.»

На подкасті Mixture of Experts від IBM Technology ведучий Тім Хван разом з експертами з штучного інтелекту Амбі Ґанесаном, Рінн Вітна та Санді Бесін обговорюють несподівану новину зі світу кіно: на престижний кінофестиваль Tribeca почали подавати фільми, створені з використанням генеративного ІІ. Це не рекламні ролики і не «швидкі» TikTok‑відео, а претензія на мистецтво, яке прагне критичного визнання.

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

Tribeca відкриває двері для генеративного відео

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

Рецензія з Tribeca, яку обговорюють учасники подкасту, описує дуже строкату картину. Частина AI‑фільмів виглядає сирою, інша — вже підбирається до межі, за якою глядач і критик можуть «примружитися» і визнати це повноцінним кіноформатом. Звідси й головне запитання: чи побачимо за п’ять–десять років повністю згенерований ІІ фільм, який отримає серйозну нагороду? І чи матиме він окрему категорію, чи конкуруватиме на рівних?

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

AI давно в кіно: від CGI до повнометражних «генераток»

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

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

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

Інструмент проти автопілота: де закінчується ремесло

Експерти проводять чітку межу між двома режимами роботи з генеративним ІІ.

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

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

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

Беклаш і новий клас досвіду

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

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

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

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

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

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

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

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

Як AI змінює ремесло режисера, а не лише картинку

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

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

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

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

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

Нове кіно як компроміс між швидкістю та майстерністю

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

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

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

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

Джерело

Mixture of Experts – Microsoft’s new AI models & bots dominate the internet (IBM Technology)

У подкасті Mixture of Experts від IBM Technology ведучий Тім Хван спілкується з інженерами та лідерами AI‑напряму про те, як компанії намагаються приборкати витрати на генеративний ШІ. На тлі нових великих моделей, здатних за лічені дні «спалити» бюджети на токени, дискусія зосереджується не стільки на швидкості чи якості, скільки на економіці: як проєктувати системи, які не розорять замовника — і при цьому не зламають робочий процес команди.

Дві школи економії: «дешевий спочатку» проти «одним пострілом»

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

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

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

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

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

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

Логіка тут доволі прагматична. Є цілий клас запитів і задач, які мають:

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

Для них очевидно не потрібен найновіший «5.5‑каліберний» гігант. Їх цілком здатні закривати менші моделі — за значно нижчою ціною.

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

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

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

Не все має бути «фронтиром»: де вистачає простіших моделей

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

Лише відносно невелика частина кейсів реально вимагає:

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

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

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

Рідко обговорюваний важіль: вартість не лише токенів, а й людей

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

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

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

Звідси — ще один шар компромісів:

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

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

Стиснута розробка й «стіна рев’ю»: коли швидкість б’є по процесу

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

У класичній схемі розробки існують три фази:

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

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

Коли:

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

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

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

Баланс попиту: коли потрібен «state‑of‑the‑art»

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

Є типи задач, де:

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

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

Висновок: економіка AI — це не лише прайс лист на токени

З розмови на Mixture of Experts вимальовується інша оптика на вартість генеративного ШІ. Вона включає не тільки ціну виклику моделі, а й:

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

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

Джерело
https://www.youtube.com/watch?v=SvBheXuKY8s

Microsoft повертається в центр розмови про моделі штучного інтелекту — цього разу вже не лише як партнер, а як самостійний гравець. У подкасті Mixture of Experts від IBM Technology команда фахівців з прикладного ІІ обговорює нові моделі Microsoft MAI-Thinking-1 і MAI-Image-1 та те, як компанія намагається зайняти «середній ринок»: між найдорожчими frontier‑моделями та дешевшими, але ризикованішими рішеннями.

Власні моделі Microsoft: від інфраструктури до повного стеку

На великій дев-конференції Microsoft вперше чітко заявила про власну лінійку foundation‑моделей. Два флагманські релізи — це MAI-Thinking-1 та MAI-Image-1.

MAI-Thinking-1 позиціонують як «35‑мільярдну» модель, але це не просто черговий середній за розміром LLM. Під капотом — архітектура mixture of experts (MoE): загалом це трильйон параметрів, які задіюються частково, маршрутизуючись до приблизно 35 мільярдів активних параметрів залежно від завдання. Тобто йдеться про велику MoE‑систему з багатьма «експертними» підмоделями, що вмикаються під конкретні типи запитів.

Другий реліз — MAI-Image-1, модель для генерації зображень. Її подають як окремий стовп цього ж стеку: текстова «thinking»‑модель для складних задач і образна модель для візуального контенту.

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

Трилійон параметрів і MoE: не абсолютний frontier, але близько

Чи можна вважати MAI-Thinking-1 повноцінною frontier‑моделлю? У дискусії звучить обережна відповідь: «sort of». Тобто це не пік сучасних можливостей, але й далеко не просто «маленька» модель.

Експерти описують її як «дуже велику mixture‑of‑experts‑модель», яка стоїть «десь посередині» між найбільшими, багатотрильйонними системами та класичними середніми LLM. На низці бенчмарків вона, ймовірно, буде конкурентною, на інших — відставатиме. Але загальний рівень оцінюють як «frontend‑ish», «на калібрі open‑source‑моделей OpenAI» з відставанням приблизно на «дев’ять місяців — рік» від найсучасніших рішень.

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

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

«Чисті» датасети й індемніфікація: ставка на регульовані галузі

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

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

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

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

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

Ціна токена як фактор виживання: хто виграє середній ринок

Усі ці технічні та юридичні нюанси врешті впираються в те, що сьогодні хвилює більшість корпоративних замовників: вартість використання моделей. Формулювання в подкасті різкі: «cost is on the top of minds of a lot of enterprises», «організації просто прожигають свої бюджети на токени», аж до того, що деякі «буквально банкрутують, бо витратили забагато на токени».

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

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

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

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

Модель‑роутинг і UX: як архітектура впливає на бізнес‑логіку

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

перша — завжди починати з «дешевої» моделі й ескалювати до великої тільки за потреби;

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

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

MAI-Thinking-1 органічно вписується в таку схему як «середній» шар: достатньо потужний для агентних задач, але дешевший за топові моделі. Її MoE‑архітектура фактично втілює роутинг усередині самої моделі, активуючи різні експерти «залежно від завдання».

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

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

Висновок: Microsoft шукає позицію між потужністю, безпекою й бюджетом

Якщо узагальнити дискусію навколо MAI-Thinking-1 і MAI-Image-1, Microsoft не намагається вистрілити тільки в один параметр. Нові моделі одночасно:

наближаються до frontier‑рівня завдяки трильйонній MoE‑архітектурі;

грають у довгу в юридично чутливих галузях за рахунок ліцензованих, «чистих» датасетів та індемніфікації;

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

Чи вдасться Microsoft реалізувати цю «and‑and‑and»‑стратегію, багато в чому залежатиме від конкретного ціноутворення щодо моделей OpenAI в Azure і від того, наскільки переконливо компанія доведе свою перевагу в безпеці даних. Але сам факт появи такого гравця з повним вертикальним стеком — від дата-центрів до власних моделей — уже змінює розклад сил на ринку й посилює тиск на всіх інших постачальників LLM переглядати ціну кожного токена.

Джерело

Mixture of Experts — Microsoft’s new AI models & bots dominate the internet

Шоу Mixture of Experts від IBM Technology цього разу починається з цифри, яка миттєво змінює оптику на інтернет. Ведучий Тім Хван і його співрозмовники — фахівці з AI‑інфраструктури та впровадження в корпораціях — розбирають нове дослідження Cloudflare: агентні AI‑боти вже генерують більшість веб‑запитів у світі. Звучить як «кінець людського інтернету», але розмова швидко переходить від паніки до більш тверезого питання: що означає така зміна трафіку для того, як ми будуємо веб, показуємо рекламу й фінансуємо контент?

Боти в більшості — не вчорашній шок, а давно встановлений статус-кво

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

Учасники дискусії наголошують, що «bots have outnumbered humans on the web for quite a long time… scrapers different things like that… search engine indexing… automated requests on the web are a pretty big part of it». Тому новина не стільки про раптову зміну, скільки про те, що до традиційних ботів додалася нова масова категорія — агентні AI‑системи, які працюють від імені користувачів.

Саме це й відображає дослідження Cloudflare: «Aentic AI bots generate 57.4 of web requests globally with humans accounting for just 42.6». Ключова деталь — це підрахунок «direct requests to websites». Люди все частіше не заходять безпосередньо на сайти, а натомість ставлять запити своїм AI‑асистентам, і вже ті роблять десятки запитів у бекграунді.

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

UX через агентів: дослідження, пошук, доступ до знань

Одне з найяскравіших зрушень — те, як люди взагалі потрапляють до інформації. «A lot of people are interacting for research tasks through their AI agents these days… rather than people going directly to a site», — зазначають у подкасті.

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

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

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

Веб для людей чи для моделей: LLM.txt як симптом нової епохи

Одна з цікавих деталей, яку наводять учасники, — поява на багатьох документаційних сайтах спеціальних файлів на кшталт LLM.txt (у розмові згадується як «LLM.ext file»). Їхня ідея проста: «a lot of doc sites now have like an LLM.ext file… so the LLM doesn’t have to go and parse like the HTML». Моделі можуть читати компактну, структуровану версію знань без потреби розбирати верстку, меню, банери й інший «людський шар» сторінки.

Це вже практичний крок до світу, де «you may not even need to write websites for humans anymore» — достатньо зробити інформацію «widely accessible to LLMs». З погляду власника ресурсу, головне стає не те, як текст виглядає в браузері, а те, наскільки легко його з’їдають й цитують агенти.

Звідси — низка потенційних сценаріїв:

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

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

Агентна комерція: обіцянка «священного Грааля» ще попереду

У розмові фігурує чіткий поділ на два великі блоки впливу агентного інтернету. Перший — як саме сервіси «serve up information to humans», тобто подають відомості людям у зручному вигляді. Другий — ширший пласт «agentic commerce», або агентної комерції: задачі, де агенти не лише шукають інформацію, а й виконують дії.

Сьогоднішній стан описують так: усе, що пов’язане з ботами, включно з агентними, «is still in that first category… how do you serve up information for humans ultimately to consume in some sort of a distilled manner». Користувачі йдуть у чат‑сервіси — «you go on chat you go on claw you go on perplexity whatever it is you’re looking up for information» — агенти збирають і «distill» інформацію, але фінальне рішення й дії все одно за людиною.

Натомість «the holy grail promise is that hey, you know, there is a world in which agents can go and do [shopping]». Учасники описують класичний сценарій: людина, яка самостійно обирає, наприклад, пару взуття — переглядає десяток варіантів, порівнює ціни, акції, додає в кошик, оформлює доставку й «already tired». Ідеальний агент мав би робити це автономно під задані вподобання, бюджет і контекст.

Зараз, як підкреслюють, «we’ve seen some of those glimpses of it with Perplexity», але це все ще «a couple of years out». Поточний бум агентів у трафіку — це саме інфраструктура для першої категорії (інформаційної дистиляції), а не зріла екосистема повноцінної агентної комерції. Людина «still deciding… which offers you want to take and then go shop around».

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

Реклама під загрозою: якщо агент дивиться, а не людина

Найбільшою економічною змінною в цій картині називають рекламу. В учасників немає сумнівів: «the real commercial impact is what does this mean for the ads business… what does this mean for the ads business I don’t think we have a clear answer on that yet».

Проблема багаторівнева.

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

По-друге, реклама досі — фундаментальна опора для значної частини публічного інтернету. У подкасті прямо артикульовано: «a lot of the content on the internet that we care about like news and journalism and things like that are funded by advertising, right? They have to be». Якщо агентні системи «з’їдають» контент, але не повертають джерелу жодної вартості, модель фінансування новин, розслідувань, аналітики виявляється під питанням.

По-третє, вже зараз відбуваються експерименти з іншими моделями монетизації — платний доступ, преміум‑контент, пейволи. Але, як визнають учасники, «I don’t know where that’s going to land right and I think… figuring out a modern funding model for how does an agent give back to the places where it’s getting content from is not something that’s figured out yet».

Ще одна можлива точка напруги — гіпотетичний сценарій, де агенти не лише читають веб, а й «збирають» собі власні вузькоспеціалізовані сайти «на льоту», комбінуючи фрагменти з різних джерел. У такому всесвіті, де «you actually live in your own internet», класичні рекламні мережі втрачають не лише покази, а й сам об’єкт показу — сторінку як цілісний носій.

AI‑браузери й розщеплення інтернету на два шари

На тлі цих змін у розмові з’являється ще одна лінія — можливе розділення «AI‑native web» і «web that exists today». Йдеться про ситуацію, коли частина інтернету буде з нуля проєктуватись під взаємодію з агентами та моделями, а решта — лишатися переважно людоорієнтованою, з набором «плагінів» та «екстерналів» для роботи з AI.

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

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

Поки що учасники дискусії обережні у висновках: «time will tell on that and how it evolves». Але сама постановка питання про «AI native browsers and AI native web» показує, наскільки серйозно індустрія сприймає можливість, що чат‑інтерфейс і агентні системи можуть стати основним способом взаємодії з інтернетом, а не просто ще одним «режимом» поверх класичного браузера.

Куди це веде: менше паніки, більше питань до бізнес‑моделей

Попри драматичну цифру 57,4%, тон розмови врешті-решт скоріше стриманий. Спікери відзначають, що ми, ймовірно, вже «довгий час жили в інтернеті, де домінують роботи», а сьогоднішні дослідження просто роблять це явище видимим і ставлять незручні запитання.

Головні з них стосуються не стільки технології, скільки економіки й дизайну систем:

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

Учасники обговорення не дають прогнозів, які б претендували на остаточну правду. Навпаки, наголошують: «I don’t think we have a clear answer on that yet». Але факт, що ці питання ставлять уже зараз, у момент, коли боти офіційно стали більшістю веб‑трафіку, означає: конфігурація інтернету як економічної системи — а не лише як технологічної платформи — неминуче зміниться.

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

Джерело

Mixture of Experts — Microsoft’s new AI models & bots dominate the internet

У новому випуску подкасту Silicon Valley Girl професорка Стенфорду й співзасновниця World Labs Фей-Фей Лі та засновник Masterclass Девід Рож’є говорять не стільки про моделі й коди, скільки про людську рису, без якої штучний інтелект легко перетворюється з інструмента на загрозу. Ця риса — агенція: здатність діяти самостійно, брати на себе ризик, формувати власні цілі, а не лише шукати зовнішнього схвалення.

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

Підприємництво як синонім агенції

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

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

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

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

Безпека, провали й резилієнтність: з чого складається агенція

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

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

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

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

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

Культура похвали проти культури власного голосу

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

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

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

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

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

Чому нове покоління має перевагу

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

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

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

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

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

Століття інструментів і зростання ваги особистого голосу

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

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

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

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

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

Як працювати з агенцією — у собі й у дітях

Коли розмова переходить до практики, обидва співрозмовники визнають: універсальних рецептів немає. Але є конкретні підходи, які вони використовують у власних командах і сім’ях.

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

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

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

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

Висновок: агенція як головна навичка AI-століття

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

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

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

Джерело

Godmother of AI: In 10 Years There Will Be Only 2 Kinds of Workers