There is a folder in my head where I keep the things I stopped questioning. Code review has been sitting in that folder for most of my career. Somebody writes the code, somebody else reads it, we talk, we merge. That was the deal. It worked well enough that I never asked what the deal was actually for.
The subject came up on my team this week. Not as a big architectural debate, just the ordinary version of it. The queue is longer than it used to be, the changes are bigger, and somebody said out loud what a few of us were already thinking. Are we still getting from this what we think we are getting?
Then, by coincidence, I read two articles about exactly that question, written by two people I respect, and they land in different places. I have not been able to put it down since. So this note has no conclusion. I am writing it because right now the question is better than any answer I have.
Everything we asked review to do
Think about what we loaded onto that one step over the years.
We used it to find bugs, which is the reason everybody says out loud. We used it to check that the logic matched the business rule, which is the reason that actually saved money. We used it to spread domain knowledge, so the payment flow was not living inside one person’s head. We used it to teach juniors how a more experienced person reasons about a trade off. We used it to keep architecture from drifting.
That list is mine, not a standard. Your team probably has a different one, and it should. A regulated product cares about the audit trail. A startup with four people cares that somebody else can keep the thing alive next week. A team with a lot of new hires reviews for learning more than for defects. The criteria belong to the team and the business it serves, and I would be suspicious of anybody selling one checklist for everybody. What I do think is common is the pattern underneath. Whatever your list is, it grew.
And then we used it for a lot of other things. Formatting. Naming. “We already have this in the shared library.” “We agreed not to do it this way.” I have written every one of those comments, and over the years I built myself a rule about them. If the problem was logic, or the business rule was wrong, or the thing was going to break in production, I blocked. Anything else I wrote down, explained in plain words why it mattered and what it would cost us later, and asked for it in the next pull request. A folder name is not worth holding a feature hostage.
I also sat on the other side of that rule, and it taught me more. I have waited days on a change because a comment said the code was “not the standard”, and nothing else. No example. No reason. No suggestion of what the standard was. I would ask, the answer would arrive the next morning, then a second round, and meanwhile a finished feature sat there earning nothing while two engineers negotiated a naming convention. Some of that was real quality work from people who cared. Some of it, if I am honest about the ones I remember, was ego with a good technical vocabulary.
I once wrote that code review is not about ego, it is about money. I still believe that. What I did not see back then is how much unrelated work we had all quietly parked in the same place, and how much of it could have been settled before anybody wrote a line.
Code review was never one practice. It was six practices wearing the same coat.
The interesting part is that this was never a secret. A Microsoft study back in 2013 found that most developers named defect detection as the main motivation for review, while only 14 percent of the actual comments were about defects. We have known for over a decade that we were doing something other than what we said we were doing. It just never cost enough to matter.
The math stopped working
Now it costs. DX measured that the median pull request grew 64 percent in a year, and that AI is pushing up both the size of each change and the number of changes. Inside Meta, the reported numbers are harder still. Significant lines of code per human landed diff up 106 percent in a year, diffs per developer per month up 51 percent, more than 80 percent of that growth coming from agentic AI, and the share of diffs reviewed within 24 hours going down. In some groups, thousands of reviews waiting.
Then there is the number that made me stop. Developers say that in an ideal week they would spend about 7 percent of their time reviewing code. Not 30. Seven.
So the input tripled and the appetite did not move. That is not a process problem, it is arithmetic. And it lands on the business before it lands on anybody’s calendar. Code sitting in a review queue is finished work that is earning nothing. We paid to build it, we are paying to hold it, and the value only starts when it ships. Every week that queue gets longer, the return on the AI investment gets quieter, which is the same trap I described in the note about pilots that never land.
Same diagnosis, different medicine
Here is where it gets uncomfortable. Rachel Laycock says the problem is that we wait until the end to have the important conversation. If we want alternatives explored, do it before somebody implements one. If we want knowledge transfer, pair. If we want architectural alignment, design together and encode the constraints. Review by exception, for the changes where a human really needs to look. Her line stayed with me. Engineers should understand systems, not diffs.
Brian Houck worries about what disappears if we automate the ceremony away. His argument is that the visible output of review is better code and the invisible output is a better engineering organization. Automate the diff and you may have reviewed the diff, but nothing moved from one head to another.
I read both and I nodded at both, which is usually a sign that I have not thought hard enough yet. What I notice is that they agree on the diagnosis. Review was carrying more than it should. They disagree about where the weight goes now.
The part I keep circling
I have approved code this year that I understood in shape and not in detail. I would like to tell you that never happened. It happened.
That is the honest sentence, and it is why I cannot pick a side yet. If I say “review by exception”, I have to believe my team is really doing the pairing and the design sessions and the fitness functions. Some days we are. Some days we are shipping. If I say “keep reviewing everything”, I am asking a small group of people to absorb a volume that grows every month, and I already know how that story ends. They will read faster, and then they will read less, and the approval will still be there.
Approving code nobody understood is not a review. It is a signature.
The thing I actually care about is the one neither approach hands me for free. Six months from now, when something breaks at an awkward hour, does somebody on the team know why the code is shaped that way? That was always the real product of review, and it never showed up on a dashboard. It is the same comprehension debt I keep writing about, and I still do not know which practice pays it down at this volume.
So I am leaving this one open. Not because I am being coy, but because I think the honest position right now is a question. What are we actually buying when we require a human to read every change? If the answer is confidence, there might be cheaper ways to buy it. If the answer is a team that understands its own system, then review was never the point, it was just the last place we still made time for it.
I would rather sit with that for a while than pretend I know. And knowing me, I will probably come back here in a few months with a second note and a very confident answer . Hold me to it.
Pax et bonum.