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%
  • 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 31% is the pressure valve: when the queue gets too long, people merge without reading. Anyone who has seen lean manufacturing knows the picture: lots of activity, little coming out the other end.

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, and says the broad evidence isn’t in yet. 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. Add the 225% increase in the time a task spends in progress from the same Faros report and you have people spinning more plates and finishing later.

Chainguard turned the lights off in 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.