Your team ships six pull requests a day. You open the next one — 400 lines across nine files. You know you should check for security issues, style violations, missing error handling, and whether the approach actually fits the system. You also know you have three more PRs waiting.
So you skim. You catch the obvious things, approve, and move on. The review took ten minutes instead of forty, but you skipped half of what matters.
This is not a discipline problem. It is a process problem — and it has a straightforward fix.
Why PR reviews take so long
A thorough code review is actually two separate jobs done in one pass:
Job 1: Mechanical checks. Does this diff contain hard-coded secrets? SQL injection? Missing auth on a new endpoint? Inconsistent naming? Unclosed resources? Logging sensitive data?
Job 2: Architectural judgment. Does this approach fit the system? Is the abstraction at the right level? Will this scale? Is there a simpler way?
Job 1 is pattern matching. It is the same checklist on every PR, and it is tedious. Job 2 is the part that requires a senior engineer's experience and context.
The problem is that most reviewers do both in a single pass through the diff. They are scanning for typos and SQL injection at the same time they are evaluating whether the service boundary makes sense. Context switching between those two modes is what makes reviews slow and exhausting.
The fix: split the two jobs
If you separate the mechanical checks from the architectural review, each one gets faster.
Step 1: Automate the mechanical checks. Before a human reviewer opens the PR, run automated checks for the patterns that do not require judgment:
- Hard-coded secrets and credentials
- SQL injection and other injection flaws
- Missing authentication or authorisation checks
- Overly permissive CORS
- Sensitive data in logs
- Unused imports and dead code
- Naming convention violations
These checks are deterministic. A tool that knows the rules catches them more reliably than a human who is also thinking about architecture.
Step 2: Review what is left. When the mechanical issues are already flagged — or already fixed by the author before you open the diff — your review starts clean. You read the code once, focused entirely on design, approach, and whether this change fits the system.
One focused pass instead of two interleaved passes. That is where the 2x comes from.
What this looks like in practice
Here is a concrete before-and-after for a 400-line PR that adds a new API endpoint:
Before (single-pass review, ~40 minutes):
- Open the diff. Scroll through nine files.
- Notice a hard-coded database URL on line 47. Leave a comment.
- Check the new endpoint's route — no auth middleware. Leave a comment.
- Spot an
f"SELECT ... {user_input}"\— SQL injection. Leave a comment. - Think about whether this endpoint belongs in this service or should be a separate one. Lose the thread because you are still looking for bugs.
- Find a
console.log(req.body)\that logs passwords. Leave a comment. - Go back to the architectural question. Decide the service boundary is fine.
- Approve with comments.
After (split review, ~20 minutes):
- Automated review has already flagged the hard-coded URL, the missing auth, the SQL injection, and the logged passwords. The author fixed them in a follow-up commit before requesting human review.
- Open the diff. It is clean — no security issues, no style violations.
- Focus entirely on the architectural question: does this endpoint belong here, is the data model right, will this scale.
- Approve.
The human review went from 40 minutes of interleaved scanning to 20 minutes of focused thinking. The bugs were caught faster, too — within seconds of the PR opening, not hours later when the reviewer got to it.
Setting up the automated first pass
You need a tool that runs on every PR, checks for the mechanical issues, and posts findings as inline comments so the author can fix them before requesting review.
An automated pull request review tool does exactly this. It reads the diff, checks it against security and quality rules, and comments on the specific lines that need attention — all before a human opens the PR.
Diffnix runs this check in under five seconds per PR. Its PRInspector agent catches hard-coded secrets, injection flaws, missing auth, logged sensitive data, and more, posting findings as inline GitHub comments. It runs on self-hosted models, so your code never leaves your infrastructure. There is a free plan for up to three repositories — enough to try it on the repos with the longest review queues.
Three things to do this week
- Pick your slowest repo. The one where PRs sit in the review queue longest. Start there.
- List your mechanical checks. Write down the things you check on every PR that do not require architectural judgment. Hard-coded secrets, injection, auth, logging, style. This is the list you automate.
- Automate the list. Set up a tool that checks every PR against that list before a human reviewer opens it. The goal is that by the time you open a PR, the easy issues are already flagged or fixed.
Your reviews are slow because you are doing two jobs in one pass. Split them, automate the repetitive one, and spend your review time on the questions only a human can answer.
For background on what automated review checks and how it fits a team workflow, read What Is AI Code Review? A Practical Guide for Engineering Teams.
Moonlight Devs builds Diffnix, an AI code reviewer for GitHub pull requests.
Top comments (0)