4 ms·

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 b

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.

consumer451 1y ago
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.

consumer451 1y ago

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.