Code Review Became Sampling and Nobody Wrote It Down

Linear's data shows agent-connected teams tripled their weekly pull requests in two years. Headcount didn't triple. Here's how to decide what still gets read.

Twenty-one pull requests a week, then sixty-five. That's the two-year arc for teams that connected a coding agent, according to Linear's first "How teams build" report, published August 18 by head of data Tim Qi. Teams without an agent went from eight to ten over the same window.

Now hold that number next to a second one from the same report: nothing shrank. Time spent creating and triaging issues went up. Time spent commenting went up. Planning time held flat. Chatting with AI and delegating to agents appeared as entirely new minutes on top of the old ones. Linear's own closing note says total time on product development is rising, not falling, and floats Jevons paradox as the explanation.

So the diffs tripled and the hours went up and the people stayed the same people. Something in that equation had to give, and it wasn't the pull request count.

It was reading.

The transition nobody announced

Every engineering organization I've talked to this year still uses the phrase "code review" the way it used the phrase in 2022. Two approvals. A required reviewer on the CODEOWNERS line. A merge gate that says a human looked.

At sixty-five pull requests a week per team, a human did not look at sixty-five pull requests a week. Some of them got a scroll and a thumbs up. Some got the CI badge treated as the review. Some got read carefully because the reviewer happened to care about that file. That last category is a sample, and right now it's an accidental one, selected by whoever had time on Thursday afternoon.

I want to be careful here, because Linear did not measure this. Linear measured volume. It counted pull requests opened, not merged, and only in repositories connected to Linear. The read-rate claim is mine, and it's an inference from arithmetic rather than a finding. But it's arithmetic that's hard to argue with. Reviewer capacity is roughly a constant. The thing being reviewed tripled. The ratio moved.

The interesting part is that a sampling regime isn't automatically worse than a review regime. Aviation, manufacturing, and financial audit all run on sampling, and they run on it deliberately, with a documented policy about what gets a full inspection and what gets spot-checked and what gets a machine gate. Software teams have arrived at sampling by accident and are still describing it as review. That gap between the practice and the description is where the failures will live.

What the rest of the numbers say about who's writing

The volume story gets more pointed when you look at who's opening these PRs.

Linear reports the share of product managers who attached a pull request in the last thirty days rose from 3% to 10% between June 2024 and June 2026. Designers went from 1% to 8%. Engineers went from 20% to 34%. Those are floors, since PRs outside Linear-connected repos don't count.

And issue creation crossed a line most people missed. Two years ago fewer than one issue in a thousand in Linear came from AI. Linear's own summary now reads: teams use AI to write just under half of everything created in the tool, and at the current pace it will soon author more than people and integrations combined. The underlying weekly series puts the two lines within about two percent of each other by early August 2026, with the agent line the one still climbing.

Put those together and the reviewer's job changed shape. It used to mean checking a colleague's work against shared context you both had. Now a meaningful slice of incoming diffs come from a designer prompting an agent against a codebase neither of them has read. The reviewer is not verifying a peer's judgment. The reviewer is the first human in the loop.

That's a different job, and it deserves a different allocation of attention than "everybody reviews everything, sort of."

Put this into practice: write the sampling policy down

The lowest-friction move here costs one afternoon and produces one document. You are already sampling. Write down which sample.

Step one: name the always-read set. Pick the file paths and change types where a bad merge is expensive and hard to reverse. My list, in rough order of how much sleep it has cost me: authentication and session handling, anything touching money or billing, database migrations, deletion paths, secrets and credential handling, new third-party dependencies, and CI configuration. In GitHub that is a CODEOWNERS file plus a required-reviewers branch rule, and it takes about twenty minutes. In GitLab it's a CODEOWNERS plus approval rules. Every PR that touches those paths gets a real human read, no exceptions, no matter how many are in flight.

Step two: name the machine-gated set. Everything else gets automated gates that actually block: type checks, tests with a coverage floor on changed lines, lint, static analysis, and a secret scanner. The gate is the review for this tier, and you should say so out loud rather than pretending a human also read it. If you want an AI reviewer in this tier, fine, but treat its approval as a lint pass, not as a second opinion.

Step three: pick a real spot-check rate and put it on a calendar slot. Ten percent of merged PRs, sampled randomly, read properly by a human within a week of merge. Not to gate anything. To find out what your gates are missing. If the spot-check keeps turning up nothing, lower the rate. If it turns up something ugly twice in a row, the always-read list is too short and you just learned which line to add.

Step four: make the agent write the risk note. Add a line to your agent's instructions requiring every PR body to answer one question in plain language: what breaks if this change is wrong, and how would we notice? An agent that cannot answer that question for its own diff has told you something useful. This is the single highest-value change on the list and it costs one sentence in a prompt file.

Step five: cap concurrency. Limit how many agent PRs can be open against one repository at once. Six is a number I've seen work; the right number is whatever your always-read tier can absorb without the reviewer skimming. A queue is a feature. Unbounded parallel agent output is how the sample rate goes to zero without anyone deciding it should.

Start with step four if you only do one. It's a prompt edit.

Where this argument is weak

Linear sells agent features. The report is aggregated product data from one vendor's paid customer base, and the vendor benefits if agents look productive. That doesn't make the numbers wrong, and the methodology section is franker than most vendor research I read, but it belongs at the front of your mind rather than the back.

The cohorts were never comparable, and the report says so while the marketing around it does not. Agent teams were already opening 21 PRs a week in June 2024 while non-agent teams opened 8, so these two groups differed by roughly 2.6x before any coding agent existed. Linear's chart note asks you to read each cohort against its own baseline. Divide the June 2026 endpoints instead and you get 65 over 10, which is the tidy 6.5x figure that travels well in a headline and that the report's own methodology note does not support. Read the caveat, not the ratio.

Pull requests opened is a motion metric, not a value metric. Linear says so in the closing note. A PR that renames a variable counts the same as one that fixes a data-loss bug. The report also can't see merge rates, revert rates, or incidents, which are the numbers that would actually tell us whether the sampling transition is going badly.

And my central claim is unmeasured. I'm asserting that human read-rate per PR fell because volume rose and headcount didn't. I have no dataset for reviewer attention. If your team tripled reviewers alongside the agents, this article isn't about you. Most teams didn't.

One more honest note: sampling might be correct. If agent output has a lower defect rate than junior human output on routine changes, then reading a fixed random slice plus everything dangerous is a better use of senior attention than reading all of it badly. I suspect that's true for a lot of changes. I have no evidence for it, and neither does anyone selling you a review tool.

What to do this week

Pull your own number first. Count pull requests opened per week against your main repository for June 2024, June 2025, and last month. Then count the humans who merged something in each of those months. The ratio between those two lines is your review-to-sampling curve, and it takes about ten minutes with the GitHub API to draw.

If the curve looks like Linear's, you're sampling. You get to choose whether the sample is your always-read list or whoever felt like reading a diff on Thursday.

That's the whole decision, and it's still yours to make.

Sources: Linear, "AI usage patterns in software teams" (How teams build, Edition 01), reported by Tim Qi, head of data, with cohort N = 6,887 paid teams (4,280 with coding agents, 2,607 without).