Podman часто сприймають як «ще одну альтернативу Docker», але екосистема навколо нього давно вийшла за межі просто контейнерного рушія. У свіжому відео на каналі IBM Technology показано, як сучасний Podman допомагає розробникам і DevOps-командам — від локальної розробки й Kubernetes до AI-функцій та «завантажуваних» контейнерів, що перетворюються на повноцінні образи ОС.

Podman Desktop: єдиний інтерфейс для контейнерів і локального Kubernetes

Типовий робочий день інженера, який працює з контейнерами, — це постійне перемикання між інструментами: контейнерний рушій, kubectl, minikube або Kind, SSH для дебагу, реєстри образів, YAML‑маніфести тощо. Podman Desktop намагається зібрати все це в одному місці.

Podman Desktop — це кросплатформений, відкритий GUI, який:

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

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

Інтеграція з Systemd: контейнери як системні сервіси

Одна з найпотужніших можливостей Podman — запуск контейнерів як системних сервісів через Systemd. Це особливо корисно для довготривалих сервісів у продакшені або домашніх лабораторіях.

Команда:

podman generate systemd <ім’я-контейнера-або-pod’а>

створює декларативний unit‑файл Systemd, який:

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

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

Автоматична генерація Kubernetes‑маніфестів

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

Команда:

podman kube generate <ім’я-контейнера-або-pod’а>

створює YAML‑маніфести Kubernetes, серед яких можуть бути:

• Deployment для застосунку;
• Pod‑ресурси;
• Volume‑описання;
• Service для мережевої доступності.

Отримані файли можна застосувати через:

kubectl apply -f <файл>.yaml

або через Podman Desktop. Таким чином, розробник:

1. Локально запускає й налагоджує контейнер.
2. Генерує Kubernetes‑маніфест.
3. Деплоїть його в кластер без ручного написання YAML «з нуля».

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

Podman AI Lab: локальні AI‑моделі як API

Все більше команд отримують завдання «додати AI» — від RAG‑сценаріїв до агентних систем. Питання в тому, як інтегрувати моделі в застосунок без залежності від зовнішніх сервісів.

Podman AI Lab — це розширення для Podman Desktop, яке дозволяє:

• запускати AI‑моделі в контейнерах як inference‑сервер;
• піднімати локальний AI‑API на базі Llama.cpp з моделями під ліцензією Apache 2.0;
• звертатися до моделей через звичайні REST‑запити або інтегрувати їх через LangChain.

У результаті:

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

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

Завантажувані контейнери: один файл — і застосунок, і операційна система

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

Ідея така:

1. Є звичайний containerfile, який описує застосунок і залежності.
2. Як базовий образ використовується варіант, що містить:
3. ядро Linux;
4. драйвери;
5. необхідні системні компоненти.
6. На основі цього будується образ, який можна розгорнути як:
7. хмарний образ (наприклад, AMI);
8. образ для віртуальної машини (QCOW2, RAW тощо);
9. образ для IoT‑пристроїв.

Тобто один і той самий опис (containerfile) стає джерелом не лише для контейнера, а й для повноцінної ОС із вбудованим застосунком.

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

Висновок

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

• Podman Desktop спрощує щоденну роботу з контейнерами та Kubernetes.
• Інтеграція з Systemd робить контейнери повноцінними системними сервісами.
• Генерація Kubernetes‑маніфестів зменшує бар’єр входу в оркестрацію.
• Podman AI Lab дозволяє будувати AI‑функції локально, без зовнішніх залежностей.
• Завантажувані контейнери наближають модель, де один опис визначає і застосунок, і операційну систему.

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

Джерело

YouTube: 5 Podman Features You Should Know: Kubernetes & Containers Simplified

На каналі AI Engineer розробник і серійний «хакер продуктивності» K (відомий як Kitze, @thekitze в X), якому в день виступу виповнилося 34, розповів, як від ейфорії навколо ChatGPT-плагінів він прийшов до радикально іншої моделі цифрового життя: самохостингових агентів, що працюють поверх власних даних. Його шлях — це не просто історія одного ентузіаста, а показовий зсув від «універсального чату» до інфраструктури, де головне не застосунки, а дані й агенти, які ними оперують.

Коли здавалося, що «все буде чат»: короткий тріумф універсального інтерфейсу

Пік хайпу навколо ChatGPT-плагінів став моментом, коли багатьом у галузі здалося, що традиційним SaaS-застосункам залишилися лічені роки. Kitze не був винятком. Коли OpenAI запустила плагіни, він буквально подзвонив дружині з фразою: «Все, кінець усім застосункам, кінець усьому SaaS. GPT з’їсть світ. Усе буде всередині чату. Benji безглуздий. Я змарнував роки».

Benji — його власний гігантський «life OS», над яким він працює вже 3–4 роки, намагаючись зібрати в одному місці десятки функцій: від рутини й календаря до харчування. На тлі плагінів ChatGPT ця багаторічна робота раптом виглядала зайвою. Якщо будь-який сервіс можна «підвісити» до одного універсального чат-інтерфейсу, навіщо взагалі окремі застосунки?

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

Claude Code як «не той шел»: чому термінал не став життєвим асистентом

Після хвилі захоплення ChatGPT-плагінами Kitze спробував інший підхід: замість того, щоб чекати ідеального універсального чату, він почав будувати власного агента поверх Claude Code. Модель від Anthropic тоді вже підтримувала tool calls і функції, тож здавалося логічним використати її як «мозок» для особистого асистента.

