Running AI coding agents in parallel on one repo

Running one coding agent is useful. Running three or four at once, each on its own branch, is where it gets genuinely fast: one agent on checkout, one on the coupon logic, one on tests, and a fourth fixing whatever the gate rejected.

It works well right up to merge time. Then two branches that each passed on their own turn out to have changed the same file, and you spend the next twenty minutes untangling work you never saw overlap.

I wanted to know how often that really happens, what actually helps, and whether the collision can be seen while the agents are still working instead of after. Here is what I found.

Why parallel agents collide

Giving each agent its own branch or git worktree isolates its working copy. It does not isolate the files the branches will eventually be merged into. Agents working on related tasks gravitate to the same places:

• Append-only files such as CHANGELOG.md, where every agent adds a line in the same spot.
• Registries and route tables where every new feature registers itself.
• Shared config and fixtures that every change touches a little.

In my own repo’s history, CHANGELOG.md was touched in about one commit in five. With several agents running at once, that file alone guarantees a conflict on almost every merge.

What I measured

To get numbers instead of guesses, I ran a small simulation on a throwaway copy of the nimblegate repo: 4, 8 and then 16 synthetic agents, each branching from the same point and making a realistic change, with three problems planted on purpose - two agents appending to the same file, a pair that breaks only when combined, and a pair whose tests pass alone but fail together. Every branch passed its own tests. It is a small synthetic test, not a benchmark, but the shape was clear:

• One file caused most of the conflicts. With git’s default merge, the shared CHANGELOG.md alone blocked 3 of 4 agents. Switching that one file to git’s union merge driver left only the single genuine conflict.
• Most “conflicts” in code were not real. Two agents adding different functions at the end of the same file is a textual conflict for git, but a syntax-aware merge driver merged it cleanly - while still refusing the one case where both changed the same line.
• Testing the combined result matters. The pairs that broke only together were invisible when each branch was tested alone, and caught every time the merged result was tested.
• Batching scales, one-at-a-time does not. Landing 16 branches one after another took 655 seconds on this repo; testing them in batches took 170.

Fixes that work today

None of these need special tooling.

Let append-only files merge themselves. A two-line .gitattributes entry tells git to keep both sides instead of conflicting:

CHANGELOG.md merge=union

Use it only for files where the order of added lines does not matter. See git’s merge attributes.

Try a syntax-aware merge driver. Mergiraf merges at the level of functions and statements, which clears the “two agents appended different things in the same place” conflicts that are most of the noise.

Split the work by files, not just by task. The cheapest conflict is the one that never happens. If you know two tasks will touch the same module, run them one after the other.

Name branches so you can tell agents apart, for example agent/claude/checkout-tax and agent/cursor/checkout-coupons. It costs nothing and makes every later question - who changed what, whose branch collided - easy to answer.

Have agents push checkpoints, not only finished work. Anything that watches for overlap can only see what has been pushed.

Seeing the overlap while the agents work

The fixes above reduce conflicts. What I still wanted was to know about an overlap the moment it appears, not at merge time.

That is a natural fit for nimblegate, the gate my agents already push through. It holds every pushed branch, so on each accepted push it compares the files that branch changed since the default branch with the other open branches. When two share a file:

• the push gets an overlap pill in the dashboard feed,
• an Overlaps page lists what overlaps right now and what was recorded, with both commits,
• and, if you turn it on, a push.overlap webhook tells whatever runs your agents immediately, so it can pause one, reorder the work, or let both carry on knowingly.

It is advisory by design. Two agents touching one file can be deliberate, so nothing is blocked, and the agent that pushed is told nothing - the signal goes to you and your orchestrator. You can click through it on the live demo, where two agents are working on the same checkout file.

What I have not built (yet)

The simulation made a proper merge queue tempting: land branches in batches, test the combined result, and keep a losing edit instead of discarding it. I have deliberately not built it. Detecting the overlap covers most of the pain for a fraction of the complexity, and I would rather see real overlap data from real agent swarms before deciding what the next step should be.

Try it

If you run agents in parallel, start with the .gitattributes line - it is free and it removes the most common conflict outright. If you want to see overlaps as they happen, the demo shows the whole dashboard over sample data, and the source and install guide are at github.com/nimblegate/nimblegate. The earlier post, I loop AI agents on my repos, covers why the gate sits where it does.