If you live in Virginia you know Interstate 66. Out west it is eight lanes wide and the cars are doing 60 miles an hour. Then it gets closer to Washington and it narrows, and narrows, and near the city it is two lanes, and now you are doing 5 miles an hour, and sometimes you are not moving at all.
The cars did not get slower. The road got narrower. It is always the narrowest part that decides how fast anything arrives, and that narrow part has a name. It is called the bottleneck.
Software development now has exactly that shape. The eight lanes are the code, and they got wider, and everything in them is flying. Whatever my team did in one month, one person now does in a day. The two lanes are the people who have to say it works, and nobody widened those.
Writing code is not the issue. The bottleneck is software quality assurance.
Do not take that from me. Take it from the people with the data.
GitHub publishes a yearly count of what happens on its platform. In 2025, pull requests created went up 20.4%. A pull request is one batch of changes, offered up for somebody to look at before it goes in. In the same year, comments on those pull requests went up 0.35%, and comments on commits fell 27%. Production went up a fifth. Reading it did not move at all.
Uber's engineering team wrote publicly about why they had to build a review tool. Their sentence: reviewers are overloaded with the increasing volume of code from AI-assisted code development. They land about sixty-five thousand of those batches every week.
And it is not only counts. Stack Overflow surveys developers every year. In the last one, of forty-nine thousand of them, the most common frustration with these tools, named by 66%, was AI solutions that are almost right, but not quite. Another 45% said debugging AI-generated code takes longer than writing it themselves would have.
Google's own DORA research team went through one thousand one hundred and ten written answers from Google engineers. They gave their section a title I could not improve on. The verification tax: time saved writing is often re-spent auditing.
Every one of those organizations could hire more reviewers tomorrow. None of them is doing that. So what stops them?
Reading does not scale the way writing just did. You can double the amount of code by paying for more of the thing that writes it. You cannot double a careful human being by paying twice. One of Google's own engineers said it in a single sentence in that study: reviewing somebody else's code is so much harder than writing it, and AI tools are increasing the rate at which people can churn out code that needs to be reviewed. So the two lanes cannot be widened by hiring. They can only be widened by building something that does the checking itself, and that is a job, and it is the one at the end of this argument.