Він почав завантажувати в Claude Code так звані «personal skills» — навички й процедури, які мали б покривати реальні життєві задачі: податки, розбір пошти, керування to‑do, інші рутинні процеси. Ідея була проста: замість того, щоб вручну крутити десятки застосунків, делегувати це агенту, який знає його контекст і має інструменти для дій.

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

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

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

Cloudbot і месенджери як справжній інтерфейс до агента

Поворотним моментом став Cloudbot, який створив розробник на ім’я Peter. На відміну від Claude Code, Cloudbot одразу пропонував те, чого бракувало: природний інтерфейс у вигляді звичних месенджерів. Можливість спілкуватися з агентом через WhatsApp або Telegram стала для Kitze тим самим «клацанням», якого не вистачало, щоб його уявлення про персонального агента стало практичним.

Він став одним із ранніх користувачів Cloudbot і приєднався до Discord-спільноти, коли там було менше сотні людей із налаштованими інстансами. Навіть сам Peter дивувався, як йому вдалося все підняти без нормального онбордингу. Відповідь була показовою: Kitze не заглиблювався в JSON-конфіги, а просто просив своїх ботів — Claude Code чи Codex — змінити налаштування, покращити пам’ять, щось полагодити. Він фактично використовував ШІ, щоб налаштовувати інфраструктуру для ШІ.

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

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

Лобстер, OpenClaw і єдиний асистент для всього життя

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

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

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

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

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

Відмови від хмарних UI: чому самохостинговий асистент виявився переконливішим

Після того як OpenClaw запрацював як єдиний асистент поверх його даних, Kitze фактично перестав користуватися веб-інтерфейсами великих моделей. Він описує це як «повний хіпстер-режим»: жодного Gemini, жодного ChatGPT, жодного «хмарного Claude» у їхніх стандартних UI.

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

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

Дані понад застосунки: міграція з комерційних хмар у світ Nextcloud і Markdown

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

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

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

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

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

Від клубу тінкерів до нового типу користувача

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

Джерело

The End of Apps — Kitze, Sizzy.co (YouTube)

Anthropic сьогодні — один із найагресивніших гравців на ринку генеративного AI. Компанія, відома моделлю Claude, за останній рік перетворилася на еталон швидкості розробки: багато фіч виходять не за пів року, а за тиждень чи навіть день. У центрі цієї динаміки — Cat Wu, Head of Product для Claude Code та Cowork, яка відповідає за шлях від ідеї до релізу й за те, щоб маркетинг, продажі, фінанси та інфраструктура встигали за темпом інженерів.

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

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

Людська помилка, а не збій AI: що насправді сталося з витоком Claude Code

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

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

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

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

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

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

Як Anthropic «загартувала» процеси після інциденту — і не загальмувала релізи

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

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

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

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

Щоб така модель не перетворилася на хаос, Anthropic тримає кілька опорних структур:

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

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

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

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

Межі платформи: чому Anthropic обмежує сторонні продукти на кшталт OpenClaw

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

Одним із таких прикладів став OpenClaw — інструмент для побудови персональних AI‑агентів. Anthropic ухвалила рішення обмежити використання підписок Claude у подібних сторонніх продуктах. Мотивація була не в тому, щоб «закрити екосистему» як таку, а в тому, щоб чітко розставити пріоритети:

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

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

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

Інфраструктура як продуктове обмеження: масштабування, токени й ефективність

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

Попит на Claude зростає настільки швидко, що компанія змушена паралельно вирішувати дві задачі:

перша — масштабувати інфраструктуру, щоб обслуговувати дедалі більшу кількість запитів;
друга — підвищувати токен‑ефективність, тобто зменшувати кількість обчислень (і, відповідно, витрат) на одиницю корисної роботи.

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

Тому Anthropic працює в двох площинах:

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

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

Міф про «чарівні внутрішні інструменти»: роль Mythos і процесів

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

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

Команда Claude Code вже кілька кварталів працює в режимі, коли:

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

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

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

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

Інженери з продуктовим смаком: чому Anthropic концентрує відповідальність на індивідуальному рівні

Ще один ключовий елемент моделі Anthropic — те, кого саме компанія наймає й як розподіляє ролі між інженерами та продакт‑менеджерами. Cat Wu прямо говорить: компанія свідомо шукає інженерів із сильним продуктовим смаком.

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

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

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

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

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

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

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

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

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

Джерело

How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)

У київській студії УТ‑2 співзасновник і CEO Formlabs Макс Лобовскі пояснює, чому open‑source підхід, який перевернув світ програмного забезпечення, не спрацював так само в апаратному світі, зокрема у 3D‑друці. Formlabs, компанія з оцінкою близько $2 млрд, що відвантажила понад 100 000 професійних принтерів і генерує понад $200 млн річного доходу, стала одним із ключових гравців у глобальній індустрії адитивного виробництва. На цьому тлі Лобовскі формулює амбітну місію: зробити перехід від цифрового дизайну до фізичного об’єкта настільки швидким і дешевим, щоб «залізо» могло розвиватися майже так само гнучко, як програмне забезпечення.

Open‑source у 3D‑друці: чому немає «Linux для заліза»

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

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

