receiving-code-review

Process code review feedback through a structured six-step protocol: READ the feedback carefully, UNDERSTAND what's being suggested, VERIFY it against your codebase, EVALUATE its technical correctness, RESPOND with clarification if needed, and IMPLEMENT only validated changes. This ensures changes are technically sound rather than performative.

Push back on code review feedback when it's technically questionable or unsupported by codebase usage. Before rejecting a suggestion—like removing 'legacy code'—verify whether the code is actually unused or serves backward compatibility needs, then respond with reasoned technical arguments rather than defensiveness.

When code review feedback is unclear, explicitly state which items you understand and request clarification on specific points before proceeding. This prevents misinterpretation and ensures you're addressing the reviewer's actual intent, not assumptions about their feedback.

Verify suggested changes by checking actual codebase usage patterns. Apply a YAGNI check to confirm whether 'professional' features or refactorings are genuinely needed—not just theoretically sound—before implementing, ensuring changes deliver real value rather than technical debt.

Implement code review changes one item at a time with testable validation for each change. This approach isolates which modifications improve code quality, prevents bundling unrelated suggestions, and allows rollback of individual changes if problems emerge.

Verifying code review feedback prevents blind implementation of technically unsound suggestions. This verification step—checking against architectural decisions, codebase patterns, and actual usage—ensures changes maintain quality standards and don't introduce regressions or unnecessary refactoring.