Сучасні пайплайни обробки даних народили цілу екосистему термінів — data warehouse, data lake, lakehouse, streaming, TableFlow. У новому освітньому ролику Confluent Developer пояснює, як саме ці технології з’явилися, які проблеми вони вирішують і чому їхні назви насправді логічні, а не просто маркетинг.

Витоки: дата-склади та ера schema-on-write

Першим кроком стали data warehouses — по суті, спеціалізовані бази даних для аналітики.

Традиційні бази будувалися для OLTP (online transaction processing): швидкі, дрібні операції — платежі, замовлення, оновлення записів. Для цього обиралися одні архітектурні рішення, але вони погано підходили для аналітичних запитів по великих масивах даних.

Data warehouse орієнтований на OLAP (online analytical processing):

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

Ключова ідея — schema-on-write:

1. Спочатку визначається структура таблиці (поля, типи, обмеження).
2. Потім у таблицю записуються тільки ті дані, які цій схемі відповідають.
3. Зміна схеми потребує міграції вже наявних даних.

Цей підхід добре працює, коли:

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

Але інтернет усе змінив.

Вибух даних і народження data lakes: schema-on-read

Зі зростанням інтернету та цифрових сервісів почали масово накопичуватися:

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

Ці дані:

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

HDFS та об’єктне сховище

Відповіддю став Hadoop Distributed File System (HDFS) — спосіб зберігати файли без необхідності вписувати їх у реляційну структуру. SQL-можливості додавалися окремими інструментами (наприклад, Hive).

На цій основі виросло об’єктне сховище:

• Amazon S3, Google Cloud Storage та подібні сервіси;
• зберігання будь-яких типів файлів (CSV, JSON, відео, зображення, документи);
• дуже низька вартість за гігабайт (у рази дешевше за традиційне сховище);
• практично необмежена масштабованість;
• паралельний доступ багатьох команд без деградації продуктивності.

Але просто зберігати — недостатньо. Дані потрібно аналізувати. Так з’явилися data lakes.

Data lake: вода з усіх джерел в одному озері

Метафора озера тут показова:

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

Так само data lake:

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

Це і є перехід до schema-on-read:

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

Переваги такого підходу:

• можна зберігати будь-які формати (JSON, CSV, Parquet, відео, зображення);
• різні команди можуть по-різному інтерпретувати одні й ті самі файли;
• складне моделювання можна відкласти до моменту, коли вимоги стануть зрозумілішими;
• data scientists та аналітики отримують доступ до сирих даних без зміни джерел.

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

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

Для data lake це не проблема — структура не нав’язується при записі.

Коли озеро перетворюється на болото

Успіх data lakes породив нові труднощі:

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

У результаті data lake часто перетворюється на data swamp — «болото», де знайти надійні, узгоджені дані стає майже неможливо.

Data lakehouse: метадані як міст між гнучкістю та порядком

Наступний крок — спроба поєднати:

• дешеве, гнучке об’єктне сховище data lake;
• продуктивність, керованість і транзакційність data warehouse.

Так з’явилася концепція data lakehouse.

Метадані як «розумний каталог»

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

• Apache Iceberg;
• Delta Lake.

Метадані зберігають:

1. Схеми даних
2. опис структури файлів;
3. історію змін схем;

4. можливість еволюції схеми без поломки запитів.

5. Статистику файлів

6. кількість рядків;
7. діапазони значень;

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

9. Транзакційні журнали

10. підтримка ACID-транзакцій;

11. можливість time travel — запитів до стану даних у минулому.

12. Управління дрібними файлами

13. відстеження великої кількості малих файлів;
14. автоматичне об’єднання (compaction) у більші, ефективніші блоки.

Усе це перетворює об’єктне сховище на платформу, яка поєднує:

• продуктивність і надійність data warehouse;
• гнучкість і форматну різноманітність data lake.

Що робити з «незручними» неструктурованими даними

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

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

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

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

Наступний крок: TableFlow і реальний час у єдиній аналітичній площині

Попри всі переваги lakehouse, залишалася одна суттєва прогалина: реальний час.

Потоки подій у Apache Kafka та подібних платформах:

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

Це створювало розрив між:

