Швидкий розвиток генеративного штучного інтелекту не лише змінює інструменти, якими користуються компанії, а й формує зовсім нові професійні ролі. В одному з випусків подкасту 20VC with Harry Stebbings обговорюється поява принципово нового типу фахівця, для якого, ймовірно, буде створено сотні тисяч, а то й мільйони робочих місць у найближчі п’ять років.

Хто такий «оператор агентів»

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

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

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

Які навички потрібні новій ролі

Оператор агентів має бути помітно технічнішим за пересічного користувача AI-сервісів. Від нього очікується:

• Глибоке занурення в AI-середовище. Розуміння того, як працюють сучасні AI-агенти, їхні обмеження та можливості.
• Робота з MCP та CLI. Знання протоколів і інтерфейсів командного рядка (CLI), які використовуються для підключення агентів до різних систем і сервісів.
• Написання «skills». Уміння створювати та налаштовувати окремі навички (skills) для агентів — тобто описувати, що саме агент уміє робити, з якими даними працює, які кроки виконує.
• Робота з agents.md та подібними конфігураційними файлами. Це документація й конфігурація, яка визначає поведінку агентів, їхні ролі, доступи та сценарії використання.

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

Де працюватимуть оператори агентів

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

• Маркетинг. Налаштування агентів для аналізу аудиторії, автоматизації контенту, A/B‑тестів, роботи з рекламними кампаніями.
• Юридичні відділи. Автоматизація первинного аналізу документів, підготовка шаблонів, пошук релевантної практики.
• Операції. Оптимізація логістики, управління запасами, моніторинг процесів у реальному часі за допомогою агентів.
• Life sciences та дослідження. Пошук і структурування наукових публікацій, допомога в плануванні експериментів, аналіз даних.

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

Чи стане це повноцінною професією

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

Це означає, що:

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

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

Source

The future of job roles — 20VC with Harry Stebbings

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

Про це явище детально розповідає Гергелі Орош, колишній інженер Uber і Skyscanner та автор популярної розсилки The Pragmatic Engineer, у розмові на каналі AI Engineer. На прикладах Meta, Microsoft, Salesforce та Coinbase він показує, як великі компанії повторюють старі помилки з вимірюванням продуктивності — тільки тепер замість рядків коду рахують токени.

Що таке token maxing і як він працює всередині корпорацій

«Token maxing» — це неформальний термін для практики, коли співробітники свідомо генерують великий обсяг AI‑запитів і відповідей, аби збільшити свій вимірюваний обсяг використання токенів усередині компанії.

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

У Meta та Microsoft існували внутрішні лідерборди, де відображався обсяг AI‑токенів, які «спалює» кожен інженер. У Salesforce пішли ще далі й задали цільовий мінімальний внутрішній AI‑спенд — близько 175 доларів на співробітника на місяць.

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

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

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

Коли в компанії з’являється публічний рейтинг використання AI, він майже гарантовано запускає гонку озброєнь. У Meta, за словами Ороша, на лідерборді почали з’являтися люди з «масивними» обсягами токенів, і це налякало багатьох інженерів. Ніхто не хотів опинитися в нижніх 25–50% списку — особливо на тлі хвиль скорочень у галузі.

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

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

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

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

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

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

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

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

У Coinbase базові зарплати окремих інженерів перебувають у діапазоні 300–400 тисяч доларів на рік до врахування опціонів. Сигнал був однозначним: ігнорувати AI — небезпечно для кар’єри. Після цього, за словами Ороша, «усі просто почали користуватися» інструментами, незалежно від того, наскільки вони реально допомагають у роботі.

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

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

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

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

Для Ороша історія з token maxing — це не щось принципово нове, а черговий виток давно знайомої проблеми. У 2010‑х роках на ринку з’явилися інструменти на кшталт Velocity чи Pluralsight Flow, які намагалися вимірювати продуктивність розробників за кількістю рядків коду, числом pull request’ів та іншими простими метриками.

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

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

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

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

