У київській студії каналу УТ‑2 нещодавно побував Макс Лобовскі — співзасновник і CEO Formlabs, однієї з найпомітніших компаній у глобальній індустрії 3D‑друку. Саме її принтери стоять у лабораторіях Tesla та Apple, а сама компанія оцінювалася інвесторами приблизно у $2 млрд ще у 2021 році. Історія Formlabs — це не про «іграшки для гаража», а про послідовне будівництво великого, прибуткового hardware‑бізнесу, який із Kickstarter‑кампанії виріс до одного з лідерів професійного 3D‑друку.

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

Formlabs з’явилася на ринку у 2012 році — в епоху, коли 3D‑друк масово асоціювався з хобі‑машинками для ентузіастів, а не з інструментами інженерів. Перший принтер компанія запустила через Kickstarter, що автоматично створювало враження «B2C‑гаджета для всіх». Але стратегія з самого початку була іншою.

У заголовку тієї самої Kickstarter‑сторінки 2012 року прямо стояло формулювання «професійний 3D‑принтер». Formlabs свідомо йшов проти хвилі масового FDM‑ентузіазму, де друк виглядав грубо, з помітними шарами, а якість деталей рідко відповідала вимогам інженерних команд. Компанія одразу обрала дорожчі, складніші, але значно якісніші технології — SLA (фотополімерні смоли) та згодом SLS (порошкові пластики).

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

У 2018 році Formlabs офіційно стала «єдинорогом», подолавши оцінку в $1 млрд. У 2021‑му, під час останнього раунду фінансування, компанію вже оцінювали приблизно у $2 млрд. Але сам Лобовскі ставиться до цих цифр стримано, апелюючи до відомої метафори Воррена Баффета: у короткостроковій перспективі ринок — це «машина для голосування», у довгостроковій — «машина для зважування». Для нього важливіші не слайди з оцінкою, а реальні показники: скільки принтерів стоїть у клієнтів, який дохід генерує бізнес і чи працює він прибутково.

Сьогодні Formlabs вже відвантажила понад 100 000 професійних 3D‑принтерів по всьому світу, генерує понад $200 млн річного доходу і працює з прибутком — рідкісний статус для hardware‑стартапу на такій стадії розвитку.

Чому Formlabs не про «3D‑принтер у кожен дім»

У ранніх медіа‑сюжетах про 3D‑друк часто звучала мрія «принтер у кожній оселі». Лобовскі теж колись формулював місію як «принести 3D‑друк у кожен дім» — це добре зафіксовано, зокрема, у документальному фільмі Netflix «Print the Legend». Але реальна траєкторія Formlabs виявилася іншою.

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

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

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

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

Клієнти рівня Tesla та Apple: як 3D‑друк стає інструментом серйозної інженерії

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

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

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

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

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

Прибутковий hardware: чому Formlabs — виняток серед стартапів

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

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

У випадку Formlabs цьому сприяло кілька факторів.

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

По‑друге, масштаб. Понад 100 000 встановлених пристроїв — це не лише разові продажі, а й база для повторних закупівель матеріалів, сервісних контрактів, оновлень. У 3D‑друці маржинальність часто концентрується не тільки в «залізі», а й у витратних матеріалах та сервісах, і Formlabs послідовно будує навколо принтерів повноцінну екосистему.

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

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

Уроки CEO: як слабкі сторони засновника впливають на клієнтів

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

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

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

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

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

Місія на перетині софту й заліза

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

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

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

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

Висновок: 3D‑друк як зріла індустрія, а не футуристична обіцянка

Історія Formlabs руйнує кілька стійких міфів про hardware‑стартапи й 3D‑друк.

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

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

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

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

Джерело

Інтерв’ю Макса Лобовскі на каналі УТ‑2

Оновлення інструмента Codex від OpenAI, про яке розповідає канал Tech With Tim, показує помітний зсув у тому, як може виглядати AI‑асистована розробка. Мова вже не лише про генерацію коду: модель отримала змогу самостійно працювати з інтерфейсами, тестувати створені застосунки й навіть взаємодіяти з ними в реальному часі.

Від генерації коду до взаємодії з інтерфейсом

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

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

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

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

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

Computer Use: вихід за межі браузера

Аналогічні можливості винесено й за межі браузера — функція отримала назву Computer Use. У цьому режимі Codex:

• «бачить» екран користувача;
• рухає власний курсор;
• клікає в будь‑яких застосунках на macOS.

