Керівник напрямів ChatGPT і Codex в OpenAI Тібо Сотіо (Thibault Sottiaux) переконаний: те, що сьогодні відбувається з програмуванням, дуже швидко накриє всю розумову працю. Якщо Google вже заявляє, що близько 75% його коду пише ШІ, то найближчими місяцями подібна трансформація почне відбуватися з маркетингом, аналітикою, менеджментом, контентом та будь‑якою роботою «за комп’ютером».

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

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

Від ручного промптингу до «агентного» робочого дня

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

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

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

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

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

Особистий агент для всіх: коли ШІ приходить до «нетехнарів»

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

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

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

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

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

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

Нова базова навичка: не промптинг, а структуризація роботи

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

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

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

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

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

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

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

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

Хмара замість локальних файлів: як агенти стануть по‑справжньому «персональними»

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

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

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

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

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

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

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

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

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

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

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

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

Безпечна автономія: як «другий агент» навчає нас довіряти першому

Щоб агенти могли працювати довше й автономніше, особливо з чутливими даними, потрібні не лише кращі моделі, а й нові механізми безпеки. Один із таких механізмів — Auto Review, який OpenAI нещодавно запустила.

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

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

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

Що це означає для кожного, хто працює за комп’ютером

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

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

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

По‑третє, відповідальність нікуди не зникне. Навіть якщо агент бере на себе рутину — від податкових розрахунків до щоденних дайджестів новин зі Slack, — людина залишається тим, хто затверджує рішення й відповідає за наслідки. Інструменти на кшталт Auto Review зменшують ризики, але не скасовують потреби розуміти, що відбувається.

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

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

Висновок: переосмислити роботу раніше, ніж це зробить ваш інструмент

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

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

Джерело

Head of ChatGPT & Codex: agents for normal people are HERE

Швидкий розвиток AI створює ілюзію, що успіх залежить від уміння «трошки всього»: від prompt engineering до векторних баз даних. Канал Tech With Tim пропонує протилежну стратегію: зосередитися на одній ніші й копати максимально глибоко. Для кар’єри в штучному інтелекті це може бути вирішальним.

Чому «вивчити все одразу» — хибна стратегія

Сфера AI‑інжинірингу має величезну «поверхню» технологій і підходів:

• prompt engineering
• Retrieval-Augmented Generation (RAG)
• агенти
• fine-tuning моделей
• мультимодальні системи
• ембеддинги
• векторні бази даних

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

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

Глибока спеціалізація як шлях до працевлаштування

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

• обрати конкретну ділянку (наприклад, комп’ютерний зір, робота з агентами, RAG‑системи);
• вивчити її до рівня впевненого практичного застосування;
• лише потім поступово розширювати горизонт.

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

Як обрати напрям і не потонути в хайпі

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

Практична стратегія:

1. Обрати одну область
   Наприклад:
2. комп’ютерний зір;
3. робота з текстом і LLM‑агентами;
4. побудова RAG‑систем;

5. оптимізація та fine-tuning моделей.

6. Зануритися в основи
   Не обмежуватися туторіалами, а розібратися в ключових концепціях, архітектурах, типових патернах рішень.

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

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

«Спочатку глибоко, потім широко» як кар’єрна стратегія

Оптимальна послідовність для AI‑інженера виглядає так:

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

Такий підхід дозволяє:

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

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

Джерело

Stop learning everything at once and go deep in one area first 🎯 — Tech With Tim

Порівняння AI‑інструментів для програмістів дедалі частіше виходить за межі абстрактних бенчмарків. У свіжому експерименті автор каналу Tech With Tim поставив перед двома флагманськими середовищами — Claude Code (Opus 4.7) та Codex (GPT 5.5) — однакове реальне завдання: з нуля зібрати Collab MD, веб‑додаток для спільного редагування markdown у реальному часі.

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

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

Базовий інтерфейс: обидва моделі влучили в макет, але з різними шрамами

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

На цьому етапі і Claude Code, і Codex продемонстрували, що здатні досить точно інтерпретувати UI‑вимоги. Обидва згенерували спліт‑екранний інтерфейс із верхньою панеллю та базовим редагуванням markdown. З погляду макета, ключова вимога була виконана: користувач отримував знайому структуру «редактор + прев’ю» з верхнім баром, що відповідає типовим патернам для markdown‑додатків.

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

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

Claude Code, навпаки, показав більш стабільну поведінку ядра редактора, але «спіткнувся» на зв’язуванні UI‑елементів. Кнопка «New document» у його версії просто не працювала: натискання не призводило до створення чи відкриття нового документа. Водночас, якщо вручну перейти за URL на кшталт /doc/test, редактор відкривався і працював коректно. Це важливий нюанс: проблема була не в самому редакторі чи логіці документа, а в маршрутизації або обробнику кнопки, який не був правильно прив’язаний до відповідної дії.

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

Ранні баги: що говорять нескінченні цикли та «мертві» кнопки

Поведінка обох додатків на ранньому етапі тестування добре ілюструє різні типи помилок, до яких схильні AI‑генеровані застосунки.

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

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

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

Claude Code зіткнувся з іншим класом проблем: інтеграційно‑маршрутизаційним. Кнопка «New document» була присутня в інтерфейсі, але не виконувала жодної дії. При цьому прямий перехід на URL документа демонстрував, що:

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

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

Ключовий момент у цьому експерименті полягає в тому, що обидва інструменти отримали явний фідбек про виявлені баги ще до переходу до наступної фази. Автор прямо описав Codex проблему з нескінченним циклом при створенні нового документа, а Claude Code — несправну кнопку «New document» і той факт, що редактор працює при прямому переході за URL.

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