Як лідери загнали себе в пастку метрик AI

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

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

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

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

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

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

Чому token maxing — симптом глибшої проблеми з AI‑продуктивністю

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

Реальність складніша. Навіть усередині компаній, які активно експериментують з AI, результати неоднорідні. У Meta невелике дослідження за участю близько 30 людей показало цікавий розрив між відчуттями та реальністю: учасники відчували себе приблизно на 20% продуктивнішими з AI‑інструментами, але за вимірюваними результатами в середньому були на 20% менш продуктивними.

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

Цю думку підтверджує й досвід розробників, які глибоко занурені в тему. Британський інженер і блогер Саймон Віллісон, відомий своєю роботою над Django та дослідженнями prompt‑ін’єкцій, після двох років активного використання AI‑інструментів описує їх як «річ, у якій дуже важко стати справді хорошим». Немає готового мануалу; доводиться постійно змінювати робочі процеси, тестувати нові підходи, вчитися на помилках.

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

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

Чого навчає історія token maxing компанії, які будують AI‑стратегію

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

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

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

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

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

Висновок: AI як інструмент чи як KPI

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

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

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

Джерело

How AI is changing Software Engineering: A Conversation with Gergely Orosz, @pragmaticengineer

Ринок технічних спеціальностей входить у період різкої перебудови. У розмові на Lenny’s Podcast пролунала жорстка, але конкретна оцінка: найближчі 12–24 місяці можуть стати часом одночасно масових скорочень і масового ж нового найму — але вже під зовсім інші вимоги, пов’язані з штучним інтелектом.

«Судний день» для старих структур

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

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

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

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

Масові скорочення та вибірковий найм

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

• компанія скорочує, умовно, 30 000 співробітників;
• і майже одразу ж наймає близько 8 000 нових.

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

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

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

Хто такі «AI‑first» спеціалісти

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

Це може означати:

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

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

Два складних роки попереду

Очікувана трансформація описується як «темна» і «складна». Причини очевидні:

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

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

Source

Are tech jobs safe in 2026? — Lenny’s Podcast

У квітні 2026 року дослідник Google DeepMind Сандер Ділеман, який понад десятиліття працює над генеративними медіамоделями на кшталт Veo та Nano Banana, публічно розклав по поличках механіку дифузійних моделей для зображень і відео. На відміну від автогресивних підходів, що домінують у мовних моделях, сучасні системи генерації візуального контенту майже повсюдно спираються саме на дифузію.

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

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

У серці дифузійних моделей — чітко визначена пара процесів: прямий (forward) і зворотний (reverse). Перший — це контрольоване псування даних, другий — навчена спроба це псування скасувати.

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

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

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

Як шум руйнує зображення: спершу деталі, потім структура

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

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

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

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

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

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

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

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

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

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

Багатокроковий семплінг: рух за локальними підказками

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

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

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

Такий підхід має кілька наслідків.

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

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

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

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

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

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

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

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

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

Нелінійна траєкторія в просторі зображень і латентів

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

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

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

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

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

Висновки: дифузія як керований рух від шуму до структури

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

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

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

Джерело

Building Generative Image & Video models at Scale – Sander Dieleman (Veo and Nano Banana)

У корпоративних проєктах зі штучним інтелектом дедалі частіше постає питання: яку архітектуру обрати — агентну (ADK) чи retrieval-орієнтовану (RAG)? Канал IBM Technology пропонує просту ментальну модель, яка допомагає розкласти це рішення «по поличках» і зрозуміти, коли потрібен AI, що діє, а коли — AI, що точно знає.

Дві «алеї» AI: дія проти знання

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

З AI-системами ситуація аналогічна:

• ADK (Agent Development Kit) — це «алея інструментів». Архітектура для агентів, які виконують багатокрокові завдання, запускають робочі процеси, користуються інструментами й ухвалюють рішення.
• RAG (Retrieval-Augmented Generation) — це «алея довідників». Архітектура, де модель підключається до документів, витягує потрібні фрагменти й на їх основі формує відповідь.

