Як ШІ змушує переосмислювати програмування

В останні роки індустрія програмування суттєво трансформується. Це підтверджують результати опитування Stack Overflow Developer Survey: 84% розробників використовують інструменти штучного інтелекту (ШІ) або планують це робити, 51% працює з ними щодня.

У зв'язку з цим з'явився vibe coding (вайб-кодинг) – підхід, за якого розробник описує ідею продукту, а ШІ генерує код. У певних сценаріях це прискорює процеси, але разом з його появою у компаній з'явилися нові виклики.

Швидкість проти якості?

Компанії масово долучають ШІ до програмування, однак результати поки що стримані. Дослідження Microsoft, MIT, Princeton та Wharton School "Вплив генеративного штучного інтелекту на висококваліфіковану роботу", у якому взяли участь понад 4 тис. розробників, зафіксувало зростання продуктивності за використання GitHub Copilot на 26%.

Цікава деталь: найбільші результати продемонстрували junior-розробники, тоді як senior-розробники не показали статистично значущих покращень.

Команда Duanex з появою ШІ виконує завдання за години замість днів. Час написання автоматизованих тестів у працівників скоротився на 50%, а покриття збільшилося на 20%. Одна frontend-команда покрила застарілі компоненти за два дні замість запланованих двох тижнів, а створення стандартних API (Application Programming Interface) за допомогою ШІ дозволяє економити 10-15% часу.

Водночас ця швидкість має чіткі межі. Вайб-кодинг добре працює для стандартних рішень, але з ускладненням виникає розрив між швидкістю створення коду і розумінням результатів. Проєкти з незвичайною архітектурою потребують глибокої senior-експертизи.

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

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

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

Безпека – найнебезпечніша ілюзія

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

Водночас на ринку з'являються інструменти, які допомагають краще контролювати ризики. Наприклад, платформи на кшталт Lovable можуть перевіряти зміни в коді після його оновлення і попереджати, якщо певні дані стають доступними стороннім.

Проте розробники стримано ставляться до ШІ. Згідно з опитуванням Stack Overflow Survey, більшість спеціалістів (46%) скептично ставиться до коректності інструментів ШІ, вірять їм 33% і лише невелика частина (3%) дуже довіряє цим інструментам.

Що далі

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

Упродовж наступних років структура команд буде змінюватися. Наприклад, проєкт з трьома командами по вісім осіб зможе зменшити кількість спеціалістів до шести-семи на команду (скорочення на 12-25%). Це відбудеться завдяки тому, що на заміну вузькоспеціалізованим ролям прийдуть універсальні інженери.

Конкурентну перевагу матимуть компанії, що будуть стратегічно використовувати ШІ в процесах, інвестуватимуть у розвиток команд і системно працюватимуть з безпекою.