How to — review AI-written code before you merge it
You want to merge AI-written code without reading every line of it — and still be able to say, out loud, what it does and what happens when it breaks. That is a review job, and it is mostly about reading the right parts in the right order.
Cockroach Labs ran its codebase like a teaching hospital for five months and reports merging well over a million lines of code with seven total reverts — a run where no agent's plan moved without a human-signed review first (we covered Coding agents as a hospital: Cockroach's five-month results). The speed was never the interesting part; the review protocol was. Meanwhile the review workload is visibly rising: a longitudinal study of 33,228 pull requests across vLLM and SGLang found PR comment density up more than fourfold while PR size stayed roughly flat — comments per change are growing, the changes are not shrinking. Reviewing agent output is becoming the job. If "vibe coding" is an unfamiliar label for what your team already does, AI 101 — What is vibe coding? is the two-minute version.
1. Start from the request, not the diff. Before you open the change, write one sentence: what did I ask for? Then read the diff against that sentence. Anything that isn't in the sentence — a refactor "while I was in there," a renamed variable, a new helper nobody requested — is scope creep, and scope creep is where wrong code hides. If the diff doesn't map cleanly onto your sentence, the first finding is the mismatch, not the syntax.
2. Read the failure path first. The happy path is what the agent tested and what the summary describes, so it is the part you understand best already. Go straight to what happens when the network call fails, the input is empty, the permission is missing, the retry lands twice. Confident code reads worst exactly there: errors swallowed, defaults assumed, partial writes committed. Deletions, overwrites and anything that migrates data get the same first-line treatment — irreversible changes are checked last in the diff and should be checked first by you.
3. Probe three edges yourself. Pick three cases the happy path never touches — an empty result, a duplicate request, a caller without the permission it assumes — and trace them through the change by hand. Then ask the agent which cases it handled and which it skipped, and verify two of its claims against the actual code. Its list is a starting point, not evidence; the agent that wrote the blind spot is the same one reporting on it.
4. Treat the tests as claims, not proof. Run them, yes — then break something on purpose. Change a value the tests depend on, feed a bad input, and confirm a test actually goes red. A test that passes no matter what the code does is documentation, not a guard. This step matters more than it sounds: in SecProbe, an evaluation published in September 2026 that gave nine frontier models 353 vulnerability-repair tasks across six languages, the best success rate peaked at 28.33%. Agents are not automatically good at the failure modes that bite you, and the tests they wrote inherit that.
5. Audit the new surface. New dependencies: what is the package, who publishes it, does it need network or file access beyond the task? New network destinations and widened credentials count the same. And check the instructions that rode in with the work — a repository you only opened can run code through your AI coding agent, which is why we wrote A repo you only opened can run code through your AI coding agent. A diff is not just code; it is code plus everything the code can now reach.
6. Ask for the explanation, then spot-check one claim. Have the agent describe the change as if to a reviewer, pick one concrete claim — "the cache is invalidated on write" — and confirm it against the diff. When prose and code disagree, you are reviewing prose. Keep the explanation short enough that a mismatch would be obvious.
Don't do this: don't approve a diff you can't re-explain from memory. The summary can be eloquent, the tests can be green, and you can still be merging code you do not understand. If the change is larger than you can reconstruct in your own words, send it back for smaller steps. Size is the one review failure no amount of reading fixes — you cannot read your way out of a diff you lost track of three files ago.
How you'll know it worked: reviews get shorter — minutes per change instead of tens of minutes — while the bugs that reach you turn into disagreement bugs ("it did what I asked, not what I meant") instead of unread-change bugs. You can reopen any merged change a month later and explain why it exists without reading it again, and your revert count stays in single digits even as the agent's share of the commits climbs. That is what Cockroach's ledger was actually measuring.
What's the strangest thing an AI-written diff has slipped past you — and did your review process catch it later? Tell us in the comments.
