Звільнення продовжаться, доки ми не навчимося використовувати ШІ
Автор оригіналу: Арнав Гупта, інженер з ІІ
Баоюй, AI-аналітик

У кабінеті вищого керівництва нашої компанії лежить список звільнень на 8000 осіб. У мене 10% шансів опинитися в цьому списку. Через кілька днів, 20 травня, я дізнаюсь свою долю.

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

Зараз існує велика кількість статей, які суперечать: чи ця нова хвиля звільнень (яку більшість вважають початою зі звільнення Джеком Дорсі 40% працівників Square) є результатом штучного інтелекту, чи це просто «AI-washing» (коли компанії використовують прийняття ШІ як прикриття для інших комерційних невдач або справжніх причин звільнень).

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

Високо оцінений «AI-продуктивність» та важко виявлені докази

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

Зокрема у технологічних компаніях очевидним є ракетоподібний стрибок у використанні ШІ. Навіть ті найбільш консервативні компанії, які обмежують бюджет на ШІ та не надають працівникам інструменти ШІ, не можуть заперечувати, що певна частина роботи фактично виконується ШІ — навіть якщо працівники лише таємно використовують Gemini або Copilot у Google або Microsoft Office для редагування документів.

Щодо компаній, які мають більше дальновидності й погрузилися в океан AI-токенів (токен — базова одиниця обробки тексту AI-моделлю, яку компанії зазвичай оплачують за кількістю спожитих токенів під час використання великих мовних моделей), таких як Uber або Shopify (я тут не включаю такі компанії, як Meta або Microsoft, які розробляють власні великі мовні моделі, ніж Vercel або Cloudflare, які активно будують AI-інфраструктуру; мова лише про чистих «користувачів»), їхнє використання AI дійсно вийшло з-під контролю.

Ми вже не дивуємося: від того, що 90–100% коду генерується штучним інтелектом, до збільшення кількості кодових рев’ю (PRs/diffs) на тиждень у 2–5 разів, до витрачання річного бюджету на штучний інтелект у сотні мільйонів доларів за кілька місяців.

Однак такі технологічні коментатори та інвестори, як Ед Зітрон, Вілл Манідіс, Гарі Маркус та Майкл Бері, обов’язково зададуть вам гострий, суттєвий питання: якщо це так, чому дохід цих компаній не збільшився в 2–5 разів? Чому їхні додатки виглядають майже так само, як і шість місяців тому? Якщо ШІ справді так продуктивний, що саме вони виробили за допомогою ШІ? Якщо вони написали в 5 разів більше коду, а кінцеві користувачі не помітили жодної різниці, то в чому сенс цього коду? Це надзвичайно гостре та логічне питання.

Вхід, вихід та результат

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

Вони пояснять вам суть бізнесу, яку всі розуміють, але завжди забувають:

Код — це лише інвестиція.

Функціональність — це результат.

Користувачі охоче платять за ваш продукт — ось що є результатом.

Штучний інтелект (або, принаймні, такий продукт, як Claude Enterprise) суттєво є програмним сервісом для бізнесу (B2B SaaS). Ви помітите, що ціноутворення та маркетинг SaaS-продуктів варіюються. Якщо продукт може безпосередньо змінити «результат», вони зазвичай беруть відсоток від самого «результату». Уявіть таку продажну пропозицію: «Наш інструмент дозволяє вам швидше отримувати ліди на 36%. Почніть використовувати зараз, сплативши лише 5% від обсягу продажів».

Це точно вб’є клієнтів. За інших рівних умов, якщо раніше вам потрібно було 100 днів, щоб укласти 100 угод, зараз вам знадобиться лише 63 дні. Зекономлені 36 днів (якщо я правильно порахував) дозволять вам укласти ще 57 угод! Тобто ваш потенційний обсяг продажів зросте на 57%. Будь-хто буде радий віддати 5% від своєї комісії, щоб отримати додатковий дохід на 57%. А якщо ви не використовуватимете цей продукт, вам не потрібно платити ні копійки.

Ви, мабуть, вже вгадали, про що я хочу сказати — ціноутворення Claude за споживання Tokenів працює зовсім інакше. Якщо ваші інженери-програмісти залежать від програмування з використанням Claude (я тільки що зрозумів, що їхні англійські скорочення обидва — «cc»), і вони генерують по 100 мільйонів Tokenів щодня, то вам доведеться витрачати по 100 доларів США на кожного інженера щодня.

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

Хоча деякий код пізніше викликав серйозну системну аварію (SEV) (SEV означає Severity — термін, який технологічні компанії використовують для позначення серйозних онлайн-інцидентів, що призводять до переривання сервісу), і його було терміново відкотено;

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

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

Що саме перешкоджає нам!