У демонстрації інструмент грає в «хрестики‑нулики» в нативному застосунку, відкриває Spotify та вмикає музику. Але показові приклади — лише верхівка айсберга. Заявлені основні сценарії використання:

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

Важлива деталь: Codex керує своїм курсором, тож користувач може продовжувати працювати паралельно, поки AI виконує власні дії на екрані.

Закриття головного «вузького місця» AI‑розробки

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

Оновлений Codex намагається закрити саме цю ділянку:

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

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

Джерело

Codex Built a Game and Then Played It With Me — Tech With Tim

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

Її розмова з митцем і дослідником Деніелом Александером Джонсом на сцені TEDNext 2025 — це не просто історія про подолання труднощів. Це спроба переосмислити саму архітектуру почуттів: що саме змушує нас страждати — події чи думки, які ми про них думаємо?

Від «усе чудово» до «темної ночі душі»

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

Потім усе обвалилося майже одночасно. Премію отримала інша акторка. Серіал, у якому вона знімалася, закрили. Чоловік залишився в Нью-Йорку, а вона переїхала до Лос-Анджелеса, який він відверто не любить. Вони намагалися завагітніти, але були розділені трьома тисячами миль. Роботи не було. Із зовнішнього «успіху» Ронда опинилася в стані глибокої внутрішньої темряви.

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

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

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

Що таке емоційний суверенітет: простір між подією і почуттям

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

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

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

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

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

Саундтрек у голові: як внутрішній голос підриває або підтримує

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

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

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

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

Коли тіло болить, а філософія перевіряється: історія викиднів

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

Один із найяскравіших епізодів стався під час репетицій вистави «Phoenix Fabrik» у Міннеаполісі. На сцені разом із нею працювала їхня спільна з Деніелом Александером Джонсом наставниця — легендарна акторка Вінні Берроуз. Берроуз, яка починала на Бродвеї у 1950-х, зіткнулася з жорсткими расовими обмеженнями, але згодом створила один із перших сольних театральних проєктів і зіграла його понад 6000 разів по всьому світу. Її життя було втіленням особистої й творчої агенції.

У день, коли Ронда дізналася, що в неї викидень, вона ходила по вулиці, говорила телефоном із чоловіком, а Вінні спостерігала за нею крізь вікно репетиційної зали. Коли Росс зайшла всередину, Берроуз, у властивій їй драматичній манері, запитала, що сталося. Почувши про викидень, вона вигукнула: «Це кінець світу». Ронда погодилася: «Так». І тоді Вінні додала: «Але це не так».

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

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

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

«Життя в русі»: від Вінні Берроуз до щоденних панік на вулиці

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

Одного разу, згадує він, Вінні зустріла його на вулиці в Нижньому Іст-Сайді Нью-Йорка, міцно схопила за руку й кілька разів повторила: «Життя — це рух. Життя — це рух!». Ця фраза стала для нього й для Ронди своєрідною формулою: життя не зупиняється, не завмирає в зручній точці, воно постійно змінюється, іноді болісно, іноді раптово.

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

Один із найприземленіших прикладів — її нещодавня паніка на 125-й вулиці в Нью-Йорку. Її син Раїф не був там, де мав бути, хоча трекер показував, що він поруч. За її словами, це тривало всього близько п’яти хвилин, але за цей час у голові встиг розгорнутися повноцінний «шторм»: страх, катастрофічні сценарії, відчуття втрати контролю.

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

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

Від макро до мікро: свобода як щоденна практика

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

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

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

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

Як працює внутрішня агенція: три ключові кроки

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

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

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

Третій крок — пошук думки, яка запускає це почуття. Не події, а саме думки. Росс називає такі думки «automatic screwy thoughts» або «automatic sabotaging thoughts» — автоматичні «криві» або саботуючі думки, скорочено AST. Це ті самі фрази, які звучать у внутрішньому саундтреці: «я нікчемний», «зі мною завжди щось не так», «мене ніхто не любить», «я завжди все псу», «зі мною обов’язково станеться найгірше». Коли людина чітко формулює цю думку, стає очевидно: «ніхто не може почуватися добре, маючи в голові таку фразу». Усвідомлення цього відкриває можливість змінити саму думку, а не лише боротися з емоцією.

Далі, у своїй ширшій методиці, Росс говорить про перетворення AST на INT — «intentionally nourishing thought», навмисно живильну думку, яка працює як персоналізована афірмація або мантра. Але навіть без детального розгляду цього етапу зрозуміло головне: емоційний суверенітет — це не заперечення болю, а перенесення фокусу з неконтрольованих обставин на контрольовані думки.