Ключове запитання, яке спрощує вибір:
Ваш AI має діяти чи пригадувати?

• Якщо завдання звучить як «зроби щось для мене» — це зона ADK.
• Якщо завдання звучить як «розкажи щось на основі моїх даних» — це зона RAG.

Коли обирати ADK: AI як виконавець процедур

ADK-фреймворки будуються навколо дій і міркування. Вони підходять там, де:

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

Характерні риси ADK

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

Типові сценарії для ADK

ADK доцільний, коли AI має робити роботу, а не шукати факти:

• Онбординг і HR/IT-асистенти: проведення нового співробітника через послідовність кроків, створення доступів, заповнення форм.
• Автоматизація робочих процесів: запуск і координація бізнес-процесів, ескалація задач, маршрутизація запитів.
• Генерація та трансформація контенту: написання чернеток, переформатування текстів, адаптація під різні канали.
• Заповнення форм і тріаж: збір даних, перевірка повноти, розподіл запитів між командами.

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

Коли обирати RAG: AI як точне джерело знань

RAG-архітектура зосереджена на знанні та точності. Вона потрібна там, де:

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

Що робить RAG

• Підключається до PDF, політик, регламентів, технічної документації, мануалів, баз знань.
• Витягує релевантні фрагменти перед генерацією відповіді.
• Дає змогу ставити різні типи запитань:
• «Де в документах згадується ця тема?»
• «Що саме сказано в цьому звіті?»
• «Стисло підсумуй відповідний розділ».

Типові сценарії для RAG

RAG доцільний, коли система має пам’ятати те, що людині утримати важко:

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

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

Гібридні системи: коли потрібні і дії, і знання

У реальних проєктах рідко обмежуються лише ADK або лише RAG. Найчастіше працюють гібридні архітектури, де:

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

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

Де гібрид особливо корисний

• Юридичні та інженерні копілоти: агент веде користувача через процес аналізу, а RAG забезпечує доступ до норм, стандартів, технічних специфікацій.
• Медичні асистенти: поєднання клінічних протоколів і логіки маршрутизації пацієнта.
• Ентерпрайз-копілоти для задач: AI координує роботу, приймає рішення й одночасно звертається до внутрішніх баз знань.

Якщо узагальнити:

• Контент-генерація, мало пошуку, багато міркування → перевага за ADK.
• Внутрішній пошук знань, відповіді повністю залежать від документів → перевага за RAG.
• Доменно-специфічні копілоти, глибокий пошук + складне міркування → гібрид ADK + RAG.

Як поставити собі правильне запитання

Повертаючись до метафори будівельного магазину:

• ADK — це інструменти: вони виконують кроки, будують, діють.
• RAG — це довідники: вони дають інформацію й «заземлюють» роботу у фактах.

Більшість успішних AI-проєктів використовують обидві «алеї»: інструменти — щоб будувати, і довідники — щоб будувати правильно.

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

Source

ADK vs RAG: How to Choose the Right AI Stack — IBM Technology

OpenAI представила IMAGen 2.0 (також згадується як Images 2.0 або GPT Images 2) — нове покоління моделі для створення зображень, інтегроване в ChatGPT та доступне через API. У розмові з командою дослідників OpenAI генеральний директор Сем Альтман порівняв стрибок від попередньої версії до IMAGen 2.0 з переходом «від GPT‑3 одразу до GPT‑5». Усередині компанії цю зміну описують ще радикальніше: якщо ранні системи були «печерними малюнками» й «античним мистецтвом», то IMAGen 2.0 — це вже «Ренесанс» у генерації зображень.

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

Від «вау‑картинок» до продакшн‑візуалів: що саме змінилося

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

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

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

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

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

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

Модель, що «думає»: як IMAGen 2.0 виходить за межі простого промптингу

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

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

