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

Цей матеріал зосереджується саме на таких прикладних сценаріях: як побудовані агенти Meeting Prep і Software Review, а також як внутрішні команди OpenAI використовують workspace‑агентів для маркетингу, бухгалтерії та фінансів.

Від брифу до сайту і від ризику до звіту: як внутрішні команди OpenAI вже працюють з агентами

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

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

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

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

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

Meeting Prep: щоденний бриф із календаря, вебу та Google Drive

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

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

Ключовий елемент — стандартизований формат. Meeting Prep використовує шаблон Google Docs і навички (skills), які задають структуру документа. У брифі передбачені секції на кшталт executive readout, customer snapshot, meeting objectives. Executive readout дає стислий огляд для керівників, customer snapshot фіксує основні факти про компанію й поточний стан відносин, а meeting objectives формулюють цілі конкретної розмови. Така структура дозволяє будь‑якому учаснику зустрічі швидко зорієнтуватися, навіть якщо він підключається в останній момент.

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

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

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

Software Review: автоматизований «фільтр» заявок на новий софт у Slack

Другий показовий сценарій — агент Software Review, змодельований на основі реального внутрішнього агента OpenAI, який працює в Slack‑каналі й обробляє запити співробітників на нові інструменти. Для багатьох компаній це болюча тема: співробітники хочуть швидко підключати нові сервіси, а IT‑та безпекові команди змушені вручну перевіряти кожен запит, звіряти його з політиками, ліцензіями, бюджетами.

Software Review виступає як перша лінія обробки таких запитів. Коли співробітник просить доступ до нового сервісу, агент досліджує постачальника, порівнює його з уже затвердженим стеком програмного забезпечення і приймає рішення, що робити далі. Якщо в організації вже є інструмент із подібними можливостями, агент може вказати на нього й запропонувати використати існуюче рішення. Якщо ж запит виходить за межі стандартних політик або потребує додаткової оцінки, агент ескалує кейс у Jira для детального розгляду IT‑командою.

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

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

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

Шаблони, skills і попередні прогони: як агенти закріплюють найкращі практики

У всіх описаних сценаріях — від маркетингового сайту до Meeting Prep і Software Review — ключову роль відіграє не стільки «інтелект» моделі, скільки правильне кодування процесів і практик усередині агента.

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

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

Ще один важливий елемент — можливість попередніх прогонів. Перед тим як віддати Meeting Prep або Software Review в щоденну експлуатацію, їх можна запускати в режимі preview run. У цьому режимі видно покрокове виконання: до яких файлів агент звертається, які інструменти використовує, як формує проміжні результати. Це дозволяє будівникам агентів перевірити, чи правильно інтерпретовано інструкції, чи не виходить агент за межі дозволених дій, чи коректно він працює з календарем, поштою, документами.

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

Від індивідуальної продуктивності до командних процесів

Сукупність описаних прикладів показує зсув фокусу від індивідуального використання AI до командних, процесних сценаріїв. Маркетинговий агент, що будує сайт із брифу, бухгалтерський агент для month‑end close, фінансовий агент для vendor risk review, Meeting Prep і Software Review — усі вони працюють не як «розумні асистенти для однієї людини», а як вбудовані компоненти командних робочих процесів.

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

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

Джерело

Build Hour: Workspace agents in ChatGPT — OpenAI

У спеціальному кросоверному епізоді подкастів Security Intelligence та Mixture of Experts від IBM команда експертів з AI та кібербезпеки — Гейб Гудгарт (chief architect for AI open innovation), Мартін Кін (master inventor) та Джефф Крум (distinguished engineer з безпеки даних і AI) — розбирає одну з найгарячіших тем у технологіях: чи безпечний відкритий AI і що саме в ньому створює ризики.

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

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

Дві різні «відкритості»: код проти ваг моделі

У публічних дебатах про відкритий AI часто все зводять до одного запитання: «Чи безпечний open source?» Але в контексті генеративних моделей це надто грубе спрощення.

Ключова відмінність, на якій наполягають технічні практики, — це розділення двох рівнів:

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

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

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

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

Коли ваги відкриті: як легко зняти «запобіжники» з моделі

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

Комерційні хостингові платформи будують навколо своїх моделей багаторівневі «запобіжники»:

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

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

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

завантажити модель локально;
видалити або змінити безпекові налаштування;
провести донавчання (fine-tuning), яке «перепише» частину поведінки, включно з усіма відмовами та обмеженнями.

Технічно це не складніше, ніж звичайний fine-tuning для доменної адаптації. Якщо модель навчали казати «я не можу надати цю інформацію», то додаткове навчання може змусити її відповідати прямо протилежним чином.

У результаті з’являються «розблоковані» моделі, які:

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

Це не теоретичний сценарій, а прямий наслідок публікації ваг. Як тільки модель опиняється «на волі», контроль над її поведінкою переходить від вендора до будь-кого, хто має достатньо технічних навичок для fine-tuning.

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

Чому «securable» не означає «secure»: уроки Linux і Kubernetes для AI

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

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

Тому більш точна характеристика для сучасного AI-стеку — «securable, але не secure за замовчуванням». Це формулювання добре знайоме тим, хто працював з Linux або Kubernetes.

Linux — не «безпечний» сам по собі. Він:

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

Те саме стосується Kubernetes: за замовчуванням це платформа з відкритими можливостями, а не фортеця. Без належного hardening, політик доступу, сегментації мережі та контролю секретів кластер стає легкою мішенню.

AI-стек — це продовження цієї логіки. Він складається з:

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

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

Відкритий код тут не є ні гарантією безпеки, ні автоматичною загрозою. Він просто означає, що:

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

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

Закриті моделі як «фільтр»: коли безпека живе в софті, а не в самій моделі

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

Коли модель доступна тільки через API, розробник платформи може:

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

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

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

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

забрати модель із захищеного середовища;
запустити її без guardrails;
навчити її ігнорувати будь-які обмеження.

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

OpenClaw та ілюзія «безпечних за замовчуванням» AI-рішень

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

Характеристика, яку отримує OpenClaw, показова для всієї галузі: це система, яку можна зробити безпечною, але вона не є безпечною «з коробки». Іншими словами, це ще один приклад «securable, not secure».

Багато конкуруючих рішень, які ринок сприймає як «secure by design», на практиці концентруються переважно на двох аспектах:

ізоляція середовища виконання (sandboxing), щоб обмежити шкоду від потенційно небезпечних дій;
дозволи на інструменти (tool permissioning), які визначають, до яких зовнішніх сервісів або ресурсів агент має доступ.

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

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

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

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

Як бізнесу думати про безпеку відкритого AI сьогодні

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

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

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

По-третє, у випадку відкритих ваг потрібно виходити з припущення, що:

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

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

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

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

Дискусія навколо відкритого AI часто зводиться до ідеологічних гасел: «інформація хоче бути вільною» проти «нам потрібен контроль заради безпеки». Але в технічних деталях картина значно складніша.

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

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

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

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

Джерело

https://www.youtube.com/watch?v=PJGIWDW_W2A

Google запустила новий інструмент Flow Music — вебсервіс, що генерує повноцінні треки з вокалом, інструментами та обкладинкою за текстовим описом. Канал Teacher’s Tech детально показує, як сервіс працює, які в нього режими, обмеження та модель оплати. Нижче — структурований огляд можливостей Flow Music для тих, хто хоче швидко зрозуміти, чи варто додавати цей інструмент у свій креативний набір.

Старт: текстовий запит і перші треки

Flow Music доступний у браузері за адресою flowmusic.app. Вхід — через Google-акаунт, банківська картка на старті не потрібна.

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

• можна написати щось загальне на кшталт «upbeat indie folk song, something you’d hear on a road trip»;
• або сформулювати детальний запит із жанром, настроєм, інструментами, темпом тощо.

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

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

Налаштування музики: оцінки, правки, голосовий режим

Оцінювання та швидкі дії

Для кожної версії треку доступні:

• оцінка «подобається / не подобається» (thumbs up / thumbs down);
• швидкі дії: remix, завантаження відео, посилання для шерінгу та додаткові опції.

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

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

Вокал і точкові зміни

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

Якщо результат не влаштовує, можна:

• у текстовому полі попросити змінити темп, тип вокалу, настрій, інструменти;
• скористатися готовими підказками (швидкі кнопки) — наприклад, «faster tempo» або «change to male vocals».

Система перегенерує варіанти з урахуванням цих правок.

Voice Mode: розмова з ШІ як із продюсером

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

• користувач натискає кнопку мікрофона або утримує клавішу P;
• формулює запит усно, наприклад:
  «I want some warm acoustic guitar music. Something laidback, just instrumental, nothing too busy»;
• система відповідає голосом, пояснює, що робить, і генерує дві версії треку.

Перевага цього режиму — можливість ітеративної розмови. Наприклад, після прослуховування можна сказати:
«I like the vibe, but it feels a little flat. Can you add some light percussion to give it a little bit more energy?»
Flow Music перегенерує композиції з легкою перкусією, зберігаючи загальний настрій.

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

Розширені інструменти: власні матеріали, Flows, Instructions і Spaces

Вхідні дані: запис, аудіо та зображення

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

• Recording — запис аудіо прямо в сесії: можна наспівати мелодію, зіграти кілька акордів на гітарі, і система використає це як основу;
• Audio upload — завантаження існуючого аудіофайлу (до 40 МБ), наприклад, демо-версії;
• Image upload — завантаження зображення, яке може надихнути на тексти або обкладинку.

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

Також у налаштуваннях сесії є технічні параметри:

• Instruments — вибір базової музичної моделі (на момент запису доступна одна);
• Ghostwriter — спосіб написання текстів пісень (стандартний режим можна змінювати);
• Producer — «режим мислення» моделі:
• Standard — глибша обробка для вищої якості;
• Fast — пріоритет швидкості з компромісом у якості.

Flows: збережені промпти для повторюваних задач

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

Приклад сценарію:

1. У розділі Flows створюється новий flow, наприклад, Acoustic coffee house.
2. У ньому прописуються детальні інструкції:
   стиль «acoustic coffee house session», теплий, інтимний, розслаблений настрій, fingerpicking на акустичній гітарі, бажаний темп тощо.
3. Після збереження в полі промпту достатньо ввести /acoustic coffee house і натиснути Send — система підставить усі ці інструкції у фоновому режимі.

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

Instructions і Memories: глобальні налаштування стилю

Окремо від Flows існує розділ Instructions. На відміну від Flows, які спрацьовують лише за викликом, Instructions:

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

Є також опція Memories — використання історії розмов для персоналізації. Якщо її увімкнути, система зможе враховувати попередні взаємодії під час генерації нових треків.

Spaces: інтерактивні аудіоінструменти замість просто пісень

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

Приклад:

• користувач просить:
  «a weather-based ambient music tool where I could adjust rain, wind, thunder to create the sound»;
• Flow Music генерує невеликий застосунок із повзунками для дощу, вітру, грому;
• зміна параметрів у реальному часі змінює звучання.

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

Модель оплати, кредити та ліцензування

Кредити та тарифи

Flow Music працює за кредитною системою:

• Безкоштовний рівень:
• 500 кредитів при реєстрації;
• +30 кредитів за кожен день входу.
• Орієнтовна вартість генерації:
• інструментальний трек — близько 10 кредитів;
• пісня з текстом — 15–30 кредитів.

Цього достатньо, щоб створювати кілька треків на день без оплати. Для інтенсивнішого використання є платні плани: Starter, Plus, Member — із більшими лімітами та комерційними правами.

Flow Music також входить до складу деяких підписок Google AI (AI Starter, AI Pro Plus, Ultra тощо). У такому разі кредити Flow Music можуть бути включені в загальний пакет. Користувачам варто перевірити свій акаунт: якщо вже є підписка на Google AI, можливо, додатково платити за Flow Music не потрібно.

Ліцензія та маркування ШІ-контенту

За описом до відео:

• Платні плани (Starter, Plus, Member) надають комерційні права:
• можна використовувати треки в монетизованих відео;
• застосовувати в роботі з клієнтами тощо.
• Безкоштовний рівень доцільно розглядати як особисте використання. Для комерційних задач рекомендується перейти на платний тариф.

Кожна пісня отримує нечутний водяний знак SynthID, який позначає її як створену ШІ. Це не обмежує комерційне використання, але дозволяє верифікувати походження контенту.

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

Рекомендований робочий процес для новачків

Для тих, хто лише знайомиться з Flow Music, пропонується такий базовий сценарій:

1. Почати з простого текстового промпту.
   Згенерувати дві версії, уважно прослухати обидві.
2. Чесно оцінити треки.
   Використовувати thumbs up / thumbs down, щоб система краще розуміла смаки.
