Ninox (8.10): AI з трасованістю проти vibe coding — які логи закрити в соло-Bubble до першого агента

8 жовтня 2026 року Ninox представив оновлену версію своєї платформи і прямо протиставив свій підхід «vibe coding» (вайб-кодингу). Їхня теза проста. Таблиці, поля й логіку можна швидко генерувати текстовими промптами, але все це має лишатися прозорим, контрольованим і повністю трасованим, а не ставати чорною скринькою. Схожий розбір: SK AX AI Boot Camp.

Я розумію, чому нетехнічні засновники, які запускають перший MVP на Bubble, люблять вайб-кодинг. Технічний поріг мінімальний, а до перших користувачів чи першої розмови з інвестором можна дійти дуже швидко. Проблема починається, коли ви сліпо довіряєте AI-асистенту і ніхто не фіксує, що саме він зробив. Тоді база даних і воркфлоу швидко перетворюються на хаос. Про це окремо: IT Brew: vibe-coding у бізнесі.

Кидати через це Bubble і переходити на Ninox я не раджу. Достатньо взяти звідти одну інженерну звичку, трасованість (traceability), і адаптувати її під соло-застосунок. Дорогі корпоративні інструменти для цього не потрібні. Про це окремо: Expo SDK 57 у Bubble.

Що пропонує Ninox і що це означає на практиці

У публічних матеріалах запуску Ninox описує трасованість через три елементи:

1. Інспекція структури: сутності, створені за допомогою AI, лишаються звичайними низькокодовими блоками та скриптами. Їх можна переглянути й відредагувати вручну.
2. Режими підтвердження (Manual vs Auto approval): адміністратор вирішує, чи зміни структури застосовуються автоматично, чи чекають підтвердження людини.
3. Історія змін (History): аудит створення, оновлення й видалення записів із фіксацією користувача, часу та дифу полів.

Чесно кажучи, це класична історія змін даних плюс видимість коду. Окремого поглибленого аудиту AI-сесій, тобто хто ввів який промпт і яку модель викликав, тут немає. Але сам принцип розділити «швидку генерацію» і «прозорий контроль» я вважаю критичним для будь-якого MVP.

Чому в Bubble це стає ризиком при першому підключенні агента

Коли соло-фаундер підключає першого AI-агента або Bubble MCP, він натрапляє на кілька характерних підводних каменів:

• Аутентифікація від вашого імені: Bubble MCP виконує операції з правами залогіненого користувача. Якщо агент працює під вашим щоденним акаунтом, у журналі змін (changelog) складно відрізнити, де діяв живий розробник, а де згенерований запит.
• Немає аудиту операцій читання: Bubble пише операції запису в changelog, а запити на читання даних через MCP окремо не логує.
• Небезпека для живих даних: автономний агент із прямим доступом до бази може випадково пошкодити дані ваших перших реальних користувачів.

Чотири правила контролю до першого запуску агента в соло-Bubble

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

1. Виділіть окремий акаунт для агента. Не підключайте інтеграції під своїм основним профілем. Створіть окремого технічного користувача (workspace user). Тоді в Bubble changelog чітко видно, які саме зміни вніс агент.
2. Ізолюйте середовище (тільки Dev Database). На етапі прототипування агент не отримує доступу до Live-бази. Ніколи. Усі експерименти й виклики MCP відбуваються лише в гілці розробки (Development) і на тестових даних.
3. Увімкніть «Manual Approval» для структури. Не дозволяйте AI у фоні змінювати схему бази даних (Data Types / Fields) чи правила приватності (Privacy Rules). Працюйте через ручний перегляд: агент пропонує логіку, ви перевіряєте її в редакторі.
4. Зберігайте транскрипти сесій зовні. Bubble MCP не фіксує історію запитів читання, тому промпти й відповіді агента я зберігаю в клієнті, наприклад у середовищі розробки чи системі викликів. Для чутливих дій користувачів у застосунку заведіть просту таблицю AuditLog (Хто, Що, Коли, Статус) і записуйте туди критичні мутації.

Що я з цього беру

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