How to Actually Review a Claude Code Diff (Without Trusting It)
You hit Accept. You scan the green. You move on. That's how the silent bugs get in. Here's a faster way to review that catches the real problems.
The default review flow for Claude Code output is: read the summary, skim the green lines, click Accept. This feels fast. It is fast. It's also how every silent deletion bug I've ever shipped got in.
The Order Matters
Most people read diffs in file order, top to bottom, green and red mixed together. This is the wrong order. Your brain naturally latches onto additions because they look interesting, and skims deletions because "well, it's gone, whatever."
Here's the order I use now, drilled in after getting burned too many times:
- Read every red line first. Ignore the green. For each red line, ask: "Why did this exist? Is it safe to delete?" If you can't answer, stop and figure it out.
- Then read the greens in context. Not as standalone additions — as replacements. What did this replace? Is the replacement actually equivalent, or is it subtly different?
- Check the file tree. Are there files that should have been touched but weren't? A feature rename should affect 5+ files. If Claude only touched 2, you're going to have a bad time.
The "What Was Here Before?" Test
For every significant red block, spend 10 seconds asking what the deleted code was for. If it was error handling, is the new code still handling that error somewhere? If it was a special case for a specific user type, is that case still handled? If it was logging, did logging move somewhere else or just vanish?
I keep a mental list of things that should never silently disappear:
- Try/catch blocks (where did the error go?)
- Auth checks (did the route lose its guard?)
- Input validation (can untrusted data now reach the core logic?)
- Rate limiting / retry logic (will we hammer the third-party API now?)
- Comments explaining non-obvious decisions (the decision is still non-obvious, we just lost the why)
The Search Test
After a larger refactor, I do one more thing: grep for the old function/variable/type name across the entire repo. If anything still references it, the refactor is half-done and the next deploy will break. This is also great for catching copy-paste drift where Claude renamed one file but left a near-duplicate elsewhere using the old name.
When to Skip the Full Review
Not every change needs this level of scrutiny. For a new file being added, the deletion count is zero — red-first doesn't apply. For a one-line typo fix, obviously skip it. The full flow is for anything that modifies existing working code: refactors, feature changes, "just cleaning this up." Those are the ones that hide silent deletions.
The Vibe Code Fix checklist has a dedicated item for this under Hallucinations — "Nothing that was working before is quietly gone." It sounds obvious written down. It's the item that burns the most people anyway.