• streaming-даними (Kafka);
• аналітичними даними (lakehouse).

TableFlow: автоматичні таблиці з Kafka-топіків

Новий підхід — TableFlow — намагається закрити цю прогалину:

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

Результат:

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

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

Логіка еволюції: кожне покоління закриває слабкі місця попереднього

Якщо подивитися на розвиток технологій з висоти:

• Data warehouse зробили аналітику по операційних даних доступною та продуктивною.
• Data lakes додали гнучкість і підтримку різноманітних форматів, але втратили структуру й керованість.
• Lakehouse повернули продуктивність, транзакційність і керованість, зберігши гнучкість lakes.
• TableFlow знімає напругу між потоковими даними та аналітикою, інтегруючи реальний час у lakehouse.

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

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

Назви теж виявляються не випадковими:

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

Джерело

The Evolution of Data Storage (And What’s Next) | Modern Data Engineering Pipelines — Confluent Developer

У Google DeepMind активно перебудовують спосіб, у який розробники взаємодіють з моделями Gemini. На сесії AI Engineer Thor Schaeff та Philipp Schmid показують новий Interactions API — поверхню, яка має замінити generateContent і зробити створення агентів та мультимодальних асистентів значно простішим. У центрі цієї трансформації — уніфікована модель контенту, вбудовані інструменти, підтримка стримінгу та системні інструкції, що визначають поведінку агентів.

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

Єдиний формат контенту: від тексту до function_call в одному полі type

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

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

Така уніфікація вирішує одразу кілька проблем, які накопичилися в попередніх поколіннях API. Старіші інтерфейси Gemini були помітно «гуглівськими»: сильно зав’язаними на protobuf, gRPC і власні специфічні структури. Interactions API навпаки намагається виглядати максимально знайомим для веб-розробників, які вже працювали з OpenAI chat completions чи API Anthropic. Єдині контент-блоки з полем type — це крок у бік більш стандартної, передбачуваної моделі.

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

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

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

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

Це означає, що розробник може будувати агента, який, наприклад, приймає відеоінструкцію, витягує з неї релевантні кадри, аналізує аудіодоріжку, а потім повертає текстове пояснення, згенероване зображення або навіть відеофрагмент. З погляду API це все — різні контент-блоки з відповідними type: audio, video, image, text.

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

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

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

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

Ще один ключовий елемент Interactions API — підтримка стримінгу відповідей через Server-Sent Events (SSE). Для веб-розробників це знайомий патерн: замість чекати на повну відповідь, клієнт отримує потік подій, які надходять поступово.

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

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

Для розробників, які звикли до WebSockets, SSE пропонує простіший варіант для одностороннього стримінгу від сервера до клієнта. У випадку Interactions API це логічний вибір: більшість сценаріїв передбачає, що клієнт надсилає запит і потім лише слухає відповідь. SSE знімає частину інфраструктурних складнощів, пов’язаних із двосторонніми з’єднаннями, але при цьому дає змогу реалізувати майже ті самі UX-патерни.

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

Інструменти в одному виклику: Google Search, кастомні функції та віддалені MCP

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

Серед вбудованих інструментів особливо виділяється Google Search. Модель може напряму викликати пошук, отримувати актуальну інформацію з вебу й використовувати її в своїх відповідях. Раніше розробникам доводилося або покладатися на вбудовані агенти, або будувати власні обгортки навколо API пошуку. Тепер це інтегровано в сам Interactions API.

Паралельно API дозволяє визначати власні інструменти — як локальні функції, так і віддалені MCP-тулзи. MCP (Model Context Protocol) дає змогу підключати зовнішні сервіси як інструменти моделі, не вбудовуючи їх жорстко в код агента. Це особливо корисно для корпоративних сценаріїв, де потрібно інтегрувати внутрішні API, бази знань або бізнес-логіку.

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

Технічно Interactions API представляє виклики інструментів як структуровані типи в результаті interaction. Коли модель вирішує скористатися інструментом, у вихідних блоках з’являється function_call із параметрами. Клієнтський код виконує відповідну функцію (локальну чи віддалену), отримує результат і повертає його назад у модель як function_result. Цей цикл може повторюватися доти, доки модель не завершить використання інструментів.

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

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

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

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

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