Реальний час: хто швидше вийшов на стабільну синхронізацію

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

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

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

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

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

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

Персистентність і надійність: коли сторінка F5 стає тестом на зрілість

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

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

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

Цікаво, що ранні симптоми в Claude Code — несправна кнопка «New document» при працездатному редакторі за прямим URL — уже натякали на розрив між UI та документним життєвим циклом. Проблеми з персистентністю лише підсилили це враження: модель добре справляється з локальною логікою редагування, але дає збої на стику з довготривалим зберіганням і відновленням стану.

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

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

Що це означає для розробників, які покладаються на AI‑кодери

Порівняння Claude Code та Codex на прикладі Collab MD показує, що оцінювати AI‑інструменти лише за швидкістю генерації коду або обсягом scaffolding — недостатньо. Ключові відмінності проявляються саме в тому, як моделі поводяться на рівні фіч, багів і надійності.

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

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

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

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

Нарешті, проблеми з перезавантаженням сторінки в Claude Code нагадують, що для будь‑якого колаборативного редактора перевірка F5 — це не дрібниця, а базовий тест зрілості. AI‑інструменти можуть вражати здатністю швидко зібрати складний стек — від WebSocket до курсорної присутності, — але саме дрібні, «нудні» сценарії на кшталт збереження й відновлення стану часто виявляються найвразливішими.

Висновок: AI‑кодери вже будують складні фічі, але без людини не обійтися

Експеримент із Collab MD показує, що і Claude Code, і Codex уже здатні самостійно реалізовувати нетривіальні функції: спліт‑екранний markdown‑редактор, реальний тайм‑колаб, курсорну присутність. Обидва інструменти дотрималися базової UI‑специфікації, а в реальному часі забезпечили синхронізацію між клієнтами, включно з відображенням користувачів через мітки курсора або підсвічування намірів.

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

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

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

Джерело

YouTube: I Built the Same App With Claude Code and Codex

У новому експерименті з каналу Tech With Tim два з найпомітніших AI‑асистенти для розробників — Claude Code (Opus 4.7) та Codex (GPT 5.5) — отримали однакове завдання: самостійно зібрати складний веб‑застосунок Collab MD, реальний час колаборативний markdown‑редактор. Обидва інструменти працювали з однаковим технічним описом, архітектурою та макетом інтерфейсу, а процес було розбито на кілька фаз: від початкового scaffolding до реального часу синхронізації, курсор‑присутності, документного CRUD, версійності та експорту.

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

Нерівний старт: ліміти, моделі й повний доступ до системи

Перед запуском першого промпту обидва інструменти опинилися в різних умовах щодо використання ресурсів. Claude Code уже був частково «розігрітий»: приблизно 11% тижневого ліміту та 5% п’ятигодинного ліміту були витрачені раніше. Codex, навпаки, стартував практично з нуля — фактично 0% як загального, так і тижневого використання. Це важливий контекст, коли йдеться про те, наскільки агресивно кожен інструмент може «спалювати» підписку під час тривалої сесії.

З точки зору конфігурації, обидва асистенти отримали максимально «розв’язані руки». Claude Code працював на моделі Opus 4.7 у найвищому режимі reasoning з контекстним вікном у 1 мільйон токенів. Codex використовував GPT 5.5 в режимі extra high, без увімкненої опції 1.5x speed, щоб не створювати штучної переваги в швидкості, якої немає в Opus 4.7.

Ключовий момент — режим доступу. І Claude Code, і Codex було переведено у так званий bypass‑permission або full access mode. Це означає, що моделі могли самостійно:

редагувати файли в робочому каталозі,

запускати dev‑сервери,

керувати процесами.

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

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

Scaffolding: швидкий Claude проти педантичного Codex

Перша фаза — scaffolding проєкту — виявила разючу різницю у стилі роботи двох систем.

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

У випадку Claude Code структура клієнта й сервера була відносно компактною. У директоріях client/src та server/src було кілька основних файлів, достатніх для старту, але без надмірної деталізації. Це виглядало як мінімально необхідний каркас, на який можна швидко навішувати функціональність.

Codex пішов іншим шляхом. У клієнтській частині в src з’явилося значно більше директорій та файлів, з чіткішим поділом за відповідальністю. На сервері, окрім основних файлів, були додаткові структури на кшталт окремих типів, директорій dist, data та інших службових елементів, яких не було в проєкті Claude. Загалом scaffolding Codex був помітно більш розгалуженим і структурованим.

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

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

Автономне тестування: Codex сам запускає, Claude чекає вказівок

Уже на етапі scaffolding Codex продемонстрував агресивнішу модель автономії. Після створення структури він самостійно:

запустив застосунок,

відкрив браузер,

перейшов до локального URL,

перевірив базову працездатність інтерфейсу.

Це відбувалося через кроки комп’ютерного контролю: модель не просто виконувала команди в терміналі, а й взаємодіяла з браузером, створювала новий документ у Collab MD і візуально переконувалася, що сторінка працює. Такий підхід нагадує поведінку розробника, який після ініціалізації проєкту обов’язково запускає dev‑сервер і відкриває UI, щоб переконатися, що все хоча б «піднімається».

Claude Code, попри наданий повний доступ, поводився інакше. Після завершення scaffolding він не запустив застосунок самостійно, не відкрив жодного прев’ю й не перевірив працездатність у браузері. Модель лише повідомила, що сервер можна запустити, але не зробила цього без прямої вказівки.

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

