Розробники відмовляються працювати без ШІ: чи не загралися вони з технологіями?

• Ключові деталі:
• Дослідження 2026 року показують, що розробники надто залежні від ШІ-інструментів для кодування, щоб відмовитися від них.
• Хоча ШІ прискорює написання коду, він може призводити до збільшення помилок та витрат на підтримку.
• Рекомендується глибоке розуміння можливостей ШІ, ретельний перегляд згенерованого коду та збереження людського контролю над архітектурою та безпекою.

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

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

Зокрема, у лютому 2026 року авторитетна дослідницька лабораторія в галузі ШІ METR опублікувала неочікувані результати: переважна більшість розробників не бажають працювати навіть над обмеженим колом завдань без допомоги штучного інтелекту.

METR планували оновити дані попереднього дослідження 2025 року, яке вивчало продуктивність кодування за допомогою ШІ. Тоді науковці вимірювали час, який розробники-відкривачі витрачали на виконання завдань вручну порівняно з використанням ШІ.

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

Коли METR спробували повторити експеримент для оцінки прогресу ШІ та рівня кваліфікації кодерів, вони зіткнулися з несподіванкою проблемою.

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

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

Однак, останні заголовки про шалені витрати на так званий “токенмаксинг” та низка свіжих досліджень ставлять під сумнів такі самооцінки.

“Токенмаксинг” – використання кількості токенів, спожитих особою, як показника продуктивності з ШІ – став головним трендом 2026 року. І, схоже, він вже добігає кінця.

Amazon закрила внутрішній рейтинг відстеження токенів Kirorank після того, як співробітники почали зловживати ним, надмірно використовуючи ШІ-агентів та збільшуючи витрати, повідомив Financial Times. Ці випадки продемонстрували, що використання ШІ не завжди автоматично призводить до підвищення продуктивності.

Uber вичерпав свій річний бюджет на ШІ за перші чотири місяці 2026 року, як повідомляє The Information. Операційний директор Ендрю Макдональд нещодавно зазначив у подкасті, що такі витрати не призвели до вимірюваного зростання кількості проєктів чи продуктивності.

Згенерований ШІ код не обов’язково зменшує потребу в постійному обслуговуванні коду, а може навіть збільшити її, елегантно довів програміст та автор Джеймс Шор у своєму блозі, який став вірусним на Hacker News.

«Ви пишете код удвічі швидше? Сподівайтеся, ви зменшили витрати на його підтримку вдвічі», — написав він. «Інакше ви приречені. Ви обмінюєте тимчасовий приріст швидкості на вічне рабство».

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

Вірусний твіт від Айшварії Санкар, засновника та генерального директора стартапу Entelligence AI, стверджує, що компанії витрачають 44% своїх токенів на виправлення помилок, згенерованих їхнім ШІ. Водночас, компанія CodeRabbit, що займається інструментами для рев’ю коду, повідомляє, що проаналізувала запити на злиття у проєктах з відкритим кодом і виявила, що ШІ генерує на 1,7 раза більше проблем, ніж людський код.

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

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

Враховуючи, що програмісти обожнюють своїх ШІ-асистентів, яким може бути рішення?

Ті, хто продає вам ШІ-агентів для кодування, стверджують, що розробники можуть просто використовувати ці агенти для виконання виснажливих завдань з виправлення коду так само швидко, як ШІ його генерує. Таку думку висловив Скотт Ву, засновник і генеральний директор Cognition, розробник ШІ-агента Devin.

Але навіть він визнає, що, хоча Devin може працювати самостійно, його поточний рівень кваліфікації він оцінює як середній між молодшим та середнім програмістом, залежно від завдання. Це не рішення типу “передав і забув”.

Дослідники з SMU пропонують більш людиноцентричний підхід. Програмісти повинні так само глибоко розуміти, які завдання ШІ виконує добре, а які ні, як вони знають свої улюблені мови програмування. Їм потрібні надійні системи контролю якості, розроблені для ШІ, і вони змушені будуть ретельно переглядати роботу ШІ, ніби це молодший розробник.

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

За даними порталу: techcrunch.com