Most teams have code review. Fewer teams have code review that works well. The process itself is not the problem – it is the patterns that emerge around it. Over time, without deliberate intervention, reviews drift towards behaviours that slow the team down, create friction between colleagues, and miss the issues that actually matter.
These are the anti-patterns. Each one is common, each one is recognisable, and each one has a structural fix.
The nitpick review
The nitpick review focuses on style over substance. The reviewer leaves 15 comments about bracket placement, variable naming conventions, import ordering, and trailing whitespace. The actual logic of the change – the algorithm, the edge cases, the error handling – goes unexamined.
Nitpick reviews feel productive because they generate a lot of comments. But they are not productive. They consume the author's time addressing trivial changes, they consume the reviewer's time writing comments that a linter could have caught, and they create a false sense of thoroughness. A PR with 20 style nits and zero logic concerns has not been reviewed. It has been proofread.
The deeper problem is what nitpicking does to trust. When an author sees a wall of comments about semicolons and blank lines, they stop taking review seriously. If the reviewer is focused on formatting, the author concludes that the reviewer is not really reading the code. And they are usually right.
The fix: Automate style enforcement entirely. Use a linter, a formatter, and pre-commit hooks. Remove style from the scope of human review. Once formatting is automated, reviewers have no choice but to engage with the actual substance of the change. This is not just more efficient – it forces better reviews.
The rubber stamp
The rubber stamp is the opposite of the nitpick. The reviewer opens the PR, glances at the diff, and clicks approve. No comments. No questions. No evidence of engagement. The review is complete in under two minutes, regardless of the size or complexity of the change.
Rubber stamping happens for several reasons. The reviewer might be overloaded with their own work and views review as an interruption. They might trust the author implicitly and assume the code is fine. They might not understand the area of the codebase well enough to provide useful feedback, and rather than admitting this, they approve silently.
Whatever the reason, the effect is the same: the review provides no value. Bugs pass through. Knowledge is not shared. The author gets no feedback on their approach. And the team develops a false confidence that reviewed code is quality code.
The fix: Require reviewers to leave at least one substantive comment per review – a question, a suggestion, or an explicit statement about what they checked. This does not need to be a policy written in stone; it can be a team norm. The goal is to create evidence that the reviewer engaged with the code. Some teams use a lightweight checklist: did you verify the error handling? Did you check for edge cases? Did you understand the test coverage? Completing the checklist is fast, but it forces the reviewer to actually look.
The architecture astronaut
The architecture astronaut turns every PR into a design discussion. A simple bug fix receives comments about the overall module structure. A feature addition triggers a debate about whether the service should be decomposed into microservices. The review stops being about the change and becomes about the system.
Architectural concerns are legitimate. But a PR review is not the right venue for them. The author submitted a specific change with a specific scope. When the reviewer expands that scope to encompass the entire architecture, the author is stuck. They cannot merge because the reviewer has raised objections. But they also cannot address the objections within the PR, because the objections are about system-level decisions that require broader discussion.
The result is a PR that sits open for days or weeks while architectural debates play out in comment threads. Momentum dies. The author context-switches to other work. When they finally return, the PR has merge conflicts and the discussion has gone stale.
The fix: Establish a clear norm: PR reviews evaluate the change as submitted, not the ideal state of the system. If a reviewer identifies an architectural concern, they should approve the PR (assuming the change itself is sound) and file a separate issue or discussion for the broader topic. This separates tactical review from strategic planning and keeps PRs moving.
The ghost reviewer
The ghost reviewer is assigned to the review and then disappears. Days pass. The author pings them. More days pass. The PR sits in limbo, blocking deployment and creating merge conflicts with other work. Eventually the author either reassigns the review, merges without approval, or gives up and abandons the change.
Ghost reviewing is rarely malicious. It usually happens because the reviewer is overloaded, the notification got buried, or they are avoiding a review they feel unqualified to do. But the effect on the team is corrosive. It tells the author that their work is not important enough to look at. It creates bottlenecks in the development pipeline. And it trains the team to treat review assignments as optional.
The fix: Set explicit SLAs for review turnaround. A common standard is 24 hours for initial feedback, with an automatic reassignment if the deadline passes. Make review load visible – if one person is consistently overloaded with review requests, redistribute. And normalise declining a review assignment. It is better for a reviewer to say “I cannot get to this today, please reassign” than to silently let it rot.
The scope creep review
The scope creep review turns every PR into a refactoring opportunity. The author submits a focused change, and the reviewer responds with comments like “while you are in this file, could you also rename this function?” or “this would be a good time to extract this into a utility module” or “can you add tests for the existing functionality too?”
Each individual suggestion might be reasonable. But collectively, they expand the scope of the PR far beyond what the author intended. The author now faces a choice: do the extra work (which delays the PR and introduces additional risk) or push back (which creates friction with the reviewer). Neither option is good.
Scope creep reviews also make PRs larger, which makes them harder to review, which increases the chance that something gets missed. The irony is that the reviewer is trying to improve quality, but by expanding scope, they are actually reducing the effectiveness of the review process.
The fix: Adopt the principle that suggestions for out-of-scope work should be filed as follow-up tickets, not blocking comments. The reviewer can say “I noticed this function could use a rename – I have created a ticket for it.” This captures the observation without holding the current PR hostage. It also creates a visible backlog of improvement work, which is more honest than pretending every improvement must happen in the current PR.
The common thread
All five anti-patterns share a root cause: the absence of explicit norms about what code review is for. Without a shared understanding, each reviewer defaults to their own interpretation. One sees review as a formatting check. Another sees it as an architectural forum. A third does not see it as their responsibility at all.
The fix, in every case, is structural. Automate what can be automated (style, formatting, common patterns). Set clear expectations for what human review should focus on (logic, design, edge cases, readability). Establish turnaround SLAs. Keep PR scope contained. Create separate channels for architectural discussions.
AI code review tools can help with this by handling the mechanical layer – the pattern checks, the vulnerability scans, the consistency analysis – and freeing human reviewers to focus on the judgement calls that only humans can make. When reviewers are not spending their time on nitpicks, they have the mental bandwidth to catch the bugs that actually matter.
The goal is not to make code review faster. It is to make it effective. A fast rubber stamp is worse than no review at all, because it creates false confidence. A slow architecture debate is worse than a focused review, because it blocks deployment without improving the change. Effective review is targeted, timely, and focused on what the automation cannot cover.
If your team recognises any of these anti-patterns, that is not a failure. It is an opportunity to make review better by addressing the structural causes rather than blaming individuals. The patterns are predictable. The fixes are straightforward. And the result is a review process that developers actually value rather than endure.
Limits and tradeoffs
- It can miss context. Treat findings as prompts for investigation, not verdicts.
- False positives happen. Plan a quick triage pass before you schedule work.
- Privacy depends on your model setup. If you use a cloud model, relevant code is sent to that provider; local models can keep inference on your own hardware.