How to review Claude Code changes without reading every line

Claude can generate a lot of code fast. The review problem is real: if you spend as much time reviewing as you saved generating, the speed advantage disappears. But not reviewing is how you ship broken things.

Here's how to review efficiently.

Start with the file list, not the diff

Before reading any code, run git diff --name-only HEAD. Look at which files changed. The question isn't "what changed in this file" — it's "should this file have changed at all?"

If you asked Claude to add pagination to an API endpoint and it touched the auth middleware, that's a red flag before you read a single line of the actual diff. Files that shouldn't have changed are the fastest signal that something went sideways.

Read the tests before the implementation

If Claude wrote tests, read those first. Tests describe what the code is supposed to do. If the tests are testing the wrong thing, or testing nothing meaningful, the implementation doesn't matter — the whole thing needs to be redone.

Common patterns to catch: tests that only assert the function ran without error, tests that mock out everything they're supposed to test, tests that pass because they're testing a stub Claude added to make them pass.

Check the edges, not the happy path

Claude's happy path code is usually fine. The problems show up at the edges: what happens when the input is empty, when the API returns an error, when the user has no permissions, when a required field is missing.

For any new function, ask: what happens if each parameter is null or undefined? Is that handled, or does it throw?

The grep for footprint

Run git diff HEAD | grep "^+" | wc -l to see how many lines were added. If you asked for a small change and got 400 new lines, something went wrong. Either Claude solved the wrong problem or it built more than you asked for.

Also grep the diff for things that shouldn't be there: console.log, TODO, hardcoded values, commented-out code. These show up in generated code more than in human-written code.

Ask Claude to explain the risky parts

After Claude finishes, ask: "What parts of this change are most likely to cause problems, and why?" Claude usually knows. If it flags something, read that section carefully. If it says nothing is risky and you have 300 changed lines, be skeptical.

The one thing you always read

Whatever the core logic is — the function that actually does the work — read that in full. Not the scaffolding around it, not the imports, not the error handling boilerplate. The actual logic. That's where wrong answers live.