3. Перейти до Voice Mode.
   Спробувати покроково змінювати трек голосовими командами, додаючи інструменти, змінюючи темп чи настрій.
4. Зберегти улюблений стиль як Flow.
   Якщо певний вайб подобається, оформити його як збережений промпт для швидкого доступу.
5. Експериментувати зі Spaces.
   Коли базові можливості стануть зрозумілими, спробувати створити інтерактивні аудіоінструменти, а не лише пісні.

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

Джерело

YouTube: How to Use Google Flow Music (Free AI Music Tool)

У 2026‑му штучний інтелект у розробці вже не виглядає футуристичним експериментом — це буденність. Але те, як саме AI‑агенти вбудовуються в роботу команд, виявляється набагато менш лінійним, ніж здається ззовні. Про це докладно говорить Армін Роначер — автор Flask, багаторічний інженер і ранній користувач та контриб’ютор до самозмінного AI‑агента Pi, який лежить в основі персонального асистента OpenClaw.

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

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

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

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

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

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

Великі pull request і маленькі шанси все зрозуміти

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

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

Команди описують кілька типових наслідків таких великих PR:

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

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

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

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

Коли код пишуть неінженери: нова роль PM, маркетингу й сейлз

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Від pull request до prompt request: як змінюється саме поняття рев’ю

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

Саме тому Пітер Штайнбергер, творець OpenClaw, пропонує радикальну ідею: замінити або доповнити традиційні pull request так званими «prompt request». Йдеться про те, щоб фіксувати не тільки змінені файли, а й повний ланцюжок промптів, налаштувань і кроків, за допомогою яких агент згенерував цей код.

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

Для AI‑згенерованого коду це критично з кількох причин.

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

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

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

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

«Усі можуть усе» — але без процесу це шлях до хаосу

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

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

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

Особливо небезпечним є поєднання двох тенденцій:

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

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

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

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

Висновок: агенти змінюють не лише код, а й культуру

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

Сезонні сплески використання під час відпусток демонструють, що агенти часто входять у компанії як тимчасове рішення, але залишаються надовго. Великі, важкі для осмислення pull request змушують переосмислювати саму модель код‑рев’ю. Участь PM, маркетингу й сейлз у написанні коду відкриває нові можливості для швидких експериментів, але водночас створює ризики розриву між демо й реальним продуктом.

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

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

Джерело

Pragmatic Engineer Podcast — Building Pi, and what makes self-modifying software so fascinating

Квітневий реліз Jetpack Compose приніс одну з найпомітніших хвиль змін за останній час. Android‑розробник і автор навчального контенту Philipp Lackner у своєму огляді новинок Kotlin‑ та Android‑екосистеми зосередився саме на Compose: від оновленої поведінки корутин у UI‑тестах до нових потужних макетів Grid і Flexbox, експериментального API стилів і покращень прев’ю. Ці зміни не лише додають можливості, а й змушують переглянути звичні підходи до верстки та тестування інтерфейсів.

Тестування під прицілом: як перехід на StandardTestDispatcher ламає звичні UI‑тести

Одне з найменш помітних на перший погляд, але потенційно найболючіших оновлень у Compose 1.11 стосується саме UI‑тестів. Внутрішні API для тестування інтерфейсу більше не використовують UnconfinedTestDispatcher і переходять на StandardTestDispatcher. Для команд, які активно покривають UI корутинними тестами, це може стати джерелом несподіваних падінь.

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

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

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

Наслідок для розробників очевидний: оновлення до Compose 1.11 може зламати частину існуючих UI‑тестів. Особливо це стосується тих, що неявно покладалися на «автоматичний» запуск корутин. Тепер доведеться:

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

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

Прев’ю без рутини: PreviewWrapper як спосіб стандартизувати вигляд усіх екранів

Ще одна зміна, яка напряму впливає на щоденну роботу з інтерфейсом, — поява так званих preview wrappers. Compose тепер дозволяє створювати обгортки для прев’ю, що реалізують інтерфейс PreviewWrapper, і використовувати їх як універсальний контейнер для будь‑якого прев’ю‑контенту.

Типовий сценарій, знайомий кожному Android‑розробнику на Compose: для кожного прев’ю доводиться вручну обгортати composable у тему застосунку. У результаті код прев’ю рясніє повторюваними блоками з викликом MyAppTheme { ... }, які дублюються десятки разів по всьому проєкту.

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

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

Можливості preview wrappers не обмежуються лише темами. Концепція обгортки дозволяє створювати спільні layout‑контейнери для прев’ю, додавати стандартні відступи, фонові кольори, debug‑рамки, імітацію різних розмірів екранів або станів системи. Фактично, це ще один рівень композиції, але орієнтований саме на дизайн‑час, а не на продакшн‑UI.

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

Стилі проти модифікаторів: експериментальний styles API як спроба переосмислити декларацію вигляду

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

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

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

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

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

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

Grid: Compose наближається до CSS‑парадигми макетів

Найяскравіше оновлення в частині макетів — поява нового composable для побудови сіток, який за концепцією дуже нагадує CSS Grid. До цього моменту розробникам доводилося комбінувати LazyVerticalGrid, Row, Column та інші компоненти, щоб отримати складні сіткові інтерфейси. Тепер Compose отримує повноцінний Grid‑layout із можливістю керувати заповненням рядків і колонок окремими елементами.

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

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

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

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

Flexbox: курс на заміну FlowRow і FlowColumn знайомою веб‑моделлю

Паралельно з Grid у Compose з’являється ще один знайомий веб‑розробникам інструмент — Flexbox. Це експериментальний layout, API якого майже повністю віддзеркалює CSS Flexbox: із властивостями flexGrow, flexShrink, flexWrap, justifyContent, alignItems та іншими звичними термінами.

До цього моменту роль «гнучких» рядів і колонок у Compose виконували FlowRow і FlowColumn. Вони дозволяли елементам переноситися на наступний рядок або колонку, коли не вистачало місця, і надавали базові можливості вирівнювання. Однак їхня модель не була повною аналогією Flexbox, а термінологія відрізнялася від веб‑світу.

Новий Flexbox у Compose покликаний цю ситуацію змінити. Ідея полягає в тому, щоб зробити його основним рішенням для побудови гнучких, адаптивних рядів і колонок, а FlowRow і FlowColumn у перспективі відправити в розряд застарілих. Це не просто ще один layout, а спроба уніфікувати мову опису інтерфейсів між вебом і Android.

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

