Salesforce engineers call flat review time on the biggest pull requests a sign of disengagement

Stack Linear's per-change savings and the minute is accounted for. The change-detection job, which had been checking the full working tree when it needed almost none of it, went from a 26-second median to 8 ^[8]. Moving a cache-marker write off the critical path saved another 42 seconds on every API pull request ^[9]. Those two come to 60 seconds on the API path ^[21], against a reported drop in pull request wait from more than 6 minutes to just over 5 ^[3]. They sit on the same pipeline, so the savings are not additive, and the runner upgrade and the compiler swap were cutting the same wall clock.

The load side is less comfortable. Suites almost quadrupled since the start of the year ^[2], and runner time per test fell roughly by half ^[4]. Four times the tests at half the time each is about double the total machine time ^[22].

Two of the largest single wins carry conditions. The 73% cut in the tsc check's weekly median came from moving to the tsgo compiler ^[6]. That transfers to a team whose typecheck is actually on the critical path and whose code compiles under tsgo. The 68% cut in API lint time came from rewriting custom rules that needed TypeScript type information so they read the abstract syntax tree instead, which let ESLint shed TypeScript entirely ^[7]. A team that owns those rules can do that rewrite. It is out of reach for a team whose type-aware rules arrive inside someone else's plugin.

Salesforce's end of the funnel has no runner bill. Shan Appajodu and Ravi Boyapati report code volume up roughly 30% ^[11], pull requests regularly past 20 files and 1,000 changed lines ^[12], and review latency climbing quarter over quarter ^[13]. The signal they single out is the one that looks like progress on a dashboard: review time on the largest pull requests plateaued or declined ^[14]. They read it as reviewers no longer meaningfully engaging ^[15].

A flat number does not by itself separate a reviewer skimming a 1,000-line diff from a diff that needs less reading. The inference rests on their account of what reviewers were doing, which is that large diffs spanned unrelated files and architectural layers, so reviewers spent more time navigating than reasoning and the second-pair-of-eyes guarantee eroded ^[16]. Their answer rebuilt the review system around reconstructing intent and disclosing risk progressively, so attention lands where it matters ^[17]. The write-up describes the volume and latency figures as internal signals and gives no baseline period.

The dev.to account argues that cycle time and generation throughput are the wrong scoreboard under agent load, and proposes watching the ratio of validation cost to change size across pull request size buckets ^[19]. An average over all pull requests hides the 1,000-line changes, and those are the population Salesforce reports getting less attention ^[14].

Both write-ups put the failure on the judging side of the pipeline, not on the code the model produced ^[18]. Sorting out which one you have is cheap. If pull requests sit on green checks and runners cost real money, Linear's list applies; if large changes merge while review time on them stays flat, none of Linear's numbers help, and the dev.to account is explicit that the two fixes are not interchangeable ^[20].