TL;DR: AI can draft and critique code faster than humans can read every line, but merge decisions still need a human who can explain intent, behavior change, blast radius, and rollback. AI review output is comments, not ownership—teams that replace responsibility structures with “the bot approved it” lose the shared accountability peer review used to create.

AI writes code. Another AI reviews that code.

That is familiar now. Large PRs land; an AI reviewer leaves dozens of comments. The author may not have typed every line; the human reviewer may not read the full diff. AI produces plausible summaries and fix suggestions.

Then someone asks:

Why did you choose this structure?

What existing behavior changes because of this?

If this fails in production, which data and users are affected?

Why does passing this test mean we are safe?

If nobody can answer well, you did not do code review. You performed a ritual of machines echoing each other.

When things break, the dangerous sentence is not “AI wrote this code.” It is “I did not write this code.”

Review bottlenecks are not only “humans are slow”#

The objection is obvious: line-by-line human reading will not scale with AI-generated volume.

Research on traditional review also does not claim humans catch every serious bug. Much feedback targets evolvability—maintainability, readability, structure, docs—more than catastrophic functional defects.[8] As change size grows, comment density falls; review effectiveness ties closely to review size.[7]

AI clearly helps here: repetitive violations, type errors, risky dependencies, missing-test candidates, blast-radius hints, and rule violations faster than humans alone. Studies on AI code review show promise for functional issues and noise reduction when combining multiple independent reviews.[4]

This is neither an argument for banning AI review nor a demand that humans read and approve every diff.

The trap is believing that faster generation automatically expands understanding, verification, and accountability.

AI review leaves comments; code review must leave accountability#

Evidence that AI-only review has fully replaced human review is thin.

A 2026 study of code-review agents analyzed 3,109 PRs from the AIDev dataset. PRs with AI reviewers only merged at 45.20%; human-only review merged at 68.37%. AI-review-only PRs also showed higher discard rates.[1]

Those numbers alone do not prove AI causes failure—harder changes might get AI-only review. They do not support “AI reviewed it, so drop human review.”

Signal quality matters more. Among discarded AI-review-only PRs, 60.2% had meaningful feedback below 30%; 12 of 13 AI reviewers studied averaged signal ratios under 60%.[1]

Many AI comments ≠ safer shipping.

LLM review struggles are not only “the model cannot read code.” Real PR review needs context outside the diff: repo structure, past design decisions, operational constraints tests do not encode, team agreements, customer-facing behavior.

SWR-Bench, using 1,000 real PRs with full-project context, concluded current AI review tools do not reach adequate performance in realistic settings. Top setups suffered low precision—many false positives—and verification cost returns to humans.[4]

AI can say “this value may be null.” It struggles with “null is acceptable for backward compatibility with last year’s app” or “this change’s cost under next week’s promo traffic” from a snippet alone.

Worse than what AI misses is what humans stop looking for#

Showing AI review first can feel like it helps humans review better. It can also narrow attention.

In a controlled study of 29 professional developers, reviewers who saw automated review first focused on locations the AI flagged. Automation found more low-severity issues but not more high-severity ones. Review time did not shrink.[14]

That does not make AI review useless. It means when AI sets the starting frame, human review can shrink to that frame.

That shift is quiet:

  • Authors may not understand AI-generated code deeply.
  • Reviewers spend time clearing AI comments.
  • Design, data, operations, and customer impact AI never mentions fall off the checklist.
  • Nobody owns the full meaning of the change.

So the key question in the AI era is not “how many bugs did AI catch?”

Is there a person who knows why we are making this change, what changes, and who recovers if it fails?

Peer review built shared ownership, not just bug detection#

Code review is technical and social.

Work on accountability in code quality describes traditional peer review as expanding individual responsibility into collective responsibility. Authors explain decisions to peers; reviewers question and participate. Personal standards, professional diligence, pride in good code, and reputation within the team underpin that accountability.[2]

That work warns LLM-based review can weaken the mutual accountability structure. You owe an explanation to a colleague later; you are not required to explain to an LLM. An LLM is not on call when production breaks and does not decide recovery for live customers.[2]

“AI reviewed it” is not a quality guarantee. With no accountable owner, it can blur responsibility.

That is not because AI is bad—it is because teams added AI without redesigning who owns what.

Professionals protect the company they have now, not only the model they hope for later#

AI will likely improve. The band where humans need not read every implementation line will grow.

Some argue for the end of human code review: agents can pursue defect detection, style, knowledge transfer, and team awareness cheaper and faster; humans re-reading all AI code does not scale.[10]

Take that seriously. Human review is imperfect; AI output volume exceeds old habits.

But sacrificing today’s quality and accountability for a hypothetical fully automated future is different.

METR’s 2025 randomized controlled trial had 16 experienced open-source developers complete 246 real tasks. Work allowed to use AI took 19% longer on average. Participants believed AI made them faster; measurement did not.[5]

That does not mean AI always slows developers—METR does not generalize to every task or team.[5] Other work finds faster initial implementation with AI and no clear penalty when others extend that code.[6]

So the lesson is not “never trust AI.”

Teams that do not separate what AI is already reliable for from what humans must own are taking the wrong risk.

If you are paid to ship, you cannot hollow out today’s quality process on faith in tomorrow’s cheap perfect model. Professional duty is not predicting model curves—it is making current systems explainable, recoverable, and improvable when they fail.

Reviewers in the AI era should not read every line#

The answer is not more diff for humans.

Mechanically verifiable work belongs in code and automation:

  • lint, format, typecheck
  • build and tests
  • vulnerable dependencies, secrets, license checks
  • static analysis
  • changed files and dependency impact exploration
  • candidate rule violations
  • functional decomposition and summary of large diffs

AI can help surface issues humans might otherwise miss.

These still need a human name on the decision:

  • why this change is needed now
  • what existing behavior changes
  • impact on users, data, operations, cost
  • residual risk even when tests pass
  • how you detect failure and roll back
  • who understood the risk and approved

So AI-era PRs need a change accountability brief before—or at least alongside—the code diff:

  1. Why — problem being solved
  2. What changes — add/modify/delete
  3. Blast radius — users, data, APIs, ops, cost
  4. Behavior delta — compatibility implications
  5. Evidence — tests, logs, runs, runbooks used to verify
  6. Risk and rollback — detection and reversal
  7. Approver — who understood and signed off

This is not a cosmetic template. It restores understanding and ownership teams lose when AI increases code volume.

Closing#

AI can write code and AI can review it; that share will grow.

After an incident, “the AI suggested it” does not restore service for customers, teammates, or the business.

Code review in the AI era cannot remain “read every line.” It must become clearer: AI explores, checks, summarizes, and proposes; humans own intent, impact, risk, recovery, and final accountability.

A professional is not someone who blindly distrusts AI-generated code.

They design what to automate and what humans must own so the company keeps sustainable quality even as models improve.

Sources#

[1] https://dl.acm.org/doi/full/10.1145/3793302.3793614 [2] https://arxiv.org/html/2502.15963v1 [4] https://arxiv.org/html/2509.01494v1 [5] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study [6] https://arxiv.org/abs/2507.00788v2 [7] https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/iet-sen.2020.0134 [8] https://pmc.ncbi.nlm.nih.gov/articles/PMC9489594 [10] https://arxiv.org/html/2606.13175v1 [14] https://arxiv.org/html/2411.11401v1