@ahmetcantryk
Running an effective code review means hunting for risk, not nits: correctness, design, and maintainability matter far more than formatting a linter should already catch. Small PRs, fast turnaround, a clear blocking-versus-non-blocking split, and a skeptical eye toward 2026's AI-slop wave are what actually cut risk — not who wins the semicolon debate.
What is code review actually for?
The job of code review is to check correctness, architecture, and maintainability — not code style. Google's reviewer standards say this outright: a reviewer should look at design first, then functionality, complexity, and test coverage, while style and formatting belong to automated tools, not humans. The same guide recommends a "Nit:" prefix — a short label that marks a comment as trivial and explicitly non-blocking.
Debating a major design decision inside PR comments is already a defense played too late. A decision that reshapes the architecture should have been settled in an engineering RFC before any code was written; if "why did you build it this way" comes up during review, the process is running a step behind.
My mildly spicy take: a review that leaves forty nit comments and still misses a race condition isn't thorough — it's a failure. Comment count measures what the reviewer focused on, not the quality of the review.
Why small PRs and fast turnaround cut cycle time
Most complaints about the review process are actually complaints about its speed. Google's eng-practices guide sets a hard target: respond to a review request within one business day at the latest, ideally much sooner, and try to fit multiple review rounds into a single day. It states the point directly: "most complaints about the code review process are actually resolved by making the process faster."
Volume matters as much as speed. SmartBear's long-cited research (Cisco-originated, still SmartBear's flagship data page) found that the optimal review batch is 200–400 lines of code, and capping sessions at 60–90 minutes yields roughly 70–90% defect detection. Push past 400 lines, or review faster than 500 lines of code per hour, and that rate drops sharply.
Review batch size | Defect detection | Pace |
|---|---|---|
≤ 200 lines | High (70–90% range) | Comfortable, under 500 LOC/hour |
200–400 lines | Optimal, 70–90% | At or under 500 LOC/hour |
> 400 lines | Drops sharply | Usually exceeds 500 LOC/hour |
Combine the two data points and the practical rule writes itself: keep PRs under 400 lines, cap the review at 90 minutes, and answer the request within a business day. Git branching strategies like trunk-based development naturally force a small, frequent PR flow; a giant feature branch getting stuck in review is usually a branching-strategy problem in disguise.
Tone, and blocking vs non-blocking comments
The severity of a comment should be legible from its label, not the harshness of the sentence. The author's question — "can I merge this?" — should be answered by the comment itself, not by guessing the reviewer's mood.
Nit: We could rename this to `id` instead of `userId`, not required.
Should: This function is 120 lines; let's consider splitting out the validation.
Must: This query doesn't escape user input — SQL injection risk, fix before merge.No PR should merge with an unresolved "Must" comment; no PR should be blocked by a "Nit." When that line is left to each reviewer's mood, one teammate writes "great work" while another holds up the PR over a comma — and that inconsistency wears a team down faster than the review itself.
Author responsibilities
A good review needs a good PR. Read your own diff before requesting review; a large share of "Nit" comments disappear the moment authors self-review first. Running through clean code principles as a checklist — naming, function length — before opening the PR frees the reviewer to spend their time on actual risk.
Don't skip the description: what changed, why, and how it was tested. A PR that ships without tests forces the reviewer to fly blind; unit tests that actually help verify correctness with runnable proof, not the reviewer's eyeballs. Meet feedback with curiosity, not defensiveness — "why this way" is usually a genuine information gap, not an accusation.
Reviewing AI-generated PRs skeptically
As of July 2026, AI slop is no longer a theoretical risk — it's daily operational load. One open-source maintainer reported that 71% of the 136 pull requests they received in a 15-day window were low-quality, AI-generated "slop." CodeRabbit's own research found AI-generated PRs carry roughly 1.7x more issues than human-written ones — vendor research, so read it as directional rather than neutral, but the direction is clear.
The volume got bad enough that The Register reported in February 2026 that GitHub was evaluating a "kill switch" for pull requests to stem AI slop, and curl shut down its public bug-bounty program for the same reason. In that environment, a PR shouldn't get a different quality bar just because "AI wrote it" — but it should get a more skeptical default: the code may look like it works while nobody, human or agent, can explain why it was written that way.
Two habits make the real difference in practice: refusing to accept that a diff "looks reasonable" as sufficient, and instead interrogating every error path and edge case individually, and confirming the author — human or agent — can actually defend the diff. Our posts on mistakes when using AI coding assistants and how AI slop is straining open-source security dig deeper into where this skepticism should come from.
Reviewer checklist and a comment-severity convention
Ask the same questions in the same order every time: risk first, style last.
- Does this change actually work, and were edge cases considered?
- Is there a security hole, data leak, or authorization gap?
- Is the design consistent with the rest of the system, or does it bolt on unneeded complexity?
- Do the tests verify real behavior, or just pad coverage numbers?
- Is this change reversible, or does it open a one-way door in production?
- If there are style or formatting issues, could a linter already own those?
Label | Meaning | Blocks the PR? |
|---|---|---|
Nit | A preference, an optional polish | No |
Should | A real improvement, but not urgent | Usually not — author's call |
Must | Correctness, security, or architectural risk | Yes, unresolved blocks merge |
The three-label system isn't complicated, but applied consistently it keeps authors from getting defensive and makes it easier for reviewers to say what actually matters without burying it.
Frequently Asked Questions
What's the most common mistake in code review?
Spending more time on style and formatting than on correctness and design. Most of those issues are already solved by a linter and a formatter; spending human attention there increases the odds of missing the risks that actually matter.
How fast should a PR get reviewed?
Google's guidance is within one business day at the latest, ideally much sooner. If multiple rounds are needed, aim to fit them into the same day — delay is the root cause behind most complaints about the review process.
Should AI-written code be reviewed differently?
Change the default trust level, not the bar. Even when a diff looks reasonable, interrogate every error path separately and confirm the author can defend the change; the 2026 AI-slop data shows the gap between "looks correct" and "is correct" has grown wider than it used to be.
Should Nit comments be ignored entirely?
No, but they shouldn't block. A suggestion labeled Nit can still be valuable — it just leaves the decision to act on it with the author and shouldn't hold up the merge.