Це ілюструє фундаментальну різницю в робочому стилі:

Claude Code орієнтується на швидке виконання інструкцій і мінімально необхідні кроки, не витрачаючи час на ініціативне тестування.

Codex, навпаки, інвестує час у повний цикл: створити структуру, запустити, відкрити, перевірити, за потреби перезапустити.

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

UI‑фаза: синхронна швидкість, асинхронні проблеми

На другій фазі обидва інструменти отримали завдання побудувати базовий інтерфейс Collab MD: розділений екран із лівою панеллю редактора, правою панеллю прев’ю, верхньою панеллю керування та базовим markdown‑редагуванням.

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

Codex продовжував тримати dev‑сервер у робочому стані й підтримував застосунок, що працює в браузері. Його Collab MD було доступно на порту 5174, і модель без видимих труднощів керувала запуском і перезапуском сервера.

Claude Code, навпаки, знову не мав запущеного застосунку після завершення фази. Щоб побачити оновлений інтерфейс, довелося знову явно попросити модель переконатися, що dev‑сервер працює на конкретному порту (5173). Claude намагався це зробити, але зіткнувся з труднощами при розгортанні, перш ніж йому все ж вдалося підняти застосунок.

Коли обидва інтерфейси запрацювали, виявилися перші відмінності в поведінці застосунків.

У Codex при відкритті нового документа з’являлася помилка у вигляді нескінченного циклу. Після кліку на «new document» UI входив у стан, де сторінка постійно оновлювалася або повторювала якусь дію, що робило роботу з документом неможливою. При цьому базові операції на кшталт створення й видалення документів працювали, але перехід до нового документа ламався.

У Claude Code кнопка «new document» взагалі не працювала. Однак, якщо вручну перейти за URL на кшталт /doc/test або /doc/hello-world, редактор відкривався й працював коректно. Тобто маршрутизація та сам редактор були реалізовані, але зв’язка між кнопкою створення документа та відповідним переходом не спрацьовувала.

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

Реальний час синхронізації: Codex тестує, Claude просто пише

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

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

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

Claude Code, зі свого боку, демонстрував іншу стратегію. Він швидко генерував код, але витрачав менше часу на автоматичне тестування на рівні браузера. Проблеми з dev‑серверами й розгортанням доводилося вирішувати вручну або через додаткові промпти, а не через ініціативні дії моделі.

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

Claude Code швидко виконує окремі кодові завдання, але його робочий цикл менш насичений автоматичними перевірками в реальному UI.

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

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

Швидкість, вартість і контроль: що насправді означає «кращий» AI‑кодер

Якщо дивитися лише на таймінги, Claude Code виглядає привабливо: початковий scaffolding за шість хвилин проти чотирнадцяти в Codex, швидке завершення окремих фаз без зайвих дій. Але в реальній розробці швидкість генерації коду — лише частина історії.

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

По‑друге, різниця в автономності впливає на витрати підписки. Claude Code стартував уже з 11% тижневого ліміту й 5% п’ятигодинного, тоді як Codex — із практично нульового використання. Модель, яка більше часу проводить у режимі комп’ютерного контролю, відкриває браузер, перезапускає сервери й активно тестує, потенційно споживає більше токенів і часу. Це може швидше «спалювати» ліміти, але водночас економити людський час.

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

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

Claude Code — швидкий, контекстно потужний асистент, який добре працює в парі з розробником, що сам контролює середовище, запускає й тестує застосунок.

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

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

Висновок: два стилі AI‑розробки замість одного переможця

Експеримент із Collab MD показує, що порівнювати Claude Code і Codex лише за кінцевим результатом — занадто спрощений підхід. Важливо дивитися на те, як вони поводяться в процесі: як швидко стартують, як будують структуру проєкту, наскільки активно керують середовищем, як часто й на якому рівні тестують застосунок.

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

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

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

Джерело

YouTube: I Built the Same App With Claude Code and Codex

У блозі Tech With Tim вийшов детальний експеримент: два найпомітніші інструменти для AI‑розробки, Claude Code та Codex, отримали одне й те саме завдання — з нуля створити реальний застосунок. Не черговий «to‑do list» і не набір ізольованих алгоритмічних задач, а повноцінний веб‑додаток із фронтендом, бекендом, реальним часом і складною взаємодією. Мета — подивитися, як моделі поводяться в умовах, максимально наближених до роботи живого розробника.

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

Collab MD: тест не про «хеллоу ворлд», а про реальний продукт

Замість синтетичних промптів на кшталт «написати функцію сортування» чи «згенерувати компонент React», обидва інструменти отримали завдання побудувати один і той самий застосунок — Collab MD. Це реальний, хоч і демонстраційний, продукт: колаборативний markdown‑редактор із роботою в реальному часі.

Базова ідея Collab MD проста, але технічно вимоглива. Інтерфейс має бути розділений на дві панелі: зліва — markdown‑редактор, справа — live‑прев’ю відрендереного тексту. Над ними — верхня панель із елементами керування. Уже цього достатньо, щоб перевірити, як AI‑кодер справляється з типовим стеком сучасного фронтенду.

Але справжня складність починається з вимог до реального часу. Collab MD повинен підтримувати одночасну роботу кількох користувачів над одним документом. Для цього в технічному завданні прямо прописано використання WebSocket‑з’єднань. Моделі мають не просто «якось синхронізувати текст», а побудувати систему, здатну обробляти паралельні зміни, потенційні конфлікти редагування та оновлення інтерфейсу без перезавантаження сторінки.

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

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

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

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