На рівні коду це поєднується з клієнтом GenAI і класом Agent, який зберігає глобальний previousInteractionId для багатокрокових діалогів. Кожен новий запит до агента надсилається разом із цим ідентифікатором, щоб серверна сторона могла відновити контекст. У відповідях модель може повертати function_call для читання файлу, запису чи виконання bash-команди. Клієнтський цикл перевіряє вихідні блоки, виконує відповідні локальні функції, додає результати назад у interaction і повторює процес, доки модель не припинить викликати інструменти.

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

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

Висновок: Interactions API як основа для наступного покоління агентів

Новий Interactions API у виконанні Google DeepMind — це не просто ще один ендпоінт для генерації тексту. Це спроба побудувати єдину, послідовну поверхню для моделей і агентів, яка враховує реальні потреби розробників: мультимодальність, інструменти, стримінг, керування станом і поведінкою.

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

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

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

Джерело

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

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

Що таке Q‑Day і які алгоритми під загрозою

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

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

• Симетричні шифри
  Один ключ використовується і для шифрування, і для розшифрування. Найпоширеніший стандарт — AES (Advanced Encryption Standard). Його застосовують для «масового» шифрування великих обсягів даних, оскільки він працює відносно швидко.
• Асиметричні шифри
  Використовують пару математично пов’язаних ключів: один шифрує, інший розшифровує. Класичний приклад — RSA. Такі алгоритми повільніші, але вирішують критичні задачі:
• розподіл ключів;
• побудова інфраструктури відкритих ключів (PKI);
• робота цифрових сертифікатів.

Квантові алгоритми по‑різному впливають на ці дві групи:

• Grover’s algorithm прискорює перебір ключів симетричних шифрів. Для AES‑128 це означає, що ефективна стійкість знижується, тож рекомендація — подвоїти довжину ключа до 256 біт. Стандарт AES це дозволяє, і криптографічна спільнота вважає такий перехід достатнім захистом від квантових атак.
• Shor’s algorithm фактично «обнуляє» безпеку асиметричних алгоритмів на кшталт RSA. Тут просте збільшення розміру ключа не рятує — потрібні зовсім нові схеми, так звана постквантова криптографія (post‑quantum cryptography, quantum‑safe cryptography).

Отже, підготовка до Q‑Day включає два ключові кроки:
1. Перехід на AES‑256 для симетричного шифрування.
2. Повну заміну нинішніх асиметричних алгоритмів на постквантові.

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

Якщо квантові комп’ютери зламають чинні криптосистеми, наслідки вийдуть далеко за межі «теоретичної вразливості».

Кінець конфіденційності

Під загрозою опиняються:

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

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

Злам автентифікації

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

• стане важко відрізнити легітимного користувача від зловмисника;
• зросте ризик масштабних атак із підміною особи (identity theft, impersonation).

Підрив цифрових підписів і цілісності даних

Цифрові підписи та механізми перевірки цілісності документів дозволяють:

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

Якщо криптографічні основи цих механізмів будуть зламані, зникне впевненість у тому, що:

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

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

Коли настане Q‑Day — і чому чекати небезпечно

Точну дату ніхто не знає. Оцінки, які зараз циркулюють у галузі, — приблизно 5–10 років від моменту запису відео. Регулятори та уряди орієнтуються на період 2030–2035 років як на часовий горизонт, коли старі криптостандарти мають бути виведені з обігу.

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

1. Час на міграцію: «злітна смуга» занадто коротка

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

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

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

Інакше кажучи, «злітної смуги» може просто не вистачити.

2. Вартість запізнення

Чим ближче до Q‑Day, тим дорожче буде перехід:

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

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

3. Несподіваний прорив у дослідженнях

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

• наявних квантових комп’ютерів,
• класичних суперкомп’ютерів,
• та алгоритмів на кшталт Grover і Shor

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

У такому випадку часовий горизонт «5–10 років» миттєво перетвориться на «вже запізно».

4. «Harvest Now, Decrypt Later»: атака з майбутнього

Найбільш концептуально тривожний сценарій — Harvest Now, Decrypt Later («збирай зараз, розшифровуй потім»):

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

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

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