У цьому сенсі open‑source hardware у 3D‑друці не зміг повторити шлях Linux. Якщо в софті відкритий код часто означає високу якість і широку адаптацію, то в апаратному світі відкритість поки що не корелює з технологічним лідерством. Навіть у сегменті FDM‑принтерів, де open‑source традиційно сильніший, найвищі показники продуктивності та якості зазвичай демонструють закриті, інтегровані системи.

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

Чому співпраця над «залізом» набагато важча, ніж над кодом

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

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

Лобовскі наводить контраст: змінити один рядок коду в ядрі Linux — миттєво й безкоштовно; змінити одну невелику деталь у формі для лиття пластику — це може коштувати $10 000 і зайняти шість тижнів. Кожна фізична ітерація — це не просто «коміт», а витрати на виробництво, логістику, тестування, іноді — на нове обладнання.

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

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

Війна дронів і межі open‑source hardware

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

На перший погляд, це приклад успішного open‑source hardware: спільноти швидко адаптують конструкції, діляться напрацюваннями, масштабують виробництво в гаражах і невеликих майстернях. Але Лобовскі пропонує подивитися глибше. На його думку, open‑source підхід добре працює для «простого FPV‑дрона», але не для «далекобійного, високопродуктивного ударного дрона».

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

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

Місія Formlabs: зробити еволюцію «заліза» схожою на еволюцію софту

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

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

Formlabs зосереджується на двох технологіях: SLA (друк на смолі) та SLS (друк із порошкових пластикових матеріалів). Обидві дозволяють отримувати деталі, які за якістю поверхні та точністю наближаються до лиття під тиском. Лобовскі підкреслює: якщо дати людині в руки SLA‑деталь Formlabs, вона часто не зможе відрізнити її від класичної литої.

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

Саме тому Formlabs від початку орієнтувалася на професійних користувачів, а не на домашній сегмент. Компанія стартувала на Kickstarter у 2012 році, але навіть тоді позиціонувала свій продукт як «професійний 3D‑принтер». Модель була незвичною: професійна якість за ціною, наближеною до споживчого ринку. Це дозволило дати в руки інженерам і дизайнерам інструмент, який раніше був доступний лише великим корпораціям і університетам на кшталт MIT чи Apple.

Apple, дрони й стоматологія: як 3D‑друк вбудовується в реальне виробництво

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

Apple, наприклад, використовує металеві технології 3D‑друку для деяких деталей — про це компанія публічно говорила, зокрема в контексті розробки порту зарядки для iPhone. Водночас для інших внутрішніх потреб Apple застосовує принтери Formlabs. Це показує, що майбутнє виробництва — не в домінуванні однієї технології, а в гнучкій комбінації: металевий 3D‑друк там, де потрібні унікальні властивості й міцність; полімерний SLA/SLS — там, де важливі швидкі ітерації, складна геометрія й точність; класичне лиття й обробка — для масового випуску.

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

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

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

Середній бізнес проти корпорацій: як продуктова ДНК впливає на стратегію

Formlabs досягла значного масштабу: понад 100 000 професійних принтерів по всьому світу, понад $200 млн річного доходу, прибутковість, статус «єдинорога» з 2018 року й оцінка близько $2 млрд у раунді 2021 року. Але структура клієнтської бази компанії показує, як внутрішня ДНК впливає на ринок.

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

Частково це пов’язано з особистими пріоритетами CEO. Лобовскі описує себе як більш продукт‑орієнтованого, ніж sales‑орієнтованого керівника. Одним із найскладніших уроків він називає вміння наймати й довіряти людям у сферах, де сам слабший, — процес-менеджмент, масштабні продажі, робота з великими корпоративними клієнтами.

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

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

Майбутнє виробництва: коекзистенція технологій і зменшення «тертя»

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

Металевий 3D‑друк використовується там, де критичні міцність і унікальна геометрія. Полімерний SLA/SLS — там, де потрібні швидкі ітерації, складні форми, персоналізація й відносно невеликі серії. Класичне лиття, штампування, фрезерування — там, де йдеться про мільйони однакових деталей за мінімальною собівартістю.

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

Formlabs намагається будувати саме таку інфраструктуру: доступні за ціною, але професійні SLA й SLS‑принтери; матеріали, які дають якість, близьку до лиття; софт, що знімає бар’єри для користувача. У цьому сенсі компанія не просто продає обладнання, а змінює саму динаміку розробки «заліза».

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

Висновок: open‑source не програв, але правила інші

Історія open‑source у 3D‑друці та апаратному світі загалом — це не історія поразки ідеї, а історія зіткнення ідеї з фізичною реальністю. Там, де зміни дешеві й миттєві, як у софті, відкриті моделі здатні створювати продукти рівня Linux. Там, де кожна ітерація коштує тисячі доларів і тижні часу, open‑source втрачає свою головну зброю — масову, швидку еволюцію.

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

Поки що open‑source hardware у 3D‑друці й дронах відстає від найсучасніших закритих рішень. Але чим більше інструментів на кшталт професійних, доступних 3D‑принтерів з’являється в руках інженерів, медиків і конструкторів, тим ближче той момент, коли еволюція «заліза» стане хоча б віддалено схожою на еволюцію софту. І тоді питання вже буде не в тому, чи можливий «Linux для заліза», а в тому, хто першим навчиться ним користуватися.

Джерело

