Vibe coding: чому AI-assisted розробка часто розчаровує

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, мене звати Антон Небилиця, я Senior Software Development Engineer в SPD Technology.

Почну з цифри, яка мене свого часу вразила: незалежне дослідження METR (arXiv:2507.09089, липень 2025) провело рандомізований контрольований експеримент із досвідченими розробниками — людьми, які знали свої репозиторії роками. Результат: доступ до AI-інструментів уповільнив їх на 19%. При цьому самі розробники вважали, що прискорилися на 20%. Розрив між відчуттям і реальністю — аж 39 пунктів. METR самі уточнили, що ця цифра може бути завищеною в інших контекстах, але perception gap залишається задокументованим фактом незалежно від точного числа.

Це не означає, що AI не працює. Означає, що ми погано розуміємо, де він реально допомагає, а де лише створює ілюзію продуктивності чи потребує додаткової конфігурації, налаштування бази знань для проєкту.

У цій статті я хочу розкрити основні причини, чому vibe coding розчаровує — завищені очікування, швидкість без осмислення та 3 структурні сліпі зони, які AI просто не бачить.

AI як додатковий розробник у твоїй команді

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

Раніше лід роздавав задачі команді й проходився по pull request’ах. Зараз частину цієї роботи я делегую AI, але підхід залишився таким самим. Я перевіряю, що зроблено, чи все працює, чи пройшли тести, чи немає security issues, чи реалізація відповідає задачі.

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

На практиці в мене склалася така схема: налаштування проєкту, планінг і архітектурна валідація віддаються сильній моделі, а написання рутинного коду слабшій. Якщо наближається ліміт токенів за часом, але є запас токенів, тоді я перемикаюся назад на сильну модель. Якість одразу видна в кількості багів і в тому, скільки ітерацій займає реалізація фічі. Ще одне правило, яке я для себе встановив — дуже часті коміти з невеликою кількістю змін, щоб не загубитися в коді і не втратити розуміння того, що відбувається.

Чому vibe coding так часто не спрацьовує

Причин кілька, і вони накладаються одна на одну.

Завищені очікування на старті

Коли AI-інструменти вийшли на масовий ринок, багато хто очікував ідеального результату з першої спроби. І дані добре показують, наскільки цей розрив між очікуванням і реальністю нікуди не зник. У JetBrains State of Developer Ecosystem 2025 (опитування на 24 534 розробників) 85% регулярно користуються AI, але лише 44% реально інтегрували його у свій workflow. А Stack Overflow Developer Survey 2025 (понад 49 000 респондентів) додає деталей, що найчастіша скарга 66% користувачів AI на рішення, які «майже правильні, але не зовсім», а 45% розробників витрачають більше часу на дебаг AI-коду. Тобто інструментом користуються майже всі, а отримують з нього суттєво менше, ніж очікували.

DORA 2025 (дослідження Google Cloud приблизно на 5 000 програмістів) додає до цього важливий нюанс про те, що AI підвищує throughput, команди дійсно роблять більше, але водночас знижує stability, тобто додає збоїв і переробок. Мені сподобалася думка, що AI не виправляє команду, а підсилює те, що вже є. Слабкі процеси він масштабує разом зі швидкістю.

Я порівнюю це з еволюцією програмування загалом. Колись потрібно було точно думати про оптимізацію пам’яті й обчислень, потім з’явилися бібліотеки і фреймворки, і фокус змістився на швидкість розробки. З AI відбулося щось схоже: інструмент ще дозрівав, а очікування вже були максимальними. Сучасні моделі значно краще розуміють запит і якісніше реалізують задачі, але магії все одно не відбувається, адже потрібно зробити певне налаштування агента, щоб система давала результат.

Швидкість без осмислення

Це, мабуть, найпідступніша проблема vibe coding. Він дає відчуття величезної швидкості, здається, ніби дав задачу і отримав результат. Але саме в цій швидкості зникає простір для осмислення.

Класична пастка — дуже багато фіч виконано за перший спринт/місяць, але проблема в тому, що вони повністю не пройшли всі етапи розробки. Потім senior-рев’ю знаходить auth-логіку, продубльовану 12 разів, N+1 запити (47 queries на один endpoint) і race condition та інші проблеми.

