Авіакомпанія Virgin Atlantic тестує можливості OpenAI Codex у розробці свого нового мобільного застосунку. За рахунок інтеграції інструмента в роботу команд компанія фіксує помітні зміни в швидкості розробки, якості коду та досвіді користувачів.

Прискорення роботи команд

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

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

У результаті новий застосунок Virgin Atlantic вийшов у бета-версії з уже високим рівнем опрацьованості та стабільності.

Зменшення технічного боргу

Окремий акцент — на технічному боргу, який традиційно накопичується в довгострокових проєктах. Завдяки Codex командам вдалося суттєво скоротити цей борг як у самих продуктах, так і на рівні платформ:

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

Це безпосередньо впливає на надійність цифрової інфраструктури авіакомпанії та спрощує подальші оновлення.

Продуктивність, безпека й досвід користувачів

Використання Codex відобразилося не лише на внутрішніх процесах, а й на кінцевому продукті:

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

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

Джерело

What Codex Unlocks for Virgin Atlantic — OpenAI на YouTube

AI-редактор коду Cursor продовжує радикально переформатовувати власний інтерфейс і внутрішню архітектуру. Співзасновник і технічний лідер продукту Девід Гомеш на конференції AI Engineer розповів, як команда викинула тисячі рядків нативної реалізації Git work tree й перевела паралельні робочі гілки в площину “markdown як код” і slash-команд. За цим, однак, стоїть не лише спрощення коду, а й нова модель взаємодії з агентами, зміна гарантій ізоляції та довгостроковий курс на Cursor 3.0.

Від дропдаунів до slash-команд: як тепер працюють work tree в Cursor

Історично work tree в Cursor були глибоко вшиті в клієнт: окремий UI, складна логіка створення й менеджменту Git work tree, жорстка ізоляція агентів, підтримка setup-скриптів, cleanup-механізми. Усе це дозволяло запускати кілька агентів паралельно, кожен у власному Git work tree, і не боятися, що модель “втече” в основний checkout.

Нова версія працює інакше. Work tree тепер живуть не в окремому нативному модулі, а в шарі “skills/commands”, які фактично описані в Markdown і керуються з сервера. Для користувача це проявляється в тому, що замість дропдаунів з’явилися slash-команди.

Ключова зміна інтерфейсу: work tree тепер викликаються через /worktree. Користувач просто вводить команду в чаті, додає завдання — наприклад, “виправити typo у футері сайту” — і Cursor запускає агента в окремому work tree, де той виконує роботу, не торкаючись основного checkout. Паралельно з’явилася команда /bestevent (best-of-N), яка організовує змагання кількох моделей над одним завданням, кожна у власному work tree.

До цього набору додали ще дві службові команди: apply_worktree і delete_worktree. Перша переносить зміни з побічного work tree в основний checkout, друга прибирає тимчасову гілку й звільняє диск. Разом вони закривають повний життєвий цикл: створити ізольоване середовище, попрацювати, застосувати зміни, прибрати за собою.

Важливий нюанс архітектури: формально це не “user skills”, а серверні команди. Проте працюють вони майже так само: їхні промпти підвантажуються в контекст лише тоді, коли користувач явно викликає команду. Це дає Cursor можливість змінювати й покращувати поведінку work tree на бекенді без оновлення клієнта: наступний виклик /worktree автоматично отримає оновлену інструкцію для моделі.

Паралельна робота в кількох репозиторіях: multi-repo як стандарт

Один із найбільш практичних виграшів нової реалізації — підтримка multi-repo-сценаріїв. У попередній нативній версії work tree просто не працювали, якщо проєкт складався з кількох репозиторіїв, наприклад окремих frontend і backend. Функцію доводилося вимикати, і користувачі з реальними продакшн-архітектурами залишалися без паралельних агентів.

Slash-команда /worktree знімає це обмеження. Тепер Cursor, отримавши завдання в такій конфігурації, створює окремий work tree для кожного репозиторію, який входить у робочий простір. Якщо користувач просить відкрити pull request, система відкриває кілька PR — по одному на кожен репозиторій, де були зміни.

Фактично, multi-repo-підтримка стала “побічним ефектом” того, що логіка винесена в промпти й агентні сценарії. Замість того, щоб жорстко кодувати обмеження в клієнті, Cursor описує бажану поведінку в Markdown-інструкціях: створити work tree там, де є Git, запустити setup-скрипти, тримати агента в межах відповідного каталогу, а потім синхронізувати результат через PR. Для користувача це виглядає як природне розширення можливостей, але під капотом — суттєва зміна парадигми.

Ще одна важлива нова можливість — динамічне підключення work tree посеред діалогу. Раніше роботу в ізольованій гілці потрібно було конфігурувати наперед через UI: обрати режим, налаштувати параметри, запустити агента. Тепер користувач може вести звичайну розмову з агентом, а коли розуміє, що настав час “відокремити” зміни, просто ввести /worktree і продовжити роботу вже в ізольованому середовищі. Це знижує когнітивне навантаження: не потрібно планувати структуру сесії заздалегідь, достатньо викликати потрібну примітивну операцію в момент, коли вона стала доречною.

Від жорсткої ізоляції до “ізоляції через промпт”: нові ризики

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

У новій skill-базованій версії таких гарантій немає. Ізоляція тримається на промптах: Cursor агресивно інструктує модель залишатися в межах конкретного work tree, не змінювати файли в основному checkout і не “тікати” в інші гілки. Це дає величезну гнучкість — логіку можна змінювати, не торкаючись клієнтського коду, — але одночасно відкриває двері для помилок моделей.

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

Це не теоретична проблема. Cursor уже бачить у своїх eval-тестах, що менші моделі, зокрема Claude Haiku, частіше “виходять із work tree” і вносять зміни в основну копію репозиторію. Великі моделі краще дотримуються інструкцій, але й вони не ідеальні. У результаті користувачі отримують змішаний досвід: частина спільноти цінує нову гнучкість і можливість керувати work tree через slash-команди, інша частина шкодує за старим UI і жорсткою ізоляцією, яка давала більше впевненості.

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

Як Cursor тестує поведінку моделей: headless CLI, Braintrust і RL

Щоб не покладатися лише на інтуїцію й окремі користувацькі історії, Cursor вибудовує системну перевірку того, як моделі поводяться в новій архітектурі work tree. Для цього використовується headless-версія Cursor CLI, яка дозволяє проганяти сценарії без графічного інтерфейсу, та eval-інфраструктура на базі Braintrust.

Суть підходу проста: команда формулює завдання, де агент має працювати виключно в межах певного work tree, і дивиться, чи не “просочуються” зміни в основний checkout. Такі тести запускаються на різних моделях, що дозволяє порівнювати їхню дисциплінованість. Саме завдяки цим eval’ам Cursor помітив, що менші моделі на кшталт Claude Haiku частіше порушують обмеження, тоді як більші поводяться обережніше.

Ці спостереження не залишаються лише діагностикою. Cursor планує покращувати промпти для work tree саме через цикл eval → зміна промпта → повторний eval. Але на цьому компанія не зупиняється: work-tree-сценарії вбудовуються й у reinforcement learning-пайплайн власної моделі Composer.

