DEV Community: Pyor

Reviewing PRs Locally vs. in the Browser

Othman Shareef — Wed, 24 Jun 2026 08:00:00 +0000

Every team has one: the reviewer who refuses the web diff, pulls the branch, and reads the change in their editor. They’re usually among the best reviewers on the team, and they’re paying a real tax for it. Some of the strongest engineers we know review this way; this piece is about what they’re getting, what it costs, and when each mode actually wins.

The short answer:
Pull the branch when you need to navigate (jump to definition, find usages), run the change, or judge a refactor’s shape; the editor’s context is unbeatable. Stay in the browser for small, self-contained diffs where inline comments and speed matter more. The deciding question: do I need to see more than the diff shows? If yes, pull.

What local review actually buys you

Navigation. Go-to-definition, find-references, the call hierarchy: the diff shows what changed; the editor shows what the change touches. For judging a refactor or an API change, that difference is the review.
Execution. Run the tests, poke the feature, profile the hot path. The web diff asks you to trust; the checkout lets you verify.
Your tools. Your keybindings, your linters, your search. Reviewing in an environment tuned over years beats any vendor’s viewer for raw reading throughput.

What it costs

Context switching. Stash or commit your work, switch branches (or maintain a second worktree), restore state afterward. gh pr checkout makes the fetch cheap; nothing makes the interruption cheap.
The transcription tax. Findings live in your head and the PR conversation lives in the browser. Every comment means re-finding the file and line on github.com and reconstructing your thought. This is where local reviewers quietly lose their time advantage, and why their feedback sometimes arrives as one big comment instead of anchored threads.
No shared state. Viewed-file tracking, resolved threads, suggested changes: the collaborative review machinery doesn’t follow you into the editor.

A decision rule that holds up

Pull the branch when the review question is architectural or behavioral: does this design hold, does this actually work, what does this break elsewhere. Stay in the diff when the question is local correctness: is this logic right, are the edges handled, is it consistent. Mixed PRs (most large ones) often deserve both: a browser pass for triage and threads, a checkout for the two files where the real decision lives.

The gap both modes leave

Notice the shape of the trade: one mode has the context (editor) and the other has the conversation (browser), and review needs both. That gap is the design brief we started Pyor from: a native review app with diff ergonomics built for reading (file triage, viewed tracking that includes whole folders, focus mode, a diff that keeps your place at any size) and the full review loop: inline threads, approvals, and merge, synced with GitHub. It talks to GitHub directly from your machine, so the privacy posture matches local review: your code never passes through our servers. Free for individuals. It won’t replace the checkout for “does this design hold” (nothing replaces running the code), but it retires the checkout you were doing just to read comfortably.

If you take one habit from this

Make the mode a deliberate choice per-PR instead of an identity. The reviewers who do this best aren’t “local people” or “browser people”; they ask what does this change need from me? and pick the cheapest surface that delivers it. The one identity worth keeping: never approve a change you couldn’t explain to the next reviewer, wherever you read it.

Frequently asked questions

How do I check out a PR branch quickly?

With GitHub’s CLI: gh pr checkout <number> fetches and switches to the PR branch in one step. Add --detach to avoid creating a local branch you’ll forget to delete.

Do I lose the ability to comment when reviewing locally?

On vanilla setups, mostly yes: findings have to be transcribed back to the PR by hand, which is the biggest hidden cost of local review. Editor extensions (like the GitHub PR extension for VS Code) close part of the gap; dedicated review apps close more of it.

Stop Losing Review Requests: Fixing the PR Review Inbox

Othman Shareef — Mon, 22 Jun 2026 08:00:00 +0000

Somewhere in your GitHub notifications is a review request from four days ago. The author pinged once in Slack, felt annoying, and stopped. The PR is rotting; the branch is drifting toward conflicts. Nobody decided this; it’s just what happens when review requests travel through a channel built for everything.

The short answer: Review requests get lost because GitHub notifications mix them with every mention, CI result, and issue update across every repo. The fix is a dedicated funnel: a filtered view that shows only what waits on you, a team SLA for first response (Google’s guidance: one business day, maximum), and scheduled review blocks so the queue gets drained on purpose instead of by guilt.

