You Still Have to Own It: Code Review When the Model Wrote the Diff
A year into treating Claude Code and Cursor as default workflows, the most interesting change on my team isn't how much code we write. It's what code review has quietly become. When a meaningful share of a pull request was generated — and the human author is, honestly, the first reviewer more than the author — the old review checklist stops fitting. "Did you test this?" and "any typos?" were never the point, but they used to be a decent proxy for whether someone had thought hard about their change. That proxy is gone.
The uncomfortable version: it is now entirely possible to open a large, clean, well-formatted, plausibly-correct pull request that the person submitting it does not actually understand. That never used to happen. Writing code by hand was slow enough that comprehension came along for free. It doesn't anymore, and reviewing as if it does is how teams quietly accumulate code nobody can maintain.
The question that replaced "is this correct?"
We changed what a reviewer is asked to certify. The old question was is this correct? The new one is do we understand this well enough to own it at 2 a.m.? Those sound similar. They are not. A diff can be correct and unownable — correct because the model got it right this time, unownable because no human on the team could confidently change it, debug it under load, or explain why it's shaped the way it is.
Correctness is table stakes and, increasingly, the cheap part — evals and tests catch a lot of it, and the model is often right. Ownership is the expensive part, and it's the part that decides whether you can still move next quarter. So that's what review now protects.
A pull request isn't a request to merge code. It's a request to transfer ownership of that code to the team. The model can't accept that transfer. A person has to.
The author defends, not narrates
The practical mechanic that made this real for us: the author has to be able to defend the change, not narrate it. Narrating is "this function parses the response and updates the cache" — a description anyone can read off the diff, or the model can generate for you. Defending is "we cache here rather than in the view layer because the Android side re-subscribes on config change and we were double-fetching; here's the tradeoff we're accepting on staleness." You cannot fake the second one from a diff you didn't think about. It's the single fastest way to tell whether the human understood what they shipped.
So our review conversations shifted from the reviewer hunting for bugs to the reviewer probing understanding. If the author can't answer why the code is shaped the way it is — not defensively, just factually — that's the signal. Not that the code is wrong. That nobody owns it yet. And unowned code merged is a debt with no name on it.
Smaller diffs matter more, not less
The reflex when generation gets cheap is to let pull requests get bigger, because producing them got easy. That's exactly backwards. When the cost of producing a change collapses but the cost of understanding it doesn't, the binding constraint moves entirely onto the human review side. A 1,200-line generated PR isn't a productivity win; it's a comprehension bill you've deferred to whoever reviews it and everyone who touches it later.
We got stricter about diff size, not looser — because the scarce resource is now human attention per line, and the only way to keep review honest is to keep the units small enough that a person can actually hold the whole change in their head and vouch for it.
What this looks like on a 12-engineer team
Concretely: our PR template now asks the author to state, in one or two sentences, the decision the diff encodes and the tradeoff they're accepting — not a summary of the code, the why behind it. Reviewers are told explicitly that "looks correct" is not an approval; "I understand this and I'd be comfortable being paged for it" is. Generated code is welcome — most of ours is, in some sense — but it enters the codebase under a human name, and that name means something.
None of this is anti-AI. My team ships more, and takes on harder problems, precisely because the tools are good. But the tools got great at production and haven't changed the economics of ownership at all. Somebody still has to understand the system well enough to be woken up for it. Review is where we make sure that somebody exists — before the incident, not during it.
If you're rethinking review on a team that's gone all-in on AI tooling, I'm happy to compare notes. Reach me at arun@arunjalota.com.