Мистецтво як носій суверенітету

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

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

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

Висновок: свобода починається з фрази в голові

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

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

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

Джерело

How to Tune Your Inner Voice | Rhonda Ross, Daniel Alexander Jones | TED

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

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

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

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

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

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

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

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

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

Пам’ять, що не обнуляється: як Hermes працює з користувацьким контекстом

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

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

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

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

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

Глибокий доступ до системи: можливості й ризики

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

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

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

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

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

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

Hermes проти OpenClaw: один потужний агент чи складна мультиагентна система

Hermes Agent прямо позиціонується як конкурент OpenClaw — іншого популярного фреймворку для AI-агентів. Водночас акценти в цих двох системах помітно різні, і це визначає, кому яке рішення підійде краще.

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

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

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

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

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

Один агент — багато каналів: Telegram, Slack, Discord

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

У туторіалі демонструється налаштування Hermes через інтерактивний термінальний інтерфейс (TUI), який запускається командою hermes. На етапі конфігурації користувач може активувати модуль «messaging» і вибрати, через які платформи агент буде доступний. Серед підтримуваних варіантів — Telegram, Slack і Discord.

Telegram у прикладі використовується як основний канал, особливо рекомендований для початківців. Причина проста: створити бота в Telegram відносно легко. Достатньо звернутися до BotFather, виконати команду /newbot, задати відображуване ім’я та унікальний username, який обов’язково має закінчуватися на _bot. Після цього видається токен, який потрібно вставити в конфігурацію Hermes.

Важливий момент безпеки — Hermes вимагає вказати хоча б один дозволений Telegram user ID. Якщо цього не зробити, бот фактично стане публічним: будь-хто, хто знайде його в Telegram, зможе з ним спілкуватися й, опосередковано, керувати вашим агентом. Щоб цього уникнути, у прикладі пропонується отримати власний user ID через спеціального бота userinfobot і додати його до списку дозволених.

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

Факт підтримки кількох платформ означає, що Hermes може стати «єдиною точкою інтелекту» для користувача чи команди, доступною з різних чат-середовищ. Один і той самий агент, зі спільною пам’яттю та навичками, може відповідати вам у Telegram особисто, а в Slack — як «колега» в робочому каналі.

Автономія й оркестрація: чому Hermes виглядає зрілішим за класичні боти

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

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

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

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

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

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

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

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

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

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

Джерело

Hermes Agent Full Tutorial for Beginners | Setup Guide

У київській студії УТ‑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 Макс Лобовскі

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

Технологічний ринок штучного інтелекту входить у фазу надмасштабних угод і безпрецедентних оцінок. У новому випуску подкасту 20VC with Harry Stebbings обговорюються одразу кілька подій, які можуть задати тон для всієї індустрії на найближчі роки: гігантське придбання Cursor, відставка Тіма Кука з Apple, стрибок вартості Anthropic до трильйона доларів на вторинному ринку та запуск нового продукту Claude Design.

Рекордне придбання Cursor: $60 млрд і безпрецедентний break‑fee

Однією з головних тем стала угода, яку на ринку вже називають історичною: Cursor купують XAI або SpaceX за 60 млрд доларів. Додатковий штрих — break clause (штраф за розрив угоди) на рівні 10 млрд доларів. Такий масштабний штраф свідчить про надзвичайну серйозність намірів сторін і про те, що угода розглядається як стратегічно критична.

На тлі цього лунає оцінка, що така транзакція може стати “high water mark” приватних M&A — тобто найвищою точкою для приватних злиттів і поглинань — щонайменше на десятиліття. Іншими словами, ринок може довго не побачити нічого більшого за цю угоду в сегменті приватних компаній.

Водночас звучить прогноз, що угода на $100 млрд у цьому секторі — питання найближчих 12 місяців. Якщо Cursor за $60 млрд — не межа, то індустрія входить у період, коли суми, які ще недавно здавалися фантастичними, стають новою нормою.

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

Окремо підкреслюється механіка, яка робить такі придбання можливими. Якщо компанія торгується з мультиплікатором 100× виручки, вона фактично може дозволити собі купувати бізнеси, що оцінюються у 10–15× виручки, майже без обмежень.

Логіка проста: використовуючи власні “дорогі” акції як валюту, така компанія може консолідувати активи, які ринок оцінює значно дешевше від неї самої. Це створює потужний стимул до агресивних M&A‑стратегій, особливо в AI‑секторі, де очікування майбутнього зростання часто випереджають реальні фінансові показники.

