Have you ever read code you just wrote, and somehow felt nothing was wrong with it? I've been shipping iOS and Android apps as a solo developer since 2014, and I've lost count of how many times I've nodded at code I wrote at midnight, only to find a serious oversight a week later.
Most people first try Claude Code as a reviewer with the obvious approach — "please review this code." That returns useful feedback, but in my experience, the comments are mysteriously gentle when the author of the code is the one asking. Maybe the model reads the room, or maybe my own phrasing nudges it that way. Either way, asking politely doesn't produce a tough review.
This piece walks through how I summon Claude Code as a mid-career engineer who has just walked into the codebase to read someone else's work, complete with the prompt template I actually use. The technique itself is simple, but the depth of the feedback you get back is on a completely different level.
Why "your own code" produces softer feedback
In a way, this mirrors human review culture. The way you review a teammate's code differs from the way you review code from an unfamiliar contractor team. With the latter, you naturally read with a more skeptical eye, willing to question premises.
When you hand Claude Code a snippet with no context, the model responds as if the author is sitting next to you, watching the conversation. Important but ego-bruising observations get pushed to the back, or softened in language. The AI isn't being lazy — it's just that the default mode of dialogue leans that way.
If you reframe the review as "context where the author's feelings don't need to be considered," the priorities of the feedback shift. The single most effective change I've found is to explicitly mark the code as someone else's.
Base template — pretend a mid-level engineer wrote it
Here's the skeleton I drop in at the start of a Claude Code session. I tweak it per project, but the bones stay the same.
You are a senior engineer who recently joined this team.
The code below was written six months ago by a mid-level engineer
who has since rotated off the project. You cannot ask them
about commit context.
Before this passes the next review gate, read it strictly through
the following lenses:
- Design landmines that detonate later (naming, responsibility, data flow)
- Failure modes around exceptions, boundary conditions, concurrency
- Traps that tests won't catch but production absolutely will
I do not need "looks fine" or "generally OK" verdicts.
Enumerate every concern with priority labels.Three things are doing work in this prompt. First, it withholds the fact that I wrote the code. Second, it removes the author from reach. Third, it explicitly closes the "looks fine" escape route.
That last point matters more than it looks. Without it, Claude Code instinctively balances "things I liked" against "things I'd push back on." In a review setting, you only need the latter. Cut the first half cleanly.
Split the angles — don't ask for everything at once
On top of the template, I split the review across multiple turns rather than packing everything into one request.
I usually slice into five angles. For security, I narrow the lens to input validation, authorization, and secret handling. Asking "if you wanted to attack a system using this code, where would you start?" pulls feedback in attacker voice.
For naming and readability, I ask whether the variables, functions, and comments make sense to "the version of me six months from now." Prompting "predict what this function does from its name, then check whether the body matches" surfaces the gap between intent and implementation.
For responsibility splits, I check whether one file or function is doing too many jobs. My favorite version is "if you had to split this file in two, where would the cut go?" Forcing a concrete proposal makes the seams visible.
For exceptions and boundaries, I aggressively explore the unhappy paths. "List ten inputs that would crash this code" surfaces cases I never thought of.
For testability, I ask which parts make unit testing painful. "Where would writing a unit test for this function get stuck?" pulls out the tightly coupled, side-effect-heavy parts.
Sending all five at once dilutes each one. Splitting into separate turns is, counterintuitively, faster and produces deeper notes.
A real save from my indie work
A specific example: I had Claude Code review the billing-related code recently, framed as "someone else's code." It strongly flagged that I was returning a Stripe session ID directly to the client.
Right after writing it, I had been satisfied — it worked, the tests passed. A plain "please review" produced a soft mention along the lines of "be careful with session ID handling." But the moment I switched to "read this from an attacker's perspective," the feedback escalated to "this lets a third party intercept other customers' payment sessions; I strongly recommend immediate remediation."
The fix was a few lines. Had it shipped, it would have been the kind of incident that destroys trust. One line of phrasing changed the outcome that much.
Anti-patterns — phrasings that dull the review
A few requests have actively backfired for me.
"Please be gentle." If you ask for gentleness, you get gentleness. That trades information density for tone. I now keep emotional support tasks fully separate from review tasks.
"Encourage me while pointing out issues" walks into the same trap. Words spent on encouragement come straight out of the feedback budget.
"Keep it short" is sneakier. When you compress, the truly important findings get cut and the surface-level ones survive. If I want a short review, I let it run long first, then ask "summarize the top three by priority." Two passes preserve the depth and still leave a short read.
"Don't compare against examples, just use your own experience." I deliberately avoid this. Claude Code's strength is in surfacing common pitfalls drawn from a vast corpus, and forbidding comparisons silences that strength.
Hand the review to your future self
I never let a review end at "fixed and forgotten." The same class of mistake will return six months later.
I keep a _review_log/ folder at the project root, where I write down strong findings and how I addressed them, in plain markdown. Next time I open Claude Code on this project, I include the latest entries in the context with a note like, "I've been called out on these patterns before, please check before writing new code."
Since I started doing this, repeat findings of the same flavor have visibly dropped. Treating reviews as build-up rather than throwaway turns Claude Code from a one-off reviewer into a personal reviewer that knows your habits.
Switch the reviewer — multiple personas, same code
One advanced move: don't restrict the persona to "mid-level engineer."
Read it through the eyes of a brand-new junior engineer, and you'll surface missing documentation and unspoken assumptions. As a tech lead, architectural inconsistencies appear. As a security engineer, the attacker-perspective notes proliferate. As a CTO, the appropriateness of the underlying tech choices comes into question.
Reading the same code through several lenses in sequence yields a density of feedback that you simply cannot reach alone. Before any release I care about, I run at least three personas through the code.
Closing — the smallest first step
If you want to try this tomorrow, take the code you're writing now and hand it to Claude Code framed as "someone else's." Just changing the first three lines of your prompt is enough to make the feedback noticeably sharper.
Then take one strong finding, drop it in your _review_log/ equivalent, and include it in the context of your next session. Repeat that exchange three or four times, and the conversation slowly transforms — from a one-shot review into a quality gate that knows you personally.