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
threecheese•6mo ago
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.
consumer451•6mo ago
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.