Code Review

Claude Code is effective at code review because it can scan entire diffs without fatigue, catch every instance of a pattern (SQL injection, missing null checks), and check consistency across a codebase. Human reviewers remain essential for architectural judgment and domain context. The best approach: use Claude as a first pass, then send to human reviewers.

Three Review Scenarios

1. Reviewing your own code before pushing (self-review)
2. Reviewing Claude’s code — evaluating AI-generated output
3. Reviewing teammates’ PRs — using Claude as a second pair of eyes

Reviewing Your Own Code

Pre-Push Self-Review

Stage your changes, then ask Claude to review them:

git add -p  # stage what you want reviewed

Review the staged changes. Check for:
1. Any security issues (injection, auth bypass, exposed secrets)
2. Missing error handling
3. Edge cases that aren't covered
4. Anything that would break existing behavior

Review a Specific File

Review src/OrderProcessor.ts. This handles order creation, payment
processing, and inventory updates. Focus on:
- Whether the payment -> inventory -> email sequence is correct
- Whether failures at any step are handled properly
- Whether the order state is consistent if something fails halfway

Tip: Giving context about what the code does helps Claude focus. “This handles payments” is much better than “review this file.”

After Claude Makes Changes: Verify with /diff

Whenever Claude edits files, check what it actually changed:

/diff

This is essential. Claude sometimes makes changes you did not ask for — extra refactoring, adding comments, changing imports. /diff lets you catch these before committing.

Reviewing Claude’s Code

When Claude generates code for you, it requires the same scrutiny as any other code. Claude produces plausible code that may have subtle bugs.

What to Check in AI-Generated Code

• Does it match your intent? Claude may have interpreted your requirements differently
• Are edge cases handled? Claude tends to handle the happy path well but may miss boundary conditions
• Did it change things you didn’t ask for? Check the diff for unasked-for refactoring
• Are the tests testing the right things? Tests that pass are not necessarily correct tests
• Does it follow your project’s patterns? Compare with existing code in the same module

The Self-Review Prompt

After Claude builds something, ask it to review its own work:

Review all the changes we've made in this session. Check for:
- Security issues (can the rate limit be bypassed?)
- Edge cases we missed
- Performance concerns with the in-memory store
- Anything that doesn't follow our existing code patterns

Be critical. I'd rather fix things now than in code review.

Claude in “review mode” applies different heuristics than Claude in “build mode.” It finds issues it missed during implementation.

Reviewing PRs and Diffs

Review a Git Diff

Review the changes in this diff for bugs and security issues:
git diff main...feature-branch

Review Recent Commits

What changed in the last 3 commits? Review each change for correctness
and flag anything that looks risky.

GitHub PR Review (with gh CLI)

# Get the diff for a PR
gh pr diff 123

Then ask Claude to review:

Review the output of `gh pr diff 123` for issues. Focus on the
TypeScript changes -- ignore the package-lock.json changes.

Complete Walkthrough: Reviewing a Large PR

Scenario: A teammate submitted a PR with 400+ lines of changes across 8 files. They added a new “task preferences” feature. You need to review it before the 2pm merge window.

Step 1: Get the Big Picture

You type:

Review the changes between main and feature/user-preferences. Give me a
summary of what changed: which files were modified, what the feature does,
and your initial impressions. Don't go line-by-line yet.

Claude does:

• Runs git diff main..feature/user-preferences --stat for the file list
• Runs git log main..feature/user-preferences --oneline for commit messages
• Summarizes:
  • 8 files changed, 420 insertions, 12 deletions
  • New table user_preferences with JSON storage
  • New endpoints: GET/PUT /api/users/:id/preferences
  • New middleware for preference-based response formatting
  • 3 commits: schema change, API endpoints, integration
• Initial impressions: “The feature is well-scoped. Two concerns to investigate: the new SQL query and the middleware that modifies all responses.”

Why this works: The overview-first approach prevents you from spending 20 minutes reading line-by-line diffs of boilerplate before finding the interesting parts.

Step 2: Deep Dive on the Risky Parts

You type:

The new SQL query in the preferences repository concerns me. Check it for:
1. SQL injection risk -- is user input properly parameterized?
2. N+1 patterns -- does it load preferences for each request individually?
3. Missing indexes for the WHERE clause
4. What happens when a user has no preferences set -- null handling

Claude reports:

1. SQL injection: “All user input is parameterized with ? placeholders. No string concatenation. Looks safe.”
2. N+1: “The middleware loads preferences on every authenticated request. This adds one database query per request. Should use caching or load preferences once during auth.”
3. Indexes: “The WHERE clause filters on user_id but there is no index on user_preferences.user_id. Add one.”
4. Null handling: “If no preferences exist, the query returns undefined. The middleware uses optional chaining so it degrades to defaults. This is correct.”

Step 3: Check for Missing Tests

You type:

Does this PR include tests? If so, are they sufficient? If not, what
test cases should exist before we merge?

Claude finds one test file with 3 tests covering the happy path. Missing tests for:

• Invalid JSON in the preference body
• Attempting to update another user’s preferences (authorization)
• The default behavior when no preferences exist
• The index migration

Step 4: Write the Review Comments

You type:

Draft review comments for this PR. For each issue, include:
- The file and line number
- What the problem is
- A suggested fix (code if applicable)

Separate into "must fix before merge" and "nice to have for a follow-up."

Claude produces:

Must fix:

1. src/database.ts line 87 — Add index on user_preferences.user_id
2. src/middleware/preferences.ts line 14 — Cache preferences in req.user during auth instead of querying on every request
3. src/routes/users.ts line 142 — Add authorization check — users should only update their own preferences unless admin

Nice to have:

1. Add JSON schema validation for the preferences body
2. Add the 3 missing test cases
3. The preference middleware could be lazy-loaded

Focused Review Strategies

Security-Focused Review

Review this code as if you're a security auditor. Check for:
- SQL injection (string concatenation in queries)
- XSS (unescaped user input in HTML)
- Authentication bypass (missing auth checks)
- Hardcoded credentials or secrets
- Sensitive data in logs
- Missing input validation on API endpoints

When to use: Before merging anything that touches auth, payment, or user data.

Performance-Focused Review

Review this code for performance problems:
- N+1 queries (database calls inside loops)
- Missing database indexes for new query patterns
- Unnecessary re-renders in React components
- Blocking operations in async code paths
- Unbounded queries without pagination
- Large objects being serialized unnecessarily

When to use: Before merging database schema changes, API endpoints, or frontend components that render lists.

”What Would Break?” Review

Read this diff. For each change, tell me: what existing behavior
could this break? What inputs would trigger the break?

This is the most valuable review question. It forces Claude to think about the blast radius of each change.

Test Adequacy Review

Read the implementation changes and the test changes in this diff.
Are the tests sufficient? What scenarios are tested and what's missing?
Be specific -- give me exact test cases that should be added.

Reviewing Large Diffs

When a PR is too large to review at once, break it into logical groups:

This PR has 47 files changed. Read the PR description first:
gh pr view 312 --json body

Then review the changes in groups:
1. First, review only the model/schema changes
2. Then the service layer changes
3. Then the API layer changes
4. Then the test changes

For each group, tell me if the changes look correct before
moving to the next group.

Reviewing 47 files at once overwhelms both humans and AI. Breaking into layers lets Claude focus its context on related changes.

Anti-Pattern Scanning

Use Claude to scan for common code smells across a module:

Read the files in src/services/. Check for these anti-patterns:
- God classes (classes doing too many things)
- Circular dependencies between services
- Hardcoded configuration that should be in environment variables
- Catch blocks that swallow exceptions silently
- TODO comments older than 6 months (check git blame)
- Dead code (functions that are never called)

List anything you find with the file and line number.

A focused anti-pattern checklist produces more actionable results than a vague “review this code.”

Review Prompt Techniques

Be Specific About the Concern

Provide Business Context

This code processes credit card refunds. Review it knowing that:
- A bug here means real money is lost
- We've had issues with duplicate refunds before
- The payment gateway has a 30-second timeout

Context changes what Claude flags. Without it, Claude gives generic advice. With it, Claude focuses on double-processing, idempotency, and timeout handling.

Ask for Severity Levels

Categorize each issue as:
- CRITICAL: Must fix before merge (security, data loss, crashes)
- IMPORTANT: Should fix (logic bugs, missing validation)
- MINOR: Nice to fix (style, naming, minor optimization)

This prevents critical issues from being buried in style nits.

Responding to Review Findings

When Claude is Right

Fix the issue:

Fix the SQL injection issues you found in lines 42, 67, and 103.
Use parameterized queries.

When Claude is Wrong

Push back:

That's not actually an issue because the input is already sanitized
by the middleware on line 15. Skip that one and continue the review.

When You’re Not Sure

Ask for proof:

You flagged the discount calculation on line 89 as an off-by-one
error. Walk me through the math. What input would trigger the wrong
result?

If Claude cannot produce a concrete failing input, it is likely a false positive.

Multi-Agent PR Review (Claude Code Review)

For Teams and Enterprise subscriptions, Claude Code Review is a managed service that automatically reviews GitHub pull requests using a fleet of specialized agents.

How It Works

When a review is triggered, specialized agents analyze your code changes in parallel:

• Logic errors and broken edge cases
• Security vulnerabilities
• Subtle regressions
• Breaking changes

A verification step filters out false positives before posting findings.

Severity Levels

What It Checks

By default, Claude Code Review focuses on correctness — bugs that would break production. It does NOT flag formatting, missing test coverage, or style issues unless you configure it to via REVIEW.md.

Setup

1. Go to claude.ai/admin-settings/claude-code and find the Code Review section
2. Install the Claude GitHub App with required permissions (contents, issues, pull requests)
3. Select which repositories to enable
4. Set the review trigger for each repo

Trigger Modes

Customization with REVIEW.md

Create a REVIEW.md file at the repository root to define team-specific review rules:

## Always Check
- New API endpoints must have integration tests
- Database migrations must be backward-compatible with the previous release
- All user input must be sanitized before database queries

## Style
- Prefer match statements over chained isinstance checks
- Use structured logging, not f-strings
- Error responses must include a request_id field

## Skip
- Ignore generated files under src/gen/
- Ignore formatting-only changes in *.lock files
- Do not flag TODOs that reference a ticket number

Your existing CLAUDE.md files also apply to reviews. If a PR violates a rule in CLAUDE.md, it is flagged as a nit-level finding.

Self-Hosted Alternatives

If you cannot use the managed service, review can be self-hosted:

• GitHub Actions: Run Claude in your own workflows with claude -p "review this diff"
• GitLab CI/CD: Self-hosted integration for GitLab pipelines
• Local review: Pre-push reviews on your machine

Best Practices for Automated Review

1. Start with Manual mode for high-traffic repos — opt specific PRs into review
2. Write a REVIEW.md encoding your team’s conventions and focus areas
3. Use severity levels to triage — fix Red issues before merge, Yellow at your discretion
4. Monitor costs for the first month to establish baselines ($15-$25 per review on average)
5. Treat it as a first pass — human review still matters for architecture and design

Tips for Different Review Contexts

Reviewing Your Own Work (Pre-Push)

• Focus on: edge cases, error handling, security
• Use staged changes for targeted review
• Fix issues before pushing — saves a review round-trip

Reviewing Teammates’ PRs

• Focus on: correctness, design consistency, test adequacy
• Provide business context for more relevant feedback
• Use severity levels so the author knows what is critical

Reviewing Legacy Code (Before Modifying)

• Focus on: understanding behavior, finding hidden assumptions
• Ask Claude to explain the code before suggesting changes
• Ask about test coverage before refactoring

Reviewing After a Production Incident

• Focus on: what caused the incident, are there similar patterns elsewhere
• Ask Claude to search for the same anti-pattern across the codebase
• Review not just the fix but whether the original code should have caught it

Reviewing Code in Unfamiliar Languages

Claude handles all the languages your team uses. You can review Java code even if you primarily write TypeScript:

I'm reviewing a Java PR but I mainly work in TypeScript. Read this
Java code and explain:
1. What does it do in plain English?
2. Are there any bugs or anti-patterns?
3. What would the equivalent TypeScript look like?