Why the default funnel fails

The notification stream is unranked and unbounded: a review request, the one item where a teammate is blocked on you, gets the same row as a bot comment. Email filters help until they file the request neatly into a folder nobody opens. And the morning sweep (“mark all as read”) is where review requests go to die. The structural problem: requests for your attention live mixed with information that merely mentions you.

Make a view that answers “who waits on me?”

GitHub’s own search can build a serviceable inbox; most developers just never wire it up. Bookmark these:

is:open is:pr review-requested:@me archived:false: everything explicitly waiting on your review, across all repos.
is:open is:pr reviewed-by:@me -review-requested:@me: PRs you reviewed that may have replied to you (re-review limbo, the second-biggest leak).
is:open is:pr author:@me review:changes_requested: your own PRs blocked on your response; authors leak too.

The discipline is checking the views on a schedule, which is the next fix.

An SLA plus review blocks beats heroics

Google’s review-speed guidance is blunt: respond within one business day at the slowest, because slow review taxes the whole team’s velocity and morale. The workable pattern isn’t interrupting deep work for every request; it’s two or three scheduled review blocks a day (start of day, post-lunch) plus the SLA as a backstop. Predictability is the actual product: an author who knows the longest possible wait can plan; one staring at silence pings, escalates, or gives up.

The first response doesn’t need to be the full review: “looked at the description, I’m the right reviewer, full pass by 3pm” unblocks more than it sounds like it should.

Drain the queue by unblock value, not arrival order

When the block starts, don’t review oldest-first. Triage by what unblocks the most: PRs with no reviewer yet beat PRs with two; a teammate’s release-blocker beats a refactor; a re-review (author already responded) usually costs minutes and clears a thread someone is anxiously refreshing. Five minutes of queue triage routinely saves a teammate’s afternoon.

Tooling: this is a solved-shape problem

Everything above is workflow, and it works with bookmarks and a calendar. The tooling version is having the funnel built in, which is how we approached it in Pyor (our product, free for individuals): a pull-request dashboard for everything that matters to you (authored, assigned, awaiting your review), a comments inbox that gathers every thread and reply across repos into one feed, and a team view that ranks open PRs by how much you can unblock, surfacing the ones with no reviewer first. The queue stops being something you remember to check and becomes something you look at once and act on. For what to do when the PR you open is enormous, see reviewing large PRs.

Frequently asked questions

What’s a reasonable SLA for first review response?

Google’s engineering practices set the bar at one business day as the absolute maximum, and treat faster as materially better. Many teams aim for a few working hours for the first response, even if it’s “looked, will review properly after lunch.” The SLA is for responsiveness, not completed review.

Should reviewers be interrupted by every review request?

No. Interrupting deep work for every request trades one team problem for another. The standard compromise is scheduled review blocks (start of day, after lunch) plus an SLA that makes the longest possible wait predictable. Authors can plan around predictable; they can’t plan around silence.

AI Writes Code Faster Than You Can Review It

Othman Shareef — Sat, 20 Jun 2026 08:00:00 +0000

In GitHub’s controlled experiment, developers using Copilot completed a coding task 55% faster than the control group. That was 2022-era tooling: autocomplete, not agents. Nobody has published the companion number, because it doesn’t exist: reviewing a line of code is exactly as expensive as it was in 2019. Human reading didn’t get a model upgrade.

The short answer: AI made writing code dramatically cheaper while the cost of understanding code stayed flat. That asymmetry moves the bottleneck from authoring to review, and no amount of “review harder” fixes a structural imbalance. The fixes are structural too: smaller changes, review pushed upstream of the PR, and a review surface that wastes none of the reviewer’s attention.

Amplifiers amplify both directions

There’s a line making the rounds in engineering leadership circles: AI is an amplifier: teams with strong practices get stronger, teams with weak ones get worse. Review is where that cashes out. A team that already wrote small PRs with good descriptions now ships even faster, because review keeps up. A team that tolerated 1,500-line mixed-concern PRs now produces them twice as often, and the review queue, not the roadmap, sets their velocity.

