Reading the diff before accepting

Of all the habits in this curriculum, this is the one that separates careful Claude Code users from people who eventually ship a real bug, lose a real file, or break a real deploy: always read the diff before accepting. It takes ten seconds. It catches ninety percent of the problems that would otherwise become bugs.

What a diff is

A diff is a side-by-side comparison of two versions of a file — usually "before" and "after." Claude Code shows you a diff every time it's about to edit a file:

  src/components/Button.tsx
   1: import React from "react";
   2:
   3: export function Button({ label, onClick }) {
-  4:   return <button onClick={onClick}>{label}</button>;
+  4:   return (
+  5:     <button
+  6:       onClick={onClick}
+  7:       className="px-4 py-2 rounded bg-black text-white"
+  8:     >
+  9:       {label}
+ 10:     </button>
+ 11:   );
  12: }

Lines starting with - are being removed. Lines starting with +are being added. Unchanged lines are shown for context but not modified. That's the whole format.

What to actually look at

You don't need to read every line word by word. The ten-second scan is more useful:

1. The file path. Is this the file you expected to be changed? If you asked for a button tweak and the diff is touching a database query, stop.
2. The number of changes. A small task should have a small diff. A 200-line diff for a one-line change is a red flag, even if the changes look reasonable.
3. The deletions. The - lines are where surprises hide. Code being removed is the easiest thing to miss and the most likely thing to regret.
4. Anything that looks like config. Environment variable handling, imports, build settings. These rarely need to change for a feature task; if they did, ask why.
5. Anything that looks like a workaround. Comments like // TODO, magic numbers, try/catchblocks that swallow errors. Each one is a place to ask "is this actually right?"

The deletion problem

The single most common Claude Code mistake on big tasks: deleting something you needed. Maybe it looked unused. Maybe a function it called got renamed. Maybe Claude was "cleaning up."

Deletions are sometimes correct and sometimes catastrophic, and you can't always tell from inside the diff. The defensive move: every time you see a substantial deletion, pause. Ask Claude what was there and why it's gone. The two minutes you spend asking is dramatically cheaper than the hour you'd spend tracking down the missing feature later.

The accept/revise/reject rhythm

For each diff Claude proposes, you have three choices. Train yourself to use all three:

Accept

The change matches what you asked for. The scope is right. The deletions, if any, are intentional. Approve and move on.

Revise

The change is most of what you wanted, but something is off. Don't accept; tell Claude what to adjust. Specifically. "Looks good, but don't change the function signature; keep the old parameter name." Claude updates the diff. You look again.

Reject

The diff is going in the wrong direction. Start over. Tell Claude what was wrong and how you want to approach it differently. Don't accept a wrong change "just to keep moving" — you'll pay for it later.

Sanity-checking refactors

Refactors are diffs from hell to read. A simple refactor can touch dozens of files and hundreds of lines. The scanning strategy:

1. Read the goal first, not the diff.What was the refactor supposed to accomplish? If you can't state it in one sentence, you don't know enough to review.
2. Pick a sample.If 30 files were modified in the same way, read three of them carefully. The pattern is either right or wrong; reading all 30 doesn't add much.
3. Look for anomalies.Files that were modified differently from the rest. Files that probably shouldn't have been modified at all. These are the failure modes.
4. Run the tests. If the project has them. A refactor that passes the test suite is much more likely to be correct.

The git safety net

Even with great diff hygiene, mistakes happen. The reason committing often matters: every commit is a checkpoint you can roll back to. If you accept a diff, run the code, realise it's wrong, and want to undo — git reset --hard HEAD wipes uncommitted changes. git revertcreates an undo commit if the changes are already committed. Neither is scary once you've done it a few times.

The combination of careful diff review and frequent commits is the safety net. It's OK to be a little fast on the review if you know you can always rewind.