Anthropic: відмова від $800 млрд і вихід на трильйон на вторинному ринку

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

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

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

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

Claude Design: новий виклик Figma, Adobe та Canva

На додачу до фінансових рекордів Anthropic розширює продуктову лінійку, запускаючи Claude Design. Новий інструмент напряму націлений на сегмент, де домінують Figma, Adobe та Canva.

Це важливий сигнал для ринку:

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

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

Відставка Тіма Кука: ще один символ епохи змін

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

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

Джерело

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

Після аварії на Фукусімській АЕС Японія опинилася перед енергетичним вибором: замінити атомну генерацію вугіллям чи зробити ставку на чисті джерела. TED-виступ кліматичної активістки Кіміко Хірати, записаний на TED Countdown Summit 2025, показує, як невеликий громадський рух зміг зупинити частину вугільних проєктів і переформатувати дискусію — від «ні вугіллю» до «так відновлюваній енергетиці».

Вибух вугільних проєктів після Фукусіми

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

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

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

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

Акціонерний тиск на фінансистів вугілля

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

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

Сукупність локальних кампаній, публічного тиску та акціонерних дій дала відчутний ефект: із 50 запланованих вугільних проєктів 17 (загальною потужністю 9 ГВт) були скасовані. За оцінками, це дозволило уникнути 50 млн тонн CO₂ щороку та 1,7 млрд тонн за весь строк роботи цих станцій — еквівалент виведення з експлуатації понад 8 млн автомобілів щороку протягом 40 років.

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

Від «ні вугіллю» до «так відновлюваній енергетиці»

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

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

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

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

Міста як лабораторії енергетичного переходу

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

• Тойоока (західна Японія) — курортний регіон із гарячими джерелами та гірськолижною інфраструктурою. Місто вже відчуває наслідки зміни клімату: менше снігу, екстремальна спека. Відповіддю стала спроба перетворитися на модель сталого туризму, поєднуючи підхід «nature-positive» (підсилення природних екосистем) із декарбонізацією.

• Ічікава (поблизу Токіо) — щільно забудована міська зона з великою кількістю житлових будинків. Тут ставка робиться на масове встановлення дахових сонячних панелей і підвищення енергоефективності житла, зокрема для молодих сімей. Такий підхід показує, як міста з високою щільністю населення можуть інтегрувати ВДЕ без масштабних наземних проєктів.

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

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

Візія: 90% ВДЕ та експорт змін до Азії

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

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

Джерело

«A Cheat Sheet for Canceling Coal | Kimiko Hirata | TED»

Запуск ChatGPT Images 2.0 став однією з найпомітніших подій на ринку генеративної графіки 2026 року. Новий візуальний модуль від OpenAI, інтегрований у ChatGPT, позиціонують як серйозного конкурента популярним моделям на кшталт Nano Banana, які довго вважалися «золотим стандартом» для зображень. Канал Futurepedia провів розгорнуте практичне тестування новинки — від промпт‑трюків до складних інфографік та освітніх постерів.

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

Одне слово, велика різниця: як «photorealism» змінює якість зображень

Перший практичний висновок, який кидається в очі під час роботи з ChatGPT Images 2.0, стосується промптингу. Звичні формулювання на кшталт «realistic photo», «iPhone photo» чи «cinematic» дають цілком пристойні результати, але не виводять модель на максимум її можливостей.

Ключовим виявилося одне слово — «photorealism». Додавання цього терміна до вже наявного промпту радикально змінює результат:

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

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

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

Це добре ілюструє важливу рису сучасних генеративних моделей: вони мають власні «мовні звички» та приховані стилістичні перемикачі. Те, що працює в одному генераторі («cinematic», «DSLR shot», «8k»), не обов’язково дає найкращий результат в іншому. Для ChatGPT Images 2.0 таким перемикачем, принаймні зараз, виявляється саме «photorealism».

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

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

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

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

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

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

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

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

4K через API: коли роздільна здатність справді має значення

Ще один важливий елемент екосистеми ChatGPT Images 2.0 — підтримка 4K‑генерації через API. OpenAI додала цю опцію для GPT‑Image 2, і в тестах вона виявилася не просто маркетинговою позначкою, а реальним покращенням якості, особливо для облич і дрібного тексту.

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