Обов’язкове проти «було б класно»: як розділили ядро й додаткові фічі

Щоб не перетворити експеримент на безкінечне нарощування функціоналу, специфікація Collab MD чітко розділяє обов’язкові можливості й так звані stretch‑цілі — бажані, але не критичні для базової версії.

До ядра застосунку входять:

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

Це той мінімум, без якого Collab MD перестає бути тим, чим його задумано: багатокористувацьким редактором, придатним для реальної роботи.

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

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

Експорт — ще один «приємний бонус», який вимагає додаткових форматів вивантаження (наприклад, Markdown‑файл або HTML), генерації файлів на сервері чи клієнті та коректної інтеграції з UI.

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

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

Рівні умови: однаковий стек, однаковий бриф, однакові фази

Щоб порівняння Claude Code і Codex було максимально чесним, обидва інструменти отримали однаковий стартовий пакет інформації. Перед початком будь‑якого кодування їм передали письмову специфікацію Collab MD, короткий огляд архітектури й опис бажаного UI‑макету.

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

Далі весь процес розробки був розбитий на чіткі фази. Замість одного гігантського промпту «зроби мені Collab MD» моделі крок за кроком отримували окремі завдання:

спочатку — початкове проєктне scaffolding, тобто створення структури клієнта й сервера, налаштування залежностей і базового оточення;

потім — реалізація базового редактора та прев’ю, щоб користувач міг хоча б редагувати markdown і бачити результат;

далі — додавання синхронізації в реальному часі через WebSockets;

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

окремим етапом — створення лендінг‑сторінки, яка слугує входом у застосунок і точкою керування документами;

наступний крок — повний CRUD для документів: створення, перегляд, оновлення, видалення;

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

і вже наприкінці — версійна історія, експорт і темна тема як додаткові можливості.

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

Конфігурації моделей: максимум можливостей для обох сторін

Ще один ключовий елемент експерименту — налаштування самих AI‑моделей. І Claude Code, і Codex запускалися в режимах, максимально наближених до «преміум‑доступу», щоб не обмежувати їх у ресурсах без потреби.

Claude Code працював на моделі Opus 4.7 у найвищому режимі reasoning. Це означає, що система мала доступ до повної потужності моделі, включно з розширеними можливостями міркування й планування. Контекстне вікно було встановлено на рівні 1 мільйона токенів — це дозволяє моделі тримати в пам’яті величезний обсяг коду, специфікацій і проміжних результатів без агресивного обрізання історії діалогу.

Codex, у свою чергу, використовував модель GPT 5.5 в режимі extra high. Опція прискорення на 1,5x не була увімкнена, щоб не створювати асиметрію: у Claude Code немає аналогічного режиму, тож для чесності обидва інструменти працювали без штучного форсажу. Контекстне вікно в Codex було меншим, ніж у Claude Code, але це — технічне обмеження самої платформи, а не вибір експериментатора.

Обидва інструменти отримали повний доступ до файлової системи й середовища виконання. Claude Code було переведено в режим повного доступу або bypass‑permission, що дозволяє моделі змінювати файли без ручного підтвердження кожної дії. Codex також працював у режимі full access: він міг запускати сервери, відкривати браузер, керувати процесами на машині.

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

Перед стартом експерименту автор перевірив і поточне використання лімітів. У Claude Code воно було на рівні приблизно 11% від тижневого ліміту й 5% від ліміту в п’ять годин — тобто запасу мало вистачити на повний прогін. У Codex показники були практично нульовими як за загальним, так і за тижневим використанням, тож модель стартувала фактично «з чистого аркуша».

Як виглядали перші кроки: scaffolding та базовий інтерфейс

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

Структура проєкту, згенерована Codex, виявилася помітно більш розгалуженою. На боці клієнта в директорії source з’явилося більше папок і файлів, ніж у варіанті Claude Code. На сервері Codex створив окремі каталоги на кшталт types, dist, data та інші службові структури, яких не було в Claude‑версії. Тобто Codex витратив додатковий час на побудову більш детального каркасу застосунку.

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

Claude Code, навпаки, після завершення scaffolding не запустив застосунок автоматично й не відкрив прев’ю в браузері. Модель лише повідомила, що сервер можна запустити, але не зробила цього самостійно, попри наданий повний доступ. Довелося явно попросити її запустити застосунок, після чого Collab MD дійсно піднявся, хоча й без інтегрованого прев’ю, яке показував Codex.

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

Під час раннього тестування UI виявилися перші баги. У Codex при відкритті нового документа інтерфейс потрапляв у нескінченний цикл оновлень — очевидна логічна помилка в обробці стану. Водночас Claude Code згенерував інтерфейс, у якому кнопка «новий документ» не працювала, але якщо вручну перейти за URL на кшталт /doc/test, редактор функціонував коректно й без «зациклення».

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

Реальний час як стрес‑тест: WebSockets і синхронізація

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

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

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

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

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

Експеримент із Collab MD показує, що порівнювати AI‑інструменти для розробки на основі окремих промптів — майже марна справа. Лише коли моделі отримують завдання побудувати цілісний застосунок із реальним часом, персистентністю, UI та обробкою помилок, стає видно їхні сильні й слабкі сторони.

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

У цьому сенсі Collab MD — показовий кейс. Він достатньо складний, щоб виявити проблеми з архітектурою, синхронізацією й UX, але водночас досить компактний, щоб його можна було реалізувати в межах одного експерименту. А те, як Claude Code і Codex поводилися на різних етапах — від scaffolding до WebSockets, — дає значно більше інформації, ніж будь‑який рейтинг «хто швидше написав функцію сортування».

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

