Запитайте власника маркетингового агентства на п’ять людей, юридичної фірми з двома партнерами чи невеликої архітектурної студії, що змінилося цього року, — і відповідь прилетить миттю: сьогодні всі делегують роботу тому, хто вміє відповісти. Чернетку брифу спершу показують чат-боту, а вже потім клієнту. Перше читання договору проганяють через модель, перш ніж його побачить помічник юриста. Грубий ескіз молодшого співробітника отримує другу думку від програми, яка «прочитала» більше будівельних норм, ніж будь-яка людина встигне за життя. Сам інструмент уже не найцікавіша частина цієї історії. Те, що й досі відпрацьовується — тихо, у тисячах невеликих практик, — це дисципліна користуватися ним правильно.
Інструмент, який робив новачків кращими
Найпереконливіші ранні докази прийшли не з ради директорів, а з кол-центру. Економісти Ерік Бріньольфссон, Даніель Лі та Ліндсі Реймонд простежили за 5,179 операторами служби підтримки в софтверній компанії, коли асистента на основі генеративного ШІ впровадили в одних командах раніше, ніж в інших. Головна цифра виглядала скромно: кількість вирішених звернень за годину зросла в середньому на 14 відсотків. А цифра під нею скромною не була зовсім. Новачки та низькокваліфіковані оператори покращили результат на 34 відсотки, тоді як найдосвідченіші майже не зрушили з місця. Інструмент, як з’ясували дослідники, поширював найкращі практики найздібніших працівників, стискаючи роки навчання на роботі до кількох тижнів для решти.
Подібна картина проявилася й серед офісних професіоналів, зайнятих значно буденнішою справою — письмом. Шеккед Ной і Вітні Чжан дали 453 маркетологам, грантрайтерам та HR-фахівцям з вищою освітою реальні робочі завдання з написання текстів, узяті з їхніх власних професій, а тоді випадковим чином надали половині з них доступ до ChatGPT. Середній час на завдання скоротився на 40 відсотків; якість тексту, оцінена наосліп, зросла на 18 відсотків. Виграш розподілився нерівномірно: слабші автори покращилися найбільше, а найсильніші не отримали майже нічого. Але показовішим виявилося те, що інструмент зробив із самою формою роботи: професіонали здебільшого перестали писати чернетки від руки й перенаправили зекономлений час на генерацію ідей та редагування. Машина писала. Людина перевіряла. Саме цей розподіл праці й виявляється суттю всієї історії.
Де фронтир стає зубчастим
Через два роки після початку буму друга хвиля досліджень перестала запитувати, чи допомагає ШІ, і почала з’ясовувати, де саме він допомагати перестає. Найпоказовішу відповідь дало дослідження 758 консультантів Boston Consulting Group, проведене командою з Harvard Business School, Wharton та MIT. Отримавши вісімнадцять реалістичних консультаційних завдань, консультанти з доступом до GPT-4 виконали на 12.2 відсотка більше завдань, працювали на 25.1 відсотка швидше й видавали роботу, оцінену більш ніж на 40 відсотків вище за якістю — але лише на завданнях, що потрапляли всередину того, що дослідники назвали «зубчастим фронтиром» ШІ: межі компетентності, яка поводиться не як пряма лінія, а радше як лінія узбережжя — щедра в одних затоках і підступна одразу за мисом.
Консультанти-люди самостійно, без допомоги ШІ, розв’язували задачу правильно у 84 відсотках випадків, але коли вони користувалися ШІ, результат погіршувався — правильну відповідь вони давали лише у 60–70 відсотках випадків.Ітан Моллік, про висновки щодо «зубчастого фронтиру»
Саме цей результат, можливо, найкорисніше речення в усій цій літературі для власника невеликої практики, адже воно перевертає інтуїцію, з якою більшість людей підходить до цих інструментів. Ризик — не в ентузіазмі. Ризик — у довірі не в тому місці. Ті самі дослідники знайшли два робочі способи керувати цим ризиком, які назвали «кентаврами» та «кіборгами». Кентаври проводять чітку межу — це моя частина, а це частина машини — і тримаються її. Кіборги змішують працю безперервно, дозволяючи моделі закінчувати за них речення й виправляючи її на ходу. Жодна з цих позицій не «доброчесніша» за іншу. Спільне для обох — і саме цього бракувало консультантам, які гірше впоралися із завданнями поза фронтиром, — це робоча теорія того, де саме проходить власна межа.
Впровадження — це не те саме, що довіра
Було б зручно, якби вирішенням було просто швидше впровадити інструмент. Дані свідчать про інше. У трьох рандомізованих дослідженнях за участю 4,867 розробників програмного забезпечення в Microsoft, Accenture та одному з виробників електроніки зі списку Fortune 100 доступ до GitHub Copilot підняв кількість виконаних щотижневих завдань у середньому на 26 відсотків — молодші розробники виграли 27–39 відсотків, старші — лише 8–13. Та через рік після впровадження рівень використання в усіх трьох компаніях усе ще становив лише близько 60 відсотків, попри те що інструмент був безкоштовним, швидким і доведено корисним. Дослідники також чесно визнали прогалину у власних даних: вони могли виміряти, скільки коду написано, але не те, чи був цей код якісним, — бо доступу до нього в них просто не було. Навіть у компаніях із формалізованим процесом інженерного рев’ю якість лишалася найважчим для перевірки параметром.
| Дослідження | Умови | Вибірка | Головний результат |
|---|---|---|---|
| Brynjolfsson, Li & Raymond, NBER (2023) | Оператори служби підтримки | 5,179 операторів | +14% середня продуктивність; +34% для новачків |
| Noy & Zhang, Science (2023) | Професійні завдання з написання текстів | 453 фахівці | −40% часу на завдання; +18% якості |
| Dell’Acqua et al., HBS/BCG (2023) | Консультаційні завдання в межах фронтиру | 758 консультантів | +12.2% виконаних завдань; +25.1% швидкості; >40% якості |
| Cui et al., Microsoft/Accenture/Fortune 100 (2025) | Розробка ПЗ, Copilot | 4,867 розробників | +26% виконаних завдань; ~60% використання через рік |
У невеликих практик немає відділу контролю якості, на який можна спертися. Немає комплаєнс-столу, який спіймає вигадане судове посилання до того, як воно потрапить у документ, немає другого читача, який помітить, що лист клієнту непомітно перебільшує результат. Процедуру доводиться винаходити самому власнику, свідомо, ще до того, як інструменту довірять щось, що побачить клієнт, — і наведені вище дослідження доволі точно підказують, що ця процедура має містити. Вона повинна визначати, завдання за завданням, які частини власної роботи практики потрапляють у межі її фронтиру, а які ні, бо ця межа специфічна для кожної сфери і наперед її ніхто не наносив на карту. Вона повинна зберігати етап людської правки на всьому, що залишає офіс, — так само як фахівці з дослідження Ноя і Чжан спрямовували зекономлений час на перевірку, а не відкладали його як вільний час. І вона повинна зберігати настороженість до бездоганної гладкості викладу, адже відповідь, яка звучить впевнено, — не те саме, що відповідь, яка правильна, а консультанти, які довірилися гладко сформульованій, але неправильній відповіді, впоралися гірше за тих, хто спирався лише на власне судження.
Що справді накопичується
Ніщо з цього не є аргументом проти делегування. Оператори підтримки, автори текстів і розробники, які добре користувалися цими інструментами, вирвалися вперед — і то з великим, стабільним відривом, — а практики, які взагалі не торкаються цієї технології, просто робитимуть менше, повільніше й дорожче в перерахунку на годину експертизи. Аргумент тут вужчий і для невеликого бізнесу практичніший: описаний вище виграш прийшов не від встановлення чат-бота. Він прийшов від працівника чи фірми, які виробили звичку перевіряти — розподіляючи працю, як кентавр, змішуючи її, як кіборг, або просто навчаючись методом проб і помилок, яким категоріям завдань можна довіряти машині без нагляду. Ця звичка формується довше, ніж купується підписка, — і саме тому вона діє за принципом складного відсотка. Практика, яка перші місяці роботи з новою моделлю витрачає на те, щоб нанести на карту власний зубчастий фронтир, усе ще користуватиметься цією картою ще довго після того, як саму модель замінить наступна.
