Code Review Health Is a Trend, Not a Comment Count
Use automation and draft pull requests to align teammates early, then track whether repeated feedback declines as shared conventions become real practice.
Source and AI note: This article is based on Gemini’s Devpractice on YouTube. It was generated and edited with the
gpt-5.6-solmodel.
If dozens of review comments arrive after three days of work, that says less about the author’s ability than about when the team synchronized. A new teammate may have completed a large change only to discover that the team uses a different structure, while a release is already close. Neither merging it unchanged nor rewriting it under pressure is a good outcome.
If dozens of comments arrive after three days, alignment came too late
The answer is to make the work visible sooner. Start a new teammate with smaller work, and open a draft pull request before the implementation is complete. A proposed concept, table shape, or early slice gives colleagues something concrete to review while direction is still cheap to change. Drafts also help when someone has been stuck longer than expected: an asynchronous look at the work in progress can reveal the size of the task and the decision causing delay without waiting for a polished PR.
Remove comments a machine can settle
Formatting, spacing, lint, and other deterministic rules should be enforced by a formatter, check, or build task. Repeating them in human review is noise, not team alignment.
People are more useful on the team’s concepts, system design, implementation choices, and local conventions. Careful feedback to a newcomer is a sign that a colleague wants to work in step with them. The explanation should come from this product and team’s choices, not from invoking an outside authority as the answer.
Read the direction, not the total
Many comments are normal when a person joins or a team is newly assembled. After a year together, the same volume and same kinds of disagreement are a reason to ask whether the team has actually aligned. The useful measure is whether repeated feedback declines as people learn how they build the software together.
A low count can mean shared judgment, or it can mean nobody reviewed carefully. A high count can mean good teaching, or feedback that arrived too late. Content and trend distinguish those cases. The goal is not a silent PR; it is a team that catches important differences early and has fewer old arguments to repeat.