Flexbox у Compose залишається експериментальним, але вже має окрему документацію з описом сценаріїв використання та відмінностей від існуючих layout’ів. За своїми можливостями він ближчий до веб‑оригіналу, ніж до FlowRow/FlowColumn, і пропонує тонше керування вирівнюванням, розподілом простору й поведінкою елементів при зміні розміру контейнера.

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

Висновки: Compose дорослішає й зближується з веб‑світом

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

По‑друге, інструменти розробки інтерфейсу стають зручнішими: preview wrappers знімають рутину з оформлення прев’ю й допомагають будувати більш системний дизайн‑процес, а експериментальний styles API відкриває дискусію про те, як саме має виглядати декларація стилів у Compose.

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

Разом ці зміни показують, що Jetpack Compose виходить за рамки просто «декларативного UI для Android» і поступово перетворюється на повноцінну платформу з власною екосистемою інструментів, але при цьому уважно придивляється до рішень, які вже давно працюють у веб‑світі.

Джерело

https://www.youtube.com/watch?v=QViURZf9x1s

У Сан‑Франциско, під час сесії для розробників, лідерка з developer relations у Google DeepMind Пейдж Бейлі — інженерка з досвідом у машинному навчанні ще з 2009 року та учасниця розробки NumPy, SciPy і scikit‑learn — показувала, як нове покоління моделей DeepMind виходить далеко за межі текстових чат‑ботів. За останні півтора місяця команда випустила цілу хвилю моделей, і серед них — цілий пласт мультимодальних систем, орієнтованих на зображення, відео, аудіо, музику та інтерактивні середовища.

На тлі ринку, де більшість моделей досі мислять категоріями «текст + код» і максимум сприймають статичні зображення, стек Google DeepMind виглядає як спроба переосмислити сам формат взаємодії з ШІ. У центрі — Gemini як універсальний мультимодальний рушій, а поруч — спеціалізовані моделі Veo, NanoBanana, Lyria та Genie, які закривають окремі, але взаємопов’язані сценарії: від відеогенерації до побудови інтерактивних світів.

Gemini як справжній мультимодальний центр: один інтерфейс для відео, аудіо, коду й тексту

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

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

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

1. розбирає відео по кадрах;
2. ідентифікує об’єкти (у цьому випадку динозаврів);
3. зіставляє їх із назвами видів;
4. доповнює відповідь фактами, використовуючи підключений інструмент пошуку.

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

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

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

Спільний простір для всіх медіа: навіщо потрібні мультимодальні ембеддінги

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

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

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

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

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

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

Від картинок до відео: NanoBanana 2 та Veo 3.1 Lite як інструменти візуальної творчості

Якщо Gemini — це універсальний мультимодальний «мозок», то NanoBanana 2 та Veo 3.1 Lite — це спеціалізовані інструменти для візуального контенту, які закривають окремі етапи креативного процесу.

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

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

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

Veo 3.1 Lite, своєю чергою, відповідає за відео. Це модель генерації відео, оптимізована під низький вартісний профіль. Іншими словами, вона спроєктована так, щоб дозволити створювати багато відео — для прототипів, тестів, A/B‑експериментів — без вибуху витрат.

У контексті AI Studio Veo 3.1 Lite з’являється як один із варіантів у «відео‑пілці» модального вибору моделей. Розробник може обрати саме Lite‑версію, коли йдеться про:

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

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

За межами статичних медіа: Lyria 3 та Genie 3 як крок до інтерактивних світів

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

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

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

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

Користувач задає умови — наприклад, «платформер у стилі ретро‑піксель‑арту з низькою гравітацією» — і Genie 3 формує середовище, де ці умови реалізуються. Це відкриває можливості для:

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

У поєднанні з Lyria 3, NanoBanana 2 та Veo 3.1 Lite виникає екосистема, де:

NanoBanana 2 відповідає за візуальні активи,
Veo — за кінематографічні або промо‑ролики,
Lyria — за музичний шар,
Genie — за інтерактивну «фізику» світу,
а Gemini — за логіку, наратив і клей між усіма цими компонентами.

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

AI Studio як вітрина мультимодальності: від вибору моделі до коду в один клік

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

Сервіс доступний безкоштовно за адресами a.dev, ai.studio або aistudio.google.com і працює з особистим акаунтом Gmail. Усередині інтерфейсу користувач бачить «пілки» моделей за модальностями: можна обрати Gemini для тексту й мультимодальних задач, Veo для відео, а також налаштувати додаткові інструменти — від структурованих відповідей до виконання коду.

У випадку з відео‑аналізом, описаним Бейлі, AI Studio дозволяє:

додати медіа з Google Drive, завантажити файли, записати аудіо, підключити камеру, вставити YouTube‑URL,
увімкнути «grounding» через Google Search, щоб модель могла підтягувати актуальні факти,
налаштувати «thinking»‑режим Gemini — від мінімального до високого, залежно від того, скільки токенів модель має витратити на «роздуми».

Після виконання запиту розробник може натиснути «Get code» і отримати готовий фрагмент коду для Python, TypeScript чи Java, який відтворює ту саму операцію через API: вибір моделі, передавання відео (чи YouTube‑URI), формування промпту. Це перетворює AI Studio на місток між «погратися з моделлю в браузері» та «вбудувати її в реальний застосунок».

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

Висновок: мультимодальність як новий базовий рівень для AI‑додатків

Те, що демонструє стек Google DeepMind, — це спроба зробити мультимодальність не «фічею», а базовою властивістю AI‑систем. Gemini приймає й генерує кілька типів медіа в одному інтерфейсі, мультимодальні ембеддінги дозволяють шукати й зіставляти контент через модальності, NanoBanana 2, Veo 3.1 Lite, Lyria 3 та Genie 3 закривають спеціалізовані креативні та інтерактивні сценарії.

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

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

Джерело

Build & deploy AI-powered apps — Paige Bailey, Google DeepMind

OpenAI поступово перетворює Codex із «розумного автодоповнення» в терміналі на повноцінне середовище для програмної інженерії. На воркшопі AI Engineer розробники OpenAI Вайбгав Срівастава та Катя Гіл Гусман показали, як сьогодні виглядає Codex як застосунок: багатопроєктна робота, автоматизації для Slack і Gmail, а також нова система плагінів, що збирає навички, інтеграції та MCP‑сервери в повторно використовувані робочі процеси.

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

