Chapter 06 · Section IV · 10 min read
Reviewing what Claude changed
The summary at the end of a turn is the assistant's story about what it did. The diff is what actually happened. Learning to review the diff, not just skim the summary, is the single most important discipline in this whole course.
There is one habit that separates people who ship reliable work with Claude Code from people who ship subtle bugs. That habit is verifying, every time, that the work matches the summary. Not most of the time. Not for risky-looking changes. Every time.
Summary vs diff
At the end of a turn, Claude writes a paragraph or two describing what it did. That paragraph is not the work. It is the assistant’s account of the work. Sometimes it overstates. Sometimes it hedges reality with confident language (“I updated the callers…” — but did it update all of them?). Sometimes the summary is exactly right. You cannot tell which without checking.
The check is the diff.
The four-question review
For any non-trivial change, spend 60 seconds on these:
- Are the files it changed the ones I expected? Look at the list of paths. Any surprises? A file you did not name should raise an eyebrow.
- Do the edits inside those files match the intent? Read the diff. Do not skim — read.
- Is anything missing? If the summary says “and updated all call sites”, grep to confirm.
- Does it build / does the test pass? The compiler is a cheap sanity check. Run it.
Any of the four failing is a “keep working”, not a “commit”. Any of them passing without you checking is how bugs sneak past.
When the summary is wrong
Common patterns:
- “Cleaned up unused imports” while quietly leaving one that was actually used somewhere else.
- “Updated all callers” in one directory, missing one in a sibling directory.
- “Preserved existing behaviour” except for a subtle change in error-handling that turns out to matter.
- “Added a test” — the test exists but does not actually test the change; it happens to pass even without the code change.
None of these are malicious. All of them are the natural output of an assistant that wrote a summary before verifying its own work. Your review is the check.
Building the discipline
If reviewing feels tedious at first, that is normal. Two habits make it stick:
- Small diffs. A well-scoped prompt produces a small diff. Small diffs are easy to review. This is one more reason why prompting well pays back so much.
- Reading against the test. Before you look at the diff, look at the test that would have caught the wrong version. If there is no such test, the diff review is doing the work of the test — and you can decide whether it is worth writing one.
Trust, over time
Trust with Claude Code is earned per pattern. Over time you learn: “for renames in this codebase, Claude is very reliable; I review lightly.” “For anything touching the payments module, I review carefully.” That calibration only exists because you kept reviewing at the start.
Check your understanding
Quick check
—