Розробники відмовляються писати код без ШІ, попри ознаки падіння продуктивності

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

Парадокс продуктивності

У лютому 2026 року лабораторія з дослідження ШІ "METR" намагалася повторити відоме дослідження, що порівнювало, скільки часу розробники витрачають на завдання з допомогою ШІ та без неї. Експеримент провалився з неочікуваної причини: учасники просто відмовлялися працювати без своїх ШІ-інструментів, навіть для обмеженої кількості завдань і в суворо контрольованому середовищі.

Первинне дослідження METR від 2025 року вже окреслило тривожну картину. Програмісти стверджували, що ШІ "прискорив" їх приблизно на 24%, але реальні вимірювання показали протилежне – у середньому вони витрачали на 19% більше часу на виконання завдань. Затримка була зумовлена додатковими зусиллями на пошук та виправлення помилок, керування ШІ-помічником та очікування на згенерований код.

Навіть після того, як вони на практиці зіткнулися з цим уповільненням, учасники продовжували оцінювати, що ШІ приносить їм близько 20% приросту швидкості – це свідчить про значне розходження між суб'єктивним відчуттям та об'єктивними результатами. Після того, як лабораторії не вдалося відтворити експеримент у 2026 році, вона опублікувала опитування, в якому самі розробники заявили, що ШІ робить їх "удвічі ціннішими" для їхніх організацій.

Код нижчої якості та більше прихованих витрат

Незалежні аналізи підказують, що прискорення має серйозну ціну в якості. Платформа для code review "CodeRabbit" проаналізувала 470 відкритих pull request-ів і встановила, що код, згенерований ШІ, містить у середньому приблизно в 1,7 раза більше проблем порівняно з написаним вручну. Критичні та серйозні дефекти у змінах, створених за допомогою ШІ, зустрічаються до 1,7 раза частіше, логічні та коректні помилки зростають приблизно на 75%, а вразливості в безпеці збільшуються в 1,5–2 рази.

Стартап "Entelligence AI", що спеціалізується на надійності та моніторингу, повідомляє, що компанії витрачають близько 44% своїх ШІ-токенів на виправлення проблем, створених самим ШІ – оцінка, заснована на даних понад 2400 організацій. Дослідники з Сінгапурського університету менеджменту дійшли подібних висновків у звіті за квітень, попереджаючи, що "згенерований ШІ код може втягнути реальні програмні проєкти у довгострокові витрати на підтримку".

Як керувати залежністю від ШІ

Рекомендації фахівців зводяться до чіткого принципу: ставтеся до коду, створеного ШІ, так, як ви ставилися б до коду програміста-початківця. Команда SMU та засновник "Cognition" "Скотт Ву" – творець ШІ-агента для програмування "Devin" – одностайні в тому, що критично важливо підтримувати надійні системи контролю якості та уважно переглядати кожну зміну, запропоновану ШІ.

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

«Ви пишете код швидше, але в підтримки немає автопілота»

Програміст і автор "Джеймс Шор" формулює дилему особливо гостро в публікації, яка швидко стала популярною на "Hacker News": «Тепер ви пишете код удвічі швидше? Краще сподівайтеся, що витрати на підтримку також зменшилися вдвічі. Інакше ви в пастці. Ви обмінюєте тимчасовий сплеск швидкості на вічне рабство.»

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