# PR fatigue, in numbers: when writing outpaces review

Monday morning, nine pull requests are waiting on you. Six were opened by agents over the weekend. Each one is plausible, each one passes CI, and each one asks for the same thing: that a person read it and say yes.

You approve the small ones on sight, leave the big one for later, and by Thursday there are fourteen. That is PR fatigue. It is not laziness, and it is not a tooling bug. It is what happens when the cost of writing a change falls and the cost of reading one does not.

Logposa started from this problem. Here is the case in numbers.

How much a reviewer can actually read

One often-cited industrial dataset is SmartBear’s study of a Cisco Systems team: 2,500 reviews covering 3.2 million lines of code. Its guidance is about one review session, in that setting:

• 200 to 400 lines at a time. Past about 400 lines, the ability to find defects drops.
• Under 60 minutes per session, never more than 90. After that, detection falls sharply.
• Under 500 lines an hour. SmartBear reports better detection at slower rates, especially below 300 lines an hour.

SmartBear estimates 70 to 90 percent defect discovery for reviews of that size and duration. That is a result from its study, not a universal target for every repository or a hard ceiling for every pull request.

What review looked like when it worked

Google’s 2018 study of its own code review is a good picture of a healthy system. It covers 9 million reviewed changes and found:

• the median change modifies 24 lines, and about 90% touch fewer than 10 files;
• the median time for the whole review is under 4 hours;
• developers spend about 3.2 hours a week reviewing (median 2.6).

In the same paper, earlier studies reported median times to approval of 14.7 to 24 hours at other companies. Small changes likely helped Google review quickly; the authors also point to review culture and the number of reviewers.

Put the two studies together for an illustrative budget. At 400 lines an hour and 3.2 hours a week, one engineer could inspect about 1,300 lines a week. The inputs come from different organizations and methods, so this is not a measured capacity or a recommended quota. It shows how quickly a queue can grow when the amount to inspect rises and review time does not.

What changed with AI adoption

Faros AI’s AI Productivity Paradox Report 2025 measured more than 10,000 developers across 1,255 teams. On teams with high AI adoption:

Metric	Change
Tasks completed	+21%
Pull requests merged	+98%
Average pull request size	+154%
Review time per pull request	+91%
Bugs per developer	+9%

Look at the direction of each line. More pull requests were merged, their average size increased, and review time per pull request rose too. At the company level, Faros found no significant correlation between AI adoption and better outcomes. These are associations across the teams it studied; they do not show that every additional pull request was written by an agent.

Google’s DORA research reported a related association in 2024. A 25% increase in AI adoption was associated with an estimated 7.2% decrease in delivery stability and 1.5% decrease in delivery throughput, alongside a 3.1% increase in code review speed. The report points to small batches and robust testing as practices that matter when adopting AI; it does not establish that AI adoption alone caused those delivery changes.

As a thought experiment, if a team reviewed twice as many pull requests and each contained two and a half times as many lines, the total lines presented for review would rise roughly fivefold (1.98 × 2.54 ≈ 5). That is not a measured change in reading demand: some lines are generated, deleted, or revisited, and the Faros figures describe merged pull requests rather than every review attempt. It does illustrate why a growing queue can feel nonlinear.

What fatigue does to a team

When the queue is longer than the budget, the review still happens, but it changes shape:

1. Shallow reviews. An approval may come with little visible explanation. An empty comment alone cannot tell us how carefully the reviewer read.
2. Latency. Pull requests wait days and drift from main, so rebasing them becomes another thing to review.
3. Batching. Authors, human or agent, stop splitting changes, because every pull request pays the waiting cost. Changes get bigger, and review gets worse again.
4. Quiet risk. A rushed review may miss a defect. DORA’s stability result raises concern about delivery outcomes, but it does not identify which defects a code reviewer could have caught.

Why an AI reviewer alone is not the fix

Another model can help find bugs or direct attention to a risky part of the change. Its comments still need triage, and they leave the question of who is accountable for the yes? A tool can inform the decision. A person remains responsible for allowing the change into a system others depend on.

