Ask HN: Why don't LLM dev tools used by "vibe coders" enforce main/develop?
That viral replit story [0] is stuck in my head. Even if we had AGI vibe coding nirvana, we would still need at least a main/develop branching strategy, wouldn't we?
This feels like such an obvious self-own on the part of the tool devs, that I feel like I must be missing some level of complexity in the implementation.
Why do seemingly all of these LLM-based dev tools appear to default to developing in prod?
For a moment I thought that merge conflicts were the reason, but a single dev and simple main/develop git branching strategy, would never have merge conflicts if hot-fixes were not allowed, correct?
Am I missing something, or are these currently caveman dev tools?
[0] https://news.ycombinator.com/item?id=44625119
My $.02, is these are authoring tools, and not aware of the SDLC. That’s a different/related core competency that the tools would need to perform well in, and because it varies widely it would need to perform well across a broad range of use cases. Git branching is just one small piece, and even that assumes that Git is used and that the user of the tool uses that branching pattern.
Further, this branching pattern would need to be supported across tools - like the MCP server for talking to a database - and now it becomes really complex.
I’m sure we’ll get there, and having these kinds of problems will be what drives businesses to build it.
Thank you so much for taking the time to reply.
Supabase seems like they are ahead on this problem, but yeah, still early days.
I spoke with a Supabase dev about this type of problem a while back on reddit, and that was in reply to their launch of their own MCP, to replace vanilla Postgres MCP.
The conversation started with my typical lack of decorum: "Wait, the launch of Supbase MCP is cool, but you allow writing to the DB via MCP?! I have been using the old MCP for months, and when I look at the Sonnet 3.5 generated migrations, there are always misunderstandings that I must correct. Ffs, give me a --read-only flag! In fact, default to that or there will viral reddit/hn/twitter posts about 'Supabase destroyed my DB!'"
The first immediate reply was "We plan to use branching for that" - which seems like an attempt to address the back end branching issue that I believe you and I raised.
To their credit, 3 days later I got a response ~"Yeah, that actually makes sense, we will include a --read-only flag option for our MCP."
However, I cannot imagine how expensive it would be to implement their original idea "when you use write MCP, we will create a new branch."
Yeah... this would need to be driven from IDE, and coordinated with Vercel or Netlify. This seems so expensive.
These are indeed early days. I feel like we are watching the first LLM dev caveman paintings. I suppose it will take a few months/couple years for the LLM tools to catch up to 2010's era workflows.
I suppose that maybe the reason that there is no frontend main/develop in the vibe tools is that the DB sync is expensive. Whoever nails that first will be interesting.
I wonder if we will soon see some adopted standard, which at least separates prod/not prod.
Since git is very versatile and there are huge differences in written documentation vs practice, as well as practice vs best-practice, I imagine it quite difficult to prompt the LLM in the right direction.
getting git strategies right by an LLM is one of those things of which I am not sure if it is going to be achieved before we have AGI or after that.