This is the first week in years that I’ve been excited about building in Bubble. It is the first time that the product has felt “too good to be true.” Where once I felt dread at the thought of opening the editor, I now feel hope. Bubbling is addictive again! With that said, I also want to point out some opportunities for improvement, much of which the team seems to already be aware of (this is itself a promising signal).
First, the good. In very simple terms, this recent release has obviated the need to fix critical issues with Bubble’s editor. In colloquial terms, it has “wiped Bubble’s ass.” The 1975 era expression composer which only allows left to right editing and breaks in the middle of complex expressions no longer presents an urgent need to be fixed/revamped, because the AI Agent/MCP can simply just brute force the complex expression for you. The lack of something as simple as find & replace no longer matters, because the AI Agent/MCP can simply just brute force the changes for you. For nearly* every deficiency ( *you still can’t bulk order option sets even now), the AI Agent/MCP can just brute force its way through. And so on. It no longer feels like a waste of time to improve my app. This will hopefully also free Bubble’s engineering team up to focus more on performance, server-side rendering, scaling, backend functions, etc.
Visual editing + LLMs have a great back-and-forth dynamic. Sometimes I want to iterate in the editor to instantly see the changes or go by my intuition. Then when I’m happy with one change I can just say, “now do this to every other element in this group.” Or if I’m feeling lazy and I want to make a quick simple fix that would require me to jump through 5 menu options, I can just tell the AI Agent to do it. I have yet to encounter a single Bubble “issue” from either the AI Agent or the MCP.
Which leads me to the bad: The AI Agent is extremely frustrating for anything outside of simple point changes. It cannot “make this page responsive” or one-shot relatively complex features. In fact, as you progress through multiple turns, the output gets worse and worse (beyond what would be expected from traditional “context rot”), to the point where it feels like I’m using an AI model from late 2024 or early 2025 (it really feels like Sonnet 3.5, I don’t know how this is possible!). Once I saw Emmanuel quote a statistic about how apps started with the Bubble agent have higher 2-week retention, but I think the team needs to take a harder look at the analytics (maybe longer time intervals, paid conversions, etc.) because something is very wrong here. If I were a new Bubble user using the AI Agent, I would absolutely despite Bubble, trash the product, and never use it again. It’s an exercise in frustration and a complete waste of time for anything outside of simple point changes. Furthermore, the monthly usage is equivalent to the 5-hour usage of a $20 AI plan, so it is a fundamentally unserious option for doing serious work, even if it actually worked. From a business point of view, I can see the potential upside in buying tokens in bulk at a discount and reselling them at a higher rate, but I’m not sure the unit economics of this are sustainable in the long-term, and the product is simply awful right now.
A lot of this likely has to do with the fact that the Bubble Agent can’t see what it’s doing and readily admits this through the UI. How is it possible for Bubble’s home-grown AI Agent to not be able to render the client and preview changes when the MCP Agent + a frontier model will spontaneously generate an entire rendering script to view changes through Playwright? An entire engineering team couldn’t programmatically implement something than LLM can generate on the spot? Very bizarre. I think this is a dangerous release and it should actually be disabled until you achieve parity with the MCP.
Which naturally leads me to the amazing: depending on which model you use, the MCP can automate weeks of Bubbling in hours with high taste and good decision-making. This is very model-dependent because using Astra + Bubble MCP to make a page responsive resulted in a frankenslop app where the output actually looked quite good on mobile, but I had no idea how it had achieved the result. There weren’t any conditionals on the elements. After a bit of sleuthing, I found out it had created a weird-looking unreadable jumble of HTML and CSS to handle all the responsive parts. This basically defeats the point of Bubble because then it’s just vibe coding with an extra step in between. The purpose of Bubble is to actually be able to understand what the model is doing to my app. So I switched to Opus 5.5, which actually made the changes in Bubble, and somehow created a near-flawless mobile implementation of the desktop view using 95% native Bubble. With that said, if you actually observe the chain of thought, you can see that there’s still a lot of room for improvement for the MCP.
If you don’t link it up to a repository with a “handover doc” or a single source-of-truth, it will spend the first 20 minutes of any prompt figuring out ways to render the site from scratch. A complete waste of tokens and Bubble’s resources as well. It also has no idea what the limitations of Bubble’s MCP tools/programming language are (e.g., Found it: Bubble dates only have </> (no ≤/≥)). It will try to do things and then discover that they’re not possible, before finally figuring out what to do through a bunch of needless trial-and-error. It’s like a 150 IQ child with zero knowledge of the world that still manages to solve a complex puzzle through sheer grit and intelligence instead of a known heuristic that would make it trivially easy. Bubble needs to provide the MCP tools with “best practices” and “known limitations” instead of expecting users to build their own internal Bubble manual from scratch in a Github repo through trial and error. There also needs to be better observability about what’s being changed, because right now the only way to see a changelog is by inspecting said Github repo and reading a bunch of lines of text. It feels kind of spooky to just have to trust that the MCP is making the changes you think it’s making. In this narrow sense, the AI Agent is actually a better experience than the MCP currently, since it exposes all the changes in the UI. In the AI era, it makes sense to expand the restore option across paid plans since the MCP/AI Agent can theoretically make changes that you only discover much later down the line. If you are going to increase the price of the starter plan, maybe also allow restoring your app from 7 days ago. 2 days is simply spooky. Even 14 days on the Growth plan might be too little when hundreds of changes are being made in a very short span of time.
Continuing on the MCP, several tools don’t seem to work, like passing a user token or getting a preview link. Other tools are just missing, like for example reordering option sets, renaming conditional, or editing conditions. Bubble needs to keep working on the MCP tools and making them more robust. It would be nice, for example, to be able to query live data. Just add a checkbox on the privacy rules for “MCP.”
Other downsides of the MCP include technical and security aspects that new users wouldn’t understand, like for example if your test version is locked with a password (as it should be), you would need to know that the MCP server can’t access the test version unless you provide it with secrets, but you have to do this in a secure way (depending on the harness) instead of just pasting it in the chat. Additionally both Anthropic and OpenAI have their own way of dealing with permissions, with Anthropic’s being more granular but also more annoying to set up for the first time. Ideally there should be a “recommended” set of permissions a user can use out of the box which strikes a balance between constant babysitting and zero oversight. In an ideal world, that’s what the AI Agent is, but only if it lets us choose a model. The ideal product is a mix of the AI Agent and the MCP, an opinionated Bubble harness that is model-agnostic with a Bubble-optimized “auto mode” and Bubble-optimized everything else that makes it fast and token-efficient (yes, this sentence is bait for a specific prominent member of the Bubble community). If you can’t deliver on that, then please focus on the MCP over the AI Agent.
So yeah, I feel like the world is my oyster again, building feels joyful instead of tedious, AGI has been achieved, Bubble is #back, etc.
Appendix/Bonus Section
Below are Astra’s thoughts on what MCP tools the Bubble team should work on, which overlap with some of the ones I listed earlier. Maybe something for the team to look at, I’m sure there’s some good ones mixed in with the slop.
Critical
These are the foundations for approving and applying changes reliably.
-
1. Preview changes before applying them. Show a readable changeset, affected objects, before-and-after values, and validation results before anything is written.
-
2. Approve a complete, reviewable changeset once. Support task-level approval with clear scopes for the app, branch, environment, and types of changes.
-
3. Apply exactly the revision that was reviewed. Detect intervening edits so an approved changeset cannot silently be applied against an outdated app state.
-
4. Reliable status checks and retries. Provide persistent request IDs, completion checks after timeouts, and duplicate prevention when requests are retried.
High
These would close major gaps in editing, troubleshooting, testing, and maintaining existing apps.
-
5. Searchable change history and recovery. Provide a durable record of changes, their authors, affected branches, and available recovery actions.
-
6. Report what the current connection can actually do. Explain effective permissions, supported environments, sign-in restrictions, and unavailable tools before execution.
-
8. App-wide search and “where used.” Find exact references throughout the app and preview the impact of coordinated replacements.
-
9. Runtime logs and workflow traces. Expose errors, executed steps, conditions, relevant values, and timing.
-
10. Expression evaluation and runtime state inspection. Inspect evaluated expressions, element values, custom states, and conditional results in an authorized test session.
-
11. Executable functional tests. Run tests and backend workflows with controlled inputs, assertions, pass/fail results, screenshots, and traces.
-
13. Reliable authenticated previews. Provide a supported authorization flow for password-protected previews and app-user test sessions across compatible sign-in methods.
-
14. Effective privacy-rule testing. Show what a selected user can access and explain which rules produce that access.
-
17. Complete option-set management. Edit existing sets, attributes, and options; change saved ordering; preserve identifiers during edits; and identify affected references.
-
25. Permission-scoped, read-only live-data access. Support production diagnosis with explicit restrictions on data types, fields, filters, and record limits.
-
27. API Connector initialization and response schemas. Initialize and reinitialize calls, preview outgoing requests, and define response schemas from supplied samples.
-
28. Secure completion of integration authentication. Provide protected credential entry, OAuth handoffs, and authentication-status checks.
Medium
These would improve completeness and efficiency, particularly for larger apps and more involved maintenance tasks.
-
7. Bulk reads and consistent app snapshots. Read multiple nodes efficiently and retrieve selected definitions from a consistent revision.
-
12. Reproducible test data and integration mocks. Create, reset, and clean up fixtures, simulate API responses, and establish explicit test isolation.
-
15. Performance and workload diagnostics. Identify expensive searches, slow workflows, and workload usage, with comparisons before and after changes.
-
16. Scheduled workflow management. Inspect queued jobs and execution history, and cancel, reschedule, or retry selected jobs.
-
18. Direct editing of existing conditionals. Update conditions and overrides in place using stable identifiers.
-
19. Schema migrations. Support field-type and list-status changes with conversion previews, backfills, dependency updates, and resumable progress.
-
20. Copy selected components and extract reusables. Copy element subtrees and workflows across containers, extract groups into reusables, and support mobile-view cloning.
-
23. Structured app-settings access. Read and update supported app-level settings through documented schemas and permissions.
-
24. Complete file and asset management. List assets, inspect usage, upload supported local files, replace assets, and remove unused files.
-
29. Native branch and revision comparisons. Return structured differences across workflows, expressions, privacy rules, schema, and UI definitions.
-
30. Branch synchronization and merging. Preview conflicts, select resolutions, and synchronize or merge branches.
-
31. Reviewed deployments and release visibility. Prepare and deploy an explicitly approved revision, with deployment status, release history, and recovery information.
Low
These are useful refinements to prioritize after the core editing, approval, and testing capabilities.
-
21. Global Expression refactoring. Detect repeated expressions, extract shared expressions, replace usages, and coordinate signature changes across call sites.
-
22. More complete style and variable maintenance. Edit existing style conditions and support variable consolidation, reference replacement, and unused-variable cleanup.
-
26. More efficient data queries. Add field selection, aggregate summaries, and structured exports to reduce unnecessary data retrieval.