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

Від Tesla‑візії до української реальності: з чого складається автономний дім

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

У центрі цієї моделі — енергетична незалежність. Сонячні панелі на даху або на ділянці забезпечують генерацію, домашні батареї накопичують енергію, а електромобіль виступає додатковим мобільним сховищем. Тут легко впізнати ідею, яку роками просував Ілон Маск: Tesla як не просто виробник машин, а як екосистема для автономного будинку — від Solar Roof до Powerwall і електрокара в гаражі.

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

Окремий блок — водопостачання. Ведучі наголошують: сучасні технології буріння дозволяють добути воду майже будь-де, якщо йдеться про достатню глибину. Йдеться про глибинні свердловини на сотні метрів, які відкривають доступ до артезіанських вод. Орієнтовна вартість такого буріння, за їхніми словами, становить близько 4 000–9 000 доларів США. Це одна з ключових капітальних інвестицій на шляху до автономності, але вона радикально змінює статус будинку: з «об’єкта, підключеного до мережі» він перетворюється на власника власного джерела.

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

І, нарешті, третій стовп автономності — зв’язок. Тут на сцену виходить Starlink.

Starlink як нервова система автономного будинку

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

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

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

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

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

Локалізація як відповідь на крихкість глобалізації

Обговорення автономного житла в «УТ‑2» природно переходить у ширшу тему — трансформацію глобальних ланцюгів постачання. Ведучі згадують, як разом із Ярославом Мажнюком аналізували чергові «Request for Startups» і дійшли висновку: американці поступово «розчехляються» й усвідомлюють, що радикально глобалізовані ланцюги — це не лише економічна ефективність, а й серйозна вразливість.

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

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

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

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

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

Від «оф‑грід» хобі до інфраструктурної стратегії

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

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

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

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

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

Локалізація інфраструктури: від будинку до країни

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

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

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

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

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

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

Розмова на «УТ‑2» показує, що тема автономного житла виходить за межі технічних дискусій про сонячні панелі чи супутниковий інтернет. Йдеться про зміну базової моделі мислення щодо інфраструктури.

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

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

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

Джерело

Тім Кук на пенсію: 15 років без інновацій. Robinhood роздає гроші хакерам. mvc #26

У корпоративному світі AI‑агентів та інструментів на базі Model Context Protocol (MCP) розрив між зручністю для розробників і вимогами безпеки стає дедалі помітнішим. Кожне підключення нового MCP‑сервера означає ще один OAuth‑флоу, ще один екран згоди, ще один набір токенів, які потрібно обслуговувати. Попри наявність Single Sign‑On (SSO), користувачі знову й знову проходять авторизацію в одних і тих самих системах.

Гаррет Галоу, керівник продукту в WorkOS, який раніше будував enterprise‑платформи для розробників у Microsoft Azure та Cloudflare, пропонує іншу модель. WorkOS забезпечує автентифікацію для того, щоб застосунки та AI‑агенти були «enterprise‑ready», і вже сьогодні стоїть за логіном у таких продуктах, як Anthropic, Cursor та OpenAI. У своїй доповіді він описує Cross‑App Access (XAA) та специфікацію Identity JWT Authorization Grant (ID‑JAG) — механізм, що перетворює один SSO‑вхід у множину короткоживучих токенів доступу до різних MCP‑серверів.

Коли SSO не рятує: як MCP множить OAuth‑флоу

MCP сьогодні покладається на OAuth як базовий шар автентифікації. Для кожного MCP‑сервера — Figma, Notion чи будь‑якого іншого — MCP‑клієнт на кшталт Cursor або Claude ініціює окремий OAuth‑флоу з власним екраном згоди. Користувачеві доводиться підтверджувати: так, Cursor може отримати доступ до мого Figma‑акаунта; так, Claude може працювати з моїми документами в іншому сервісі.

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

Теоретично SSO мав би розв’язати цю проблему. Працівник компанії входить через Okta чи Microsoft Entra, отримує єдину сесію і далі безшовно працює з усіма корпоративними застосунками. Але MCP руйнує цю модель: протокол виходить з того, що застосунки не знають одне про одного, не мають спільного уявлення про користувача і не можуть покладатися на вже встановлену довіру. У результаті SSO існує, але не використовується як єдине джерело істини для AI‑агентів, які ходять у різні сервіси.

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

Тристороння довіра: як XAA використовує Identity Provider як посередника

Cross‑App Access (XAA) пропонує змінити точку опори. Замість того, щоб кожен MCP‑клієнт напряму будував довіру з кожним MCP‑сервером через окремі OAuth‑флоу, XAA використовує вже наявну довіру до корпоративного Identity Provider (IDP) — Okta, Entra чи іншого.

У типовій архітектурі, яку демонструє Галоу, є три ключові учасники. MCP‑клієнт — наприклад, Cursor або Claude. MCP‑сервер — Figma, що надає API й MCP‑ендпоінт. І IDP — Okta, через яку співробітники компанії вже входять у всі свої застосунки.

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

Суть у тому, що Identity Provider стає посередником довіри між MCP‑клієнтом і MCP‑сервером. Клієнт не просить Figma про доступ напряму, а звертається до Okta з проханням видати спеціальний токен, який Figma визнає як достатній доказ того, що:

користувач автентифікований через SSO;
користувач є членом і клієнтського застосунку (Cursor/Claude), і серверного (Figma);
IT‑адміністратор дозволив саме цьому клієнту запитувати доступ до саме цього сервера.

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

ID‑JAG: специфікація, що перетворює SSO‑сесію на крос‑аплікейшн токен

Технічно XAA реалізується через специфікацію Identity JWT Authorization Grant (ID‑JAG). Попри громіздку назву, її роль відносно проста: визначити, як і в якому форматі ідентифікаційні твердження (assertions) від IDP можуть бути обміняні на токен, придатний для доступу до іншого застосунку.

У демонстраційній схемі з Claude, Figma й Okta ланцюжок виглядає так.

Спочатку користувач один раз входить у Claude через SSO в Okta. Це стандартний OIDC‑флоу: після успішної автентифікації Claude отримує від Okta ID‑токен і refresh‑токен. Ці токени засвідчують особу користувача і дають змогу оновлювати сесію без повторного логіну.

