What to Do When You Disagree With a Code Review Comment

The Silence-or-Escalate Trap

You get a code review comment you disagree with. The reviewer wants you to restructure the service layer in a way you think is overengineered for the current requirements. You have two instincts: either quietly make the change to avoid conflict and get the PR merged, or push back hard and defend your approach.

Both are wrong. Silent compliance produces code you don't believe in, builds resentment, and robs the reviewer of feedback they need. Defensive escalation turns a design discussion into a territorial dispute and damages working relationships.

There's a third path that's more productive than either — and most developers never learn it because nobody teaches the soft mechanics of code review disagreements.

First: Check Whether You Understand the Comment

Before responding to a review comment you disagree with, make sure you understand it correctly. Not the words — the concern behind it.

"This should be in the service layer, not the controller" might be:

• A stylistic preference for layered architecture
• A concern about testability (business logic in controllers is harder to unit test)
• A concern about code reuse (this logic might be needed from multiple endpoints)
• A concern about separation of concerns (HTTP-specific code shouldn't contain business rules)

These are different concerns with different rebuttals. If you respond to the first one when the reviewer meant the fourth, you'll talk past each other for three exchanges.

Ask:

Could you say more about the concern here? I want to make sure I understand
whether this is a testability issue, a reuse concern, or a separation of
concerns principle — the response would be different for each.

This is not stalling. It's the fastest path to resolution.

Separating Opinion from Correctness

Some review comments are opinions. Others identify actual problems. The distinction matters.

An opinion: "I prefer explicit return types on all functions." A problem: "This function returns None implicitly, but the caller at line 47 dereferences the return value without a None check — this will throw AttributeError in production."

You can disagree with an opinion. You cannot disagree with a problem (you can disagree with the proposed fix, but not with the existence of the problem). Conflating the two is the most common source of review disagreements that go nowhere.

When you're disagreeing, be explicit about what category the comment falls into:

I see this as a style preference rather than a correctness issue. I don't
object to either approach, but I'd prefer to keep the current one for
consistency with the rest of the module. Happy to open a separate ticket
to establish a team-wide convention.

Versus:

I think there's a genuine correctness question here. My reading is that
the None case is actually handled by the fallback on line 34 — does that
address the concern, or am I missing something?

How to Make the Disagreement Productive

State your position clearly and explain the reasoning. Not defensively — just the facts of why you made the choice you made.

I chose to keep this in the controller rather than the service layer because
this validation is specific to the HTTP request format — it checks Content-Type
and validates the multipart boundary. That's presentation-layer logic; it would
be unusual to test this outside of the HTTP context. The business rules
themselves are in PaymentService#validateAmount.

If the concern is that business logic is in the controller, I agree — and I
don't think it is. If the concern is something else, I'd like to understand it.

That response is direct, explains the reasoning, acknowledges the general principle behind the concern, and opens the door for clarification. It does not capitulate and it does not dig in emotionally.

When to Yield

Yield to a review comment when:

1. The reviewer identifies a correctness issue you missed
2. The reviewer has domain knowledge you lack (security patterns, database behavior, infrastructure constraints)
3. The reviewer's approach is clearly better and you were attached to yours for non-technical reasons
4. The tradeoff is close and it's not worth the time to argue — "I'll defer to your preference, since either approach works"

Explicit deference on close calls is not weakness. It's efficiency. If you would spend thirty minutes arguing for an approach that's 10% better but functionally equivalent, the argument has negative expected value.

When to Hold Your Ground

Hold your ground when:

• You have evidence the reviewer's approach is wrong (correctness, performance, maintainability)
• The reviewer's suggestion would introduce a regression you can demonstrate
• The reviewer is applying a general principle in a context where it doesn't apply, and you can explain why

Hold your ground respectfully. "I've thought about this and I still don't think X is the right approach here for reason Y" is a complete and professional response.

If you've gone two rounds without convergence, escalate to synchronous discussion — a quick call or chat is almost always faster than three more async exchanges. Explicitly call it: "I think we're talking past each other. Can we do a five-minute call to sort this out?"

The Comment That's Actually Wrong

Sometimes a reviewer is factually wrong. They misread the code, misunderstand the framework behavior, or apply a rule that doesn't hold in this context.

Address it with evidence, not condescension:

I think there might be a misread here — on line 34, the `session_id` is checked
before the call to `getUser()`, so the NPE case is already handled. Let me know
if I'm missing something.

I ran the test PaymentSessionTest#nullSessionOnGuestCheckout to confirm —
happy to share the output if it helps.

That response is respectful, specific, and gives the reviewer an easy off-ramp ("let me know if I'm missing something"). Most reviewers, when shown they've misread something, appreciate the correction.

The Norm Worth Establishing

Teams that handle review disagreements well have one thing in common: they've normalized explicit disagreement as part of the process. "I see this differently" is treated as a routine part of code review, not a confrontation.

If your team treats any pushback on a review comment as disrespectful, you've created an environment where compliance is incentivized over correctness. The code suffers for it.