Від «чату з моделлю» до робочого столу: що дає Codex App

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

Codex можна викликати з різних поверхонь — через застосунок, IDE‑розширення, CLI, Slack, GitHub або кастомні інтеграції з Figma, Linear, Notion та іншими сервісами. Саме Codex App став центральною точкою, де ці можливості зібрані в робоче середовище, а не в окремі «чати».

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

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

Паралельні фічі без колізій: робочі дерева в Codex

У кожному проєкті Codex App підтримує власні work trees — робочі дерева, прив’язані до окремих задач. Це дозволяє одночасно вести кілька фіч, виправлень багів або просто гілок Q&A, не змішуючи контексти.

Фактично це нативна підтримка того, що багато команд намагаються емулювати через гілки Git, окремі сесії в IDE або множинні вікна терміналу. У Codex кожне робоче дерево — це окремий простір, де агент бачить відповідний зріз коду, історію дій та інструкції. Якщо в одному work tree Codex рефакторить модуль авторизації, а в іншому — додає новий API‑ендпоінт, їхні контексти не перетинаються.

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

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

Від macOS до Windows: чому важливий нативний sandbox

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

Однак наступним кроком стало повноцінне розширення на Windows — із нативною підтримкою та, що особливо показово, з власним Windows‑sandbox для безпечного виконання команд і інструментів. За словами команди, це перший у своєму роді sandbox такого типу для Windows серед подібних агентних «harness‑ів».

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

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

Автоматизації як вбудований «операційний шар» для інженера

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

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

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

Щоденні дайджести Slack: як AI фільтрує шум

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

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

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

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

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

Gmail під контролем: пошук листів, що справді потребують відповіді

Схожа логіка застосовується до Gmail. Codex‑автоматизації можуть бути налаштовані на щоденне сканування вхідної пошти з кількома цілями.

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

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

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

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

Плагіни як новий рівень: навички, застосунки, MCP‑сервери й промпти в одному пакеті

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

Плагін у Codex — це пакет, який може включати навички (skills), застосунки (apps), MCP‑сервери та промпти. Разом вони утворюють робочий процес, який можна підключити до проєкту, поділитися з колегами й використовувати повторно в різних контекстах.

Навички: як упакувати процес у повторно використовувану інструкцію

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

У навичку можна закласти:

інструкції, які пояснюють, як саме має діяти агент;

скрипти, що автоматизують частину кроків;

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

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

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

Застосунки й MCP‑сервери: вихід за межі локального середовища

Другий компонент плагінів — застосунки. Це підключення до зовнішніх сервісів, таких як Notion, Linear, Google Drive та інші. Через застосунки Codex отримує змогу не лише читати дані, а й оновлювати їх, працюючи з ними як із частиною загального робочого процесу.

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

Разом навички, застосунки й MCP‑сервери, об’єднані в плагін, створюють повторно використовуваний workflow. Наприклад, плагін може описувати повний цикл роботи з певним типом задачі: від збору даних із Google Drive і Linear до оновлення документації в Notion і надсилання підсумку в Slack.

Повторне використання й обмін між проєктами

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

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

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

Codex як середовище, а не просто модель

Усе описане вище — багатопроєктна структура з робочими деревами, нативний sandbox на macOS і Windows, автоматизації для Slack і Gmail, система плагінів із навичками, застосунками та MCP‑серверами — вказує на важливий зсув у тому, як OpenAI позиціонує Codex.

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

працювати над кількома фічами або багами в окремих робочих деревах;

виконувати регулярні операційні задачі через автоматизації;

інтегруватися з зовнішніми системами через застосунки й MCP‑сервери;

діяти за стандартизованими процесами, описаними в навичках і плагінах.

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

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

Висновок: AI‑інженер, який живе у вашому робочому просторі

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

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

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

Джерело

Codex and Subagents — Vaibhav Srivastav & Katia Gil Guzman, OpenAI (YouTube)

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

Що таке Plan mode і для чого він потрібен

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

Найкраще він підходить для ситуацій, коли:

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

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

Як виглядає робота з режимом

Робочий процес у Plan mode можна описати кількома кроками:

1. Перемикання в Plan mode
   Спочатку активується режим Plan mode On. Це сигнал для системи, що зараз пріоритет — планування, а не виконання окремих дрібних запитів.

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

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

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

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

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

Чому варто починати проєкт із Plan mode

Режим планування пропонується використовувати як стартову точку для будь-якого нового проєкту — хоча б для першого запиту. Це дає кілька практичних переваг:

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

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

Джерело

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

У світі великих мовних моделей увага зазвичай прикута до гігантів на сотні мільярдів параметрів. Але паралельно формується інший фронтир — малі моделі, здатні працювати повністю на пристрої, у межах сотень мегабайт пам’яті, з мілісекундною затримкою. Саме на цьому сегменті спеціалізується Liquid AI, де Максим Лабонн очолює напрямок пре-тренування. Компанія розробляє моделі від 350 млн до 24 млрд параметрів для тексту, зору й аудіо, а їхні ваги доступні на Hugging Face.

Один із ключових проєктів Liquid AI — лінійка LFM, а зокрема рецепт тренування LFM 2.5 для малих «фронтирних» моделей. Його особливість — поєднання екстремально великого пре-тренінгу (28 трильйонів токенів для моделі всього на 350 млн параметрів) з багатоступеневим пост-тренуванням: від суворо структурованого supervised fine-tuning до преференційного вирівнювання й підкріплювального навчання.

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

28 трильйонів токенів для 350M: навіщо малим моделям стільки даних

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

Liquid AI пре-тренувала 350-мільйонну модель LFM 2.5 на 28 трильйонах токенів. Для цього масштабу параметрів це нетипово високе співвідношення даних до параметрів, яке значно перевищує те, що зазвичай застосовують для малих моделей.

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

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

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

Результати підтверджують доцільність такого підходу. Порівняння LFM 2.5 з попередньою версією LFM2 350M на низці бенчмарків показує суттєвий приріст якості. Модель помітно покращилася в завданнях знань (GPQ Diamond), інструкційного слідування (IFB Bench), структурованого витягу даних (Case Report Bench) та інструментального використання (PFCL, T2 Bench) — при тому, що кількість параметрів залишилася тією самою.

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

Єдиний рецепт для малих фронтирних моделей: від пре-тренінгу до RL

