You have heard the claim. A small team with the right tooling now does what used to take five people, or ten, and the org chart is about to be rewritten.
Two things are worth doing with that. First, ask whether it's true, because it is almost always asserted without a number. Second — and this is the more interesting exercise — grant it, and follow the consequences. They are not the ones the people making the claim seem to expect.
Is there any measurement behind it?
Very little, and the best-designed study we have points the other way.
METR ran a randomized controlled trial: sixteen experienced open-source developers, 246 real issues from their own repositories, each issue randomly assigned to allow or forbid AI tooling. Not benchmarks. Actual work on codebases averaging over a million lines that these people already knew intimately. Readers who reach what happens when one engineer does the work of five through a growth or RevOps role will want the team at XenGrowth alongside this.
They were 19% slower with AI available. Beforehand they had forecast a 24% speedup; afterwards, having done the work, they estimated a 20% speedup.
I want to be fair about how far that generalises. Sixteen developers is a small sample, the tooling was early 2025, and the setting is close to the worst case for AI assistance — experts on mature code they already understood, where the tool's main advantage of knowing things you don't barely applies. On unfamiliar code or in a rusty language the result would likely flip.
But the perception gap generalises much further than the slowdown does. Roughly 39 percentage points of error, in the flattering direction, by experts assessing their own labour. Every 5x claim you have heard was produced by exactly that mechanism: somebody consulting their impression of their own week.
Nobody making the five-engineers claim has ever shown me a before-and-after cycle time. The claim is always about how the work felt.
DORA's 2025 data is the honest middle position. Throughput genuinely is up — teams ship more than they did. Delivery stability is still falling. So the extra output is real and it is partly being paid for in defects, which is a very different proposition from five people's work appearing for free. On the operations side of this specifically, The XenGrowth resource library is worth reading.
What caps the gain even if the tooling is perfect?
Amdahl's law, and the numbers are unkind.
Speed up one part of a system and your total improvement is bounded by how much of the system that part was. Meyer et al.'s instrumented study of 20 developers over 220 work days measured coding at 21.0% of the workday, against 24.4% on collaborative activities, 14.5% on email and 11.4% on work-related browsing.
Make coding instantaneous and the workday gets 21% shorter. That is the ceiling, before subtracting the time spent verifying output you didn't write. A 5x on the whole job would require automating things that are not code at all — the meeting where scope gets decided, the conversation with the stakeholder who changed their mind, the afternoon spent working out what the customer actually meant.
If you automate... | Share of the day | Best-case reduction in the day |
|---|---|---|
All coding, perfectly, with zero verification cost | 21.0% | 21% |
All coding plus all work-related browsing | 32.4% | 32% |
Everything except collaborative work | ~75% | 75% — and this is fantasy, not a forecast |
Collaborative work (meetings, email, negotiation) | 24.4% | Not automatable in any near-term sense |
To get 5x — an 80% reduction — you would have to automate essentially everything including the collaboration, and do it with no verification overhead at all. Against a measured 45% security-flaw rate in generated code, the verification overhead is not zero.
But suppose it were true anyway. Then what?
This is the part worth thinking about properly, because the interesting consequences don't depend on the claim being wrong.
The bottleneck moves to review
If one person produces five people's output, somebody still has to check it — and review capacity does not scale with the same tooling, because reviewing requires understanding, which is the expensive direction. Veracode's 45%, and Stack Overflow's finding that 'almost right' output makes debugging slower, both land squarely on the reviewer. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
So the team of five doesn't become a team of one. It becomes one person generating and several people trying to keep up with reading, which is a worse job than the one they had and a genuinely difficult thing to staff.
Brooks runs in reverse, but not as far as you'd like
Brooks's observation was that communication paths grow quadratically with team size, so adding people to a late project makes it later. Run it backwards and a smaller team really does carry less coordination overhead — that part is real, and it is the strongest argument for the small-team thesis.
The limit is that the coordination you remove is internal. The meetings with the customer, the sales team, the compliance review and the other department don't disappear because your team got smaller. Meyer's 24.4% collaborative figure is mostly external, and it survives the reorganisation intact.
Software gets more plentiful and worse on average
This is the outcome I'd bet on, and GitClear's numbers already show it beginning. Copy-pasted lines up from 8.3% to 12.3%, refactored lines down from 24.1% to 9.5%, and block duplication climbing from 40.3 to 73.0 per million changed lines. More code, less structure. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
That's what a supply shock looks like in any market. Quantity rises, average quality falls, and the variance widens dramatically — because the teams with real verification discipline convert the extra capacity into more good software, while the teams without convert it into more of what they were already producing. DORA's framing, that AI amplifies what a team already is, is the same observation.
Naive expectation | What the evidence suggests instead |
|---|---|
Teams of five become teams of one | Teams stay similar and the review queue becomes the constraint |
Costs fall proportionally | Costs shift from writing to verification and incident response |
Everyone ships five times as much | Strong teams gain, weak teams accumulate instability (DORA) |
Fewer engineers needed | BLS still projects 15% growth; the shortage moves to senior judgment |
Quality is unaffected | Duplication up, refactoring down, delivery stability falling |
Where the claim is closest to true
It would be dishonest to leave this without naming the cases where something near a 5x genuinely does show up, because they exist and they are not trivial. They share a shape: work where the expensive part was never the thinking.
Greenfield projects with no existing codebase to be consistent with — the context gap costs nothing when there is no context yet
Throwaway work: prototypes, internal scripts, one-off migrations, anything where being subtly wrong has almost no consequence and nobody will maintain it
Work in an unfamiliar language or framework, where the alternative was hours of documentation reading rather than minutes of typing
Mechanical transformation at volume — reshaping a hundred files the same way, writing the tedious half of a test suite, converting between formats
Solo work with no review requirement, where the verification cost is simply not being paid rather than being cheap
Notice that the last item is doing quite a lot of the work in most 5x stories. An individual building something alone, quickly, with nobody reviewing it and no production consequences is genuinely much faster than they used to be. That is a real and useful capability. It is also the specific situation whose economics do not transfer to a team maintaining a system that other people depend on, which is what the org-chart argument is actually about.
The honest version of the claim is therefore narrower and still significant: the cost of producing software that nobody has to maintain has collapsed. What has not moved much is the cost of producing software that many people depend on for years, because almost none of that cost was ever in the typing.
How would you know if it were happening to you?
Not by asking, which is the entire lesson of the METR result. If you want to know whether your team got five times more productive, the good news is that this is measurable with data you almost certainly already have.
Cycle time on comparable work, measured over a quarter rather than a sprint. Comparable is doing the work in that sentence — cherry-picking the greenfield tasks will show you a 5x that isn't there
Change-failure rate alongside it, always. DORA's whole finding is that these two decoupled, and looking at throughput alone will tell you everything is going wonderfully
Review turnaround and PR queue depth. If output rose and this got worse, you have not gained capacity — you have moved the constraint and stopped measuring where it went
Incident count and mean time to resolution. This is where 'almost right' code eventually shows up, on a lag long enough that nobody connects it to the tooling decision
Duplication trend in your own repository. GitClear's numbers are industry-wide; yours are computable, and the trend matters more than the absolute figure
If those five numbers all improve together, you have something real and you should tell people, because almost nobody has published such a result. If throughput improved and the rest got worse, you have reproduced DORA's finding in miniature, which is useful in a different way.
What you should not do is what the claim's proponents mostly do, which is to notice that the week felt fast and extrapolate an org chart from it. Sixteen experts did exactly that under controlled conditions and were wrong by 39 points.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If what happens when one engineer does the work of five is part of a growth programme rather than a standalone build, XenGrowth, who work on the commercial side of this is the companion reading.
