Linear put up a really good post about reworking their CI because AI coding agents had turned it into the bottleneck. The numbers are worth reading on their own terms: their test suite roughly quadrupled since the start of the year, yet they brought PR wait time down from over 6 minutes to just over 5, while cutting runner time per test roughly in half. They did it the way good engineers do. Switched to faster third-party runners, moved off type information in their lint rules so ESLint could drop TypeScript entirely, capped fetch depth on the jobs that gate everything else, moved a cache write off the critical path.
Every one of those is a machine-parallel fix. That's worth sitting with, because it's exactly why the same trick won't work on the gate that actually becomes the bottleneck when agents ship at agent speed.
CI is embarrassingly parallel. Review is not.
Linear's optimization list is a list of ways to make each unit cheaper or run more units at once. Add test shards, faster CPUs, drop the type graph from lint, cache the right things, stop installing packages you don't need. Each shard is independent, checking its own slice of the diff, and the aggregate curves down as capacity goes up. This is what engineering does well: find the parallelizable surface and widen it.
Code review is the opposite shape of work. Reading a diff for correctness is serial reasoning across the whole change. The claims in one file depend on the contract in another. Two reviewers don't halve the time, they add surface for disagreement. You cannot shard a reasoning task the way you shard a test run, because the answer isn't a pass/fail per chunk, it's a judgment over the assembled whole.
So when agents make the output side exponentially faster, the serialization point moves. Generation used to be the scarce resource and review was affordable. Now generation is nearly free and the diff volume is the thing climbing. Linear noticed the CI side of that and leaned in. Nobody in that post talks about the read-of-the-diff side, and that's the half that doesn't get to lean in the same way.
The cheap ways to buy review at volume are the wrong ones
When review volume outstrips the humans, teams reach for two shortcuts and both are the correlated-judge trap in a new costume.
You sample: review one in every N PRs, because the full pass is too expensive. But sampling an LLM reviewer hits the accuracy-inflation problem I wrote about before, where a model reports 96% accuracy and nobody measures recall. The slice you sample is the mild PR, and the recall you need is on the PR that breaks an authorization check. Sampling optimizes for orphaning exactly the set you can't afford to miss. The CI lesson is the opposite of sampling. Linear tests everything, they just test it cheaply and in parallel. Sampling review is like deleting a test shard because it's expensive, and hoping the coverage you cut was the coverage nobody needed.
Or you let the model review its own output. That's not a review, that's one model's opinion measured several times. Five AI reviewers that don't catch a bug are still one model's judgment, sampled five ways. The depend on the judge being right, and the judge is the same model that produced the output. No independent ground truth anywhere in the loop.
The point isn't that review can't be automated. It's that the expensive, serial reasoning has to be spent where it matters, and the mechanical stuff has to be done mechanically first. Linear didn't give up the test suite when it got expensive, they made it cheap and parallel. The review equivalent is not fewer judgments, it's cheaper judgments by moving the deterministic work out of the reasoning pass.
Compress the gate, don't skip it
This is where the CI lesson actually transfers. Linear didn't remove their test suite, they made each run cheaper and stopped wasting capacity. The review equivalent is to route the deterministic, cheaply-verifiable checks to deterministic judges that auto-fail fast, and reserve the expensive model reasoning for the judgment that actually needs it. My earlier post on deterministic judges makes this case with run-to-run data: an LLM judge shifts its score run-to-run, which makes it a flaky test suite, not a verdict.
The practical shape is a review pipeline that separates layers. Formatting, lint, contract drift, the checks a rule engine can own, handled by rules that always return the same answer. Then the semantic judgment over the assembled diff, where a model adds real value because it's reasoning across the change, not ad-libbing a score. The deterministic layer is the shard you can parallelize and cache, the reasoning layer is the serial pass that has to happen once. Tools built around the first layer cheaply and the second layer deliberately are the ones that scale with agent output the way Linear's CI scales with its test suite.
What the transferable lesson is
The takeaway that generalizes: speeding up the machine side of your pipeline only moves the serialization point. If agents quadruple your diff volume, you can cut CI time all you want, you just push the wait to review. Every team that's proud of its fast CI but has a two-day PR review queue has already discovered this, they've just filed it under "review is slow" and not "the bottleneck moved."
The team that wins is the one that treats the review gate as the critical path, the way Linear treated CI. That means spending the deterministic checks first, auto-failing fast, and concentrating the model reasoning pass on the diff-level judgment the rules can't reach. It means measuring the review gate like Linear measures CI: wait time, throughput, the cost of each verification unit. And it means not buying volume with sampling or self-review, because those two give back the recall you actually need.
Linear deserves credit for naming the real dynamic: agents made shipping cheap, so validation got expensive by comparison. The follow-on is the part nobody in the thread has said out loud yet. The validation that scales is the validation you can parallelize and cache. Code review's serial reasoning is the one validation step that can't, and pretending otherwise is how you end up with a green CI and a review queue nobody reads.
Sources: Linear's full writeup on reworking CI because AI coding made it the bottleneck. My earlier notes on why the bottleneck is the wait, not the read, the recall gap hidden in AI reviewer accuracy claims, and on deterministic judges over flaky LLM verdicts.
Top comments (0)