The limited resource is not review comments. It is a person’s attention, and the decision that only a person should make. So the useful question is not “how do we review more?” but “how do we make each review cost less to read, without taking the decision away from a person?”

What lowers the cost of reading

This is what we are building Logposa around:

• Read change sets, not piles of diffs. Nine pull requests that make one change across three repositories are one decision. Group them, and review the story instead of the fragments.
• Filter by relevance to you. Some pull requests are outside your area of responsibility. A tool that reads the forge with your permissions can set those aside, openly and reversibly, and bring forward the ones that need your attention.
• The machine proposes, the person affirms. Algorithms detect the groupings and links, and a person confirms them. Nothing becomes a decision because a model was confident.
• Never the approver. An assistant can act for you in your own space and propose for everyone else, but the approval always belongs to a person who is not the requester.

The aim is to make each review easier to understand while keeping the human decision and its evidence visible.

Five metrics to measure your own fatigue

You don’t need a vendor to see whether review pressure is growing. Track these over comparable time windows:

1. Pull request size distribution. Track the median and upper quartile of lines requiring human inspection. Compare them cautiously with SmartBear’s 200–400 lines per session; separate generated code and large deletions.
2. Median time to first submitted review. The time from opening the pull request to a submitted review, not the first time someone opens the page. It makes part of the queue visible.
3. Approved without a review body. The share of approved pull requests whose submitted reviews have no written body. This is a prompt to inspect review practice, not proof of rubber-stamping; inline and other comments can still carry substantial feedback.
4. Review load per reviewer. Lines waiting on each person per week, interpreted alongside the time your team actually makes available for review, rather than treating the illustrative 1,300 lines as a quota.
5. Agent share. The fraction of pull requests opened by agents. It gives context for the other measures; a higher share alone does not predict review quality or delivery outcomes.

A quick sample of the first three is possible with the GitHub CLI and jq:

gh pr list --repo OWNER/REPO --state merged --limit 200 \
  --json createdAt,additions,deletions,reviews |
jq '
  def median:
    sort | if length == 0 then null
    else (.[(length - 1) / 2 | floor] + .[length / 2 | floor]) / 2 end;
  def p75:
    sort | if length == 0 then null
    else .[((length * 0.75 | ceil) - 1)] end;
  map(.reviews |= map(select(.submittedAt != null))) as $prs
  | [ $prs[] | select(.reviews | length > 0) ] as $reviewed
  | [ $prs[] | select(any(.reviews[]; .state == "APPROVED")) ] as $approved
  | {
      sampled_merged_prs: ($prs | length),
      reviewed_prs: ($reviewed | length),
      median_pr_lines_changed:
        ($reviewed | map(.additions + .deletions) | median),
      p75_pr_lines_changed:
        ($reviewed | map(.additions + .deletions) | p75),
      median_hours_to_first_review:
        ($reviewed | map((([.reviews[].submittedAt | fromdateiso8601] | min)
                          - (.createdAt | fromdateiso8601)) / 3600) | median),
      approved_without_review_body_pct:
        (if ($approved | length) == 0 then null else
          100 * ([ $approved[]
                   | select(all(.reviews[];
                       ((.body // "") | gsub("\\s"; "") | length) == 0)) ]
                 | length) / ($approved | length)
        end)
    }'

This samples up to 200 merged pull requests returned by GitHub, not a fixed month or the full review history. additions + deletions is a rough size measure; the last field reads review bodies but not inline or issue comments. For a team metric, use a fixed date window, include all pull requests in it, and inspect the distributions and exceptions before drawing conclusions.

Sources

• Faros AI, The AI Productivity Paradox Report 2025 (July 2025): 10,000+ developers, 1,255 teams.
• Google Cloud, 2024 Accelerate State of DevOps (DORA) Report.
• Sadowski et al., Modern Code Review: A Case Study at Google, ICSE-SEIP 2018.
• SmartBear, Best Practices for Code Review and What is Code Review?.