Stop parallelizing your AI agents
The merge tax will eat your 10x speedup
Stop Parallelizing Your AI Agents
I’ve been using AI coding agents heavily for the past few months. Along the way, I’ve learned something counterintuitive about how to get the most out of them.
The temptation: Spin up 9 agents, each working on a different task in the same codebase, merge everything at the end. Compute is cheap. This should be 9x faster, right?
The reality: Your agents spend more time resolving merge conflicts than writing code.
The Merge Tax
Here’s what actually happens when you parallelize work within a single project:
Every parallel branch creates a future merge event. The cost of that merge isn’t constant. It depends on how much the codebase has changed since the branch was created. And that depends on how many other parallel branches have already been merged.
This creates a compounding problem:
2 parallel agents: Occasional conflicts. Easy to resolve.
5 parallel agents: Frequent conflicts. Some cascade. Resolving one creates new conflicts in the others.
9 parallel agents: A clusterfuck. Agents spend more time resolving conflicts than writing new code.
The merge tax is superlinear. Each resolved conflict changes the base, invalidating other branches’ assumptions. Yes, AI agents can resolve merge conflicts. They’re actually quite good at it mechanically. But that doesn’t change the fundamental math: the conflicts grow faster than the productive work.
Why It’s Worse Than Amdahl’s Law
You might be thinking of Amdahl’s Law: the sequential portion of your work limits your maximum speedup. That’s true, but Amdahl’s Law assumes the parallel portion can be perfectly parallelized with zero coordination cost. Under Amdahl, more parallelism always helps. You get diminishing returns, but always positive returns. The curve flattens but never goes down.
That’s not what happens with AI agents working in the same codebase.
The merge conflict problem introduces a coordination cost that Amdahl doesn’t model. If you have N parallel branches, the potential conflict surface is roughly N(N-1)/2.
Every branch can conflict with every other branch.
But it’s worse than that, because merging branch A changes the base for branches B through N, potentially creating new conflicts that didn’t exist when those branches were created.
This means the total work isn’t just “parallel portion + fixed sequential portion.” It’s “parallel portion + coordination overhead that grows quadratically with N.” Past a certain number of agents, the coordination overhead exceeds the time you saved by parallelizing. The curve doesn’t just flatten. It goes down. You’re not just getting less benefit from each additional agent. You’re getting negative benefit.
This is a known phenomenon in systems theory. Neil Gunther’s Universal Scalability Law models exactly this: a coherency penalty that grows with the square of N, creating a peak throughput beyond which adding capacity makes things slower.
What I’ve found is that AI agents in a shared codebase hit this peak surprisingly fast.
Parallel Projects, Not Parallel Tasks
So what’s the right unit of parallelism?
The project, not the task.
Say you’re building a SaaS product. You have a Rails backend, a React frontend, and an internal CLI tool for data migrations. These live in separate repos. You can absolutely have agents working on all three simultaneously. They don’t share state. No merge conflicts. No coordination costs. True parallelism.
But within your Rails app? Don’t spin up five agents to build five features at once. The auth changes conflict with the billing changes. The new API endpoint conflicts with the middleware refactor. Each merge invalidates assumptions the other branches were built on.
Instead: one agent works, logs what it did, and the next session picks up where the last left off. No branching. No merge resolution. No wasted work.
This sounds slower. It isn’t. Because:
Zero time lost to merge conflicts. In my experience, conflict resolution was eating 30-50% of parallel agent time.
Each agent has full context. It reads what the previous agent did, understands the current state, and makes decisions with complete information.
No rework. Parallel agents constantly duplicate effort or make contradictory changes. Sequential agents don’t, because each one sees the current truth.
This Is a Design Choice, Not a Limitation
Think about how software development actually works. PRs can only be merged one at a time. Deploys are sequential. The critical path through any project is fundamentally serial. The art is choosing the right sequence, not making everything parallel.
A better concrete example: you have four features on your sprint:
Add a “last login” timestamp to the user profile.
Build an admin search page for users.
Add email preferences to the settings page.
Implement a “deactivate account” flow.
Four vertical slices. The temptation is four agents. But all four touch the users table. Three of them modify the users controller. Two of them change the settings view. Agent 1 adds a column to the users migration. Agent 3 adds a different column in a separate migration. Agent 4 adds a deactivated_at column and a scope that filters active users, which breaks agent 2’s search query that didn’t know about it. Now you’re resolving conflicts across migrations, controllers, and views that wouldn’t have existed if you’d just done them in order.
When This Gets Interesting
“Massively parallelizing work just makes more work later. Everything has to be merged one thing at a time anyway.”
- Me, at some point in the past week
Git worktrees are a short-term solution that only works for a subset of simple projects. For real production-grade stuff, they’re a far cry from what’s needed. Full isolated environments (containers, VMs, cloud dev environments) will get there eventually. But even then, the sequencing becomes very important, because PRs still can only be merged one at a time.
The future isn’t 100 agents all writing code simultaneously. It’s one agent moving very fast through a well-sequenced backlog, with full context at every step, handing off cleanly to the next session.
That’s slower in theory and faster in practice.
The Takeaway
If you’re using AI agents for software development:
Parallelize across projects. Different repos, different codebases, go wild.
Sequence within projects. One agent at a time, with structured context handoffs.
Invest in context, not compute. The bottleneck isn’t how fast your agent writes code. It’s whether the next agent knows what happened.
The coordination problem isn’t routing. It’s context. Give every session full context and you don’t need parallelism to go fast.
This insight is part of why I built WCP, an open-source work tracking protocol for AI agents. It gives Claude persistent memory across sessions: tasks, status, decisions, and history. One agent works, logs what it did, and the next session picks up with full context. No merge conflicts. No lost work.
One command to install:
claude mcp add --transport http --scope user wcp https://workcontextprotocol.io/mcp
Dave Paola is a technology leader and the creator of WCP.