Code Review After AI: What Has to Change

The single most underappreciated change in software engineering this year is that code review broke, and most teams haven't noticed yet.

The break is structural, not sentimental. The old code review playbook — "read the diff, assume the author thought about it, push back on parts you don't understand, approve" — depended on an assumption that's no longer reliable: that the code in front of you was written by the person who submitted it, and therefore that the questions you'd usually ask ("why this approach?", "did you consider X?") would land on someone with answers.

When the draft was produced by an AI agent — and at this point, in most repos with adopted AI tooling, the majority of net new code is — those questions land in a different place. Sometimes the human author has answers; often they have plausible answers that come from the same model that wrote the code; sometimes they have nothing. The review loop, which was built on a particular kind of conversation, has lost the conversation.

What's needed isn't a return to "humans must write all the code" — that ship has sailed and the productivity gains are real for the parts that fit. What's needed is a new set of rules for reviewing code in an era where the draft is automated and the verification is the bottleneck. This is the version of those rules we've landed on, after a year of iterating.

Rule 1: The author defends, doesn't explain

The old PR description format was a summary of what the change does. That's fine when the author wrote the code, because the description was redundant with the diff but reassuring. When the code was AI-drafted, "what it does" can be read off the diff by anyone, and the author's description should answer a different question: why this approach, and what alternatives were considered?

We've moved to PR descriptions that look more like a design doc summary than a changelog. Three sections:

• The problem. What is this change addressing? Specific, named, testable.
• The approach. Why this approach, and not the obvious alternative? If the answer is "the model suggested it and it worked," that is not a defense.
• The risks. What could go wrong? Where did you stress-test the change?

The third bullet is the one that exposes most thin reviews. If an author can't articulate what could break, they haven't sat with the change long enough.

Rule 2: Treat "looks plausible" as the failure mode

The old failure mode in code review was "I don't understand this code, but the author seems smart, so I'll approve." The new failure mode is "this code looks like code I'd write, so I'll approve."

The second failure mode is worse, because plausibility is exactly what large language models are optimized for. The output will reliably look like the kind of code that a competent engineer would have written. It will not reliably be that code. The difference between plausible and correct can be a renamed variable that no longer matches its initializer, a missing edge case in the third arm of a switch, an inverted condition in the unhappy path.

The practical change: read the diff with the assumption that something subtle is wrong, and look for it. Not "skim the diff and trust the patterns." The trust calibration that worked for human authors is dangerously miscalibrated for model output, because the surface fluency is high and the deep correctness is variable.

Rule 3: Read the tests first

When the author wrote the code, the tests are usually a secondary check — "did they remember to test." When the code was drafted by a model, the tests are the primary documentation of intent: what did the author actually believe the code should do?

We read tests before diffs now. If the tests cover the happy path and nothing else, the change isn't ready. If the tests pass but only because they assert the current behavior of the new code rather than the expected behavior, the change isn't ready. If there are no tests at all and the change isn't a documentation update, the change isn't ready.

This is not new advice. It is newly load-bearing.

Rule 4: Force the diff smaller

A 600-line PR was always a bad PR. It is much worse now, because the cognitive cost of reviewing a 600-line AI-drafted PR is higher than reviewing a 600-line human PR. Every paragraph of code needs the "is this plausible-correct or actually-correct?" check, and that check does not parallelize well across a large diff.

We've started rejecting PRs over a threshold size with a comment that's gotten harder-edged over time. The current version is roughly: "This PR is too large for a useful review. Please split it into the smallest atomic changes that pass tests. We will review the resulting smaller PRs faster than this one." The number is around 300 lines of net new code. Below that, the review is sharp. Above it, the review is performative.

This was also true before AI. The tolerance has narrowed because the cost of imprecise review has risen.

Rule 5: Reject vibes-driven approval

"LGTM 🚀" has always been a weak review. It is now a dangerous review, because it is exactly the kind of fast approval that AI-drafted code most reliably defeats.

A useful review has at least one of:

• A specific question about a specific line.
• A concrete suggestion ("consider X instead of Y because Z").
• A test scenario the author hasn't considered.
• An explicit affirmation: "I read this carefully, I understand what it does, I've considered the edge cases I could think of, I'm approving."

We don't enforce this with a bot. We do enforce it with culture: a one-emoji approval gets the comment "can you say more?", and the reviewer either does or removes their approval. This has been more effective at improving review quality than any tool change.

Rule 6: The author is responsible, regardless of where the code came from

The most important rule, and the one that takes the longest to internalize across a team: the human who opens the PR is the author, in every sense that matters. They are accountable for the code that was committed. "The model suggested it" is not a defense. "I didn't write that part" is not a defense. If it's in the PR, it's the author's now.

This sounds harsh and it's actually what makes AI-assisted development workable at all. If authors are accountable for the model's output, they read it carefully before they ship it. If they're not, they don't, and the team accumulates technical debt at a rate that no review process can compensate for.

We've made this explicit in our contribution guidelines. The line reads: "If you submit a PR, you are claiming that you understand every line of the diff and stand behind it. The origin of the draft is irrelevant."

The math

There's a number worth knowing: PR review times in repos that have adopted AI tooling are up roughly 91% on average, while PR count is up about 98%. The throughput of code in is up; the throughput of code understood is approximately flat.

The rules above are an attempt to close that gap. They cost time at submission and they recover time at review, which is where the gap actually lives. A well-described, narrowly-scoped, well-tested PR with a defensive author can be reviewed in roughly the same time as a small human-written PR was reviewed in 2023. A poorly-described, sprawling, AI-drafted PR cannot.

The teams who keep their old rules and absorb the new draft style end up with longer review queues, more rewrites, and the productivity statistics from the AI productivity paradox. The teams who tighten their rules — who shift the cost upstream, to the author, where the cost is cheapest — get back to a healthy review pace at a higher throughput.

Code review is not broken because AI is bad. Code review is broken because it was tuned for a different cost structure, and the new structure rewards different habits. We're early. The habits that will become normal in 2027 are the habits we're slowly forming now. The teams paying attention will get there first.

---

Practiced at Syntax Lab Technology across four products and five engineers. Your team's rules will vary; the principles probably won't.