Код став дешевшим. Але випуск продуктів, ні. Що показав звіт Karat

Я уважно стежу за дослідженнями про ШІ та продуктові команди, і минулого тижня мою увагу привернув новий звіт Karat, опублікований 8 жовтня. Я очікував побачити звичну історію про те, як «ШІ робить усіх у 10 разів продуктивнішими». Натомість натрапив на кілька цифр, які, на перший погляд, суперечать одна одній. І вони аж надто добре збігаються з тим, що я спостерігаю у власній роботі.

Три цифри, які не сходяться

Звіт про трансформацію робочої сили під впливом ШІ за 2026–2027 роки (2026–2027 AI Workforce Transformation Report) підготувала компанія The Harris Poll на основі опитування CIO, CTO та керівників інженерних команд.

Головна цифра, яку всі цитуватимуть: 82% технологічних керівників у США стверджують, що завдяки ШІ їхні компанії почали створювати більше продуктів і функцій.

Але варто прочитати наступний рядок, і картина змінюється:

• 82% повідомляють про збільшення кількості продуктів і функцій.
• 67% зазначають, що час виведення нових функцій на ринок зріс.
• 44% повідомляють про збільшення кількості помилок у коді. Більше результатів. Повільніша доставка. Більше помилок.

Це не революція продуктивності. Це проблема пропускної здатності процесу, замаскована під революцію.

Дешевий код означає більше коду, а не менше роботи

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

З кодом відбувається щось подібне.

90% технологічних керівників у США стверджують, що використовують ШІ для збільшення обсягів розробки, зберігаючи або розширюючи інженерні команди. Лише 10% використовують його, щоб підтримувати той самий обсяг роботи з меншою кількістю інженерів.

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

Але все це, як і раніше, потрібно перевіряти, тестувати, інтегрувати, документувати та підтримувати.

Вартість написання коду знизилася. Вартість усього, що відбувається навколо нього, зросла.

Вузьке місце змістилося на етапи до та після написання коду

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

Тепер, коли ШІ суттєво скорочує час на написання коду, справжні обмеження стають очевидними.

Karat називає їх прямо: інженери витрачають більше часу на перевірку результатів ШІ, уточнення вимог, проєктування систем, тестування та управління ризиками, пов'язаними зі стрімким зростанням обсягів коду.

Інакше кажучи, робота змістилася на обидва кінці процесу.

У попередній версії звіту це підтверджується цифрами. Керівники зазначають, що їхні інженери стали витрачати більше часу на перевірку результатів ШІ (72%), роботу з вимогами (60%), архітектуру (60%) і тестування (54%).

Написання коду — єдина діяльність, для якої більше респондентів повідомили про скорочення витрат часу (46%), ніж про їх зростання (39%).

1. До написання коду: визначити, що саме потрібно створити. Раніше нечіткі вимоги поступово уточнювалися, поки розробник ставив запитання протягом кількох днів. ШІ-агент не ставить запитань. За лічені хвилини він упевнено створює щось на вигляд цілком правдоподібне, але неправильне.

2. Після написання коду: довести, що все працює. Черги на перевірку зростають швидше, ніж кількість людей, здатних її виконати. Кожен згенерований рядок коду — це рядок, якому хтось має довіритися.

Саме тут і виникають ті 44% помилок.

ШІ рідко пише синтаксично некоректний код. Він пише правильний код для неправильно зрозумілого завдання.

Це помилка у вимогах, яка проявляється як помилка в коді.

Чіткість вимог — нова основа продуктивності

Я працюю над дизайн-системами. І з моєї точки зору цей звіт більше про дизайн, ніж про інженерію.

Коли написання коду було дорогим, неоднозначність вимог обходилася дешево. Розробник міг самостійно заповнити прогалини, спираючись на власний досвід, коротке обговорення у Slack або швидкий перегляд наявного продукту.

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

Кожне нечітке рішення множиться на кількість агентів та інженерів, які генерують код, спираючись на нього.

Саме для цього й потрібна зріла дизайн-система.

Не просто набір компонентів, а система рішень, ухвалених один раз:

• Токени, які описують призначення, а не лише значення.
• Документація компонентів, у якій визначені правила використання, стани та нестандартні сценарії.
• Патерни, які відповідають на запитання «як ми реалізуємо X у нашому продукті» ще до того, як хтось його поставить.

Люди могли дозволити собі покладатися на неформалізовані командні знання. Агенти — ні.

Документація вашої дизайн-системи тепер є вхідними даними для створення продукту, а не довідником, який ніхто не читає.

Якщо документація неповна, ШІ заповнить прогалини типовими рішеннями. І ви просто почнете швидше випускати посередній продукт.

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

Це робота з вимогами. Це робота з дизайном.

Цінність фахівців дедалі більше визначається їхньою здатністю чітко формулювати наміри та очікувані результати.

Що це означає, на мою думку

Я працюю з дизайн-системами понад десять років, а протягом останніх трьох років системи, які я створюю, використовують також ШІ-агенти, переважно Claude Code.

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

Тому це не покрокова інструкція. Це мої роздуми над звітом, засновані на власному досвіді.

1. Обсяг створеного — найпростіший показник для вимірювання і водночас найменш корисний. Коли ШІ штучно збільшує кількість реалізованих функцій, цей показник майже втрачає сенс. Час від ідеї до випуску в продукт і кількість дефектів, які доходять до користувачів, здаються мені значно чеснішими метриками.

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

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

4. Перевірка результатів — місце, де переваги ШІ можуть непомітно зникнути. Якщо 72% керівників бачать зростання часу на перевірку результатів ШІ, цей час або заздалегідь закладений у процес, або забирається з інших завдань.

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

Звіт вказує на схожу тенденцію.

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

В інших командах цей показник становить 65%.

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

Важливе застереження

Це опитування 157 технологічних керівників у США та Китаї, а не вимірювання фактичних показників розробки та випуску продуктів.

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

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

Головний висновок

ШІ не усунув найскладнішу частину створення програмного забезпечення.

Він усунув ту частину, за якою ховалася справжня складність.

У найближчі два роки виграватимуть не ті команди, які генерують найбільше коду.

Виграватимуть ті, які точно знають, що саме хочуть створити.

І це залишає мене із запитанням, на яке саме лише опитування не може дати відповіді.

Якщо ваша команда створює більше, ніж будь-коли раніше, чи справді вона рухається швидше? Чи робота просто перемістилася туди, де її поки ніхто не вимірює?

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