How to Scale AI Coding Agents Across a Dev Team

One developer with a coding agent is a productivity story. It is easy to tell, it demos well, and it is genuinely true.

Five developers with twenty agents is a different thing entirely. It is a coordination problem, and coordination problems do not get solved by the tool that created them. This is the part nobody writes about, because it only shows up after the enthusiasm phase: the individual gains are real, they arrive immediately, and then somewhere around the third or fourth developer the team starts spending its new speed on cleaning up after itself.

What follows is the failure order. Not a list of best practices in the abstract, but the sequence in which things actually break, because fixing them in the wrong order wastes a quarter.

What breaks first: shared context

Every developer running an agent is quietly teaching it their own version of the codebase.

One person tells their agent the project uses server actions and never API routes. Another never mentions it, so their agent writes API routes. A third mentions it once, in a session that ended three days ago. Nobody is wrong, nobody is lying, and the repository now contains three interpretations of the same convention. You will notice this in the review queue, which is the wrong place to notice it: by then the code exists.

The fix is boring and it is the highest leverage thing on this page. Put the conventions in a file, commit the file.

CLAUDE.md for Claude Code, AGENTS.md for Codex and most other CLI agents, and in practice a lot of teams keep one portable context file rather than maintaining two that drift apart. The mechanism matters more than the filename: the instructions live in the repository, so they arrive with a git pull instead of arriving through whoever happened to be in the room.

What belongs in it:

• The conventions an agent cannot infer from reading the code, especially the ones the codebase currently violates in places
• The commands: how to run the tests, the build, the linter, and which of them are allowed to be run automatically
• The parts of the repo that are dangerous to touch, and why
• What the team does not want: the refactor nobody asked for, the dependency that must not be added, the pattern being migrated away from

What does not belong in it, and this is where teams get burned: anything specific to one machine. Absolute paths, personal API tokens, local ports, someone's preferred editor. The moment a machine specific value lands in a committed context file, every other developer inherits a setting that is wrong for them, and agents are extremely good at faithfully following instructions that no longer apply.

A useful test before adding a line: if a teammate pulls this, does it help them or does it break them?

What breaks second: two agents, one file

Agents do not negotiate. They do not check whether someone else is mid edit. Two agents pointed at the same module will overwrite each other, and neither will mention it, because from each one's point of view the work completed successfully.

Solo, this is invisible. You run one agent at a time, or you run several and they happen to touch different things. On a team it becomes structural, and it produces the worst class of bug: work that silently disappears between two green test runs.

Two mechanisms fix it, and you want both.

Isolation. Git worktrees give each task its own checkout of the repository, so parallel agents physically cannot collide. This is the cheap half of the solution and there is no reason not to do it.

Ownership. Isolation stops the overwrite; it does not stop two people from solving the same problem twice, in two branches, in two incompatible ways. That one is solved at assignment time, by scoping each task to a set of files and saying so in the task itself. Not "improve the checkout flow" but "change the payment step, in these three files, do not touch the cart".

The second half is the one teams skip, and it is the one that determines whether the merge is a formality or an afternoon.

What breaks third: review

Everything about review at team scale follows from one number: how much diff arrives per hour.

One developer reading every line works fine. Five developers running four agents each generates more diff per day than the team can read, and the honest outcome is not careful review, it is approval theatre. A human skimming a nine hundred line diff at 6pm produces a signature without producing knowledge, which is worse than not reviewing, because it manufactures assurance where there is none.

The policy that survives is not "review everything" and it is not "trust the agents". It is to move review to the two boundaries of the work: read the plan before the agent starts, because a wrong plan executed perfectly is the most expensive failure mode available, then read the diff in proportion to what the change can break. Marketing copy and CSS get a skim. Auth, payments, permissions, personal data and migrations get read line by line by a human, every time, regardless of how clean the diff looks.

This deserves its own conversation, and we wrote it up separately: should you still review your AI agent's code goes through the ten objective tells that a change went wrong, and the blast radius table teams can adopt as is.

One team specific addition. When several agents share a repository, review needs attribution: which agent, which task, which developer. Without it, a diff has no author and review turns into archaeology. This is the single most useful thing to fix in your setup once you pass three or four concurrent agents.

What breaks fourth: cost, and the conversation about cost

Token spend stops being a personal detail the moment it appears on a team invoice.

The trap is that the invoice is monthly and aggregate, so the conversation it produces is also monthly and aggregate, which means it produces a policy instead of a fix. Someone proposes a cheaper model for everyone. Someone else proposes limiting sessions. Both are guesses.

The actual distribution is almost never uniform. It is a small number of long running sessions, on one or two projects, with context that grew all day and was never reset. That is a fixable behaviour, and you can only fix it if you can see spend per session and per project rather than per month. We covered the mechanics of this in how to check token usage and how to cut it without slowing down.

Make the number visible to the people who generate it, before it becomes a management topic. A developer who can see that one session cost more than their entire previous day changes their habits on their own, and that costs the team nothing politically.

What actually changes in the team's rituals

Three things, in our experience and in what teams report.

Standup shifts from status to unblocking. What each person did yesterday is largely visible in the branches. What is worth five minutes is which agents are stuck, and on what.

Prompts become shared assets. The instruction that got a good result for one developer is worth more to the team than the code it produced, and it is exactly the kind of thing that evaporates in a private terminal history. Teams that keep a shared prompt library in the repository stop rediscovering the same phrasing every week.

Specialisation moves from people to roles. Once agents handle the writing, the interesting question is who reviews what, and teams naturally drift toward assigning roles to agents the same way they assign them to people: one on implementation, one on review, one on tests. That is the idea behind Agent Teams, where a task is handed from a Dev role to a QA role with the diff, the risks and the test hints attached, and quality gates are decided by your test suite rather than by an agent's own opinion of its work.

The setup that holds

Condensed, in the order that matters:

The first four cost nothing but agreement. The last two are the reason a team eventually wants something above the terminal: not because terminals are bad, but because a terminal shows one agent at a time and gives you no way to answer "who is running what, on which project, right now".

That is the problem AgentsRoom for teams is built around: every agent across every project in one view, with its role, its status and its cost attached, and a mobile companion for the times the team is not at their desks. It works the same way with Claude Code and with Codex, which matters more than it sounds: most teams end up running both, and a setup that assumes one provider quietly becomes the next thing that breaks.

Start with the context file though. It is free, it takes an afternoon, and it removes more friction than any tool you can install this quarter.