Друга — «thinking»‑режим, доступний лише платним користувачам через окремий тумблер «thinking mode». У цьому режимі модель:

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

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

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

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

Текст без помилок і дизайн без хаосу: як IMAGen 2.0 працює з типографікою

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

У IMAGen 2.0 ця проблема, за оцінкою дослідників, практично знята. Вони говорять, що:

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

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

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

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

Від манґи до гардероба: як «мисляча» модель працює з послідовністю та контекстом

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

У режимі «thinking» IMAGen 2.0 здатна:

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

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

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

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

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

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

2K‑роздільна здатність і «натуральність» як новий стандарт

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

Окремий акцент команда робить на «натуральності» зображень. Дослідники показують приклади, де модель відтворює фотографії з характерними «недосконалостями»: зернистістю, специфічним освітленням, дрібними артефактами, притаманними, наприклад, зйомці на «одноразову камеру» чи смартфон. Достатньо додати до промпту слова на кшталт «photorealistic», «professional photography», «shot on iPhone» або «disposable camera», і модель адаптує стиль відповідно.

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

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

Миттєва доступність: ChatGPT і API з першого дня

Стратегічно важливий крок OpenAI — зробити IMAGen 2.0 доступною одразу в двох ключових каналах: у ChatGPT і через API. Це означає, що:

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

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

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

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

Висновок: «Ренесанс» як зміна ролі зображень в AI‑екосистемі

Метафора «від печерних малюнків до Ренесансу» у випадку IMAGen 2.0 описує не лише стрибок у якості картинки. Вона відображає зміну ролі зображень у ширшій AI‑екосистемі.

Раніше генерація зображень була переважно інструментом для натхнення, експериментів, візуальних жартів. Тепер OpenAI позиціонує IMAGen 2.0 як модель, що:

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

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

Джерело

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

Штучний інтелект стрімко змінює ринок праці, і все більше розробників замислюються про перехід в AI-інженерію. Канал Marina Wyss – AI & Machine Learning пропонує практичну дорожню карту для тих, хто вже працює в розробці ПЗ й хоче перекваліфікуватися без повернення в університет і багаторічних теоретичних курсів.

Чому не потрібен новий диплом — і чому «це просто інший API» теж помилка

Серед розробників умовно є дві крайні позиції щодо AI-інженерії:

• «Це майже неможливо: треба вчити трансформери, PyTorch, вищу математику і йти в магістратуру».
• «Я вже все вмію: це ж просто виклик іншого API».

Обидві позиції хибні — і можуть дорого коштувати кар’єрі.

AI-інженер у 2026 році працює переважно на прикладному рівні: будує застосунки поверх foundation-моделей. Щоденні задачі включають:

• роботу з AI API;
• проєктування ефективних промптів;
• побудову RAG-пайплайнів (retrieval-augmented generation);
• створення агентів, які використовують інструменти й приймають рішення;
• розробку фреймворків для оцінки якості AI-функцій;
• за потреби — тонке донавчання моделей під конкретні кейси.

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

Розробники вже вміють:

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

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

Нові компетенції: що доведеться вивчити розробнику

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

1. Базове розуміння LLM

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

• що таке токени та контекстне вікно;
• як працюють параметри на кшталт temperature;
• чому моделі «галюцинують»;
• чим відрізняється fine-tuning від простої зміни промптів.

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

2. Промпт-інженерія як дисципліна

Промпт-інженерія — це не просто «написати гарний текстовий запит». Важливі елементи:

• структуровані виходи (JSON, схеми);
• різні підходи до reasoning (ланцюжки міркувань, поетапні інструкції тощо);
• few-shot патерни (приклади в промпті);
• системні промпти й рольові інструкції;
• експерименти з варіантами промптів і аналіз впливу змін.

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

3. RAG: як змусити модель працювати з вашими даними

Retrieval-augmented generation — ключовий патерн для бізнес-застосунків, де модель має відповідати, спираючись на конкретні документи чи бази знань. Тут потрібні:

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

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