У мене був схожий кейс. Я працював над проєктом, де з самого початку мала бути інтеграція Stripe. Весь дизайн і вимоги були надані AI разом із задачею. У результаті onboarding-флоу виявився непропрацьованим до кінця. AI не захотів реалізовувати частину, пов’язану зі Stripe, і просто упустив цей крок замість того, щоб зробити повну реалізацію із заглушками там, де потрібні реальні виклики до Stripe. Я пропустив це на ревʼю, бо все виглядало готовим. Зрозумів проблему пізніше, коли почав тестувати флоу повністю.

Коли я пишу код самостійно, я проходжу певний процес — отримую задачу, оцінюю її, досліджую домен, поступово формую рішення, уточнюю вимоги, переглядаю підхід. Коли цей етап пропускається заради швидкості, легко не поставити важливі питання бізнесу, не зрозуміти реальну проблематику і отримати результат, який «ніби є», але насправді слабкий.

Прогалини в системному мисленні

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

Якщо узагальнити мій досвід, то метапатерн один. AI робить і оптимізує локальний, видимий, happy-path код. І стабільно сліпий до трьох речей:

• іншого файлу чи компонента, з яким значення має бути скоординоване;
• шару defense-in-depth, який локально виглядає надлишковим;
• поведінки в рантаймі або на момент застосування, яку він просто не може спостерігати під час написання коду.

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

