I was watching the (well made) video “Can We Trust AI to Code Without Human Oversight?” by Sam Newman on the Modern Software Engineering channel (recommended watch). He asks how much attention we still need to give to the code our agents write and concludes that the human code review may be the bottleneck in our delivery process. I think he is right about the bottleneck, but I don’t think “stop reviewing” is the lesson. We still open pull requests and still ask a colleague for approval, even though no human wrote that code and no human will maintain it. That is worth questioning, so let’s look at the numbers.

More code is not more software

Newman leans on Faros’ “Acceleration Whiplash” report, published in April with data through March. It compares the same teams before and after they crossed the threshold into heavy AI use, so it is not a year-over-year claim. What it found:

  • Pull requests are 51% larger
  • Developers touch 67% more PRs per day
  • Tasks completed per developer went up 34%
  • Epics completed per developer went up 66%
  • Time a task spends in progress went up 225%
  • Median time in PR review went up 441%
  • Lead time from commit to production went up 480%*
  • PRs merged without any review went up 31%

*) only 10% of the teams measured this, and the variance was high.

I think Newman is right: much more code goes in, not much more software comes out. Merged PRs per developer only went up 16%, where the previous edition of the same report still saw 98%, and the teams that track their deployments ship 11% less often than before. Faros calls that a “review bottleneck throttling delivery”. To be fair, developers do finish more tasks and more epics, so we don’t deliver less. We deliver a small part of that extra code, and late.

Waiting is not free, as a pull request gets worse while it sits: 26% more tasks sit for a week without activity and work restarts are up 14%. The diff that finally reaches a reviewer is bigger, older and unexplained, so merging it is riskier than on day one. That is also where the 31% comes from; once the queue gets long enough, people merge without reading. Anyone who has seen lean manufacturing knows the picture: lots of activity, little coming out the other end.

Google’s DORA team published a report on the ROI of AI in April that has a name for this: the verification tax. It is the time developers spend checking generated output, and they see it as the main reason AI does not pay off yet. They expect it to be temporary and their answer is not more reviewers, it is automating the gate.

The four goals of a code review

Newman then asks what a code review is actually for. He lists four goals:

  1. Correctness, does the code do what it should do?
  2. Shared learning, both for the author and for the reviewer.
  3. Alignment with the strategy and the practices of the team.
  4. Awareness of what is going on in the codebase.

Now go through that list again, but assume AI wrote the code, AI reviewed it and AI will modify it next month. Correctness was never something I could confirm by reading a diff, and I certainly can’t do it at three times the volume. Learning is gone in one direction: my review comment does not train the next model, the best I can do is fix the context and the skills that produced the code. I care less about consistency in code that no human edits by hand. And for awareness, a generated summary of the change tells me more in less time than the diff does.

Not much of the list survives, and what is left is a poor return on the most expensive attention in the team. It also costs something: Newman suspects this is feeding the reports of developer burnout, but he has no numbers for it. What we do have is a Harvard Business Review article from February, “AI Doesn’t Reduce Work, It Intensifies It”, in which workers describe doing more at once and feeling more pressure than before they used AI. That is what the 225% above looks like: people work on more things at once, so each one sits longer before it is done.

Chainguard’s dark factory has one room

Newman compares where this leads to dark factories: robotic factories that run without lights, because no human needs to be there. His example is Chainguard, a supply chain security firm. He presents it as a company that stopped human code review. Their own write-up is narrower than that, and the details are the good part.

They encode each coding standard as a machine readable skill. Agents open the pull requests that apply those standards across the hundreds of modules in their monorepo. A PR merges without anyone reading the diff when two things are true at once:

  1. a high confidence grade, bound to that exact commit
  2. every required CI check green, on that same commit

The bot that does the merge is deterministic. No model, no judgement, just policy. Over eight weeks the system opened 4,746 standards fixes, graded 3,044 of them and merged 840 with nobody in the loop.

What they did not automate is the interesting bit. A change to a skill goes through the same pull request, review and CI as any other change, because a standard that gets applied to hundreds of modules has to be right. Anything touching production infrastructure or auth is capped and goes to a human no matter what the model thinks. Their own conclusion is not that they trust the model more, it is that they never let it merge alone. So the lights are off in one specific room, not in the building.

Conclusion

I was watching a good video and I agree with the diagnosis: reviewing every diff by hand does not scale and does not buy what it used to buy. But most of the value of a code review was never in improving the code. It was in agreeing on what to build, learning from each other and keeping a shared picture of the system. Those things still matter and they no longer fit in a diff. Reviewing the standard, the skill or the design document instead is not skipping review, it is reviewing the thing that decides what all the code will look like.

That only works if you can check the result without reading every line. Tests, types and a build you trust are what let you turn the lights off. If you don’t have those, the review policy is not your problem. Chainguard did not flip a switch either: they picked one bounded class of changes, made the merge decision deterministic and kept a human on everything that can hurt.