Composer — це внутрішня модель Cursor, яку команда тренує під задачі програмування. Тепер до RL-пайплайну додаються завдання, де модель має працювати в стилі work tree: створювати ізольовані середовища, не виходити за їхні межі, коректно застосовувати зміни. Ідея полягає в тому, щоб майбутні версії Composer “з коробки” краще розуміли концепцію ізольованих робочих гілок і менше покладалися на жорсткі технічні обмеження.

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

Agent-centric Cursor 3.0 і повернення “нативних” work tree в новому вигляді

Паралельно з перебудовою work tree Cursor готує масштабні зміни в інтерфейсі. Версія 3.0 рухається до більш “агент-центричної” моделі: з’являється окреме вікно агента, яке стає центральним місцем взаємодії з AI у процесі розробки. Це не просто косметичний редизайн, а спроба зробити агентів повноцінними “учасниками” робочого процесу, а не лише доповненням до редактора.

У цьому контексті work tree розглядаються як одна з базових можливостей, яку варто глибше інтегрувати в новий агентний інтерфейс. Cursor прямо говорить про плани побудувати більш повну, “нативну” реалізацію work tree всередині нового agent window. Тобто нинішня skill-базована версія — не кінцева точка, а радше проміжний етап, який дозволяє швидко експериментувати з поведінкою й промптами, поки формується нова UI-парадигма.

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

Тому Cursor досліджує локальні примітиви паралелізації, які не залежать ані від work tree, ані від Git загалом. Ідея полягає в тому, щоб надати агентам можливість працювати в кількох “гілках реальності” локально — наприклад, через легковагові копії файлів чи інші форми ізольованих контекстів — без повноцінного Git-оверлею. Це може виявитися критичним для проєктів, де Git використовується нетипово або взагалі відсутній, але потрібна паралельна робота кількох агентів над різними варіантами змін.

У результаті майбутнє work tree в Cursor виглядає як багаторівнева система: з одного боку, класичні Git work tree для тих, хто хоче інтегруватися з існуючими CI/CD-пайплайнами й PR-процесами; з іншого — легші локальні механізми паралелізації, які можуть бути швидшими й універсальнішими. Обидва шари мають бути доступні агентам через новий agent-centric інтерфейс.

Між гнучкістю й гарантіями: куди рухається інструментарій AI-розробки

Історія work tree в Cursor добре ілюструє загальну напругу, з якою стикаються розробники AI-інструментів. З одного боку, є спокуса “зашити” поведінку в жорсткий нативний код, який дає чіткі гарантії: моделі не можуть вийти за межі дозволеного, інфраструктура контролює кожен крок. З іншого — світ LLM змінюється настільки швидко, що підтримка тисяч рядків спеціалізованого коду стає тягарем, а гнучкість промптів і серверно-керованих skills дозволяє реагувати на нові можливості й моделі значно швидше.

Перехід Cursor до slash-команд /worktree і /bestevent, появи apply_worktree та delete_worktree, підтримки multi-repo й можливості перемикатися в work tree посеред чату — усе це кроки в бік більш гнучкої, агентно-орієнтованої архітектури. Але вони ж оголюють слабкі місця: моделі не завжди слухаються, менші моделі частіше порушують ізоляцію, а частина користувачів відчуває, що втратила звичну надійність старого UI.

Відповідь Cursor — не відкат до старої нативної реалізації, а інвестиції в інфраструктуру вимірювання й навчання: headless CLI, Braintrust-eval’и, RL-тренування Composer на work-tree-подібних задачах, а також розробка нових локальних примітивів паралелізації, які можуть доповнити або частково замінити Git work tree.

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

Джерело

YouTube: Replacing 12K LoC with a 200 LoC Skill — David Gomes, Cursor

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

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

Свіжі markdown‑доки проти «model rot»: коли модель не знає, що світ змінився

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

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

Щоб обійти «model rot», команда зробила ставку на максимально просту, але потужну ідею: замість покладатися на застарілі знання моделі, вони «заливають» в контекст свіжу документацію у вигляді markdown‑файлів з posthog.com.

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

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

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

«Модельні літачки»: як прикладні проєкти задають правильну форму інтеграції

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Щоб виявляти такі ситуації системно, команда запровадила простий, але ефективний механізм: inference‑time опитування агента на стоп‑хуку кожного запуску. Коли агент завершує роботу, система ставить йому одне запитання: що ми могли зробити краще, щоб підготувати тебе до успішного виконання цього завдання?

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

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

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

Безпечна робота з .env: спеціальний інструмент замість повного доступу

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

На ранніх етапах розвитку Wizard мав можливість читати .env‑файли напряму. Це було зручно: щоб щось записати, агенту потрібно розуміти поточний вміст файлу. Але це також означало, що вміст середовища міг опинитися в логах хмарного провайдера LLM — із усіма API‑ключами та секретами.

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

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

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

Висновок: надійна LLM‑кодогенерація — це інженерія, а не магія

Досвід PostHog із Wizard показує, що успішна автономна кодогенерація — це не про «розумніші моделі», а про правильну інженерію навколо них. Свіжа markdown‑документація в контексті компенсує «model rot» і дозволяє моделі працювати з актуальними знаннями. «Модельні літачки» задають правильну форму інтеграції, з якої агент може зчитувати патерни. Breadcrumbing обмежує імпровізацію й змушує модель спочатку осмислити бізнес‑події, а вже потім писати код. Inference‑time опитування агента допомагає виявляти людські помилки в інструкціях і конфігурації інструментів. А спеціальний тул для .env показує, як можна поєднати зручність і безпеку без компромісів.

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

Джерело

LLM codegen fails and how to stop ’em — Danilo Campos, PostHog

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

1. Пауза: одна секунда, яка змінює досвід

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

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

Одна секунда перед тим, як відкрити месенджер, відповісти на лист, загуглити симптом чи новину, дозволяє:

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

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

2. Дивуватися: плавати в цікавості, а не тонути в інформації

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

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

«Плавати у власній цікавості» означає:

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

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

3. Питати вголос: відновити живий діалог

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

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

Ставити питання вголос означає:

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

Це особливо важливо в моменти вразливості — коли потрібна не інформація, а присутність.

Чому це важливо саме зараз

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

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

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

Джерело

How to make sure your IRL is actually IRL — TED

У Google DeepMind активно переосмислюють, як розробники працюють з великими мовними моделями. На воркшопі AI Engineer інженери Thor Schaeff та Philipp Schmid показують, як із новим Interactions API будувати агентів, які не просто відповідають у чаті, а реально працюють з кодом: читають і змінюють файли, запускають bash-команди, підтримують багатокрокові діалоги й ефективно керують контекстом.

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

Від generateContent до Interactions: чому архітектура агента змінюється

Interactions API, запущений у бета-версії в грудні, має замінити знайомий багатьом розробникам generateContent. Формально це нова поверхня для Gemini, але практично — інший спосіб мислити про взаємодію з моделлю.

