Team size has a ceiling, and agents lowered it

Estimates stopped meaning anything to me about a year ago.

Points were always defined as complexity rather than time. In practice velocity worked anyway, because for a human team the two moved together: a complicated story took longer, reliably enough that a sprint average predicted the next sprint. Coding agents break that link in both directions. Work I would have sized at two weeks lands before lunch. Work that looks like an afternoon takes three days, because the agent surfaced four things that were already wrong and each one needed a decision. Average that over a sprint and the number is noise, and the estimating conversation becomes an argument about a figure nobody in the room believes.

The reflex at that point is to look for a better ratio. Output per unit of spend, value delivered against cost. Those are answerable, and they tell you whether last quarter was efficient. They do not tell you what to change on Monday.

What I need to know instead is how many people a piece of work can absorb before the next one makes it slower. Every piece of work has that ceiling. Agents moved mine, and not in the direction I expected.

The ceiling is not new, only the height of it

This part is not new, and the literature is older than my career. Brooks wrote down the communication-paths argument in 1975, and it gets quoted as a slogan about late projects when the interesting half is the arithmetic: the number of paths between people grows with the pairs, not with the headcount.

It helps to separate two different costs, because they behave differently and they have different cures.

The first is the work that has to happen one at a time. One test environment. One release path. One person who has to approve the change. Add contributors and they queue. This flattens the return on each new person, but on its own it never makes the team slower.

The second is the cost of keeping contributors consistent with each other. Reviewing each other's work, knowing what already exists, redoing something because a change landed underneath it. This one grows with the pairs, and it is the one that bites. Past some number of contributors, each additional person costs the others more attention than they contribute, and total output falls.

So the shape is not a line and not a plateau. It is a curve with a peak, and that peak is the ceiling. Anyone who has watched a team of twelve deliver less than those same eight people delivered has already seen it. What is worth noticing is where it comes from: almost entirely from that second cost. Fix the queueing and the curve flattens later. Fix the consistency cost and the peak itself moves.

What agents change

Here is the part I am less sure about, and I would rather state it as a hypothesis than dress it up as a finding.

Agents raise what one contributor produces, and they raise the cost of keeping contributors consistent at the same time. Those pull in opposite directions, and I think the second one wins: the ceiling comes down, and the same piece of work now wants a smaller team than it did three years ago.

Three things I have watched happen push in that direction.

Generation stopped being the constraint and review became it. One agent will happily work across the data layer, the API and the front end in a single afternoon. The person reviewing it has real depth in one of those, which is not a failing: each layer has its own patterns and its own ways of going wrong, and that is why specialists exist. The uncomfortable version is that output gets checked only as well as the person steering can check it, so the layer nobody on the team specializes in is exactly where plausible mistakes survive.

Handing the review to another agent does not fix it. Two models trained on the same material agree for reasons that have nothing to do with the code being right, and agreement between them is weak evidence dressed as a second opinion. A review bot is useful for the classes of mistake it is actually good at. It is not a substitute for someone who knows the layer.

The agent builds a second version of something that already exists, because nothing in its context said the first one was there. I have lost count of how many times I have found two helpers doing the same job, or a second validation path beside the one I wrote in the spring. That is not the agent being careless. It is the consistency cost arriving as code instead of as a meeting.

And the guidance files have the same disease one level up. Plans, notes, conventions, backlog text, all of it accumulates, some of it goes stale, and the stale parts quietly instruct the next piece of work. Guidance needs grooming and archiving the way code does, and almost nobody treats it that way yet, including me for longer than I would like to admit.

If that is true, you fan out rather than staff up

Take it seriously for a moment. If the peak sits lower than it used to, then a twenty-person group is better arranged as five teams of four across five separable pieces of work than as two teams of ten, with specialists at each layer providing architecture and code oversight across those teams rather than sitting inside one of them.

I have run that arrangement, and it predates the agent question by years. On one engagement I took a team of one to more than seventy engineers, staffed across thirteen of the client's own product teams, which is roughly five to a team. I was the technical counterpart the client's executive relied on across all of it, and part of the job was growing senior engineers into architects so that oversight layer got wider as the work did. We did not arrange it that way because of a theory about team size. It was the only shape that worked.

So the claim I am actually making is narrower than "small teams are better." It is that agents lower the ceiling on contributors per piece of work far enough that fanning out stops being good practice and starts being the only arrangement that holds.

Two things would have to be true, and both are easy to get wrong.

The oversight layer is not free, and it is the next bottleneck. One architect reviewing five teams is a queue with a utilization limit, and review was already the constraint. Fanning out moves the consistency cost out of the team and into a shared service; it does not delete it. If you set this up, measure how long work waits for that layer, and treat a rising wait as the same problem you thought you had solved.

It only works where the pieces are genuinely separable. Five teams sharing one schema, one deployment path and one set of core libraries are one team of twenty with extra meetings. Coupling is what creates the queueing cost, and queueing is the part that fanning out cannot fix.

What I would measure

Not points, and not a cost ratio. Five things, all of which a normal tracker and a code host already know, and together they tell you where your own ceiling sits:

• Contributors per piece of work, counting people and agents separately. Without this there is no curve, and it cannot be reconstructed later.
• The share of a piece of work's elapsed life spent waiting on a person rather than being built. With agents this is usually most of it, and it is the consistency cost made visible.
• How much rework lands on changes that already passed review, counted a couple of weeks later rather than at merge.
• When working one item spawns another, whether the new item is something the agent found or something the agent introduced. Those are two different problems with two different fixes, and teams that lump them together end up treating neither.
• Work in flight per contributor, to tell a real throughput gain from a pile of unfinished things.

Every one of those can be gamed, so none of them should be attached to anyone's performance review. They are instruments, not scores.

What I have not proved

One contributor on one platform for nine months is a mechanism, not a measurement. I can tell you what fails and why. I cannot hand you the curve, because a single point does not make one, and anyone who shows you that curve from their own team this year is showing you a drawing.

What I have is the arithmetic, which is old and well established; the failure modes, which are first-hand and repeatable; and one worked instance of the fan-out structure at a size most people have not run. The hypothesis is the new part, and the list above is how someone with a real team could prove me wrong.

So the practical form of all this is a question worth asking before the next hire or the next reorganization: not how many people we can afford, but how many this work can hold. The ceiling was always there. What changed is that it is lower than it was, which means the next move is usually another surface rather than another body on this one.

If you are running this at team scale and seeing something different, I would like to hear it.