Далі, коли Claude хоче підключитися до Figma як до MCP‑сервера, він не показує користувачеві новий екран згоди. Натомість клієнт звертається назад до Okta і, посилаючись на вже отримані ID‑токен або refresh‑токен, просить видати ID‑JAG‑токен, який буде дійсним саме для Figma.

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

Ключовий момент у тому, що перед видачею такого токена IDP виконує перевірку членства. Okta має інформацію про те, до яких застосунків підключений користувач, і про те, які крос‑аплікейшн‑зв’язки дозволені IT‑адміністратором. Тому, перш ніж видати ID‑JAG‑токен, вона перевіряє, чи є користувач членом як MCP‑клієнта (Claude), так і MCP‑сервера (Figma), і чи дозволено Claude запитувати доступ до Figma.

Якщо відповідь позитивна, IDP видає ID‑JAG‑токен, який Claude може пред’явити Figma як доказ того, що:

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

Як XAA вбудовується в існуючий OAuth‑ландшафт MCP‑серверів

З боку MCP‑сервера XAA не вимагає радикальної перебудови. У прикладі з Figma архітектура розділена на два компоненти: ресурсний сервер (власне Figma API та MCP‑сервер) і сервер авторизації, який видає OAuth‑токени.

Коли Claude отримує ID‑JAG‑токен від Okta, він надсилає його не безпосередньо в API Figma, а в компонент авторизації Figma. Повідомлення по суті звучить так: «Ось ID‑JAG‑токен для цього користувача від нашого спільного IDP. Перевірте його і, якщо все гаразд, видайте мені звичайний OAuth‑access‑токен».

Сервер авторизації Figma, маючи власну інтеграцію з Okta, верифікує ID‑JAG‑токен у IDP. Якщо токен дійсний, не прострочений і відповідає дозволеній конфігурації крос‑доступу, Figma видає Claude стандартний OAuth‑access‑токен.

На цьому етапі XAA‑специфіка закінчується, а далі починається звичайний MCP‑флоу. Claude використовує отриманий OAuth‑токен, щоб звертатися до MCP‑сервера Figma, а той — до свого API. Для MCP‑сервера це виглядає як звичайний клієнт із коректним OAuth‑токеном; не потрібно підтримувати новий тип облікових даних або змінювати семантику доступу.

Важливо, що XAA на цьому етапі зосереджується саме на автентифікації та встановленні довіри між застосунками. Він не змінює моделі авторизації всередині Figma чи інших MCP‑серверів: які саме дії може виконувати агент, як налаштовані ролі й дозволи — усе це залишається в межах існуючих механізмів самого сервісу. Специфікація ID‑JAG наразі не визначає «урізані» або спеціально скоуплені гранти для крос‑аплікейшн‑доступу; вона лише описує, як безпечно перенести ідентичність користувача з одного застосунку в інший через IDP.

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

У демонстрації з Claude‑клієнтом, Figma‑сервером і Okta як IDP користувацький досвід радикально відрізняється від класичного MCP‑сценарію.

Спочатку користувач відкриває Claude і проходить SSO‑логін через Okta. Це може бути перший вхід за день або за тиждень — залежно від політик організації. Після успішної автентифікації Claude отримує ID‑токен і refresh‑токен і зберігає їх локально.

Далі, коли користувач відкриває список MCP‑серверів у Claude, Figma вже відображається як підключена. Немає додаткового вікна браузера, немає окремого екрану згоди, немає ручного підтвердження доступу. Підключення відбулося «автоматично», але не за рахунок прихованих API‑ключів чи небезпечних практик, а завдяки тому, що за лаштунками відпрацював XAA‑флоу з ID‑JAG‑токеном.

Для користувача це виглядає як справжній «one login to rule them all»: один вхід через корпоративний IDP відкриває шлях до всіх дозволених MCP‑серверів, без повторних авторизацій і без плутанини з тим, чому той чи інший інструмент раптом «забув» попередню згоду.

Для IT‑відділу це означає, що всі ці підключення відбуваються в рамках контрольованої моделі. Адміністратори в IDP явно визначають, який застосунок може запитувати доступ до якого іншого. У налаштуваннях Okta вони конфігурують Cross‑App Access, встановлюючи, наприклад, що Claude має право отримувати ID‑JAG‑токени для Figma, але не для якогось іншого, небажаного сервісу. Якщо політика змінюється, адміністратор оновлює її в одному місці — в IDP.

Короткоживучі токени й залежність від SSO‑сесії

Ще одна важлива характеристика XAA‑патерну — те, як він працює з часом життя токенів. У класичному OAuth‑сценарії MCP‑клієнт часто отримує довгоживучі access‑токени або refresh‑токени, які можуть залишатися дійсними днями чи тижнями. Якщо користувач звільняється або його обліковий запис компрометовано, ці токени можуть продовжувати давати доступ до сервісів, навіть коли SSO‑доступ уже відкликано.

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

При цьому MCP‑клієнт не змушений турбувати користувача кожні п’ять хвилин. Поки SSO‑сесія в IDP активна, Claude або Cursor можуть повторювано отримувати нові ID‑JAG‑токени, пред’являючи refresh‑токен або інше первинне твердження, і обмінювати їх на свіжі access‑токени для MCP‑серверів — усе це без додаткової взаємодії з користувачем.

Якщо ж SSO‑сесію в IDP відкликано, користувач втратив доступ до застосунку або його обліковий запис деактивовано, ланцюжок обривається. MCP‑клієнт більше не може отримати нові ID‑JAG‑токени, а отже, після закінчення строку дії поточного короткоживучого access‑токена доступ до MCP‑серверів автоматично припиняється. Це повертає контроль у руки IT‑відділу: достатньо відкликати сесію або доступ у IDP, щоб через кілька хвилин AI‑агенти втратили можливість звертатися до корпоративних сервісів.

Підтримка з боку IDP та роль адміністраторів

Щоб XAA працював, потрібна підтримка з боку Identity Provider. У випадку Okta така підтримка вже є для OIDC‑підключень, а в планах — розширення на SAML‑базовані інтеграції. Це означає, що застосунки, які вже використовують Okta як IDP через OpenID Connect, можуть поступово додавати підтримку ID‑JAG і Cross‑App Access без повної перебудови своїх auth‑флоу.