Раніше, коли генеральний директор або продукт-менеджер (PM) хотіли зробити 10 речей, розробницька команда завжди казала, що зможуть впоратися лише з двома найважливішими, а решту 8 — не встигнуть. Чому? Бо написання коду — це не гра в дітей, і розробка складного, працюючого програмного забезпечення вимагає величезних зусиль і часу.

Так… але зараз код майже безкоштовний. Чому ми все ще не зробили ті решті 8 речей?

Є два відповіді: одна не подобається генеральному директору та продукт-менеджеру; інша — менеджерам середньої ланки та досвідченим співробітникам.

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

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

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

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

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

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

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

Що саме може вирішити скорочення персоналу?

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

З якою метою проводять скорочення? За моєю гіпотезою, якщо ШІ насправді не замінив 30% працівників по одному (цього, мабуть, всі згодні — хоча в багатьох завданнях він перевершує молодших офісних працівників, у інших — поступається людині; він абсолютно не є деталлю, яку можна просто витягнути й вставити, і тим більше не може безпосередньо замінити 10%, 20% чи навіть 30% людей у компанії).

Тоді де логіка скорочення штату? Бо воно миттєво вирішує дві очевидні короткострокові проблеми.

Це насправді найпростіша арифметична задача на грошові потоки. Очевидно, що якщо ваші інженери, залежні від Claude, щодня витрачають по 100 доларів США на Claude (тобто 2500 доларів США на місяць і 30 000 доларів США на рік), ця сума в Індії відповідає повній зарплаті інженера-програміста (SDE); в Європі — наполовину зарплати SDE; в США — чверті зарплати SDE.

Якщо зробити найпростіший і найгрубіший розрахунок: припустимо, у компанії з плоскою структурою всі співробітники — це SDE. Щоб зберегти загальні витрати на зарплати (включаючи витрати на купівлю токенів), вам потрібно звільнити 50% (Індія), 33% (Європа) або 20% (США) співробітників.

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

Якби ми справді навчилися використовувати ШІ — зрозуміли, як перетворити збільшення витрат на 50% на збільшення доходів на 50%, — нам не довелося б робити цей крок. Але оскільки ви ще не навчилися, деяким з вас доведеться піти, щоб звільнити кошти для оплати праці Anthropic.

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

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

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

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

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

Це звільнення через ІІ, навіть якщо ІІ прямо не замінило вашу посаду

Чи ваш номер працівника був замінений новим екземпляром Claude, що працює на віртуальній машині? Ми всі знаємо, що це не так.

Тим не менш, чи не було в компанії багато робочих процесів, які раніше вимагали, щоб ви набирали клавіші та клацали мишкою у VS Code, Figma, Canva чи Google Docs, а зараз перетворилися на те, що інші (ті, хто раніше залежав від ваших результатів) просто кричать на великі мовні моделі, вводячи підказки, і вже не хочуть звертатися до вас за допомогою? Це також невід’ємна правда.

Чи ці звільнення справді є «AI-відмиванням»? Іншими словами — чи існували в компанії заздалегідь різні фундаментальні проблеми, що не мають відношення до ШІ (наприклад, надмірний набір персоналу, зниження прибутку, тиск з боку конкуренції, погані бізнес-рішення), і зараз вони просто використовують ШІ як «підставу» для звільнень? Так, це з певної точки зору має сенс.

Ви також можете помітити, що якщо зібрати всі листи про звільнення, відправлені цими CEO за цей період, ви навіть зможете подумати, чи не створили вони чат, де разом обговорюють і пишуть ці листи. «AI-натуральні групи», «менеджери, що пишуть код», «збільшення діапазону управління», «плоска структура», «керівництво командами AI-агентів»… Ви побачите, що ці нові терміни однаково з’являються в кожному листі. Наче вони надали GPT однаковий промт.

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

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

До того як ми справді зрозуміємо, як ШІ реальний впливає на зростання світового ВВП, щоб покрити щорічні витрати на токени в розмірі 70 мільярдів доларів США (загальний корпоративний дохід OpenAI та Anthropic), компанії змушені «перекладати кошти» за рахунок зменшення зарплат працівників.

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

За 15 днів я дізнаюсь свою долю. Але незалежно від результату, я вже розумію причину. Навіть якби я був тим, хто приймав рішення в тій просторій кабінеті CEO в кутку, я не впевнений, що зробив би краще — ймовірно, я б зробив таку ж саму вибір, як і інші CEO, що створювали групи.

Оригінальне посилання

Натисніть, щоб дізнатися про вакансії в律動BlockBeats

Вступайте до офіційного спільноти律动 BlockBeats:

Телеграм-канал з підпискою: https://t.me/theblockbeats

Telegram-чат: https://t.me/BlockBeats_App

Офіційний аккаунт Twitter: https://twitter.com/BlockBeatsAsia