If you only ever run one coding agent, you do not need most of this. You're also probably working more inefficiently than you could be.
If you run...
For further actions, you may consider blocking this person and/or reporting abuse
To your question: in our setup the expensive collisions were never in the repo. We run three agent sessions in parallel on one machine, and the two that cost the most time were:
Duplicate work. Two sessions picked up the same task from a shared notes file, because "read the notes first" was advice, not a gate. What fixed it was an explicit claim step: a task is claimed (who, when) before any work starts, and a stale claim has to be taken over visibly, not silently redone. Your
intent publishis the same idea one level up, with scopes instead of task ids.Shared resources that are not files at all: one screen and mouse, one logged-in browser profile, one test phone. Worktrees give each agent its own checkout, but if two agents drive the same GUI, one types into the other's window. We ended up with a lease (acquire before touching the GUI, release after, a holder that goes quiet for ~30 s counts as dead) rather than a merge-time check, because by merge time the damage is a sent message, not a diff.
So I'd add "anything with side effects outside the repo" to your list of things worktrees don't isolate. On scope hierarchy: a class-level replace matching every method-level scope under it sounds like exactly the pair your PaymentService example needs.
the lease for GUI control makes sense, do you think other shared resources might need a similar approach?
Yes, anything where the damage happens outside the repo and can't be merged away. The ones that bit us, roughly in order:
Rule of thumb we ended up with: if it can be duplicated per agent (port, DB schema, checkout), duplicate it; if it can't (one account, one phone, one screen), lease it and log every side effect.
Our costliest collision was agent-versus-gate, not agent-versus-agent: a batch of otherwise-clean commits swept a gated post onto the live site — no overlapping lines, every diff merged fine, and the outcome was still wrong, because the violation was against an intent, not against any text. That's "Git compares text, not intent" with receipts attached, and it's also why the fix wasn't task splitting: the checks that came in afterwards run on the merged result and look for policy breaks specifically. On your scope-hierarchy question — a whole-class change contradicting a method-level one is exactly the shape our incident had, one level up: file-level changes contradicting a repo-level rule. Nothing in any diff could ever have shown it.
This is exactly why we built Foremerge. Agents declare their intent and claim scopes before writing, so potential conflicts show up early, not just in the text. It helps catch those issues before they affect the merged output.
foremerge.com
The collision that costs me the most time across parallel sessions is contract drift on shared test fixtures and mock generators.Two agents get tasks on separate modules that both depend on a common factory or schema definition. One agent refactors a mock helper to satisfy a new nullable field, while the other updates an integration test assuming the old fixture signature. Neither touches the other's source files, Git merges the branches cleanly, and the failure only surfaces when the full test suite runs on the merged branch.The second messy failure mode is lockfile churn. Even with separate worktrees, if two agents add different packages around the same time, merging their pnpm or poetry lockfiles creates merge conflicts where automatic resolution silently drops dependencies or scrambles transitive pins. Enforcing that only the primary integrating branch runs package additions stopped the lockfile corruption.
We built Foremerge to address contract drift. It should solve your use case perfectly. Agents log their intent and claim a scope before they write, so conflicts show up while they're still plans. This helps catch issues before they impact the test suite.
foremerge.com
On the scope hierarchy question: matching a whole-class scope against a method scope matters a lot in practice. When one agent touches PaymentService#authenticate and another replaces PaymentService, every human reviewer reads that as one story, so flagging that overlap would catch exactly the merge-time failures git stays silent on.
How do you flag that overlap in your workflow? In Foremerge, agents log their intent and claim a scope before writing, so conflicts show up while it’s still a plan.
The question I’d most like answers to: if you run two or more agents on one repo, what are the collisions that cost you the most time? Was it two agents in the same file, or two that never touched the same file and still contradicted each other, like the PaymentService one above?
Also let me know whether scope hierarchy would matter for how you work: a change to a whole class not matching a change to one of its methods. It’s the biggest gap our own replay showed, and I’d rather build it from real cases.
If you’ve hit the replace-versus-extend failure (two agents, both correct, jointly wrong), I’d love to hear how you caught it. In our case it was the merged tests, a day later.