Джерело

YouTube: I Built the Same App With Claude Code and Codex

Понад десять років тому Amazon і Google навчили світ розмовляти з ШІ. Завдяки Amazon Alexa та Google Assistant користувачі звикли до «активаційних слів» і відпрацювали природні голосові запити – заради того, щоб ставити таймери, вмикати музику, керувати розумним домом і витягувати потрібну інформацію з результатів пошуку. У 2026 році все виглядає інакше. Окрім агентивного ШІ, одна з тем цьогорічної конференції Google I/O — зміна того, як Google уявляє нашу розмову з ШІ. Компанія показала кілька нових можливостей із голосовим введенням — але в «непригладженому» форматі, де вся відповідальність за інтерпретацію намірів і подальші дії лягає на Gemini. Така зміна може мати неочікувані наслідки: Google хоче, щоб користувачі «балакали» з ШІ, аби виконувати завдання, але в процесі вони можуть загалом менше думати.

Приклад — Rambler, оновлена версія голосового введення Gboard, яку Google продемонструвала в шоу The Android Show: Google I/O 2026 Edition 12 травня. «З Rambler вам не потрібно добирати ідеальні слова, перш ніж почати», — пише Google. «Ви можете говорити природно, а він виокремить важливі частини та збере їх у лаконічне повідомлення». Модель Rambler, що працює на пристрої, вміє прибирати «е-е» й «ну», а також схоплювати суть повідомлення, не розшифровуючи дослівно всю вашу балаканину. Важливо, що Rambler може сприймати перемикання мов на льоту — так, як це часто роблять білінгвальні люди в родинному чи дружньому спілкуванні. Функція має принаймні одну очевидну користь з погляду доступності: і розшифрування, і редагування повідомлення відбуваються одночасно, без потреби торкатися клавіатури. Можливість надиктувати довге повідомлення, коли одна або обидві руки зайняті, теоретично може стати в пригоді будь-кому.

Додаток для керування завданнями Todoist досліджує подібні ідеї через функцію Ramble, яка дозволяє просто наговорити все, що потрібно зробити, а створення й сортування завдань перекладає на ШІ. У ширшому контексті Кремнієвої долини The Wall Street Journal уже зафіксував тренд на голосове диктування у корпоративних середовищах. Додатки на кшталт Wispr Flow та Monologue дозволяють говорити або шепотіти комп’ютеру, перетворюючи мовлення на текст і автоматично редагуючи його тон та стиль залежно від застосунку. В медичній сфері багато лікарів швидко перейняли інструменти ШІ-транскрипції як спосіб вести нотатки під час прийому пацієнтів. Google пропонує подібні переваги без потреби оформлювати окрему передплату чи встановлювати додатковий застосунок: Rambler можна використовувати на будь-чому, що працює під управлінням Android 17.

Docs Live, своєю чергою, — один із кількох прикладів інтеграції досвіду живого голосового спілкування з Gemini (Gemini Live) в інші сервіси Google. Завдяки Docs Live ви можете просто наговорити інформацію ШІ-моделі, а вона створить на основі сказаного документ Google Docs. «Просто говоріть, а Docs Live виконає важку роботу — упорядкує думки, структурує документ і, за вашого дозволу, підтягне релевантні деталі з Gmail, Drive, Chat і вебу», — пояснює Google. У демонстрації компанії це виглядає радше як диктування плану виступу, але Docs Live нібито однаково добре перетворює й потік свідомості на чернетку. Keep Live забезпечить подібний досвід у застосунку нотаток Google Keep, а Gmail Live перетворить голосові сесії з ШІ на швидший спосіб знаходити листи.

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

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

Ніхто не змушує користувачів користуватися цими інструментами, а Docs Live, Keep Live і Gmail Live на старті будуть доступні лише платним передплатникам тарифів AI Pro, AI Ultra та бізнес-клієнтам Workspace. Однак надлишок голосових ШІ-функцій змушує замислитися над тим, чому вони навчать активних користувачів. Google Assistant і Amazon Alexa з часом краще розуміли примхи людської мови, але структура більшості взаємодій із ними все одно залишалася роботизованою «запит-відповідь» — це був найнадійніший спосіб досягти результату. Потрібно було подумати, яку саме лампочку ви хочете ввімкнути, чи який Alexa-«skill» запустити, і сформулювати команду відповідно.

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

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

Джерело

Engadget

Одним із найперспективніших анонсів на конференції розробників Google I/O у вівторок став новий спосіб користування вебом для пересічних користувачів — через AI-агентів. Але водночас це виявилося й одним із найбільш заплутаних нововведень.

Google представила інформаційних агентів — переосмислену й «прокачану» штучним інтелектом версію застарілої сервісу Google Alerts. Такі AI-агенти працюють у фоновому режимі 24/7 та допомагають користувачам залишатися в курсі тем, які їх цікавлять, на кшталт ринкових трендів, відстеження цін чи попереджень про негоду.

Далі йде Gemini Spark — «персональний» AI-агент, який має допомагати орієнтуватися у вашому цифровому житті, інтегруючись із продуктами Google — Gmail, Google Docs та Google Workspace. Компанія каже, що цей асистент зможе виконувати щоденні завдання: виділяти головні теми з розсилок, організовувати домашній інвентар і стежити за тим, що потрібно докупити, або допомагати планувати й керувати спільною поїздкою з друзями.

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