LFM 2.5 — це не лише про обсяг даних. Liquid AI вибудувала цілісний рецепт тренування, який поєднує масивний пре-тренінг із чітко структурованим пост-тренуванням. Ланцюжок виглядає класично: спочатку пре-тренінг, потім supervised fine-tuning, далі преференційне вирівнювання, і на завершення — підкріплювальне навчання.

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

Пре-тренінг на 28 трильйонах токенів формує базову мовну компетентність і знання, але не робить модель корисною «з коробки» для конкретних сценаріїв. Для edge-кейсів — від витягу даних до багатокрокового виклику інструментів — потрібна тонка настройка поведінки, формату відповідей і стійкості до помилкових патернів, зокрема до так званих «doom loops», коли модель застрягає в нескінченному повторенні фрагментів тексту.

Саме тут вступає в гру триступеневе пост-тренування LFM 2.5:

спочатку supervised fine-tuning, який задає базову «мову завдань» і інструкційне слідування;

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

і нарешті reinforcement learning, який закриває «on-policy» контур і дозволяє моделі вчитися на власній поведінці в динамічних середовищах.

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

Supervised fine-tuning: навчити модель говорити мовою завдань

Перший етап пост-тренування LFM 2.5 — supervised fine-tuning (SFT). Його завдання — не «виправити» модель, а навчити її базовим правилам гри: як виглядають інструкції, у якому форматі очікуються відповіді, як структурувати кроки міркування, як оформлювати виклики інструментів.

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

У випадку LFM 2.5 команда свідомо обрала пріоритетні напрями: витяг структурованих даних і робота з інструментами. Модель на 350 млн параметрів не має бути найкращою в коді чи математиці, якщо її реальні сценарії використання — це, наприклад, витяг полів із документів або керування зовнішніми API в агентних системах. SFT-дані й мікс завдань підбираються саме під такі цілі.

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

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

Преференційне вирівнювання: як зробити малу модель надійною в тісних межах

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

Liquid AI використовує власний on-policy алгоритм преференційного вирівнювання, заснований на length-normalized direct preference optimization. Ключова ідея — не просто «підганяти» модель під статичний датасет пар «краща/гірша відповідь», а генерувати дані за участі самої моделі, оцінювати їх і вчити модель віддавати перевагу кращим варіантам.

Для малих моделей це має кілька наслідків.

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

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

LFM 2.5 інтегрує боротьбу з doom loops безпосередньо в пайплайн преференційного вирівнювання. Для кожного промпту модель із температурним семплінгом генерує кілька варіантів відповідей, а також один варіант із нульовою температурою, який із високою ймовірністю «залипає» в doom loop. Далі всі варіанти оцінює окрема LLM-журі, і відповіді з doom loops систематично потрапляють у категорію «rejected». У результаті модель під час навчання отримує чіткий сигнал: такі патерни поведінки небажані.

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

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

Reinforcement learning: завершення on-policy контуру для малих моделей

Останній етап рецепта LFM 2.5 — reinforcement learning (RL). Якщо SFT навчає модель формату, а преференційне вирівнювання — загальним уподобанням, то RL дозволяє відшліфувати поведінку в конкретних, часто складних середовищах, де статичних даних недостатньо.

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

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

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

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

У результаті RL завершує on-policy вирівнювання LFM 2.5: модель не лише вчиться на статичних прикладах і людських оцінках, а й адаптується до власної поведінки в реальних або наближених до реальних середовищах. Для edge-сценаріїв, де модель часто працює як частина агентної системи з інструментами, це особливо цінно.

Висновок: фронтир малих моделей — це не «менші GPT», а окрема інженерна дисципліна

Рецепт LFM 2.5 показує, що малі моделі на кшталт 350M-параметрових систем Liquid AI — це не просто зменшені копії великих LLM. Вони вимагають окремої стратегії тренування, яка враховує їхню пам’яткову обмеженість, вузьку спеціалізацію й жорсткі вимоги до затримки.

Ця стратегія складається з трьох ключових ідей.

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

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

По-третє, on-policy підхід до вирівнювання, який дозволяє не лише підганяти модель під статичні датасети, а й систематично боротися з такими проблемами, як doom loops, і виявляти прогалини в SFT-даних через зворотний зв’язок із RL.

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

Джерело

Everything I Learned Training Frontier Small Models — Maxime Labonne, Liquid AI

У 2026 році один із найвпливовіших AI‑агентів для програмістів виявився не продуктом великої корпорації, а роботою одного розробника з Австрії. Маріо Цехнер, відомий у геймдев‑та ML‑спільнотах, створив Pi — мінімалістичного, самозмінного AI‑coding‑агента, який став ядром персонального асистента OpenClaw Пітера Штайнбергера. Поруч із ним — Армін Роначер, автор Flask, ранній користувач і контриб’ютор Pi. Їхня розмова на подкасті The Pragmatic Engineer дає рідкісний погляд на те, чому саме зараз самозмінне ПЗ стало практичним, чому простота важливіша за «розумні» індекси, і як один невеликий інструмент опинився в центрі нової хвилі AI‑розробки.

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

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

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

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

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

Самозмінний агент: коли користувач просить Pi переписати самого себе

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

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

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

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

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

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

Ще одна показова деталь дизайну Pi — відсутність підтримки MCP (Model Context Protocol) «з коробки». У час, коли багато гравців ринку намагаються стандартизувати інтеграції через MCP, Pi свідомо стартує без нього. І далі відбувається характерний сценарій: користувачі просто просять Pi… додати MCP‑підтримку в самого себе.

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

Ключ до такого підходу — у тому, як Pi працює з кодом. Тут важливий момент, який Маріо називає переломним: поява Claude Code з його «agentic search» по файловій системі. Ідея виявилася простою, але потужною: замість того щоб будувати складні індекси векторних баз, агенту просто дають можливість «пропахати» файлову систему, читати файли напряму й будувати власну картину проєкту в реальному часі.

Для Маріо це стало моментом, коли coding‑агенти перестали бути іграшкою й стали по‑справжньому корисними. Усе, що було до цього — IDE з вбудованими індексами, окремі сервіси на кшталт векторних сховищ, — раптом виглядало зайвим. Прямий доступ до файлів виявився ефективнішим за «розумні» dense/sparse‑пошуки. Агенту не потрібно гадати за векторною близькістю, який фрагмент коду релевантний; він просто читає потрібні файли, як це зробив би людина‑розробник.

