AI Code Review Skill
Human code fails where the human got tired or didn't know; AI code fails where plausibility diverged from correctness — and it fails fluently, with confident naming, clean formatting, and tests that pass without testing anything. Reviewing it with human-code instincts ("looks careful, probably is careful") is how the new bug class ships. This skill reviews for the failure modes that are characteristically AI.
What This Skill Produces
- A review of the change organised by AI-characteristic risk, each finding with file/line and severity
- Verification steps the reviewer must actually run (not read) per risk class
- A team checklist for AI-authored PRs, calibrated to this codebase
Required Inputs
Ask for (if not already provided):
- The diff or PR (or the files changed)
- Provenance honestly: fully agent-written, human-piloted, or mixed — and whether the author reviewed it themselves before requesting review
- The codebase context: existing conventions/utilities the AI may not have known, and what the change claims to do
- Test infrastructure: what CI actually runs (the AI may have written tests CI never executes)
The AI-Characteristic Failure Modes
Review in this order — most damaging first:
- Plausible-but-wrong logic. The code reads correctly and does something subtly different: inverted edge conditions, off-by-one on boundaries the prompt never mentioned, the right algorithm for a slightly different problem. Verification: trace 2-3 concrete inputs through the changed logic by hand — the fluency of the code is not evidence; it's the camouflage.
- Hallucinated or misused APIs. Methods that don't exist in this version, config keys from a different library, plausible-sounding parameters silently ignored. Verification: for every external API call touched, check the actual dependency version's docs — not memory, not the AI's comment.
- Tests that test nothing. Asserting mocks return what they were mocked to return; happy-path-only suites with confident names; tests copied from the implementation (tautological). Verification: mentally break the implementation — would any test fail? If not, the coverage number is decoration.
- Reinvention and drift. A new utility duplicating an existing one (the AI didn't know your
utils/), a new pattern where the codebase has a convention, a second source of truth. Verification: for each new helper/abstraction, grep for the existing equivalent. - Over-engineering as default. Speculative generality: interfaces with one implementer, config for things that never vary, error hierarchies for a script. AI pads scope because scope was ambiguous. Finding, not felony — but it's yours to maintain forever.
- Dead scaffolding. Unused imports/variables, TODO stubs presented as done, commented-out alternatives, leftover debug logging. Cheap to catch, and its presence predicts the deeper failures — a diff with scaffolding wasn't self-reviewed.
- Silent security shortcuts. Broad exception swallowing, disabled TLS verification "for now", string-built SQL, secrets in examples that became code, permissive CORS. AI reproduces the internet's average security posture unless told otherwise. Verification: run the security linters even for a "trivial" change; the shortcut is rarely where the feature is.
Output Format
AI Code Review: [PR/change] — provenance: [stated]
Verdict: ✅ approve / 🟡 approve with required fixes / 🔴 request changes — [one line]
Findings
| # | Failure mode | Location | Severity | Finding + fix |
|---|
Verified by running: [the hand-traces, API checks, and break-the-test exercises actually performed — a review that only read the diff says so]
Debt accepted knowingly: [over-engineering/style items merged anyway, listed so they're chosen]
Team checklist for AI-authored PRs: [the 7 modes as a calibrated checklist + the house rule: AI-assisted PRs declare provenance, and the author self-reviews before requesting review]
Quality Checks
- At least one concrete input was hand-traced through the changed logic
- Every touched external API was verified against the actual dependency version
- Each test was assessed by "what breakage would this catch?"
- New helpers were grepped against existing utilities
- The verdict distinguishes required fixes from accepted debt
Anti-Patterns
- Do not extend human-code trust heuristics ("clean and well-named, so probably correct") — fluency is the failure mode's costume
- Do not approve on green CI without checking whether the tests can fail
- Do not review the description instead of the diff — AI PR descriptions are confident summaries of intent, not of behaviour
- Do not reject code for being AI-written — review the code; provenance calibrates scrutiny, not verdicts
- Do not skip security linting because the change is small — the shortcut hides in the periphery
- Do not accept "the agent tested it" as verification — demand the evidence in the PR