Як готуватися: перехід до постквантової криптографії

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

Ключові напрямки підготовки:

• Інвентаризація криптографії
  Виявити всі місця, де використовуються:
• симетричні алгоритми (наприклад, AES‑128);
• асиметричні алгоритми (RSA та інші);
• цифрові сертифікати, PKI, протоколи шифрування.
• План міграції на AES‑256
  Для симетричного шифрування — перехід на 256‑бітні ключі там, де це ще не зроблено.
• Оцінка готовності до постквантових алгоритмів
  Вивчення стандартів постквантової криптографії, які проходять або вже пройшли відбір у профільних організаціях, та планування їхнього впровадження в інфраструктуру.
• Стратегія поетапного переходу
  З урахуванням тривалості процесу, варто закладати:
• поетапну заміну алгоритмів;
• тестування сумісності;
• оновлення політик безпеки та процедур.

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

Джерело

Q‑Day Explained: How Quantum Computing Threatens Today’s Cryptography — IBM Technology

Claude Code, новий агентний інструмент для розробки від Anthropic, обіцяє повний цикл створення софту з однієї текстової інструкції. У відеогайді Futurepedia автор демонструє це на прикладі шести проєктів, зокрема 3D‑гри в браузері. Але найцікавіше тут не стільки самі результати, скільки те, як саме Claude Code планує, будує, тестує й поступово вдосконалює продукт разом із користувачем.

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

План замість хаосу: як працює Plan Mode

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

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

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

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

Користувач може перечитати план, відредагувати окремі пункти, додати нотатки або вказати, що саме потрібно змінити. Claude Code вміє переробляти план до тих пір, поки він не відповідатиме очікуванням. Лише після натискання «Accept and allow edits» система переходить до реального будівництва проєкту.

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

Час як ресурс: скільки триває планування й збірка

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

Планування в Plan Mode зазвичай займає кілька хвилин. За цей час інструмент:

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

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

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

У демонстрації з грою Claude Code протягом цього часу:

створює й редагує файли;
оновлює внутрішній список завдань;
використовує різні «інструменти» (команди й утиліти);
запускає попередній перегляд;
виконує тестові дії в інтерфейсі.

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

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

Автоматичне тестування: коли агент сам грає у власну гру

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

На прикладі 3D‑гри цей процес добре видно в логах дій. Після створення основних файлів Claude Code:

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

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

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

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

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

Ітерації без перезапуску: як змінювати продукт крок за кроком

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

Для більшості змін немає потреби щоразу повертатися в Plan Mode. Достатньо залишатися в режимі «accept edits» і давати інструменту короткі, чіткі запити. Наприклад:

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

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

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

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

Claude Code не лише реалізував логіку, а й додав у інтерфейс перемикач, що дозволяє вмикати й вимикати режим гри проти AI. Знову ж таки, без повернення до Plan Mode і без повного «перебудування» проєкту з нуля.

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

Чому «одна зміна за раз» — не просто порада, а стратегія

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

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

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

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

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

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

Після цього йдуть ще кілька кроків:

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

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

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

AI‑суперник і рівні складності: демонстрація ітеративної потужності

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

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

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

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

Черговими короткими запитами користувач попросив додати три рівні складності й потім окремо пом’якшити «medium», який виявився надто жорстким. Claude Code вніс зміни в логіку прийняття рішень AI, зберігши при цьому загальну структуру гри.

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

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

Висновок: план, збірка, тест, ітерація — новий базовий цикл розробки

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

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

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

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

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

Джерело

The Ultimate Non-Technical Guide to Claude Code — Futurepedia

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

Від «людини, що пише код», до «наглядача за агентами»

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

• У великих компаніях уже сьогодні 70–90% коду може бути повністю згенеровано ШІ.
• Людина, яка не використовує AI‑інструменти, стає відчутно менш продуктивною порівняно з тими, хто інтегрував їх у робочий процес.

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

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

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

Новий фронт: Agent Experience замість класичного UX

Ще одна тенденція — поява дисципліни Agent Experience (AX). Якщо UX (user experience) фокусується на взаємодії людини з інтерфейсом, то AX — на тому, як із продуктом працюють AI‑агенти.

