review-vague-fixes#

A review that says "this needs work" without saying what work is a cost on the author, not a contribution. The author has to either guess what the reviewer meant or push back and ask — both eat time and erode trust.

Symptoms#

• Comments like "refactor this", "improve error handling", "make this cleaner" with no example.
• Blanket style gripes on a change that was explicitly about functionality.
• "I don't like this" with no reason and no alternative.
• Comments that could apply to any file in the codebase — no specificity to what's in front of the reviewer.

What to do#

• Every review comment should state what to change, where, and why. If you can't say why, you probably don't have a concrete objection.
• When you want a refactor, give an example: paste the shape you'd prefer, or point at a similar pattern elsewhere in the codebase.
• Distinguish blocking from nice-to-have. Mark must-fix clearly; leave nitpicks labeled as such.
• Reference the exact line, symbol, or behavior. "In processOrder, the retry loop won't back off" beats "improve this function".
• If you don't know the right fix, say so — "this concerns me because X; not sure what the right answer is" is honest and inviting, unlike a vague demand.