The failure modes are predictable. Diffs grow, because generating is cheap and splitting is work, the trend that made us write how big should a PR be? Reviewers rubber-stamp, because honest review of the incoming volume is impossible and something has to give. Or reviewers hold the line and become the constraint, absorbing the team’s frustration for doing their job. Pick your dysfunction.

“Just review less” isn’t the answer: understanding is the product

It’s tempting to conclude review is now overpriced ceremony: let CI and the AI reviewer bots gate merges. But code review was never only defect-hunting. Microsoft’s research on review at scale found its biggest delivered values include knowledge transfer and shared understanding, not just bugs caught. In the agent era that function gets more important: when a model writes the code, review is the moment a human takes ownership of it. Skip that, and you ship a system nobody on the team understands, a debt with compounding interest.

The three places to attack the asymmetry

Shrink the unit of review. Size caps, stacked PRs, splitting norms: everything in the data says this is the highest-leverage move. Small changes are the one thing that makes every other fix cheaper.
Move review upstream. The author (or their agent’s supervisor) reads the diff before it becomes a PR (pre-PR review), and an AI first pass clears mechanical noise. Human reviewers should see changes a human has already vouched for, with a checklist like our AI-code review checklist applied.
Stop taxing the reviewer. If review is the scarce resource, every lost scroll position, collapsed file, and buried thread is waste of the exact thing you’re short on. This is the lever we work on at Pyor: making the irreducible human part (reading and understanding a diff) as fast as the surface allows, especially for the large PRs that keep coming.

The uncomfortable conclusion

Most teams’ effective shipping speed is now set by review throughput, not authoring speed, whether they’ve noticed or not. The teams that internalize that will redesign around it: smaller units, upstream review, surfaces that respect reviewer attention. The rest will keep buying faster code generation and wondering why the cycle time didn’t move. The bottleneck doesn’t care how fast you fill the queue.

Frequently asked questions

Won’t AI reviewers eventually close the gap themselves?

They’ll keep absorbing the mechanical share of review: bugs, style, obvious edge cases. But review is also the team’s understanding-transfer mechanism: a human vouching that the change is what the team intended. Outsourcing that entirely means nobody on the team understands the system, which is a different and worse bottleneck.

What’s the single highest-leverage fix?

PR size. Every line of evidence, from the Cisco review study to Google’s engineering practices, says small changes get reviewed faster and better. Most other fixes (self-review, AI first passes, better tooling) work best after size is under control.

GitHub PR Review Alternatives in 2026: An Honest Comparison

Othman Shareef — Thu, 18 Jun 2026 08:00:00 +0000

First, the disclosure this genre usually buries: we build one of the tools in this comparison , Pyor. Read accordingly. We’ll make the case for the others honestly, because they’re good tools attacking the same real problem from different directions, and the right pick genuinely depends on your team.

The map: Four ways to escape the github.com review experience: prevent big diffs (Graphite’s stacked PRs), add AI guidance to the diff (Stage’s chapters, CodeRabbit’s bot reviews), upgrade the surface and let AI triage it (Pyor), or pull the branch and review locally (free, powerful, high friction). They’re mostly complementary, not exclusive.

Why teams look beyond github.com for review

GitHub is where the PRs live, but its review surface shows its priorities: it’s a code host first. Large diffs paginate and collapse, your place evaporates between visits, review requests drown in notification noise, and there’s no triage: every file gets equal billing whether it’s the core change or a lockfile. None of this is fatal for a 50-line PR. All of it compounds for the 2,000-line ones that keep arriving in the agent era.

Graphite: don’t have big PRs in the first place

Graphite is the workflow cure: stacked pull requests. Break a large change into a sequence of small, dependent PRs; their tooling (CLI, VS Code extension, stack-aware merge queue) makes the bookkeeping bearable, and an AI reviewer plus a PR inbox round out the platform. The case for it is the research: small changes review better, full stop. The honest caveats: stacking is a team-wide workflow change with a real learning curve, the cure doesn’t apply to changes that are legitimately atomic (migrations, codemods), and you’re adopting a platform, not a viewer. If your team has the discipline budget, it’s the structurally right answer. Free trial, then per-seat pricing.

Stage: let AI narrate the diff

Stage (YC-backed, launched 2026) takes the opposite bet: the diff stays big, but AI organizes it into logical chapters with guidance (what changed, what to double-check), plus an assistant that answers “what’s risky here?” with line citations. Everything syncs back to GitHub. If your reviewers’ bottleneck is orientation (staring at an unfamiliar change with no map), the chaptering is genuinely clever. Our honest reservation (and it’s now a difference of degree, since we ship AI triage too): Stage leans on generated prose you read and trust, chapters plus an assistant, and when the narration and the code disagree you still have to read the code. We keep our AI pointing at the code (groups, one-line labels, hints) rather than narrating it, so there’s less generated text standing between you and the diff. Reviewers who want a fully narrated guide may prefer Stage, and that’s fair. 14-day trial, then paid.

CodeRabbit and the AI-reviewer bots: a first pass, not a reviewer

Tools like CodeRabbit (and GitHub’s own Copilot review) post AI-generated review comments directly on the PR. As a mechanical first pass (obvious bugs, style drift, missed edge cases) they’re cheap and useful, and they run before a human ever looks. The limits are the ones we covered in reviewing AI-generated code: the bot doesn’t know your intent, shares blind spots with whatever generated the code, and adds comment volume that someone still has to triage. Adopt one to clear noise; don’t let “the bot approved” become culture.

Pyor: a fast surface, plus AI that organizes the diff

Our entry, so the claims stay modest and checkable: Pyor is a native review surface for existing GitHub PRs (read, comment, approve, and merge in one window, without opening github.com), web first with a desktop app for macOS and Windows. The thesis is that the raw act of reviewing is the bottleneck, so the surface gets the engineering: a file rail built for triage, folder-level viewed tracking, inline threads that stay put, focus mode, and a diff that stays navigable at any size.

Where Pyor uses AI, it organizes rather than narrates. It groups the files by complexity, labels each group in one line, and drops short hints that point you at the parts worth your attention first, so on a big PR you review the right code first (there’s a walkthrough mode that orders the whole thing for you). What it deliberately does not do is generate walls of summary you have to read and then re-check against the code. The AI points at the diff; it never stands in front of it. Free for individuals; paid per-seat for org features. The honest caveats: it’s young, and it’s a viewer, not a workflow platform (no stacking, no merge queue).

The free option: pull the branch

git fetch && git checkout remains a legitimate answer: full editor navigation, run the tests, zero dollars. The cost is friction: stash your work, lose inline commenting, transcribe findings back to GitHub by hand. It’s the power move for the gnarliest changes and overkill for the rest. We compare it properly in a future piece on local vs. browser review.

At a glance

Tool	Approach	Best when	Pricing
Graphite	Stacked PRs + merge queue + AI reviewer	The team can adopt a stacking workflow	Free trial, then per-seat
Stage	AI chapters + guidance over the diff	Reviewers need orientation in unfamiliar changes	14-day trial, then paid
CodeRabbit (and bots)	AI comments posted on the PR	Mechanical first pass before human eyes	Per-seat
Pyor	Native surface + AI that triages, not narrates	The reading itself is the bottleneck	Free for individuals; per-seat orgs
Pull locally	Full editor + run the code	One gnarly architectural change	Free

How to actually choose

Team can adopt a new workflow? Graphite’s stacking attacks the root cause.
Reviewers feel lost in unfamiliar changes? Stage’s chapters give them a map.
Want mechanical issues caught before humans look? Add an AI reviewer bot.
Drowning in big diffs but allergic to walls of AI text? That’s Pyor: the AI triages and points, you read the code.
One brutal change, once? Pull it locally.

And since they all sync to GitHub, the cheapest experiment is one reviewer trying one tool on one real PR this week, no team buy-in required.

Frequently asked questions

Do these tools replace GitHub?

No. Every tool in this comparison sits on top of GitHub pull requests: comments, approvals, and merges sync back to GitHub. You can adopt any of them (or stop using them) without changing where your code lives.

Which alternative is best for large pull requests?

It depends on where you want to spend effort. Graphite prevents large PRs by making small stacked ones ergonomic. Stage and CodeRabbit add AI explanation on top of the diff. Pyor uses AI to triage the diff (group files by complexity, one-line group labels, steering hints) on a fast navigable surface, without generating prose you must read. Teams that can adopt stacking should; reviewers who still face big diffs need a better surface for them.