Усе частіше користувач:

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

Це змушує команди переосмислювати дизайн систем:

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

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

Витік інженерного таланту та «LLM‑шлак» у продакшені

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

Кілька факторів накладаються один на одного:

• Скорочення можливостей для джунів.
  З моменту запуску ChatGPT зайнятість розробників 22–25 років впала майже на 20%, а кількість вакансій початкового рівня — на 46–67% (залежно від джерела підрахунку). Компанії дедалі рідше інвестують у навчання молодих спеціалістів, віддаючи перевагу сеньйорам і AI‑інструментам.

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

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

Моделі великих мов (LLM) добре передбачають текст на основі того, що вже існує. Вони:

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

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

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

Код більше не вузьке місце: що стало справді дефіцитним

Ще одна фундаментальна зміна — зсув «вузького місця» у розробці.

Раніше:

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

Тепер:

• код став дешевим — AI може за хвилини згенерувати те, на що раніше йшли тижні;
• але все, що навколо коду, залишилось дорогим і складним.

Справжніми дефіцитними навичками стають:

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

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

• Технічний judgment.
  Уміння робити компроміси між швидкістю, якістю, безпекою, вартістю інфраструктури й бізнес‑цілями.

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

Через це:

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

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

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

Невизначене майбутнє та вимога до адаптивності

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

З одного боку:

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

З іншого:

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

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

Джерело

The State of Software Engineering in 2026 — Tech With Tim

У межах воркшопу на каналі AI Engineer інженери Google DeepMind Тор Шефф і Філіп Шмід показують, як будувати розмовні агенти на базі Gemini. Центральним елементом стає новий Interactions API, який поєднує моделі, вбудовані агенти та мультимодальні контент-блоки в єдину систему. На цій основі вони демонструють, як безкоштовна модель Gemini 1.5 Flash Free, агент Deep Research і генеративні моделі на кшталт Nano Banana можуть працювати в одному кодовому шляху, виконуючи складні, довгі й багатокрокові завдання.

Gemini 1.5 Flash Free як робоча конячка для коду й планування

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

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

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

Модель, яка не знала про Interactions API: роль навичок і документації

Цікавий нюанс полягає в тому, що Gemini 1.5 Flash Free тренували ще до появи Interactions API. Це означає, що модель не «знає» про цей API з навчальних даних і не має вбудованого досвіду роботи з ним. Її здатність коректно викликати інструменти, працювати як агент і використовувати нові можливості API спирається не на попереднє навчання, а на те, як розробник описує навички, інструкції й структуру взаємодії.

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

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

як виглядає інтерфейс інструментів і агентів;

які кроки потрібно виконати в межах одного завдання;

які обмеження й очікування щодо відповіді.

У результаті Flash Free перетворюється на універсальний «двигун міркування», а вся «агентність» — це наслідок того, як її вбудовують у Interactions API. Такий підхід добре узгоджується з трендом на «skills» і «tools» як окремі сутності, які можна оновлювати й комбінувати без ретренінгу моделі.

Єдиний кодовий шлях для моделей і агентів

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

У найпростішому випадку це означає заміну ідентифікатора: замість model: “gemini-1.5-flash-free” можна вказати agent: “deep-research” або інший агентний ID. Решта структури запиту — контент-блоки, параметри, інструкції — залишається тією самою. Для розробника це означає, що один і той самий кодовий шлях може:

спочатку викликати модель для швидкого планування чи кодування;

потім передати результат у вбудованого агента для довготривалого дослідження;

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

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

Deep Research як вбудований агент для довгих завдань

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

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

користувацький інтерфейс більше не прив’язаний до однієї HTTP-сесії;

дослідження можна запускати «в один клік» і повертатися до них пізніше;

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

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

Асинхронність, опитування й вебхуки: як працюють довгі агенти

Щоб такі агенти, як Deep Research, були практично корисними, Interactions API вводить повноцінну асинхронну модель виконання. Замість того, щоб тримати HTTP-з’єднання відкритим хвилинами, розробник:

ініціює інтеракцію з агентом;

отримує ідентифікатор завдання чи інтеракції;

