Code review response

Code review is a technical exchange, not a social one. The job isn't to agree warmly and start changing things — it's to understand each point, verify it against the real code, and then implement it, push back on it, or ask about it on the merits. Blindly applying a suggestion that's wrong for this codebase is as much a failure as ignoring a good one.

The response pattern

For each piece of feedback:

1. Read it fully before reacting. Take in all of it, not just the first comment.
2. Restate the point in your own words — or ask, if you can't. If you can't articulate what's being asked, you can't correctly implement it.
3. Verify against reality. Check the claim against the actual codebase. Is the problem real here? Does the suggested approach fit how this code already works?
4. Evaluate on technical merit. Is it sound for this codebase, not just in the abstract?
5. Respond. A technical acknowledgement, a clarifying question, or reasoned pushback — whichever the evaluation produced.
6. Implement one item at a time, verifying each before moving to the next.

Skip the performance

Don't open with "You're absolutely right!", "Great point!", or "Let me implement that right away" — the first two are filler, and the third commits you before you've checked anything. Replace the reflex with substance: restate the technical requirement, ask a clarifying question, push back with reasoning if it's wrong, or just quietly start the work. Actions communicate more than agreement noises.

When feedback is unclear

If any item is ambiguous, stop — don't implement anything yet — and ask about the unclear items specifically. Guessing at what a reviewer meant and building the wrong thing wastes both your effort and their next review. It's faster to ask.

When feedback seems wrong

Sometimes a suggestion is incorrect for this codebase: it misreads the code, conflicts with a constraint the reviewer can't see, or would introduce a regression. Push back — with evidence. Cite the file and line, state the concrete problem the suggestion would cause, and propose the alternative. A reviewer would rather be shown a real issue than have a mistaken comment implemented silently. If you turn out to be the one who's wrong, you've learned something; either way the code is better than if you'd agreed reflexively.

Implementing

• One item at a time. Bundling several changes makes it impossible to tell which one broke something.
• Verify each change before the next — the verify-completion skill is the standard: run the check, read the output, then move on.
• For anything non-trivial, a failing-test-first approach (the test-driven-development skill) proves the change does what the reviewer asked.
• Track which items you've addressed and which you've deferred, so the reviewer can see what happened to each comment.