Натомість Microsoft Entra на момент виступу ще не підтримує XAA або ID‑JAG. Це обмежує можливості організацій, які повністю покладаються на Entra як на єдиний IDP, але водночас задає вектор розвитку: якщо патерн XAA приживеться, іншим постачальникам ідентичності доведеться наздоганяти.

IT‑адміністратори відіграють центральну роль у цій моделі. Саме вони в IDP визначають, який застосунок може запитувати доступ до якого іншого. У термінах Okta це означає конфігурацію Cross‑App Access: наприклад, дозволити Claude запитувати ID‑JAG‑токени для Figma, але заборонити будь‑яким іншим AI‑клієнтам робити те саме. Таким чином, навіть якщо користувач спробує підключити «лівий» MCP‑клієнт до корпоративного Figma, без відповідної XAA‑конфігурації в IDP це буде неможливо.

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

Висновок: XAA як міст між зручністю AI‑агентів і вимогами enterprise

Model Context Protocol відкриває шлях до потужних крос‑аплікейшн‑AI‑воркфлоу, але традиційна модель OAuth у цьому контексті виявляється незручною і для користувачів, і для адміністраторів. Cross‑App Access і специфікація ID‑JAG пропонують спосіб використати вже існуючу довіру до корпоративного Identity Provider, щоб перетворити один SSO‑логін на множину контрольованих, короткоживучих токенів доступу до MCP‑серверів.

У прикладі з Claude, Figma та Okta видно, як це працює на практиці: користувач входить один раз, а далі MCP‑клієнт непомітно для нього обмінює SSO‑сесію на ID‑JAG‑токени й стандартні OAuth‑access‑токени для різних сервісів. При цьому зберігається сумісність з існуючими OAuth‑механізмами, а контроль над тим, хто до чого має доступ, концентрується в IDP.

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

Джерело

One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

Коли компанії запускають перші пілоти з генеративним AI, усе часто починається з простого скрипта й таблиці. Але саме на етапі переходу від «воно працює в демо» до «воно стабільно працює в продакшені» більшість команд застрягає. Про цю прірву між proof‑of‑concept і реальними продуктами говорить Філ Гецел, керівник напрямку solutions engineering у Braintrust — платформі, що позиціонує себе як «agent quality platform» з фокусом на evals та observability. До Braintrust він 12 років працював у консалтингу в KPMG та Slalom, де очолював глобальний підрозділ Databricks.

Його досвід з десятками клієнтів показує: побудувати ефектний прототип на LLM сьогодні вміють багато хто, а от довести агентів до надійного продакшену — одиниці. Ключова причина — відсутність зрілих підходів до оцінювання (evals) та спільних визначень якості. Історія еволюції eval‑воркфлоу — від for‑loop і Google Sheets до колаборативних платформ — добре показує, чому без цього ланцюжка інфраструктури AI‑проєкти так часто «застигають» на стадії експериментів.

Чому простий for‑loop і таблиця працюють… лише на старті

Початковий сценарій знайомий майже кожній команді, що пробує LLM‑агентів. Є якийсь сервіс або агент, є набір вхідних прикладів, є простий скрипт — зазвичай це банальний for‑loop, який проганяє всі інпути через модель. Результати потрапляють у Google Sheets чи Excel, де команда руками виставляє оцінки, залишає коментарі, фіксує помилки.

На цьому етапі є три базові компоненти:

1. спосіб виконати агента (скрипт або невеликий сервіс),
2. UI для перегляду відповідей (таблиця),
3. спосіб зібрати «input examples» — запити чи контексти, які запускають агента.

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

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

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

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

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

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

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

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

Власний UI та база даних: перша спроба навести лад

Наступний логічний крок для багатьох команд — вийти за межі Google Sheets і побудувати внутрішній інструмент. Типовий сценарій виглядає так: продуктова чи AI‑команда «на коліні» збирає веб‑інтерфейс, підключає базу даних (часто щось на кшталт Neon чи іншого керованого Postgres), переносить туди логіку for‑loop і починає зберігати результати eval‑запусків централізовано.

Це вже суттєвий прогрес. З’являється:

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

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

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

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

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

Eval як командна гра: чому платформа має бути спільною мовою

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

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

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

Тому eval‑платформа в зрілому вигляді — це не просто «тест‑раннер», а місце, де ці різні перспективи зводяться разом. Вона має:

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

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

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

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

У практиці Braintrust це виглядає як «playground‑стиль» інтерфейсу. Користувач отримує доступ до конкретної конфігурації агента й може в UI змінювати певні параметри — наприклад, системні інструкції (system prompt). Поруч — можливість запустити eval на двох різних конфігураціях і побачити, як змінюються оцінки.

Такий підхід змінює динаміку роботи:

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

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

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

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

Як еволюція eval‑воркфлоу допомагає дійти до продакшену

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

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

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

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

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

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

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

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

Джерело

YouTube: Why building eval platforms is hard — Phil Hetzel, Braintrust

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

Коли озеро може «ніколи не існувати»: крихкість ландшафтів

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

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

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

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

Між виживанням і збереженням: пошук іншого шляху

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

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

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

Манґрові, краби й туризм: як консервація стає бізнесом

На узбережжі Індійського океану, в окрузі Кіліфі, біля Ватаму, формується модель того, як може виглядати «переосмислена консервація».

Двадцять років тому місцева група Dabaso, спираючись на дослідження та співпрацю, почала висаджувати манґрові ліси. Це рішення не було популярним: учасники стикалися з образами, насмішками, сумнівами. Проте послідовна робота дала результат:

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

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

Повернення лісів і порятунок озера: коли «що, якби» стає реальністю

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

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

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

Любов як рушійна сила консервації

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

Він пропонує іншу опору — пошук чогось більшого за власні інтереси. У центрі цієї ідеї — любов як основа консервації:

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

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

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

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

Уява як перший крок до змін

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

Як показують історії з Кенії — від манґрових у Ватаму до лісів Мачакосу й озера Ол’ Болоссат — уява, підкріплена дослідженнями, співпрацею та любов’ю до місця, може перетворювати «що, якби» на реальні зміни.

Джерело

Conservation: A Love Story | Elsaphan Njora | TED

