Sizing Teams in the Copilot Era

The problem

When drafting code gets cheap, the obvious move is to staff smaller teams and bank the difference. It’s the wrong move, because drafting was never the constraint — and cutting the team removes the people who absorb the work that is.

I made that call. Standing up a new service team just as coding assistants got genuinely useful, I did the arithmetic everyone was doing that quarter: if each engineer produces more, staff at four instead of seven and still hit the roadmap. Six weeks in, the team was generating more code than any group I’d run and shipping slower than the one it replaced. Two of the four were effectively full-time reviewers, because the volume of plausible-looking generated code was enormous and the cost of merging something subtly wrong was real. Nobody held the whole system in their head; the assistant happily wrote into corners no human had read recently.

The model

The constraint on a team was never typing speed — it’s coordination and how much system a group can hold in their heads at once. That’s why the old rule of thumb, a team of six to eight, survives tooling that triples raw output: the number tracks human bandwidth, not keystrokes. What the assistants do is relocate the bottleneck. When drafting is cheap, the scarce work becomes reviewing, specifying, and verifying — deciding what should exist and confirming what got generated is correct. Output went up; the ability to trust output did not come along for free.

What to do

• Size against review and shared context, not output. Keep teams in the six-to-eight band. “AI means we can run this at half headcount” becomes a claim people defend with evidence, not a default.
• Move freed capacity into the new constraint instead of banking it. Time the assistants give back goes into tests, evaluation harnesses, and the review pipeline — the work that lets you trust a higher volume of generated code.
• Make specification first-class. When drafting is free, the expensive mistake is building the wrong thing quickly. Write down what a change should do before generating it, so review compares against intent.
• Change what you measure. Drop lines and raw throughput. Watch review latency, rework rate as generated volume rises, and a rough per-engineer load signal — the numbers that move when a team is past its real limit.

The results

Over two quarters, review latency on that team fell by roughly half — PRs that had sat for two or three days got a real read inside a day. The rework rate, which had climbed as generated volume rose, flattened and then drifted down as eval and test scaffolding caught the plausible-but-wrong changes earlier. Throughput per person was modestly up, but the honest framing is that it rose because the team was the right size to absorb the new work, not because four people became seven.

The caveat: AI did change the headcount math in one direction I underweighted. For well-bounded, well-specified work with strong tests, a slightly smaller team really can carry more, because verification is cheap and the output is easy to trust. Where it didn’t help — and where I was simply wrong — was anywhere the system was poorly understood or a subtle error was costly; there, more generation made things worse, faster. The size is set by how much you have to verify, and you have to know which kind of work you’re staffing. Next time I’d build the eval and review capacity before touching headcount, not in a scramble after.

Further reading

• The Debug Agent — eval-first gates and a verification step that won’t advance on low confidence.