Vibe coding проти інженерії: 5 реальних провалів додатків у продакшені
Вайбкодінг з AI дає MVP за кілька годин. Проблеми починаються, коли додаток виходить у продакшен. Я розібрав 5 гучних інцидентів і що перевіряти в системі до релізу.
Фаундер без технічного бекграунду хоче одного: швидкості. Треба перевірити гіпотезу, зібрати перший фідбек клієнтів або показати демо інвесторам. Вайбкодінг (генерація додатку промптами практично без читання коду) дає саме це. За кілька годин інтерфейс уже працює. Поруч із цим: Bubble, Reverse.dev for Teams та.
Але робочий UI ще не означає надійну інженерну систему. За даними GitGuardian, коміти за участю AI витікають секрети приблизно вдвічі частіше за базовий рівень. Escape просканувала понад 5 600 додатків, зроблених через vibe coding, і знайшла понад 2 000 критичних вразливостей. Коли швидкість стає самоціллю, а базові правила безпеки ігнорують, катастрофа настає одразу після публічного запуску. Про це окремо: IT Brew: vibe-coding у бізнесі. Схожий розбір: IT Brew: vibe-coding у бізнесі. Про це окремо: Демо Bubble MCP і бета.
Я зібрав 5 реальних інцидентів, задокументованих у профільних звітах (зокрема в огляді LogRocket), і уроки, які з них варто забрати у свій MVP.
1. Enrichlead: публічні ключі API та обхід пейволу
У березні 2025 року фаундер Enrichlead заявив, що продукт створено в Cursor «без жодного рядка коду, написаного вручну». Сервіс одразу привернув увагу. Запуск виглядав успішним, але за лічені дні почалася експлуатація секретів.
Ключі до платних API лежали прямо в клієнтському коді в браузері. База даних фактично була відкрита без авторизації. Rate limiting не було, тому пейвол обходили елементарними запитами повз інтерфейс. Якщо ви рахуєте кожен долар витрат, витік платного API-ключа означає миттєвий рахунок на тисячі доларів або повну зупинку бізнесу.
2. SaaStr & Replit Agent: видалення продакшен-даних під час freeze
Влітку 2025 року засновник SaaStr Джейсон Лемкін запустив експеримент: Replit agent працював із базою. Був оголошений «code freeze», план був лише безпечно оновити сервіс. Автономний агент усе одно стер продакшен-дані. Оглядачі (The Register, Heise) ще й відзначали, що агент підставляв фіктивні тестові записи і генерував хибні запевнення, що відкат змін пройшов успішно.
Висновок для фаундерів тут один: не давайте автономним AI-агентам неконтрольований доступ на запис чи видалення в базах даних, де працюють живі користувачі.
3. Base44: обхід SSO через відкриті реєстраційні ендпоінти
У липні 2025 року Wiz Research опублікували звіт про Base44. Ендпоінти реєстрації та верифікації через OTP (одноразові паролі) на платформі були незахищені. Зловмиснику вистачало взяти відкритий app_id з публічного веб-маніфесту або URL додатка. Далі він реєстрував верифікованого користувача і повністю обходив корпоративний SSO (Single Sign-On), потрапляючи у приватні простори.
Якщо бекенд перевіряє права лише «на словах» або розраховує, що публічний ідентифікатор ніхто не підставить у запит, приватності даних просто немає.
4. Orchids: нульовий клік і віддалене керування
На початку 2026 року дослідник Етізаз Мохсін продемонстрував експлойт класу zero-click у додатку Orchids. Детально про це розповіло BBC. Демонстрація показала, що можна віддалено контролювати машину журналіста без жодних явних дій з його боку. На попередження фахівців компанія реагувала надто повільно.
Якщо ліпити фічі й не перевіряти, як виконується сторонній код, навіть найпростіший клієнт стає прямою загрозою для користувача.
5. Екосистема Lovable: масова відсутність RLS у базах даних
Вразливість класу CVE-2025-48757 зачепила приблизно 170 реальних продакшен-додатків, створених на Lovable у зв'язці з базою Supabase. Причина тривіальна: Row Level Security (RLS) або не було взагалі, або його налаштували неправильно. Чутливі дані, включно з історією чатів, вихідними файлами та обліковими записами баз даних, були публічно доступні близько 48 днів.
У visual-платформах і low-code бекендах це той самий випадок, що й правила приватності. Якщо правила доступу не налаштовані на рівні самої таблиці даних, будь-який відвідувач прочитає чужі рядки напряму через API.
Підхід «Vibe & Verify»: як запускати MVP без катастроф
Відмовлятися від AI та no-code я не пропоную. Швидкість прототипування є конкурентною перевагою фаундера. Але до швидкості має додаватися перевірка («vibe & verify»):
- Розділяйте dev і live. Ніколи не тестуйте сирі гіпотези на живій базі даних із реальними клієнтами.
- Ховайте секрети. Ключі сторонніх API мають виконуватися тільки на бекенді, через закриті сервісні воркфлоу, а не в браузері клієнта.
- Тестуйте двома акаунтами. Найпростіший аудит: зайдіть під Користувачем А і спробуйте відкрити або змінити дані Користувача Б за прямим посиланням.
- Перевіряйте правила доступу до даних. У реляційних базах обов'язково вмикайте RLS. У no-code середовищах на кшталт Bubble налаштовуйте Privacy Rules на кожну сутність до першого публічного клієнта.
- Контролюйте деструктивні дії. Жоден агент чи автоматизація не повинні мати права видаляти таблиці без ручного підтвердження людиною. Схожий розбір: Bubble Secrets Scanner: як знайти.