4. Агентні патерни та безпечний tool use

AI-агенти — це системи, які:

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

Потрібно вміти:

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

Головний «невидимий» навик: як оцінювати AI-системи

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

У звичайних системах:

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

У LLM-систем:

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

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

Ключові моменти:

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

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

Практична дорожня карта: як вчитися й будувати портфоліо

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

Тиждень 1: одразу будувати

Важливо не відкладати практику:

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

Можна використовувати прямі виклики LLM API або фреймворки на кшталт LangChain чи LlamaIndex.

Тижні 2–4: вчитися «по ходу болю»

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

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

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

Місяць 2: амбітніший проєкт

На другому місяці варто:

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

Це вже основа для портфоліо AI-проєктів.

Далі: позиціонування себе як AI-інженера

Наступний крок — зробити свої навички видимими:

• писати про те, що будуєте (блоги, пости, технічні нотатки);
• контриб’ютити в open source-проєкти в AI-сфері;
• обговорити з менеджером можливість додати AI-фічі в поточний продукт.

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

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

Джерело

How to Transition from Software Engineering to AI Engineering — Marina Wyss – AI & Machine Learning

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

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

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

Цифрові зображення й відео природно задаються як ґратки пікселів: двовимірна сітка для зображення, тривимірна (час + 2D) для відео. На ранніх етапах розвитку дифузійних моделей дослідники справді тренували їх безпосередньо на пікселях — і це працювало краще, ніж багато хто очікував. Але щойно зросли роздільність, тривалість і цільова якість, стало очевидно: пряме моделювання пікселів не масштабується.

Проблема в сирих тензорах. Візьмімо 30 секунд відео у 1080p при 30 кадрах за секунду. Це сотні кадрів, кожен — масив розміром приблизно 1920×1080×3. Якщо зібрати це в один тензор для тренування, обсяг даних для одного прикладу обчислюється гігабайтами. Для великих батчів, необхідних для стабільного навчання, це просто не поміщається в пам’ять навіть великих GPU-кластерів.

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

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

Автоенкодер як «вхідні ворота» до латентного простору

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

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

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

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

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

Приклад Stable Diffusion: як виглядає латентний тензор

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

Розглянемо конкретні числа. Маємо RGB-зображення 256×256. У піксельному вигляді це тензор розміром 256×256×3. Після проходження через енкодер автоенкодера воно перетворюється на латентний тензор приблизно 32×32 з більшою кількістю каналів.

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

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

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

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

Чому латентні компресори «примітивніші» за JPEG і H.265 — і це добре

На перший погляд може здатися, що автоенкодер — це просто ще один кодек. Але між ним і стандартами на кшталт JPEG чи H.265 є принципова різниця в цілях.

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

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

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

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

У результаті ми отримуємо представлення, яке:

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

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

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

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

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

На практиці перехід до латентного простору для відео дозволяє зменшити розмір тензорів приблизно на два порядки. Тобто замість умовних 100 одиниць пам’яті для сирих пікселів модель працює з 1–2 одиницями для латентів. Це не просто оптимізація, а різниця між «можна тренувати» і «неможливо навіть завантажити один приклад у пам’ять».

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

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

Латентний простір як фундамент для дифузійних моделей нового покоління

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

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

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

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

Висновок

Перехід від сирих пікселів до латентних просторів став одним із ключових кроків у розвитку сучасних генеративних моделей зображень і відео. Навчені автоенкодери створюють стиснені, але структуровані представлення, які зберігають 2D- або 3D-ґратку, абстрагують дрібні текстури, але не семантику, і дозволяють дифузійним моделям працювати ефективно й масштабовано.

Приклад Stable Diffusion показує, як 256×256 RGB-зображення може бути перетворене на 32×32 латентну ґратку з додатковими каналами, зберігаючи топологію сцени. Для відео використання латентів дає скорочення розміру тензорів до двох порядків, що робить можливим навчання й генерацію на практичних апаратних ресурсах.

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

Джерело

