I think it's a really sound idea. It sounds feasible, and useful.
The only problem is your lack of a moat. It's going to be a lot easier to integrate into an existing merge tool. Your users will likely also be using an AI-capable IDE, and its own builtin version control software.
For users banging out code with vi and the command line, I don't see them using it. And if they did, I don't see them paying for it.
It sounds like an idea you should be able to bring to one of the big IDE developers (or perhaps Gitlab?) and say, "Hire me and I'll make this happen." Maybe they'll help you patent it, to preserve some kind of moat. At least, that would get them on the market first, giving them a branding win.
Thanks for the feedback, I too thought about the moat here and there's technically none. But on the flip side, there's mostly no moat now a days for any product/tool imho. Correct me if I'm wrong.
Definitely I understand this is easily doable for an AI-native IDE like Cursor and they already have the distribution. I'm collecting more feedback as we speak and fingers crossed.
As a developer, I've faced this issue constantly and I believe there is a great potential for an AI agent to autonomously resolve merge conflicts from upstream repositories. I wanted to take the HN community feedback.
The only problem is your lack of a moat. It's going to be a lot easier to integrate into an existing merge tool. Your users will likely also be using an AI-capable IDE, and its own builtin version control software.
For users banging out code with vi and the command line, I don't see them using it. And if they did, I don't see them paying for it.
It sounds like an idea you should be able to bring to one of the big IDE developers (or perhaps Gitlab?) and say, "Hire me and I'll make this happen." Maybe they'll help you patent it, to preserve some kind of moat. At least, that would get them on the market first, giving them a branding win.