When Every Developer Has an Army

I’ve watched three engineering organisations go through the same transition in the last year. They start with one AI coding agent per developer. A copilot. An assistant that writes boilerplate, suggests implementations, handles the tedious parts. Developers describe it as “having a very fast junior.” Productivity goes up. Morale goes up. Everyone is happy.

Then someone asks the obvious question: if one agent is good, why not five?

The three transitions

The trajectory looks like this. Phase one: agent as assistant. One agent, one developer, the developer drives. Phase two: agents as workforce. Multiple agents per developer, working in parallel on different tasks. The developer becomes a coordinator. Phase three: autonomous agent fleets. Agents that pick up work, execute, and deliver without a developer initiating each task.

Most organisations are somewhere between phase one and phase two. A few are experimenting with phase three. Each transition creates a qualitatively different problem, and the problems compound.

The jump from phase one to phase two is where I’ve seen things break. Not gradually. Abruptly.

Fifty contractors, no blueprint

Here’s the metaphor I keep coming back to. Imagine you hire 50 contractors. You give each one a room in a building and say: “build something good.” Each contractor is skilled. Each one works hard. But nobody gave them a shared floor plan. Nobody told them where the plumbing runs. Nobody is checking whether the walls line up.

You get 50 rooms that don’t connect.

This is what happens when five agents work on the same codebase without shared context. One agent refactors the authentication module while another builds a feature that depends on the old interface. A third agent introduces a caching layer that conflicts with the data consistency model a fourth agent just implemented. Each change, reviewed in isolation, looks fine. The interactions between changes are where things go wrong.

I sat with an engineering director who showed me a week’s worth of merge conflicts from agent-generated code. Not the normal kind, where two developers touched the same file. These were architectural conflicts: different agents making different assumptions about how the system should work. The agents had no awareness of each other. Why would they? Nobody designed for that.

The coordination problem is structural

There’s a temptation to treat this as a tooling problem. Better merge conflict resolution. Smarter context windows. Agent-to-agent communication protocols. These help at the margins, but they miss the real issue.

The coordination problem is structural. When humans work together on a codebase, they coordinate through a web of mechanisms that nobody thinks about because they evolved organically: hallway conversations, team standups, shared mental models of the architecture, institutional memory about why things are the way they are. A senior developer who has been on the team for three years carries context that isn’t written down anywhere. That context shapes every decision they make.

Agents have none of this. Each agent starts from the code as it exists at the moment it reads it. It has no memory of last week’s architectural discussion. It doesn’t know that the team tried a different caching approach six months ago and abandoned it. It can’t sense that another agent is working on something related.

Multiply this by five agents per developer, across a team of twenty developers. That’s a hundred agents operating on the same codebase with no shared understanding of where it’s going.

What breaks first

In the three organisations I’ve observed, the failure mode is consistent. First, subtle inconsistencies accumulate. Different naming conventions in different modules. Slightly different error handling patterns. Two implementations of roughly the same utility. These feel minor. They aren’t. They’re early signals that the codebase is losing coherence.

Then come the conflicting architectural decisions. One agent moves toward event-driven patterns while another builds synchronous request-response flows in the same system. Both are reasonable choices. They’re incompatible with each other.

Finally, velocity actually drops. The team spends more time untangling conflicts, debugging integration issues, and reworking agent output than they saved by using multiple agents. The agents are fast individually. Collectively, they create drag.

The missing layer

What these organisations are missing is a layer that doesn’t exist yet in most engineering stacks: a coordination layer that sits above individual agents and below human decision-making. Something that holds the architectural intent, the design constraints, the decisions already made. Something each agent can check before it starts and validate against when it finishes.

Without this layer, scaling agents is like scaling contractors without blueprints. You can do it. You’ll regret it.

The organisations that get this right will move at a speed that’s hard to comprehend today. Twenty developers with a hundred coordinated agents, all pulling in the same direction, all working against a shared specification that updates as the system evolves. That’s the promise.

The ones that get it wrong will move fast in five different directions and spend their time cleaning up the mess. I’ve seen the early version of this. It’s already happening.