Пастка плато

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

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

Нова розділка

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

Вам не слід відчувати себе добре.

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

Обидві групи з’являються у ваших панелях як “приймачі штучного інтелекту”. Але одна з них знаходиться на прогресивній програмі тренування. Інша зупинилася на першому важелі, який відчувався зручним.

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

Як виглядає плато насправді

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

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

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

Конкурентний тиск реальний і прискорюється

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

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

Галузь програмного забезпечення в основному була створена, щоб допомогти людям у цифровій роботі: допомогти агентам підтримки бачити вхідні справи, відстежувати відповіді клієнтів, керувати робочими процесами. Тепер агенти штучного інтелекту витісняють весь робочий процес і разом з ним порушують основні платформи SaaS. Окрім того, з тим, як штучний інтелект стає все більш здатним щодня, ваші клієнти починають ставити питання: “Чи нам ще потрібно купувати це, або можемо ми побудувати це самі зараз?” Штучний інтелект почав скорочувати бар’єр між “купити” і “побудувати” для розширюваного набору випадків використання. Прилипання, яке раніше захищало ваш дохід, ослаблює кожен квартал.

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

Цитата, яка переформулювала все для мене

Я вже неодноразово чув це, від менеджерів продукту, які закатували рукави та кодували функції, від лідерів інженерних команд, які переробили провальні архітектури, в різних компаніях, у різних контекстах:

“Було легше для мене ітерувати це з моїми агентами, ніж з тим інженером.”

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

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

• Вони працюють “на одному рівні” зі своїми зацікавленими сторонами (менеджерами продукту, інженерними менеджерами тощо). Вони розуміють, що таке добре, тому вам не потрібно надмірно пояснювати їм речі. Адже якщо вони створюють стільки ж недорозумінь, скільки ваш агент кодування, агент завжди виграє цю битву. Він доступний миттєво, 24/7, і невтомний.
• Вони постійно покращують свої налаштування штучного інтелекту, тому коли ви передаєте їм щось, ви знаєте, що це буде зроблено не тільки добре (див. вище), але й досить швидко, щоб збігти з новим ритмом ринку.

Чому це проблема лідерства, а не індивідуальна

Це спокусительно позначити це як індивідуальну відповідальність інженера. “Тримайся або відставай.” Але якщо ви керуєте інженерною організацією, таке позначення звільняє вас від відповідальності.

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

Інженери, які продовжували тискати? Більшість з них самі мотивовані. Вони продовжили б незалежно. Але ви не можете укомплектувати інженерну організацію повністю самими мотивованими першопроходцями. Питання для лідерів таке: як ви рухаєте середину?

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

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

• Зменшіть зміну. “Прийняти штучний інтелект” надто абстрактно, щоб діяти. Цей спринт, закріпіть тестування агентів від початку до кінця, наступний спринт розгорніть його по всій організації, і так далі. Конкретні керувані кроки перемагають амбітні програми трансформації кожен раз, і маленькі перемоги мають значення.
• Переформуйте замовчування. Закодуйте процес верифікації у навичках штучного інтелекту та переконайтеся, що вони розгорнуті по всій вашій команді та по всіх їхніх агентах. Визначте свої робочі процеси та використовуйте інструменти, які підтримують це. Зробіть новий спосіб роботи шляхом найменшого опору, так щоб люди рухалися до нього, не маючи потреби боротися за це.

Вікно закривається

Ось частина, яка робить це терміновим, а не просто важливим.

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

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

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

Кожен інженерний лідер, з яким я розмовляю, розуміє це інтелектуально. Дуже мало хто змінив, як вони керують своїми командами у відповідь. Розрив між розумінням та діями сам по собі є種 плато.

Немає зручного темпу

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

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

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