Code review is the last line of defence before code becomes everyone’s problem, and the AI era has changed what it needs to be. When a human wrote every line slowly, a reviewer could assume a certain baseline of thought behind the code. When a machine generated it in seconds — fluent, idiomatic, confident — that assumption is gone, and the reviewer’s job shifts from polishing to verifying. This is the third of three on AI-era engineering hygiene, following commits and pull requests.
Review in layers: machines first, humans last
The single biggest efficiency in modern review is to stop wasting human attention on things machines do better.
- Layer 1 — automated gates. Formatters, linters, type-checkers, the test suite, and a SAST security scan should run on every push and catch everything mechanical before a human ever looks. If a person is manually commenting “missing semicolon” or “this variable is unused,” your tooling is broken — fix the pipeline, not the PR. These checks are fast, free, and never get tired.
- Layer 2 — AI-assisted review. AI review bots (and the review features now built into assistants) add a genuinely useful first pass: they summarise the diff, flag likely bugs and smells, and suggest missing tests. Treat this as a helper for the reviewer, never as the approver. It’s a smart linter with opinions, not a substitute for judgment.
- Layer 3 — human review. This is where the irreplaceable work happens — the questions only judgment can answer. Is this actually correct, and does it do what the ticket intended? Is the design sound and maintainable? What breaks at the edges? Are there security implications? And the one no tool asks: should this code exist at all? The machines handle the cheap, mechanical layers so the human can spend their limited, expensive attention here.
The principle: push the mechanical down to the robots, reserve human attention for intent and judgment.
The new failure mode: automation complacency
Here’s the trap the AI era introduces, and it’s a serious one.
Automation complacency is the tendency to defer to a confident machine. “An AI wrote it, so it must be fine.” “The CI passed, so it’s correct.” Both are false, and both lull reviewers into rubber-stamping. Passing tests only prove the tests passed — not that the code does the right thing, handles the edge cases, or is even needed. And AI code is especially dangerous here because it’s fluent and idiomatic: nothing looks off, so the usual reviewer instinct for “this smells wrong” never fires.
AI-generated code fails in specific, recurring ways that a reviewer must actively hunt for:
- Hallucinated APIs — methods, parameters, or libraries that don’t exist, or existed only in an old version.
- Plausible-but-wrong logic — code that solves a slightly different problem than the one asked, or has a subtle off-by-one that reads perfectly.
- Missed edge cases — empty inputs, nulls, concurrency, error paths — the boring branches AI consistently under-weights.
- Security holes — injection, missing authorization, secrets in code — that pass tests and look completely normal.
- Scope creep — a sprawling diff that does far more than was asked, burying the one change you wanted in noise.
The habit that counters this: review AI-generated code harder, not softer. Read it as if a confident junior wrote it — because effectively one did. Verify it solves the actual problem (not a plausible-sounding neighbour of it), hunt the edge cases the model skipped, demand tests you actually understand, and watch for the security issues that hide behind clean-looking code. The reviewer’s job didn’t shrink in the AI era; it moved — from “spot the typo” to “verify the intent.”
Reviewing well, as always
The AI shift sits on top of timeless review habits worth repeating:
- Review the intent, not just the diff. Ask “does this solve the right problem?” before “is this line correct?”
- Be kind and specific. Review the code, not the author; explain why, and distinguish blocking issues from nits (a simple
nit:prefix goes a long way). This matters more when the “author” may have leaned on AI — the goal is better code, not blame. - Be timely. A review that sits for three days blocks a person and rots context. Small PRs (the previous article) make fast review possible.
- Approve means “I understand this and vouch for it.” Never approve code you don’t understand — least of all because a machine wrote it and the checkmark is green. If you can’t vouch for it, that’s a comment, not an approval.
Takeaways
- Review in layers: automated gates (lint/types/tests/SAST) and AI bots catch the mechanical; humans own correctness, intent, design, edge cases, security, and “should this exist.”
- The new risk is automation complacency — “AI wrote it / CI passed, so it’s fine.” Passing tests prove only that the tests passed.
- AI code fails in specific ways: hallucinated APIs, plausible-but-wrong logic, missed edge cases, security holes, scope creep — none of which look off. So review it harder, verify it solves the real problem, and demand tests you understand.
- Approval means you vouch for it. Never rubber-stamp code — human- or AI-written — that you don’t understand.
That’s the series: write atomic, well-explained commits, open small self-reviewed PRs, and review for intent — the discipline that keeps quality high when the code itself is cheap to produce. For the security side of reviewing code, the Security Engineering course goes deeper on what to look for.
