Code Review — Asking Claude to Critique Your Work

Series: Claude Learning Journey · Core Workflows

Code review is most useful when it challenges your assumptions. You wrote the code, you know what it is supposed to do, and you are probably too close to see the edges where it breaks down. Claude does not have your context, which means it reads what is actually there rather than what you meant to write. That is precisely what makes it useful as a reviewer.

Reading code you have written

The basic pattern is simple: give Claude the code, ask it to review.

You: "Review this function and point out any bugs or issues:
[read file contents]

Focus on: correctness, edge cases, and whether the error handling is appropriate."

Claude will read the code, spot patterns that look suspicious, and flag things like:

• Null pointer access that would only surface with specific inputs
• Inconsistent error handling
• Assumptions about data that may not hold in production
• Race conditions or state management issues

The fact that Claude has no investment in the code being correct means it will tell you when something is wrong without the social pressure of a human reviewer who does not want to seem unhelpful.

Asking specific question

Vague review requests produce vague output. Specific questions produce focused analysis.

Vague: “What do you think of this code?”

Specific: “This function authenticates a user and returns a session token. The token is stored in a cookie. Does the implementation correctly handle token expiry, and are there any scenarios where an attacker could forge a token?”

Specific questions get specific answers. The second version tells Claude what to evaluate and what threat model to consider.

What Claude is good at spotting

Claude is particularly good at catching:

Logic errors: Loops that terminate one iteration too early, conditions that miss edge cases, boolean logic that does not do what you intended.

Security issues: SQL injection vectors, missing authentication checks, insecure direct object references, secrets in code that should be in environment variables.

Performance problems: N+1 queries, loading too much data into memory, missing indexes on frequently queried fields, unnecessary nested loops.

Code smell: Functions that are too long, too many responsibilities, unclear naming, deeply nested conditionals that are hard to follow.

What Claude is less good at

Claude cannot:

• Run the code and observe actual behaviour
• Know your specific production environment
• Understand business context that would change whether something is correct
• Tell you if the approach itself is wrong for the problem

Treat Claude as a thorough but context-blind reviewer. It catches things humans miss because it reads every line without the attention shortcuts that experienced developers develop.

Reviewing pull requests

Claude can review a git diff directly, which makes it useful for PR review:

git diff main..feature-branch | claude -p "Review this diff. Flag any bugs, security issues, or cases where the changes introduce unexpected behaviour. Be specific about line numbers."

This gives you a first-pass review before involving the rest of your team. It catches the obvious stuff so human reviewers can focus on architecture and design decisions.

Setting review scope

Be explicit about the scope of the review you want:

You: "This is a database migration. Focus only on whether the migration is reversible and whether it handles existing data correctly. Do not comment on code style."

Claude will respect scope constraints. If you only want security feedback, say so. If you want everything, say that too.

Try it yourself

Take a piece of code you wrote recently and ask Claude to review it with a specific question. Pick something small — a function, a class, a module. Ask about one specific concern (correctness, security, performance). Compare the response to what you expected. If Claude found something you missed, that is the value proposition right there.

What’s Next

Debugging is where code review skills directly apply. The next post covers using Claude to trace errors — from the first symptom to the root cause.

Part of the Claude Learning Journey series · Next: Debugging with Claude: From Error to Fix