Can I try these without asking my whole team?

Mostly yes. Graphite, Stage, and Pyor all work for an individual reviewer on existing GitHub PRs without requiring teammates to change workflow. AI reviewer bots like CodeRabbit are repo-level: they post comments everyone sees, so that one is a team decision.

Reviewing AI-Generated Code: A Practical Checklist

Othman Shareef — Tue, 16 Jun 2026 08:00:00 +0000

Most working developers now have an AI assistant in the loop: Stack Overflow’s 2024 survey put it at three-quarters of respondents using or planning to use AI tools. That means most code review is now, at least partly, review of generated code. The awkward truth: generated code doesn’t fail the way human code fails, and a checklist tuned for human failure modes will miss it.

The checklist:

Intent match: does it solve the actual ticket, or a plausible nearby problem?

Hallucination scan: do all APIs, options, and imports actually exist?

Edge honesty: error paths, empty states, concurrency. Generated code loves the happy path.

Test the tests: do they assert requirements, or just mirror the implementation?

Codebase fit: does it duplicate an existing helper or invent a new pattern?

Security surface: injected strings, permissive defaults, secrets handling.

Provenance: did a human read this before requesting review?

1. Intent match comes first

The signature failure of generated code is being a correct answer to a slightly different question. It compiles, it’s idiomatic, the tests pass, and yet it implements a subtly different behavior than the issue asked for, because the prompt (or the model’s reading of the codebase) drifted. Before reading any implementation, re-read the requirement, then check the change’s observable behavior against it. Everything else on this list is cheaper to check than this, which is exactly why it gets skipped.

2. Verify that everything it calls exists

Models still invent: a config option that was never real, a method from a different library’s API, an import that resolves only in the model’s memory of an older version. Types and CI catch most of it. The dangerous remainder is the call that exists but does something different than the generated comment claims. If a usage looks unfamiliar, check the docs, not the comment above it.

3. Audit the edges, not the middle

Generated code is strongest on the happy path, because that’s where the training data lives. Spend your attention where it’s weakest: error handling that swallows instead of propagating, empty and null inputs, timeouts, partial failures, and any shared state. A quick heuristic: find every catch and every default value, and ask whether a human with context would have chosen it.

4. Test the tests

When the same model writes the code and its tests, the tests often assert what the code does, not what it should do: a tautology with good coverage numbers. Read the assertions against the requirement. The tell: tests with exact-value assertions copied from implementation output, and no test for the case the ticket was actually about.

5. Check codebase fit

Generators reach for the median solution from everywhere, not your conventions. Watch for re-implemented helpers that already exist, a third state-management pattern, or styles that fight the file around them. Industry analyses such as GitClear’s code-quality reports have flagged rising duplication and churn alongside AI adoption. Review is where that trend gets stopped, one duplicate helper at a time.

6. Sweep the security surface

Generated code inherits the average security posture of its training data, which is not a compliment. String-built SQL or shell commands, permissive CORS, broad IAM defaults, tokens logged “temporarily”. None of these are exotic; all of them show up in generated diffs regularly. If the change touches input handling, auth, or anything that executes, slow down there.

7. Ask whether a human read it first

The cheapest quality gate for generated code is upstream of review: the author reading their own diff before requesting eyes. Teams adopting agents are formalizing this as pre-PR review: reading the agent’s work on your own branch before it becomes a pull request. It’s a workflow we believe in enough to have built into Pyor (our product, free for individuals): review the agent’s diff locally, leave notes, land a cleaner PR. Your reviewers get changes a human has already vouched for, and this checklist gets shorter every time.

For the size dimension of the same problem (agents make big diffs cheap), see how big should a pull request be?

Frequently asked questions

Should AI-generated code be labeled in pull requests?

It helps. Knowing a change was largely generated tells the reviewer which failure modes to prioritize: plausible-but-wrong logic, invented APIs, tests that assert the implementation rather than the requirement. Many teams add a simple description field for it.

Can I use an AI to review AI-generated code?

