Code Review in the Age of AI-Generated PRs
We now generate code faster than we can reliably review it. Practical principles for reviewing AI-generated pull requests without slowing your team down.
By Subash Adhikari · · 4 min read
AI has made producing code almost free.
A feature that used to take a couple of days now shows up as a pull request before lunch. Tests included. Nicely formatted. Confident description.
That's great for the first pillar of the Delivery Trinity: our ability to produce code has never been higher.
But it quietly moves the pressure somewhere else. If anyone can generate a thousand lines in minutes, the hard question is no longer "can we write it?" It's "are we confident enough to ship it?"
And for most teams, that confidence still comes down to one thing: a human reading the code. The trouble is that we now generate code faster than we can reliably review it.
Code review is now the bottleneck. Here's how I think about it.
The author is still the author
The most important rule is the simplest one.
If your name is on the PR, you own every line in it. It doesn't matter whether you typed it, pasted it, or an agent wrote it while you made coffee.
"The AI wrote that bit" is not an answer in a review. If you can't explain why a line is there, it's not ready for someone else to look at.
Reviewers shouldn't be the first human to read the code. The author should be.
Small PRs matter more than ever
AI makes big changes cheap to create. It doesn't make them cheap to review.
Google's engineering practices guide says there are no hard rules, but 100 lines is usually a reasonable size for a change, and 1000 lines is usually too large. That advice was written for humans typing code. It matters even more when a model can produce the 1000-line version in seconds.
Ask the agent for small steps. Split refactors from behaviour changes. Ship the boring plumbing first, then the feature on top. A reviewer can actually reason about a small diff. A huge one just gets skimmed, and skimmed code is where bugs hide.
Review the intent, not the syntax
Linters, formatters and type checkers handle style. AI handles a lot of the boilerplate. So what's left for the human?
The questions a machine can't answer for you:
- Should we build this at all? Is this the right change for the product right now?
- Does it fit the system? Google's guide puts it well: the most important thing to cover in a review is the overall design. Does this belong here? Does it integrate with what we already have?
- What happens when it goes wrong? Edge cases, failure modes, retries, data that isn't shaped the way the happy path assumes.
- Can we live with it in six months? Someone will have to debug this at 2am. Will they understand it?
AI-generated code tends to look plausible. It compiles, it reads well, and it's often subtly wrong in exactly the places that matter. Reviews should spend their time there, not on variable names.
Make the PR description do the work
A good description is a gift to your reviewer. With AI in the loop, it's no longer optional.
Tell me:
- What problem this solves and why now.
- What you checked yourself, and how.
- Which parts were generated, and which parts you'd like a careful second pair of eyes on.
- What you deliberately left out.
If the description is also AI-generated and says nothing, that tells the reviewer something too.
Use AI to review, but don't outsource judgement
AI reviewers are genuinely useful. They're good at catching obvious bugs, missing null checks, inconsistent naming and forgotten tests. Let them do that first pass, so humans don't waste time on it.
What it can't do yet is verify a change end to end: actually use the product, click through the flows, and confirm it behaves the way a user expects. Today, that still needs people.
Approval is also a judgement call about risk, and that stays with people too. An AI reviewer doesn't know the customer conversation from last week, the incident from last quarter, or why that weird-looking function exists.
Don't chase perfect
This one cuts the other way.
When code becomes cheap, it's tempting to demand perfection in every review. "Just ask the AI to rewrite it." Endless rounds of nitpicks.
That's the same dogma trap, just with new tools. Google's standard is the one I like: approve a change once it definitely improves the overall code health of the system, even if it isn't perfect.
Review exists to give us confidence to release. Once we have that confidence, ship it.
What actually matters
When writing code was expensive, code review was a safety net. Now that writing code is cheap, it's become the main way we decide what's good enough to ship.
So treat it that way:
Own every line you submit. Keep changes small. Review the intent, not the syntax. Let AI do the first pass, and keep the judgement human.
In the end, what we care about is whether the software works and how it behaves, not how the code looks. For now, review is how we earn that confidence.