One Claude Code Tip a Day: Review the Diff Before You Believe It

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

A dangerous Claude Code session usually does not look dangerous. The model edits a few files, explains the change confidently, and the app appears to start. The trap is accepting the explanation instead of reviewing the patch. Today’s habit is simple: after Claude Code changes code, make git diff the source of truth.

The Real Failure: A Fix That Looked Done

Imagine a React dashboard where a customer filter stops updating after a route change. You ask Claude Code to fix it. It reads the component, updates a hook dependency, touches a small utility, and says the bug is resolved. The page now works in your manual check.

But when you run git diff, you see something uncomfortable: the patch also changes the default fetch limit from 50 to 500, removes a debounce, and rewrites an error branch that was unrelated to the route bug. None of that was in your request. The code may still pass the happy-path check, but the patch has grown a second, unreviewed feature.

The Workflow: Make Claude Explain the Diff, Not the Intent

After Claude edits, do not ask, “Is it fixed?” Ask it to account for every meaningful line in the diff. In Claude Code, the workflow looks like this:

1. Start with your normal implementation prompt: “Read the filter state flow in src/routes/dashboard and src/components/CustomerFilter. Fix the stale filter after route changes. Keep the change minimal and do not edit unrelated behavior.”

2. Let Claude make the patch.

3. Before accepting anything, run: “!git diff -- src/routes/dashboard src/components src/lib”

4. Then ask: “Review this diff as if you are blocking your own pull request. For each changed hunk, explain why it is necessary for the route-change bug. Mark any change that is unrelated, risky, or should be reverted. Do not edit yet.”

That last sentence matters. If you immediately ask Claude to “clean it up,” it may make a new patch before you understand the first one. Diff review is a read-only checkpoint.

What to Inspect in the Diff

A good Claude Code diff review is not a generic summary. You want it to separate four kinds of changes.

First, look for the direct fix: the line that makes state reset on route change, invalidates the query key, or re-subscribes the component. This should map cleanly to the original bug.

Second, look for collateral edits: formatting, renames, dependency reorderings, or rewritten helpers. Some are harmless, but they increase review cost. Ask Claude why they exist.

Third, look for behavior expansion. In our example, changing the fetch limit and removing debounce are not part of the stale filter bug. They might make the manual check look faster or more complete, but they also change performance and backend load.

Fourth, look for missing verification. If the diff changes state behavior, there should be a test, a reproduction step, or at least a focused command that exercises the failure.

A useful prompt here is: “Classify each hunk as direct fix, supporting test, harmless cleanup, or unrelated behavior change. For unrelated behavior changes, propose the smallest revert.”

Second Pass: Revert the Clever Parts

The best second pass is often smaller, not smarter. Once Claude identifies unnecessary changes, ask for a surgical correction:

“Revert the fetch limit and debounce changes. Keep only the route-change state fix. Add one test that fails before the fix and passes after it. Then show the new git diff.”

Now run the commands yourself through Claude Code’s shell integration:

“!pnpm test -- CustomerFilter”

“!pnpm lint src/components/CustomerFilter.tsx”

“!git diff --stat”

Then ask Claude to interpret the results, not to celebrate them: “Based on the test output and diff stat, what risk remains? Is there any file in this patch that does not need to be changed?”

This mirrors how strong real sessions work: prompt, inspect, find a flaw, correct narrowly, and verify again. The value is not that Claude writes the first patch. The value is that it can help you interrogate the patch before it becomes your problem.

Failure Modes

There are three common ways this habit fails.

The first is reviewing only the final explanation. Claude’s summary is useful, but it is not evidence. The diff is evidence.

The second is allowing a huge diff to stay huge. If the patch touches ten files for a one-file bug, pause and ask for a smaller plan. Sometimes the breadth is justified; often it is momentum.

The third is skipping tests because the manual check worked. For UI bugs, at least capture the reproduction path: route A, select customer, navigate to route B, return, verify the filter state. If there is no automated test, write the manual checklist into the PR notes.

Rule of Thumb

Use Claude Code to write code, but use git diff to decide whether the code deserves to live. A healthy session has two conversations: first with the codebase, then with the patch. If Claude cannot justify a changed line against the original bug, revert it or make it prove the need with a focused test.