Ask an engineering team why they review code and the answer will be about quality: catching bugs before they ship, keeping the codebase consistent, stopping the bad change before it lands. Watch what review actually does over a year and a different picture emerges. The defects it catches are real but few, and most of them would have been caught by tests or by the first user. What review reliably produces is something else: a new engineer who understands the system because they read a hundred diffs in their first month, a senior engineer who knows what everyone else is building, and a team that owns the codebase collectively rather than in private territories. Review was never mainly about bugs. It was the mechanism by which a team learned its own system, and nobody said so because catching bugs sounded like a better reason.
This matters now because the assumption underneath review, that a human wrote the code and another human can read it in roughly the time it took to write, has stopped being true. When a machine produces most of the diffs, the volume of code arriving for review grows far faster than the attention available to read it, and the review process either becomes a rubber stamp or becomes the bottleneck the generation was supposed to remove. Teams are noticing this and responding with the only tool they have, which is to tell people to review harder. That is not a plan. It is a wish, and it fails for the same reason it always would have.
What review was quietly doing
Being honest about what review produced is the first step to rebuilding it. Onboarding is the clearest case. A new engineer learns a codebase by reading changes to it, because a change shows what matters, why it matters and who cares, in a way that documentation never does. Context spreading is the second: review is how the person working on billing finds out that the person working on auth changed something that affects them, without anyone having to schedule a meeting. And shared ownership is the third, the least measurable and the most valuable, the sense that the system belongs to the team and that anyone may, and should, have an opinion about any part of it.
None of these functions requires that every line of every change be read by a second person. They require that changes be visible, that people look at the ones that touch what they care about, and that the team has a shared place where the shape of the system is being discussed. Review happened to provide all three as a side effect of its stated purpose. The stated purpose is now impossible at the volumes involved. The side effects are still what the team needs, and they can be provided on purpose instead of by accident.
The problems review was solving badly
Some of what review was doing, it was doing badly, and the pressure of volume is a good excuse to stop. Review was used to enforce style, which a formatter does better. It was used to enforce architectural rules that nobody had written down, which meant the rules lived in the heads of the reviewers and were applied unevenly. It was used to gate deploys, which meant a change waited on whoever was slowest, and the wait was blamed on the process rather than on the fact that the process was doing three jobs at once. And it was used, quietly, to let senior people feel in control of a system that was already too large for any one of them to hold.
Review was never mainly about bugs. It was the mechanism by which a team learned its own system, and nobody said so because catching bugs sounded like a better reason.
Stopping these is not a loss. Style belongs in tooling. Architectural rules belong in writing, and if writing them down reveals that nobody agrees on them, that is a discovery worth making. Deploy safety belongs in tests, staging and progressive rollout, none of which depend on a tired human reading a diff late in the afternoon. And the feeling of control was always an illusion at scale; giving it up is uncomfortable and honest. What remains after these are removed is a much smaller set of things that genuinely benefit from a person’s attention, and that set is small enough to be affordable even when the volume of code is not.
What still deserves a human
The smaller set looks something like this. Changes to the boundaries of the system, the interfaces other teams or customers depend on, because those are promises and promises deserve a second opinion. Changes to anything that moves money, grants access or touches data that cannot be regenerated, because the cost of being wrong is not symmetrical. Changes that introduce a new pattern the team will copy, because the first instance sets the standard for every instance after it. And changes made by someone new, not because their work is suspect but because reading their work is how the team gets to know them and they get to know the team.
The list will look thin to engineers raised on the belief that everything must be reviewed, and that reaction is worth sitting with, because it reveals how much of the old process was ritual. Most changes to most systems are small, local and reversible, and a human reading them was never adding much beyond the comfort of having done so.
Everything outside that set can be handled differently: merged on the strength of tests, sampled rather than exhaustively read, or reviewed after the fact by a machine looking for known failure shapes while humans spend their attention where it changes outcomes. The proportion of changes that fall inside the set will vary by company, but it is rarely more than a fifth, and a review process that puts a human on a fifth of the changes with real attention beats one that puts a human on all of them with none.
Keeping the learning alive
The remaining problem is the one review solved best and the one that is hardest to replace: the learning. If nobody reads every diff, how does the new engineer learn the system, how does the team find out what other parts of it are doing, and how is ownership kept shared. The answer is to build those things directly, since the accidental version has stopped working. A weekly walk through the changes that mattered, presented by the people who made them, spreads context better than a queue of unread approvals ever did. Written design notes, short and required for anything in the human-review set, give newcomers a map that diffs never provided. And a habit of assigning new engineers to read, and summarise, a slice of the week’s changes teaches them the system faster than reviewing it line by line would have.
None of this is as tidy as the old process, which had the great advantage of being one thing that appeared to do everything. But the old process only appeared to do everything, and the volume of machine-written code has removed the appearance. What is left is a chance to build, deliberately, the parts of review that were always the point.