Agents made it faster to write code. Two engineering teams published what happened on the validation side when they did, and the two write-ups land on the same structural claim from opposite ends. Linear found its CI gate became the bottleneck. Salesforce found its human review stopped engaging. Neither team concluded that generation was the problem. Both concluded that the part of the system built to judge a change had not kept pace with the part built to produce one.
Linear's engineers, in a post titled AI coding has made CI a bottleneck, so we reworked ours to keep up, dated September 21, 2026, report that their test suites almost quadrupled since the start of the year. Pull request wait time went from more than 6 minutes to just over 5, and runner time per test dropped roughly in half. The throughput gains are real, but the story is about where they came from. Linear did not get faster by telling agents to slow down. It reworked the validation machinery.
The list of changes is mostly mechanical. Faster third-party runners with better CPU, storage, and cache made the same pipeline run about 34% faster on average, with the tsc workload down 52%. Moving to the tsgo compiler cut the tsc check's weekly median by 73%, enough to move typechecking off the bottleneck. A handful of custom lint rules that depended on TypeScript type information were rewritten to use the abstract syntax tree, which let ESLint shed TypeScript entirely and cut API lint time by 68%. A change-detection job that checked the full working tree when it needed almost none of it had its median trimmed from 26 to 8 seconds. Moving a cache-marker write off the critical path saved 42 seconds on every API pull request.
The headline metric there is the one nobody markets: how long a proposed change waits to be judged, and how much machine time the judging consumes. As test suites quadruple under agent load, that is the number that decides whether agents feel fast in practice.
On the other end of the same funnel, Salesforce engineers Shan Appajodu and Ravi Boyapati published "Scaling Code Reviews: Adapting to a Surge in AI-Generated Code" in January. Their internal signals: code volume rose roughly 30%, pull requests regularly exceeded 20 files and 1,000 changed lines, and review latency climbed quarter over quarter. The signal they flag as most worrying is when review time on the largest pull requests plateaued or declined. They read that as reviewers no longer meaningfully engaging.
That is a different failure than the CI one. Large diffs spanned unrelated files and architectural layers, so reviewers spent more time navigating than reasoning, and the second-pair-of-eyes guarantee eroded. Salesforce's answer was not to make review faster in the throughput sense. It was to rebuild the review system around reconstructing intent, treating context as a first-class dependency, and progressively disclosing risk so reviewers spend attention where it matters. I wrote separately about what that plateau says when review time stays flat.
Put the two reports side by side and the shape is clear. Linear's validation bottleneck was mechanical and cheap to fix, so they sped it up. Salesforce's was cognitive and structural, so they rebuilt how review presents a change. But both are the same failure: generation got cheaper and faster, and the system that verifies a change did not scale with it. That is the load every team with agents is now carrying at one of two points, and often both.
Linear's post gives the concrete numbers for the mechanical end. Salesforce's post gives the language for the cognitive end. The engineering task is knowing which end you are hitting. If pull requests sit waiting on green checks and runners are expensive, you have Linear's problem. If large changes sail through with flat review time and senior reviewers context-switch all day, you have Salesforce's problem. The two fixes are not interchangeable.
Teams commonly track cycle time and generation throughput, and both reports suggest those are the wrong scoreboard. Linear tracked wait-on-CI and runner time per test. Salesforce tracked review time on the largest pull requests, because a flat number there is a disengagement signal hiding a decline in scrutiny. A useful review metric under agent load is the ratio of validation cost to change size, watched across PR size buckets so the huge 1,000-line changes do not get lost in an average.
Tooling is catching up on both ends. CI-aware validation and cost-conscious runners shore up the mechanical side, and context-first review tools work the cognitive side by keeping related changes grouped and surfacing risk. Kodus fits in the same category as the context-first review tools, applying team-specific rules rather than generic linting. The point of the comparison is not which product wins. It is that a review tool earns its place on the side of the funnel where your own bottleneck sits, so the first question is which end is breaking for you.
Both posts are worth reading in full, and both are unusually honest about method. Linear publishes its before and after numbers. Salesforce names the metric that actually signaled trouble. If you want a single takeaway: when agents make code generation effectively free, the constraint that remains is validation, and the teams that publish measured work are the ones fixing that side.
The vendors marketing "reviews every PR" are talking about throughput. The measured sources are talking about whether a human looked closely enough, at either the CI gate or the review table. When you are asked to review a growing volume of AI-written code, the first useful step is to place your own bottleneck on that spectrum. If review time on your largest changes is flat while the changes get bigger, the problem is not that review is slow. It is that review stopped reading. That is the number to watch, and it is the one neither vendor dashboard tends to show.