YouTube: Building Generative Image & Video models at Scale – Sander Dieleman (Veo and Nano Banana)

Платформи на кшталт OpenClaw відкрили шлях до складних автономних AI‑агентів, але їхнє самостійне розгортання зазвичай вимагає API‑ключів, конфігурацій, інфраструктури та чимало часу. MiniMax пропонує іншу модель: Maxclaw — це їхній хостинговий сервіс на базі OpenClaw, який працює на власній моделі M2.7 і одразу постачається з інструментами для веб‑пошуку, генерації зображень і відео, виконання коду та інтеграціями з Telegram, Slack, мобільними й десктопними застосунками.

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

Від фіксованої підписки до токенів: як MiniMax продає доступ до агентів

MiniMax пропонує два базові підходи до оплати: пряма підписка на агентів і універсальний токен‑план. Обидва варіанти працюють із Maxclaw, але орієнтовані на різні сценарії використання.

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

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

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

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

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

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

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

У межах токен‑плану MiniMax розподіляє квоти запитів між кількома напрямами:

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

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

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

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

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

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

Один токен‑план — кілька агентів: як працює зв’язка Maxclaw і MiniMax Plus

Окремий пласт — це інтеграція Maxclaw із токен‑планами через API‑ключ. MiniMax дозволяє «підв’язати» Maxclaw до існуючого токен‑абонемента, зокрема до Plus‑плану, так, щоб усі агенти й завдання використовували спільний пул токенів.

Технічно це виглядає просто: у Maxclaw є опція «підключитися до MiniMax coding / token plan». Користувач генерує API‑ключ у своєму акаунті MiniMax, вставляє його в інтерфейс Maxclaw — і з цього моменту агент працює не на окремій «агентній» підписці, а безпосередньо на токен‑балансі.

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

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

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

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

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

Практична вартість: повноцінний асистент за «кілька доларів»

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

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

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

Фактично це демонструє, що токен‑план може одночасно:

покривати особисті експерименти власника акаунта з Maxclaw і іншими сервісами;

живити кілька демонстраційних агентів;

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

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

Чому модель «один план — багато можливостей» може стати стандартом

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

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

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

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

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

Висновок: Maxclaw як сервіс, а не як інфраструктурний проєкт

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

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

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

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

Джерело

YouTube: I Built an AI Agent in 20 Minutes – Here’s How

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

Офіс як прискорювач кар’єрного росту

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

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

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

Як середовище впливає на лояльність і мотивацію

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

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

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

Сила кросфункціональної взаємодії

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

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

• «Нам не подобається ця кнопка»
• «Було б добре, якби це працювало інакше»

Такі сигнали не потрібно збирати через формальні звіти чи асинхронні тікети — вони стають частиною щоденного фону. Це:

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

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

Гібрид і ремоут: чому до них ставляться скептично

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

Ключовий закид до ремоуту — втрата ефекту присутності:

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

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

Джерело

The best young people want to be in office — 20VC with Harry Stebbings

У спільному воркшопі каналу AI Engineer Луї-Франсуа Бушар, Самріді Вайд та Пол Іуштін показують, як побудувати повноцінну систему для глибоких досліджень і технічного письма на базі LLM. Після гнучкого дослідницького агента, який збирає й структурує факти, у центрі уваги опиняється інша, набагато жорсткіша частина — конвеєр написання коротких технічних текстів на кшталт LinkedIn‑постів. Саме ця друга половина системи, разом із засобами спостереження, трасування та оцінки якості, визначає, чи перетвориться сирий артефакт дослідження на справді корисний контент, а не черговий шматок «AI‑slop».

Чому технічне письмо потребує іншої архітектури, ніж дослідження

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

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

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

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

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

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

Обмежений воркфлоу для LinkedIn‑рівня: як влаштований «писець»

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

