Коли консультантка з ШІ та колишня керівниця напрямів AI в IBM та AWS Елі Міллер прокидається вранці, її агенти вже кілька годин працюють замість неї. Вона входить до переліку TIME100 AI, консультує великі корпорації та фонди, і водночас демонструє дуже особистий експеримент: що відбувається з продуктивністю, коли штучний інтелект стає не просто «чатиком», а повноцінним робочим середовищем.
Її досвід показує: за два роки інтенсивного використання AI продуктивність зросла від удвічі до десятикратного рівня — залежно від завдання. Але разом із цим з’являється інша, менш приємна динаміка: всередині компаній формується новий клас «AI-суперкористувачів», які стрімко відриваються від колег. І проблема тут не в доступі до технологій, а в тому, як (і чи взагалі) організації діляться знаннями про те, як ці технології використовувати.
Від 20–30% до 2–10x: як змінилася сама природа продуктивності
Два роки тому типовий сценарій роботи з генеративним ШІ виглядав доволі лінійно. Користувач ставив запитання, отримував відповідь, далі самостійно брався за реальну роботу: переносив текст у документи, структурував, планував, виконував. ШІ був радше «розумною довідкою», ніж учасником процесу.
Міллер описує це як приблизно 20–30% приросту продуктивності. AI допомагав швидше дослідити тему, сформулювати чернетку, зібрати інформацію. Але ключові години — планування, виконання, координація — все одно залишалися на людині.
Перелом стався з появою так званого агентного AI. Замість одного чат-бота, який відповідає на запитання, користувач отримує систему з десятків агентів, здатних самостійно ініціювати завдання, ходити в інші сервіси, збирати дані, створювати документи, нагадувати, ранжувати, готувати зустрічі. Це вже не «підказка», а делегування реальної роботи.
У власному робочому сетапі Міллер бачить радикально іншу картину: залежно від типу задачі, AI дає їй від 2x до 10x приросту продуктивності порівняно з тим, як вона працювала два роки тому. Там, де раніше ШІ економив хвилини, тепер він забирає на себе години.
Ключова відмінність — у характері взаємодії. Якщо раніше користувач мав кожного разу «запускати» AI, формулювати запит, переносити результати, то тепер значна частина роботи відбувається без його участі. Система сама ініціює дії: збирає інформацію, готує дайджести, аналізує пошту, пропонує наступні кроки. Людина підключається вже на етапі прийняття рішень.
Саме це й створює ефект «зламаної години», про який Міллер говорить в ширшому контексті: одна й та сама одиниця часу для різних людей починає означати зовсім різний обсяг зробленого.
Коли агенти працюють, поки ви спите: як виглядає день AI-суперкористувача
Щоб зрозуміти масштаб розриву, варто подивитися на конкретні приклади. У Міллер — 36 проактивних робочих процесів і близько сотні агентів, які працюють на неї. Вони не чекають, поки вона зайде в чат і щось запитає. Вони заплановані, запускаються за розкладом, підключаються до календаря, пошти, сервісів на кшталт Fireflies чи Granola, і приносять результат у вигляді готових листів, брифінгів, нагадувань.
Один із показових сценаріїв — щоп’ятничний агент для пошти. Що він робить:
спершу проходиться по Gmail за останні п’ять днів,
відбирає листи, на які ще немає відповіді,
ранжує їх за терміновістю,
генерує чернетки відповідей,
додає опції делегування для членів команди,
ставить нагадування, якщо лист залишиться без реакції.
Результат — не просто «список непрочитаних», а структурований, пріоритизований план дій, де значна частина рутинної роботи вже виконана. Людині залишається переглянути, скоригувати, затвердити.
Інший щоденний сценарій — ранковий брифінг. Щоранку Міллер отримує лист, який включає:
огляд новин індустрії,
добірку подій у Нью-Йорку чи Сан-Франциско на день,
підготовку до зустрічей із календаря: хто учасники, що про них відомо, які питання варто підняти, які матеріали потрібні.
Якщо в брифінгу згадується важлива зустріч, достатньо відповісти листом із ключовим словом — і окремий агент запустить підготовку активів для цієї зустрічі: документів, презентацій, нотаток. Усе це працює на базі Claude Co-work, Claude Code та інших режимів доступу до моделі, які дозволяють не лише відповідати на запити, а й діяти: створювати Google Docs, працювати з локальними файлами, ходити в Gmail та інші сервіси через API.
Принципово важливо, що жоден із описаних процесів не вимагає від користувача писати код. Код, безумовно, є — він працює «за лаштунками», коли Claude підключається до Gmail чи Google Workspace, але користувач взаємодіє з цим через природну мову. Для запуску автоматизації достатньо описати свою проблему, а не знати синтаксис чи структуру API.
Це знімає технічний бар’єр, але створює інший: когнітивний. Потрібно вміти побачити власні патерни роботи, сформулювати, що саме варто делегувати, і перетворити це на стабільний робочий процес. І саме тут починає формуватися розрив між тими, хто це робить системно, і тими, хто обмежується епізодичними запитами в чат.
«Скаржитися AI» як нова навичка — і чому вона рідко стає командною практикою
Цікава деталь у підході Міллер — вона радить починати не з «ідеального процесу», а з банальних скарг. Замість того, щоб одразу проєктувати складний workflow, вона пропонує просто описати Claude свої щоденні роздратування: постійний стрес перед клієнтськими дзвінками, неможливість знайти час для глибокої роботи, вічні проблеми з погодою і парасолькою, розкидані між пристроями фото.
AI у відповідь не просто співчуває, а пропонує рішення у вигляді конкретних агентів і сценаріїв: проактивний блокувальник зустрічей, агент підготовки до клієнтських дзвінків, автоматичний менеджер фото, який створює папку в Google Drive, класифікує зображення, відправляє добірки команді.
Далі можна піти ще глибше: попросити Claude не лише запропонувати рішення, а й поставити серію уточнювальних запитань, щоб спроєктувати оптимальний процес. У Claude Code для цього є вбудований скіл «ask user questions», який буквально інтерв’ює користувача, поки не збере достатньо контексту, а потім переходить у режим планування і пропонує конкретну конфігурацію.
Це вже не просто «запит–відповідь», а спільне проєктування робочого середовища. І тут проявляється ще одна причина, чому AI-суперкористувачі так швидко вириваються вперед: вони не чекають готових шаблонів, а будують власні, заточені під свої задачі.
Однак у корпоративному контексті саме на цьому етапі часто виникає розрив. Ті, хто навчився «скаржитися AI» і перетворювати свої проблеми на автоматизовані рішення, рідко документують ці процеси так, щоб ними могли скористатися інші. Вони накопичують власні скіли, промпти, конфігурації, але зберігають їх у особистих акаунтах, приватних проектах, локальних файлах.
Формально це не завжди навмисне «приховування». Часто це просто відсутність звички чи вимоги ділитися. Але ефект від цього дуже схожий на класичне «захоплення знань» окремими експертами: організація залежить від кількох людей, які «вміють працювати з AI», а решта залишаються на рівні базових чат-запитів.
Коли знання не виходять за межі однієї голови: як народжується внутрішня цифрова нерівність
Міллер звертає увагу на те, що технологічний бар’єр для входу в AI-автоматизацію стрімко знижується. Не потрібно вміти програмувати, щоб налаштувати агента, який сканує вашу пошту, працює з календарем, створює документи чи аналізує файли. Claude та подібні платформи пропонують чотири основні режими доступу — від звичайного веб-додатку до бізнес-орієнтованого Co-work, більш технічного Code і розширення для браузера, яке може буквально керувати вікном Chrome.
Але попри це, у багатьох компаніях спостерігається одна й та сама картина: невелика група людей витискає з AI максимум, тоді як більшість використовує його на рівні «задати питання — отримати відповідь». Розрив між цими групами зростає не через різницю в інструментах, а через різницю в практиках.
Одна з ключових причин — брак системного обміну знаннями. AI-суперкористувачі будують десятки власних workflow, створюють скіли для типових задач, налаштовують інтеграції з поштою, календарем, документами. Але ці напрацювання часто залишаються:
у вигляді довгих промптів у їхніх особистих чатах,
у приватних проектах у Claude чи інших платформах,
у вигляді неформальних лайфхаків, які передаються усно або в закритих чатах.
У результаті організація як ціле не отримує повної віддачі від інвестицій у AI. Замість того, щоб один добре спроєктований скіл чи workflow масштабувався на десятки людей, він працює лише на одного. Кожен новий співробітник, який хоче автоматизувати свою роботу, змушений починати з нуля, повторюючи шлях, який хтось уже пройшов.
Це створює внутрішню «цифрову нерівність» нового типу. Раніше вона проявлялася в доступі до інструментів чи техніки. Тепер — у доступі до практик: хто знає, як перетворити щоденні скарги на стабільні AI-процеси, той отримує 2–10x продуктивності. Хто ні — залишається на рівні 20–30%.
Особливо гостро це відчувається в командах, де результати вимірюються кількістю і швидкістю: продажі, маркетинг, консалтинг, розробка контенту. Двоє людей можуть формально мати однакову посаду і однаковий робочий день, але один із них за рахунок AI-автоматизації фактично проживає «два–десять робочих днів» за час одного.
Чому компаніям важко масштабувати AI-успіх — і що з цим робити
На перший погляд, рішення здається очевидним: змусити AI-суперкористувачів документувати свої процеси, створити внутрішні бібліотеки скілів, шаблонів, workflow, проводити навчання. Але на практиці це виявляється набагато складнішим.
По-перше, самі суперкористувачі часто перевантажені. Вони вже працюють на межі, обслуговуючи не лише власні задачі, а й запити колег: «підкажи промпт», «налаштуй мені агента», «поясни, як це зробити». У них немає часу сісти й системно описати свої процеси так, щоб ними могли скористатися інші.
По-друге, у багатьох організаціях відсутня чітка структура для зберігання й поширення таких знань. Навіть якщо хтось створює корисний скіл чи workflow, не завжди зрозуміло, де його розмістити, як задокументувати, як оновлювати, хто відповідає за підтримку.
По-третє, є й людський фактор. У деяких випадках суперкористувачі свідомо чи несвідомо сприймають свої AI-налаштування як конкурентну перевагу. Вони бояться, що, поділившись усім, втратять унікальність або стануть менш незамінними. Навіть якщо це не артикулюється прямо, мотивація «тримати свої фішки при собі» може бути доволі сильною.
Усе це призводить до того, що розрив між AI-пауер-юзерами та рештою команди не просто зберігається, а й поглиблюється. Кожен новий скіл, кожен новий workflow, який суперкористувач створює для себе, ще більше збільшує його відрив.
Щоб розірвати це коло, компаніям доведеться ставитися до AI-налаштувань так само серйозно, як до коду чи дизайн-систем. Якщо програмний код зберігається в репозиторіях, а дизайн — у бібліотеках компонентів, то й AI-сценарії мають жити в спільних просторах: у вигляді документованих скілів, шаблонів, стартових документів, до яких мають доступ усі.
Важливо й те, що сучасні платформи на кшталт Claude вже підтримують концепцію «скілів» — багаторазових довгих промптів із конфігурацією, які працюють як інструменти в наборі. Міллер радить кожному користувачу починати хоча б із двох базових: скілу тону голосу та скілу бренд-гайдів. Якщо такі речі створюються не як особисті, а як командні артефакти, вони одразу зменшують розрив між тими, хто «вміє промптити», і тими, хто тільки починає.
Нова лінія поділу: не «з AI» і «без AI», а «з системою» і «без системи»
У публічних дискусіях про штучний інтелект часто звучить проста дихотомія: ті, хто користується AI, і ті, хто ні. Але досвід Міллер показує, що реальний поділ проходить інакше. Важливо не стільки «користуєшся ти AI чи ні», скільки «чи побудував ти навколо нього систему».
Людина, яка час від часу заходить у веб-версію Claude, щоб поставити питання й отримати відповідь, формально теж «користується AI». Але її приріст продуктивності обмежується тими самими 20–30%, які давали перші покоління чат-ботів.
Людина, яка:
перетворила свої щоденні скарги на стабільні workflow,
налаштувала проактивні агенти, що працюють за розкладом,
створила скіли для типових задач,
підключила AI до пошти, календаря, документів,
зробила так, щоб результати приходили у вигляді готових листів, брифінгів, чернеток,
отримує зовсім інший ефект — ті самі 2–10x, про які говорить Міллер.
У корпоративному вимірі це означає, що через рік-два в одній і тій самій команді можуть працювати люди, для яких година — це 60 хвилин умовно «аналогової» роботи, і люди, для яких година — це 60 хвилин, протягом яких паралельно працюють десятки агентів. І якщо організація не навчиться перетворювати індивідуальні AI-системи на колективні, ця прірва лише зростатиме.
Водночас саме зараз ще є вікно можливостей. Поки агентні системи тільки входять у мейнстрім, компанії можуть закласти правильні практики: вимагати документування workflow, створювати спільні бібліотеки скілів, заохочувати обмін кейсами, робити AI-налаштування частиною онбордингу. Інакше через кілька років доведеться не просто «наздоганяти AI», а долати внутрішню структурну нерівність, яка вже встигне закріпитися.
Висновок: продуктивність як функція культури, а не лише технології
Історія Елі Міллер — це не лише про особистий експеримент із сотнею агентів, які працюють, поки вона спить. Це про те, як швидко може змінитися саме поняття продуктивності, коли AI перестає бути інструментом «за запитом» і стає постійним, проактивним учасником робочого процесу.
Технологічно вхідний бар’єр ніколи не був таким низьким: щоб отримати 2–10-кратний приріст продуктивності в окремих задачах, не потрібно вміти програмувати. Достатньо навчитися чесно формулювати власні проблеми, дозволити AI ставити уточнювальні запитання і перетворювати це на стабільні workflow.
Але саме тут і народжується нова прірва: між тими, хто робить це системно, і тими, хто залишає AI на рівні «розумного пошуку». І поки компанії не навчаться перетворювати індивідуальні AI-напрацювання на колективний актив, розрив між AI-суперкористувачами та всіма іншими лише зростатиме.
У підсумку питання вже звучить не так: «Чи використовує ваша команда AI?», а так: «Чи перетворює вона індивідуальні AI-системи на спільну інфраструктуру знань і процесів?». Від відповіді на це залежить, чи стане AI джерелом колективного зростання, чи новою формою внутрішньої нерівності.