Code Review Doesn’t Start With a Pull Request. It Starts With the Plan.

We’re asking the wrong question

I’ve spent more than 20 years reviewing code, designing systems, mentoring engineers, managing releases and dealing with whatever broke in production. Now AI can generate the code, review the pull request, write the tests and flag likely vulnerabilities. So I’ve been asking myself how much traditional code review we still need.

I think that’s the wrong question. Whether AI can review code matters less than whether we’re building and delivering what we actually intended.

An AI review can tell me the code follows best practices, the implementation is efficient, the tests pass, there are no obvious vulnerabilities and the architecture looks reasonable. All of that can be true of a feature the customer can’t use. A technically correct implementation can still be the wrong solution, and a code review won’t tell you which one you have.

AI has also moved the bottleneck. Engineers used to spend most of their time writing the code. Now a team can produce code faster than it can confidently verify it. That makes review more important, and it makes reading every diff line by line a poor way to spend the time we have.

Every change has to answer three questions: did we build it correctly, did we build the right thing, and can we operate it safely?

Review the plan before the code

Reviewing an implementation plan is often worth more than reviewing hundreds of lines of code afterward. A wrong approach costs a conversation in planning. In a pull request, it costs a rewrite. After release, it can cost a migration.

Before development starts, I want answers to a short list:

• What problem are we solving, and is it the right problem?
• What does success look like, and what are the acceptance criteria?
• Is this the simplest implementation that would work?
• What existing functionality could this affect?
• What are the security, performance and operational risks?
• How will we verify that it works?

AI is useful here. I ask it to challenge the assumptions in a plan, compare architectural options, and point out requirements nobody wrote down. It’s good at “what about this case?” It doesn’t know which tradeoff the business can live with, so the decision stays with the team. Most of the waste I wrote about in the most expensive engineering work is work nobody needed could have been caught at this stage.

Not every change needs the same review

A typo fix in the docs shouldn’t get the same scrutiny as a change to authentication, billing or a production database. Yet many teams apply one rule to every pull request: two approvals, whatever it touches. The trivial change waits as long as the risky one, and the risky one gets the same quick skim as the trivial one.

I’d rather match review effort to risk:

The tradeoff is real. More human review costs delivery speed. Less review means more risk of defects, and the cost of a defect depends on where it lands. Keeping changes small helps whatever model you use, because a reviewer can actually hold a small change in their head. I went into that in smaller user stories and pull requests.

What AI should review

Much of what reviewers traditionally comment on is repetitive, and AI handles it well:

• Coding standards and consistency with the rest of the codebase
• Common bugs and missing error handling
• Known security vulnerability patterns
• Unnecessary complexity and duplicate logic
• Performance concerns, like a query inside a loop
• Gaps in test coverage and likely regression risks
• Documentation that no longer matches the code

Letting AI take this first pass means people stop spending review time on formatting and naming.

AI review has limits, though. It produces false positives, and people learn to ignore them. It misses subtle problems, especially ones that depend on how the rest of the system behaves. It doesn’t know the business context unless someone gives it. And it can confidently approve an implementation that’s wrong. When AI wrote the code and also reviewed it, both can share the same misunderstanding of the requirement. An AI review is one input. It shows the code was checked. It doesn’t show the code is safe. I wrote about what that looks like in a real diff in I can recognize AI-generated code.

What people should still review

Human attention is expensive, so I want it on the decisions that need context, accountability and judgment:

• Are we building the right thing? Does the change address the customer’s problem, or only the ticket’s wording?
• Is the design appropriate? Are we adding abstractions or moving parts the problem doesn’t need?
• What could go wrong? Operational failures, security boundaries, scale, data integrity and side effects in other parts of the system.
• Can the team maintain it? Will another engineer understand this six months from now?
• Are we comfortable deploying it? And who owns the risk if it fails?

A reviewer who spends their time on these, and leaves the routine comments to automation, adds far more than one who reads every line looking for style issues.