Замість жорстко «модель-центричного» підходу Interactions API пропонує єдиний інтерфейс і для моделей, і для агентів. Це наближає його до того, що вже стало стандартом у галузі: формат, подібний до chat completions в OpenAI чи API Anthropic, з чіткою структурою повідомлень і контент-блоків.

У цьому ж інтерфейсі розробники можуть:

• викликати моделі на кшталт Gemini 1.5 Flash Free (у воркшопі її називають Gemini Free Flash) для швидких, дешевих кодових і планувальних задач;
• працювати з агентами, які мають власну логіку, інструменти та довготривалі сесії.

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

• читає файли з файлової системи;
• записує нові файли або змінює існуючі;
• виконує bash-команди локально.

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

Серверний стан і previousInteractionId: як агент «пам’ятає» розмову

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

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

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

У демонстраційному прикладі використовується клієнт GenAI з класом Agent, який зберігає глобальний previousInteractionId. Цей ідентифікатор оновлюється після кожного виклику Interactions API й використовується в наступному запиті. Таким чином, агент підтримує багатокрокову розмову, не дублюючи історію на клієнті.

Цей підхід особливо важливий для кодового агента, який:

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

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

Дешевше й швидше: як серверний стан покращує кешування

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

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

• кешовані вхідні токени можуть бути до приблизно 90% дешевшими;
• стартапи, які вже використовують Interactions API, бачать у 2–3 рази кращі показники потрапляння в кеш.

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

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

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

Свобода вибору: коли варто керувати контекстом на клієнті

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

Є кілька причин, чому хтось може обрати саме такий шлях:

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

Interactions API дозволяє працювати в обох режимах. Кодовий агент може:

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

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

Як працює кодовий агент: цикл інструментів і структуровані виклики функцій

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

Логіка виглядає так:

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

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

Кодовий агент далі:

1. Переглядає вихідні дані взаємодії й шукає в них виклики функцій.
2. Для кожного виклику визначає, яку локальну функцію потрібно виконати: наприклад, прочитати файл main.py або запустити npm test.
3. Виконує відповідну функцію в локальному середовищі.
4. Додає результат виконання як ще один структурований блок у взаємодію.
5. Повторно викликає Interactions API з оновленим контекстом, доки модель не припинить викликати інструменти.

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

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

Структуровані function_call: чому це критично для надійних інструментів

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

Такий підхід крихкий:

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

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

Для кодового агента це означає:

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

Це відкриває шлях до складніших сценаріїв:

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

У демонстраційному агенті цей механізм використовується для роботи з файловою системою й bash. Але той самий підхід можна застосувати до будь-яких інструментів: від внутрішніх API до зовнішніх сервісів.

Чому для кодового агента обрали Gemini 1.5 Flash Free

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

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

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

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

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

Практичні аспекти: ключі, безпека й розгортання агента

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

Доступ до Gemini відбувається через ключі API, які рекомендують отримувати через Google AI Studio. Потрапити туди можна за адресами ai.dev або ai.studio; потрібен лише Google-акаунт, без кредитної картки. Усе, що демонструється в сесії, вкладається в безкоштовний тариф.

Окремо наголошується: ключ API — це секрет. Його не можна:

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

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

Висновок: кодові агенти як наступний крок у роботі з LLM

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

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

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

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

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

Джерело

Building Conversational Agents — Thor Schaeff and Philipp Schmid, Google DeepMind

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

Радість як навичка, а не випадковість

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

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

Радість подається як:

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

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

Чому великі події не можуть бути єдиним джерелом щастя

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

Такий підхід створює кілька проблем:

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

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

Маленькі радощі як інфраструктура стійкості

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

Приклади таких моментів:

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

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

«Легко задовольняється» чи «часто щасливий»?

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

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

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

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

Джерело

Joy Will Find You — If You Let It | David Larbi | TED

У подкасті 20VC інвестор у SaaS‑компанії Джейсон Лемкін (SaaStr, ранній інвестор у Algolia, Talkdesk, RevenueCat, Salesloft та інші) та венчурний партнер Scale Venture Partners Рорі О’Дрісколл обговорюють, як штучний інтелект змінює економіку програмного забезпечення. Центральна тема розмови — перехід від світу, де люди обирають інструменти й моделі, до світу, де це роблять автономні AI‑агенти. І цей зсув, за їхніми оцінками, вже починає ламати звичні уявлення про конкурентні переваги, виручку та життєвий цикл SaaS‑продуктів.

Від «люди обирають софт» до «агенти обирають усе»

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

Йдеться не про повністю автономні системи, які безконтрольно запускають код і «підривають Mac mini», а про агентів, які тихо, але системно «ведуть» процеси: пишуть і відправляють листи, оновлюють CRM, ініціюють білінг, створюють звіти, запускають маркетингові кампанії, готують драфти контрактів. Люди залишаються в контурі ухвалення рішень, але саме агенти виконують левову частку рутини й технічної роботи.

Ключова зміна — саме агенти, а не люди, починають обирати:

• які моделі LLM використовувати для конкретних задач;
• які API підключати;
• які SaaS‑продукти їм реально потрібні, а які — зайві.

Лемкін прямо говорить: конкурентна перевага майбутнього буде залежати не від того, що подобається людям‑користувачам, а від того, що «подобається» агентам. Якщо раніше CTO чи VP of Engineering могли сказати: «Мені зручніше з Claude» або «Команда любить Gemini», то в агентській ері вирішальним стає інше: з якими моделями агенти працюють краще, швидше, дешевше, стабільніше.

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

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

Коли моделі оцінюють API: експеримент з «агентським» рейтингом

Щоб зрозуміти, як агенти бачать світ інструментів, Лемкін провів показовий експеримент. Він побудував «agentic API grader» — систему, де три великі моделі (Claude від Anthropic, модель OpenAI та Gemini від Google) разом оцінювали приблизно 120 найпопулярніших API та інструментів.

Мета була проста: подивитися, які сервіси AI‑агенти вважають найціннішими для себе, а не для людей‑користувачів.

Результати виявилися промовистими.

По‑перше, Stripe отримав єдину оцінку A+. Жоден інший сервіс не наблизився до такого рівня консенсусного схвалення з боку моделей. Для інвестора це виглядає як сильний сигнал на користь Stripe: інфраструктурний гравець, чий API вважається агентами максимально корисним, надійним і «інноваційним».

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

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

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

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

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

Коли агентський «грейдер» аналізував Marketo, Outreach, Salesloft та подібні сервіси, моделі фактично висловилися вкрай жорстко: ці інструменти «не мають сенсу для агентів». Формулювання, яке наводить Лемкін, звучить майже як вирок: агент «ніколи не відправить email через Outreach, Salesloft чи Marketo, бо сам здатен написати й надіслати кращий лист».

Логіка проста. Якщо агент:

• сам генерує текст листа;
• сам обирає час відправки;
• сам трекає відповіді й оновлює CRM;

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

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

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

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

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

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

