The bottleneck in vibe coding was never writing the code

The law nobody repealed

In 1975, Fred Brooks published the observation that adding people to a late project makes it later. His explanation was about communication: every new person adds channels, and channels cost everybody time.

Fifty years on, the promise of AI-assisted development looks like the opposite. If each person writes three to five times more code an hour, adding people should add delivery. That is the arithmetic every AI vendor is doing right now, in public.

I did the arithmetic to the end. I simulated a thirteen-module application built with vibe coding by teams of 1, 2, 3, 5, 8 and 13 people.

What the simulation returned

People	Weeks
1	14
2	8.5
3	6
5	5
8	5.5
13	7.5

From 1 to 3 the gain is real and large. From 3 to 5 it turns marginal. From 5 to 8 the project gets slower. At 13 people the result is close to what 2 people produced.

Before the cause, the caveat this table has earned: it is a simulation, not a measurement of real teams. What it is worth is the shape of the curve, not the exact week on any row.

Why the curve turns

The reason is structural, and it has nothing to do with how good the model is.

Each person with an agent generates three to five times more code an hour than a developer without one. At thirteen people, the output volume is equivalent to forty or fifty developers.

But the capacity to review, integrate and test is still bound to the number of humans on the team. Nothing multiplied it.

So the two sides grow asymmetrically: more people produce more code, more code produces more merge conflicts, more architectural drift, and more time spent coordinating, integrating and throwing work away. In the thirteen-person simulation a large share of the code produced is discarded, and individual efficiency collapses to a fraction of its potential.

The bottleneck in vibe coding was never producing code.

It is absorbing code.

The number that falls out

The sweet spot in the simulation held steady at three people, and three is not a magic number: it is the count of naturally independent domains in that project.

That is the practical rule, and it is about sizing rather than tooling:

The right number of people on an AI-assisted project equals the number of independent domains in the system.

Past that you are not buying parallelism. You are buying integration overhead, and it consumes exactly the gain that justified the hire.

What to do with it

The useful conclusion is not to hire fewer people for its own sake. It is that the work of decomposing a system into independent domains has become the work of sizing the team. It used to be architecture; now it is budget as well.

And this is where the curve meets the rest of the method. If the bottleneck is absorption, then everything that lowers the cost of absorbing is worth more than everything that raises production: conventions that make review predictable, contracts that make integration fail early, gates that reject by machine what a human would otherwise have to read. A well-built harness does not make the agent write more. It makes what the agent wrote cheaper to let in.

Brooks was right fifty years ago. The logic is unchanged. What changed is the scale it shows up at, and how fast you reach the ceiling.