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

Ось що мене змусило задуматися: керівники раптом одержимі вимірюванням продуктивності у найбуквальніших її формах. Ми говоримо про CTO, які кодують о 5 ранку, бо хочуть «відновити зв’язок» з базовим кодом, CEO, що відстежують витрати на використання інструментів ШІ до хвилини, і засновників стартапів, які буквально кажуть співробітникам, що вони «недостатньо наполегливі», якщо їхні взаємодії з Claude Code не досягають якоїсь довільної норми. Один CEO з компанії, що працює з ШІ, відкрито зізнається, що переглядає рахунки за використання ШІ, як фінансовий аудит — чим більше вони витрачають на інструменти ШІ, тим «краще» вони працюють. Це… багато.

Але тут стає цікаво. Існує величезна різниця між тим, що думають керівники, і тим, що насправді відбувається на місцях. Опитування показують, що понад 40% керівників вважають, що ШІ економить їм понад 8 годин на тиждень, тоді як 67% звичайних співробітників кажуть, що ШІ економить їм менше ніж 2 години або взагалі нічого. Дослідження UC Berkeley, яке вивчало організацію з 200 людьми, виявило ще більш показову річ: навіть при тому, що ШІ виконує купу роботи, фактичні робочі години все одно зростають. Люди не звільняються — вони стають ще більш тривожними щодо оптимізації кожної миті.

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

Також є проблема «розширення завдань», про яку ніхто справді не говорить. Коли нефахівці починають використовувати ШІ для генерації коду, інженери витрачають години на очищення напівзроблених реалізацій. Це фактично ускладнює їхнє навантаження, а не полегшує. До того ж з’являється дивна гібридна ситуація, коли межі між ролями розмиваються, і раптом пишеться більше коду ніж будь-коли — але чи є він справді цінним? Компанія Intuit повідомила про 30% приріст продуктивності у виробництві коду, але якщо більшість цього коду в кінцевому підсумку викидається або забувається, яка справжня вигода?

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

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