The Second-Opinion Review Methodology

You just had Claude Code implement a rate limiter across four files. The code looks right. The tests pass. But something nags at you. Claude wrote it, Claude tested it, and Claude says it is good.

That's like asking the student who wrote the essay to grade it.

Why This Works

A second-opinion review means running Claude's output past a different AI. A fresh Claude Code session, OpenAI's Codex CLI, whatever can read code and think critically. The key: the reviewer hasn't seen the implementation process. No context about your back-and-forth. No memory of compromises. No attachment to the code.

Claude Code is biased toward its own output. Not maliciously. It just can't see the assumptions it baked in during implementation. A fresh set of eyes (even artificial ones) catches what the original author misses. Same reason human code review works. The reviewer wasn't in the room when the decisions were made, so they question things the author takes for granted.

When to Bother

You don't need a second opinion on every change. That would be slow and pointless.

Features touching 3+ files. Cross-file changes create subtle bugs at the boundaries. A reviewer spots inconsistencies between what one file expects and what another provides.

Security-sensitive code. Auth flows, crypto, input validation, API key handling, permission checks. Never trust a single pass on security code. Ever.

Architecture decisions with 3+ components. Before you commit to a design that will be painful to undo, get another take.

When your gut says something is off. If you have that nagging feeling but can't pinpoint it, that's exactly when a second opinion pays off. Trust the instinct.

Ask the Right Questions

Vague review requests get vague responses.

Bad:

claude "Review the code I just wrote"

Good:

claude "Review the rate limiter implementation in src/middleware/rateLimiter.ts. Look for race conditions under concurrent requests, edge cases in the sliding window logic, and consistency with our existing middleware patterns in src/middleware/."

The good prompt tells the reviewer exactly which files to look at, what failure modes to check, and what patterns to compare against.

Categories worth asking about:

• Logic errors and edge cases. Empty input? Null values? Concurrent access?
• Security vulnerabilities. SQL injection, XSS, improper auth checks, exposed secrets.
• Performance issues. N+1 queries, unnecessary re-renders, missing indexes.
• Consistency with existing patterns. Does the new code follow established conventions?

Always ask for specific file names and line numbers. "Consider error handling" is useless. "Line 47 of rateLimiter.ts doesn't handle the case where Redis is unavailable" is actionable.

The Writer/Reviewer Pattern

Two sessions. Distinct roles.

Session A (Writer) does the implementation. You give it the task, it writes the code, it runs the tests.

Session B (Reviewer) gets the output cold. It reads the files without knowing what Session A was trying to do, beyond what the code itself shows.

Then you bring the feedback back to Session A for fixes.

# Session A — the writer
claude "Implement a rate limiter for our API endpoints using a sliding window algorithm"
 
# Session B — the reviewer (fresh session, no shared context)
claude "Review the rate limiter implementation in src/middleware/rateLimiter.ts.
Look for edge cases, race conditions, and consistency with our existing
middleware patterns. Be specific with file names and line numbers."
 
# Back to Session A — address the feedback
claude "Here is the review feedback: [paste Session B output]. Address these issues."

You can flip this for testing too. Have one session write tests based on requirements, then a different session write the code to pass them. Different biases, more robust results.

Build a Review Skill

Instead of typing review prompts every time, make a skill.

Create .claude/skills/review.md:

---
name: review
description: Independent code review of recent changes
---
 
Review the code changes in the current branch. Focus on:
 
1. Logic errors and edge cases
2. Security vulnerabilities
3. Performance issues
4. Consistency with existing patterns
 
Be specific. Reference file names and line numbers.
Do not summarize what the code does. Only report problems.

Trigger it whenever you hit a review moment. Build specialized variants too. A security-review skill for auth and input validation. A perf-review skill that hunts for N+1 queries and unnecessary allocations. Make them as specific as the reviews you actually need.

Subagents as Reviewers

Claude Code's subagents can act as built-in reviewers without cluttering your main conversation:

claude "Use a subagent to review this code for edge cases"

The subagent reads relevant files, checks for issues, and returns findings. Your main session stays clean.

When the AIs Disagree

Sometimes the writer says the code is fine and the reviewer flags a problem. Sometimes two reviewers disagree with each other.

Don't just pick the answer you like better. That defeats the purpose. Investigate the disagreement. If one AI says a race condition exists and the other says it doesn't, write a test that simulates concurrent access and see what happens. The disagreement is a signal pointing you toward the exact spot that deserves your human attention.

The goal isn't consensus. It's surfacing risks that a single pass would miss.

Try It

Pick something you recently implemented with Claude Code. Open a fresh terminal. New session.

claude "Review the implementation in src/features/myFeature.ts and
src/features/myFeature.test.ts. Look for:
1. Edge cases that the tests do not cover
2. Error handling gaps
3. Any assumptions that could break with unexpected input
Reference specific line numbers."

Compare what the reviewer finds against what you expected. It'll catch at least one thing you overlooked. Probably more.

Worth Remembering

A fresh AI session reviewing code catches assumptions the original author baked in. Trigger reviews for 3+ file changes, security code, architecture decisions, or whenever your gut is uneasy.

Specific prompts produce specific results. Tell the reviewer which files, which failure modes, and demand line numbers. Build reusable review skills so invoking a review takes seconds.

When AIs disagree, that's useful. The disagreement points directly at the spots most likely to contain real problems.