Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Architecture Behind Lovable and Bolt

beam.cloud

Post reply on HN
Print view View original

21–30 of 33 posts

Re: The Architecture Behind Lovable and Bolt

#21

Post by atleastoptimal »

WXLCKNO wrote: post #2

"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...

Re: The Architecture Behind Lovable and Bolt

#22

Post by theamk »

atleastoptimal wrote: post #21
WXLCKNO wrote: post #2

"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...

Re: The Architecture Behind Lovable and Bolt

#23

Post by exiguus »

tezza wrote: post #3

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.

Re: The Architecture Behind Lovable and Bolt

#24

Post by nichochar »

tezza wrote: post #3

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’

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)

Re: The Architecture Behind Lovable and Bolt

#25

Post by transformi »

nicolaslecomte wrote: post #13
bnchrch wrote: post #5

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?)

Re: The Architecture Behind Lovable and Bolt

#26

Post by kadder »

tezza wrote: post #3

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’

[dead]

Re: The Architecture Behind Lovable and Bolt

#27

Post by joshdavham »

paulgb wrote: post #18
tezza wrote: post #3

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’

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 us…

> 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

Very well put. Maybe a will try out vibe coding some time after all.

Re: The Architecture Behind Lovable and Bolt

#28

Post by api »

joshdavham wrote: post #27
paulgb wrote: post #18

Earlier quoted context omitted.

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 us…

> 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 Very well put. Maybe a will try out vibe coding some time after all.

Even better use it to prototype, to play, to fling spaghetti at the wall. If something works but the AI code sucks, rewrite the thing that works by hand.

This could massively accelerate experimentation.

Re: The Architecture Behind Lovable and Bolt

#29

Post by throwacct »

nichochar wrote: post #24
tezza wrote: post #3

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’

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,…

Is this similar to the "vibe" code tool sold to Wix?

Re: The Architecture Behind Lovable and Bolt

#30

Post by throwacct »

exiguus wrote: post #23
tezza wrote: post #3

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.

This is a sane approach. I'll try to propose this to the team to see if this sticks, hehe.
Post reply on HN