AI now writes a large share of the code in most product teams, and it writes it fast. But faster code has not meant faster releases.
The 2026 data tells a consistent story. Teams using AI open more pull requests than ever, and those pull requests are bigger, carry more issues and wait longer for review. The bottleneck did not disappear. It moved from writing code to checking it.
We use AI-assisted engineering every day, and we see the same pattern in the products we take over. This post explains what the research shows, why quality assurance has become the slow step, and the short list of things every product team should check this week.
Inside the 2026 data on AI and code quality
This is not one survey or one vendor's opinion. Several large studies, based on millions of pull requests and real delivery pipelines, point in the same direction.
More code, not more releases. CircleCI's 2026 State of Software Delivery report analyzed more than 28 million CI workflow runs. Workflow runs grew 59% year over year. Yet for the median team, feature-branch throughput rose only 15%, while throughput on the main branch, the code that actually ships, fell 7%. (Larridin summary)
Bigger pull requests that wait longer. LinearB's 2026 benchmarks covered 8.1 million pull requests across 4,800 engineering teams. At the 75th percentile, AI-assisted pull requests were 2.6 times larger than unassisted ones: 408 lines of code against 157. Pull requests opened by AI agents waited 5.3 times longer before a reviewer picked them up. (Codacy)
Review time up, review coverage down. Faros AI's 2026 AI Engineering Report, based on telemetry from 22,000 developers, found median time in pull request review up 441%. It also found 31% more pull requests merging with no review at all. Not by policy, but because reviewers could not keep up.
More issues in every change. CodeRabbit compared 470 open-source pull requests. Those co-written by AI carried 10.83 issues each, against 6.45 for human-only ones, about 1.7 times more. Veracode's 2026 GenAI Code Security Report tested 11 models on 80 coding tasks: on average, only 56% of the generated code passed its security checks. (LeadDev)
Debt that stays. A 2026 study of AI-generated commits on GitHub traced close to half a million issues introduced by AI tools. About one in four were still in the code at the latest revision. (arXiv) Separately, GitClear and GitKraken read 623 million code changes from 2023 to 2026 and found duplicated code up 81% against the pre-AI baseline.
Stability still lags. Google's 2025 DORA report found that AI adoption now helps delivery throughput, but still goes together with higher instability: more change failures and more rework.
For any team shipping with AI, testing and review capacity is now the speed limit.
Why QA becomes the bottleneck?
None of this means AI coding tools are a bad choice. They do speed up writing code. The problem is that the rest of the delivery process was sized for human-speed output. Four things change when AI joins the team:
Volume outgrows reviewers. One developer with an assistant can open several pull requests in the time one used to take. The number of senior engineers who can review them stays the same.
Changes get bigger. AI makes a large change cheap to write, so batches grow. Small batches have long been one of the safest habits in software delivery, and large AI-generated changes quietly undo it.
The reviewer has to rebuild intent. With human code, you can ask the author why. With AI-written code, the reviewer works from the ticket and the diff alone, and the code often looks right even when it is not.
The same tool writes the code and its tests. When AI writes both, the tests tend to confirm what the code does, not what the product should do. Coverage goes up; confidence does not.
There is also a quieter trap: a green pipeline is not the same as a tested product. Automated checks only test what someone told them to test. Edge cases, business rules, integrations and real user journeys still need a person who understands the product. When review queues grow, those are the checks that get skipped first.
What it means for your business?
A slow review queue is not only an engineering problem. For a product company it touches cost, customers and compliance:
Speed that never reaches customers. If code waits days for review, the AI investment shows up as licence fees and busy engineers, not as features shipped.
Defects found later, at a higher price. A bug caught in review costs minutes. The same bug found by a customer costs incident hours, support time and trust.
Security and compliance exposure. Since 11 September 2026, the EU Cyber Resilience Act requires makers of products with digital elements to report actively exploited vulnerabilities within 24 hours. Code that fails security checks almost half the time makes that clock harder to meet.
A growing maintenance bill. Duplicated, loosely structured code is cheap to write and expensive to own. Every shortcut merged today slows down the next feature.
Seven things to check this week
You do not need a large QA team to start. Ask your engineers these seven questions, and get a written answer for each:
How long does a pull request wait before review? Measure pickup time and review time separately. If the average is more than a day, that is likely your biggest hidden delay.
How many pull requests merge without a real review? Count approvals given within minutes of opening, or with no comments at all.
Are our pull requests getting bigger? Agree on a size limit, for example 400 changed lines, and ask for large AI-generated changes to be split.
Do we know which code was AI-assisted? Label AI-assisted and agent-written pull requests, so you can track their defect and rework rates.
Who writes the tests, and against what? Tests should come from acceptance criteria and real user journeys, not only from the code that was just generated.
What runs before a human looks? Static analysis, dependency and security scans, and AI review should catch the routine issues, so people can focus on logic, architecture and risk.
Do we track quality, not just speed? Next to throughput, follow change failure rate, rework and defects found after release. If speed goes up while these get worse, the gain is borrowed.
How we approach it at TechSoft?
We use AI in our own engineering every day, so we had to solve this problem for ourselves first. Our answer is simple: when code gets cheaper to write, we spend the time saved on checking it. What that looks like depends on where your product stands:
Building something new. In a project-based engagement, testing is planned together with the requirements. Acceptance criteria and test cases come before the code, and every AI-assisted change is reviewed by an engineer who understands it.
Taking over an existing product. When we take over a product, we start with a quality baseline: review times, failure rates, test coverage and the places where AI-written code has piled up. Then we fix the riskiest parts first.
Strengthening your own team. Through our "1 + 1 = 3" partnership, we work alongside your engineers to set up review rules for AI-generated code, automated checks in the pipeline and the quality metrics worth tracking.
Across all three, our Software Testing & Quality Engineering team keeps one rule: AI can help write and test the code, but a person signs off on what reaches your customers.
