ai-code-review

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

| # | 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