Другий кошик — «стабільні системи запису» (systems of record). Це продукти на кшталт Workday, які зберігають критичні дані про бізнес: фінанси, HR, контракти, операційні показники. Вони мають довгі контракти, глибоку інтеграцію в процеси й високий бар’єр міграції. Лемкін наводить характерний приклад: Workday зазвичай підписує клієнтів на три роки з подальшими п’ятирічними пролонгаціями, фактично створюючи восьмирічний горизонт. Але навіть це, на його думку, не гарантує «вічного» утримання: це радше «вісім років, щоб знайти кращі агентські рішення».

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

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

Коли менше людей, але більший рахунок: як агенти змінюють економіку виручки

Один із найяскравіших прикладів того, як агенти змінюють економіку SaaS, Лемкін наводить на власному досвіді роботи із Salesforce.

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

Натомість річний рахунок зріс до 22 тисяч доларів.

Причина — у зміні структури споживання. Агенти:

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

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

Це демонструє, як може виглядати нова модель монетизації для SaaS:

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

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

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

Агентські війни: чому виграти «шар агентів» важливіше, ніж просто мати модель

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

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

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

О’Дрісколл порівнює ринок базових моделей із трьохстороннім олігополієм у хмарній інфраструктурі: OpenAI, Anthropic і Gemini нагадують AWS, Google Cloud і Azure. У такому світі, якщо ти керуєш однією з цих платформ, логічно прагнути не лише продавати «сиру» обчислювальну потужність і моделі, а й контролювати шар, де агенти приймають рішення.

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

Чому довгі контракти більше не гарантують безпеки

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

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

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

• працювати поверх даних Workday;
• або навіть замінити Workday як систему запису;

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

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

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

Висновок: агентська оптика як новий обов’язковий фільтр

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

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

Прогноз Лемкіна про те, що до 2026–2027 років більшість робочих процесів будуть керуватися агентами, може здатися агресивним. Але вже сьогодні видно перші контури цього світу: агенти, які самі обирають OpenAI як улюблений API; моделі, які називають класичні маркетингові платформи «марними»; інфраструктурні сервіси на кшталт Stripe, що отримують єдину оцінку A+ від трьох провідних моделей.

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

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

Джерело

YouTube: Anthropic Raises $45B but Falls Short on Compute & Thoma Bravo Hand Back Medallia Keys to Creditors

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

Коли софт перестав бути «ровом» навколо бізнесу

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

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

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

Екосистема як справжня конкурентна перевага

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

Кілька ключових елементів такої екосистеми:

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

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

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

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

Платформи й вертикальна інтеграція: чому їх важко клонувати

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

Платформа замість окремого продукту

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

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

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

Ставка на апаратну частину

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

Причини, чому це важко повторити:

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

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

Що це означає для AI‑стартапів і продуктів

Ситуація з AI сьогодні дуже схожа на те, що вже відбулося із софтом:

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

Практичні висновки для команд, що працюють з AI:

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

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

Джерело

YouTube: Software is not a moat — Lenny’s Podcast

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

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

Чому Claude Code недоступний безкоштовно і що це означає для користувача

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

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

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

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

Claude Pro за $20 на місяць: оптимальний вхідний квиток для навчання й особистих проєктів

Для більшості нових користувачів, які тільки знайомляться з Claude Code, рекомендованим стартовим варіантом є план Claude Pro вартістю $20 на місяць. Частина аудиторії вже може мати цю підписку для звичайної роботи з Claude як чат-моделлю, і в такому разі доступ до Claude Code відкривається без додаткових кроків.

Pro-план логічно позиціонується як «робоча конячка» для навчання, експериментів і створення персональних інструментів. У демонстрації Futurepedia на ньому будуються цілком реальні проєкти: від 3D-браузерної гри до корисних дашбордів і автоматизацій. Користувачеві не потрібно писати код, достатньо формулювати завдання природною мовою, перемикатися в Plan Mode для початкового планування, а потім ітеруватися через прості уточнювальні промпти.

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

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

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

Claude Max за $100: коли «іграшка» перетворюється на робочий двигун

Якщо Pro — це оптимальний старт для більшості, то Claude Max за $100 на місяць орієнтований на тих, хто планує використовувати Claude Code як інтенсивний робочий інструмент. Йдеться про сценарії, де білди запускаються часто, проєкти стають складнішими, а кожна сесія включає велику кількість ітерацій.

Max-план дає суттєво вищі ліміти використання. Це особливо важливо для користувачів, які:

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

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

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

П’ятигодинні «дихальні паузи»: як працює перезавантаження лімітів

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

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

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

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

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

Щотижневий стеля: чому важливо стежити за розділом Settings → Usage

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

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

Щоб не опинитися в ситуації, коли важливий білд зупиняється на півдорозі через неочікуване вичерпання тижневого ліміту, варто регулярно перевіряти розділ Settings → Usage у інтерфейсі Claude. Там відображається поточний стан використання, що дозволяє:

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

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

Як поєднати плани й ліміти з реальним процесом розробки

Фінальна картина використання Claude Code складається з трьох шарів: тип підписки (Pro чи Max), п’ятигодинні перезавантаження лімітів і тижневий стеля. Разом вони формують рамки, в яких користувачеві доводиться планувати свою роботу.

Для тих, хто тільки починає, логіка може виглядати так. Спочатку оформлюється Pro за $20 на місяць. У перші дні користувач знайомиться з інтерфейсом десктопного застосунку, обирає локальну папку для проєкту, запускає перший білд через Plan Mode, дивиться, як Claude Code створює файли, використовує інструменти, тестує гру чи застосунок у вбудованому прев’ю. Потім починається ітераційна фаза: дрібні зміни, одна за одною, з перевіркою результатів після кожного кроку.

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

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

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

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

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

Висновок: Claude Code як сервіс, а не «чарівна кнопка»

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

Доступ до Claude Code вимагає платної підписки Claude. Для більшості користувачів, які вчаться, експериментують і будують особисті інструменти, оптимальним стартом є план Pro за $20 на місяць. Для тих, хто використовує Claude Code інтенсивно й регулярно, логічним кроком стає перехід на Max за $100, що дає суттєво вищі ліміти.

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

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

Джерело

The Ultimate Non-Technical Guide to Claude Code — Futurepedia

У динамічному технологічному середовищі ввічливість і м’якість часто вважаються безумовними чеснотами. Та фрагмент розмови в подкасті 20VC with Harry Stebbings піднімає неприємне, але важливе питання: чи не стає культ «доброти» причиною втрати часу й темпу розвитку команд?

Коли ввічливість перетворюється на втрату часу

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

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

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

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

Агресивність як інструмент, а не вада

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

Агресивність у цьому контексті — це:

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

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

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

Команда, що «тисне на газ», а не на гальма

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

Пріоритети в такій культурі:

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

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

Джерело

YouTube: «kindness is slowing you down» – 20VC with Harry Stebbings

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

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

Рекордний британський пакет: 120 тисяч дронів як політичний і промисловий сигнал

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

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

Такий підхід важливий з кількох причин.

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

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

По‑третє, у пакет інтегруються як британські, так і європейські розробки, локалізовані у Британії. Показовий приклад — португальська компанія Tekever, яка має виробництво у Сполученому Королівстві й постачає свої дрони в рамках цього пакета. Таким чином, Лондон стає хабом, де перетинаються європейські технології та британська промислова база.