As a first pass, yes. AI reviewers are decent at mechanical issues and obvious bugs, and they’re cheap. But they share blind spots with the generator and don’t know your intent. Use them to clear noise before human review, not to replace it.

Is AI-generated code lower quality than human code?

It’s differently distributed. Generated code is often locally clean and idiomatic while being wrong about intent or context. Industry analyses (e.g. GitClear’s year-over-year reports) have flagged rising code churn and duplication alongside AI adoption, signals worth watching in your own repo rather than taking on faith.

How Big Should a Pull Request Be?

Othman Shareef — Sun, 14 Jun 2026 08:00:00 +0000

Every team eventually argues about this number. Here’s the honest version: the research points to a range, not a magic value, and the range is smaller than most teams’ habits.

The short answer: Aim for under ~400 changed lines of code per pull request, and treat smaller as better. SmartBear’s study of peer review at Cisco found defect-detection ability drops beyond roughly 400 lines, and Google’s engineering practices push for small changes as the default. Count only lines a human must understand, lockfiles and generated code aside.

Where the ~400-line figure comes from

The most-cited data point in this debate comes from a large study of peer review at Cisco, popularized by SmartBear: reviewers’ ability to find defects degrades as the change grows, with ~400 lines as the practical ceiling and ~200 as the comfortable middle. It’s old data, gathered on human-written code, but nothing about human working memory has improved since, and it matches what reviewers feel: past a few hundred lines, you stop reviewing and start skimming.

Google’s public review guidance arrives at the same place from experience rather than measurement: small changelists get reviewed faster and more thoroughly, are less likely to import bugs, and are easier to roll back. Their reviewer docs treat “can this be split?” as a standard first question.

Why size matters more than ever

AI assistants lowered the cost of producing lines dramatically. In a controlled GitHub experiment, developers with Copilot finished a task 55% faster than the control group. Nothing comparable happened to the cost of understanding lines. When authoring accelerates and review doesn’t, PR size is the valve where the pressure shows up. Holding the size line is how a team keeps review quality while adopting AI tooling.

When it’s fine to break the rule

Mechanical bulk: renames, formatting, codemods, lockfiles, generated artifacts. Reviewers verify legitimacy, not logic, so flag these in the description.
Migrations and schema changes that lose meaning when fragmented.
Coherence beats arithmetic: a 600-line change with one clear idea reviews better than five 120-line fragments nobody can evaluate alone.

The test isn’t the line count; it’s whether a reviewer can hold the idea of the change in their head. Size is a proxy: a good one, but a proxy.

How to split a PR that grew

Refactor first, behavior second. The classic two-PR split: a no-behavior-change refactor that makes the feature diff small, then the feature.
Slice vertically. One thin end-to-end path first (schema → API → UI for one case), then the variations.
Land the leaves. Utilities, types, and tests that stand alone can merge ahead of the trunk change that uses them.

And when the big PR ships anyway

It will; agents are prolific and deadlines are real. For the review side of that problem, we wrote a separate field guide: how to review large pull requests. And if the bottleneck is the review surface itself, that’s the problem Pyor exists to fix: triage-first file rail, folder-level viewed tracking, and a diff that keeps your place at any size. (Our product; free for individuals.)

Frequently asked questions

Is there an official maximum PR size?

No standard body defines one. The most-cited guidance comes from SmartBear’s study of peer review at Cisco (keep reviews under ~400 lines) and Google’s engineering practices (small changes, reviewed quickly). Treat 400 changed lines as a soft ceiling, not a law.

Do generated files and lockfiles count toward PR size?

Practically, no. Reviewers scan them for legitimacy rather than reading them. What matters is the number of lines a human must actually understand. A 2,000-line PR that is 1,800 lines of lockfile is a small PR wearing a big coat.

My AI assistant produces large changes. Should I force-split everything?

Split when there is a real seam (refactor vs. behavior change, layer by layer). Don’t manufacture artificial fragments that can’t be understood alone; a coherent 600-line change can beat five incoherent 120-line ones. When a large PR is unavoidable, review it with triage and passes instead.

How to Review Large Pull Requests (Without Losing Your Mind)

Othman Shareef — Fri, 12 Jun 2026 08:00:00 +0000

