When a Whole Team Runs Agents on the Same Codebase

What changes when it is a team, not a person

One developer orchestrating several agents is a coordination problem with known patterns: planner and worker splits, parallel fan-out, sequential handoffs. Those patterns assume a single operator holding the plan.

Five developers each running agents against one repository is a different problem, because nobody holds the whole plan and the agents were never told about each other.

The defining characteristic is that generation capacity multiplies across the team while every downstream constraint stays fixed. The repository still has one main branch. CI still has finite capacity. And the number of people who can competently review a change did not change at all.

That produces a specific and predictable failure. Throughput appears to rise for a few weeks because pull requests are opened faster. Then the queue lengthens, review quality degrades under volume, and the team is slower than before while producing more code. The measurable version arrives later, as time to resolve incidents in code nobody reviewed properly.

So the useful framing is that the team's ceiling moved to review and comprehension the moment agents were adopted broadly, and the work is to redesign around that ceiling rather than to keep raising generation.

The three failures, and what actually addresses them

Review is the binding constraint. Agents multiply the supply of changes and add nothing to the supply of judgement. The response is to make each change cheaper to review rather than to ask reviewers to go faster.

Smaller merge units, so a review is one comprehensible decision. A written statement of intent attached to each change, so the reviewer reads what was meant before reading what was done. And an explicit rule that generated code is reviewed as an untrusted contribution, since a review performed on the assumption that the author understood the change is not a review when the author was a model.

Conflicts arrive at agent speed. When two agents edit adjacent code within the same hour, the result is not a textual conflict that a merge tool resolves. It is two different designs for overlapping behaviour, both plausible, neither aware of the other.

The effective fix is ownership by surface rather than by task. A person and their agents own a module, a service, or a directory, and work that crosses a boundary becomes an explicit handoff instead of a simultaneous edit. This is an old idea and agents make it load-bearing, because the cost of two people converging on the same file went up sharply.

Agents make inconsistent decisions. Each agent works from whatever context its operator gave it, so five agents answer the same architectural question five ways, all defensible in isolation. Over a few weeks the codebase acquires several conventions for the same thing and nobody chose that.

This is the failure a shared retrieval layer addresses directly. When every agent on the team resolves questions against the same indexed knowledge, they converge on the same patterns rather than inventing local ones. RDK exists for exactly this: a common grounding layer so a fleet of agents shares one source of truth, with stacked retrieval keeping most queries from reaching the model at all.

A workable setup

Concretely, for a team adopting this without losing the quarter.

Set ownership boundaries first, before increasing agent usage. Write down who owns which surface. This single step removes most of the conflict problem and it costs a meeting.

Cap work in progress rather than generation. Limit how many agent-authored changes may be open per person at once. The constraint is review capacity, so the queue should be bounded by it rather than by how fast anyone can produce.

Ground every agent in the same place. A shared index of the codebase and the team's decisions, queried by all of them, is what makes independent agents produce compatible work. Without it, consistency depends on each operator remembering to explain the same conventions.

Make intent reviewable. Require a short statement of what a change is meant to do and how it was verified. It is the cheapest quality control available and it turns review from reconstruction into checking.

Isolate environments per developer. As above, and cheaper than the debugging it prevents.

Measure the right thing. Track time from opened to merged, and time to resolve incidents. Both capture whether the ceiling moved. Counting changes produced measures the input, and the input was never the constraint.

The summary worth keeping: agents raise supply, and a team's throughput is set by its narrowest downstream stage. Adding supply without widening that stage produces a longer queue and calls it progress.