Tekever AR3 та AR5: дорога розвідка з низьким тепловим слідом

Серед можливих компонентів британського пакета для України — розвідувальні дрони Tekever AR3 та AR5. Це не масові «розхідники» рівня комерційних квадрокоптерів, а дорогі спеціалізовані платформи для глибокої розвідки.

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

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

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

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

Octopus: українсько‑британський зенітний дрон як модель спільної розробки

Окремий елемент британського пакета — зенітні дрони Octopus. Це вже не просто імпорт готового продукту, а результат спільної розробки: систему створили українські військові у співпраці з британськими партнерами.

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

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

Однак вартість цієї технологічної основи відчутно зросла. Якщо раніше модуль Nvidia Jetson коштував приблизно 300 доларів, то зараз ціна піднялася до діапазону 500–800 доларів за одиницю. Для серійного виробництва це суттєвий фактор: собівартість кожного дрона зростає, а отже, дорожчає і масштабування системи.

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

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

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

Вихід українських дронів на британський ринок оборонних закупівель

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

Для українського miltech‑сектору це має кілька наслідків.

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

По‑друге, вихід на такий ринок автоматично підвищує вимоги до якості, стандартизації, документації, випробувань і after‑sales підтримки. Британські оборонні закупівлі — це складні процедури, де кожен елемент має відповідати чітким критеріям. Для українських компаній це стимул підтягувати процеси до рівня НАТО‑стандартів, що в перспективі полегшує вихід і на інші ринки.

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

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

ЄС: 90 мільярдів євро кредиту й пріоритет українських дронів

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

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

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

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

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

Запит України на 2026 рік: 28 мільярдів євро з акцентом на безпілотники

Ще один елемент довгострокової картини — Україна подала запит на оборонну допомогу ЄС на 2026 рік на суму 28 млрд євро. У цьому запиті пріоритет віддано безпілотним системам українського виробництва.

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

Для галузі це критично. Масштабування виробництва дронів — це не лише закупівля додаткових верстатів чи оренда цеху. Це інвестиції в інженерні команди, R&D, сертифікацію, логістику, навчання операторів. Усе це потребує впевненості, що попит не зникне через півроку.

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

Ліцензування та локалізація: як українські технології масштабуються через партнерів

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

Це дає кілька переваг.

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

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

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

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

Висновок: від «допомоги дронами» до спільної дронової індустрії

Рекордний британський пакет у 120 000 дронів, інтеграція систем Tekever AR3/AR5, поява зенітних Octopus як спільної українсько‑британської розробки, ліцензування через ЦМТР, вихід українських виробників на британські оборонні закупівлі, а також європейська кредитна програма на 90 млрд євро з першим траншем на українські дрони — усе це елементи однієї картини.

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

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

Джерело

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

У світі інструментів для розробників рідко трапляються моменти, коли команда свідомо видаляє 15 тисяч рядків працюючого коду й замінює їх на кількасот рядків тексту у Markdown. Саме це зробив Cursor — AI-редактор коду, відомий своїми агентами та глибокою інтеграцією з Git. Співзасновник і технічний лідер Cursor Девід Гомеш розповів, як команда спочатку побудувала складну нативну реалізацію Git work trees і режиму Best-of-N, а потім повністю викинула її й відтворила ту саму поведінку як набір «скилів» і субагентів, описаних у Markdown-промптах.

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

Важка артилерія Cursor 2.0: work trees і Best-of-N як нативна фіча

Щоб зрозуміти масштаб змін, варто повернутися до жовтня 2023 року, коли разом із Cursor 2.0 з’явилися дві ключові можливості: Git work trees та режим Best-of-N. Вони були реалізовані як повноцінна нативна фіча всередині застосунку.

Git work trees у Cursor — це, по суті, паралельні checkout-и репозиторію. Кожен work tree — окреме робоче дерево, в якому агент може змінювати код, запускати команди, лінтери й тести, не торкаючись основної гілки розробника. На екрані це виглядало як сітка агентів, що одночасно працюють над різними задачами або навіть над однією задачею, але в різних варіантах.

Ключова ідея: один і той самий файл міг існувати в кількох work trees з різним вмістом. Агент змінював файл у своєму ізольованому дереві, а основний checkout залишався недоторканим, доки користувач не вирішував застосувати зміни або відкрити pull request саме з цього work tree.

На цьому фундаменті Cursor побудував Best-of-N — режим, у якому одна й та сама задача віддається кільком моделям одночасно. Кожна модель працює у власному work tree, генерує свою реалізацію, а користувач може:

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

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

Ціна такої потужності була високою. Початкова реалізація work trees і Best-of-N складалася приблизно з 15 000 рядків коду. Вона включала:

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

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

Велике видалення: мінус 15 000 рядків і перехід до Markdown-скілів

Наступний крок виглядає радикально навіть за мірками швидкого AI-розвитку. Cursor відкрив pull request, у якому повністю видалив нативну реалізацію work trees. Застосунок втратив близько 15 тисяч рядків коду — ціла підсистема зникла.

На її місці з’явився інший підхід: замість того, щоб реалізовувати поведінку work trees і Best-of-N у вигляді класичного застосункового коду, команда перенесла логіку в промпти — так звані «скили» та субагенти, описані у Markdown.

Це означало кілька принципових змін.

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

По-друге, розмір реалізації скоротився на порядки. Якщо попередня версія Best-of-N займала близько 4 000 рядків коду, то новий Best-of-N-скіл вміщується приблизно в 40 рядках Markdown. Разом із новим скілом для work trees загальний обсяг — «порядку кількох сотень рядків» Markdown, які замінюють 12–15 тисяч рядків нативної системи.

По-третє, ці скіли стали частиною сервер-контрольованих команд. Промпти, які описують поведінку work trees і Best-of-N, живуть на бекенді Cursor. Їх можна змінювати, не випускаючи нову версію клієнта. Коли користувач наступного разу викликає відповідну команду, він автоматично отримує оновлену логіку.

Фактично Cursor перетворив частину свого продукту з «коду як артефакту» на «код як текстову специфікацію для моделі».

Як працює новий шар: скіли, субагенти й 40 рядків Markdown

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

Команда зрозуміла, що, комбінуючи ці два механізми, можна відтворити і поведінку work trees, і Best-of-N без важкої нативної реалізації.

Новий скіл для work trees описує кілька ключових речей:

• як створити Git work tree;
• як запустити користувацькі setup-скрипти, якщо вони налаштовані;
• як працювати всередині цього checkout-а;
• як не виходити за його межі.

Це — текстові інструкції для моделі, написані у Markdown. Вони враховують кросплатформеність: окремі вказівки для Windows, Linux і macOS. Модель отримує чіткі кроки, які команди запускати й у якому середовищі.

Best-of-N реалізовано як окремий скіл, ще компактніший. Приблизно 40 рядків Markdown описують сценарій, у якому:

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

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

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

Команди замість UI: /worktree, /bestevent і сервер-контрольовані промпти

Разом із переходом на скіли змінився й спосіб взаємодії користувача з work trees і Best-of-N. Якщо раніше це була частина UI з випадаючими списками та налаштуваннями, то тепер усе зведено до slash-команд.

