AI для вайб кодинга: асистент чи агент для коду поруч із Bubble

Вайбкодінг навколо Bubble: звідки береться код під час запуску MVP

Коли треба перевірити бізнес-ідею, залучити перших користувачів або показати демо інвесторам, я беру Bubble як no-code фундамент. Інтерфейс і бази даних збираються візуально, без жодного рядка коду. Але навіть у найпростішому MVP швидко з'являються задачі, де без коду не обійтися: Поруч із цим: Як вчитися ai для кодинга.

API Connector: складні JSON-структури, масиви параметрів і заголовки для інтеграції платіжних систем чи AI-сервісів.
Кастомні плагіни: невеликі серверні або клієнтські скрипти (Server-side / Client-side actions), коли готових розширень у маркетплейсі бракує.
Тестові фікстури та скрипти: масиви даних, щоб наповнити базу перед першими інтерв'ю з клієнтами.

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

Асистент чи агент: у чому принципова різниця

Офіційна документація розробницьких платформ розділяє їх не за стилем спілкування, а за рівнем доступу до системи.

1. AI-асистент (Inline Suggestions та Chat)

Це генератор підказок у діалозі чи автодоповненні: чат ChatGPT, Claude або inline-підказки в редакторах коду.

Як працює: пропонує ізольований фрагмент коду, пояснює помилку або форматує JSON-рядок. Доступу до файлової системи чи термінала не має. Сам нічого не виконує.
Роль у Bubble: я копіюю результат і сам вставляю його в поле редактора Bubble. Кожна дія лишається під моїм прямим контролем.

2. AI агент для кодинга (Autonomous Multi-step Loop)

Це багатокроковий автономний цикл: режим Agent у Cursor, Copilot Agent або Claude Code.

Як працює: агент отримує ціль, сам планує кроки, редагує файли проєкту, ставить сторонні бібліотеки через командний рядок і викликає локальні утиліти, доки не виконає завдання.
Роль у Bubble: агент мені корисний тільки в локальній папці на комп'ютері. Наприклад, коли я готую окремий репозиторій для кастомного плагіна, налаштовую package.json або пишу локальний скрипт валідації даних.

Межі дозволів: про що попереджають розробники інструментів

Коли MVP треба запустити швидко, хочеться дати агенту повну автономність: «Run Everything» або пропуск підтверджень. Офіційна документація з безпеки прямо попереджає про обмеження: Поруч із цим: Shopify Canvas: магазин у чаті.

Класифікатори та білі списки (Allowlists) не гарантують безпеку. У документації Cursor і VS Code це сказано прямо: permissions.json або режими на кшталт «Auto-review» зроблені для зручності розробника, а не як непробивний контур захисту. AI може помилково вирішити, що команда безпечна.
Дії в терміналі та мережі незворотні. Редагування тексту я відкочу через історію змін. А якщо агент уже відправив мережевий запит або запустив скрипт, що перезаписав дані в зовнішньому сервісі, кнопка «Undo» цього не виправить.
Ізоляція та .cursorignore. Якщо агент працює локально, я ізолюю робоче середовище. Секретні ключі, бойові конфігурації та конфіденційні файли клієнтів не повинні потрапляти в контекст моделі.

Критичні точки ручної перевірки (Review Gates) для Bubble

AI згенерував код чи параметри. Я не вставляю їх одразу в робочий додаток. У Bubble є три критичні зони, де підказки моделі я перевіряю руками. Про це окремо: Retool NL для PostgreSQL/REST: що.

1. Ініціалізація в API Connector: це завжди РЕАЛЬНИЙ виклик

Коли ти налаштовуєш новий запит в API Connector і тиснеш Initialize call, Bubble робить справжній live-запит до стороннього сервісу.

Ризик: якщо AI-асистент підставив у тіло запиту випадковий ID або реальний робочий ключ, цей виклик може створити фіктивну підписку, списати кошти через платіжний шлюз або видалити запис у сторонній базі.
Правило: перший виклик роблю тільки на тестових API-ключах (Sandbox / Test Mode) і тільки з безпечними зразками даних.

2. Тіло запиту (Body) в API Connector відкрите для клієнта

За документацією Bubble, поля тіла запиту (Request Body) і назви колекцій можна побачити в браузері користувача через інспектор коду.

Ризик: моделі часто радять класти секретні токени чи ключі доступу прямо в JSON-тіло або в URL-параметри. Приймеш таку пораду, і секрети стартапу стануть загальнодоступними.
Правило: секретні ключі зберігаю тільки в спеціальних полях автентифікації конектора (Authentication). Якщо параметр секретний, на ньому обов'язково стоїть галочка Private.

3. Сумісність із Plugin API v4

Кастомний плагін на JavaScript для серверних дій Bubble має працювати за сучасним стандартом Plugin API v4.

Ризик: моделі, навчені на старих даних, регулярно галюцинують застарілими синхронними конструкціями. Наприклад, синхронним методом .get() замість промісів або старим context.request замість context.v3.request.
Правило: будь-який серверний код плагіна я переглядаю вручну. Він має повертати плоский JSON, використовувати async/await і спиратися на актуальні виклики v4.

Що дозволяти, а що тримати під ручним контролем: шпаргалка для запуску

Задача	Кому довірити	Режим дозволів	Що обов'язково перевірити руками
JSON-пейлоади для API Connector	AI-асистент (чат / inline)	Ручне копіювання	Чи позначені чутливі поля як Private, чи немає API-ключів у тілі запиту
Ініціалізація стороннього API	Тільки людина	Ручне натискання	Під час першого виклику використовується тільки тестовий (sandbox) акаунт
Скрипти тестових даних у локальній папці	AI-агент	Запит дозволу на кожну команду термінала	Чи не звертається скрипт до продакшн-бази і чи не видаляє випадково файли
Серверний код плагіна (Node.js)	AI-асистент або агент у пісочниці	Повний перегляд diff перед копіюванням	Є `async/await`, коректний `context.v3.request`, ліміти на розмір відповіді

Швидкість вайбкодінгу не в тому, щоб дозволити моделі наосліп тиснути кнопки за мене. AI знімає з мене рутину синтаксису. Роль архітектора лишається за мною: я контролюю безпеку ключів і надійність MVP до того, як прийдуть перші клієнти.