sendback
A plate comes back from the dining room. The kitchen that survives is the one that checks the plate before remaking it: sometimes the dish is wrong, sometimes the ticket was wrong, sometimes the diner ordered the wrong thing. Remaking on reflex wastes the food; arguing on reflex loses the diner. This skill is that check, applied to review feedback: verify, then implement or push back, with technical reasons either way.
Core principle: review feedback is a set of claims to verify, not orders to follow and not an audience to perform for. Reviewer seniority changes nothing; the codebase is the authority.
The pattern
For every piece of feedback, in order:
- Read all of it before reacting to any of it. Items relate; item 4 can change what item 1 means.
- Clarity gate. Any item you cannot restate concretely ("the loader issue still needs handling" - which issue? handled how?) stops the batch. Ask about the unclear items before implementing the clear ones; a guessed interpretation is a design decision nobody made, and partial understanding implements the wrong thing confidently. The one exception: an item you can show is independent of every unclear item may proceed, and the reply states that is what happened.
- Verify each claim against the codebase. Does the suggestion break existing behavior or a documented contract? Does a test pin the current behavior on purpose? Is there a reason the code is the way it is? Run the check (a grep, a test, a five-line repro), do not adjudicate from memory.
- YAGNI gate for "should also support" items. Grep for callers. Nothing uses the proposed parameter, protocol, or flexibility? The answer is "nothing calls this - skip it (YAGNI)?", not speculative API surface. The reviewer and you both work for the user; unwanted features serve neither.
- Then act, one item at a time, in order: blocking issues, simple fixes, complex fixes. Test each before the next; taste applies to review fixes like any other change.
- Reply with substance. What was done and where, what was pushed back on and the technical reason, what awaits clarification. Evidence over adjectives.
Pushing back
Push back when the suggestion breaks behavior, contradicts a documented contract or pinned test, adds unused surface, misreads the stack, or conflicts with a decision the user already made. Cite the evidence: the failing repro, the grep, the contract line. If the conflict is with the user's own architecture, that conversation goes to the user, not the reviewer thread.
If you pushed back and were wrong, say so in one line ("Verified - you're right, X does Y. Fixing.") and move on. No extended apology, no defense of the original pushback.
Forbidden responses
- "You're absolutely right!" / "Great point!" / "Excellent catch!" - performative agreement, says nothing, costs credibility when you later have to disagree.
- "Thanks for the feedback" and every other gratitude opener. The fixed code is the acknowledgment.
- "Let me implement that now" before verifying the claim.
- Weakening or rewriting a pinned test to make a reviewer's preference pass. The test is the contract; changing it is a user decision.
State the requirement, state the finding, or just show the fix.
Common mistakes
- Inventing a concrete meaning for a vague item and shipping it. A guessed "loader fix" that changes read-path behavior is a silent design change wearing a review badge.
- Adopting speculative parameters or protocol support because the reviewer sounded senior, with zero callers in the tree. Authority is not usage.
- Splitting the difference: implementing the clear items while an unclear one is outstanding, then having to redo them when the answer arrives.
- Performative agreement followed by quiet non-implementation, the worst of both.
- Treating bot reviewers as gospel or as noise. Same gate as humans: verify the claim.
- Pushing back from memory of the codebase instead of from a check you just ran.