Є й окрема назва для способу відстеження сповіщень від Spark — Android Halo. (Навіщо окремий бренд для функції Android — загадка. Але можна припустити, що внутрішні продуктові команди Google досить конкурують між собою і хочуть підсвітити власну роботу, навіть ціною плутанини для користувачів.)

Додаток Gemini також отримує AI-агента, який може складати персоналізований дайджест із вашої поштової скриньки Gmail, календаря та списку завдань і показувати оновлення у форматі Daily Brief.

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

Передплатники Google Pro та Ultra у США зможуть користуватися інформаційними агентами вже цього літа, а Spark стане доступним для Ultra «скоро». Halo з’явиться в користувачів Android «пізніше цього року». Daily Brief починає розгортатися у США для передплатників Ultra, Pro та Plus.

У результаті всіх цих запусків ми отримаємо стільки різних точок входу до AI-агентів, що буде складно зрозуміти, з чого взагалі почати. (І це ще не згадую дедалі «агентніший» браузер Chrome. Google показала, як можна говорити з Chrome під час онлайн-пошуку автомобіля, щоб налаштувати різні опції та комплектації у межах вашого бюджету, не торкаючись клавіатури й не клацаючи мишкою. Ну… гаразд?)

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

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

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

На самому заході Google тільки підлила олії у вогонь, демонструючи химерні AI-зображення між виступами. Також показали кітчеву анімацію, згенеровану AI, із «балакучими» чипами Tensor у стилі Cinnamon Toast Crunch. А в демонстрації окулярів на Android компанія показувала, як пристрій (який згодом отримає можливість знімати фото) може використовувати AI для перетворення зроблених користувачем світлин на щось інше.

У цьому прикладі ведучий зробив фото аудиторії, а система відредагувала його, додавши дирижабль у небі, після чого зображення було надіслано на годинник Android Watch. Гарний трюк, але чи варто заради цього зносити чиюсь домівку за процедурою примусового викупу землі, щоби прокласти лінії електропередач до нового дата-центру?

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

У попередні роки Google анонсувала нові споживчі гаджети — наприклад, смартфони Pixel і розумні дисплеї Nest Hub — разом із новими Android-функціями, на кшталт сервісу бронювання ресторанів і салонів, який у 2018 році всіх вразив. Тоді ці технології позиціонувалися як спроби згладити повсякденні побутові труднощі.

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

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

Замість інструментів для розв’язання проблем середньостатистичний техно-поінформований глядач цьогорічного Google I/O побачив гіганта, який просто вбудовує ще більше AI у все, чим люди вже користуються — від Docs та електронної пошти до окулярів і навіть Пошуку, що тепер став «AI-first» досвідом.

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

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

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

Тим часом стартапи, що будують AI навколо обміну повідомленнями, як-от Poke, Poppy, RPLY і Wingman, пропонують себе як спосіб більш природної взаємодії з AI-агентами через функцію, якою всі користуються щодня: текстові повідомлення.

Чи зможете ви колись надсилати повідомлення Spark? Представники Google на I/O туманно відповіли, що це станеться «колись у майбутньому».

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

Google I/O могло б стати переломним моментом, коли AI-агенти стали б доступні кожному через простий, безкоштовний продукт для споживачів (і з єдиним брендом). Люди, можливо, навіть «полювали б» на запрошення так само, як колись на інвайти в Gmail. Натомість нові AI-агенти Google — інструменти, здатні працювати замість нас і підлаштовуватися під наші особисті потреби — залишаються переважно недосяжними для більшості.

Джерело

TechCrunch

У медіаландшафті, де домінують Baby Shark і Skibidi Toilet, стартап Maka Kids намагається переосмислити дитячий контент, роблячи акцент не на тривалості перегляду, а на добробуті дитини.

Maka Kids створює стримінговий застосунок для дітей віком від нуля до шести років із контентом, що сприяє здоровому розвитку. Стартап залучив $3 млн пре-сід інвестицій для масштабування платформи й уже відкрив список очікування для користувачів.

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

Maka Kids заснували Ізабель Шайнман (Isabel Sheinman) і Танієлла Лета (Tanyella Leta), які раніше створили Nabu — неприбутковий проєкт, що надав доступ до дитячих книжок понад 15 млн дітей у 26 країнах.

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

Ідея Maka Kids виникла після розмов із друзями, родинами та клієнтами Nabu. Засновниці чули від батьків, які дедалі більше тривожилися через вплив екранного часу на дітей. Спираючись на ці занепокоєння, команда провела сотні інтерв’ю з користувачами, що зрештою вилилося в рішення — дитячий стримінговий застосунок, розроблений із фокусом на добробут.

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

Увесь контент Maka Kids оцінюється за допомогою Maka Imprint — власної, запатентованої у процесі, розробницької рамки, створеної в результаті дворічних R&D-досліджень спільно з науковцями з Yale Child Study Center. Ця рамка відображає сім ключових доменів раннього дитячого розвитку більш ніж через 650 індикаторів — зокрема мовлення, креативність, емоційні навички та мислення з орієнтацією на зростання (growth mindset).

Maka Kids ліцензує контент безпосередньо в правовласників і незалежних креаторів. Стартап також співпрацює зі студіями та аніматорами для створення оригінальних проєктів.

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

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

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

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

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

Цього літа Maka Kids проводить приватне бета-тестування на iOS і планує публічний запуск восени на iPhone та iPad із підтримкою трансляції через AirPlay. За словами компанії, у списку очікування вже кілька тисяч родин.

Бізнес-модель Maka Kids — підписка вартістю $11,99 на місяць із дешевшим річним планом.

