ШІ та програмісти: чому досвідчені деви з ним працюють повільніше

У відео на YouTube-каналі ЦЕ ПО РОБОТІ обговорювали результати дослідження, проведеного командою METR (абревіатура Mr.), що стосується впливу штучного інтелекту на продуктивність розробників. Йшлося про те, чи дійсно такі інструменти, як GPT або Claude, пришвидшують кодинг. Виявилося, що навіть досвідчені деви, які користуються цими інструментами, часто помиляються у власній оцінці ефективності. Ми підготували короткий і водночас деталізований виклад найважливішого — з поясненням, кейсами та практичними висновками.

Як проходив експеримент

Команда дослідників METR залучила до експерименту 16 розробників з Open Source-спільноти. Кожен із них мав понад п’ять років досвіду й працював із великими кодовими базами, де рахунок ішов на мільйони рядків. Їм дали 246 реальних задач з кодування, які потрібно було виконати у двох режимах: половину з використанням ШІ, іншу — без нього.

ШІ-асистентами були обрані популярні на той момент моделі: Cursor Pro, Claude 3.5 та Claude 3.7. Мета дослідження — не перевірити, чи можна згенерувати код, а оцінити реальний вплив ШІ на продуктивність професійних девелоперів у рутинних і нетривіальних завданнях.

Що думали учасники: очікування

Перед початком експерименту учасники — а це були не новачки, а досвідчені розробники з багаторічною практикою в Open Source — були впевнені, що інструменти штучного інтелекту стануть для них суттєвим бустером продуктивності. У середньому вони прогнозували приріст швидкості роботи на 24%. Такий оптимізм базувався на їхньому особистому досвіді: багато хто вже тестував GPT-помічники, Copilot чи Claude у повсякденних задачах, і мав відчуття, що це справді полегшує рутину. Чимало девелоперів використовували ШІ для генерації шаблонного коду, документації або навіть для розв’язання логічних задач. Їм здавалося, що навіть якщо результат і не завжди ідеальний, сам факт делегування частини завдань звільняє руки і дає змогу зосередитися на важливішому. До того ж, середовище програмування й ринок загалом формують навколо ШІ сильну атмосферу очікувань: «усі вже юзають», «хто не встигає, той випадає». Це також впливало на сприйняття потенціалу інструментів. Усе це створювало передумови для когнітивного упередження: здавалося, що ШІ точно має бути корисним, лишається лише з’ясувати — наскільки саме.

Фактичний результат: мінус 19% продуктивності

Натомість сухі цифри показали геть іншу картину. Замість прискорення на чверть, виявилося, що реальна швидкість виконання завдань із ШІ була нижчою, ніж без нього. У середньому розробники працювали на 19% повільніше, коли залучали штучний інтелект. Це стало несподіванкою навіть для самих учасників — суб’єктивно вони залишалися впевненими, що працювали швидше. Щоб зрозуміти, у чому причина, дослідники проаналізували структуру часу. Стало очевидно, що значна частина ресурсу йде не на створення рішення, а на боротьбу з його недосконалістю: перевірку, діагностику, редагування або регенерацію з урахуванням уточнень. Проблема посилюється тим, що навіть одна помилка в коді — це привід витратити десятки хвилин, особливо коли вона виявляється лише на пізніх етапах тестування. У класичній розробці девелопер швидко усуває такі помилки завдяки інтуїції та розумінню архітектури, а ШІ часто не має уявлення про контекст і знову видає умовно правильну, але неефективну відповідь. Як результат — повторні ітерації без прогресу.

Підписуйтеся на наші соцмережі

Ілюзія швидкості: чому навіть досвідчені деви помиляються

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

Це створює викривлене враження, ніби час не витрачався, хоча насправді — робота не просувалась уперед. І хоча руки були вільні від клавіатури, задачі не виконувались ефективніше.

Причини неефективності: технічні й людські

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

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

Окреме питання — обмеження самих моделей. Навіть сучасні ШІ-системи не завжди здатні враховувати усі залежності, контекст і специфіку проєкту. На складних, «живих» завданнях це швидко стає помітно.

Високонавантажені проєкти: зона, де ШІ ще не справляється

Складні проєкти — це зовсім інша екосистема. Тут кожна зміна може мати далекосяжні наслідки. ERP, CRM, логістичні сервіси, банківські модулі — усе це вимагає безперервної інтеграції, тестування і стабільності. У таких умовах навіть одна хибна інтерпретація бізнес-логіки може призвести до критичних збоїв. Саме тому більшість практиків з реального сектору, які вже намагаються впроваджувати ШІ в роботу, говорять про однакову картину: на перших 40–50% розробки модель справляється непогано, дозволяючи швидко сформувати скелет мікросервісу чи базовий шар логіки. Але чим далі в глибину — тим більше правок, несумісностей, конфліктів у версіях та нюансів, які ШІ не бачить. І саме тут інструмент стає гальмом. Чим вища складність проєкту, тим менше шансів, що модель дасть релевантну відповідь без ризику. У результаті більшість senior-розробників або відмовляються від ШІ в ключових модулях, або використовують його лише як інструмент швидкого нарису — і не більше.

Vibe coding і користувачі без технічної освіти

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

Це називають vibe coding — коли користувач не знає мови програмування, але може створити щось реальне за допомогою промтів і ШІ-асистентів. Це розширює аудиторію, демократизує розробку, дає нові інструменти для креативного самовираження. Але не замінює експертність.

Особистий досвід: як не-програміст намагався зробити скрипт

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

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

Підсумок: ефективність ШІ залежить від контексту

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

Глосарій ключових понять

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