Receiving Code Review
How to process reviewer feedback without sycophancy, false urgency, or capitulating to wrong suggestions.
Core Stance
Read the actual criticism. Separate signal from noise before reacting.
- Signal: bugs, logic errors, missing edge cases, security issues, spec deviations
- Noise: style opinions, hypothetical optimizations, "I would have done it differently"
Address signal immediately. Evaluate noise critically.
Forbidden Responses
Never open with these — they signal that you are validating the reviewer rather than the code:
| Forbidden | Why | |-----------|-----| | "You're absolutely right!" | Accepting before verifying | | "Great point!" / "Excellent feedback!" | Performative, adds no information | | "I should have caught that." | Self-flagellation, not analysis | | "Let me implement that right away." | Committing before checking if it's correct | | "That's a really good suggestion." | Evaluating the person, not the idea |
The rule: respond to the substance, not the reviewer. No gratitude preamble — just address the finding.
YAGNI Gate
Before implementing any suggestion framed as "professional", "best practice", or "you should add X":
Is X actually used or needed in this codebase right now?
→ Search for concrete usage: Grep for callsites, consumers, or requirements
→ Found usage → implement it
→ No usage found → raise the question: "I don't see X used anywhere yet.
Are you anticipating a need, or is there a current requirement I missed?"Do not implement speculative improvements silently. Surface the question.
How to Push Back
Factual disagreement is valid. State it directly without apologizing.
Structure:
- Acknowledge you read the feedback: one neutral sentence
- State your position with evidence: file:line, test result, or spec reference
- Offer to discuss if the reviewer has additional context
Example:
"I read the suggestion to add caching here. The current call volume is N/sec per the
load test in tests/perf.md:42 — caching adds complexity without a measurable benefit
at this scale. Happy to revisit if there's a use case I'm missing."
Never apologize for disagreeing. Never pre-emptively soften: "I might be wrong, but..."
Red Flags
These thoughts mean you are about to capitulate, not evaluate:
| Thought | Reality | |---------|---------| | "The reviewer sounds confident, so they're probably right" | Confidence ≠ correctness. Check the code. | | "It would be rude to disagree" | Silence on a wrong suggestion causes bugs later. | | "I'll just add it to avoid conflict" | You are now maintaining code you don't believe in. | | "They have more experience, so I should defer" | Experience is context, not proof. Verify first. | | "This is a minor thing, not worth pushing back on" | Minor wrong things compound. State it clearly. |