Перший принцип — повна залежність від артефакту дослідження. Вихід дослідницького агента — це Markdown‑файл research.md, де вже зібрані, структуровані та процитовані джерела. Саме цей файл стає головним (і по суті єдиним) вхідним контекстом для письменницького воркфлоу. Модель не ходить у веб, не викликає додаткових інструментів, не «домислює» відсутні факти. Вона працює з тим, що є.

Другий принцип — жорсткі інструкції. Воркфлоу задає:

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

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

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

Проста послідовність замість важкої оркестрації

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

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

Такий підхід має кілька наслідків.

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

По‑друге, чітко розділяються відповідальності. Дослідницький агент відповідає за повноту й якість фактів, письменницький воркфлоу — за форму й подачу. Якщо виникає проблема з точністю, дивляться на research.md. Якщо проблема зі стилем або структурою — на конвеєр письма.

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

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

Як система бореться з «AI‑slop»: контроль, петлі рев’ю та LLM‑суддя

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

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

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

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

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

Такий LLM‑суддя дозволяє:

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

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

Спостережуваність і трасування: навіщо Opik у конвеєрі письма

Ще один важливий шар — спостережуваність. Щоб розуміти, як поводяться і дослідницький агент, і письменницький воркфлоу, у проєкт інтегровано Opik — платформу для трасування й аналізу LLM‑запусків.

Opik дозволяє:

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

Для конвеєра письма це особливо важливо. Якщо LLM‑суддя показує падіння F1‑міри, а користувачі скаржаться на якість постів, без трасування складно зрозуміти, де саме все пішло не так: на етапі дослідження, при формуванні research.md чи вже в самому воркфлоу письма.

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

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

Витоки системи: автоматизація внутрішнього конвеєра Towards AI

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

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

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

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

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

Інфраструктура під капотом: Python, uv і Gitingest для GitHub‑контенту

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

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

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

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

LLM‑суддя, датасети й F1: як вимірюють якість конвеєра

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

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

Цей підхід дозволяє:

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

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

Висновок: технічне письмо як інженерна задача, а не побічний продукт LLM

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

Розділення на гнучкий дослідницький агент і жорстко обмежений воркфлоу письма, послідовний запуск через простий скрипт, явний артефакт research.md, інтеграція спостережуваності через Opik, використання LLM‑судді й F1‑метрик, інфраструктура на Python з Gitingest для роботи з GitHub — усе це елементи однієї картини. Вони показують, що якісний AI‑контент — це результат продуманої архітектури, а не просто «кращої моделі».

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

Джерело

Full Workshop: Build Your Own Deep Research Agents – Louis-François Bouchard, Paul Iusztin, Samridhi

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

Генерація юридичного контенту спростилася, але це лише половина процесу

Сучасні AI‑інструменти дозволяють будь-кому за лічені хвилини створити:

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

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

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

Справжнє вузьке місце — не контент, а кількість кваліфікованих юристів

Коли «кожен відчуває себе юристом» завдяки AI, обсяг юридичних документів у обігу різко зростає. Але:

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

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

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

Чому це може призвести до зростання попиту на юристів

Поєднання двох трендів — масової генерації текстів і незмінних вимог правової системи — логічно веде до зростання попиту на юридичну експертизу:

1. Більше документів — більше перевірок. Кожен AI‑згенерований контракт чи меморандум, який клієнт хоче реально використати, потребує професійного рев’ю.
2. Зростання ризиків. Помилки в автоматично створених документах можуть коштувати бізнесу дорого. Це стимулює компанії частіше звертатися до юристів.
3. Формалізовані вимоги системи. Судові та регуляторні органи не приймають документи лише тому, що їх «написав AI». Важить відповідальність конкретного юриста або фірми.
4. Розширення доступу до права. Коли створити базовий документ стає легко, до юридичних інструментів звертаються ті, хто раніше взагалі не йшов до юристів. Це відкриває нові сегменти попиту.

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

Розбіжність із домінуючим на ринку поглядом

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

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

Джерело

We will have MORE lawyers in 5 years not LESS — 20VC with Harry Stebbings