You open a pull request that is simply too long to read properly. You scroll, skim the parts that look familiar, approve it, and tell yourself the tests will catch what you missed. Every engineer carries a private threshold for when this happens, and nobody ever wrote it down. On 16 September 2026, Spotify’s Tyson Singer , SVP of Technology and Platforms, published a retrospective on a year of AI-assisted development arguing that those old thresholds — the size and complexity limits that used to flag a change as too risky to trust — may simply no longer apply now that a human and an agent write code together. Inside a single review, though, a threshold that has gone obsolete and a threshold nobody can enforce anymore look identical, and Spotify’s own evidence does not fully separate the two.
The evidence Spotify offers for relaxing the line
The scale of the shift is real. Total merged changes at Spotify more than doubled year over year, from roughly 8,100 to 17,000 in August, while quality and optimization work rose from 27% to 31% of that mix. Across the incidents reviewed so far, Singer writes, Spotify “did not identify AI-authored code as a material direct contributor” — but in the same breath admits “the volume of change increased faster than some of our verification controls could adapt.” That second clause is doing more work than the first: it is the company conceding its own checks lagged the growth it is defending.
Spotify’s strongest evidence is a metric, not a mood. Rework rate — which weights code by age, a better proxy for whether recent changes hold up — stayed flat even as Faros AI’s 2026 report found code churn rising sharply across the industry. Faros itself cautions that churn “measures what was shipped, not what survived,” and may reflect legitimate large-scale refactoring rather than failure. Spotify’s own near-miss makes the stakes concrete: an automated dependency upgrade “passed our checks, but still failed in production,” prompting the company to add safeguards around automated upgrades, expand rollback capacity, and schedule automated changes during working hours so someone is awake to catch the next one.
The engineer who has to pick which PR to actually read
That instinct to add human safeguards around automation cuts against the headline claim. If you are the engineer who gets three 600-line agent-authored pull requests before lunch, you still have to decide which one you will actually read line by line — and Spotify’s reframing offers no help with that choice. GitHub’s own review guidance , published four months earlier, takes the opposite position: send a PR back when the diff touches more than five unrelated files, or when you cannot describe its purpose in a single sentence. The platform vendor’s advice is to hold the line, not loosen it — which makes Spotify’s stance the outlier, not the consensus, and hints at why GitHub Copilot’s ability to approve and resolve its own review comments has drawn scrutiny rather than relief.
Inside a single review, a threshold that has gone obsolete and a threshold nobody can enforce anymore look identical.
What Faros’s own telemetry complicates about the story
The honest complication is that Faros’s telemetry, drawn from 22,000 developers across 4,000-plus teams, also shows incidents-to-PR ratio up 242.7% and median time in review up 441.5% over the same period. Spotify is reporting on its own organization, with an obvious interest in the conclusion it reaches, even where the rework-rate evidence looks genuine rather than spun. Both companies, notably, measured different things: Spotify tracked incident attribution and rework inside one company, Faros tracked cross-organization correlations between adoption and delivery metrics. As an earlier look at post-edit rework found, the mechanics of what makes agent-touched code hold up are still being worked out study by study, not settled by any single one.
Neither measured the thing this whole debate actually turns on: whether a human reviewer’s comprehension keeps pace with a larger, agent-co-authored pull request. That gap is not a footnote — it is the entire question. Read across from what Spotify and Faros did measure, that absence suggests the comprehension threshold is now unvalidated in both directions: nobody has shown the old limits are obsolete, and nobody has shown they still hold. Spotify’s promise to keep “strengthening the entire delivery system” is candid about that gap even as it argues past it, which is closer to where code review has been relocating rather than disappearing all year.
Until someone re-derives the number, the pull request too long to read properly is still going to get approved on faith — only now it comes with a company blog post explaining why that faith might be justified.