далі або періодично опитує API, або (коли це стане доступним) отримує сповіщення через вебхуки.

У воркшопі окремо наголошують: тримати HTTP-запит відкритим довше 10 секунд — погана практика для веб-додатків. Тому Interactions API спроєктовано так, щоб довгі завдання природно переходили в асинхронний режим. Це дозволяє:

масштабувати бекенд без блокувальних запитів;

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

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

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

Мультимодальні контент-блоки як клей між моделями й агентами

Ще одна фундаментальна ідея Interactions API — уніфікований формат контент-блоків. Кожен вхід і вихід описується як блок із полем type, яке може позначати текст, аудіо, відео, зображення, function_call або thought_signature. Це означає, що:

одна й та сама структура використовується для звичайних текстових діалогів;

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

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

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

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

Ланцюжок Deep Research → Nano Banana: приклад складного воркфлоу

На базі цих принципів у воркшопі демонструють показовий сценарій: як за допомогою Interactions API зв’язати між собою Deep Research і модель Nano Banana для генерації зображень.

Схема виглядає так:

спочатку розробник ініціює інтеракцію з агентом Deep Research, формулюючи запит, який потребує глибокого аналізу;

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

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

Nano Banana на основі текстового опису, сформованого Deep Research, створює зображення.

Важливий момент: увесь цей ланцюжок реалізовано через один і той самий Interactions API. Розробник не перемикається між різними SDK чи протоколами, а просто змінює ціль: спочатку agentId для Deep Research, потім modelId для Nano Banana. Контент між ними передається в тому самому форматі блоків.

Такий підхід відкриває шлях до ще складніших сценаріїв. Наприклад, можна уявити:

агент, який досліджує ринок, формує текстовий звіт;

модель, яка перетворює цей звіт на серію інфографік;

інший агент, який генерує аудіо- або відео-огляд на основі тих самих даних.

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

Швидкість і економність як дизайн-принципи

Якщо подивитися на всі ці елементи разом — Gemini 1.5 Flash Free, Deep Research, мультимодальні блоки, асинхронні агенти — стає помітно, що Google DeepMind намагається зрушити фокус із «максимальної потужності моделі» на «ефективність у реальних воркфлоу».

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

У підсумку розробник отримує можливість:

будувати агентів, які швидко реагують на користувача, використовуючи Flash Free;

делегувати важкі дослідження Deep Research, не блокуючи інтерфейс;

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

керувати всім цим через один API, який підтримує як синхронні, так і асинхронні сценарії.

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

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

Поява Interactions API, використання Gemini 1.5 Flash Free як базового «двигуна» й інтеграція Deep Research як вбудованого агента показують, куди рухається екосистема Gemini. Замість того, щоб зосереджуватися на окремих моделях, Google DeepMind вибудовує платформу, де моделі, агенти й мультимодальні формати працюють разом у єдиному кодовому шляху.

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

Джерело

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

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

Менше технічного боргу, більше швидкості

У Virgin Atlantic Codex став ключовим елементом під час перенесення баз даних до основного дата-складу. Інструмент допомагає:

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

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

Мобільний застосунок із «винятковою» якістю тестів

Одним із практичних результатів використання Codex став запуск нового мобільного застосунку Virgin Atlantic у бета-версії. Якість продукту напряму пов’язують із рівнем тестового покриття, якого вдалося досягти завдяки Codex.

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

Радикальне скорочення коду

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

• скорочення обсягу коду на 78–80% завдяки використанню Codex.

Менший код — це не лише про елегантність. Це:

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

Від інструмента для інженерів до платформи «для всіх»

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

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

Джерело

Відео OpenAI: What Codex Unlocks for Virgin Atlantic

У подкасті 20VC інвестори Джейсон Лемкін (SaaStr, один із найвідоміших SaaS‑інвесторів останнього десятиліття) та Рорі О’Дрісколл (Scale Venture Partners, ранній інвестор у Bill.com, Box, DocuSign) обговорюють, як штучний інтелект і зміна настроїв публічних ринків перелаштовують оцінку програмних компаній. Від ServiceNow і Workday до Canva, Rippling і драматичної історії Medallia — формується нова епоха, де «магічні» мультиплікатори SaaS більше не працюють, а інвестори дедалі жорсткіше дивляться на реальні грошові потоки, AI‑агентів і ризики боргу.

