Code Reviews Without the War: How to Give and Take Feedback That Lands

The Real Problem: Text Has No Tone

A pull request is the only place at work where colleagues critique your work in writing, in public, and on a permanent record. That's already tense. Then the medium makes it worse: text strips out everything your face and voice would have carried.

A reviewer types "why is this here?" meaning I'm curious, walk me through it. The author reads you did something stupid. Google's own engineering guidelines name this directly — they tell reviewers that text "can convey unintended tone," and they tell authors to assume the reviewer is asking the constructive question, not throwing the insult. Both sides are told the same thing: the words on screen are not the intent behind them.

That gap is the whole problem — and it's exactly the kind of gap AI is good at closing, not by being smarter than you, but by separating what was said from what was meant, in both directions. There's an extra layer in Indian teams: when the reviewer is two levels senior and three time zones away, pushing back feels risky, so people either cave silently and resent it, or get defensive and start a thread war. The techniques below give you the third path.

Part 1 — When You're On the Receiving End

The first comment lands: "You really shouldn't be doing the DB call in a loop. This will fall over in prod." Your fingers are already drafting the defence. Don't respond to the tone. Respond to the technical ask buried inside it. Make AI dig it out.

Every prompt in this article follows the same shape — Role (who the AI should be), Task (what to do), Context (your situation), and an Example when the format matters. That structure is what reliably gets a useful answer instead of a vague one.

Prompt: The Signal Extractor

Role: You are a calm senior engineer who reads past tone to the technical substance.
Task: Ignore the tone of the review comment below completely. In one line, state the specific technical concern being raised. In a second line, state exactly what change would resolve it. If the concern is unclear, give me the single question I should ask to clarify it.
Context: This is a comment on my pull request and my instinct is to get defensive — I want to respond to the substance, not the tone.
Comment: [PASTE]

Nine times out of ten the "attack" was a real, fixable point wearing blunt clothing. Now you can act on it instead of fighting it. When you genuinely disagree, don't argue from instinct — argue from their strongest case, a debate technique called steelmanning.

Prompt: Steelman, Then Reply

Role: You are a fair-minded staff engineer who argues from the other side's strongest case before responding.
Task: First, state the STRONGEST version of the reviewer's argument (steelman it) — assume they know something I might be missing. Then write a short, calm reply that either (a) addresses that strongest version with my reasoning, or (b) proposes we settle it on a quick call.
Context: I disagree with this comment but want to pressure-test whether I'm actually right before I respond. No defensiveness, no apology, keep it technical.
Their comment: [PASTE]
My position: [PASTE — why I think my approach is right]

This pressure-tests whether you're actually right and produces a reply that sounds like a senior engineer, not a cornered one.

Part 2 — When You're Leaving the Comments (The Higher-Leverage Skill)

Giving feedback well is the rarer skill, and it has an actual industry standard you can borrow: Conventional Comments. The idea is dead simple — prefix every comment with a label that states your intent, plus a decoration that states whether it blocks the merge:

<label> [decoration]: <your comment>

The labels you'll use most:

• praise: — call out something genuinely good (do this more than you think).
• nitpick: — trivial, preference-based; the author can ignore it.
• suggestion: — a concrete improvement you're proposing.
• issue: — a real problem that needs fixing.
• question: — you actually want to understand, not challenge.
• thought: — a non-blocking idea for later.

And the decoration that prevents most review friction: (blocking) or (non-blocking). The single biggest reason reviews drag is that the author can't tell which comments actually hold up the merge and which are the reviewer thinking out loud. The label removes the guesswork — and the perceived aggression, because nitpick (non-blocking): literally cannot be read as an attack. You don't have to memorise the format. Make AI apply it:

Prompt: The Conventional Comments Reformatter

Role: You are a respected code reviewer known for feedback people actually want to act on.
Task: Rewrite each of my raw review comments using the Conventional Comments standard — start each with a label (praise, nitpick, suggestion, issue, question, or thought) and add (blocking) or (non-blocking). Keep the technical point exact; soften the framing, never the substance. Frame each issue as the problem + its impact, then a suggested direction or a question.
Context: Assume the author is a competent peer, not a junior who made a dumb mistake.
Example:
  Raw: "don't query the DB in the loop, this is wrong"
  Rewritten: "issue (blocking): this queries the DB once per iteration, so it fires N times per request and spikes latency under load. Suggest batching into one query before the loop."
My raw comments: [PASTE YOUR COMMENTS]

Before and After: 3 Real Examples

Example 1 — A blunt comment becomes a clear, rankable one

Raw:

Reformatted (Conventional Comments):

Example 2 — A defensive reply becomes a confident one

Raw:

Rewritten:

Example 3 — Pushing back on a senior, without the standoff

Raw:

Rewritten:

The 10-Second Cheat Sheet

• Got a comment that stings → run the Signal Extractor, reply to the ask.
• Disagree with a comment → run Steelman, Then Reply.
• Writing comments → run the Reformatter, ship them as Conventional Comments.
• Praise is free leverage → drop one genuine praise: per review; it makes every issue: land softer.

Which AI Does This Best?

• Claude writes the most natural, least corporate tone and won't dilute your technical point into mush — strongest pick for review wording.
• ChatGPT is solid but tends toward the "compliment sandwich"; tell it to skip the fake warmth.
• Gemini is fine if it's already in your stack — just give it the explicit label format above or it stays generic.

When NOT to Reach For AI

• A genuine architecture disagreement. Polished text won't resolve a real design conflict — get on a 10-minute call. AI fixes tone, not substance.
• A security or data-loss risk. Some comments should be blunt and (blocking). Don't let AI soften "this leaks customer data" into a gentle suggestion.
• A pattern, not a one-off. If the same person keeps shipping risky code, that's a direct conversation (or one with your reporting manager) — not a wording exercise.

Why I Wrote This

I'll be straight with you: I'm not an engineer shipping code every day — I'm an automation consultant. This section of the site exists for one reason: a software engineer I trust told me, plainly, that there was nothing here for people like him.

So I didn't invent any of this. I built it from how the best engineering teams actually work — the Conventional Comments standard that keeps reviews civil, and Google's own engineering guidelines on giving and taking feedback — and I tested every prompt above myself before putting it here.

What I do know, from a different chair, is how much damage one badly-worded line can do, and how a small reframe can save a working relationship. If this saves you a single tense PR thread, or one reply you'd have regretted sending, it did its job.