Stop Using Claude Like a Rubber Duck: Real Code Review Strategies
So you've started throwing your code at Claude or ChatGPT for reviews. Cool. But if you're copy-pasting your entire 200-line function and waiting for generic comments, you're wasting everyone's time—including the AI's.
Here's what actually works.
The Problem With "Can You Review This?"
When you dump code and ask for feedback, you get feedback. Generic feedback. "Good variable naming here" and "Consider extracting this logic" and other things that read like they came from a linter output.
The AI doesn't know what you're worried about. Is the performance sketchy? Does the error handling suck? Are you confused about the logic? It's guessing.
Prompt Like You Mean It
Bad: "Review this code"
Better: "I'm worried this function will timeout on large datasets. Walk me through the time complexity and suggest optimizations."
Bad: "Does this have any bugs?"
Better: "I refactored our auth flow here. Are there edge cases around concurrent requests that would break this?"
Bad: "Is this readable?"
Better: "This logic is getting complex. Can you explain what each section does in plain English, and if any part is confusing, suggest how to rewrite it."
Specificity changes everything. The AI goes from guessing to actually helping.
Use It to Explain, Not Replace Thinking
Here's my workflow:
- Paste code + what I changed
- Ask the AI to walk me through it - "What's the execution flow here? Where could we hit edge cases?"
- Listen to what it says - Sometimes it catches something real. Sometimes it's obviously wrong and that tells me something
- Make my own call - The AI isn't the final authority; it's a second set of eyes
Example:
I changed the payment retry logic from exponential backoff to fixed intervals.
Can you trace through what happens if a request fails 5 times in a row?
Are there any issues with the new approach?
The AI walks you through the logic. You spot problems. You learn something. This is how code review is supposed to work.
Three Patterns That Actually Work
Pattern 1: Diff + Context
Instead of pasting the new function, show the diff:
We changed from:
python
for user in users:
if user.premium:
process(user)
To:
python
premium_users = [u for u in users if u.premium]
for user in premium_users:
process(user)
Question: "Does this change the memory profile? Any performance difference?"
plaintext
The AI can see exactly what changed. Way easier to spot implications.
Pattern 2: "What Could Go Wrong"
This is underrated. Instead of asking for bugs, ask for failure modes:
We're using this to batch process 50,000 records at a time.
What could break? What edge cases should we test?
plaintext
The AI will walk through timeout scenarios, memory issues, partial failures, etc. You now have a checklist.
Pattern 3: The Rubber Stamp
Sometimes you just want confirmation. That's fine:
I think this recursive approach is correct, but I want a fresh pair of eyes.
Walk through the base case and how it handles depth limits?
Quick, specific, useful.
What To Ignore
- Stylistic nitpicks that don't matter
- Suggestions that change behavior without reason
- Generic praise ("This is well-structured!")
- Contradictions with your codebase's actual patterns
You're the expert. The AI is a tool. Use judgment.
The Real Win
The actual benefit of AI code review isn't getting perfect feedback. It's thinking through your own code while someone (or something) listens. Explaining your logic out loud catches gaps. Having it reflected back helps you spot assumptions you didn't know you made.
That's worth the 30 seconds of prompting.
Bonus: Don't Ask AI To Review AI-Written Code
If Claude wrote the code and you're asking Claude to review it, you're in a loop. Works okay for minor tweaks, but for serious review, paste it to ChatGPT, Claude's competitor, or better yet, have a human look at it. Different perspectives catch different things.
Want more on building with AI sustainably? Check out LearnAI Weekly newsletter for practical patterns and tools that actually save time.