Керівництво Apple входить у нову еру. Після багатьох років на чолі компанії Тім Кук йде у відставку й виходить на пенсію. Його наступником стане Джон Тернус — нинішній старший віцепрезидент з апаратної інженерії, людина, яка стояла за запуском iPad, AirPods і численних поколінь iPhone, Mac та Apple Watch.

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

Хто такий Джон Тернус і чому саме він

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

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

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

AI під софтом, а не над усім: чим Apple відрізняється від конкурентів

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

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

Такий підхід має дві сторони.

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

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

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

«AI‑рів» Apple: коли залізо стає головною перевагою

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

Цей «рів» складається з кількох елементів.

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

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

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

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

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

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

Чи залишиться Apple в «залізній смузі» AI

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

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

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

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

Усередині самої компанії поки що немає «AI‑першої» фігури на рівні топ-менеджменту, яка б задавала тон усьому бізнесу. AI залишається під крилом програмного забезпечення, а не окремим центром сили. Один із можливих шляхів розвитку — модель «two in a box», де поряд із апаратним CEO формується сильний співкерівник або блок, відповідальний саме за AI‑стратегію. Для Apple це могло б стати способом поєднати апаратну спадковість із новими вимогами AI‑ери.

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

Коли 8 мільярдів параметрів наздоганяють 120: шанс для обчислень на пристрої

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

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

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

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

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

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

Майбутнє Apple в AI: між контролем і амбіцією

Зміна керівництва в Apple відбувається в момент, коли компанія стоїть між двома полюсами.

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

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

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

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

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

Висновок

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

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

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

Джерело

Mixture of Experts – Apple’s new CEO & how AI understands intent (IBM Technology)

Роль продакт-менеджера стрімко змінюється під тиском AI‑революції. В епоху LLM‑сервісів і «AI‑native» продуктів виграють ті команди, які вміють не планувати роками, а відправляти нові фічі в продакшн щотижня. На це звертають увагу в подкасті Lenny’s Podcast, де обговорюють, як саме трансформується робота PM у світі штучного інтелекту.

Від багатоквартальних роадмапів до тижневих релізів

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

Ключова вимога зараз — надшвидка ітерація:

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

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

«Пісочниця» в продукті: де ідея стає фічею за тиждень

Один із практичних підходів — створити в межах продукту умовний «концепт-куток» або пісочницю, де:

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

Такий простір дозволяє:

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

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

Як LLM змінюють завдання продакт-менеджера

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

Саме тут посилюється роль PM:

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

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

Головна метрика: час від ідеї до користувача

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

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

Скорочення цього інтервалу — центральне завдання. Воно вимагає:

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

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

Джерело

The best PMs are shipping weekly — Lenny’s Podcast

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?