Основні нові команди:

• /worktree — створює ізольований work tree для задачі, яку формулює користувач. Наприклад, можна написати /worktree fix a typo in the footer of the website, і агент виконає цю правку у власному work tree, не торкаючись основного checkout-а.
• /bestevent — запускає режим Best-of-N, коли одна й та сама задача віддається кільком моделям, кожна у своєму work tree.

Додатково з’явилися:

• apply_worktree — переносить зміни з побічного work tree в основний checkout;
• delete_worktree — видаляє work tree й очищує сліди його роботи.

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

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

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

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

З точки зору користувача, новий підхід має ще одну практичну перевагу: тепер можна переключитися в work tree посеред розмови з агентом. Раніше UI не дозволяв елегантно додати таку опцію, не перевантажуючи інтерфейс. Тепер достатньо в будь-який момент ввести /worktree з описом задачі — і агент продовжить роботу вже в ізольованому дереві.

Нові можливості: мульти-репо, гнучкі Best-of-N і менше техборгу

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

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

Новий /worktree поводиться інакше. Якщо користувач працює з кількома репозиторіями одночасно, агент створює окремий work tree для кожного з них. Коли користувач просить відкрити pull request, система формує кілька PR-ів — по одному на кожен репозиторій. Таким чином, паралельна робота з фронтендом і бекендом у рамках однієї задачі стає прозорою.

Ще одна суттєва зміна стосується Best-of-N. У новій реалізації батьківський агент має значно більше контексту про те, що зробив кожен субагент у своєму work tree. Це дозволяє не лише «вказати переможця», а й:

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

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

З інженерної точки зору головний плюс очевидний: обсяг коду, який потрібно підтримувати, різко скоротився. Work trees — це фіча для «паверкористувачів», а не для 90% аудиторії Cursor. Тримати для неї окрему складну нативну підсистему з тисячами рядків коду означало постійний технічний борг. Перенесення логіки в кількасот рядків Markdown знімає значну частину цього навантаження.

Ціна гнучкості: коли ізоляція тримається на промптах

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

У старій системі модель фізично не могла торкнутися файлів поза своїм work tree. Інфраструктура просто не давала їй такої можливості. Це гарантувало, що жодна дія агента не зачепить основний checkout, поки користувач сам не вирішить застосувати зміни.

Тепер Cursor «довіряє» моделі. Ізоляція забезпечується не системними обмеженнями, а промптами. Модель багаторазово й наполегливо просять:

• працювати тільки в межах конкретного work tree;
• не змінювати файли в основному checkout-і;
• не «втекти» з виділеного середовища.

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

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

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

Висновок: коли продуктова логіка переїжджає з коду в промпти

Історія work trees і Best-of-N у Cursor — це концентрований приклад того, як змінюється інженерна практика в епоху LLM. Те, що ще рік тому здавалося «нормальним» — тисячі рядків нативного коду, складна інфраструктура, жорстка ізоляція на рівні системи, — сьогодні може бути замінено кількома сотнями рядків Markdown, які описують поведінку моделі.

Цей перехід має кілька вимірів.

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

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

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

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

Джерело

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

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

Цей матеріал розбирає, як влаштований PostHog Wizard, чому він майже повністю побудований на markdown-документах, як працює контекстна стратегія зі «skill-файлами» та «модельними літачками» (model airplanes), і чому ставка на простий текст виявляється виграшною в епоху швидкого прогресу LLM.

Markdown як ядро: чому 90% системи — це просто текст

Якщо дивитися на PostHog Wizard як на програмний продукт, його структура нетипова для інструмента, який щомісяця генерує інтеграції для тисяч проєктів. Кампос описує її як систему, де приблизно 90% — це markdown-файли, ще близько 8% — інструменти для доставки й обробки цього markdown, а решта — тонкий «harness» для агента, який з’єднує все разом.

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

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

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

Як Wizard бореться з «model rot»: свіжа документація як контекст

Одна з базових проблем будь-якого LLM-агента — «model rot». Моделі тренуються на знімку світу, який швидко застаріває, особливо для швидкорухомих софтверних продуктів. PostHog постійно змінюється: API, SDK, найкращі практики інтеграції — усе це оновлюється значно частіше, ніж виходять нові версії великих моделей.

Щоб компенсувати це відставання, Wizard агресивно підживлює модель свіжим контекстом у вигляді markdown-документації з posthog.com. Замість того, щоб покладатися на те, що модель «колись читала» про PostHog під час тренування, система під час кожного запуску підтягує актуальні інструкції.

Механіка побудована навколо інструментів, які дозволяють агенту самостійно обирати потрібні документи. Wizard спочатку визначає, що саме інтегрується — які фреймворки й мови використовує проєкт. Після цього агент отримує можливість викликати спеціальні «markdown-інструменти» й завантажувати у свій контекст відповідні фрагменти документації: наприклад, інструкції для React, Next.js, Django чи іншого середовища.

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

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

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

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

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

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

Ці проєкти виконують одразу кілька ролей.

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

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

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

Контекстна служба та skill-файли: як зшиваються документація й приклади

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

Ця служба генерує так звані skill-файли — структуровані markdown-документи, які описують конкретні «вміння» агента. Наприклад, інтеграція PostHog у React-додаток або налаштування подій у бекенді на Python. У кожному такому файлі поєднуються кілька типів контенту.

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

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

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

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

Як Wizard працює для розробника: один CLI-запуск поверх агентної платформи

З точки зору користувача PostHog Wizard виглядає максимально просто: це CLI-інструмент, який запускається однією командою в корені проєкту. Усередині ж він обгортає Claude Agent SDK — агентну платформу від Anthropic, яка забезпечує планування кроків, виклик інструментів і роботу з контекстом.

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

Над цим шаром працює власне агент, який керується markdown-інструкціями й skill-файлами. Він поетапно виконує завдання: спочатку шукає файли з бізнес-цінністю (логін, платежі, потенційні точки відтоку користувачів), потім формує список подій, які варто відстежувати, а вже після цього, спираючись на документацію й код із model airplanes, вставляє виклики PostHog у відповідні місця.

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

Чому ставка на текст працює краще, ніж складний код

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

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

По-друге, текст легше підтримувати. Оновити інструкцію в markdown-файлі простіше, ніж змінювати код агента, тестувати нові гілки логіки й уникати регресій. Для продукту, який живе в тісному зв’язку з документацією, це особливо важливо: зміни в API чи SDK можна відобразити одночасно і в публічній документації, і в контексті Wizard.

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

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

Висновок: інтеграція як редакторська задача

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

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

Джерело

LLM codegen fails and how to stop ’em — Danilo Campos, PostHog

Google тихо додав до Gemini можливість генерувати файли — від PDF і Word до Google Docs, Sheets і Slides. Автор каналу Teacher’s Tech детально протестував оновлення й показав, що воно означає не лише для окремих користувачів, а й для майбутнього всієї екосистеми Google Workspace.

Як працює генерація файлів у Gemini

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

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

Підтримувані типи:

