Your team ships more pull requests than ever. The release still goes out Thursday, like it did before.
Nothing looks broken. The engineers are busy, the coding assistants are busy, and more tickets reach "In review" than ever. Then they sit there. The code got written. It's waiting.
That's a QA bottleneck, and it's the half of the AI productivity story that gets less airtime. AI didn't create a quality problem out of nowhere. It created a queue. More code reaches review, then waits, or skips review and ships anyway. Both outcomes land on you.
Key takeaways
A QA bottleneck is the point in software delivery where code output rises faster than the steps that validate it, so finished work waits in review, testing or release checks instead of reaching production.
Put simply: output goes up, validation doesn't, and finished work piles up between "done" and "deployed". Review, testing and release checks are the usual places it waits.
Speed up authoring without speeding up validation and validation becomes the constraint. That's how queues work. Addy Osmani, writing in June 2026, put it in one line: "The binding constraint on shipping is no longer how fast you can write code." [C8]
The best current data comes from Faros AI's 2026 engineering report. It draws on two years of telemetry from 22,000 developers and more than 4,000 teams [C1]. Two caveats first. Faros sells engineering analytics, so this is vendor research. And it's correlational: it compares each team's lowest-AI-adoption quarters with its highest, which shows association, not cause [C1].
Even so, the shape is hard to miss. Moving from low to high AI adoption, task throughput per developer rose 33.7% [C2]. Tasks per team with an associated PR rose 210% [C2]. Then the work hits review. Median time to first PR review rose 156.6% [C3]. Median time in PR review rose 441.5%, which Faros's summary calls a 5X increase [C3]. The average time a task spends in QA rose 33.7% [C3].
The far end of the pipe is narrower still. Faros has deployment data for only about 10% of its dataset. There, lead time from commit to production rose 480.4% [C3]. Deployments per week fell 11.7% [C9]. Faros puts it plainly: "More code is being written and merged, but it is not being released to production as frequently." [C9]
GitHub sees the volume side at platform scale. Octoverse 2025 reports developers merged 43.2 million pull requests a month on average, up 23% year on year [C10]. GitHub, which sells Copilot, calls these "observational signals rather than causal claims" [C10]. Fair. But every one of those PRs still needs someone, or something, to decide it's safe to ship.
Faros draws the conclusion itself: "Organizations are generating more code than the system can review and merge." [C11] Its 2025 report found high-AI teams merging 98% more PRs. In 2026 that gain was 16.2% [C11]. Faros's most likely explanation is that code quality "is creating a review bottleneck that is throttling throughput" [C11]. You can see the code review bottleneck in the timestamps.
Queues don't hold forever. Something gives, and in the Faros data the thing that gives is review.
PRs merged without any review rose 31.3% [C4]. Average PR size rose 51.3% [C4], so the PRs that do get reviewed are bigger. Then come the quality numbers. Bugs per developer rose 54%, up from a 9% rise in Faros's previous report [C4]. Incidents per PR rose 242.7%, which Faros describes as "more than tripled" [C4].
My reading: a PR merged with no review isn't speed. It's QA you've deferred to production, where your customers run it for you.
So this is a quality problem as well as a volume problem. Faros's own diagnosis is that "the code arriving for review was never ready" [C1]. Developers report something similar. In Sonar's survey of more than 1,100 developers, 38% said reviewing AI-generated code takes more effort than reviewing human code [C12]. Only 48% said they always verify AI code before committing [C12]. Sonar is a vendor too, and it calls the result "a verification bottleneck" [C12].
A code review bottleneck looks like a staffing problem, so the obvious response is headcount: more reviewers, a bigger QA team, a longer test cycle before release. The data argues against it.
Faros is blunt: "Adding reviewers, expanding QA, or investing in faster incident response treats the symptom. The problem must be addressed at the source, during code generation." [C1] Faros also sells the tooling it recommends, so weigh that. DORA gets to the same place by a different route.
DORA's 2025 report draws on nearly 5,000 respondents. It found AI adoption now has a positive relationship with software delivery throughput, which reverses its 2024 finding [C5]. AI adoption still has a negative relationship with delivery stability [C5]. DORA's explanation: "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability." [C6]
DORA's AI capabilities guidance adds the batch-size point: "AI can easily generate massive blocks of code, which are hard to review and test." [C7] Its answer is the discipline of small batches [C7].
Put those together and the trouble with a bigger review team is plain. A human reviewer is a gate at the end of the line. Add more gates and you get a slightly faster queue of oversized, under-tested PRs. The sources point somewhere else: validation that already exists when the code arrives. That means acceptance tests written before the work starts, automated checks on every PR, and CI gates that fail fast. That isn't "more QA". It's QA moved to where the code gets written.
Three objections deserve a straight answer.
"The AI speedup is overstated anyway." METR's 2025 randomised trial found 16 experienced open-source developers took 19% longer on tasks when AI was allowed [C13]. Afterwards, they believed they'd been 20% faster [C13]. METR now labels that result out of date [C13]. Its February 2026 update says developers are likely more sped up now than in early 2025 [C14]. It also calls its own data "only very weak evidence for the size of this increase" [C14]. Either way, the queue doesn't depend on per-developer speed. Faros and Octoverse count output directly, in tasks, PRs and merges [C2] [C10]. That volume fills the queue whether or not each engineer is faster. (We've covered the perception gap itself in the AI velocity paradox.)
"Developers should own testing." DORA agrees. Its test-automation guidance says teams do better when "developers are primarily responsible for creating and maintaining suites of automated tests" [C15]. The same guidance says "Testers and QA teams continue to have an important role", working alongside developers throughout [C15]. It also says "'tester' is a role, not necessarily a full-time job" [C15]. That last line matters for a growth-stage team. You may not need a QA department. You do need someone whose job this week is the tests.
"AI can write the tests too." Partly. In Meta's TestGen-LLM work, 75% of generated tests built correctly, 57% passed reliably and 25% increased coverage [C16]. Meta engineers accepted 73% of its recommendations for production [C16]. That's useful. It's also a 2024 result from a company with Meta's test infrastructure behind it. Osmani's caveat applies: "it only works if the tests are real." [C8] In the Faros 2026 dataset, AI review agents already review 25% of PRs [C1], and unreviewed merges still rose 31.3% [C4]. Automation isn't closing the gap on its own yet.
If the fix is validation that runs at authoring time, the practical question is who does the work. Your developers own tests in principle. In the Faros data, they're also completing 33.7% more tasks each [C2].
Here's what I'd put in place:
Testing AI-generated code well is its own topic (contract tests, security checks in CI, a regression suite that grows with every bug), and we've covered it in how to test AI-generated code.
That's the gap QA On Demand is built for. An AI-augmented QA engineer works in 3-day task cycles, with daily async updates and a task-by-task approval gate. The work includes release validation and smoke checks, regression suites, Playwright tests and GitHub Actions workflows. In the service page's words: "Every suite, fixture, and CI config we write lives in your repo and belongs to you." When you stop, the tests stay.
One engineer is $3,495 a month. Two working in parallel is $6,795. You're matched the same business day and get the first deliverable within 5 business days. If the engineer isn't right, we replace them within 5 business days at no charge. You can cancel any time, with no notice period. Start with one real task and judge the engineer before you subscribe.
Before you buy anything, though, pull three numbers from your own tooling for last quarter: median time to first review, time in QA and deploys per week. If output went up and those went the wrong way, you have a QA bottleneck, and now you know where it sits.
Code output rises faster than review and testing capacity. In Faros AI's 2026 vendor data, task throughput per developer rose 33.7% with high AI adoption, while median time in PR review rose 441.5% and time in QA rose 33.7%. [C2] [C3]
Not on its own. Faros AI's 2026 report says adding reviewers or expanding QA "treats the symptom". [C1] DORA 2025 says that without strong automated testing, an increase in change volume leads to instability. [C6] Validation has to move earlier, into acceptance tests and automated checks on every PR.
In Faros AI's 2026 data, PRs merged without any review rose 31.3% as AI adoption increased. [C4] Incidents per PR rose 242.7% over the same comparison. [C4] Faros is a vendor, and the data is correlational. [C1]
Compare last quarter's output with three flow numbers: median time to first review, time in QA and deploys per week. If output rose and those numbers got worse, finished work is queuing before release.
QA On Demand is $3,495 a month for one AI-augmented QA engineer, or $6,795 a month for two working in parallel. Work runs in 3-day task cycles with daily async updates. Every test suite, fixture and CI config lives in your repo and belongs to you.