Як зробити $2B на 3D-друку, конкуренція з Китаєм, враження від України. CEO Formlabs Макс Лобовскі

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

Від ідеї до робочого застосунку: поріг входу знижується

Один із показових прикладів — створення десктопного застосунку для запису подкастів. За допомогою Codex у зв’язці з GPT‑5.5 було реалізовано програму, яка:

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

Ключовий ефект тут не лише в самому застосунку, а в тому, що:

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

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

Від MVP до продакшену: роль GPT‑5.5 у масштабуванні

Ще один важливий сценарій — еволюція внутрішніх платформ. Попередню мінімально життєздатну версію (MVP) внутрішнього сервісу було створено з допомогою GPT‑5.4. Наступний етап — доведення цього рішення до продакшен-рівня — уже відбувався з використанням Codex і GPT‑5.5.

У цьому контексті GPT‑5.5 допомагає:

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

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

Довіра до моделі: коли ШІ знаходить те, про що його не питали

Окремий аспект GPT‑5.5 — зміна рівня довіри до моделі з боку інженерів. Важливий момент: система не обмежується буквальним виконанням запиту, а:

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

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

Новий рівень мотивації для розробників

Ще один непрямий, але показовий ефект — зміна ставлення до самої роботи над ПЗ. Коли інструмент:

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

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

Джерело

Відео OpenAI «Introducing GPT-5.5 with NVIDIA»: https://www.youtube.com/watch?v=VdXdGS7hUSY

Великі мовні моделі (LLM) стрімко змінюють те, як пишуть код: дедалі більше розробників делегують генерацію фрагментів програм ШІ-асистентам. У розмові на каналі The Pragmatic Engineer автор книжки Designing Data-Intensive Applications Мартін Клеппманн пояснює, чому така зміна підходу робить формальні методи й автоматичну перевірку коректності коду не просто бажаними, а необхідними.

«Vibe coding»: коли код пише ШІ

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

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

Людський код-рев’ю більше не масштабується

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

• код-рев’ю колегами;
• тестування (юнiт-, інтеграційні, end-to-end тести);
• статичний аналіз.

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

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

Безпека як головний аргумент

Проблема особливо гостра в контексті безпеки. Достатньо однієї дрібної помилки, щоб:

• відкрити вразливість;
• скомпрометувати всю систему;
• зруйнувати її модель загроз.

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

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

Формальні методи: від нішевого інструмента до масового

Формальна верифікація — це підхід, коли властивості програми (наприклад, відсутність певного класу помилок) доводяться математично. Історично такі методи вважалися:

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

Клеппманн висловлює надію, що LLM змінять цю ситуацію. Якщо моделі навчаться:

• допомагати формулювати специфікації;
• генерувати формальні моделі;
• асистувати у створенні доказів,

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

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

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

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

Джерело

Martin Kleppmann: Vibe coding → more demand for formal methods — The Pragmatic Engineer

У центрі нинішньої хвилі AI‑інструментів для розробників стоїть парадокс: моделі здатні писати тисячі рядків коду за хвилини, але саме це й загрожує перетворити проєкти на некерований хаос. Британський інженер і викладач Метт Поко́к, автор курсу «Claude Code for Real Engineers», пропонує протилежний підхід: не скасовувати класичні інженерні практики, а зробити їх ядром AI‑першого процесу розробки.

У своїй доповіді на каналі AI Engineer він показує, як поєднати промпт‑патерни, доменно‑орієнтований дизайн, типи, браузер, тести та архітектуру глибоких модулів так, щоб LLM працювала не як генератор «спагеті‑коду», а як дисциплінований співрозробник. Ключові елементи цієї системи — власний «grill me»‑промпт, «убіквітарна мова» у форматі markdown, тест‑драйв і архітектура, яка не дає моделі потонути у власних модулях.

Від «специ до коду» до спільної «design concept»

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

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

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

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

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

Щоб цього уникнути, він пропонує починати не з «генерації активів», а з досягнення спільної «design concept» — терміна Фредеріка П. Брукса з «The Design of Design». Design concept — це невидима, спільна для всіх учасників ідея того, що саме будується. Її не можна просто записати в один файл; це радше узгоджена ментальна модель системи.

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

«Grill me»: промпт, який перетворює AI на вимогливого співрозмовника

Для цього Поко́к створив окремий «skill» — промпт «grill me». Його суть вкрай проста, але наслідки виявилися масштабними. Промпт наказує моделі:

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

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

Результат виявився настільки затребуваним, що GitHub‑репозиторій із цим skill’ом набрав близько 13 тисяч зірок. Розробникам сподобалася не магія, а дисципліна: кілька рядків інструкцій перетворюють LLM на інструмент глибокого прояснення вимог.

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

Поко́к прямо порівнює цей підхід із вбудованим «plan mode» у Claude Code, яким сам користується. На його думку, стандартний режим надто прагне «створити актив» — швидко видати план і перейти до коду. «Grill me» навпаки затримує цей момент, змушуючи спочатку вибудувати спільну design concept. Саме тому він віддає перевагу власному skill’у: якість плану та відповідність намірам розробника виявляються вищими.

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

Убіквітарна мова для людини й моделі: markdown як контракт

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

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

Доменно‑орієнтований дизайн (Domain‑Driven Design, DDD) пропонує протиотруту — концепцію ubiquitous language, «убіквітарної мови». Це узгоджений набір термінів, який однаково використовується в розмовах між розробниками, у спілкуванні з бізнесом і в самому коді. У DDD це не просто словник, а відображення доменної моделі.