• Файли Google Workspace:
• Google Docs
• Google Sheets

• Google Slides

• Формати для завантаження:

• PDF
• Microsoft Word
• Microsoft Excel
• CSV
• plain text (звичайний текст)
• rich text (RTF)
• Markdown
• LaTeX

Логіка використання проста: один раз згенерувати зміст, а потім переносити його в потрібний формат без повторного промптування.

Приклад: з «сирих» нотаток — у готовий документ

Типовий сценарій — перетворення неструктурованих нотаток на оформлений документ. Наприклад:

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

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

Далі можна просто змінити формат, не переписуючи промпт і не копіюючи текст:

• «тепер дай цей самий зміст як Word-документ, щоб я міг його редагувати».

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

Інтеграція з Google Drive: перші ознаки «розумного» Workspace

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

«Drive-aware» промпти: коли AI сам знаходить потрібний файл

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

• «знайди в моєму Drive таблицю Q1 tutorial performance і зроби односторінковий PDF-екзек’ютив-самарі: три найуспішніші відео, три найгірші й діаграма з порівнянням часу перегляду».

Gemini:

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

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

Створення презентацій із даних

Ще один очікуваний сценарій — автоматичне створення презентацій. Наприклад, можна попросити:

• «візьми ті самі Q1-дані про відео й перетвори їх на презентацію Google Slides: шість слайдів, чистий сучасний дизайн, діаграма на третьому слайді».

Gemini спочатку формує структуру презентації у своєму інтерфейсі, після чого її можна:

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

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

Обмеження: PowerPoint і редагування існуючих файлів

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

PowerPoint: чому PPTX досі «за бортом»

Формат PowerPoint (PPTX) не входить до переліку підтримуваних. Якщо попросити Gemini:

• «зроби мені PowerPoint-презентацію про топ-3 відео з цього звіту, з картинками й сучасним дизайном»,

можливі два сценарії:

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

У будь-якому разі це не прямий PPTX. Якщо завантажити файл, він приходить як PDF, а не як PowerPoint.

Реальний робочий обхідний шлях зараз такий:

1. Згенерувати презентацію як Google Slides.
2. Відкрити її в Google Slides.
3. Використати File → Download → Microsoft PowerPoint (.pptx).

Тобто прямої підтримки PPTX у Gemini поки немає, і це не проблема промптів — це технічне обмеження поточної реалізації.

Gemini не вміє редагувати вже існуючі файли в Drive

Друге обмеження менш очевидне, але стратегічно важливіше.

Сьогодні Gemini:

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

Як це виглядає на практиці:

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

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

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

Від чат-бота до «Workspace Intelligence»

Окремо можливість створювати PDF чи Word-документи — не революція. Подібні функції вже давно є в ChatGPT і Claude. Важливіше інше: як це оновлення вписується в ширшу стратегію Google.

За шість днів до запуску генерації файлів на Gemini, на конференції Cloud Next 2026 Google представила концепцію Workspace Intelligence.

Що таке Workspace Intelligence

Ідея полягає в тому, щоб додати «розумний» шар під усіма сервісами Google Workspace:

• Gmail
• Drive
• Calendar
• Chat
• Docs
• Sheets
• Slides

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

Обіцяний ефект:

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

Чому нова функція — лише перший крок

Поточна генерація файлів — це перший споживчий елемент цієї стратегії:

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

Саме ця «прірва» між читанням/створенням і повноцінним редагуванням — те, що Google ще має подолати, якщо хоче, щоб Gemini став справжнім робочим асистентом у Workspace, а не окремим «пісочним майданчиком» поруч.

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

Кому це корисно вже зараз, а кому варто просто спостерігати

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

• швидке перетворення «чернеток» на оформлені документи;
• автоматичні PDF-звіти з таблиць у Drive;
• базові презентації з даних без ручної збірки слайдів;
• можливість легко переключатися між форматами (PDF → Word → Google Docs тощо).

Особливо корисними виглядають Drive-aware промпти для тих, хто регулярно має справу зі звітністю, аналітикою й спільними файлами.

Якщо ж Google Drive не є центром щоденної роботи, нинішнє оновлення радше сигналізує про напрямок розвитку: важливіше не те, що Gemini вже вміє створювати файли, а те, що Google поступово перетворює його з окремого чат-бота на інтегрованого асистента всередині Workspace.

Джерело

Gemini’s New File Feature Tested – What Actually Works

На конференції AI Engineer інженери Google DeepMind Тор Шефф і Філіп Шмід показують, як будувати розмовні агентні системи на базі Gemini. Окремий блок їхнього воркшопу присвячений тому, з чого взагалі почати: як отримати доступ до Gemini, що таке новий Interactions API, чому він замінює generateContent і як зробити перші кроки, не витрачаючи грошей. Саме на цих аспектах зосередимося в цьому матеріалі.

Від generateContent до Interactions: навіщо Gemini новий API

Gemini як платформа для розробників розвивається швидко, і класичний підхід через generateContent поступово вичерпує себе. У грудні Google DeepMind запустила в бета-версії новий Interactions API, який має стати наступником generateContent і фактично змінити спосіб, у який розробники працюють з моделями Gemini.

Ключова ідея Interactions API — уніфікація. Замість того, щоб мати окремі механізми для “голих” моделей і для складніших агентів, тепер пропонується єдина поверхня, яка працює і з моделями, і з агентами. Це наближає Gemini до того, до чого вже звикли розробники, що працювали з OpenAI чи Anthropic: за духом Interactions API нагадує chat completions та сучасні API конкурентів.

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

• викликати модель на кшталт Gemini 1.5 Flash Free для швидких відповідей;
• звернутися до вбудованого агента, наприклад Deep Research, який працює довго й асинхронно;
• комбінувати моделі, агентів і інструменти в єдиному сценарії.

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

Інтерфейс, зрозумілий веб-розробникам: менше gRPC, більше “людського” JSON

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

Новий API:

• менше орієнтований на proto та gRPC;
• більше нагадує звичні HTTP+JSON інтерфейси, з якими працює більшість фронтенд- і бекенд-розробників;
• використовує єдину модель контенту з чітко типізованими блоками.

Центральний елемент — “content blocks”: кожен вхід і вихід моделі або агента описується однаковим типом об’єкта з полем type. Це поле може позначати текст, аудіо, відео, зображення, function_call, а також спеціальний тип thought_signature. Таким чином, замість різнорідних структур для різних модальностей і дій, розробник працює з єдиною схемою, де все — просто різні типи контенту.

Для веб-розробника це означає менше “перемикання контексту” між форматами і протоколами. Взаємодія з Gemini стає схожою на роботу з будь-яким сучасним REST/streaming API: знайомі JSON-структури, знайомі патерни стрімінгу через Server-Sent Events (SSE), знайомий підхід до авторизації через API-ключ.

Саме підтримка SSE — ще один важливий штрих. Interactions API дозволяє отримувати відповіді в стрімінговому режимі, що критично для розмовних інтерфейсів, де користувач очікує перших токенів відповіді вже за частки секунди. Для фронтенду це означає можливість будувати чат-інтерфейси з “друком у реальному часі” без складних обхідних маневрів.