Is it delivering what I expected?

This is the question I care about most. A developer can implement exactly what a ticket says and still deliver something the customer can’t use. An AI agent can do the same thing, faster.

A feature can pass every unit test and still confuse users, add steps nobody needed, break an existing workflow, handle only the happy path, show error messages nobody understands, or fall short on accessibility. Sometimes it simply doesn’t solve the original problem.

Here’s a hypothetical workflow from an app for federal contractors. A user creates an account and adds several companies. Each company can have more than one UEI, the unique entity ID that identifies a business in federal contracting. The user switches between companies and takes an action for whichever company is selected.

Every API endpoint behind that can work perfectly, with green unit and integration tests. An end-to-end test can click through the whole flow and pass. And there are still questions none of those tests answer:

• Does the user understand which company is active right now?
• Could they change another company’s data by accident?
• Does switching companies keep the right context everywhere, including open tabs and cached data?
• Are permissions enforced on every path, or only the ones the UI shows?
• Does any of it make sense to someone using it for the first time?

Unit tests tell you the parts behave. Integration tests tell you the parts talk to each other. End-to-end tests tell you the workflow runs. None of them tell you the workflow is useful. That takes code quality, security testing, end-to-end testing and someone actually walking through the product as a user, together.

So who on the team is responsible for checking that the feature delivers the intended outcome?

If the answer is “QA will catch it” or “the product owner will see it in the demo,” it probably gets checked late or not at all. Acceptance criteria, product validation and real customer workflows deserve the same attention as the source code.

Review continues after deployment

Most teams treat a merged pull request as the end of review. I think production is where we find out whether the engineering decision was right. Review after release means:

• Verifying the deployment did what we expected
• Rolling out gradually behind a feature flag when the risk justifies it
• Watching error logs, performance metrics and alerts
• Looking at how people actually use the feature
• Reading customer feedback and support tickets
• Catching regressions early, with a rollback ready if we need it

A successful deployment doesn’t mean a successful feature.

A review process for the AI era

Putting it together, this is the process I’d propose:

1. Plan review. The problem, acceptance criteria, design, dependencies and risks.
2. Implementation review. AI does the first pass: code review, static analysis and test gaps. People review based on risk and complexity.
3. Functional validation. The feature behaves the way the requirements say.
4. End-to-end validation. The whole customer journey works, including edge cases and failures.
5. Release review. Deployment risk, monitoring, rollback plan and readiness.
6. Post-release validation. The feature does what we expected in production.

For a low-risk change, most of these stages take minutes, and some are a single question. For a change to permissions or billing, each one deserves real time. I’m not proposing six approval gates for every pull request. I want the right review effort at the right stage.

Too much review, or too little?

I see teams go wrong in both directions.

With too much review, developers wait days for approval. Several engineers review a one-line change. Comments argue about style instead of outcomes. Review becomes the bottleneck and people lose momentum.

With too little review, AI-generated code gets merged by people who don’t understand it. Security and data-integrity risks go unnoticed. Teams ship features that technically work and still fail users. Incidents go up and technical debt piles up. Endless AI review loops are their own version of this, and they cost more than people expect, as I covered in the hidden cost of AI coding.

To tell which problem you have, look at a few measures together: review turnaround time, change failure rate (one of the DORA delivery metrics), escaped defects and customer-reported issues. Fast reviews with a rising failure rate mean you’re reviewing too little or reviewing the wrong things. Slow reviews with few escaped defects may mean you’re over-reviewing low-risk work. I wouldn’t use lines of code reviewed or number of approvals as a measure of quality. They measure activity.

As engineering leaders, our job isn’t to make sure another engineer has read every line. Our job is to make sure the team delivers the right solution, safely and reliably. AI changes how we do that. We should automate the repetitive review and spend engineering expertise where it creates the most value. And developers still need to understand the systems they build, whether a person or an AI wrote the code.

Short answers