Поко́к переносить цю ідею в контекст AI‑асистованої розробки. Він створив окремий skill, який сканує кодову базу, виявляє ключову термінологію й автоматично формує markdown‑файл — фактично словник убіквітарної мови проєкту. У ньому терміни структуровані у вигляді таблиць із визначеннями, що робить документ зручним і для людини, і для моделі.

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

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

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

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

У підсумку ubiquitous language у форматі markdown стає ще одним видом контракту між людиною й моделлю, подібно до того, як інтерфейси й типи виступають контрактами всередині коду.

Типи, браузер і тести: як побудувати корисні фідбек‑цикли для LLM

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

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

Щоб повернути контроль, Поко́к наполягає на трьох типах зворотного зв’язку, до яких варто обов’язково підключати модель.

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

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

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

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

Щоб змусити модель рухатися дрібнішими кроками, Поко́к пропонує повернутися до ще однієї старої практики — тест‑драйв розробки.

TDD як «обмежувач швидкості» для AI‑розробника

Тест‑драйв розробки (Test‑Driven Development, TDD) традиційно вважається складною дисципліною. Потрібно вирішити, який саме блок тестувати, які сценарії покрити, що замокати, як уникнути крихкості тестів. Усе це — пов’язані між собою рішення, і саме тому багато команд або відмовляються від TDD, або застосовують його фрагментарно.

Парадоксально, але саме ця «важкість» робить TDD корисним у поєднанні з LLM. Поко́к пропонує використовувати його як спосіб примусово зменшити розмір кроків, які робить модель.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок: AI‑перший процес як повернення до класики

Підхід, який описує Метт Поко́к, виглядає парадоксально консервативним на тлі хайпу навколо «агентних» систем, що нібито здатні самостійно проєктувати й будувати складні застосунки. Замість того щоб мріяти про повну автоматизацію, він пропонує повернутися до старих книжок — Остергаута, Брукса, «The Pragmatic Programmer», Domain‑Driven Design — і використати їх як основу для AI‑першого процесу.

«Grill me»‑промпт допомагає досягти спільної design concept до того, як буде написано код. Убіквітарна мова в markdown зменшує семантичний шум і вирівнює план із реалізацією. Статичні типи, доступ до браузера й автоматизовані тести створюють щільні фідбек‑цикли, які не дозволяють «обігнати власні фари». TDD змушує модель рухатися дрібними, контрольованими кроками. А архітектура глибоких модулів забезпечує середовище, у якому LLM може ефективно орієнтуватися й еволюціонувати систему без вибуху складності.

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

Джерело

It Ain’t Broke: Why Software Fundamentals Matter More Than Ever — Matt Pocock, AI Hero @mattpocockuk

Hermes Agent — це самонавчальний AI‑агент від Nous Research з вбудованим «learning loop», який може запускатися на вашому власному сервері й працювати як персональний цифровий асистент. У великому туторіалі на каналі Tech With Tim демонструється повний шлях від вибору мовної моделі до підключення агента до Telegram. Нижче — розбір ключових технічних рішень і нюансів, які важливо врахувати, якщо ви хочете отримати стабільного й безпечного бота на базі Hermes.

Вибір модельного провайдера: чому ставка робиться на OpenAI Codeex і Minimax

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

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

Рекомендація Tech With Tim проста й прагматична: OpenAI Codeex і Minimax — одні з найбільш вигідних варіантів за співвідношенням ціна/якість. Hermes Agent може працювати з різними LLM‑провайдерами, але для більшості користувачів важливі дві речі: вартість токенів і стабільність. Обидва згадані сервіси дають достатню продуктивність для повсякденних задач агента, не роздуваючи рахунок за інференс.

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

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

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

GPT 5.4 як «двигун мислення» Hermes Agent

Після авторизації в OpenAI Codeex наступний крок — вибір конкретної моделі. У туторіалі в ролі основної обирається GPT 5.4. У контексті Hermes це не просто технічний параметр, а визначення того, як агент буде поводитися, міркувати й навчатися.

GPT 5.4 виступає головним reasoning‑двигуном Hermes Agent. Саме ця модель:

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

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

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

Чому Telegram стає головним інтерфейсом для Hermes Agent

Hermes Agent підтримує кілька платформ для обміну повідомленнями, зокрема Telegram, Slack і Discord. Однак у практичному сценарії налаштування основний акцент робиться саме на Telegram, і це не випадковість.

По‑перше, Telegram значно простіше в інтеграції для пересічного користувача. Створення бота тут не вимагає складної реєстрації застосунку, OAuth‑процедур чи налаштування callback‑URL, як це часто буває зі Slack або Discord. Усе відбувається всередині самого Telegram через спеціального системного бота BotFather.

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

У конфігурації Hermes це відображається як вибір Telegram у блоці «Messaging setup». Інтерфейс попереджає, що Slack і Discord потребують більше кроків для створення бота, тоді як Telegram рекомендований як стартова платформа, особливо для тих, хто вперше налаштовує подібну систему.

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

Як правильно створити Telegram‑бота для Hermes: BotFather, токен і унікальний username