Єдиний API для моделей і агентів: від швидких відповідей до глибоких досліджень

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

З боку моделей у воркшопі як “робоча конячка” використовується Gemini 1.5 Flash Free (часто його називають Gemini Free Flash). Це безкоштовний, швидкий і відносно дешевий варіант, який добре підходить для кодування, планування і типових агентних сценаріїв за умови, що модель отримує чіткі інструкції та “навички” через інструменти.

З боку агентів у Interactions API вже вбудований Deep Research. Це агент, який може виконувати довгі дослідницькі завдання у фоновому режимі — на рівні 10–15 хвилин, відвідуючи сотні сайтів. У споживчому продукті Gemini подібний режим знайомий як “глибоке дослідження”: користувач формулює запит, отримує план, а далі система самостійно збирає й узагальнює інформацію.

У контексті API це виглядає як ще один “агент”, до якого можна звернутися так само, як до моделі. Розробник у запиті або вказує модель (наприклад, Gemini 1.5 Flash Free), або агента (наприклад, Deep Research). Поверхня API при цьому залишається однаковою, що спрощує перемикання між швидкими відповідями й довгими асинхронними сценаріями.

Важливо, що Interactions API з самого початку спроєктований з урахуванням довготривалих задач. Для таких агентів, як Deep Research, передбачено асинхронне виконання у фоні: запит можна запустити, а потім або опитувати API, або (коли це стане доступно) отримувати нотифікації через вебхуки. Це знімає необхідність тримати HTTP-з’єднання відкритим хвилинами, що суперечить добрим практикам веб-розробки.

Серверний стан, кешування і контроль над контекстом

Ще одна фундаментальна відмінність Interactions API від generateContent — поява серверного стану. У класичній схемі клієнт повинен був щоразу надсилати повну історію діалогу, щоб модель “пам’ятала” контекст. Це ускладнювало клієнтську логіку, збільшувало обсяг даних і витрати на токени.

У новому API з’являється поняття previousInteractionId. Кожна взаємодія зберігається на сервері, і замість того, щоб повторно надсилати всю історію, клієнт може передати ідентифікатор попередньої взаємодії. Сервер “прикріпить” новий запит до вже наявного контексту.

Це дає кілька практичних переваг.

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

По-друге, суттєво покращується кешування. Оскільки сервер бачить стабільний контекст, він може ефективніше кешувати кодування вхідних токенів. Для розробників це перетворюється на економію: закешовані вхідні токени можуть бути до 90% дешевшими, а стартапи, які вже використовують цей механізм, бачать у 2–3 рази кращі показники cache hit rate. Для проєктів із великими й повторюваними контекстами це може стати помітним фактором у структурі витрат.

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

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

Інструменти, комбінування та єдина модель контенту

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

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

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

По-третє, Interactions API представляє виклики функцій і результати цих викликів як структуровані типи в результаті взаємодії. Це означає, що модель не просто “вигадує” текст із описом того, що вона нібито викликала, а повертає чітко структуровані об’єкти function_call і function_result. Для розробника це спрощує побудову циклів, де код:

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

Єдина модель контенту з типами text, audio, video, image, function_call, thought_signature робить цей процес уніфікованим. Незалежно від того, чи модель відповідає текстом, генерує зображення, ініціює виклик функції або “позначає” внутрішні міркування через thought_signature, усе це виглядає для клієнта як послідовність контент-блоків із різними типами.

Як отримати доступ до Gemini: AI Studio, ai.dev і безкоштовний рівень

Щоб почати працювати з Interactions API, потрібен API-ключ Gemini. Google DeepMind рекомендує отримувати його через Google AI Studio — веб-інструмент, який одночасно слугує “пісочницею” для експериментів із моделями та панеллю керування ключами.

Дістатися до AI Studio можна кількома шляхами. Найкоротший — перейти на ai.dev: цей домен просто редіректить на AI Studio, але саме його організатори воркшопу просять використовувати. Також працюють адреси ai.studio та aistudio.com, але ai.dev — найпростіший для запам’ятовування.

Процес отримання ключа виглядає так:

1. Користувач заходить на ai.dev або AI Studio.
2. Авторизується під своїм Google-акаунтом.
3. У розділі API keys (зазвичай у правому верхньому куті) натискає “Create API key”.
4. Якщо потрібно, створює або імпортує проєкт, дає йому будь-яку назву.
5. Через кілька секунд отримує згенерований ключ.

Важливий момент: для безкоштовного рівня не потрібна банківська картка. Достатньо мати Google-акаунт. Усі приклади, які демонструються у воркшопі, спеціально підібрані так, щоб укладатися в ліміти безкоштовного тарифу. Це дозволяє учасникам і, ширше, будь-яким розробникам повторювати приклади, експериментувати з Interactions API і Gemini 1.5 Flash Free, не ризикуючи отримати несподіваний рахунок.

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

Безпека доступу: чому API-ключ Gemini — це секрет

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

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

Рекомендації тут класичні, але їх варто повторити:

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

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

Перші кроки: що дає Interactions API розробнику вже сьогодні

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

По-перше, це уніфікований інтерфейс для моделей і агентів. Розробник може почати з простого сценарію — наприклад, чат-бота на базі Gemini 1.5 Flash Free — і поступово додавати агентні можливості, не змінюючи фундаментально спосіб взаємодії з API.

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

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

По-четверте, це знайомий для веб-розробників стек: HTTP, JSON, SSE, мінімум специфічних протоколів. Це означає, що інтеграція з фронтендом, бекендом на Node.js, Python чи будь-якій іншій популярній платформі не вимагатиме глибокого занурення в gRPC або protobuf.

Нарешті, безкоштовний рівень доступу через AI Studio дозволяє експериментувати без ризику. Усі приклади з воркшопу свідомо спроєктовані так, щоб укладатися в ліміти free tier, тож розробник може повторити їх, адаптувати під свої задачі й поступово нарощувати складність.

Висновок: Interactions API як нова точка входу в екосистему Gemini

Запуск Interactions API в бета-версії — це не просто черговий endpoint у лінійці Gemini. Це спроба переосмислити, як розробники взаємодіють із моделями й агентами, зробити цей досвід ближчим до галузевих стандартів і водночас зберегти сильні сторони екосистеми Google.

Уніфікований інтерфейс для моделей і агентів, серверний стан із покращеним кешуванням, єдина модель контенту для тексту, аудіо, відео, зображень і викликів функцій, підтримка SSE, вбудовані агенти на кшталт Deep Research, можливість комбінувати Google Search із власними інструментами — усе це формує платформу, на якій можна будувати як прості чат-боти, так і складні розмовні системи.

Для тих, хто лише починає знайомство з Gemini, шлях виглядає досить прямолінійно: зайти на ai.dev, отримати безкоштовний API-ключ через AI Studio, уважно поставитися до безпеки цього ключа й почати експериментувати з Interactions API на базі Gemini 1.5 Flash Free. Далі — питання уяви й конкретних бізнес-завдань.

Джерело

Building Conversational Agents — Thor Schaeff and Philipp Schmid, Google DeepMind