AI Code Review: What to Automate, What to Keep Human

Roughly 41% of code is now AI-generated and around 90% of developers use AI coding tools. Authoring stopped being the constraint. Review became it — and reviewing machine-written code is a different job from reviewing a colleague's, because the failure modes are different.

How AI-generated code fails differently

• Plausible and wrong. Human mistakes usually look like mistakes. Generated code is idiomatic, well-named and confidently incorrect, which defeats skim-reading.
• Context-blind. It solves the local problem correctly while ignoring a constraint established elsewhere in the system.
• Convention drift. Each generation independently picks reasonable-looking patterns, so a codebase slowly acquires four ways of doing the same thing.
• Silent scope creep. Asked for a fix, it also refactors three adjacent functions — all fine individually, none reviewed as a decision.

What machines review well

Anything with a checkable rule. This is the boring, high-volume half of review, and handing it over frees human attention for the half that needs judgement.

• Style, formatting and naming conventions.
• Known vulnerability patterns and unsafe API usage.
• Missing error handling, unhandled promise rejections, resource leaks.
• Test coverage on changed lines, and tests that assert nothing.
• Complexity and duplication metrics that flag where to look, not what to conclude.

What must stay human

• Is this the right problem? No tool knows the change was scoped wrong.
• Does this fit the system? Architectural coherence is a judgement about direction, and direction is not in the diff.
• What breaks in production? The failure modes that come from knowing this system's history.
• Is the abstraction earned? Machines are poor judges of premature generalisation, because premature generalisations look elegant.
• Should this exist at all? The most valuable review comment remains "delete this".

A workable split

Automated checks run first and must pass before a human looks. Reviewers then spend their attention on intent, fit and consequence, with the machine's findings as context rather than as the review. The anti-pattern is running both in parallel, which produces a diff annotated with fifty low-value comments that the human then has to filter.

Reviewing at a higher altitude

When generation is cheap, line-by-line review of large diffs is poor economics. The higher-leverage habits: review the interface before the implementation, require a stated intent on every change, and reject diffs too large to reason about rather than reviewing them badly.

The comprehension problem underneath

Behind all of this is a simpler issue: teams increasingly maintain code no human wrote and nobody fully understands. Review is where that debt is either paid or deferred. A reviewer who cannot explain what a change does should block it — not because it is wrong, but because unexplained code is unmaintainable regardless of correctness.