У базовому режимі всередині ChatGPT результат вийшов набагато кращим, ніж зазвичай дають подібні інструменти, але обличчя все ж залишалося трохи «м’яким», із недостатньою деталізацією. Після запуску того ж промпту через 4K‑опцію API (у тесті використовувався сервіс Higgs Field як інтерфейс до моделі) чіткість помітно зросла: зморшки, текстура шкіри, дрібні риси стали значно виразнішими.

Для порівняння той самий сценарій прогнали через Nano Banana з її власною 4K‑опцією. Там обличчя стабільно виглядали «не так»: пропорції, вираз, дрібні деталі були помітно менш точними. Це не означає, що Nano Banana погано працює в усіх 4K‑сценаріях, але саме в задачі комбінування реальних фото GPT‑Image 2 із 4K‑режимом показав себе переконливіше.

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

Від алфавітних постерів до сіток 10×10: логіка, простір і текст

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

Класичний «головоломковий» промпт — постер «alphabet animals», де кожна літера англійського алфавіту має відповідати тварині: A — alligator, B — bear, C — cat тощо. На перший погляд завдання просте, але на практиці багато моделей спотикаються на останніх рядках: 26 літер не вкладаються в ідеальну прямокутну сітку, і генератор починає «вигадувати» власну структуру.

У Nano Banana це проявлялося у вигляді зсувів: літери й назви тварин переставлялися місцями, деякі букви пропускалися, інші дублювалися. В одному з варіантів Q виявилася під носорогом, R — під лінивцем, а в іншому W і X були об’єднані в одну плитку з «гібридом» кита та риби‑рентгена.

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

Ще більш амбітний тест — сітка 10×10 зі 100 об’єктами, що починаються на літеру A. Тут модель мала не просто згенерувати сто різних предметів, а й розмістити їх у чіткій структурі, не повторюючись і не збиваючись.

Результат виявився майже бездоганним. Лише при детальному розгляді виявилися кілька дрібних збоїв: наприклад, «answering machine» і куртка опинилися на одній плитці, а в іншому місці з’явилася неоднозначність із «antique key». Водночас модель коректно обробила менш очевидні слова: «aubergine» було правильно інтерпретовано як баклажан, хоча для багатьох користувачів це слово потребує додаткового пояснення.

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

Окремої уваги заслуговує робота з текстом у складних макетах. У пародійному кіноафіші дрібний «службовий» текст унизу — імена композитора, монтажера, художника‑постановника — був відтворений без помилок: «Music by Binary Bard», «Edited by Cut and Code», «Production design by Pixel and Pine». Для порівняння, Nano Banana в аналогічному завданні створила естетично привабливий постер, але дрібний текст виявився спотвореним і нерозбірливим.

Ще один показовий кейс — газетна перша шпальта з анонсом запуску GPT Images 2. Тут ChatGPT Images 2.0 згенерував повноцінний макет: головний заголовок, підзаголовки, додаткові статті по краях, читабельний текст без очевидних артефактів. У Nano Banana подібні завдання часто «ламаються» саме на другорядному тексті: якщо не підвантажувати готовий контент, модель заповнює поля псевдосимволами або напівчитабельними фрагментами.

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

Thinking mode: коли генератор картинок спершу йде «вчитись»

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

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

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

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

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

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

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

Освітні та робочі сценарії: від рецептів до рукописних постерів

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

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

Ще один яскравий приклад — постер «We are Stardust and Co.» у стилі рукописних заміток. У Nano Banana результат вийшов акуратним, без явних помилок у тексті, але візуально нагадував звичайний друкований плакат: рівні лінії, передбачувана композиція, відсутність «живих» деталей.

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

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

Висновки: генератор зображень, який мислить як редактор

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

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

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

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

По‑четверте, ChatGPT Images 2.0 впевнено працює там, де інші моделі часто помиляються: алфавітні постери, великі сітки об’єктів, газетні шпальти, інфографіки з великою кількістю тексту.

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

У підсумку ChatGPT Images 2.0 виглядає як інструмент, який може стати центральним елементом робочих процесів для тих, хто працює на перетині тексту, даних і візуального контенту. І якщо сьогодні він уже впевнено конкурує з Nano Banana в низці ключових завдань, то подальший розвиток thinking mode і текстових можливостей може ще більше змістити баланс сил на ринку генеративної графіки.

Джерело

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

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

Як Claude Code виконує дії в проєкті

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

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

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

Фактично Claude Code поводиться як агент, який завжди «стукає в двері» перед тим, як щось змінити.

Чому агент постійно запитує підтвердження

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

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

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

Режими дозволів: як зменшити кількість запитів

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

