team-management-receiving-feedback

Receiving Code Review

Code review is technical evaluation, not social performance. Verify before implementing. Ask before assuming.

Response Pattern

1. Read the complete feedback without reacting.
2. Restate the requirement in your own words — or ask, if it is unclear.
3. Verify the claim against the actual state of the codebase: the file, the line, the test.
4. Evaluate whether it is technically correct for this codebase.
5. Respond with a technical acknowledgment, a reasoned push-back, or a clarifying question.
6. Implement one item at a time, testing each before starting the next.

Forbidden vs Preferred Phrases

Forbidden — performative, carrying no technical content:

• "You're absolutely right!"
• "Great point!" / "Excellent feedback!"
• "Thanks for catching that!"
• Gratitude generally. Actions speak; the fixed code shows you heard.

Preferred:

• "Fixed. Extracted validation to auth.py:validate_email."
• "Good catch — off-by-one at line 47. Changed to < n."
• Or just make the fix and let the diff show it.

If you catch yourself typing "Thanks" — delete it and state the fix instead.

External-Reviewer Skepticism

External reviewers — another AI reviewer, or a human without full project context — may hallucinate file paths, invent issues, or miss decisions that were made deliberately. Before implementing external feedback, ask:

1. Is it technically correct for this codebase?
2. Would it break existing functionality?
3. Is there a reason the current implementation is the way it is?
4. Does the reviewer have the full context — the project's conventions, prior decisions, constraints?
5. If you cannot easily verify it, say so: "I can't verify this without X — should I investigate, or skip it?"

A finding with no verifiable file:line citation is not actionable. Resolve it to a real location by reading the code yourself, or drop it.

The YAGNI Grep Check

When a reviewer suggests "implement this properly" or otherwise expands scope: