How should you size an engineering team now that code generation is cheap?

Size it against review and decision capacity rather than against expected output, because those are the constraints that did not get cheaper. Count how many people can competently decide what correct means and read the resulting change with real attention, and treat that number as the upper limit on how much work the team can take on.

Does adding engineers still slow a project down?

Yes, and the mechanism is unchanged. Brooks's law describes coordination cost growing faster than output as a team grows, and generation tools do not reduce coordination at all, so a larger team still spends more of its time aligning and less of it deciding.

Which engineering skills became scarce rather than abundant?

Specification and verification: deciding what the software must guarantee, and building checks that fail when those guarantees break. Producing a plausible implementation is now the easy half of the job, so the value is with the people who can say whether the implementation is the right one.

Should you hire more junior engineers because tools make them faster?

Only with a plan for who reviews their work and who develops their judgment, because both of those add work for the seniors you already have. The tool raises the minimum level of output but does not raise the best level of judgment, so a junior-heavy team produces more change than it can responsibly accept.

What is the right ratio of senior to junior engineers under these conditions?

There is no universal number, but the practical test is whether every change has someone who can review it with genuine understanding within a working day. If review is regularly waiting on one or two people, the team is already limited by its senior people and hiring more producers will make the queue longer.

How do you know your team is at the wrong size?

Watch the review queue and the change failure rate together. A growing queue with a stable failure rate means you are throughput-limited, a stable queue with a rising failure rate means work is being approved without real reading, and both point to review capacity rather than production capacity.

Does staff augmentation still make sense when generation is cheap?

It does when the missing capacity is judgment, specification, or ownership rather than volume. Adding people to produce more code addresses a slow step that mostly stopped existing, while adding people who can define correctness and take responsibility for a domain addresses the one that remains.

Why does a smaller senior team often outperform a larger mixed one?

Because coordination cost falls and decision quality rises, and both of those now matter more than raw production. A small team of people who can specify, build, and verify their own work takes each change from start to finish itself rather than passing it between a producer, a reviewer, and an owner.

How do you measure whether the team is the right size?

Use delivery outcomes rather than activity: how long a change takes to reach production, how often it fails there, and how quickly you recover. Counting commits, pull requests, or generated lines will make an over-sized team look productive until the failure rate shows the problem.

What happens to hiring plans built on the old assumption?

They over-hire producers and under-hire the people who decide and verify, which produces a team that generates more change than it can safely accept. The correction is usually not more headcount but a different mix, plus engineering time spent on automated checks so that review stops being the only check.

Should you plan for headcount reduction because of these tools?

Treating them as a headcount reduction is the most common way these programmes lose credibility, because the saving assumes review and operations are free. The realistic plan is a different distribution of the same or similar spend, weighted toward specification, verification, and ownership.

How to size a team when generation is cheap: Reveneau

Almost every headcount plan we are asked to review starts the same way. Someone estimates the size of the work, divides it by what an engineer produces in a month, adds a margin for the unknown, and arrives at a number of people to hire.

That calculation was reasonable for a long time. It rested on one assumption: that writing code is the slow and expensive part of building software, so the amount of code you need is a fair measure of the number of people you need.

That assumption is no longer true. And when the base of a calculation changes, every result built on it changes too, even if the spreadsheet still looks fine.

The thing that got cheap was typing

Be precise about what actually changed, because the loose version of this claim leads to bad decisions.

Producing a plausible implementation of a well-understood problem got cheaper and faster. That is real. What did not get cheaper:

Deciding what the software must actually guarantee. Somebody has to know that a partial refund on an annual plan should be prorated to the day rather than the month, and that is a fact about the business that a person knows or that is written in a policy document, never in a model.

Reading the result with genuine attention. Stack Overflow's 2025 survey found 66 percent of developers naming output that is "almost right, but not quite" as their biggest frustration, with 45.2 percent saying debugging generated code takes longer than writing it themselves. Almost-right is the category that consumes senior attention, and there is no version of this where it consumes less.

Being responsible when it breaks. Ownership does not divide cleanly. Ten people who all share ownership of a service produce an incident where everyone waits four minutes for someone else to start.

So the honest summary is that the cheap input got cheaper and every expensive input stayed expensive. Sizing a team against the cheap input was defensible when it correlated with the expensive ones. It no longer does.

Brooks's law still applies

The urge, when a tool makes each person more productive, is to conclude that more people now produce proportionally more.

Brooks's law says adding people to a late software project makes it later. The reason is coordination: communication paths grow roughly with the square of the team size while output grows linearly at best, and new people consume the time of existing people before they contribute anything.