Отримані інвестиції компанія спрямує на розширення каталогу перевірених шоу. Раунд очолив фонд Michigan Rise, також у ньому взяли участь Union Heritage Ventures, Flybridge, Also Capital, Detroit Venture Partners, Song United, Invest Detroit, Ann Arbor Spark Capital, 84I90, Georgetown Gain, Segal Ventures і низка бізнес-ангелів.

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

Джерело

TechCrunch

Що потрібно, щоб запустити перший справді масовий споживчий AI-продукт? Можливо, $700 млн.

Принаймні так вважають у Hark — AI-лабораторії, яка створює моделі та апаратне забезпечення для персонального AI-помічника. Компанія повідомила в четвер, що залучила таку суму в раунді Series A, який оцінив її у $6 млрд після інвестицій.

Мегараунд очолив Parkway Venture Capital. До нього також долучилися Nvidia, Align Ventures, AMD Ventures, ARK Invest, Brookfield, Greycroft, Intel Capital, Prime Movers Lab, Qualcomm Ventures, Salesforce Ventures та Tamarack Global.

Можливо, найцікавіше в цьому раунді — те, як мало Hark розкриває про свій продукт. Засновник і CEO компанії Бретт Едкок, підприємець, який раніше стояв за робототехнічною компанією Figure.AI та виробником електролітаків Archer, заснував Hark наприкінці 2025 року. Він вклав $100 млн власних коштів у розробку агентної AI-системи, що має стати універсальним інтерфейсом для взаємодії з цифровим світом.

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

Нові інвестиції підуть на залучення провідних фахівців з апаратної частини, продуктовий дизайн та AI-дослідження, а також на закупівлю обчислювальних ресурсів і компонентів. Наразі в компанії працює 70 людей, а її дата-центр оснащено GPU Nvidia B200.

Абідур Чоудхурі (на фото у промовідео), колишній продуктовий директор Apple, зараз очолює дизайн у Hark. У розмові з TechCrunch цього тижня він відмовився розкрити нові деталі того, над чим працює, але зазначив, що інвесторів вразила серія демонстрацій від його команди.

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

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

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

«Звучить як ідея для чудового продукту».

Джерело

TechCrunch

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

Так народилася ідея нового, потенційно безпечнішого застосунку для AI-терапії, який отримав назву The Path, розповів співзасновник і CEO Енсон Вітмер у коментарі TechCrunch.

Згодом відомий автор і мотиваційний спікер Тоні Роббінс настільки захопився стартапом, що приєднався до нього як співзасновник.

The Path залучив $14,3 млн посівних інвестицій. Раунд очолив фонд Prime Movers Lab (партнером якого є Роббінс), також взяли участь ковзаняр Аполо Антон Оно, боксер Деонтей Вайлдер та Designer Fund.

Після інвестиції Prime Movers Роббінс почав спілкуватися з Вітмером та співзасновником Тайлером Шеффером щодо, здавалося б, дрібних речей на кшталт брендингу, але його ентузіазм і кількість ідей для застосунку швидко зросли. Тоді йому запропонували статус співзасновника. Відтоді автор допомагає формувати The Path як застосунок «терапія плюс коучинг», що спирається на популярні методики самовдосконалення Роббінса.

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

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

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

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

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

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

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

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

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

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

Для цього, каже він, спеціально навчена модель стартапу показала результат 95 балів у бенчмарку безпеки для ШІ в ментальному здоровʼї Vera-MH. Для порівняння, найкращі споживчі боти набирають до 65 балів.

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

The Path дозволяє користувачам обрати одного з 11 віртуальних AI-терапевтів і налаштувати параметри на кшталт прямоти спілкування та інших деталей. Зараз сервіс безкоштовний, поки набирає аудиторію. У майбутньому стартап планує брати $40 на місяць.

Джерело

TechCrunch

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

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

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

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

Spotify виступає лише посередником у продажу: саму оплату квитків користувачі здійснюватимуть на сайті партнера.

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

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

Джерело

TechCrunch

Паралельно з інструментами для створення подкастів за допомогою ШІ, Spotify у четвер представила новий AI‑інструмент для самостійної публікації аудіокниг у платформі Spotify for Authors. Новинка працює на базі технологій ElevenLabs. Компанія повідомила на заході Investor Day, що функція запуститься в бета‑версії в червні за запрошеннями та спочатку підтримуватиме лише англійську мову.

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

Ця новина розвиває попереднє партнерство Spotify з ElevenLabs, яке вже дозволяло авторам надсилати до Spotify аудіокниги, створені на платформі голосового ШІ‑стартапу.

Стрімінговий аудіосервіс також мав співпрацю з Google Play Books для використання цифрової озвучки контенту. Однак Spotify, ймовірно, захотіла надати авторам доступ до новіших голосових моделей, що звучать більш емоційно й «по‑людськи», як у ElevenLabs. Показово, що у 2025 році ElevenLabs запустила власну платформу для самостійної публікації аудіокниг.

Spotify також розширює платформу «Spotify for Authors», додавши підтримку ще 10 мов, зокрема французької, канадської французької, німецької, нідерландської, латиноамериканського варіанту іспанської, шведської, фінської, ісландської, данської та норвезької.

Крім того, компанія цього року розширить тарифні плани Audiobook+ — підвищить ліміти прослуховування, а в майбутньому додасть окремі опції для студентів і сімей. Водночас Spotify не розкрила цін і детальних умов використання цих планів.

Станом на сьогодні Spotify має понад мільйон підписок на Audiobook+ і, за її підрахунками, вийшла на траєкторію отримання 100 млн доларів річного повторюваного доходу від цієї платформи.

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

