ai-code-review

Looks Good To Machine

AI wrote the code. AI reviewed the code. Guess who still gets paged.

The situation

We taught AI to write our code, and it does, at a pace that makes last year's velocity charts look like a crypto scam. So naturally, someone in a planning meeting said the obvious next thing: reviews are the bottleneck now, let's have AI do those too.

Here's the new pipeline. A model generates the code. A second model reviews the code. A human receives a condensed summary of that review and decides whether to approve. One robot is grading another robot's homework, and you are signing the report card.

The catch is that the report card goes in your file, not theirs. When this code falls over at 2 AM, the incident channel does not page a model. It pages a person. Probably you.

So the real question is not whether AI code review is good. It's already on the roadmap. The question is how a human re-reviews a machine's review of a machine's code without becoming a very expensive approve button.

The trap: a condensed review feels like certainty

A condensed AI review is dangerous the same way a movie trailer is dangerous. It shows you the explosions and hides the plot holes. It arrives confident, well formatted, and complete, and your brain quietly files the whole PR under "checked."

Two failure modes follow. In the first, reviewers skim the summary, see "no critical issues," and approve. Your review process is now a vibe. In the second, reviewers trust nothing, reread every line from scratch, and the AI review saved zero minutes while producing one more document nobody asked for. Most teams oscillate between the two and call it a process.

There's also a quieter problem: responsibility laundering. The developer assumes the AI reviewer caught things. The reviewer assumes the developer and the AI both looked. When the bug ships, it was reviewed by everyone and owned by no one. The ball doesn't get dropped dramatically. It gets dropped politely, in the gap between "the AI checked it" and "someone checked it." Those are not the same sentence.

Different robot for the red pen

Before we sort out the humans, fix the machine side of the org chart: the model that writes the code should not be the model that reviews it. Same model means same training, same habits, same blind spots. Asking a model to review its own family's output is like asking your twin to audit your taxes. Technically a second person. Spiritually the same guy.

Finance solved this centuries ago and called it segregation of duties: the hand that writes the check never approves the check. Apply it to the pipeline. Use a different model family for review, ideally from a different vendor, so the reviewer brings different biases instead of the same ones wearing a monocle. Bonus: disagreement between the two models is free signal. When the writer and the reviewer argue, that is exactly where a human should look first.

Split the job: breadth for machines, depth for humans

AI reviewers are genuinely good at breadth. Naming, style, missing null checks, obvious injection patterns, the unhandled error on line 240 that every human would have scrolled past. Let the machine own all of that, fully. If you're still checking whether the robot checked the formatting, you are wasting a human brain on a solved problem.

What the machine cannot do is context. It doesn't know this service falls over every tax season. It doesn't know the requirement itself is wrong. It doesn't know that touching this particular table has ended careers. It reviews the code that exists. Humans review whether that code should exist, in this shape, in this system, right now.

That split gives everyone a real job. Here's what each one looks like.

The developer's job: you are still the author

Prompting is authorship. "The AI wrote it" is the new "it works on my machine," and it will get exactly as much sympathy in the incident review.

  1. Read your own diff before anyone else does. Every line. If you can't explain a line, you have two options: understand it or delete it. There is no third option where you ship it anyway.
  2. Run it. The AI reviewer reads code. It does not experience your staging environment's personality. Behavior gets verified by a human with logs open.
  3. Annotate the PR with intent. Three sentences: what this changes, why, and what you're unsure about. Point at the sketchy part yourself. Reviewers forgive doubt. They do not forgive surprises.
  4. Flag what needs human eyes, and make it loud. You know which parts you generated while nodding along and which parts touch something with teeth. Mark them with an explicit, greppable tag in the PR, something like HUMAN REVIEW REQUIRED, on the auth change, the money path, the migration, the block you can't explain in one sentence. The AI reviewer doesn't know what it doesn't know. You do. Route the human's attention before they start scrolling.
  5. Triage the AI review before a human sees it. Fix the real findings, reply to the wrong ones with reasons, and do not hand your reviewer 37 open robot comments like a haunted advent calendar.

The developer's output is no longer just code. It's code plus a signed statement of what was actually checked. That statement is what makes the human review fast instead of fake.

The reviewer's job: review the code and the review

You are now reviewing two artifacts, and the second one lies by omission.

  1. Don't redo the machine's work. If you're commenting on variable names after an AI pass, you are cosplaying 2021.
  2. Go where the model is blind. Does this change fit the architecture? Does it match the actual requirement, not the requirement as the prompt imagined it? What's the blast radius? What breaks downstream? Would this survive an auditor?
  3. Spot-check the AI review itself. Pick two or three of its claims and verify them against the diff. If they hold, extend some trust. If one is wrong, the summary is fiction and you read the code properly.
  4. Treat "no issues found" as a prompt, not a permission slip. Clean reports deserve more suspicion, not less.
  5. Open the raw diff for anything risky. Auth, money movement, data migrations, deletes. The summary is a map. Maps famously leave things out.

Guardrails so the ball stays in the air

Tier the risk, and write the tiers down. Low-stakes changes like docs, tests, and config bumps can ride on AI review plus a light human glance. High-stakes changes, meaning anything touching auth, payments, or customer data, always get a human reading actual code, no matter how glowing the robot's summary is. This has to be written policy, because "use judgment" decays into "click approve" within a month.

Add one hard rule: nothing merges on machine approval alone. Ever. The AI review is an input to a human decision, not a substitute for one. And give it a twin: nothing merges while a HUMAN REVIEW REQUIRED tag sits unresolved. A developer asked for human eyes. If none showed up, that merge isn't fast, it's a confession.

Then measure the right thing. If review time drops 80 percent while escaped defects climb, you didn't get faster. You got looser, with extra steps and a subscription fee. Track what leaks into production, not how quickly you approved it.

The point

AI review is a briefing, not a verdict. One machine writes, a different machine reads everything, and the human thinks about the things machines can't. Developers flag their own risk and own what they ship. Reviewers interrogate both the code and its robot chaperone. And nobody outsources accountability, because accountability is the one thing in this pipeline that still can't be generated.