A CLI agent can pick up any triage issue, but it wonāt do it automatically in the background. Buildprint Web handles spinning up the agent/detecting when one comes in and dealing with it.
Itās actually so cool, this was one we had come in today from a client.
It gives me just the right level of control + visibility into what itās doing. And lets me approve the agent to go and do a fix and/or to merge it when Iām happy.
Yeah thatās very impressive I canāt wait to get in there today and try it out! Thanks 
Hey @georgecollier Iāve been using Buildprint to understand and clean up a Bubble app thatās been running for several years. It has accumulated legacy workflows, poorly connected data structures, increasingly complicated privacy rules, and inconsistent styling with too many styles and inconsistent use of variables.
Seeing Migrate to Code got me wondering about Bubble to Bubble: using Buildprint to understand the existing appās features, flows and styling, then rebuilding in a separate Bubble app with a cleaner architecture rather than carrying across the technical debt.
Itās an event platform built around relatively short-lived use cases, so we wouldnāt need to migrate historical data. We could keep the old app running for existing events, bring new users into the new app, and transition existing users when they create something new.
How would you approach that with Buildprint? Put another way, if I were rebuilding this from scratch, what would the ideal specification look like, in terms of format and content, for Buildprint to build from?
People will say āoh give the agent access to your Bubble appā (to build the new Bubble or code app) but I think this is a terrible thing to do
Agents tend t ofollow what they see and take it for granted that the new app should behave in the same way.
Your new agent needs product guidance, not technical guidance. If you want to use LLMs to automate it, then use Buildprint to generate product docs which explain how it works and do NOT talk about the technical side.
Thatāll allow you and your new agent to build a new one from first principles.
When rebuilding open ended problems (like a new app), use the /grill-me, /prototype skills first.
ICYMI, conversations now expire after 14 days of inactivity (14 days since the most recent user message). The conversation history exists, and it can be forked, it just canāt be resumed. This is because of costs of storing the sandboxes agents run in.
This affects, basically nobody.
The fun part is that Buildprint is being used so much that we have enough data that all graphs look smooth!
There have been 120,000 agent turns on Buildprint!
I recently realised that Buildprint has a ton of data about how people build on Bubble. I was able to find a lot of interesting insights that I think you will find useful, particularly with how you think about using AI on Bubble.
So, hereās some insights from 600,000 turns that have run on Buildprint.
Compared with 3 months ago, median agent turns are getting faster on Buildprint. Meanwhile, the longest turns are getting longer.
This is super interesting.
There are a lot of ways you could read into this data, but to me it seems that some combination of the following are true:
This means that if youāre not already, you can begin to trust Buildprint with long-horizon, multi-step work that build entire features end to end.
The top 10% of Buildprint users represent almost 50% of all messages sent. Developers that can use AI effectively are significantly more leveraged than those that.
The amount each developer is using Buildprint is growing over time.
Compared with the previous months, people are merging work faster with Buildprint. 60% of Buildprintās work is now merged within the first hour of it finishing (side note, there have been over 6,000 merges performed by Buildprint in the last 90 days!). There are a couple of main reasons:
We recommend avoiding āvibe codingā where you tell Buildprint to just solve a problem. However, Buildprint is now so accurate that if you tell it how to solve the problem, you can generally trust that it solved it in the way that you asked, and there are unlikely to be issues in the editor.
In other words, if when conversing with Buildprint you can see what it has done, you donāt need to open up the editor to confirm it if you already understand how it works. That said, we recommend it as a matter of diligence on production applications.
When Buildprint launched, it was an MCP server that let you edit your app - very similar to Bubbleās MCP. After we hit diminishing returns there, we built BubbleScript, the TypeScript language for Bubble apps.
This is more token efficient and intuitive for agents. In the week after the switchover, the most complex work ran 45% faster with BubbleScript compared to the previous MCP server approach.
Interestingly, there was not much difference for read-only turns - likely because itās a lot easier to read JSON and understand whatās going on than it is to write it new.
Bubble MCP has some differences to what the Buildprint MCP previously did, but is still a JSON-based approach. If you want the fastest, most accurate, highest quality edits and iteration, then Buildprint is still the way to do that.
Buildprintās biggest responsibility is bugs and understanding. Only 20% of requests are entirely new features. Bugs are still what take up the majority of production applicationsā time. Reassuringly, a lot of Buildprint requests pertain to general questions and review about how the application works. Bubble developers in particular do want to understand how their app works - that will result in the best long term success for them.
I hope you found this interesting!
Buildprint will generate your design system in 2 minutes, coming soon 
Well the MCP refactored mine in 40 minutes, how about that? 
Exciting update!
Bubbleās new app generation improved, so Buildprintās must too!
Buildprint is now on-par or better than comparable prompts w/ Lovable etc on new apps.
Use /bootstrap to build a new Bubble app, or /design to implement a design system on a new app or existing app.
If interested, you can view the conversation here: https://www.buildprint.ai/c/bp_IvF1ke7mmTeAeS6kl--YfjbOGHDWhoY55fttvDdUExg
Or you can try it out @ https://buildprint-app-gen.bubbleapps.io/version-test/ (username = username, password = password). This has no manual tweaks / no work after the conversation shared above.
Hello! I keep getting āThe selected provider is unavailableā in one thread in Buildprint Web. The same model/provider is working fine in another thread, so it seems specific to this conversation.
I canāt get the affected thread working again. Any advice on how to recover it without losing the context?
Hi, please see the status message at the top of the page, weāre limited by an upstream provider at the moment but it will recover once service resumes. Sorry for the inconvenience
I dismissed that message 
, as I lost my internet briefly and wondered if it was just me!
Hey @georgecollier, I start to get this:
The sandbox runtime could not complete the request.
Can you help me here?
Me too! @georgecollier Whatās the ETA for a fix? The problem with creating such an essential tool is that itās essential! Help!
I think we are all getting this. See above, George mentioned in response to me that there in an issue with upstream provider. You should have seen a banner at the top of your buildprint (web) at least.
Does using Buildprint with the CLI still work? Is it just the Buildprint UI that is down?
CLI is down for meā¦ no working connection between Buildprint and Bubble
Hi Rafael, please see above:
Any offline features with an already cloned workspace will work, by cloning a new one / applying changes etc wonāt.
Crazy how this product gets better and better. I havenāt use bubble manually for months ā¦ GJ!