У нещодавньому епізоді подкасту OpenAI дослідники Себастьян Бюбек та Ернест Рю, колишні професори математики, які перейшли в індустрію штучного інтелекту, обговорюють, як сучасні моделі вже не просто «роблять математику», а беруть участь у справжніх наукових відкриттях. Один із найяскравіших прикладів — історія Ернеста Рю, який за допомогою ChatGPT зміг розв’язати відкриту задачу в теорії оптимізації, що залишалася нерозв’язаною 42 роки.

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

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

До літа 2025 року ChatGPT уже продемонстрував результат, який ще кілька років тому виглядав фантастичним: модель досягла рівня золотого призера Міжнародної математичної олімпіади. Це означає, що вона здатна розв’язувати складні, але все ж «канонічні» задачі з відносно короткими розв’язками, які хтось уже придумав і для яких існує відома відповідь.

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

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

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

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

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

Загальна картина була відносно добре зрозуміла: у «нормальних» умовах метод Нестерова поводиться добре й збігається до розв’язку. Але в теорії оптимізації завжди є питання про найгірший випадок. І саме тут десятиліттями залишалася прогалина:

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

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

Відповідь виявилася ствердною: так, у найгіршому випадку метод може дивергувати. І саме до цього висновку Рю дійшов у співпраці з ChatGPT.

40 годин проти 12: як змінилася динаміка пошуку доведення

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

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

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

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

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

Людина як верифікатор, ШІ як генератор: новий поділ праці в математиці

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

Рю робив кілька речей одночасно.

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

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

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

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

Подвійна перевірка: чому Рю довірив, але не «здався» моделі

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

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

Цей момент важливий з двох причин.

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

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

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

Чому кейс Нестерова важливий: від пошуку в літературі до справжнього відкриття

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

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

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

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

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

Математика як полігон для ШІ: чому саме тут видно якісну зміну

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

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

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

Два роки тому, як нагадує Бюбек, не існувало спеціалізованих «reasoning models», здатних доводити складні теореми. Сьогодні, за його словами, моделі вже можуть допомагати навіть лауреатам Філдсівської медалі в їхній повсякденній роботі.

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

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

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

Джерело

Подкаст OpenAI: «What happens now that AI is good at math? — the OpenAI Podcast Ep. 17»

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

«Якщо ШІ мене замінить, я хоча б зароблю на цьому»

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

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

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

Парадокс: ненавидіти ШІ й одночасно в нього інвестувати

Складається парадоксальна ситуація. Люди, які:

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

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

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

Як OpenAI виходить на роздрібних інвесторів через Robinhood

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

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

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

ШІ як новий клас «захисних» активів?

Традиційно люди хеджували ризики втрати доходу через:

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

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

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

Джерело

YouTube: Retail investors are betting on AI replacing them

У світі розробки програмного забезпечення зараз відбувається тиха, але радикальна зміна: IDE перестають бути просто «редакторами з підказками» і перетворюються на середовища, де основну роботу виконують агенти. Один із найяскравіших прикладів цієї трансформації — Cursor, інструмент, над яким працює інженер з developer experience та продукту Ерік Закаріассон. Він активно «догфудить» Cursor у власній щоденній роботі, намагаючись підштовхнути розробку до вищих рівнів автономії — аж до концепції «software factory».

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

Від таба до агента: як народився Cursor

Початкова версія Cursor з’явилася приблизно у 2022–2023 роках і була типовим продуктом своєї епохи: VS Code‑базований редактор з «spicy autocomplete» — агресивнішим, контекстнішим автодоповненням, ніж звикли бачити розробники. Фактично це був еволюційний крок від класичних підказок коду до інструменту, який уже міг пропонувати цілі блоки логіки, а не лише завершувати рядки.

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

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

Чому довелося вийти з тіні VS Code

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

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

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

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

Рівні автономії: від парного програмування до «чорної фабрики»

Щоб зрозуміти, де зараз знаходяться інструменти на кшталт Cursor, Закаріассон апелює до ідеї рівнів автономії в розробці ПЗ. У спрощеному вигляді ця шкала описує шлях від ручного програмування з підказками до повністю автоматизованої «software factory».

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

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

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

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

Навіщо взагалі прагнути «програмної фабрики»

Ідея «фабрики ПЗ» звучить привабливо, але за нею стоять цілком прагматичні мотиви.

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

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

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

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

Примітиви та патерни: як підготувати код до агентів

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

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

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

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

Показовий приклад — демо‑проєкт «music agent», який Закаріассон зібрав повністю через агентів, не пишучи код вручну. Інтерфейс нагадує Ableton чи інше музичне ПЗ: таймлайни, кліпи, кнопки відтворення. Щоб агент зміг самостійно запустити дев‑сервер, йому достатньо було знайти package.json і стандартний start‑скрипт. Такі файли настільки «в розподілі» для сучасних моделей, що вони інтуїтивно шукають їх першими. Якщо проєкт дотримується цих звичних патернів, агент без додаткових підказок здогадується, як його запустити.

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

Правила як живий SOP: чому не варто ставити все одразу

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

Разом із запуском цієї системи Cursor опублікував «каталог» правил — cursor directory — з прикладами для різних стеків, зокрема для Next.js. Логічною, але помилковою реакцією багатьох користувачів стало бажання «поставити все»: якщо є набір правил для мого фреймворку, чому б не підключити їх усі?

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

У цьому сенсі agents.md більше схожий на живий SOP (standard operating procedure), ніж на статичний конфіг. Він еволюціонує разом із проєктом, відображаючи реальні граблі, на які наступають агенти. Із покращенням моделей, які дедалі краще слідують інструкціям, така система стає ще ефективнішою: достатньо чітко сформулювати правило, і агент рідше виходитиме за його межі.

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

Перевірка й середовище: що потрібно агенту, щоб працювати самостійно

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

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

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

У тому ж демо‑проєкті з музичним агентом для цього використовуються end‑to‑end тести на Playwright. Вони дозволяють агентам програмно взаємодіяти з UI: натискати кнопки відтворення, редагувати ноти, перевіряти, що інтерфейс поводиться як очікується. Це дає можливість не просто згенерувати код, а й автоматично довести, що він працює.