Nothing about AI code generation changes that mechanism. A model does not reduce the number of conversations required to agree an interface between two teams. It does not shorten the time to build shared context about a domain. If anything it adds to coordination, because there is more change moving through the same number of conversations.

We have written the longer version of this in why adding engineers can slow you down. The short version for a headcount plan is that the coordination penalty is now a larger fraction of the total cost than it used to be, precisely because the production cost it used to be compared against has fallen.

Size against review, not against output

Here is the change in thinking that actually changes a plan.

Ask how many changes per week your team can accept with real understanding. Not how many it can produce: how many a competent person can read, question, and take responsibility for. That number is the upper limit on useful throughput, and everything above it goes into a queue or gets approved without being read.

Then work backwards. If the limit is lower than the volume you need, you have three options and only three. Add review capacity, which means senior people and is slow and expensive. Reduce the volume, which means saying no to work. Or build automated verification good enough that a reviewer can accept a change without reading every line, which is engineering time spent up front.

The third is the only one that grows with the volume, and it is the one that gets cut from budgets because it produces no visible feature. Our method is in how to write your first eval suite, and the specific failure of building the checks after the volume arrives is in agent debt, when generation outpaces review.

What this does to the mix

The team structure that follows from this looks different from the one most plans assume.

More people who can specify. The scarce skill is deciding what correct means, in enough detail that a machine can check it. This is senior work and it is closer to product thinking than most engineers are used to. Someone who can sit with a finance lead for an hour and come away with the exact rules for proration is now worth more than someone who can implement those rules quickly, because the implementation is the cheap half.

More people who can verify. Building checks that genuinely fail is a real skill and it is rare. A suite written from the implementation asserts that the code does what it does and proves nothing, which is a mistake that looks like diligence.

Fewer people whose main contribution is volume. This is the uncomfortable part and it should be said plainly rather than hinted at. If someone's value was producing a large amount of straightforward code quickly, the market price of that has fallen. The good news is that the same person usually has the domain knowledge to move into specification work, which is where the demand went.

A clear owner per area. Not a rota. A named person who knows a domain properly and is accountable for it. This keeps responsibility clear as the team grows, and it is what keeps incidents short.

The measurement mistake

If you size the team on output metrics, you will get a team that produces output.

Commits, pull requests, story points, and lines generated all rise when you add producers, and they will keep rising past the point where the work is being accepted responsibly. The number that shows the problem is change failure rate, and it usually moves a quarter later than the headcount decision that caused it.

Track the four delivery measures from the DORA research instead: how long a change takes to reach production, how often you deploy, how often a change fails there, and how quickly you recover. If throughput rises and stability falls, you paid for activity. The 2025 DORA report found exactly that pattern across all its respondents, with AI adoption relating positively to throughput and negatively to delivery stability, and summarised it as "AI doesn't fix a team; it amplifies what's already there".

There is a further caution about assuming individual speed gains. METR's July 2025 study of 16 experienced open-source developers working on their own repositories found they took 19 percent longer with AI tools, having expected a 24 percent speedup and believing afterwards that they had been 20 percent faster. Sixteen developers is a small sample and one context, so it does not settle the question. It does show that self-reported speed is unreliable enough that you should not build a hiring plan on it. Our related argument is in measure engineers by outcomes, not output.

The plan that works

Start from the review and decision capacity you have. Treat that as your real capacity, because it is. Then decide whether to raise it by hiring senior people, or to raise the amount each reviewer can safely accept by investing in verification.

Add production capacity last, and only when you can show the reviewers are not the constraint. That ordering is the inverse of most plans, and it is the one that still works in the second quarter.

The related case for keeping the team small is in why a small senior team outbuilds a big one, and the practical work of getting new people useful quickly is in onboarding engineers quickly.

Thanks to the engineering leaders who shared plans that did not work out and were willing to say why. The pattern was consistent: the hires arrived, the output rose, and the queue in front of two senior reviewers got longer every week until something broke in production.

Cheap AI code generation leaves the team you need the same size and puts it on a different part of the process.

Related guide: Reducing coordination overhead.

Sources

Stack Overflow 2025 Developer Survey, AI section: 66 percent name "almost right, but not quite" as their biggest frustration; 45.2 percent report debugging generated code takes longer than writing it.
Brooks's law: adding people to a late software project makes it later, because coordination cost grows faster than output.
DORA research programme: the four software delivery measures.
2025 DORA report announcement, Google Cloud: AI adoption relates positively to throughput and negatively to delivery stability, and amplifies what a team already is.
METR, early 2025 AI experienced open-source developer study: 16 experienced developers were 19 percent slower with AI tools while believing they were 20 percent faster.

How to size a team when generation is cheap