Git worktrees give each coding agent its own checkout, so the agents stop overwriting each other's files. They do not remove the collision between ...
For further actions, you may consider blocking this person and/or reporting abuse
Parallel agent runs make generation feel free, but the verification burden scales quadratically with concurrent branches. Without an upfront contract on shared interfaces, human engineers just trade token latency for integration triage. In practice, serializing dependent tasks still costs fewer total developer hours than resolving semantic drift after two clean Git merges.
Parallel agent runs can indeed complicate verification, but that's where Foremerge comes in. It lets you parallelize dependent tasks while still minimizing semantic drift. We built it to handle exactly this challenge for GPTree's own agents. Do you keep everything with dependancies serialized?
Worktrees are an isolation primitive, not a coordination protocol. The useful companion is a small ownership map: which files or boundaries each task may change, what interface it must preserve, and how conflicts are resolved. Then merge time becomes a validation event rather than the first moment two agents discover they touched the same design.
Agreed that worktrees are an isolation primitive, not a coordination protocol. Foremerge is the co-ordination protocol.
The map only helps if something checks it when work is planned, not just when it’s merged. If two tasks each write down “I own the billing boundary” and nobody compares the two notes, you’re back to finding out at merge. The case from the post is the worst version of this. The edits don’t touch the same lines, Git merges them cleanly, and the contradiction only shows up in behaviour. That’s what got me building Foremerge: each agent declares what it’s about to change before it starts, and overlaps get flagged then.
How do you handle the “what interface it must preserve” part. Is it written down per task, or enforced by tests on the boundary?
Nice! Yeah, I use worktrees when I use subagents. I noticed in my case anything beyond 4-5 sub agents, AI spends an inordinate time resolving the merge issues. I would occasionally limit the sub agents to perhaps 4. Or at times I would launch 6-7 sub agents but I would merge 1 or 2 at a time :) a bit of a trial and error there. I usually do this for a milestone where many work items end up touch the same group of files. Few other tricks, I would do are like when merging say 1 tree at a time, I ask it to only merge, run few key tests and skip lint etc till all merges are done. Also I ask it to hold back any docker tests till final as that setup just increases time. Sometimes I live a bit dangerously and let it merge and run tests, lint, all that after all merges are done especially when my test suite crosses 1K mark :)
Thanks Debashish, this is a really useful field report. The 4–5 ceiling is interesting, what I’ve seen is 3 or more conflicts become much more difficult to resolve. Past that, the agents spend more time untangling each other than doing the work.
Merging one or two at a time and running only the key tests until the end is a smart trade. We only run our full test suite once prior to staging.
One question, since it’s the part I’m digging into: when merges go badly for you, is it mostly textual conflicts in the shared files, or clean merges that then fail tests? The second kind is the one I find hardest to see coming.
Let me know if you give Foremerge a try and how that improves your conflicts across multiple agents. Its a 30s setup if you drop the quick prompt into you agent.
Thanks - I will dig into Foremerge. When merge issues, not conflicts, where code compiles but causing test failures or lint issues, I pause and ask harness to merge and remove code conflicts. And let the final test pass and lint run clean out all issues. I found it’s easier and faster than doing fixes between merges. Again, my experience, I find it’s easier to see all test and lint failures and clean up in 1 shot. Note, this is why it’s important here is how big of a problem did I start with subagents. Too big, the tax is high. Too small, subagents usage has diminishing returns. I would love to hear how others do it. I am focused on getting to a working code, clean code, the fastest possible route and least token usage
Two agents, two worktrees, no merge conflict, broken code. Worked example in the article.
One agent retires PaymentService. The other adds a PayPal method to it. Git compares lines, not plans, so the merge is clean and the new method hangs off a dead class.
Merging into a throwaway branch first is the cheap check for the clean merge that still breaks.
It can help but it doesn't always reveal logic errors that arise from those merges. In our setup, we use agents to review the code against a plan and the Foremerge output, which helps us ensure that any changes align with our intended functionality before merging. Have you considered automating the validation of your logic in addition to checking for merge conflicts?
Automating that check sounds worth it for the cases Git misses. The plan review is where the logic gap would show up first.
Worktrees do not remove the collision between two coding agents. They move it to merge time, where it is more expensive and sometimes silent.
The clean merge example is the most useful part for me, because it shows how a merge can succeed and still leave the code in a confusing state. Testing the combined result before it lands feels like the practical takeaway here.