I have been writing code since 1995. For most of those years the job had one shape: the hard part was producing the thing. You sat down, you thought, you typed, and what came out the other side was the constraint on how fast the company could move. Everything around that job got built to serve it. Sprint length. Team size. Hiring plans. The whole apparatus assumed that making software was expensive and slow.
That assumption died about eighteen months ago. Almost nobody has redesigned around its absence.
Here is my claim, and you are welcome to disagree with it: your engineering organisation is not slow because your people are slow. It is slow because it was optimised for a constraint that no longer binds, and the real constraint moved somewhere nobody is measuring.
The constraint moved to review
Faros AI tracked 22,000 developers across roughly 4,000 teams. The productivity numbers are real. Epics completed per developer rose 66%. Task throughput per developer rose 33.7%. The share of AI-generated code accepted without editing went from 20% to 60%.
Then look at what happened downstream in the same dataset. Median code review time rose 441.5%. Median time to first review rose 156.6%. Code churn rose 861%. Bugs per developer rose 54%. The ratio of production incidents to pull requests rose 242.7%. Pull requests merged with no review at all rose 31.3%.
LinearB looked at 8.1 million pull requests across 4,800 teams in 42 countries and found the mechanism. An unassisted pull request at the 75th percentile is 157 lines. An AI-assisted one is over 400. Reviewer pickup time goes from roughly 200 minutes to more than 16 hours. And the number that should stop you: the 30-day merge rate for unassisted pull requests is 84.5%. For AI-assisted pull requests it is 32.7%.
Two thirds of the AI-assisted work does not merge within a month. It was generated. It was not delivered. Your throughput metric counted it. Your customers never saw it.
What is actually happening
The mechanism is simple. Adding an agent to the writing step and nothing to the review step does not make the system faster. It makes the queue longer. This is not a novel insight about software. It is the oldest result in operations research, and every CTO who has read about a factory floor already knows it. We are just failing to apply it to ourselves.
The reason we fail to apply it is that the writing step is where the visible cost sits. Engineers are expensive, so tooling that makes engineers produce more looks like an obvious win. Review capacity is invisible on a budget line. It is a byproduct of having senior people with context, and it does not appear anywhere in a procurement process.
So the org buys more production and inherits more queue.
The three shapes it takes
I want to be careful here and describe patterns rather than claim outcomes I have not measured. What I see across the engagements I run falls into three shapes.
The first is the large organisation with real seniority on the bench. Team-level velocity improves and looks convincing in a steering committee. The number that does not move is time from commit to customer, because the gain is absorbed in the gap between a pull request opening and a senior engineer having enough uninterrupted time to reason about four hundred lines they did not write. The work exists. It is queued.
The second is the mid-sized team where the senior engineers quietly become a bottleneck they were never staffed to be. Their week used to be roughly half building and half reviewing. It inverts. Nobody decides this and nobody announces it. The input rate changed and the roles did not, so the system rebalanced itself in the only place it could.
The third shape is the small product team with no senior reviewer at all. There, the 31.3% rise in unreviewed merges is not a statistic, it is the operating model. Those teams genuinely are shipping faster this quarter. They are also the population where the incident-to-pull-request ratio, up 242.7% in the Faros data, is going to show up as a customer-visible event rather than a dashboard.
GitHub has now run over 60 million automated code reviews, and roughly one in five reviews involves an agent. That helps with the mechanical layer. It does nothing for the judgement layer, which is the layer that is actually saturated.
Where this argument is weak
I should be honest about two things.
First, these are aggregate numbers across thousands of teams at a moment of rapid adoption. Some of the review-time increase is a learning curve, not a structural fact. Teams that adopted agents 18 months ago look different from teams that adopted them last quarter, and I would expect some of this to compress as review tooling catches up.
Second, the argument does not apply evenly. If your codebase is small, your team is three people, and everyone has full context, the review step was never a real queue and adding an agent genuinely does just make you faster. The constraint I am describing shows up when context is distributed across people, which is a function of headcount and codebase age, not of AI.
What I do not accept is the version of this argument that says the numbers will fix themselves. Queues do not self-correct. They get worse until somebody changes the capacity or the arrival rate.
What I would do on Monday
Measure time from pull request opened to merged, and split it by whether an agent was involved. If you measure one thing from this post, measure that. Most organisations report throughput and have never looked at this number.
Cap pull request size. The 400-line AI-assisted pull request is the specific object that breaks review. A hard cap forces decomposition at the point of generation, where it is cheap, instead of at the point of review, where it is not.
Make review capacity an explicit, staffed role rather than a tax on whoever has the most context. If two thirds of generated work is not merging, the reviewer is your production line, not your overhead.
Stop reporting throughput per developer to your board without the merge rate beside it. One of those numbers is activity. The other is delivery.
Move at least one senior engineer out of writing entirely for a quarter and watch what happens to flow. In every case where I have seen this tried, the organisation discovers the constraint was never where the budget was pointed.
The part I keep coming back to
In 1995 the scarce thing was someone who could make the machine do what you wanted. That scarcity built our entire profession, our salary bands, our org charts and our hiring funnels.
The scarcity is gone. What replaced it is the ability to look at four hundred lines of plausible-looking code and know which thirty are wrong. We did not build any of our institutions around that skill, and right now we are not staffing for it either.
The code was never the bottleneck. It just looked like one for thirty years.
I run AI transformation programs through PADISO. If the gap between your throughput metric and what your customers actually received is the problem you have, book a call at padiso.co.