Rendered at 04:51:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
naw103 3 hours ago [-]
Here are some questions I normally get asked:
What does an agent do with it?
The agents publish intents and scopes of what they are about to change (at the start and right before they make the change if its something different). Foremerge returns a signal of related work already in progress on different worktrees (even across different branches or in the same worktree) and the agents/humans who are working on it. Agents can then negotiate on the solution prior to writing any code or generating any conflicts and Foremerge runs an acceptance check (defined by a human) prior to commit.
Why advisory claims instead of locks?
Once a repo gets busy locks turn into a queue and deadlocks. A lock that the agent cant see the reason for is the worse case scenario so the hard gate is at the acceptance not the start.
What are the gaps?
Ultimately Foremerge is deterministic (does not use any judge model) so it can detect some false positives and negatives though we see that very infrequently and worst case it would have likely of been missed anyway without Foremerge. Acceptance also dosnt currently compare the actual diff by default and there are no push notificiations so the earlier agent only learns about the conflict on its next status check (both of these are on the roadmap for the next version)
I'm curious to know what's everyone custom solution to this problem ? Before AI and with AI.
It was already a problem for me before agentic AI coding : multiple developers can work on overlapping code and you always need someone to merge everything properly. Even if the overlap is very small it does add a burden to development. Not an issue anymore in 95% of cases if that person uses AI to solve conflicts, but now that "others developers" are swarm of AI agents, this problem isn't trivial to solve.
naw103 4 hours ago [-]
I think before AI was writing most of the code and with small teams the solution was probably just ownership and talking (and meetings about meetings). Things moved at a pace where it was more possible to have someone oversee this, though I agree on larger teams it has always been a problem. I think Foremerge solves that too even without agents but the manual overhead outweighs more of the cost that it does with agents.
Even if you can use AI to resolve the conflicts at PR time, you need the right context and you've already burned through tokens building and now even more fixing. Scale that across 10's or 100's of agents and you have a mess of each one running in its own direction.
The custom solution for us became one worktree per task, and before an agent writes a line of code they lease/commit their intent and scope into an immutable log and verify drift as the acceptance check...thats now Foremerge
wilsprouse 4 hours ago [-]
This is awesome. I think the current version control mechanisms are meant for humans, not agents. I'm still trying to think of a scenario where an agent needs to see a git diff. I think something like this could be the future of version control in an agent first world
naw103 4 hours ago [-]
Thanks! It' become a critical part of our development flow at GPTree since I built it back in Jan. So much so thats the reason I decided to open source it. I don't neccessarily see it as a replacement for version control, the diff is still doing most of the work at the point that really matters but Foremerge prevents those conflicts before you get to that point. Declared intent is what the agent thinks it will do and the diff is what it actually did, and the changeset being accepted currently depends on that diff.
Where I definitely agree with you though is that not human or agent should be discovering a conflict by finding it in a diff. Its too late by that point and its the layer that git dosnt solve.
ttoinou 4 hours ago [-]
Before editing each agent publishes an intent and the scopes it will change, with the operation it plans to complete on each one.
But we don't know in advance what we will need to change in our current task. And even if we did, there are always side effects.
naw103 3 hours ago [-]
You're right when the agent starts with a plan and no file list and the files only exist after edit, but the way I designed Foremerge to work, it works anyway. The initial intent does not have to be complete, it just has to be right about any destructive parts. That is why Foremerge works by declaring intent as prose, not as a file list or methods. The agents them selves determine if something conflicts based on the signals Foremerge returns. It only asserts a HIGH warning on declared scope and only a HIGH signal blocks acceptance (to avoid false possitives based on prose alone). The declaration can change at any point and the auto installed skills into the agents encourage such (the initial intent is released by the agent and the new intent is committed)
ttoinou 3 hours ago [-]
I doubt this can really be deterministic, but maybe this is where Jev models can be useful
naw103 3 hours ago [-]
You might be surprised, it works exceptionally well. If you decide to give it a shot and run into any issue feel free to reach out to me with any feedback.
... and Jev is a sore point for me right now lol we have been training our own decision intelligence model, Corgen, for the last year and a half. We're already using it in GPTree but havn't released it to the public yet. Im actually in the process of running it against JevBench right now to see how it stacks up.
What does an agent do with it? The agents publish intents and scopes of what they are about to change (at the start and right before they make the change if its something different). Foremerge returns a signal of related work already in progress on different worktrees (even across different branches or in the same worktree) and the agents/humans who are working on it. Agents can then negotiate on the solution prior to writing any code or generating any conflicts and Foremerge runs an acceptance check (defined by a human) prior to commit.
Why advisory claims instead of locks? Once a repo gets busy locks turn into a queue and deadlocks. A lock that the agent cant see the reason for is the worse case scenario so the hard gate is at the acceptance not the start.
What are the gaps? Ultimately Foremerge is deterministic (does not use any judge model) so it can detect some false positives and negatives though we see that very infrequently and worst case it would have likely of been missed anyway without Foremerge. Acceptance also dosnt currently compare the actual diff by default and there are no push notificiations so the earlier agent only learns about the conflict on its next status check (both of these are on the roadmap for the next version)
There are more questions and answers here: https://foremerge.com/blog/31-questions-coordinating-paralle...
It was already a problem for me before agentic AI coding : multiple developers can work on overlapping code and you always need someone to merge everything properly. Even if the overlap is very small it does add a burden to development. Not an issue anymore in 95% of cases if that person uses AI to solve conflicts, but now that "others developers" are swarm of AI agents, this problem isn't trivial to solve.
... and Jev is a sore point for me right now lol we have been training our own decision intelligence model, Corgen, for the last year and a half. We're already using it in GPTree but havn't released it to the public yet. Im actually in the process of running it against JevBench right now to see how it stacks up.