Skip to content

Code Review with Claude

Use Claude as a reviewer — for your own changes, PRs, or dependencies. Prompting for security, performance, and architecture review.

You finish a feature. Code works. Tests pass. You open a PR and wait. Two days later your teammate leaves a comment about a missing null check. Thirty seconds to fix, two days to discover.

Claude Code catches those things in seconds. Not a replacement for human reviewers, but a first pass that clears out the noise.

Four Lenses, Pick the Right One

"Review this code" gets you a generic response. Useless. Tell Claude Code exactly what lens to use.

Code quality. Readability, structure, naming, error handling, edge cases. You want a pedantic senior engineer's eye.

claude "Review src/payments/processor.ts for error handling, input validation, and edge cases. Suggest specific improvements with code examples."

Security. Claude Code's sweet spot. It traces data flow across files without getting bored or distracted. Input validation holes, auth bypasses, data leakage.

claude "Security review the auth module in src/auth/. Check for token leakage, session fixation, CSRF vulnerabilities, and improper access controls."

Performance. Time complexity, memory, N+1 queries, missing indexes. It will find that O(n²) loop hiding inside a seemingly innocent function.

claude "Review src/api/reports.ts for performance issues. Focus on database query patterns, memory usage, and time complexity of any loops."

Architecture. The big picture. Separation of concerns, coupling, whether the code follows patterns established elsewhere.

claude "Review the shopping cart feature in src/features/cart/. Assess separation of concerns, coupling to other modules, and consistency with patterns used in src/features/orders/."

You don't need all four every time. A CSS refactor doesn't need a security review. A new auth endpoint doesn't need an architecture deep dive. Pick the one or two that actually matter for the change.

The Writer/Reviewer Split

Counterintuitive but important: if Claude Code wrote the code, don't ask the same session to review it.

It's biased toward its own output. Glosses over issues because it "knows" why it made those choices. Same as a human who just wrote something and proofreads it immediately. They miss everything.

Fresh session. No memory of the writing process. No attachment. No sunk cost. It reads the code cold.

# Session 1: Write the feature
claude "Implement the rate limiter middleware in src/middleware/rate-limit.ts"
 
# Close the session, then start fresh
claude "Review src/middleware/rate-limit.ts for security issues, race conditions, and edge cases around concurrent requests."

I keep coming back to this pattern. The reviewing session consistently catches things the writing session is blind to.

PRs and Dependencies

Claude Code reviews more than just your code. Point it at a PR diff or a third-party dependency.

For PRs, be specific about what feedback you want:

claude "Here are the files changed in this PR: src/api/users.ts, src/models/user.ts, src/middleware/auth.ts. Review for security issues and backward compatibility. Flag any breaking changes to the API contract."

For dependencies, this is incredibly useful when adding a new npm package or bumping a major version:

claude "Review the source code of the package in node_modules/some-auth-lib/. Check for any suspicious network calls, data collection, or insecure practices."

Try it now. Pick a file you changed recently. New session. Focused review prompt. One lens. Compare what Claude Code finds to what you would've caught yourself. There's always at least one thing you missed.

Making It a Habit

Don't treat review as a special event. Make it reflexive.

Put a review checklist in your CLAUDE.md:

## Pre-PR Review Checklist
When I ask for a "pre-pr review", check all staged/changed files for:
1. Missing error handling and edge cases
2. Security issues (input validation, auth, data exposure)
3. Performance problems (N+1 queries, unnecessary loops, missing indexes)
4. Inconsistency with existing patterns in the codebase

You can also use subagents for specialized reviews. "Use a subagent to review this code for security vulnerabilities." The subagent runs focused and reports back.

Small detail worth knowing: Claude Code 2.1.20+ shows colored dots next to PRs. Green for approved, yellow for pending, red for changes requested, gray for draft. Useful for tracking status without leaving the terminal.

The goal isn't to skip human review. When Claude Code handles the null checks, missing error handlers, and obvious security holes, your human reviewers spend their time on what actually needs human judgment. Architecture tradeoffs. Business logic correctness. Whether this feature should even exist. That's where their expertise matters.

Bottom Line

  • "Review this code" is a bad prompt. Pick a lens: quality, security, performance, or architecture
  • Writer/reviewer split: write in one session, review in a fresh one. Non-negotiable for important code
  • Audit PR diffs, third-party packages, legacy code. Not just your own stuff
  • CLAUDE.md checklists make review automatic instead of aspirational
  • Claude Code handles mechanical checks so humans focus on judgment calls

Mastering Claude Code

Lesson 39 of 70