The 2,000-line PR is in your queue. You didn’t write it, you can’t hold it in your head, and “LGTM” is starting to look morally acceptable. It isn’t, but neither is pretending you’ll read forty files with equal care. Here’s the method we use to review large pull requests properly: triage, passes, and keeping your place.

The method in brief:

Read the description and commits first. Never start at file one.

Triage: sort files into core logic, supporting changes, and mechanical noise.

Review the core deeply, in passes (correctness → design → style).

Mark files as viewed as you go; protect your place.

Timebox sessions (~1 hour) and split the review across them.

Say what you reviewed deeply and what you skimmed.

Step 1: Don’t start at file one

The diff is ordered alphabetically; your understanding shouldn’t be. Read the PR description, then the commit list; commits often reveal the change’s real structure (“refactor first, then feature”) even when the description doesn’t. If the description is missing the why, ask for it before you read a single hunk. That’s not pedantry; it’s the cheapest possible round-trip, and it improves every minute you spend afterward.

Step 2: Triage the files and find the three that matter

In almost every large PR, a minority of files carry the actual decision-making. Sort the file list into three buckets before reading anything closely:

Core: new logic, changed behavior, anything touching state, money, auth, or concurrency. This is where your attention goes.
Supporting: call-site updates, types, wiring. Scan for surprises, not for line-by-line correctness.
Mechanical: lockfiles, generated code, renames, formatting. Verify they are what they claim (a “rename-only” file with a logic edit hiding inside is a classic), then move on.

Tests deserve a special mention: read them early, not last. Good tests are the best description of intended behavior you’ll get; missing tests for the risky path tell you exactly where to look hardest.

Step 3: Review in passes, not in one sweep

Trying to judge correctness, design, and style simultaneously is how reviewers burn out and miss things. Make separate passes over the core bucket:

Correctness: does it do what it says? Edge cases, error paths, off-by-ones, assumptions that don’t survive concurrency.
Design: is this the right shape? Will the next person extend it or fight it?
Style and nits: last, quickly, and labeled as non-blocking. The Conventional Comments convention (nit:, question:, issue:) keeps these from reading like blockers.

Step 4: Protect your place

Large-diff review fails as much from lost state as from lost attention. Mark files as viewed the moment you finish them. If your tool can mark whole folders viewed, use it to clear the mechanical bucket in one stroke. If you get interrupted (you will), the viewed markers are what makes resuming cost seconds instead of minutes.

Step 5: Timebox, then come back

SmartBear’s peer-review research puts the practical limits at roughly 60-minute sessions and no more than ~500 lines per hour. Past that, defect detection falls off. For a genuinely big PR that means the review is designed to span sessions. Plan it that way instead of discovering it at minute ninety.

Step 6: Report honestly

End with a review summary that says what you actually did: “Read auth flow and migration deeply; scanned call-site updates; trusted generated files.” It calibrates the author’s confidence, tells co-reviewers where to spend their attention, and keeps “approved” meaning something.

Where tooling earns its keep

Everything above works in any tool, and is less painful in a surface built for it. This is the use case we designed Pyor around: a file rail you can triage and group, folder-level viewed marking, inline threads that stay put, and a focus mode that collapses everything but the code. Full disclosure: we make it, and it’s free for individuals. If your method survives a 2,000-line PR but your tab doesn’t, that’s the gap it fills. For why PRs got this hard in the first place, see our earlier piece on the review bottleneck.

Frequently asked questions

Should I just ask the author to split a large PR?

Often yes: splitting is the best outcome when the PR mixes concerns. But ask early (before reviewing in depth), be specific about the seam, and accept that some changes (migrations, generated code, mechanical renames) are legitimately large and better reviewed with triage than split artificially.

How long should a review session be?

SmartBear’s peer-review research recommends sessions of about 60 minutes and not reviewing faster than ~500 lines per hour. For a genuinely large PR, plan multiple short sessions rather than one heroic one; defect detection drops sharply as fatigue sets in.

Is it okay to approve a large PR without reading every line?

Be honest about what you reviewed. Triage means most attention goes to high-risk files, while mechanical changes get a lighter scan, and that is legitimate. Approving code nobody read is not. Say in your review what you covered deeply and what you skimmed.

