Вайбкодинг: швидкість, яку важко виміряти, і борг, який легко накопичити

2 лютого 2025 року Андрей Карпати, співзасновник OpenAI і колишній керівник напряму ШІ в Tesla, описав у X новий спосіб програмувати. Він назвав його «вайбкодингом» (vibe coding): повністю віддатися відчуттю, «забути, що код узагалі існує», приймати всі зміни, які пропонує модель, і не читати диффи. Сам Карпати уточнював, що для одноразових проєктів «на вихідні» такий підхід «непоганий». Але термін швидко вийшов далеко за ці межі. Тепер ним називають будь-яку розробку, де людина формулює бажаний результат, а код пише й переписує модель.

Через півтора року після появи терміна можна подивитися на дані, а не на враження. Дані ці неоднозначні, і саме тому вони цікаві.

Користуються майже всі, довіряють — меншість

За опитуванням Stack Overflow 2025 року (понад 33 тисячі відповідей на питання про ШІ):

• 84 % розробників користуються AI-інструментами або планують;
• щодня ними користується 47 % усіх респондентів і близько 51 % професійних розробників;
• точності результатів ШІ довіряє близько 33 % опитаних, не довіряє — близько 46 %;
• найчастіше розробники скаржаться на рішення, які «майже правильні, але не зовсім» (66 %), а 45 % кажуть, що налагодження згенерованого коду забирає більше часу.

Цікаво, що власне вайбкодинг у професійній роботі — явище поки нішеве. На пряме запитання, чи є він частиною їхньої роботи, 72 % відповіли «ні», ще 5 % — «категорично ні», і лише близько 15 % — «так» у тій чи іншій формі.

Звіт DORA 2025 року, який Google Cloud підготував за опитуванням майже 5 тисяч фахівців, показує ту саму картину. 90 % користуються ШІ в роботі, медіанно близько двох годин на день. Понад 80 % відчувають зростання власної продуктивності, 59 % — позитивний вплив на якість коду. Водночас лише 24 % довіряють ШІ «сильно» або «дуже сильно».

Відчуття і вимірювання розходяться

Найцитованіше дослідження продуктивності — рандомізований експеримент METR, опублікований у липні 2025 року. 16 досвідчених розробників відкритого коду виконали 246 реальних задач у великих репозиторіях, з якими працювали роками. Кожну задачу випадковим чином дозволяли або забороняли робити з ШІ. Здебільшого учасники працювали в Cursor Pro з моделями Claude 3.5 і 3.7 Sonnet.

Результат здивував навіть авторів: із ШІ задачі займали на 19 % більше часу. До початку розробники прогнозували пришвидшення на 24 %, а після завершення все одно вважали, що ШІ пришвидшив їх приблизно на 20 %.

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

І вона, схоже, змінюється. У лютому 2026 року METR опублікував оновлення: 57 розробників, 143 репозиторії, понад 800 задач з інструментами кінця 2025 року. Оцінки цього разу вказують на пришвидшення: −18 % часу для розробників, що повернулися з першого дослідження (95 % довірчий інтервал від −38 % до +9 %), і −4 % для нових учасників (від −15 % до +9 %). Обидва інтервали включають нуль.

Головне в оновленні — не цифри, а пояснення, чому їм не варто надто довіряти. Розробники дедалі частіше відмовлялися від участі, бо не хотіли працювати без ШІ. Від 30 % до 50 % опитаних учасників визнали, що не віддавали в експеримент частину задач, яких не хотіли робити без ШІ. Самі автори назвали отримані дані «ненадійним сигналом» реального ефекту і написали, що розробники, ймовірно, зараз пришвидшуються сильніше, але їхні дані — лише дуже слабкий доказ масштабу цього пришвидшення.

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

Безпека: найслабше місце

Якщо з продуктивністю все неоднозначно, то з безпекою дані тривожніші. Компанія Veracode, що продає інструменти аналізу безпеки коду, у звіті від липня 2025 року дала понад 100 мовним моделям 80 задач на дописування коду, де можна було обрати безпечну або вразливу реалізацію.

• У 45 % випадків моделі обирали вразливий варіант.
• Для Java частка невдач перевищила 70 %, для Python, C# і JavaScript становила 38–45 %.
• Від міжсайтового скриптингу (CWE-80) код не був захищений у 86 % випадків, від ін'єкцій у журнали (CWE-117) — у 88 %.
• Більші й новіші моделі писали синтаксично кращий код, але не безпечніший.

Тут дві оговорки. Це дослідження постачальника засобів безпеки, а 45 % — частка тестових задач, а не частка вразливого коду в реальних проєктах. Проте висновок про те, що безпека не покращується з ростом моделей, якраз стосується вайбкодингу. Якщо ніхто не читає диффи, нікому помітити вразливість, яку модель із великою ймовірністю залишить.

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

Де межа

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

Де ризик прийнятний:

• прототипи й демо, які не дійдуть до користувачів;
• одноразові скрипти, перетворення даних, внутрішні утиліти без доступу до чутливих даних;
• навчання й дослідження незнайомої бібліотеки, коли результат усе одно перевірятиметься.

Де без перевірки людиною не обійтися:

• автентифікація, авторизація, сесії, робота з паролями й токенами;
• платежі та будь-які фінансові розрахунки;
• обробка даних користувачів, введення від користувача, формування запитів до бази даних і HTML. Саме тут Veracode фіксує найвищі частки невдач;
• код, який буде супроводжуватися роками.

Що зменшує ризики незалежно від інструмента:

• малі зміни, які людина здатна прочитати цілком;
• автоматичні тести, написані або перевірені людиною, а не лише згенеровані разом із кодом;
• статичний аналіз і сканування залежностей у CI для всього коду, не лише «людського»;
• код-рев'ю, де рецензент знає, які частини згенерувала модель.

Відкриті питання

Найважливіше, чого дані поки не показують:

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

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