Verification Debt: When AI Writes Code Faster Than Teams Can Verify It
AI sped up how fast teams write code, not how fast they can prove it works. What CircleCI and DORA data show about the gap, and the first changes engineering leaders make.
Verification debt is the growing backlog of code that has been written, and often merged, but never proven to work in conditions like production. It builds up when AI coding tools raise the volume of changes faster than a team’s capacity to verify them, and it shows up in delivery data as more work started than finished.
Writing code used to be the slow part of shipping software, so review, CI and test environments were sized to it. Coding agents changed that in about a year. The steps that prove a change works did not speed up at the same pace, and the difference between the two speeds is the debt.
Paying it down means checking each change against the running system before it merges, which is the closed loop the complete guide to verifying AI-generated code lays out for teams whose agents write much of their code.
What is verification debt?
Technical debt is code you know is not right and plan to fix. Verification debt is code you do not know is right. It is every change that cleared the checks a team can run cheaply (the build, linting, unit tests and a read-through in review) and skipped the check that shows whether it works in the running system.
That makes it a different problem from AI technical debt, the worry that AI-generated code is harder to read and maintain. Many AI-generated changes are fine. The problem is that nobody knows which ones, and the interest on that uncertainty is paid later: merges that fail, recoveries that take longer, and incidents traced back through dozens of changes nobody remembers writing.
The distinction matters because the fix differs. Refactoring pays down technical debt. Only evidence pays down verification debt: a check that ran the change against the rest of the system and passed.
Why the bottleneck moved from writing code to proving it works
Code generation got cheap faster than checking code did. Sonar’s State of Code Developer Survey, published in January 2026 from more than 1,100 developers, found that AI accounts for 42% of committed code. Developers expect that share to reach 65% by 2027.
Trust has not kept up with output. In the same survey, 96% of developers said they do not fully trust that AI-generated code is functionally correct, yet only 48% said they always check AI-assisted code before committing it. Sonar calls this a verification gap, and ties it to what AWS CTO Werner Vogels has called verification debt.
The figure that explains why the gap widens is a smaller one. 38% of developers said reviewing AI-generated code takes more effort than reviewing a colleague’s. Each additional change does not get cheaper to verify. It often gets more expensive, while the number of changes keeps climbing.
What the CircleCI data shows
Pipeline data shows the debt as work that starts and does not finish. CircleCI’s Q2 2026 State of Software Delivery analyzed more than 20 million workflows from March 2026 and compared them with the same weeks of 2025. For the median team, feature-branch throughput grew 7.7% year over year, and main-branch throughput stayed flat.
| Measure, Q2 2026 | Median team | Highest-throughput teams |
|---|---|---|
| Main-branch success rate | 76.7%, up from 70.8% in Q1, against a 90% benchmark | Not reported separately |
| Feature-branch runs for each run that lands on main | 3.9 | 1.3 for the 20 busiest organizations |
| CI cost per shipped change, year over year | Up 13% | Down 31% for the same 20 |
| Main-branch throughput | 1.7 workflows a day | 9 times the median at the 95th percentile, up from 8 times in Q1 |
CircleCI’s own summary: “Validating code is the core bottleneck now, and the typical team continues to struggle.” The middle rows show what that costs. The median team needs about five CI cycles to land one change, and each shipped change costs it more than a year earlier. The teams pulling ahead land changes in fewer passes, which is verification debt not taken on in the first place.
The September 2025 data in CircleCI’s previous report had the same shape, with main-branch throughput falling and recovery from a broken main branch slowing. Slower recovery fits verification debt, though CircleCI does not isolate the cause. Our read of that report covers what it means for teams running coding agents.
What the DORA data shows
DORA’s research places the debt in the organization, not in the tool. Its 2025 State of AI-assisted Software Development, built on a survey of nearly 5,000 technology professionals, puts it plainly: without a strong underlying system, “AI creates localized pockets of productivity that are often lost to downstream chaos.” That is verification debt described from the other end. The gain shows up in the editor and is lost in the pipeline.
The same report found that 30% of respondents have little to no trust in the code AI generates. That is a large share for tools nearly everyone now uses, and distrust without a fast way to check turns into manual verification work.
The DORA AI Capabilities Model names seven practices that amplify AI’s benefits: a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, user-centric focus, and quality internal platforms. Two of them speak directly to verification. On small batches: “AI can easily generate massive blocks of code, which are hard to review and test.” On platforms, DORA says they provide automated, secure paved roads that prevent “individual productivity gains from being lost to downstream bottlenecks.”
Teams that already had fast, reliable verification absorbed the extra output. Everyone else stacked it up.
How verification debt compounds
Verification debt does not grow in a straight line. Four effects make each unverified change more costly than the last.
- Review becomes the verification layer. When the only pre-merge check that looks at behavior is a person reading a diff, review capacity sets the ceiling on delivery. Reading a diff also cannot show whether a renamed field breaks a consumer three services away.
- Batches grow. Changes that skip system-level checks before merge meet each other in shared staging. When something breaks, every extra change in the window makes the cause slower to find.
- Context disappears. A person who wrote a change a week ago can still explain it. An agent session that wrote it has ended. As we argued in async coding agents need a verifier that isn’t a person, unchecked agent output moves the cost to whoever finds the failure.
- Attribution gets harder. In GitLab’s 2026 research with The Harris Poll, 43% of respondents said they cannot reliably tell AI-generated code from human-written code in their own codebase. Of the organizations that had a production incident in the past year, 34% could not tell whether AI-generated code contributed.
Slower attribution means slower recovery, which erodes trust, which pushes teams to verify by hand, which slows the next batch. Breaking the loop at any point helps, and the cheapest point is before merge.
How to tell if your team is carrying verification debt
There is no single number for verification debt, but most teams already have the signals in their delivery data.
- Main-branch success rate. A falling rate means more unverified changes reach main.
- Time to recover a broken main branch. A rising number means failures are getting harder to attribute.
- Feature-branch versus main-branch throughput. If the first grows and the second does not, work is piling up between writing and proving.
- Share of merged changes that ran in a production-like environment before merge. This is the most direct measure, and most teams do not track it.
- Failures found after merge that a pre-merge system check would have caught. Tag them in incident reviews and count them.
- Review wait time per pull request. If it climbs as pull request volume grows, reviewers are doing verification work that tooling should do.
The first three come straight from CI history. The others take a small change to how incidents and pull requests are tagged, which is worth making before changing anything else.
What engineering leaders change first
The order matters. Without measurement, there is no way to tell whether the other changes worked.
Measure verified changes shipped, not code generated
Lines written and pull requests opened go up with AI adoption whether or not delivery improves. Count changes that reached production without a rollback or a hotfix instead. The platform leaders we spoke with made the same point in code generation isn’t the bottleneck anymore.
Keep changes small
A small change is cheaper to verify and easier to trace when it fails. Coding agents make large diffs effortless, so the limit has to be set on purpose: one concern per pull request, and work split before an agent starts rather than after review stalls.
Move system-level verification before merge
The check most teams skip before merge is the one that needs a running system. It got skipped because a production-like environment for every pull request used to mean copying the whole stack. That is no longer the only option. Signadot gives each change its own lightweight ephemeral environment in the cluster the team already runs: only the services it changed, alongside the shared stable services, deleted on merge. Each change gets tested against the rest of the system without waiting for staging.
Let coding agents verify their own work before review
When an agent can run system-level checks itself and fix what fails, the pull request arrives with evidence attached. Feedback inside the agent’s session is also cheaper than feedback from CI, because the agent still has the context to act on it. The reviewer can then focus on intent and design instead of whether the code runs.
Write down what a passing check guarantees
A green check means whatever the merge gate verified, and on most teams that excludes system behavior. Deciding what it should mean, and checking it before merge, is the subject of what a green check on a pull request should promise.
None of this slows AI adoption. It makes the extra output count, because the teams with the highest throughput did not write less code: they verified it in fewer, faster passes. For how that loop works when coding agents do most of the writing, see Signadot for agentic development.
Frequently asked questions
What is verification debt?
Verification debt is the growing gap between how much code a team produces and how much of it has been proven to work in conditions like production. It builds up when AI coding tools raise the volume of changes faster than review, CI and test environments can keep up. Like other debt, it is paid back later, with interest: failed merges, slower recoveries and incidents traced across many changes at once.
Is verification debt the same as AI technical debt?
No. Technical debt is code a team knows is wrong or hard to maintain. Verification debt is code a team does not know is right, because it never ran against the rest of the system before merge. AI-generated code can carry both, but many AI changes are fine. Verification debt is the missing evidence about which ones are, and it grows with change volume even when code quality holds steady.
Why is AI-generated code harder to verify than code written by people?
There is more of it, and it often looks correct before it has been tested. In Sonar's 2026 developer survey, 96% of developers said they do not fully trust that AI-generated code is functionally correct, and 38% said reviewing it takes more effort than reviewing a colleague's code. An agent also leaves no author to ask once its session ends, so verification debt surfaces when the context needed to fix it is gone.
How do you measure verification debt?
There is no single number, but delivery data shows it. Track the main-branch success rate and its trend, time to recover a broken main branch, the gap between feature-branch and main-branch throughput, and the share of merged changes that ran in a production-like environment before merge. Rising feature-branch activity with flat main-branch throughput is the clearest sign that verification debt is building up.
How do engineering leaders reduce verification debt?
Start by measuring verified changes shipped instead of code generated. Then keep changes small, move system-level checks before merge into a production-like environment for each change, and let coding agents run those checks themselves before a person reviews the pull request. Finally, write down what a passing check guarantees, so the merge gate states what verification each change has had.