Щоб Hermes Agent міг працювати через Telegram, йому потрібен токен бота — це ключ, який дозволяє системі надсилати й отримувати повідомлення від імені конкретного Telegram‑акаунта‑бота. Отримується він через офіційного бота BotFather.

Процес виглядає так: у Telegram відкривається пошук, знаходиться BotFather з синьою галочкою, і в діалозі з ним надсилається команда /newbot. Далі BotFather послідовно запитує два параметри.

Перший — це ім’я бота (display name). Це те, що користувачі бачитимуть у заголовку чату. Воно не повинно бути унікальним, тож тут можна обрати будь‑яку зручну назву — наприклад, «Hermes Tutorial».

Другий — це username. І тут починаються обмеження, які важливо врахувати:

Telegram вимагає, щоб username бота був глобально унікальним і закінчувався на _bot. Це означає, що ви не можете використати ім’я, яке вже зайняте будь‑ким у світі, і обов’язково маєте додати суфікс _bot. У демонстрації використовується щось на кшталт Hermes_tutorialbot234_bot — з додатковими цифрами, щоб уникнути конфлікту з уже існуючими іменами.

Якщо username прийнятий, BotFather створює бота й повертає HTTP API token. Саме цей токен потрібно скопіювати й вставити в конфігурацію Hermes Agent у полі «Telegram bot token». У терміналі при вставці токена вхідні символи не відображаються, але це нормальна поведінка: після натискання Enter Hermes зберігає значення й переходить до наступного кроку.

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

Обмеження доступу: allowed user IDs як базовий рівень безпеки

Після введення токена Hermes Agent запитує список дозволених Telegram user ID. Це ще один важливий запобіжник, без якого бот фактично стає публічним.

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

Тому система вимагає щонайменше один allowed user ID. Це список Telegram‑ідентифікаторів користувачів, яким дозволено взаємодіяти з ботом. Усі інші повідомлення Hermes просто ігноруватиме.

Щоб дізнатися власний Telegram user ID, використовується ще один службовий бот — userinfobot. У пошуку Telegram вводиться його назва, відкривається чат, і надсилається команда /start. У відповідь бот повертає інформацію про акаунт, зокрема числовий ID. Саме це число потрібно скопіювати й передати Hermes у полі allowed user IDs.

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

Локальна взаємодія: TUI Hermes як консольний фронтенд

Окрім інтеграції з месенджерами, Hermes Agent надає локальний термінальний інтерфейс користувача (TUI). Він запускається простою командою hermes у терміналі й відкриває консольний інтерфейс для спілкування з агентом безпосередньо на машині, де він встановлений.

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

Усередині TUI Hermes підтримує низку slash‑команд. Серед них — /new, яка створює нову сесію або контекст розмови. Це важливо, коли потрібно «обнулити» попередній діалог і почати спілкування з чистого аркуша, не тягнучи за собою старий контекст. Для агента з довгостроковою пам’яттю це зручний інструмент керування тим, що саме має враховуватися в поточній взаємодії.

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

Gateway як «серце» інтеграції з Telegram: чому його не можна зупиняти

Навіть після того, як модель налаштована, Telegram‑бот створений, токен переданий, а allowed user IDs задані, Hermes Agent ще не готовий до повноцінної роботи через месенджер. Для цього потрібен окремий компонент — messaging gateway.

Gateway запускається командою hermes gateway. Це окремий процес, який виступає посередником між Telegram API й ядром Hermes. Саме він:

• приймає вхідні повідомлення від Telegram‑бота;
• передає їх у Hermes для обробки мовною моделлю й навичками;
• повертає відповіді назад у Telegram.

Фактично gateway — це «насос», який перекачує дані між двома світами: зовнішнім (Telegram) і внутрішнім (агент на сервері). Без нього бот у Telegram хоч і існує, але залишається «німим» — повідомлення доходять до Telegram, але не потрапляють у Hermes, а відповіді не відправляються назад.

Ключовий практичний момент: gateway має працювати постійно. Якщо процес зупинити (наприклад, натиснувши Ctrl+C у терміналі, де він запущений), інтеграція з Telegram миттєво перестає працювати. Бот продовжує існувати, але перестає відповідати на повідомлення, доки hermes gateway знову не буде запущений.

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

Висновки: модель, бот і gateway як три кити робочого Hermes Agent

Налаштування Hermes Agent — це не лише питання розгортання на VPS чи локальній машині. Щоб отримати по‑справжньому корисного й безпечного агента, потрібно правильно зібрати кілька ключових компонентів.

По‑перше, вибір модельного провайдера й конкретної моделі визначає інтелектуальні можливості системи та її вартість у довгостроковій перспективі. Орієнтація на OpenAI Codeex і Minimax як на економічно доцільні варіанти, а також використання GPT 5.4 як основного reasoning‑двигуна, формує баланс між якістю й бюджетом.

По‑друге, Telegram виступає оптимальним фронтендом для більшості користувачів: просте створення бота через BotFather, зрозумілі обмеження на username з суфіксом _bot, зручний доступ із будь‑якого пристрою. Але разом із цим приходить і відповідальність за безпеку: токен бота має залишатися секретом, а список allowed user IDs — обов’язковою умовою, щоб агент не став публічним інструментом у руках сторонніх.

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

У сукупності ці елементи перетворюють Hermes Agent із абстрактної «платформи AI‑агента» на конкретний робочий інструмент: персонального асистента в Telegram, який мислить на базі GPT 5.4, працює на вашому обладнанні й підкоряється лише тим, кому ви явно дозволили до нього доступ.

