Claude Code /diff: Review Every Line Before You Commit

The single most useful habit in AI coding takes thirty seconds: before you keep anything Claude Code wrote, run /diff and actually read it. The command shows you exactly what changed—the lines removed, the lines added, file by file—so you’re approving real code instead of trusting a summary. It’s the difference between owning what ships and just hoping the AI got it right.

What /diff actually shows

When you type /diff in Claude Code, it surfaces the changes from the current session. If you’ve connected Claude Code to your editor (run /ide to link VS Code, Cursor, or Windsurf), the diff opens in the editor’s familiar side-by-side view: your original on one side, the new version on the other, removed lines marked in red and added lines in green. In a plain terminal it prints the same information as text. Either way, the point is the same—you see the change, not a paragraph describing it.

This matters because an AI’s description of its own work and the work itself aren’t always the same thing. “I updated the login function to handle empty passwords” sounds fine; the diff might show it also quietly touched three other files. Reading the diff is how you catch that.

/diff versus git diff: use both

People ask whether /diff replaces git diff. It doesn’t—they answer slightly different questions:

• /diff is scoped to what Claude changed this session. Perfect for reviewing the AI’s contribution specifically, turn by turn.
• git diff (or your editor’s Source Control panel) shows everything different from your last commit, regardless of what made the change.

The honest workflow uses both: /diff while you’re working with Claude to review each step, then a final git diff or a glance at the Source Control panel before you commit, to confirm the whole picture. If you’ve built the habit of committing before you prompt, that final diff is beautifully clean—everything new is the AI’s work, clearly separated from yours.

The 30-second review habit

Here’s the loop worth burning into muscle memory:

1. Prompt Claude Code to make a change.
2. /diff to see what it did.
3. Read it—not every character, but enough to understand the shape of the change and spot anything that touches files you didn’t expect.
4. Commit if it’s right, or tell Claude what to fix if it isn’t.

Four small steps, and they completely change your relationship with AI code. Without the diff, you’re accumulating changes you’ve never looked at—and the day something breaks, you have no idea which step caused it. With it, you always know.

When the diff looks wrong

Reading the diff is also your early-warning system. If /diff shows the AI rewrote a function you asked it to leave alone, or deleted a block you needed, you don’t have to accept it. Tell Claude to revert that part, or press Esc twice (or run /rewind) to roll back to an earlier checkpoint—that restores both the code and the conversation. Just remember checkpoints are a quick local undo, not a substitute for git commits, which are your permanent, reliable save points.

This is exactly the discipline that separates people who get great results from AI coding tools from people who end up with a tangle they can’t explain: the good ones read every diff, and they never let the AI’s confidence stand in for their own review. A reasoning model can write impressive code and still make a wrong assumption about your project—the diff is where you catch it.

Set up Claude Code the right way

If you’re just getting started, our free AI for Coders tool gives you the exact setup for your machine—which assistant fits your work, the install command for your operating system, and a starter rules file so the AI follows your conventions. Pair that with the prompt → /diff → read → commit habit above, and you’ll be reviewing AI-written code like someone who actually owns it.

Keep reading

GuidesClaude Code Checkpoints vs Git: Which Safety Net for AI Coding?Checkpoints undo the AI's edits in two keystrokes; git is your permanent history. They're not rivals—here's what each one covers and why you should use both.GuidesClaude Code Skills vs Subagents vs MCP: Which Do You Actually Need?Confused by skills, subagents and MCP? The one-line rule: a skill changes behaviour, a subagent protects context, MCP adds a capability. Here's how to pick.GuidesWhy Does AI Keep Editing the Wrong File in My Project?When an AI coding assistant changes the wrong file or invents one that doesn't exist, it's lost in your codebase. A bigger context won't fix it—a map will.