Code Review Has Changed. The Contract Needs to Change Too.

For years, code review has been one of the core rituals of software engineering. A developer writes code and opens a pull request. Another developer reads the diff, looks for bugs, checks the tests, questions the abstractions, and decides whether the change is safe to merge.

That workflow made sense when writing code was a scarce resource in software development. But coding is no longer scarce. AI tools have made it dramatically cheaper to produce code, which means developers can generate larger changes faster. Agents can pick up a task, write a feature, add tests, and open a PR with very little human implementation work.

The volume of code reaching review is increasing, but the number of senior engineers available to review it has not increased accordingly. The bottleneck has moved. It used to be writing code; now it’s verifying code. However, most teams are still treating code review like nothing has changed.

The Industry Is Already Moving

Some companies are making human PR reviews optional on their own monorepos. Their auto approver reads a diff, classifies risk, and approves certain PRs without a human reviewer ever looking at the code.

That sounds extreme - and it should. But the interesting part is not that humans disappeared. Reviews still need security checks, CODEOWNERS for sensitive paths, stale approval detection, evaluation data, and a culture where engineers still own what gets merged. The human checkpoints moved to a different part of the system.

That’s the shift. The question is no longer, “Can every line of code be reviewed by a human?” The better question is: “Which changes actually require human judgment?”

Review Is Not Just Defect Detection

AI has not eliminated the need for code review; it simply changed its objective.

The old model treated review primarily as defect detection. The reviewer’s job was to find mistakes in another person’s implementation: a missing edge case, a broken assumption, a test gap, a strange abstraction, or a hidden performance issue.

That work still matters, but it cannot be the whole job anymore. Models are already good at finding mechanical issues: missing null checks, inconsistent naming, unhandled error paths, test gaps, and violations of local conventions. Sometimes they’re even too good at it.

One of my senior engineers described his first pass on a PR as a basic sanity check: Is this change likely to introduce something breaking? Does this architecture make sense? Is this a maintainable solution?

If he has time, he will proceed to pull the branch down and run his own review. He almost always finds something, but the findings are increasingly nitpicky. It’s an exercise that might be useful, but it’s certainly not the highest value use of senior engineering judgment.

The greatest value of a human review is deciding whether an incoming change is the optimal solution, or if it should happen at all.

The New Goal of Code Review

Here is the definition I keep coming back to: The goal of code review is for the author to convince the reviewer that the chosen solution is the optimal solution for the problem.

That framing changes the review contract. The author’s job is not just to submit code, it’s to make the problem, the solution, the tradeoffs, and the confidence level legible. The reviewer’s job is to decide whether the change makes sense in the broader context of the system.

This matters even more when AI is involved. AI-generated code can look plausible without being well understood. It can follow local patterns, pass tests, and satisfy the narrow prompt it was given.

But “looks right” is not the same as “is right.” An AI model will build to spec, which means that one of the most important human jobs is making sure the spec makes sense in the first place.

Start With the Problem

Before a reviewer can evaluate a diff, they need to understand the problem. What is this PR trying to solve? Why does it matter? What constraints shaped the work? What was intentionally left out?

Without that context, the reviewer is forced to reverse engineer intent from code. That workflow was already inefficient back when humans actually wrote every line. With AI-generated code, it becomes more dangerous, because there may be less human intent embedded in the implementation than the diff suggests.

Once the reviewer understands the problem, they can evaluate the chosen solution. What approach did the author choose? What alternatives were considered? Why this one? What assumptions does it rely on? What areas are risky?

This is where code review becomes less about correctness and more about judgment. A solution can be technically correct and still be wrong for the team. It might introduce a new pattern where an existing one should have been used. It might add a dependency the team does not want to maintain. It might make the broader system harder to reason about.

These are not always things a model can determine from the diff alone. They require system context, product context, team memory, and taste. That is why human review still matters.

The Reviewer’s Real Question

A good senior engineer does not only ask, “Can this work?” They ask, “Will we regret this?”

That is the question modern code review needs to center on. As code gets cheaper to produce, the cost of bad decisions goes up. A large, messy, almost correct PR can now be generated quickly. But reviewing it, understanding it, debugging it, and living with it still costs the team real time.

The danger is not that AI writes obviously terrible code. The danger is that AI writes code that is good enough to merge, but not good enough to own. That is where teams get into trouble. Reviewers start skimming, and authors assume that passing tests means the PR is fine. Everyone feels pressure to preserve velocity. The path of least resistance becomes rubber stamping.

That is not a code quality problem - it’s an operating model problem.

The New Code Review Contract

Opening a PR should no longer mean, “I wrote the code. Please check it.” It should mean, “I believe this is the right solution. Here is the evidence.”

A good PR description should answer a few basic questions. What problem does this solve? Why is this the right approach? What alternatives were considered? What areas are risky? How was this tested? What should the reviewer focus on?

Modern code review should also be risk-based. Routine changes can be handled with small PRs, strong tests, automation, and AI-first-pass review. Architectural changes need slower human review. Sensitive changes - like billing, auth, permissions, data deletion, migrations, infrastructure, and security boundaries - need the deepest review.

The reviewer is no longer just a defect finder, they’re a validator of judgment. The author is no longer just a code submitter - they are also responsible for explaining why their solution is the right one. The tools are no longer just autocomplete, they are part of the verification system.

When those roles are clear, review can get better. The author owns intent. The reviewer owns judgment. The tools provide leverage.

The main question isn’t whether one human can find mistakes in another human’s code, but whether the team can maintain a shared understanding of the system while the volume of code increases. Because the bottleneck in software development is not typing code - and hasn’t been for some time now. It’s understanding whether the code should exist at all.

Code review has changed. Now the contract has to change too.