Розробники програмного забезпечення настільки звикли до інструментів зі штучним інтелектом для написання коду, що багато хто вже відмовляється працювати без них – навіть для обмеженої кількості завдань у контрольованих експериментах. Водночас усе більше даних свідчать про те, що ці системи нерідко створюють більше проблем, ніж вирішують. Таким чином, масове впровадження ШІ у програмування починає виглядати швидше питанням сприйняття та залежності, ніж реальної ефективності.
Парадокс продуктивності
У лютому 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": «Тепер ви пишете код удвічі швидше? Краще сподівайтеся, що витрати на підтримку також зменшилися вдвічі. Інакше ви в пастці. Ви обмінюєте тимчасовий сплеск швидкості на вічне рабство.»
Ця цитата вловлює суть нової реальності в індустрії: ШІ може створювати відчуття вибуху продуктивності, але якщо організації не врахують вищі витрати на рев'ю, тестування та підтримку, вони ризикують накопичити невидимий "технічний борг", який у довгостроковій перспективі з'їсть будь-який короткостроковий прибуток від швидкості. Питання вже не в тому, чи використовувати ШІ, а в тому – як саме і з якими захисними механізмами – щоб інструмент не перетворився на джерело постійної вразливості.