Як AI‑агенти змінюють те, за що платять публічні ринки

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

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

Фактично формується новий KPI: не просто ARR чи NRR, а «AI agent‑driven revenue» — частка доходу, де джерелом створення цінності є не користувач, який клацає по інтерфейсу, а агент, що самостійно працює поверх платформи. Для таких компаній ринок готовий платити премію, бо:

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

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

Смерть «SaaS‑пилу феї»: чому премія за історію зникла у 2025‑му

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

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

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

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

• працює за моделлю підписки;
• має хмарну архітектуру;
• декларує «AI‑стратегію» без чіткої монетизації.

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

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

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

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

Canva, Rippling та інші: як виглядатимуть «реальні» IPO та оцінки

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

Це означає, що навіть за сильних фінансових показників Canva навряд чи отримає ті мультиплікатори, які ще кілька років тому здавалися нормою для швидкозростаючих SaaS‑компаній. Інвестори дивитимуться на:

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

Подібна логіка поширюється й на інші швидкозростаючі компанії. Джейсон Лемкін наводить приклад Rippling — HR‑ і payroll‑платформи, яка, за його словами, зростає приблизно на 70% при виручці близько $1 млрд. У попередню епоху такий профіль зростання майже автоматично означав би двозначний мультиплікатор до виручки.

Сьогодні очікування інші. Лемкін припускає, що Rippling, виходячи на публічний ринок, швидше за все торгуватиметься за «зрозумілими» скоригованими P/E‑мультиплікаторами, а не за роздутими SaaS‑мультиплами до revenue. Інвестори будуть готові платити за:

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

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

Довгі контракти Workday та ілюзія захищеності в епоху агентів

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

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

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

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

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

Для інвесторів це означає, що:

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

Medallia і тріщина в моделі private equity: коли борг більше не рятує

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

Thoma Bravo, один із найактивніших гравців на ринку технологічного private equity, у підсумку передав компанію кредиторам, фактично «віддавши ключі» й списавши близько $5,1 млрд акціонерної вартості. Це не історія про класичне «over‑leverage», коли бізнес задушили надмірним борговим навантаженням. Як підкреслюється в розмові, Thoma Bravo не «перезавантажили» Medallia боргом — вони просто заплатили за неї занадто дорого.

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

Проблема в тому, що:

• Medallia залишалася «pre‑AI‑історією», яка мала трансформуватися в AI‑компанію, але не встигла або не змогла зробити це достатньо переконливо;
• зростання було низьким, а отже, важко було обґрунтувати як високу оцінку, так і обслуговування понад $2 млрд боргу;
• ринок більше не був готовий платити премію за «SaaS‑лейбл» без чіткої AI‑агентної траєкторії.

У результаті виявилося неможливим обслуговувати борг на компанії з мільярдною виручкою, низьким зростанням і невизначеною AI‑перспективою. Thoma Bravo фактично визнали, що equity знецінилося до нуля, і передали актив кредиторам.

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

Для венчурних фондів це має подвійний ефект:

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

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

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

Сукупність цих сигналів — фокус аналітиків на AI‑агентній виручці ServiceNow, очікування «реального» ціноутворення для Canva й Rippling, переоцінка довгих контрактів Workday, крах Medallia в руках Thoma Bravo — вказує на структурну зміну ринку.

Новий порядок денний виглядає так:

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

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

Джерело

Anthropic Raises $45B but Falls Short on Compute & Thoma Bravo Hand Back Medallia Keys to Creditors — 20VC

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

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

Локальний агент: чому важливо, що Claude Code працює прямо на вашому комп’ютері

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

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

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

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

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

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

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

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

Папка як проєкт: як Claude Code організовує робочий простір

Ще одна фундаментальна особливість Claude Code — жорстка прив’язка кожного проєкту до конкретної локальної папки. Це не просто технічна деталь, а основа всієї моделі роботи.

Коли користувач переходить на вкладку Code у десктопному застосунку, перший крок перед будь‑яким запитом — вибрати або створити папку для проєкту. У прикладі з грою автор спочатку створює загальну директорію «Claude Code projects», а потім для кожного нового застосунку — окрему підпапку. Для гри це «Cube Tac Toe». Саме в цій папці Claude Code:

створює всі вихідні файли,
зберігає ресурси,
оновлює логіку,
запускає локальний прев’ю.

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

Прив’язка до папки вирішує одразу кілька задач.

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

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

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

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

Таким чином, папка стає не просто місцем зберігання, а «контейнером» проєкту, в якому агент працює як повноцінний учасник розробки.

Десктопний застосунок: три вкладки, одна з яких перетворює ШІ на розробника

Головний спосіб взаємодії з Claude Code для більшості користувачів — десктопний застосунок Claude. Його можна завантажити як звичайну програму, і всередині він пропонує три основні вкладки зліва: Chat, Co‑work і Code.

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

Вкладка Co‑work — окремий режим спільної роботи з Claude, для якого автор гайду навіть зробив окреме відео. У цьому матеріалі вона згадується лише побіжно, як ще один спосіб взаємодії з моделлю.

Головний герой — вкладка Code. Саме тут Claude Code розкривається як агентний інструмент для розробки. Інтерфейс побудований навколо кількох ключових елементів.

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

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

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

Після прийняття плану Claude Code починає будувати проєкт: оновлює список задач, створює файли, викликає інструменти, тестує функціональність. У правій частині інтерфейсу доступні панелі з різними режимами перегляду. Одна з них — прев’ю, де можна відразу завантажити й протестувати застосунок, не виходячи з програми. У випадку з грою це інтерактивне 3D‑поле, де можна ставити хрестики‑нулики, обертати куб, перевіряти логіку перемоги.

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

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

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

Термінал і IDE: альтернативні інтерфейси для тих, хто хоче більше контролю

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

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

Інший варіант — інтеграція з IDE (integrated development environment). Це середовище, яке на перший погляд може виглядати лякаюче для новачків, але має важливу перевагу: у міру того, як Claude Code створює файли, вони з’являються в бічній панелі IDE в реальному часі. Користувач бачить повну структуру проєкту, може відкривати будь‑який файл, переглядати й редагувати код вручну, комбінуючи роботу агента з власними правками.

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

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

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

Як середовище впливає на досвід: від «магії з однієї підказки» до керованої розробки

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

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

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

В IDE користувач отримує повну видимість структури проєкту й коду. Кожен файл, створений Claude Code, можна відкрити, прочитати, змінити вручну. Агент стає радше «співавтором», ніж «автономним будівельником».

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

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

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

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

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

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

Джерело

The Ultimate Non-Technical Guide to Claude Code — Futurepedia

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

Сьогодні ця екосистема вже виходить за рамки поодиноких стартапів. Lobby X запускає «Країну інженерів» у семи містах, «Українська бронетехніка» показує FPV з автоматичним донаведенням на базі 82‑мм міни, а Numo Robotics оновлює свій флагманський наземний роботизований комплекс, спираючись на зворотний зв’язок із передової. Разом це демонструє, як швидко в Україні вибудовується повний цикл — від ідеї до прототипу й бойового застосування.

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

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

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

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

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

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

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

FPV на базі 82‑мм міни: друге життя боєприпасів і автоматичне донаведення

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

Це рішення поєднує одразу кілька важливих трендів українського miltech.

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

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

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

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

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

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

Numo Robotics: як фронтовий фідбек змінює наземні роботизовані комплекси

Якщо дрони вже стали символом цієї війни, то наземні роботизовані комплекси (НРК) лише починають виходити з тіні. Українська компанія Numo Robotics — один із тих гравців, хто системно розвиває цей напрямок. З квітня вона оновила базову конфігурацію свого флагманського НРК Numo, і це показовий кейс того, як фронт формує технічні рішення.

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

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

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

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

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

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

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

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

Якщо подивитися на «Країну інженерів», FPV‑дрон UB60D і НРК Numo не як на окремі історії, а як на елементи однієї картини, стає помітним формування повноцінної miltech‑екосистеми.

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

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

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

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

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

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

Висновок: війна як каталізатор технологічної зрілості

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

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

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

Джерело

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

Авіакомпанія 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