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.
We initially wrote this for a less technical audience (where we spelled out MCP), then edited it to post here - it's not AI, it's just bad editing from my part. Fixed now.
I'm confused by your explanation. You originally spelled out MCP and then edited it. Did you originally have it as model context protocol and then edited it to model control plane? Or did you originally have it spelled out as model control plane and missed it in editing?
Q: Has anyone on HN built anything meaningful with Lovable/Bolt? Something that works as intended?
I’ve tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each ‘fix’ resurrecting a previous ‘break’
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.
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.
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.
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.
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
"We’ll be using FastMCP, a lightweight framework for building model-control-plane servers"
Article written by AI (and not reviewed by humans) that doesn't know MCP is model context protocol?
Or author being intentional for some weird reason?
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...
And soon, articles like that one will be ingested into next generation of models, and they would become a bit more nonsensical...
Looks like AI slop
We initially wrote this for a less technical audience (where we spelled out MCP), then edited it to post here - it's not AI, it's just bad editing from my part. Fixed now.
I'm confused by your explanation. You originally spelled out MCP and then edited it. Did you originally have it as model context protocol and then edited it to model control plane? Or did you originally have it spelled out as model control plane and missed it in editing?
Q: Has anyone on HN built anything meaningful with Lovable/Bolt? Something that works as intended?
I’ve tried several proof of concepts with Bolt and every time just get into a doom loop where there is a cycle of breakage, each ‘fix’ resurrecting a previous ‘break’
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.
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.
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)
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.
[dead]
Looks like an ad... BTW there are more sandboxes code- here is OSS one: Daytona https://github.com/daytonaio/daytona
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?
Isn't the whole point of Bolt/stackblitz that you can run node js clientside via wasm, so it's more lightweight?
Did they migrate away to a more server heavy model?
Im always hunting for someone whos solved "sandboxing" because setting it up myself is so damn painful.
Anyone ever find a good product in this space?
Beam seems close, but not quite
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
i see they mostly offer api to run the sandbox on their infra...is there a way to host the sandboxes self hosted?(how much memory/compute needed?)
what is missing for you?