Чимало керівників компаній розповідають, що штучний інтелект не буде замінювати розробників, а додасть їм у продуктивності і вони зможуть робити більше. Дослідження Metr показує, що це не завжди так трапляється. У блозі Second Thoughts описано, чому так могло трапитись. Редакція Scroll.media підготувала стислий переказ матеріалу.

Навколо AI-інструментів для програмування не вщухає хайп: стартапи запускаються з мінімальними командами інженерів, непрофесіонали «на вайбі» створюють застосунки, а ринок для Junior-розробників стрімко падає. Але, згідно з експериментом METR, проведеним навесні 2025 року, існує як мінімум одна група, якій AI-інструменти досі не допомагають.

METR провів жорстко контрольоване дослідження (доступні блог і повний текст статті), щоб виміряти приріст продуктивності від використання AI серед досвідчених розробників, які працюють над великими проєктами. Результати здивували всіх: зниження продуктивності на 19%. Навіть самі учасники експерименту були вражені — вони вважали, що AI підвищив їхню продуктивність на 20%.

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

Методологія дослідження

Дослідження проводилось максимально суворо: справжнє рандомізоване контрольоване випробування у реальних умовах. Учасниками стали досвідчені розробники, які виконували свої щоденні завдання.

• METR залучив 16 розробників з провідних opensource-проєктів.
• Кожен з них обрав перелік задач зі свого списку «to-do», розбивши великі проєкти на завдання, які можна виконати за 1–2 години. Загалом було включено 246 задач.
• Розробники оцінили, скільки часу займе виконання кожної задачі: у звичайному режимі та без використання AI-інструментів. Різниця між цими оцінками — це очікуване прискорення (тобто на скільки AI має покращити продуктивність).
• Кожну задачу випадковим чином віднесли до однієї з двох категорій: «AI дозволено» (розробник може користуватися будь-якими інструментами) або «AI заборонено» (жодних AI-асистентів).
• Розробники працювали як зазвичай, записуючи екран для подальшого аналізу. Після завершення кожного завдання вони фіксували, скільки часу витратили. Для задач з AI вони також оцінювали, скільки часу, на їхню думку, їм зекономив AI.
• Важливо: розробники не знали наперед, чи зможуть використовувати AI в тій чи іншій задачі, тож їхні попередні оцінки не були упередженими.

Для обчислення реального впливу AI дослідники порівнювали початкові оцінки часу виконання з фактичним часом. У підсумку виявилося, що розрив між прогнозованим і фактичним часом у задачах із AI був на 19% більшим, ніж у задачах без AI.

Чому так могло трапитись?

Дослідники вирішили зібрати більше причин, чому реально результати могли бути саме такими. Ось який список склали:

• Ефект Джона Генрі. Можливо, розробники хотіли «перемогти машину» й старалися сильніше на завданнях без AI. Але тоді такий ефект мав би зменшуватись із часом (адже кожен учасник виконував у середньому 15 задач по 1–2 години). Проте жодного згасання ефекту не зафіксовано.
• Недостатнє використання AI. Можливо, учасники просто не користувалися AI, навіть коли було дозволено. Але це могло б пояснити лише відсутність приросту, а не зниження продуктивності. До того ж 84% екранних записів у категорії «AI дозволено» демонстрували принаймні часткове використання AI.
• Занадто оптимістичні оцінки часу. Розробники часто недооцінюють час виконання задач. Але оскільки вони оцінювали час ДО того, як дізнавались, чи можна буде використати AI, така похибка рівномірно впливала на обидві групи.
• Нечітке визначення задач. 
• Застарілі інструменти. 
• Неточна фіксація часу.

Жоден із цих факторів не спотворив результати. Водночас є кілька чинників, які могли сприяти спостережуваному зниженню продуктивності:

• Надмірне використання AI. Деякі з учасників сказали, що почали експериментувати з задачами і AI — і це стосувалось половини всіх завдань. Тобто штучний інтелект застосували спеціально більше, ніж потрібно було.  
• Недостатній досвід з AI-інструментами. У деяких учасників його було більше, лише 44% мали великий досвід використання Cursor.
• Нові інструменти. Деякі учасники спеціально почали використовувати інструменти, якими не користувались раніше. Це їх сповільнювало.

Можливо, розробники, які використовували AI, просто розширювали обсяг задачі — наприклад, писали код для обробки додаткових edge-cases, додавали нові функції або ретельніше тестували чи документували код. Як потенційний доказ цього, дослідники наводять те, що в задачах, де дозволялося використання AI, розробники написали на 47% більше рядків коду (в розрахунку на очікуваний розмір задачі), ніж у задачах без AI. Втім, автори дослідження вважають, що навіть якщо різниця в кількості рядків реальна, її можна пояснити не лише позитивно (детальніший код, краща перевірка), але й негативно — надлишковим кодом, дублюванням, зайвими деталями тощо.

Навіть якщо розробники витрачали більше часу з AI, це не обов’язково означає, що вони витрачали більше зусиль. Перевірка або виправлення коду часто (але не завжди) легша, ніж написання з нуля, а час очікування на генерацію коду можна використати для перепочинку чи паралельної роботи.

У підсумку, вплив AI-інструментів може бути не таким поганим, як здається: частина спостереженого зниження продуктивності (-19%) могла обернутися ґрунтовнішою роботою або меншим енергозатратами. Частину зниження могли також спричинити учасники, які надмірно експериментували з AI, надто серйозно сприймаючи свою роль у дослідженні. Але факт залишається: AI-інструменти не дуже допомагали, а, можливо, навіть реально шкодили продуктивності.

Слабкі місця сучасних AI-інструментів

1. Зрілі, великі проєкти. Дослідження проводилось на «старих» проєктах із великими кодовими базами: середньому понад 10 років і понад мільйон рядків коду. Це повна протилежність «greenfield»-проєктам. Щоб виконати завдання, потрібно було розуміти значні обсяги коду, що є слабким місцем для нинішніх AI-асистентів.
2. Мовчазне знання. Розробники часто спираються на недокументоване розуміння своєї кодової бази. У дослідженні учасники неодноразово скаржилися, що AI не має цього знання, тому генерує менш корисний код. Один учасник зазначив, що AI «поводиться як новачок у репозиторії», інший — що «модель не знає, які саме дані будуть взаємодіяти з кодом, і чому важливо зберегти ось цей рядок для зворотної сумісності». Подібні нюанси важко передати в контексті AI.
3. Висока планка. Усі учасники мали багаторічний досвід із цими проєктами й працювали дуже ефективно. Тому AI мав справу не з «пересічними» програмістами, а з дуже досвідченими — і змагатися з ними було складно.
4. Суворі гайдлайни. У більшості opensource-проєктів, які досліджували, були суворі вимоги до стилю. AI не завжди їх дотримується, тож розробники витрачали додатковий час на редагування.

Висновки

Зниження продуктивності на 19%, зафіксоване в дослідженні, може здаватися демотиваційним, але воно стосується складного сценарію використання AI (досвідчені розробники, складні кодові бази, високі стандарти якості). Частково воно може пояснюватися тим, що програмісти обирали більш спокійний темп роботи, щоб зберегти енергію, або навмисне використовували AI для більш ґрунтовної перевірки. І, звісно, результати покращуватимуться з часом.

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

Втім, найважливіший висновок, ймовірно, полягає в тому, що хоча розробники виконували завдання на 19% повільніше з AI, вони вважали, що стали працювати на 20% швидше. Багато оцінок впливу AI базуються на опитуваннях або суб’єктивних враженнях — а тут ми маємо об’єктивні дані, які демонструють, наскільки оманливими можуть бути такі враження.