Retool App Builder GA (MCP, CLI, source control): корпоративний шар білдера. Звички забираю в соло-Bubble, студію не копіюю

28 жовтня 2026 року Retool вивів свій AI-керований App Builder у General Availability. Він доступний і в хмарній версії, і в self-hosted релізах. Білдер збирає застосунки на React 19 трьома шляхами: через чат усередині платформи, через локальний CLI (@tryretool/cli) або через MCP (Model Context Protocol). Є повноцінний source control (GitHub, GitLab, Bitbucket тощо) і корпоративне керування доступами. Схожий розбір: Salesforce Builder Central: beta-тиждень з.

Я пишу для нетехнічних засновників, які збирають MVP на no-code та вайбкодингу, щоб перевірити гіпотезу, отримати перший фідбек або залучити інвестиції. Для них цей реліз показує, куди рухається ринок. Але я не питаю себе, чи ставити поруч із Bubble ще один складний інструмент. Мене цікавить інше: які звички звідси забрати, а що залишити великим компаніям. Про це окремо: Copilot Code (Frontier → Work.

Що відрізняє новий білдер від звичного AI у базах даних

Спершу я відокремив цей продукт від того, що вже знав. Новий App Builder не є помічником «Ask AI», який складає окремі SQL-запити чи REST-виклики в класичних додатках Retool. Це окреме середовище. Застосунок у ньому збирається в діалозі з AI-агентом або через код у середовищі Retool.

Каналів розробки два, і працюють вони по-різному:

• MCP-сервер Retool (https://<instance>.retool.com/mcp, OAuth 2.0): працює за схемою «агент-до-агента». Ваш локальний AI-асистент надсилає запити агенту Retool, а код з'являється безпосередньо в хмарі платформи. Так можна генерувати інтерфейси, імпортувати React і керувати ресурсами. Але генерація застосунків витрачає і ваші кредити, і AI-кредити Retool (окрім варіантів Enterprise BYOK).
• Локальний CLI (retool init, clone, check, push, publish): ви завантажуєте код застосунку на свою машину, перевіряєте його і деплоїте. Команди CLI не витрачають AI-кредити Retool. Зате потрібні Node.js 22, pnpm, git і, згідно з даними пакета npm, платна підписка.

Що корисно перейняти соло-білдеру на Bubble

Коли треба перевірити продуктовий задум на реальних користувачах за лічені дні, кожне технічне ускладнення б'є по швидкості. Проте у вайбкодингу та системних білдерах я бачу три дисципліни, які прямо підвищують якість запуску на Bubble: Про це окремо: Microsoft Canvas Studio (preview): agentic.

1. Контроль версій. Git-репозиторій для цього не потрібен. У Bubble є вбудовані гілки (branches) і точки збереження (savepoints), ними й користуйтеся. Типова помилка новачка: вайбкодити фічі прямо в тестовій гілці, не зафіксувавши робочий стан. Правило просте. Кожна нова гіпотеза чи фіча йде в окрему гілку і проходить чітку перевірку перед злиттям.
2. Перевірка перед публікацією (check перед publish). У CLI Retool перевірку винесено в окрему команду check. У Bubble і no-code вайбкодингу я раджу робити те саме вручну: складіть короткий чекліст сценарію користувача (авторизація, запис у базу, оплата, повідомлення про помилку) і проходьте його перед кожним деплоєм у live.
3. MCP та AI як суворий контракт, а не магія. Коли AI генерує логіку, API-коннектори чи структуру даних, я ставлюся до нього як до виконавця з обмеженою роллю. Спершу задайте точний формат вхідних і вихідних даних. Хаотичні промпти ламають базу даних MVP.

Що не потрібно копіювати з корпоративного шару

Маркетинг вендора обіцяє прискорення розробки у 2–4 рази. Але корпоративний шар Retool зроблено під зовсім інші задачі: багаторівневий аудит дій (audit logs), складне розмежування прав (roles/groups), перенесення релізів між кількома інстансами (multi-instance release promotion), суворі політики безпеки (CSP).

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