Ідея режимів у тому, щоб знайти баланс між:

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

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

Чому модель дозволів стає стандартом для AI-інструментів

Підхід, який демонструє Claude Code, добре вписується в загальну тенденцію розвитку AI-інструментів для розробників:

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

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

Джерело

Повний огляд Claude Code – Частина 6 — KODARIK

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

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

Коли абстракції корисні, а коли — небезпечні

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

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

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

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

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

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

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

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

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

LLM не скасовують системне мислення — вони підвищують ставки

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

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

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

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

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

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

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

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

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

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

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

Від MapReduce до векторних індексів: абстракції змінюються, фундаментальні питання — ні

Друга, суттєво оновлена редакція «Designing Data‑Intensive Applications», що вийшла приблизно через дев’ять років після першої, сама по собі є відображенням зміни абстракцій. Клеппман спільно з Крісом Ріккоміні прибрав із книги розділи про MapReduce, який він безапеляційно називає мертвим: «ніхто більше цим не користується». Натомість з’явилися розширені розділи про системи, що підтримують AI‑навантаження, зокрема про векторні індекси.

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

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

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

Хто має «володіти» глибиною: нова роль системних інженерів

Якщо прийняти, що не кожен розробник має бути експертом із розподілених систем, постає питання: хто тоді відповідає за те, щоб у компанії зберігалося це знання?

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

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

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

Висновок: абстракції — це не втеча від складності, а спосіб її організувати

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

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

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

Джерело

Повна розмова: Designing Data-intensive Applications with Martin Kleppmann — The Pragmatic Engineer

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

Нові «економіки виробництва»: робота дешева, планування й рев’ю — ні

За останні 6–12 місяців змінилася сама структура роботи з AI‑системами:

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

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

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

Корисна рамка для розуміння можливостей агентів — правило верифікатора (verifier’s rule), сформульоване Джейсоном (прізвище в доповіді не уточнюється):

Якщо задачу можна розв’язати і її легко перевірити, її розв’яже AI.

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

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

Приклад: юридична галузь

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

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

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

Довіра й контроль: як правильно ділити роботу між людьми та агентами

Для ефективної співпраці людини й агента важливі дві осі:

• Довіра (trust) — скільки роботи можна не перевіряти.
• Контроль (control) — наскільки ефективно людина може «вшити» свій досвід і судження в роботу агента.

Як підвищити довіру до агента

1. Зробити задачу більш верифікованою
2. У розробці:
   • дати агенту доступ до браузера;
   • використовувати TDD (спочатку тести, потім реалізація).

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

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

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

4. Декомпозувати задачу

Замість «написати контракт» — розбити роботу на підзадачі:

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

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

1. Встановити guardrails (обмеження)

Це спосіб підвищити довіру, обмеживши можливості агента:

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

Чим менше свободи для «дивних дій», тим легше довіряти системі.

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

Як підвищити контроль над агентом

Складну роботу агента можна уявити як дерево або DAG завдань:

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

1. Планування: корисно, але недостатньо

На етапі планування агент пропонує кроки: що дослідити, які пункти перевірити, як структурувати роботу. Людина може:

• скоригувати план;
• додати чи прибрати кроки;
• уточнити, на що звернути увагу.

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

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

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

2. Skills: «вшивання» людського досвіду в вузли роботи

Більш потужний підхід — skills (навички), тобто формалізовані способи виконання окремих підзадач. Наприклад:

• «як перевіряти пункт про конфіденційність»;
• «як враховувати специфічний пункт законодавства ЄС у розділі про розірвання договору».

Переваги skills:

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

Мінус очевидний: skills не покривають усе. Неможливо заздалегідь описати кожен можливий випадок.

3. Еліцитація: питати людину, але без «інфінітного чату»

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

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

Потім людина може:

• переглянути журнал;
• скасувати або скоригувати окремі рішення.

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

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

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

Чому чат — це тупик для складних агентів

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

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

Для реальної спільної роботи потрібні «високоширокосмугові» (high‑bandwidth) артефакти, які:

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

Приклади таких артефактів

1. Документ як спільний простір роботи

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

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

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

1. Табличний огляд (tabular review)

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

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

Людина отримує:

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

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

Мова — універсальний інтерфейс, але не єдиний для агентів

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

• ставити завдання;
• уточнювати вимоги;
• пояснювати контекст.

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

Агенти таких обмежень не мають:

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

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

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

Висновок

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

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

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

Source

Agents need more than a chat – Jacob Lauritzen, CTO Legora