Не менш важливе питання — середовище виконання. Чи може агент самостійно запустити дев‑сервер? Чи достатньо йому сказати «start my project», щоб він, орієнтуючись на звичні патерни на кшталт npm start, підняв локальне середовище без участі людини? Якщо відповідь «так», це відкриває шлях до масштабування: ті самі сценарії можна запускати паралельно на безлічі окремих віртуальних машин.

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

Життя на рівні 4: як виглядає щоденна робота з агентами

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

формулює наміри й задачі, які передає агентам;

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

реактивно додає правила в agents.md, коли агенти починають поводитися некоректно;

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

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

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

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

Висновок: Cursor 3 як крок до фабрики, а не її фінальна версія

Еволюція Cursor — від VS Code‑базованого «гострого автодоповнення» у 2022–2023 роках до окремого агент‑першого застосунку Cursor 3 — добре ілюструє ширший тренд у розробці ПЗ. IDE перестають бути просто інструментами для людей і стають середовищами, де людина й агенти працюють як команда, а з часом — як менеджер і фабрика.

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

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

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

Джерело

YouTube: Building your own software factory — Eric Zakariasson, Cursor

У новому випуску технологічного шоу «УТ‑2» ведучі Саня, Ілля та Юра обговорюють те, що ще кілька років тому виглядало чистою науковою фантастикою: повноцінний аналіз власної ДНК вдома, буквально на кухні. Відправна точка розмови — історія лікаря, який секвенував свою ДНК за допомогою Oxford Nanopore MinION, NVIDIA DGX Spark та Apple Mac Studio, щоб не віддавати генетичні дані комерційним сервісам. Далі дискусія виходить на ширший контекст: що означає масове ДНК‑тестування для українців, чому MyHeritage вважають оптимальним сервісом, як ШІ‑моделі на кшталт Claude вже зараз інтерпретують сирі генетичні дані — і де проходить межа між корисною діагностикою та небезпечною тривожністю.

Лабораторія на кухні: MinION, DGX Spark і Mac Studio замість конверта зі слиною

Історія, яка задає тон розмові, звучить як типовий сюжет для Reddit, але вже цілком реалістичний з погляду сучасних технологій. Лікар, про якого говорять ведучі, зібрав у себе на кухні імпровізовану генетичну лабораторію. У центрі сетапу — портативний секвенатор Oxford Nanopore MinION, невеликий прилад, у який буквально «запихають слину» і отримують послідовність ДНК. Для обробки даних він використав NVIDIA DGX Spark — по суті, «Mac Studio від NVIDIA» за приблизно 5 тисяч доларів, тобто компактний, але дуже потужний обчислювальний вузол, — а також справжній Apple Mac Studio.

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

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

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

23andMe, MyHeritage, AncestryDNA: ринок ДНК‑тестів і український контекст

У США ринок споживчих ДНК‑тестів багато років був трикутником із трьох великих гравців: 23andMe, MyHeritage та AncestryDNA. Ведучі описують їх як основні платформи, через які мільйони людей дізнавалися про своє походження, потенційні генетичні ризики та далеких родичів. При цьому 23andMe, яку часто сприймали як флагманський бренд і піонера в цій сфері, за їхніми словами, уже збанкрутувала.

Для українців у цій трійці особливо виділяється MyHeritage. У попередньому випуску «УТ‑2» гість Богдан Логвиненко рекомендував саме цей сервіс як найкращий вибір для пошуку родичів зі Східної Європи. Причина проста й прагматична: у MyHeritage велика база користувачів саме з цього регіону, а отже, ймовірність знайти генетичних родичів, реконструювати родинні гілки, втрачені через війни, депортації та міграції, суттєво вища.

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

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

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

Від 23andMe до Claude: як ШІ вчиться читати сирі ДНК‑дані

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

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

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

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

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

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

ДНК як новий «пін‑код»: приватність, біозброя і далекоглядні ризики

Один із ведучих порівнює ДНК із набором PIN‑кодів від кредитних карток. Метафора груба, але влучно передає відчуття вразливості. Генетичний профіль — це не просто ще один ідентифікатор, який можна змінити, як пароль. Це незмінна біологічна основа, яка пов’язує людину з її родичами, минулим і потенційними майбутніми діагнозами.

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

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

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

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

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

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

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

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

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

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

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

Між автономією і довірою: куди рухається персональна генетика

Домашній аналіз ДНК на MinION із DGX Spark і Mac Studio, масові сервіси на кшталт MyHeritage, можливість завантажити сирі дані з 23andMe й прогнати їх через Claude — усе це елементи однієї великої трансформації. Генетика виходить із лабораторій у побут, стає частиною особистої цифрової екосистеми поряд із банкінгом, фітнесом і розвагами.

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

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

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

Джерело

Тім Кук на пенсію: 15 років без інновацій. Robinhood роздає гроші хакерам. mvc #26

У світі AI-інструментів для розробників Model Context Protocol (MCP) швидко стає стандартом для підключення агентів до зовнішніх сервісів — від Figma до Notion. Але разом із цим з’являється й знайома всім хвороба: нескінченні OAuth-екрани згоди, зламані сесії, «забуті» підключення та головний біль для IT-відділів.

Про те, чому саме поточна модель автентифікації MCP не масштабується для крос-додаткових AI-воркфлоу, розповідає Ґаррет Ґалоу, керівник продукту WorkOS. Він понад десять років будував enterprise-платформи для розробників у Microsoft Azure та Cloudflare, а зараз його компанія забезпечує автентифікацію для Anthropic, Cursor та OpenAI — тобто знаходиться прямо в центрі MCP- та агентної екосистеми.

Коли кожен MCP-сервер — це ще один OAuth-квест

Сьогодні MCP покладається на OAuth як базовий шар автентифікації. На папері це виглядає логічно: є клієнт (наприклад, Cursor чи Claude), є MCP-сервер (скажімо, Figma), між ними — стандартний OAuth-флоу з редіректом у браузер і consent screen, де користувач підтверджує доступ.

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

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

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

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

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

Чому SSO не рятує, навіть якщо в компанії все «по-ентерпрайзному»

Більшість організацій уже живуть у світі Single Sign-On. Працівники заходять у всі свої інструменти через єдиний Identity Provider — Okta, Microsoft Entra чи іншу систему. З точки зору користувача це «один логін до всіх додатків», а з точки зору IT — централізований контроль доступу.