Why Are Pull Requests So Hard to Review?

Othman Shareef — Wed, 10 Jun 2026 08:00:00 +0000

Every engineering team we talk to has the same queue: code that’s written, tested, and ready, waiting on review. The author moved on hours ago. The reviewer is dreading the tab. Why is reviewing a pull request so much harder than writing one?

It wasn’t always. For most of software’s history the economics ran the other way: writing code was the slow, expensive part (hours or days of design, typing, and debugging per change), and reviewing that change was the comparatively quick read at the end. AI inverted the ratio. Code is now cheap to produce in volume, and on many teams reviewing a change takes longer than writing it did. The bottleneck moved from authoring to review, while our habits and tools are still built for the old ratio.

The short answer: Pull requests are hard to review for four compounding reasons: reading code is cognitively harder than writing it, diffs are too large to hold in your head, the “why” is missing from most PRs, and the review surface itself (a browser tab built for hosting code, not understanding change) fights you on all three.

Reading code is harder than writing it

When you write code, you build the mental model first and the code falls out of it. When you review code, you’re handed the output and asked to reconstruct the model in reverse. Microsoft Research’s study of code review at scale, Expectations, Outcomes, and Challenges of Modern Code Review, found exactly this: the number-one challenge reviewers report isn’t finding defects; it’s understanding the change in the first place.

That asymmetry is the root of everything else. A reviewer doing the job properly is doing archaeology: why this file, why this approach, what else does this touch? Every missing piece of context turns into either a round-trip question or a shrug-and-approve.

Diffs outgrew our working memory

Review effectiveness falls off a cliff with size. SmartBear’s analysis of peer review (drawn from a large study at Cisco) recommends keeping reviews under roughly 400 lines of code. Beyond that, the ability to find defects drops measurably. Google’s engineering practices push the same direction: small changes get reviewed faster, more thoroughly, and with less back-and-forth.

Meanwhile real-world PRs are heading the other way. AI assistants make it cheap to generate four hundred lines before lunch, and refactors ride along with features because splitting feels like overhead. The result: a forty-file diff where three files carry the actual change, and the reviewer has to find them by scrolling.

The “why” never made it into the PR

Most PR descriptions describe the what (“Add retry logic to sync”), not the why (“Sync fails on flaky hotel wi-fi; we retry 3× with backoff; the risky part is the idempotency assumption in applyBatch”). Without the why, a reviewer either reconstructs it from the diff (slow) or reviews superficially. Neither is the reviewer’s fault: nothing in the default workflow demands that context exist.

The review surface fights you

Here’s the part we think gets too little blame: the place where review happens. The standard web diff was designed for hosting and browsing code, and it shows. Files collapse and lose your place. There’s no triage: file one and file forty get equal billing. Comments vanish into resolved threads. Forty open tabs later, the review “session” is really an exercise in remembering where you were.

None of these is fatal alone. Together they tax exactly the thing review depends on: sustained attention on an unfamiliar change.

What actually helps

Smaller PRs, enforced socially or by tooling. The single highest-leverage change, per both Google and the Cisco data above.
Authors review first. A self-review pass catches the cheap stuff before it costs a reviewer’s attention, and writing the “why” down halves the archaeology.
A review surface built for understanding. Triage the files that matter, keep your place, see every thread in context, and run the whole read-comment-approve-merge loop without losing state between tabs.

That last one is the bet we’re making with Pyor: a review app where the diff, the conversation, and the merge live in one window, and your code never leaves your machine. We built it because we were the reviewer dreading the tab. (Yes, that’s a product plug. It’s also the reason this blog exists, so we’d rather say it plainly.)

Frequently asked questions

Why do pull requests sit unreviewed for days?

Mostly because reviewing feels expensive: large diffs, missing context, and notification noise push reviewers to defer. Reducing PR size and giving reviewers a faster surface for understanding the change shortens the queue more than reminders do.

Is AI-generated code making review harder?

It shifts the bottleneck. AI assistants speed up authoring, so more code arrives per reviewer-hour, and diffs trend larger. The review side (human understanding) has not sped up to match.