The Architecture Behind Lovable and Bolt

The Model-Context-Protocol/Mode Control Plane mix up seems to come up a lot in AI slop articles. I assume its because most AI models’ training cutoff was before Model context protocol became a big thing.

You can see it here too https://www.unleash.so/post/model-control-plane-mcp-for-ai-a...

Looks like AI slop

Currently, my team and I use v0, (and try Lovable, or Bolt) as tools for fast prototyping. Mostly, Product Owners and Architects create functional prototypes to support Epics. We use these prototypes to communicate with stakeholders, suggest solutions, and verify requirements. We discard the code from these tools and sometimes only take screenshots.

disclaimer: building a competitor (https://getmocha.com)

Lovable and bolt took a massive shortcut: they outsourced the backend to a third party (supabase).

This makes their ceiling to build "useful" software incredibly low.

The right approach takes a lot more time: pick an opinionated framework (think ror) and build up a full stack app builder from the ground up.

Took us months and months of work to get it working, but now people _can_ build "useful" software (thats our bar)

I had a trip with my family and used v0 to create an itinerary app with a timeline view of our flights, hotel/airbnb bookings, activities, etc.

It was the only thing I’ve 100% vibe-coded without writing a line of code myself. It worked pretty well. In an earlier era I might have used a shared google doc but this was definitely a better experience.

If you’re looking for things to use lovable/bolt for, I’d say don’t use it for software you otherwise would have written by hand; use it for the software you would never have written at all.

It depends how you define meaningful.

I built a daily newsletter with myself as the only recipient using v0. It hits the Gemini API and returns a short story based on a historical event from that day in the language(s) that I'm learning, along with a translation, transliteration where applicable, vocabulary list from the story, and grammar tips.

I've had work in the past where I spent way too long building email templates, so having that all done for me, along with the script for sending the mail, was useful. It took an afternoon project that I probably would have abandoned, into an hour project.

With that said, I'm pretty bearish on these platforms, because I think you can't build anything beyond a toy like that. And for toys or short scripts, Claude, Gemini, ChatGPT are usually good enough.

was quite impressed after building my label maker application [1] and stylex playground [2]. Had some real world needs and both were built in bolt with 99% of edits made through prompts. My tips would mostly center around:

- don't try to fix mistakes, revert and try with an updated prompt. the context seems to get polluted otherwise.

- don't treat it as a black box, inspect the generated code and prompt to write specific abstractions. don't just tell it what to build, but also how. this is where experienced programmers will get way more mileage.

[1] https://courageous-toffee-e5dd6f.netlify.app/

[2] https://venerable-melomakarona-255f96.netlify.app/

I recently played a little story based game that was hosted on Lovable. It worked reasonably well!

I too have tried them and would like to know this.

The only Beam-specific part are the sandboxes, but those can easily be swapped out for the vendor of your choice. The architecture we described isn't exclusive to our product.

Beam is fully OSS BTW: https://github.com/beam-cloud/beta9

Fighting what you perceive to be an ad... with another ad?

Blaxel & E2B use microVMs which is usually the standard for this kind of worloads. E2B feels more ephemeral while Blaxel feels more stateful, depends on what you're looking for. Daytona uses containers, less secure than VMs.

I heard Vercel & Cloudflare launched a sandboxes offering too. Haven't tried it yet but i'm naturally wary of the marketing fluff around their annoucements

what is missing for you?