Ask developers privately what they think about code review and you will hear a consistent set of complaints. Not the polished version they give in retrospectives, but the real version – the one they share with colleagues over coffee or in anonymous surveys. Code review is slow. It is adversarial. The standards are inconsistent. The feedback is vague. It blocks deployment. It feels like surveillance.
These complaints are not character flaws. They are rational responses to a process that is frequently implemented badly. The good news is that every one of them has a structural fix.
Complaint 1: It is slow
The most common complaint is speed. A developer finishes a feature, submits a pull request, and then waits. Hours. Sometimes days. Their context evaporates. They start other work, but they are mentally holding two branches at once. When feedback finally arrives, they have to reload the original context before they can respond.
This is a legitimate complaint. Review latency is a direct drag on throughput. Research on development cycle time consistently identifies review wait time as one of the largest contributors to lead time. A PR that takes two hours to write should not take three days to review.
The fix: Set explicit turnaround expectations. Many high-performing teams target 4 hours for initial feedback and 24 hours for completion. Make review load visible so it can be balanced across the team. And reduce the amount of mechanical checking that humans need to do – every automated check that runs before a human sees the PR is time saved from the review cycle.
Complaint 2: It is adversarial
Code review can feel like a trial. The developer submits their work, and the reviewer finds fault with it. The language of review – “this is wrong,” “why did you do it this way,” “this needs to be rewritten” – carries an implicit judgement about the author's competence. Even well-intentioned feedback can land badly when it is delivered as a list of criticisms attached to someone's work.
The adversarial dynamic is amplified by power imbalances. A junior developer receiving a wall of comments from a senior engineer will often interpret it as disapproval rather than guidance. This discourages juniors from submitting work, slows their development, and concentrates knowledge in senior team members who are already bottlenecks.
The fix: Shift the framing from criticism to collaboration. Reviewers should explain the reasoning behind suggestions, not just state demands. Questions are less threatening than directives – “have you considered what happens when this input is null?” is more productive than “this does not handle null inputs.” Teams that adopt a norm of phrasing review comments as observations and questions rather than instructions see markedly better engagement from authors.
Complaint 3: Standards are inconsistent
One reviewer cares about test coverage. Another cares about naming conventions. A third focuses on performance. The same PR submitted on Monday might receive completely different feedback than if it were submitted on Thursday with a different reviewer. Developers cannot hit a target that keeps moving.
Inconsistency is demoralising because it makes review feel arbitrary. If the feedback depends more on who reviews the code than on the quality of the code itself, developers lose faith in the process. They start viewing review as a personality-dependent obstacle rather than a quality gate.
The fix: Codify your standards. Write down what a reviewer should check and what they should not. A shared checklist – even a simple one covering error handling, edge cases, test coverage, and security considerations – creates a baseline that every reviewer follows. This does not eliminate individual perspective, but it ensures that every review covers the same fundamentals. Automated analysis can enforce the objective parts of the standard, leaving human reviewers to focus on the subjective parts where individual judgement is valuable.
Complaint 4: Feedback is vague
“This could be cleaner.” “I am not sure about this approach.” “This feels wrong.” Vague feedback is one of the most frustrating aspects of code review because it gives the author no path forward. They know the reviewer is unhappy, but they do not know what to change. The result is a guessing game where the author makes modifications they hope will satisfy the reviewer, submits again, and waits for another round of feedback.
Vague feedback often comes from reviewers who sense that something is off but cannot articulate what. This is actually valuable intuition – experienced developers often detect code smells before they can name them – but it needs to be translated into actionable guidance. An unexplained feeling does not help the author.
The fix: Require that review comments include either a specific suggestion or a concrete question. Instead of “this could be cleaner,” the reviewer should say “extracting the validation logic into a separate function would make this easier to test.” Instead of “I am not sure about this approach,” the reviewer should say “this approach works, but it creates a tight coupling between the controller and the data layer – have you considered injecting the repository as a dependency?” Specificity transforms feedback from an obstacle into a learning opportunity.
Complaint 5: It blocks deployment
In many teams, code cannot be merged without an approved review. This is a sensible gate in principle, but in practice it means that review becomes a bottleneck. If the reviewer is on holiday, the code waits. If the reviewer disagrees with the approach, the code waits. If the reviewer is busy with their own work, the code waits. The deployment pipeline is only as fast as the slowest reviewer.
The blocking nature of review is especially frustrating for time-sensitive changes. Hotfixes, security patches, and small bug fixes that need to ship quickly are held to the same review process as large features. Developers learn to resent review not because they disagree with the concept, but because the implementation treats all changes as equal when they clearly are not.
The fix: Tier your review requirements by risk. Low-risk changes – documentation updates, configuration tweaks, single-line bug fixes – can use a lighter review process or post-merge review. High-risk changes – new features, security-sensitive code, infrastructure changes – warrant thorough pre-merge review. This is not about lowering standards. It is about matching the review investment to the risk of the change.
Complaint 6: It feels like surveillance
When review metrics are tracked and reported – how many comments each developer receives, how many review rounds their PRs require, how often they are asked to make changes – developers begin to feel watched. Review stops being a collaborative process and starts feeling like a performance evaluation.
This perception is especially strong in organisations where review data is visible to management. If a developer knows that their manager sees how many review comments they receive, they will optimise for fewer comments rather than better code. They will submit smaller, safer changes. They will avoid experimental approaches. They will stop taking risks. This is the opposite of what a healthy engineering culture wants.
The fix: Keep individual review metrics out of performance evaluations. Use aggregate metrics for process improvement – average review turnaround time, average cycle count, overall defect rates – but do not attribute them to individuals. Review is a team activity, and the metrics should reflect team performance, not individual scores. When developers trust that review data is not being used to judge them, they engage more honestly with the process.
The separation principle
Many of these complaints trace back to a single design problem: human reviewers are doing work that machines should do, and the things that humans are uniquely good at are being neglected as a result.
The separation principle is simple. Automate everything that can be objectively verified: formatting, linting, common vulnerability patterns, test coverage thresholds, import ordering, naming conventions. This is the mechanical layer of code review, and it should be handled by tools that are consistent, fast, and unemotional.
Reserve human review for what requires human judgement: is this the right approach? Does the naming communicate intent? Are the edge cases covered? Is the error handling appropriate? Will the next developer who reads this code understand what is happening?
When you make this separation, every complaint on the list becomes easier to address. Reviews are faster because humans are doing less. Standards are more consistent because the objective parts are automated. Feedback is more substantive because reviewers are focused on design, not formatting. The process feels less adversarial because human comments are about reasoning and approach, not style nits.
AI code review tools fit naturally into this separation. They handle the broad, mechanical scan – the vulnerability patterns, the dead code detection, the consistency checks – while humans focus on the narrow, high-judgement review that requires understanding of context, intent, and design trade-offs.
Developers do not hate code review. They hate bad code review. Fix the process, and the resistance disappears.
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.