Це пояснює й скепсис щодо MCP як обов’язкового шару. Якщо агент уже вміє працювати з файловою системою й CLI, багато інтеграцій можна реалізувати без додаткових протоколів. MCP стає не фундаментом, а опційним розширенням, яке, за потреби, сам агент може собі додати. Саме тому типовий сценарій із Pi — не «встановити плагін MCP», а «попросити Pi реалізувати MCP‑клієнт у власному коді».

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

Від Pi до OpenClaw: як один агент став ядром персонального AI‑асистента

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

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

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

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

Коли самозмінне ПЗ стає буденністю: чому саме зараз це стало можливим

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

Поява потужних LLM‑агентів змінила цю динаміку. Тепер у системі з’явився компонент, який може:

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

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

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

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

«Уповільнити хід»: простота проти гонитви за автоматизацією

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

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

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

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

Висновок: маленький агент, велика зміна в тому, як ми мислимо про AI‑інструменти

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

Замість гігантських платформ — тонкий, стабільний harness навколо LLM. Замість обов’язкових протоколів і векторних баз — прямий доступ до файлової системи й CLI. Замість закритого «чорного ящика» — агент, якого можна попросити змінити самого себе.

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

Джерело

Pragmatic Engineer Podcast — Building Pi, and what makes self-modifying software so fascinating

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

Проблема «завжди ввімкнених» батьків

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

Типова картина:

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

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

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

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

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

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

Один із практичних підходів — свідомо вводити в день короткі сесії повної присутності. Йдеться про 10-хвилинні проміжки, коли:

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

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

Такий формат має кілька важливих наслідків:

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

Чому це працює для лідерів техкомпаній

Для керівників, які звикли мислити слотами календаря, 10-хвилинні блоки — зрозумілий і керований інструмент. Їх можна:

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

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

Джерело

YouTube: Navigating Parenting as a $BN CEO

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

У центрі цієї перебудови — серія Gemini 3.1 та нове покоління відкритих моделей Gemma 4. Про те, як тепер виглядає модельний ландшафт Google і як у ньому орієнтуватися, розповідає Пейдж Бейлі, одна з лідерок напрямку developer relations у Google DeepMind, яка працює в машинному навчанні з 2009 року і свого часу робила внесок у NumPy, SciPy та scikit‑learn.

Місяць і півтора «AI‑швидкості»: навіщо Google так часто оновлює стек

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

У фокусі — серія Gemini 3.1:
Gemini 3.1 Pro, Gemini 3.1 Flash, Gemini 3.1 Flash‑Lite та Gemini 3.1 Flash Live. Паралельно з ними з’являється Gemma 4 як частина відкритої лінійки моделей, але вже не як «паралельний світ», а як елемент того ж самого стеку.

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

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

Серія Gemini 3.1: одна родина — чотири різні профілі

Серія Gemini 3.1 — це не просто «новий великий LLM», а лінійка з чітким поділом за потужністю, вартістю та сценаріями. Умовно кажучи, це не один універсальний «молоток», а набір інструментів, де кожен оптимізований під свою роботу.

Gemini 3.1 Pro: важка артилерія для найскладніших задач

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

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

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

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

Gemini 3.1 Flash: основний «робочий кінь» у продакшені

Якщо Pro — це інструмент для найважчих випадків, то Gemini 3.1 Flash — модель, яку Google прямо називає основним «production workhorse» у родині Gemini.

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

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

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

Gemini 3.1 Flash‑Lite: коли вирішують мілісекунди й копійки

Ще один елемент лінійки — Gemini 3.1 Flash‑Lite. Це менша, швидша й дешевша модель, оптимізована для сценаріїв, де критичні мінімальна затримка та наднизька вартість кожного виклику.

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

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

У сукупності Pro, Flash і Flash‑Lite формують градацію, де розробник може свідомо обирати:
де платити за глибину міркування, а де — за швидкість і масштаб.

Gemini 3.1 Flash Live: крок до живої, потокової взаємодії

У серії також присутня Gemini 3.1 Flash Live — варіант, орієнтований на інтерактивні сценарії з живою взаємодією. Деталі реалізації в демонстрації не розкриваються, але сам факт існування Live‑версії вписується в загальну логіку стеку:

Pro — для глибокого офлайн‑міркування,
Flash — для основних продакшн‑навантажень,
Flash‑Lite — для ультрашвидких і дешевих викликів,
Flash Live — для режимів, де важлива безперервна, реактивна взаємодія з користувачем.

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

Мультимодальність як базова властивість, а не «додаткова функція»

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

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

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

Практичний ефект добре видно на прикладі роботи з відео. У AI Studio можна просто вставити URL з YouTube, задати часовий діапазон і попросити, наприклад, побудувати таблицю з таймкодами та типами об’єктів у кадрі, доповнену фактами з веб‑пошуку.

У цьому сценарії модель одночасно:
аналізує відеоряд,
інтегрує зовнішні знання через Google Search,
повертає структурований текстовий результат.

Розробнику не потрібно попередньо завантажувати відео, конвертувати його, окремо запускати детектор об’єктів і потім «склеювати» все в коді. Мультимодальність стає не окремим сервісом, а властивістю базової моделі.

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

Gemma 4: відкриті ваги, але спільна екосистема

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

Gemma 4 позиціонується як частина тієї ж екосистеми. Для розробників, які з різних причин віддають перевагу open‑weight моделям — через вимоги до розгортання on‑prem, кастомного тюнінгу або ліцензійні обмеження, — це означає можливість працювати з відкритою моделлю, яка концептуально й технологічно узгоджена з рештою стеку.

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

Gemini‑моделі закривають керовані, хмарні сценарії з максимальною мультимодальністю та сервісною обв’язкою,
Gemma 4 дає можливість винести частину навантаження в середовище з відкритими вагами, не втрачаючи узгодженості з рештою інструментів.

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

Як виглядає цей стек очима розробника

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

Сервіс доступний безкоштовно за адресами a.dev, ai.studio або aistudio.google.com. Усередині — модель‑пікер, де можна обрати потрібну модель: від Gemini 3.1 Flash і Flash‑Lite до відеомоделей Veo 3.1 Lite, а також налаштувати інструменти на кшталт структурованих виходів, виконання коду, функціон‑колінгу, ґраундингу через Google Search або Maps, використання URL як контексту.

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

підвантажувати медіа з Drive, YouTube або локальних файлів,
додавати зовнішні джерела знань через пошук або простий «URL‑контекст»,
надавати моделі ізольоване Python‑середовище з попередньо встановленими науковими бібліотеками для виконання коду.

У результаті розробник може не лише обрати модель за потужністю й вартістю, а й одразу побачити, як вона поводиться в реальних сценаріях: аналіз відео, робота з документами, інтеграція з веб‑даними. А потім — одним кліком отримати готовий код для відтворення експерименту в Python, TypeScript чи Java.

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

Висновок: від «однієї великої моделі» до керованого портфеля

Новий стек Google DeepMind демонструє помітний зсув у тому, як великі гравці мислять про LLM. Замість того щоб робити ставку на один «універсальний» флагман, компанія пропонує керований портфель моделей, де:

Gemini 3.1 Pro закриває найскладніші, високоризикові задачі,
Gemini 3.1 Flash стає основним робочим інструментом для продакшн‑навантажень,
Gemini 3.1 Flash‑Lite обслуговує сценарії з жорсткими вимогами до затримки й вартості,
Gemini 3.1 Flash Live орієнтований на живу, інтерактивну взаємодію,
Gemma 4 дає відкриту, але узгоджену з екосистемою опцію для тих, хто потребує open‑weight моделей.

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

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

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

Джерело

Build & deploy AI-powered apps — Paige Bailey, Google DeepMind

У Лондоні команда OpenAI з розробницького напряму, зокрема Вайбгав Срівастав (Vaibhav Srivastav) та Катія Гіл Гусман (Katia Gil Guzman), представила оновлене бачення Codex. Те, що починалося як «розумніший автокомпліт» для програмістів, сьогодні описується як відкритий програмний інженер‑агент, здатний не лише писати код, а й виконувати команди, запускати тести, досліджувати великі кодові бази та працювати через цілу низку інструментів — від IDE до Slack і GitHub.

Це не просто ще один «AI‑асистент». Codex опирається на нове покоління моделей GPT‑5.x, працює через уніфікований агентний «harness» з вбудованою безпекою та отримав суттєві інфраструктурні покращення — від WebSocket‑стримінгу до Fast Mode, які помітно знижують затримки для розробників.

Від «агента, що пише код» до «агента, що працює як інженер»

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

Codex описують як відкритого (open) програмного інженера‑агента OpenAI. Його можливості виходять далеко за межі автодоповнення чи написання функцій. Агент може запускати команди в середовищі розробки, виконувати тести, досліджувати структуру й залежності в кодовій базі, переходити між файлами, аналізувати контекст і фактично діяти так, як це робить живий інженер, що працює з репозиторієм.

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

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

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

Єдиний агентний «harness»: як Codex керує інструментами, середовищем і безпекою

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

Цей harness виконує кілька критичних функцій.

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

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

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

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

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

Один агент — багато поверхонь: як Codex вбудовується в робочий день розробника

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

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

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

Для тих, хто віддає перевагу терміналу, є CLI‑інтерфейс. Він дозволяє взаємодіяти з агентом у звичному командному середовищі, де можна комбінувати можливості Codex з shell‑скриптами, git‑командами та іншими інструментами.

Окремий вектор — інтеграція з командними сервісами. Усередині OpenAI, як розповідають спікери, Codex активно використовують у Slack: інженери просто «пінгують» агента в каналі, просять «пофіксити» щось, пояснити помилку, допомогти з кодом. Подібний сценарій працює й у GitHub, де Codex може брати участь у рев’ю, аналізувати pull‑requests, пропонувати зміни.

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

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

Модельний стек Codex: від GPT‑5.2 до GPT‑5.4 і легких Mini/Nano

Під капотом Codex працює на сімействі моделей GPT‑5.x, які OpenAI розвиває з орієнтацією саме на інженерні сценарії.

Коли Вайбгав Срівастав приєднався до OpenAI у грудні, флагманською моделлю була GPT‑5.2. На її основі з’явилася спеціалізована версія GPT‑5.2 Codex — варіант, налаштований під задачі програмування. Ця модель стала першим кроком до того, щоб зробити агента здатним витримувати довгі, безперервні сесії роботи над кодом і довготривалі завдання.

Далі вийшла GPT‑5.3 Codex, яка продовжила цю лінію, а потім — GPT‑5.3 Codex Spark, створена у партнерстві з Cerebras. Spark позиціонують як «надшвидкий» варіант, орієнтований на сценарії, де швидкість відповіді критична.

Найсвіжіший крок — реліз GPT‑5.4, яку зараз називають state‑of‑the‑art‑моделлю. Вона стала новим флагманом, на який поступово переходить Codex. Кожне покращення в базових моделях автоматично піднімає й можливості агента: краще розуміння контексту, точніший аналіз коду, надійніша робота з довгими ланцюжками дій.

Паралельно з нарощуванням потужності великих моделей OpenAI розвиває й легші варіанти. З’явилися GPT‑5.4 Mini та GPT‑5.4 Nano — моделі, оптимізовані для коротких завдань і ролі субагентів у системі Codex.

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

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

Швидкість як функція продукту: WebSocket‑стримінг і Fast Mode

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

OpenAI робить помітний акцент на інфраструктурних покращеннях, які зменшують затримки при роботі з Codex.

Перший крок — підтримка WebSocket у API. Замість класичної моделі запит‑відповідь поверх HTTP, WebSocket дозволяє встановити постійне з’єднання між клієнтом і сервером. Це зменшує накладні витрати на встановлення з’єднання й дає змогу стримити токени швидше. У результаті, за оцінками команди, WebSocket забезпечує приблизно у 1,75 раза швидшу доставку токенів без додаткової вартості для користувачів.

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

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

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

Codex як платформа, що масштабується разом із спільнотою

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

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

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

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

Висновок: агент, що вбудовується в інженерну культуру

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

Його основу складає сімейство моделей GPT‑5.x — від GPT‑5.2 Codex до GPT‑5.4 — доповнене легкими GPT‑5.4 Mini та Nano для коротких задач і субагентів. Над моделями працює уніфікований агентний harness, який керує інструментами, середовищем, оцінкою поведінки та безпекою. А для розробників Codex доступний через низку поверхонь — десктопний додаток, IDE, CLI, Slack, GitHub і кастомні інтеграції з Figma, Linear, Notion.

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

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

Джерело

Codex and Subagents — Vaibhav Srivastav & Katia Gil Guzman, OpenAI (YouTube)