Останніми роками Spotify суттєво посилила фокус на аудіокнигах і змогла наростити каталог до 700 000 назв. Компанія вивела програму на міжнародні ринки, інвестувала в неангломовні тайтли, увімкнула покупки в додатку та запустила чарти аудіокниг. Цього року Spotify також започаткувала програму, яка дозволяє авторам продавати паперові видання книжок у США та Великій Британії.

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

Джерело

TechCrunch

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

На початку цього місяця компанія випустила інструмент командного рядка на GitHub для Claude Code та Codex, який дозволяє створювати подкаст і зберігати його у власній бібліотеці Spotify. Компанія зазначає, що незабаром користувачі зможуть створювати подкасти безпосередньо в застосунку Spotify. Вони також зможуть налаштовувати розклад — наприклад, щоденні або щотижневі брифінги з тем, які їх постійно цікавлять. Крім того, можна буде створювати одноразові подкасти, щоб розібратися в окремій темі.

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

Крім того, користувачі можуть додавати посилання, PDF і текст, а також обирати кастомний голос для генерації подкастів. Таким чином Spotify фактично наслідує підхід сервісів NotebookLM, ElevenLabs Reader та застосунку Huxe (від колишніх розробників NotebookLM), щоб створювати персональні подкасти на будь-яку тему.

Spotify також випустила окремий настільний застосунок Studio by Spotify Labs, який може під’єднуватися до пошти та календаря користувача, щоб створювати персоналізовані брифінги.

Крім того, компанія запускає функцію ШІ‑запитань і відповідей (Q&A) для преміум‑користувачів мобільної версії в США, Швеції та Ірландії. Завдяки їй користувачі можуть ставити запитання про епізод, який вони слухають, або про концепт, згаданий у подкасті, і отримувати відповіді. Також можна запитувати рекомендації подкастів на конкретні теми. Ця новинка з’явилася слідом за запуском у квітні функції створення плейлистів із подкастів на основі текстового запиту.

Досі Spotify активно просував відеоподкасти. Компанія заявляє, що кількість користувачів, які слухали відеоподкасти, зросла на 50% у річному вимірі. Тепер, із запуском нових інструментів, Spotify хоче, щоб користувачі активніше взаємодіяли із застосунком — ставили запитання про подкасти (аналогічно до функції Ask YouTube, яку Google представив раніше цього тижня) та створювали власні подкасти за інтересами.

Джерело

TechCrunch

Одна з найпоширеніших ідей для компаній в епоху ШІ — поєднати сервіси на кшталт електронної пошти, календаря, документів і нотаток, щоб формувати щоденний дайджест у текстовому чи аудіоформаті. Spotify також йде цим шляхом і випускає новий окремий десктопний застосунок Studio by Spotify Labs саме з такою метою.

Компанія запустила можливість досліджувати будь-яку тему, створюючи про неї подкаст. Spotify також додає особистий контекст до цього інструмента генерації подкастів. І, оскільки у 2026 році компанії не можуть утриматися від додавання агентів у свої застосунки, новий Studio отримав агента, який уміє переглядати веб і діставати персональну інформацію для створення персонального подкасту.

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

Усі ці згенеровані ШІ подкасти зберігаються у бібліотеці Spotify для особистого прослуховування та синхронізуються між пристроями. Вони не доступні публічно.

Аудіокомпанія попереджає, що це рання прев’ю-версія застосунку, тож ШІ може помилятися й регулярно видавати ненадійний контент.

Spotify випускає цей продукт у форматі дослідницького прев’ю більш ніж у 20 країнах. Застосунок буде доступний вибраним користувачам віком від 18 років.

Інструмент конкуруватиме з Google NotebookLM, який кілька років тому почав популяризувати генерацію подкастів на основі вибраних джерел. І в притаманній Google манері компанія також запустила окрему функцію для створення щоденного подкасту на базі стрічки Discover. Відтоді формат подкасту як способу дослідити тему або отримати щоденний брифінг був прийнятий компаніями на кшталт Adobe та ElevenLabs, а також застосунками Hero та Huxe.

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

Джерело

TechCrunch

Фудтех‑компанія у сфері ароматів Patina залучила $2 млн інвестицій від Betaworks, True Ventures та інших інвесторів.

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

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

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

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

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

“Такі реплікації мають менший вуглецевий слід, ніж початковий рослинний екстракт, споживаючи істотно менше води та нафтопродуктів”, — каже Распет.

Серед інших гравців у цій сфері — стартапи на кшталт Osmo та давні гіганти індустрії ароматів і смаків Givaudan і Symrise, одні з найбільших виробників у світі.

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

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

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

За словами Распета, нове фінансування вже дозволило команді переїхати з його подвір’я до повноцінного офісу в районі Бушвік у Брукліні, де з невеликою командою хіміків компанія працює над запуском нових молекул і розвитком партнерств.

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

Довгострокова амбіція Patina — створити те, що Распет називає “Pantone для запахів” — за аналогією з універсальною системою підбору кольорів Pantone, яку використовують у дизайні та виробництві. Йдеться про визначення базових молекул запаху, з яких можна зібрати будь‑який аромат чи смак. “Ця інформація завжди була поруч, вона лише чекала, коли технології наздоженуть її та з’явиться команда з потрібним поєднанням експертизи й одержимості, щоб її розблокувати”, — каже Распет. — “Тепер ці ідеї можна втілити, а Patina стане базовим інтелектуальним шаром”.

Джерело

TechCrunch