PR Review Time Jumped 91%. Stop Sourcing Coders. Source Reviewers.

METR's February 2026 update to its July 2025 RCT quietly closed the "AI makes engineers slower" debate: selection effects made the original −19% finding a lower bound, and AI likely does deliver gains in early 2026. The uncomfortable second-order effect is what Faros AI measured across 10,000+ developers: pull request review time is up 91%. If you are still writing 2026 reqs for "senior IC who ships features," you are hiring against last year's bottleneck.

The 91% number, and why it broke your hiring plan

The binding constraint on engineering throughput in 2026 is senior reviewer capacity, not typing speed, because AI adoption roughly doubled PR volume while review time nearly doubled too. Faros AI's study of more than 10,000 developers across 1,255 teams found AI use correlated with 21% more tasks completed and 98% more pull requests merged, with no significant correlation to company-level improvement, and PR review time up 91%.

That is the sourcing headline. The mechanism is worse than the headline:

• PR size is up 154% (Faros AI), so each review is not just more frequent, it is bigger.
• AI-assisted code introduces 1.7x more bugs than human-written code (CodeRabbit, December 2025).
• Refactoring declined 60% in codebases with heavy AI adoption (GitClear), which means more novel code and less maintenance code, so reviewers are reading cold context more often.
• At 92.6% monthly AI adoption and roughly 27% of production code AI-generated, organizational throughput has not moved past 10% (Amdahl's Law: writing code is 25 to 35% of the total cycle).

91%

The naive response is "hire more ICs to absorb the review load." That fails on arithmetic. Reviews escalate to Staff and Principal engineers, not to the same juniors producing the PRs. You do not need more writers. You need more approvers.

Why "one more IC" is the wrong 2026 req

Adding a mid-level IC to a team whose bottleneck is Staff-level review capacity makes the queue longer, not shorter, because every new IC is a net producer of PRs that only senior engineers can safely approve. This is the "productive senior IC" signal inverting in real time.

Two data points make this concrete:

1. Junior developers on simple, unfamiliar tasks show 26 to 56% gains from AI tools. Senior developers on complex legacy codebases show near-zero or negative gains in the available evidence.
2. Cursor CEO Michael Truell has publicly noted that Cursor made writing production code much faster, but for most engineering teams reviewing code looks the same as it did three years ago. Cursor then acquired Graphite, a code review startup.

That acquisition is the loudest market signal of the year. When the company that sells the authoring tool buys the review tool, the next platform layer is review.

When the vendor selling you the firehose buys a bucket company, the bottleneck has already moved.

The hiring translation is direct. Route the budget for your next IC hire into one Staff-level reviewer, plus the review tooling that senior engineer will actually use. You will clear more PRs per week than the IC would have written.

The pool is smaller than you think

The addressable US pool of Staff and Principal engineers is about 50,076 people, and only ~1,160 of them self-identify code review as a first-class skill. That is roughly 2.3% of the senior pool, and it is the shortlist to attack first.

Here is the shape of the market, straight from Refolk's index of professional profiles:

Two things about that 1,160 number. First, it is a floor, not a ceiling: many strong reviewers do not list "Code Review" as a discrete skill because they consider it table stakes. Second, it means you cannot out-recruit this problem. Even if every reviewer in the country opened their inbox to you tomorrow, the supply is roughly 1,160 people. You have to identify reviewers from behavior, not resumes.

That behavior lives on GitHub, and describing what you want in plain English is the fastest way to surface it. Refolk indexes GitHub, LinkedIn, and the open web together, so you can ask for "Staff engineers who have left more than 200 substantive PR review comments on Go or Rust repos in the last 12 months" and get a ranked shortlist instead of a title search.

The GitHub signals that actually predict a good reviewer

A good reviewer is identifiable from four GitHub signals: approval volume, comment-to-approval ratio, review latency, and cross-file diff depth. Commit count is not on that list, and neither is stars.

Use these signals in this order:

1. Approvals given, not commits authored. Filter for accounts with a sustained ratio of reviews-submitted to PRs-authored above 1.0 over the last 12 months. This finds people whose team already routes review load to them.
2. Comment density per review. A reviewer leaving 4+ inline comments per approved PR is doing structural review, not rubber-stamping. Below 1 comment per approval is a rubber-stamper, which is exactly what you do not want scaling AI-generated code.
3. Review latency under 24 hours on active repos. Fast reviewers unblock queues. Slow reviewers are the queue.
4. Cross-file diff engagement. Look at whether their review comments span multiple files in the diff, not just the file they touched last. This is the "system-level judgment" proxy that matters for AI code, where you are evaluating decisions across dozens of choice points nobody discussed with the model.
5. Resistance-to-AI in a brownfield codebase. Counter-intuitive but real: engineers who have not adopted AI heavily in legacy code often have the taste you need to review AI code. The productive-senior-IC signal inverted; treat it that way.

The mechanism behind signal 5 is worth pausing on. Reviewing AI-generated code is fundamentally different from reviewing a colleague's code. You are not checking whether a teammate implemented the approach you discussed in standup. You are evaluating whether an external system made reasonable choices across decisions you were never in the room for. That takes taste and architectural memory, not language fluency. Engineers who instinctively slow down in complex legacy code tend to have both.

Where the reviewers already work

The Staff and Principal cohort with explicit code-review positioning clusters at a small set of employers that have publicly invested in engineering quality. In Refolk's index, the names that surface repeatedly are Opendoor, Omada Health, Confluent, Cloudflare, Shopify, NVIDIA, Apple, Trustpilot, Checkout.com, and Samsara.

Two patterns are worth naming:

• US density is at infra and platform companies. Confluent, Cloudflare, NVIDIA, and Shopify all ship code where a bad review has real blast radius (data corruption, edge outages, driver regressions, merchant downtime). That selects for reviewers with system-level judgment, which is the exact taste AI code review needs.
• London is the second market, not the third. The UK Staff and Principal pool is 13,761, roughly 27% of the US at a 3.64x supply ratio, and it is concentrated in London. Checkout.com, Trustpilot, and Samsara's London offices are dense with senior reviewers who have shipped against payments, review-heavy content, and IoT firmware respectively.

If you are running a US-only sourcing process in 2026, you are ignoring a market that is a quarter the size of yours.

A concrete 2026 sourcing playbook

Reallocate one open IC req into a Staff-level reviewer req, source it from GitHub review behavior, and give the hire tooling budget on day one. That is the playbook. The steps:

1. Rewrite the rubric. Drop "ships features" language. Add "reduces median PR review latency" and "raises comment density on high-blast-radius diffs" as the success metrics.
2. Build the shortlist from behavior, not titles. Query GitHub for approval volume, comment density, and cross-file engagement on repos in your stack. This is where Refolk's plain-English sourcing across GitHub and LinkedIn earns its keep: title-based LinkedIn searches will miss the ~97.7% of senior engineers who do not list "Code Review" as a skill.
3. Prioritize the 1,160 US self-identifiers first, then expand. The self-identifiers convert faster because they already frame their work this way. After that, expand into the ~50,000 broader Staff/Principal pool using the GitHub signals above.
4. Interview for taste, not fluency. Give candidates a real AI-generated PR from your codebase and ask what they would push back on. Fluent language answers are noise. "This function should not exist" is signal.
5. Fund tooling on day one. Graphite, CodeRabbit, or equivalent. A Staff reviewer without review tooling is an expensive linter.
6. Include London. Post the same req against the UK pool. Expect roughly a quarter the volume.

If you do this, one Staff reviewer hire clears more weekly PR throughput than two additional mid-level ICs would have added. That is the arithmetic the 91% number forces.

FAQ

Is the 91% PR review time increase specific to AI-heavy teams or industry-wide?

It comes from Faros AI's analysis of 10,000+ developers across 1,255 teams and correlates with AI adoption specifically, not general team growth. The mechanism is PR volume up 98% and PR size up 154% under AI, which mechanically lengthens each review and multiplies the number of reviews. Teams with low AI adoption do not show the same review-time inflation, so if your organization is at the 92.6% monthly adoption rate the research cites, you should expect to see the effect.

How do I identify a "reviewer" on GitHub if they do not list it as a skill?

Look at behavior in the last 12 months, not profile self-description. The strongest single signal is a reviews-submitted to PRs-authored ratio above 1.0, combined with 4+ inline comments per approved PR. Cross-file comment engagement and review latency under 24 hours are strong secondary signals. Only about 2.3% of US Staff and Principal engineers explicitly list "Code Review" as a skill in Refolk's index, so behavior-based sourcing across GitHub is the only way to reach the other ~97.7%.

Should I stop hiring ICs entirely?

No, but you should reprice them against the review bottleneck. Every new IC generates PRs that only senior engineers can safely approve, so adding ICs without adding reviewer capacity makes the queue longer. A useful rule for 2026: for every two IC hires, add one Staff-level reviewer, and fund review tooling (Graphite, CodeRabbit, or similar) for the team on the same day the reviewer starts.

Is the London pool actually a substitute for US Staff engineers?

For review work specifically, yes, more than for greenfield authoring work. The UK Staff and Principal pool is 13,761, concentrated in London, with density at Checkout.com, Trustpilot, and Samsara. Payments, content platforms, and IoT firmware all select for the system-level judgment that AI code review requires. If your review work can happen async, London is a serious second market.