Здавалося б, якщо вже є SSO, проблема повторних входів мала б зникнути. Але в MCP-реальності цього не стається. Причина в тому, що SSO й OAuth працюють на різних рівнях:

• SSO забезпечує єдину сесію між користувачем і Identity Provider’ом;
• OAuth — окремі гранти доступу між кожною парою «MCP-клієнт ↔ MCP-сервер».

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

Для кодувальних агентів це означає, що:

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

Фактично, SSO вирішує проблему «скільки разів я вводжу пароль», але не вирішує проблему «скільки разів я маю натискати “Allow” і скільки різних токенів живе у моїх інструментах».

Крихкі токени й сліпі зони для IT: як MCP ускладнює безпеку

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

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

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

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

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

У локальному середовищі розробника можуть залишатися:

• збережені OAuth access tokens;
• refresh tokens, які дозволяють отримувати нові access tokens;
• API-ключі та інші облікові дані, не пов’язані безпосередньо з IDP.

У контексті MCP це означає, що навіть після звичайного offboarding’у співробітника або після інциденту безпеки:

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

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

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

Досвід WorkOS: коли автентифікація стає інфраструктурною проблемою AI

Те, що сьогодні виглядає як «дрібна незручність» для розробника, насправді є типовою інфраструктурною проблемою, з якою enterprise-світ стикається вже багато років. І саме тут досвід WorkOS виявляється показовим.

Компанія позиціонує себе як шар автентифікації, який робить додатки та AI-агентів готовими до вимог підприємств. Вона вже забезпечує auth для таких гравців, як Anthropic, Cursor та OpenAI. Тобто всі ті інструменти, які сьогодні активно інтегрують MCP і будують навколо нього агентні сценарії, фактично працюють поверх WorkOS або подібних рішень.

Ґаррет Ґалоу до WorkOS багато років займався саме enterprise-платформами для розробників у Microsoft Azure та Cloudflare. Це означає, що:

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

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

Чому поточна модель MCP неминуче ламається в крос-додаткових сценаріях

Якщо подивитися на MCP не як на окрему технологію, а як на інфраструктуру для крос-додаткових AI-воркфлоу, стає зрозуміло, чому сьогоднішня OAuth-модель не масштабується.

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

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

По-третє, SSO залишається «островом», не інтегрованим у MCP-флоу. Хоча і MCP-клієнти, і MCP-сервери вже довіряють одному й тому ж IDP, ця довіра не використовується для встановлення зв’язку між ними. Замість цього кожна пара змушена розігрувати власну міні-історію з OAuth, ніби жодної спільної точки довіри не існує.

По-четверте, життєвий цикл токенів розходиться з життєвим циклом доступу. SSO-сесія може бути відкликана, але refresh tokens у локальних інструментах продовжують жити. IT-адміністратори втрачають можливість гарантувати, що «відкликання доступу в IDP означає повну втрату доступу до всіх пов’язаних сервісів».

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

Куди рухається екосистема: MCP, агенти й enterprise-готовність

Той факт, що WorkOS уже сьогодні забезпечує автентифікацію для Anthropic, Cursor і OpenAI, показує, що питання enterprise-готовності агентів перестало бути теоретичним. Це не «майбутнє, яке колись настане», а реальність, у якій великі компанії вже тестують і впроваджують AI-агентів у свої процеси.

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

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

Поточна модель, заснована на ізольованих OAuth-грантах між кожною парою клієнт–сервер, очевидно, не задовольняє ці вимоги. Вона створює надмірну кількість точок взаємодії, не використовує вже наявну довіру до IDP і залишає IT без повного контролю над тим, як агенти взаємодіють із корпоративними даними.

Саме тому в екосистемі MCP з’являються нові підходи, які намагаються переосмислити, як має виглядати автентифікація в світі крос-додаткових AI-воркфлоу. Одним із таких підходів є Cross-App Access (XAA), який використовує Identity Provider як посередника довіри між MCP-клієнтом і MCP-сервером та будується на специфікації Identity JWT Authorization Grant (ID-JAG).

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

Висновок: MCP потребує нового шару довіри, а не ще одного екрану згоди

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

Досвід WorkOS, Anthropic, Cursor та OpenAI показує, що автентифікація для AI-агентів перестала бути другорядною технічною деталлю. Це фундаментальний елемент інфраструктури, від якого залежить, чи зможуть агенти безпечно й передбачувано працювати з десятками корпоративних сервісів одночасно.

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

Джерело

One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

У 2026 році все більше розробників працюють у середовищах на кшталт Claude Code, Cursor чи Codeex, де значну частину рутини беруть на себе AI‑асистенти. Але як тільки справа доходить до реальних баз даних, усе різко ускладнюється: конфігурація, ризик «вбити» продакшн‑дані, вартість інфраструктури та відсутність у моделей стійкої пам’яті.

У новому відео на каналі Tech With Tim демонструється інший підхід: під’єднати Claude Code до спеціальної AI‑орієнтованої бази даних Ghost.build через протокол MCP (Model Context Protocol). У результаті Claude отримує можливість самостійно створювати, форкати, видаляти й запитувати бази даних — нативно, всередині IDE, без ручного керування інфраструктурою.

Цей матеріал розбирає, як саме працює Ghost.build, як його встановити, що дає інтеграція через MCP і чому це фактично перетворює Claude Code на інструмент із «постійною пам’яттю».

AI‑рідна база даних: що таке Ghost.build і навіщо вона Claude

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

У типовому стеку розробник піднімає PostgreSQL або іншу СУБД, налаштовує користувачів, права, підключення, середовище, а потім обережно дозволяє AI‑асистенту щось із цим робити. Кожен неправильний DELETE чи ALTER TABLE може коштувати дорого. Ghost.build пропонує іншу модель: бази даних створюються, форкаються, переліковуються та видаляються самим агентом через MCP‑сервер, який виступає посередником між AI‑інструментом і інфраструктурою.

У практиці це виглядає так: Claude Code отримує набір інструментів, що дозволяють:

• створювати нові бази даних під конкретні задачі;
• форкати існуючі бази для експериментів;
• виконувати SQL‑запити;
• перераховувати всі доступні бази;
• видаляти непотрібні екземпляри.

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

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

Безкоштовний рівень і сценарії використання: від «пам’яті» Claude до одноразових БД