Джерело

Hermes Agent Full Tutorial for Beginners | Setup Guide — Tech With Tim

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

Від шкільної ради до вірусного відео

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

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

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

Особистий досвід як головний експертний ресурс

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

Алгоритм простий:

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

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

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

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

Кілька важливих акцентів:

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

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

Мережа починається з найближчих людей

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

Тому важливо:

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

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

Онлайн і офлайн: єдина траєкторія лідерства

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

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

Джерело

Leadership starts with showing up — online and offline #TEDTalks

У розмові на подкасті 20VC with Harry Stebbings пролунала проста, але показова теза: сучасні AI‑інструменти вже дозволяють командам будувати інтерфейси й прототипи без традиційного залучення дизайнерів. Це не про ще один «вбивцю Figma», а про зміну самої моделі роботи з дизайном.

Коли Figma-файл уже не потрібен

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

Учасники дискусії ставлять під сумнів саму цінність цього етапу для невеликих команд:

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

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

AI як міст між ідеєю та робочим продуктом

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

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

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

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

Як AI «кусатиме» Figma та Adobe без прямої конкуренції

Окремо підкреслюється: немає очікування, що Anthropic чи інші AI‑гравці обов’язково створять прямий аналог Figma чи Illustrator. І це може бути й не потрібно.

Важливіше інше:

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

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

Що це означає для дизайнерів і команд

З описаної тенденції випливають кілька практичних висновків:

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

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

Джерело

YouTube: Why wait 30 days for a designer anymore?

У квітні 2026 року розробник і серійний «тінкерер» Кітзе (@thekitze на X), якому саме виповнилося 34, виступив на конференції AI Engineer з історією своїх експериментів із продуктивністю, особистими агентами та штучним інтелектом. Центральним прикладом став його багаторічний сайд‑проєкт Benji — гігантський «life OS» із десятками функцій, який так і не вийшов на ринок, попри вірусний успіх окремих AI‑демо. На його фоні особливо контрастує успіх інших засновників, які взяли одну вузьку ідею — наприклад, AI‑трекінг їжі з фото — і перетворили її на багатомільйонний бізнес.

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

60 функцій в одному застосунку: коли «life OS» стає надто щільним

Benji народився у 2022 році як кульмінація більш ніж двадцятирічної одержимості Кітзе системами продуктивності. Після текстових файлів, автоматизацій через Tasker, експериментів із Google Home та IFTTT, а також попередніх застосунків на кшталт Toodo і Better, він вирішив зробити «один застосунок, щоб керувати всім».

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

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

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

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

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

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

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

Технічно це було нетривіально. Моделі тоді ще не вміли надійно повертати структуровані дані. Щоб отримати JSON, придатний для виклику API, доводилося буквально «булити» модель у промптах: забороняти Markdown, просити суворо дотримуватися формату, а потім усе одно пост‑обробляти відповідь — парсити, обрізати зайве, виправляти помилки, поки не вийде валідний JSON. Це був ручний шар інженерії поверх сирих можливостей LLM, без якого голосовий асистент просто не працював би.

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

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

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

Вузькі AI‑застосунки проти «швейцарського ножа»: хто знаходить product‑market fit

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

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

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

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

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

Як технічні обмеження LLM формували Benji — і чому це важливо для продуктів

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

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

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

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

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

Чому Benji так і залишився сайд‑проєктом — і що це говорить про стратегію

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

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

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

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

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

Висновок: уроки Benji для епохи AI‑продуктів

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

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

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

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

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

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

Джерело

The End of Apps — Kitze, Sizzy.co (YouTube)

Подкаст 20VC з Гаррі Стеббінгсом розібрав потенційну синергію між компанією, схожою на Cursor, та бізнесом на кшталт SpaceX/х Musk‑екосистеми, показуючи, чому така угода може бути економічно й стратегічно виправданою для обох сторін.

Дві протилежні проблеми: надлишок і дефіцит

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

Це класична ситуація для генеративного AI‑сектору:
– продукт добре продається;
– витрати на інфраструктуру (GPU, дата-центри, енергія) «з’їдають» маржу;
– без контролю над моделлю та обчисленнями бізнес стає вразливим і фінансово важким.

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

Тобто є технологія й інфраструктура, але немає зрозумілої монетизації та масштабного ринку збуту.

«Шлюб, укладений на небесах»: як складається пазл

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

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

• дає більше контролю над якістю й швидкістю роботи сервісу.

• Інфраструктурний гравець із надлишком compute нарешті знаходить реальний бізнес-кейс:

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

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

Що це показує про ринок AI‑інфраструктури

Цей кейс ілюструє кілька ширших тенденцій на ринку штучного інтелекту:

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

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

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

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

Джерело

Why the SpaceX-Cursor deal makes sense — 20VC with Harry Stebbings

Anthropic, компанія за Claude, Claude Code та Cowork, не лише створює одні з найпомітніших AI‑продуктів, а й експериментує з тим, як має виглядати продуктова організація в епоху моделей, що оновлюються кожні кілька місяців. Кат Ву, Head of Product для Claude Code та Cowork, опинилася в центрі цієї трансформації: її команда працює на межі між дослідженнями, платформою для розробників, ентерпрайз‑клієнтами й швидкісним зростанням продукту.

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

