The AI coding tools worked. The velocity gap they created is now the bottleneck.

TL;DR

• Teams using AI coding assistants like Copilot and Cursor are merging pull requests 3 to 5 times faster than they were eighteen months ago.
• Test coverage has not scaled with that pace. Most teams are still writing and reviewing tests at pre-AI speed.
• The result is not “fewer bugs caught.” It is a growing backlog of AI-authored changes that nobody has verified against intended behavior.
• The gap shows up first in regression blind spots: changes that pass code review but were never exercised by a test that reflects what the feature is supposed to do.
• Adding more manual test-writing capacity does not close this gap. The bottleneck is a rate mismatch, not a headcount problem.
• Closing it requires rethinking how tests get authored, not just how fast they get run.

A team merges 40 pull requests in a two-week sprint. Six months ago, that same team merged 12. The difference is not more engineers. It is Copilot drafting the boilerplate, Cursor refactoring across files in one pass, and pull requests that used to take two days now taking two hours.

QA reviewed six of the 40 pull requests properly. The other 34 got a build check, a smoke test, and a merge.

Nobody made that decision on purpose. It happened because the team’s test-writing capacity didn’t move when their code-writing capacity did.

The gap nobody budgeted for

Engineering leadership tracked velocity gains from AI coding tools closely. Pull requests per sprint. Time to first review. Cycle time from ticket to merge. Every one of those numbers improved, and the improvements got reported up.

What didn’t get tracked with the same rigor: test coverage as a percentage of new code, not as a percentage of the whole codebase. A team’s overall coverage number can look stable for months while the coverage of this sprint’s changes quietly erodes, because the denominator (total code) grows slower than the numerator problem (untested new code) compounds.

This is not a story about AI writing bad code. Most AI-assisted code is functionally fine on the first pass. The problem is that “functionally fine” and “matches intended business behavior” are different claims, and only a test that encodes the intended behavior can tell you which one you’re looking at. When the rate of code changes outpaces the rate of test authorship, more and more changes ship on the first claim alone.

Why “just write more tests” doesn’t close it

The instinctive fix is to add test-writing capacity: hire more QA engineers, ask developers to write more of their own tests, push harder on test-coverage targets in the definition of done.

This treats the gap as a headcount problem. It isn’t. A team that doubles its AI-assisted coding velocity and responds by adding one QA engineer has closed maybe 10 to 15 percent of the gap, because manual test authorship was never going to scale linearly with AI-assisted code authorship in the first place. The two activities have fundamentally different velocity ceilings: one is now bottlenecked by a language model’s inference speed, the other is still bottlenecked by a human writing test steps by hand.

Pushing coverage targets harder without changing how tests get written just moves the bottleneck. Developers spend more time writing tests and less time writing features, which erases some of the velocity gain that justified the AI tooling investment in the first place. QA teams asked to cover more ground with the same headcount either work unsustainable hours or, more commonly, start approving changes with lighter scrutiny to keep pace. Neither outcome is stable.

What actually breaks first: regression blind spots

The gap doesn’t show up as a dramatic outage on day one. It shows up as regression blind spots: areas of the application that used to be exercised by the test suite as a side effect of how slowly the codebase changed, and are no longer exercised because the codebase now changes faster than the test suite gets updated to match.

A concrete pattern: a developer uses an AI tool to refactor a shared utility function used across a dozen features. The refactor is clean and passes the existing test suite, because the existing test suite was written against the old call sites and doesn’t know the new ones exist yet. Three of those dozen features now behave subtly differently under edge-case inputs. None of this shows up until a customer hits the edge case in production, at which point the team is debugging a change that happened weeks earlier, buried under dozens of subsequent merges.

This is the specific failure mode of the velocity gap: not “AI wrote a bug,” but “the test suite’s view of the application is now stale relative to how fast the application changes,” and staleness compounds silently until something in production forces it into view.

The real cost, in one sequence

Here is how this plays out end to end, in a pattern QA leads describe consistently once they start looking for it. An AI-assisted change to a pricing calculation ships without a new test, because the existing pricing tests still pass and nobody wrote a new one for the specific new logic path. Three weeks later, a support ticket comes in: a customer was charged the wrong amount under a specific discount combination. Engineering traces it back to the change from three weeks prior. The fix itself takes twenty minutes. Finding it took four days, because the change was one of dozens that shipped in that window, and there was no test that would have flagged it at merge time.

Multiply that by the number of untested changes shipping every sprint, and the real cost of the velocity gap becomes visible: it is not a testing problem in isolation, it is a debugging-tax problem that grows every sprint the gap stays open.

The teams closing this gap are not doing it by writing tests faster by hand. They’re rethinking what “writing a test” means when the thing generating code changes at a pace no manual process can track. That rethink starts with a question most teams haven’t asked yet: what would it take for test creation to move at the same speed as code creation, without sacrificing the judgment a human still needs to bring to deciding what “correct” means for their application.

Sources

• GitHub, “The economic impact of AI on software development” (Copilot productivity research)
• Stack Overflow Developer Survey 2025, AI tool adoption and workflow impact sections
• Google DORA (DevOps Research and Assessment) State of DevOps reports, on the relationship between deployment frequency and change failure rate