1. CSRF-cookie 15 хв проти access-токена 60 хв (сліпота #1: coupled pair). У проєкті був double-submit CSRF-cookie з часом життя 900 секунд і access-токен поряд — 3600 секунд. Проблема в тому, що це coupled pair: вони мають жити узгоджено, бо обидва тримають одну сесію. Посеред реальної робочої сесії CSRF-cookie тихо протухав першим. Наступний запит ніс уже порожній CSRF-токен → 401. Аплоад падав, хоч access-токен формально ще був живий 45 хвилин. AI вибирав ці два значення в різний час і в різних файлах і жодного разу не «побачив», що коротше з них тихо керує всією сесією.
2. Клаптиковий role guard (сліпота #2: сусідні endpoint-и). Кілька мутуючих endpoint-ів — soft-delete, PATCH-reassign, archive — мали лише перевірку «є залогінений користувач», без role-check. Хоча сусідні handler-и в тому ж самому guard-файлі такий role-check мали. На практиці це означало, що роль із правами «тільки створення + аплоад» могла видаляти і перепризначати чужі сутності. RBAC ми ліпили per-endpoint у міру написання, без єдиної role-matrix як окремого артефакту, і AI покривав рівно те, що в нього просили явно, не дивлячись на сусідні endpoint-и в тому ж файлі. Знайшли це не тестами, а під час окремого compliance-проходу.
3. setDefault — пастка «ключ є, але там null» (сліпота #3: рантайм). Auth-тригер робив response.setdefault("claimsOverrideDetails«, {}). Це канонічна, абсолютно правильна Python-ідіома, і AI використав її коректно. Але сторонній auth-провайдер клав у це поле не відсутній ключ, а явний null. setdefault спрацьовує лише коли ключа немає, а коли ключ є зі значенням None, він повертає цей None і нічого не замінює. Далі звернення до None як до dict, NoneType crash і безликий 401 на логіні з TOTP. «Безпечний» код був неправильним саме для цього конкретного рантайму. AI не міг спостерігати, що кладе провайдер на момент виконання, і ми побачили це лише на staging, на реальних логінах.
4. П’ять комітів для вирішення S3 Object Lock issue (сліпота #4: apply-time). Bucket із увімкненим Object Lock має дві жорсткі вимоги: однаковий part-size на клієнті й на сервері та конкретний SHA-256 на кожен part. Перша AI-реалізація дала «Object Lock не потребує checksum» і 400 код помилки під час тестування. Другий фікс помилково підписав алгоритм замість хешу, через що SDK перемкнувся в chunked-trailer режим, який браузер просто не відтворює, як наслідок, 403 код помилки. Потім прибрали checksum, повернули його в іншій формі, і справжній фікс отримали аж на п’ятому коміті. Увесь цей ланцюжок (400 → 403 → 400 знову) — це AI, який лікує симптом за симптомом, бо реальне питання було не «чи підписувати checksum», а «яке саме поле і в якій формі». Серверну bucket-policy, яка це диктувала, він не бачив у принципі.
5. AI kill-switch із fail-open (сліпота #5: defense-in-depth і системний інваріант). Крок синхронізації knowledge-base перевіряв consent-прапорець так: event.get("ai_enabled«, True). Тобто якщо ключа в event немає, то вважається, що AI увімкнено. Оптимістичний дефолт читається абсолютно природно, і для більшості полів він правильний. Але це consent-gate, а для consent-gate інваріант протилежний: absent має означати deny. Будь-яка зміна форми event-у могла протягнути AI-disabled кейси прямо у векторний стор. Показово, що сусідній воркер на цей самий прапорець ходив у БД і поводився fail-closed, тобто узгодженого правила між компонентами не було. Це не технічна помилка в коді, це системний інваріант, який AI не вивів сам. Знайшли аудитом; рантайм-симптом ще навіть не встигло статися.
6. І окремий маленький патерн — silencing warnings. Коли AI впирається в помилку lint-правила, він інколи додає // eslint-disable-next-line або спеціалізований код, який відключає тільки цю помилку, замість того щоб виправити проблему по-справжньому. Технічно помилка зникла, але, по суті, нічого не вирішено. Це той самий метапатерн у мініатюрі: прибрати видимий симптом замість того, щоб зрозуміти, чому він узагалі з’явився.

Спільне в усіх цих кейсах одне. Жоден із них не виловили ні під час тестування, ні під час написання коду — їх знайшли на staging, під час аудиту або в окремому compliance-проході. Бо всі вони живуть саме в тих трьох сліпих зонах, які AI структурно не бачить. Цю проблему ще й посилює те, що AI добре приховує власні недоліки. Він пише впевнено, структуровано, з коментарями. Код виглядає так, ніби його написав досвідчений розробник. Саме тому такі системні помилки так легко пропустити на ревʼю.

Недостатньо практики

Багато розчарувань — це просто замало практики, бо люди пробують інструмент раз, отримують поганий результат і роблять висновок. Але одна спроба тут нічого не означає. Я помітив, що навіть пів години щодня поступово змінює розуміння того, де це реально працює. Треба тестувати різні сценарії, дивитися, що спрацьовує, а що ні, і формувати власне бачення, і не зупинятися на тому, що зараз працює, бо AI-гіганти дуже швидко покращують свої сервіси.

Для мене одним із несподіваних відкриттів стало те, що AI добре допомагає «догнати» власний старий код. Коли повертаєшся до функціоналу, який реалізовувався місяць-два тому, простіше запитати AI, який там стан і що відбувається, ніж самому все пригадувати. Це не «вайбкодинг», це практичний інструмент для роботи з великою кодовою базою. Раніше цінувався скіл, як правильно загуглити, щоб знайти те, що потрібно для вирішення задачі, а зараз, як правильно описати задачу для AI-агента.

Неправильний вибір інструменту

На ринку зараз дуже багато AI-інструментів: моделі, агентні рішення, IDE з вбудованим AI, продукти для конкретних задач. Через це складно зрозуміти, що обрати.

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

Різні інструменти сильніші в різних задачах: Claude Code (термінальний агент, що самостійно читає кодову базу і запускає команди) краще справляється з масштабним рефакторингом і реалізацією фіч у великих проєктах. Cursor зручніший для щоденного редагування і inline-рев’ю. Copilot найбільш поширений у корпоративному середовищі, але за показником «найулюбленіший інструмент» серед розробників стабільно відстає від Claude Code і Cursor за даними 2025–2026 років.

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

Безпека та ліцензії: про що говорять рідше

Veracode у 2025 році емпірично протестувала понад 100 LLM на 80 задачах і отримала 45% failure rate на security-тестах (OWASP Top 10). Найнеприємніше тут, що потужніші й новіші моделі не давали безпечнішого коду, вони покращували синтаксис і «правдоподібність», але не безпеку.

А окреме дослідження CodeRabbit «State of AI vs Human Code Generation» (грудень 2025), яке проаналізувало 470 реальних open-source pull request’ів на GitHub (320 з AI-співавторством проти 150 суто людських), показало, що AI-код містив у 2,74 раза більше XSS security-вразливостей (і в 1,7 раза більше проблем загалом), ніж людський. Це збігається з тим, що я бачу на власних кейсах: AI впевнено пише код, який локально виглядає коректним, а діра відкривається на системному рівні. Надіюся що Claude Fable 5 або Claude Mythos 5 зможуть змінити цю динаміку в протилежну сторону, і отримаємо якісну безпекову перевірку.

Є два аспекти, які рідко потрапляють у дискусії про vibe coding, але мають цілком реальний практичний вплив.

Що відбувається з вашим кодом

Агентські інструменти (Claude Code, Cursor Agent) самі читають кодову базу і надсилають фрагменти контексту до API разом із кожним запитом. Якщо у вас .env-файл потрапив у контекстне вікно агента, він іде до Anthropic або OpenAI. Якщо в конфігах є DB connection string, то ці дані передаються. .gitignore тут захищає лише частково.

Так, файловий пошук Claude Code (Glob/Grep) за замовчуванням поважає .gitignore, але це зменшує лише випадкові натрапляння: якщо агент знає або виводить шлях, він усе одно може прочитати файл напряму (реальний кейс із .env-файлами, які лишалися читабельними, описав The Register у січні 2026).

Справжній захист — це явні deny-правила (permissions.deny у .claude/settings.json для Claude Code, .cursorignore для Cursor) плюс зберігання секретів узагалі поза деревом проєкту. AI-гіганти також намагаються вирішити це зі свого боку, деякі вже мають вбудовані інструменти, які або блокують запит на сервер, або анонімізують його, якщо в контексті є чутлива чи приватна інформація.

Практичне правило по інструментах (стан на середину 2026):

• GitHub Copilot: акаунти Free, Pro і Pro+ за замовчуванням віддають взаємодію (промпти, фрагменти коду, контекст) на навчання моделі — це opt-out. Для того, щоб вимкнути слідуй інструкції: профіль > Copilot settings > «Allow GitHub to use my data for AI model training» > Disabled (або напряму github.com/settings/copilot/features). Business та Enterprise — Data Protection Agreement забороняє використання для тренування, і цей перемикач для них узагалі не показується.
• Cursor: Privacy Mode вимкнений за замовчуванням на Free та Pro; на Team увімкнений за замовчуванням; на Enterprise також увімкнений і може бути примусово застосований на рівні всієї організації. Якщо Privacy Mode увімкнено, то всі провайдери підписують угоду про нульове збереження (виняток, коли спрацювання abuse-детекторів може спричинити тимчасове зберігання).
• Anthropic Claude / Claude Code: приватні акаунти (Free/Pro/Max) — навчання працює як opt-in, а не opt-out: з серпня 2025 користувача явно питають, якщо погодився тоді retention 5 років, якщо ні — 30 днів і дані не йдуть у тренування. API та комерційні акаунти (Team/Enterprise/Bedrock/Vertex) — на них не тренуються взагалі. Логи API зберігаються 7 днів (з 14 вересня 2025) і не використовуються для навчання (окремі новітні моделі вимагають 30-денного retention).

Просте правило: якщо компанія платить за Business/Enterprise-підписку, то дані, як правило, захищені контрактом. Якщо ви на персональному акаунті, перевірте налаштування приватності до того, як вставити робочий код.

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

Ліцензії

Багато моделей навчалися на відкритих репозиторіях, і частина цього коду поширюється під permissive-ліцензіями на кшталт MIT або Apache. Але є й copyleft-варіанти, де перевикористання може накладати додаткові зобов’язання. У згенерованому коді важче помітити ліцензійно-чутливі патерни, ніж під час прямого використання бібліотеки. Тут є практичні запобіжники. GitHub Copilot має фільтр виявлення дублікатів, який блокує підказки, що збігаються з публічним кодом (у Business/Enterprise він вмикається за політикою). А для комерційних проєктів варто проганяти вихідний код через інструменти snippet-scanning, які підсвічують збіги з ліцензійно чутливими фрагментами. Ризик не нульовий, але керований.

У другій частині розберемо, як налаштувати AI-розробку, щоб вона справді працювала.