Мозаїка замість моноліту: як влаштована продуктова команда Anthropic

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

Ключові блоки цієї організації виглядають так. Є команда дослідницьких PM, яка працює безпосередньо з моделями; є команда платформи для розробників Claude, що відповідає за API та такі можливості, як керовані агенти; є продуктова команда Claude Code та Cowork, яка створює прикладні інструменти поверх моделей; є окрема ентерпрайз‑команда, що фокусується на безпеці, контролі витрат і керуванні доступами; нарешті, є growth‑команда, яка працює горизонтально по всіх цих напрямках.

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

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

Дослідницькі PM: «сполучна тканина» між моделлю та продуктом

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

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

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

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

Платформа для розробників: Claude як фундамент, а не лише застосунок

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

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

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

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

Ентерпрайз як окремий продукт: безпека, контроль витрат і RBAC

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

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

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

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

Ще одна нетипова деталь — те, як Anthropic організовує зростання. Замість того, щоб прив’язати growth‑команду до одного продукту, компанія розміщує її горизонтально поверх Claude Code, Cowork і Claude API.

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

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

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

Claude Code як AI‑нативна команда: продакти й дизайнери, які пишуть код

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

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

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

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

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

Як процеси підлаштовуються під таку структуру

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

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

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

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

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

Висновок: продуктова організація як конкурентна перевага в AI‑гонці

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

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

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

Джерело

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

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

Від «сирих дошок» до стандартного дизайну

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

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

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

Патерн 1: єдине очищення та валідація як джерело правди

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

Приклад: у записах продажів частина цін — null.

• фінанси замінюють null на 0 доларів;
• маркетинг просто відкидає такі записи.

У підсумку:

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

Щоб уникнути цього, правила очищення й валідації мають бути:

1. Уніфікованими — визначеними один раз разом із доменними експертами (наприклад, null → 0, але з прапорцем для подальшої перевірки).
2. Реалізованими в одному пайплайні — який формує «єдине джерело правди» для всіх споживачів.

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

Патерн 2: уніфікація форматів замість зоопарку структур

Навіть після очищення дані часто залишаються несумісними через різні формати:

• різні назви полів (customer_id vs user_id);
• різна структура адрес (один рядок проти окремих полів «місто», «штат», «поштовий індекс»);
• різні формати даних (JSON проти Protocol Buffers);
• різні формати дат (YYYY-MM-DD, MM/DD/YYYY, Unix timestamp).

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

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

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

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

Патерн 3: збагачення подій ближче до джерела

Більшість бізнес-запитань не обмежуються «голими» ідентифікаторами. Продаж із полями customer_id, product_id, price мало що скаже про:

• регіональні тренди;
• поведінку сегментів клієнтів;
• динаміку категорій товарів.

Традиційний підхід — кожна команда самостійно «збагачує» події, приєднуючи:

• дані про клієнтів;
• каталоги продуктів;
• географічну інформацію;
• зовнішні довідники.

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

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

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

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

Патерн 4: попередня агрегація як спільний сервіс

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

Типовий сценарій:

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

Проблеми очевидні:

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

Вихід — агрегувати дані в самому пайплайні й публікувати вже готові агреговані події:

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

Такі агрегати:

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

Від batch до real-time: роль Apache Flink

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

Сучасні стримінгові платформи, зокрема Apache Flink, дозволяють застосовувати ті самі патерни в реальному часі:

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

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

Що таке data-продукт і чому це «IKEA для даних»

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

Такий продукт має чотири ключові властивості:

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

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

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

4. Готовність до негайного використання
   Попередньо збагачені й агреговані дані покривають до 90% типових потреб; залишкові 10% — це вже специфічна надбудова для конкретної задачі.

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

Джерело

Why are data engineers building custom furniture (and how to stop)? — YouTube

НА ПРАВАХ РЕКЛАМИ
Ринок мобільних аксесуарів сьогодні надзвичайно насичений, але лише частина брендів стабільно поєднує якість, інновації та доступну ціну. Саме такі виробники формують довіру клієнтів і забезпечують стабільні продажі як в онлайн, так і в офлайн-магазинах.

Популярні бренди якісних мобільних аксесуарів

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

Серед популярних брендів варто виділити:

• McDodo – технологічний бренд, який спеціалізується на зарядних рішеннях і пропонує інноваційні кабелі та адаптери з функціями безпечної та швидкої зарядки;
• Remax – один із наймасовіших брендів із широким асортиментом аксесуарів, який поєднує доступність, стильний дизайн і великий вибір товарів;
• Momax – преміальний бренд із високою якістю матеріалів і сучасними технологіями, орієнтований на користувачів, які цінують надійність і довговічність;
• ACEFAST – новий, але перспективний бренд із сучасними рішеннями, такими як швидкі зарядки та аксесуари нового покоління;
• Nillkin – відомий виробник захисних аксесуарів, який пропонує надійні чохли та захисне скло з високим рівнем захисту;
• Monblan — бренд захисного скла та чохлів для Apple-техніки, орієнтований на преміальний сегмент, що ідеально підходить для перепродажу;
• Alabay — бренд захисного скла та чохлів для Apple-техніки в більш бюджетному сегменті для щоденного використання.

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

Чому краще працювати з перевіреними брендами

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

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

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

Де закуповувати популярні бренди

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

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

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