Files
ai-workflow-course/modules/10-reviewing-code-you-didnt-write/lab/ai-diff-review-checklist.md
T
claude 389ac2e460 style(no-slop): remove every em-dash + banned words across all modules + capstone
Apply the no-ai-slop standard (now binding in AGENTS.md): the em-dash character is
banned outright (restructured, not blind-replaced), plus the banned word/phrase
list (delve, leverage, robust, seamless, truly, unlock, etc.). 0 em-dashes remain
in modules + capstone; the only "robust" left is the planted M10 ai-change.patch
trap. Module H1 titles use a colon separator.

All deliberate teaching devices preserved; labs compile/parse (py/sh/yaml/json);
no junk. AGENTS.md updated with the hard no-slop rules.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
2026-06-22 23:21:09 -04:00

2.6 KiB

Reviewing an AI-generated diff: working checklist

Keep this open while you read a diff the AI produced. The point is not to re-read the whole file; it's to interrogate the change against the prompt you gave. Work top to bottom.

0. Frame the review

  • What did I actually ask for? Write the request in one sentence. Every changed line should trace back to it.
  • Read the diff, not the summary. Ignore the AI's account of what it did; the diff is the only ground truth. (git diff main..<branch>)

1. Scope: did it change only what was asked?

  • Every hunk maps to the request. Anything outside it is scope creep until proven otherwise.
  • No unrelated files touched (formatting churn, import reshuffles, version bumps).
  • No "while I was here" refactors of code the request never mentioned.

2. Deletions: what did it take away?

  • Read every - line. Deletions are higher-risk than additions and skim right past you.
  • Edge-case handling still there? Bounds checks, None/empty guards, try/except, validation, error returns; confirm none were dropped or weakened.
  • An error that used to be raised/logged isn't now silently swallowed (except: pass).

3. Plausibility: does it only look right?

  • Invented APIs. Every function, method, kwarg, attribute, import, env var, CLI flag, config key, and endpoint actually exists. Confidence is not evidence; verify the unfamiliar ones against real docs/source.
  • Invented behavior. It isn't relying on a flag/option that doesn't do what the name suggests (e.g. assuming list.pop takes a default like dict.pop).
  • Off-by-one / boundary logic. Indexing, ranges, slicing, loop bounds, 0- vs 1-based.
  • Inverted or weakened conditions. if not x vs if x, < vs <=, and vs or, a filter quietly dropped from a comprehension.

4. Behavior change: would the happy path hide it?

  • Does any existing command/function behave differently now? Trace one real call through.
  • Run the failure case, not the success case. The trap usually survives the happy path. Feed it bad input, an empty list, a missing file, a duplicate.
  • Return values / exit codes unchanged where callers depend on them.

5. Decide

  • I can explain, in my own words, what every hunk does and why it's correct.
  • If I can't, I request changes; the burden of proof is on the diff, not on me.

Rule of thumb: a diff is guilty until proven correct. "It runs" is the weakest possible evidence; "I read every - line and ran the failure case" is the bar.