AI Code Review Skill

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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