June 17, 2026

If you follow AI and tech news at all, you've seen the productivity stats. Developers complete tasks 55% faster. Roadmaps are moving. Features ship quicker. GitHub Copilot. Cursor. Claude. The tools are working.
And they are. That part is true.
But a report that dropped this month just laid out what the press releases aren't covering, and it's worth understanding if you run a business with software engineers — or if you're building anything with AI-assisted code.
Faros AI spent two years tracking telemetry from 22,000 developers across more than 4,000 teams. Not surveys. Not self-reported estimates. Actual engineering data: every pull request, every incident, every line of code written and deleted. The study compared outcomes in the same organizations at their lowest and highest points of AI tool adoption.
The headline findings are legitimately impressive. Task throughput per developer is up 33.7%. Epics completed per developer are up 66%. Pull request merge rate is up 16.2%. By the productivity metrics most organizations track, AI is delivering exactly what was promised.
Here's what they also found: for every pull request merged, the probability of a production incident has more than tripled. Incidents-to-PR ratio is up 242.7%. Bugs per pull request are up 28%. Code churn — lines deleted relative to lines added — is up 861%.
They named it the Acceleration Whiplash. The machine is going faster. The brakes haven't kept up.
---
The core issue is structural, not technical. AI tools optimize for output. They are not optimized for correctness in context, long-term maintainability, or what happens three PRs later when two AI-generated code changes interact in ways nobody expected.
The Faros data found that AI acceptance rates — how often developers keep AI-suggested code — have climbed from 20% to 60%. That sounds like efficiency. But it also means code is entering codebases at a rate that the review process was never designed to handle. Pull request sizes are up 51%. Median review time is up 5x. Developers are approving more, faster, under conditions that make thorough review genuinely difficult.
One of the sharpest findings from the report: the engineers most at risk of being cut to fund AI tooling budgets are, in many cases, the ones absorbing the quality gap AI is creating. Senior engineers — the ones who catch edge cases, who remember why a particular piece of the system works the way it does, who can tell when AI-generated code is plausible but wrong — are being treated as overhead in a system that increasingly depends on exactly that expertise.
The companies cutting senior engineers to fund more AI tooling may be undermining the mechanism that keeps the AI output from going sideways.
---
Microsoft published the 2026 Work Trend Index in May — a study based on trillions of Microsoft 365 signals and surveys of 20,000 AI-using workers across 10 countries. The finding that stood out wasn't the productivity numbers, which were strong. It was a single line: "Frontier Professionals refuse to outsource their thinking."
The most effective AI users in the study weren't the ones using AI the most aggressively. They were treating it as a thinking partner while keeping human judgment at the center of their decisions. Microsoft is calling this a reskilling shift — from prompting to judgment.
That's a meaningful signal. The people getting the most from AI tools aren't automating their thinking. They're staying in the loop on what matters and using AI to handle the throughput. The organizations that have moved fastest to reduce that human judgment layer are the ones showing up in the Faros incident data.
---
You might read this and think: I'm not running an engineering team at scale, so this doesn't apply to me.
It does — just at a different layer.
The dynamic Faros documented in software engineering exists everywhere AI is being used to produce outputs that then flow into real systems: marketing copy that goes live without review, customer support responses sent automatically, financial analyses acted on without a sanity check, operations decisions made from AI-generated summaries that omit the exceptions.
The pattern is the same. Output goes up. The failure rate goes up with it. The gap between the two either gets absorbed by someone paying attention, or it reaches customers.
The question for any business using AI at speed is: where is your review layer, and is it keeping pace with the output?
If the answer is "we trust the AI output," that's not a review layer. That's the same mistake the 60% PR acceptance-rate developers are making — except in your business, it's customer emails or invoices or decisions, not code.
---
The Acceleration Whiplash is not an argument against AI tools. The throughput gains are real and the productivity case is solid. But the research is clear that volume without quality controls doesn't improve the business — it just moves the damage downstream.
Three things the Faros data implies for any operator:
Track the downstream, not just the output. If you're measuring how much your AI tools are producing, also measure what's happening after that output enters the world. Incidents, corrections, customer complaints, manual fixes. That's where the real cost is.
The review function is becoming more important, not less. As AI output scales, the humans judgment-checking that output are the constraint on quality. Cutting that function to fund more AI tooling is a bet that the AI doesn't make mistakes at increased volume. The last two years of data says that bet is wrong.
Speed and quality compound differently. AI compresses timelines and that's genuinely useful. But processes that ship fast and break often have a compounding cost — in incidents, in trust, in rework — that erases the time saved. Calibrate your adoption around what the downstream can absorb.
The companies that figure this out early will have an advantage. Not because they use AI more aggressively, but because they use it with better controls attached.
If you want to think through what that looks like in your operation, start at degrand.ai/contact.