Ghost.build надає безкоштовний тариф, який за своїми параметрами більше схожий на майданчик для серйозних експериментів, ніж на обмежений демо‑режим. У фрі‑план входить 100 обчислювальних годин на місяць, 1 ТБ сховища та необмежена кількість баз даних і форків.

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

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

Навіть якщо Claude Code закрити, база даних продовжує існувати на стороні Ghost.build. Повернувшись до роботи, можна попросити Claude перелічити всі бази, до яких він має доступ через Ghost, і модель побачить раніше створені схеми. Це вже не просто «чат із пам’яттю», а повноцінний робочий простір, де дані живуть незалежно від сесій.

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

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

Водночас сервіс не подається як універсальне рішення для всіх продакшн‑сценаріїв. Для складних веб‑дашбордів із жорсткими вимогами до SLA чи для систем із детальним usage‑білінгом можуть знадобитися інші інструменти. Ghost.build радше закриває нішу AI‑керованих, відносно дешевих і безпечних для експериментів баз даних.

Встановлення за одну команду: як підняти Ghost.build і під’єднати до Claude Code

Один із ключових аргументів на користь Ghost.build — простота старту. Сервіс можна встановити на Mac або Linux однією командою в терміналі. Конкретний рядок береться з офіційної документації, але загальна логіка така: користувач копіює команду, вставляє її в термінал, натискає Enter — і клієнт Ghost починає встановлення.

Після інсталяції наступний крок — автентифікація. Для цього використовується команда ghost login. Вона відкриває вікно авторизації через GitHub: достатньо під’єднати свій обліковий запис, без окремої реєстрації в Ghost.build. Після успішного логіну клієнт запам’ятовує токен, і далі всі операції виконуються від імені цього користувача.

Щоб інтегрувати Ghost.build із Claude Code, Codeex, Cursor чи іншим MCP‑сумісним інструментом, використовується команда ghost mcp install. Після її запуску користувач обирає потрібний клієнт — наприклад, Claude Code — і Ghost автоматично реєструє MCP‑сервер у конфігурації цього інструмента.

Далі все відбувається вже всередині IDE. У Claude Code можна викликати список MCP‑серверів (наприклад, через команду /mcp) і побачити серед них Ghost. Усередині цього сервера відображається набір доступних інструментів: логін, виконання SQL, створення бази даних та інші операції.

Фактично, після цих кількох кроків Claude Code отримує повноцінний «драйвер» до Ghost.build, але в термінах MCP‑інструментів, а не класичних рядків підключення. Розробнику не потрібно налаштовувати окремі змінні середовища, DSN чи конфігураційні файли — усе це абстрагується MCP‑шаром.

Як Claude Code керує базами даних через MCP: від «reading_log» до «Movie Night»

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

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

Claude, маючи доступ до інструментів Ghost MCP, послідовно:

1. Викликає створення нової бази даних із заданою назвою.
2. Формує SQL‑схему таблиці для книжок.
3. Виконує SQL‑запити для створення таблиці.
4. Генерує й вставляє початкові записи з книжками.

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

Після створення бази Claude може виконувати запити до неї так само природно. Наприклад, запитати середній рейтинг усіх книжок у базі або вивести список книжок, відсортованих за оцінкою. Модель генерує відповідний SQL, викликає інструмент execute SQL через Ghost MCP, отримує результат і повертає його в читабельному вигляді.

Той самий підхід масштабується й на складніші сценарії. У другому демо створюється база Movie Night для відстеження фільмів із полями: назва, режисер, рік, жанр, тривалість і рейтинг за десятибальною шкалою. Claude засіває її сотнею фільмів різних жанрів і десятиліть, а потім на основі цієї бази генерує простий дашборд на Next.js із компонентами shadcn/ui.

Хоча Ghost.build орієнтований насамперед на роботу через MCP, із нього можна отримати й рядок підключення до бази, щоб використовувати її в сторонніх застосунках. У демонстрації Claude створює односторінковий дашборд, який під’єднується до бази Movie Night, показує таблицю фільмів, дозволяє фільтрувати за жанром і відображає три картки зі статистикою: загальна кількість фільмів, середній рейтинг і найчастіший режисер.

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

Форки, паралельні експерименти й «пам’ять» Claude: чому MCP‑інтеграція змінює робочий процес

Одна з найцікавіших властивостей зв’язки Claude Code + Ghost.build — це поєднання форкінгу баз даних, паралельних експериментів і стійкої пам’яті.

По‑перше, бази Ghost.build живуть незалежно від сесій Claude Code. Якщо закрити Claude, а потім знову його відкрити й попросити перелічити всі бази, до яких є доступ через Ghost, модель побачить раніше створені reading_log, Movie Night та інші. Це фактично дає Claude форму «довготривалої пам’яті»: він може повертатися до тих самих даних, продовжувати роботу над ними, видаляти або форкати їх за потреби.

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

По‑третє, форкінг відкриває можливість складних експериментів без ризику для основних даних. Показовий кейс — оптимізація повільного запиту в базі shop_analytics. Спочатку створюється велика e‑commerce‑схема: таблиці клієнтів, замовлень, позицій замовлень, продуктів і категорій. База засівається 100 тисячами клієнтів, 500 тисячами замовлень і мільйоном позицій замовлень. При цьому свідомо не додаються жодні індекси, окрім первинних ключів, щоб зробити запити повільними.

Далі ставиться завдання: виконати запит, який показує топ‑10 клієнтів за загальними витратами за останні 90 днів, разом із кількістю замовлень і середнім чеком, і заміряти час виконання. На базі без оптимізації запит виконується приблизно за 1,8 секунди. Це не катастрофічно повільно, але достатньо, щоб мати сенс для оптимізації.

Після цього Claude отримує інструкцію:

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

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

Цей сценарій демонструє одразу кілька важливих властивостей:

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

У підсумку Ghost.build перетворює Claude Code з інструмента «підказок» у повноцінного оператора баз даних, який може не лише писати SQL, а й керувати життєвим циклом сховищ, проводити експерименти й підтримувати довготривалі робочі простори.

Висновки: крок до AI‑керованої інфраструктури даних

Інтеграція Claude Code з Ghost.build через MCP показує, як може виглядати наступний етап еволюції інструментів для розробників. Замість того щоб обмежувати AI‑асистентів написанням коду в межах одного файлу, їм дають доступ до реальної інфраструктури — але в контрольованому, безпечному середовищі, спроєктованому саме під їхню модель роботи.

Ghost.build із безкоштовним рівнем на 100 обчислювальних годин, 1 ТБ сховища й необмеженою кількістю баз і форків робить такі експерименти доступними широкому колу розробників. Встановлення однією командою, авторизація через GitHub і інтеграція з Claude Code, Codeex та Cursor через ghost mcp install знижують поріг входу до мінімуму.

У результаті Claude отримує:

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

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

Якщо нинішні тренди збережуться, подібні AI‑рідні сервіси можуть стати стандартним компонентом стеку розробника, так само як сьогодні стандартом є Git чи хмарні CI/CD‑системи.

Джерело

YouTube: I gave Claude its own database, here’s what happened

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

Про цей стрибок говорять дослідники OpenAI Себастьєн Бюбек та Ернест Рю — обидва колишні професори математики й теорії машинного навчання (Princeton та UCLA відповідно), які тепер у компанії відповідають за дослідження в галузі математичного міркування моделей. Їхня розмова в подкасті OpenAI — це не історія про «чарівний апгрейд», а про надзвичайно стрімку, але все ж послідовну еволюцію: від моделей, які плутаються в розподілі витрат за похід у кемпінг, до систем, що конкурують з найкращими олімпіадниками світу й починають виходити за межі стандартних бенчмарків.

Два роки тому не було жодної моделі, здатної доводити складні теореми

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

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

Цей контраст особливо помітний на прикладі повсякденних задач, які описує Ернест Рю. На початку 2023-го, у 2024-му і навіть ще на початку 2025 року ChatGPT стабільно провалював те, що людина з калькулятором робить без особливих зусиль.

Рю тестував моделі на типових «життєвих» сценаріях:

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

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

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

Від побутової арифметики до золота на Міжнародній математичній олімпіаді

Поворотним моментом став літо 2025 року. Саме тоді ChatGPT досягнув топового людського рівня на Міжнародній математичній олімпіаді (IMO), продемонструвавши результат, еквівалентний золоту медалі.

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

Досягнення ChatGPT означає, що модель:

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

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

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

Після цього природно постало запитання: якщо ChatGPT може розв’язувати задачі IMO, чи здатен він працювати з відкритими проблемами, де відповіді ще не існує в жодному розв’язнику?

Скепсис математиків і «помилка масштабу»: чому всі недооцінили швидкість прогресу

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

На початку дискусії організатори провели опитування. Близько 80% присутніх математиків відповіли «ні»: масштабування LLM, на їхню думку, не здатне вивести моделі на рівень справжніх проривів. Після години дебатів співвідношення змінилося до приблизно 50/50 — частина аудиторії пом’якшила позицію, але скепсис залишався домінантним.

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

Цей епізод важливий з двох причин.

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

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

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

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

Від Minerva до ChatGPT: як «вражаюча» лінія на площині стала тривіальною

Ще один показовий маркер прогресу — порівняння з моделлю Minerva від Google, яка вийшла приблизно за чотири роки до подкасту.

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

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

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

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

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

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

Від провалу в «кемпінговій арифметиці» до покриття 99% потреб у вищій математиці

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

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

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

Рю пропонує просту, але показову «калібровку»:

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

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

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

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

Математика як ідеальний бенчмарк — і що означає «насичення» тестів

Чому саме математика стала центральним полігоном для оцінки прогресу моделей на шляху до AGI? Бюбек формулює дві ключові причини.

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

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

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

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

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

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

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

Від скепсису до співавторства: що означає нова ера математичного міркування AI

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

Чотири роки тому математична модель на кшталт Minerva вражала вмінням провести пряму через задані точки. Два роки тому не існувало жодної моделі міркування, здатної доводити складні теореми. Ще півтора року тому 80% математиків на спеціалізованому воркшопі були переконані, що масштабування LLM не приведе до розв’язання великих відкритих проблем.

Сьогодні:

– ChatGPT демонструє результат рівня золотої медалі IMO,
– може допомагати у щоденній роботі навіть математикам рівня Філдсівської премії,
– для 99% користувачів вищої математики фактично закриває всі практичні потреби,
– а стандартні математичні бенчмарки виявляються майже повністю «закритими».

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

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

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

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

Джерело

What happens now that AI is good at math? — the OpenAI Podcast Ep. 17

Інструменти на кшталт Claude Code дедалі активніше використовують для розробки, експериментів з кодом і швидкого прототипування. Але разом із цим зростає й потреба безболісно “відмотати” невдалий крок назад. У свіжому огляді на каналі KODARIK показано, як саме це робити за допомогою вбудованого механізму відновлення стану проєкту.

Відкат до будь-якого кроку: що вміє команда rint

Claude Code зберігає історію запитів (prompts) і змін у проєкті, а команда rint дозволяє повернутися до одного з попередніх станів. Ключова ідея: можна не лише переглянути історію, а й фактично “перестрибнути” назад до конкретного запиту.

Користувач обирає потрібний крок зі списку — наприклад, найперший запит, коли ще не існувало певного файлу (у прикладі це тестовий README). Після вибору система пропонує, що саме відновити:

• і код, і розмову (conversation);
• лише розмову;
• лише код.

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

Коли варто відкотитися, а не виправляти

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

1. Небажаний результат генерації

Якщо Claude Code згенерував код, який:

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

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

2. Помилки, що “ламають” проєкт

Бувають ситуації, коли:

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

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

3. Зміна планів під час розробки

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

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

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

Гнучке відновлення: код окремо, розмова окремо

Важлива деталь — можливість роздільного відновлення:

• Лише розмова: корисно, коли потрібно повернутися до певного контексту спілкування з моделлю, але зберегти поточний стан файлів.
• Лише код: доречно, якщо історія діалогу неважлива, а потрібно саме “відкотити” зміни в проєкті.
• Код + розмова: повний “тайм-джамп” до обраного моменту, коли і файли, і контекст відповідають вибраному запиту.

Такий підхід дає змогу гнучко керувати історією роботи, не перетворюючи відкат на грубий “reset” усього середовища.

Джерело

Повний огляд Claude Code – Частина 17 #аі #python #вайбкодинг — KODARIK