Verification debt in AI-assisted development: hypotheses, rival explanations and mitigation

By Alfredo Castillejos · Dixi-Project · October 16, 2026 · 12 min read

With artificial intelligence, a team generates software faster than it can verify it. That gap does not go away: it piles up as verification debt. And if pending code becomes more expensive to review over time, because other changes already depend on it, the debt grows exponentially.

Public GitHub data already shows the symptom. Between January 2024 and September 2026, merged pull requests (PRs) per month grew 5.6×; those approved by another person grew only 2.6×. What has not been shown yet is the harm: that this unverified code ends up causing more failures.

This article proposes which hypotheses need testing, which rival explanations could account for the same data without a serious problem, and which levers exist to mitigate it. The core conclusion: the goal is not to eliminate the debt, but to keep it below a threshold and focus verification where failure is expensive. And acting early costs far less than acting late.

The problem

A programmer working with AI generates more code than they can review. To compensate, they add tests, specifications and architecture. But that scaffolding is also generated by AI, and it also exceeds human review capacity. What remains is a debt that grows over time.

The AVD model (AI verification debt and risk) expresses this in three equations:

\frac{d D}{d t} = α G - V + δ D, D \geq 0

P_{failure} = 1 - (1 - p_{c}) \prod_{i} [1 - p_{i} (1 - s_{i})]

L = \sum_{i} P (F_{i}) C_{i}

Symbol	Meaning
D	Accumulated verification debt, in pending hours of verification
G	Changes generated per day
α	Hours needed to verify one change
V	Hours of effective verification per day
δ	Rate at which pending debt becomes more expensive (rework, dependencies)
p_i, s_i	Probability of a defect in change i, and of validation catching it
p_c	Probability of a common-cause failure: the code and its tests share the same mistake
C_i	Cost of failure i reaching production
L	Expected loss

With constant parameters, the debt follows this curve:

D (t) = \frac{α G - V}{δ} (e^{δ t} - 1)

Three non-obvious results follow from it:

There is a point of no return. If the debt exceeds the threshold D*, it keeps growing even when verification outpaces generation.

D^{*} = \frac{V - α G}{δ}

Speed enters the exponent. If the cost growth depends on the pace of change (δ = βG), generating more does not just add debt: it accelerates its growth.
There is a risk floor. The probability of failure never drops below p_c. More tests generated by the same AI do not reduce the risk that code and tests share the mistake.

What the data says

We collected the data on October 16, 2026, using GitHub's public API:

Indicator	Jan 2024	Sep 2026
PRs merged per month	3.28 M	18.4 M
PRs merged with approval from another person	0.67 M	1.76 M
ρ̂ = merged PRs per approved PR	4.9	10.5
PRs merged with no review at all	76.7%	89.3%
PRs signed by AI agents	almost 0	18.7%

In a sample of PRs from repositories with at least 10 stars, a PR signed by Claude Code is merged in a median of 58 minutes, versus 19 days for one without AI. It also receives 4.8 times fewer reviews per 1,000 lines.

One finding runs against intuition: agent PRs are not larger. The pressure comes from the number of changes, not their size.

What is proven and what is not

Claim	Status
Change generation grows much faster than human approval	Proven with public data
The share of code merged without review by another person is rising	Proven
That unreviewed code causes more failures, incidents or rework	Open
The debt grows exponentially (δ > 0)	Open: the model allows it; δ still has to be estimated
AI-generated tests share the mistakes of AI-generated code	Plausible: there is prior work, the experiment is still pending

The jump from symptom to harm is exactly what needs proving, and what a critic will attack first.

Hypotheses to confirm

Each hypothesis comes with the result that would refute it.

	Hypothesis	What we would expect	What would refute it
H1	Divergence: with ρ > 1 sustained, debt grows	Unreviewed lines accumulating per repository	Repositories with ρ > 1 for 8+ weeks and no accumulation
H2	Amplification: δ > 0, growth is more than linear	The model with δ predicts better out of sample than the linear one	The linear model fits as well or better
H2b	Speed in the exponent: δ grows with G	Faster teams have more rework per change	The relation between δ and G is not positive
H3	Common cause: tests from the same AI miss that AI's mistakes	More mutants survive its tests than tests written from the specification	No difference between both suites
H4	Saturation: beyond some ρ, producing more stops yielding more reliable software	Escaped defects grow faster than PRs	Reliable software keeps growing with G
H5	Hysteresis: with high debt, verifying more is no longer enough to reduce it	Teams that add reviewers and do not reduce their debt	Debt always falls when V > αG

Rival explanations

These explain the same data without a serious problem. It pays to raise them before anyone else does, and to say which data point separates them from the thesis.

	Rival	If it were true	How to tell it apart
R1	Displacement. Verification does not vanish: it moves from human review to CI, types, static analysis and production monitoring	Real verification is much larger than measured	If the change failure rate and reverts stay flat while ρ̂ rises, R1 wins
R2	Selection. What gets merged unreviewed is low risk: prototypes, docs, personal repositories	The debt exists, but failure costs almost nothing	If ρ does not rise in repositories with users or dependents, R2 wins
R3	Better baseline quality. AI code has fewer defects per line	Debt grows in hours, but its risk grows less	Compare defects per 1,000 lines of AI and human code
R4	Deferred payment. The debt is paid later as incidents, vulnerabilities and rewrites	It is the thesis seen from the cost side	Code rewritten within two weeks, vulnerabilities, abandoned projects
R5	Rubber-stamping. Approvals grow, but each one reviews less	The problem is worse than ρ̂ measures	Comments and time per approval. There is already a signal: 1.23 versus 5.92 reviews per 1,000 lines

R1 and R2 are the ones that could defuse the alarm, and R5 would make it worse. R4 is not a rival: it is the same thesis measured in money. A serious study has to measure the first three.

Should we mitigate?

Yes, but not to bring the debt to zero. Verifying everything by hand would cancel out the advantage of AI. Some debt is acceptable, like that of a throwaway prototype; some is not, like that of a change to payments, authentication or personal data.

The right goal has two parts:

Keep the debt below the point of no return. Beyond it, the system can no longer be recovered with normal effort.
Minimize the expected loss, not the debt. The same hour of verification is worth far more on a change whose failure is expensive.

Verification debt is a risk decision. It can be taken on deliberately, like any other debt, as long as you know how much there is, where it is, and what it costs if it fails.

Mitigation levers

Each term in the formula is a place to intervene.

Lever	Mechanisms	Cost or risk
Lower G: generate less	Limit work in progress; a change budget per cycle	Gives up part of the productivity gain
Lower α: make verification cheaper	Small PRs (defect detection drops above 500 lines per review hour); specification before code; strict types	Cheap and very effective
Raise V: more capacity	Independent automated verification: property-based, mutation and contract tests; static analysis; formal methods for the critical core	Only counts if it does not share the generator's bias
Lower δ: keep the debt from rotting	Modularity and low coupling; versioned contracts; recorded decisions; review early	Changes the shape of the curve: from exponential to linear
Lower p_c: break the common cause	Tests written before the code and frozen; tests from another person or model; review by a different model than the one that generated	The only lever that lowers the risk floor
Lower C_i: make failure cheaper	Gradual rollout; feature flags; automatic rollback; bounded blast radius	Does not reduce the debt, makes it tolerable
Allocate by risk	Full human review only where failure is expensive; the rest, automated	Requires classifying the risk of every change

How much each lever moves the needle

We simulated each lever with the model itself. The parameters are illustrative, not measured: 100 changes per day, 1.2 hours per change, 70 hours of verification per day and δ = 0.2% per day.

Verification debt over 24 months by scenario: baseline, lower α, lower δ and combined

Scenario	30 days	1 year	2 years	Versus baseline
Baseline	1,546 h	26,877 h	82,649 h	—
Lower α from 1.2 to 1.0 h per change	928 h	16,126 h	49,589 h	−40%
Raise V from 70 to 90 h per day	928 h	16,126 h	49,589 h	−40%
Lower G from 100 to 80 changes per day	804 h	13,976 h	42,977 h	−48%
Lower δ from 0.2% to 0.1% per day	1,523 h	22,026 h	53,754 h	−35%
Combined: α = 1.0 and δ = 0.1%	914 h	13,215 h	32,252 h	−61%
Verify at the pace of generation (V = 120 h)	0 h	0 h	0 h	−100%

Three takeaways:

Lowering α is as good as hiring capacity. Saving 0.2 hours per change yields the same as adding 20 hours of verification a day, and usually costs far less: smaller, better-specified PRs.
δ barely shows after a month and dominates after two years. At 30 days, halving δ reduces the debt by less than 2%; at two years, by 35%. That is why investing in architecture looks useless in the short term and is decisive in the long term.
Acting late costs more. To stop the debt from day zero, 120 hours of verification a day are enough. Wait a year, with 26,877 hours already accumulated, and it takes 174 hours a day, 45% more, just to stop it from growing.

Controls by change risk

Risk	Examples	Minimum controls
Low	Docs, styling, prototypes, internal scripts	Automated verification; merging without human review is acceptable
Medium	Business features without sensitive data	Tests written before the code; PRs of 400 lines or less; agent review plus human confirmation
High	Authentication, personal data, money, external input	All of the above, plus line-by-line human review, a threat model with one test per threat, and gradual rollout
Critical	Calculation core, security, regulatory compliance	All of the above, plus two independent human approvals, formal or property-based verification, and rehearsed rollback

An edge case: a single maintainer

We also looked at a production repository with a single maintainer and the automated controls already in place:

Tests are written first, and a mechanism prevents the agent from editing them.
No PR may exceed 400 lines of code.
Full verification is mandatory before anything is marked as done.
The agent reviews and a person approves.
There is an approval gate before production and rollback by artifact.

In that repository, 70% of commits are co-authored by AI, and none of its 116 PRs was reviewed by another person. It is a useful case for the underlying question: do automated controls replace human review, or merely disguise its absence?

How to validate it

Step	What is measured	What it decides
1. Symptom versus harm	ρ̂ per repository versus the rate of reverts and fix PRs	Whether the thesis or rival R1 wins
2. Split by risk	ρ̂ in repositories with users or dependents versus personal ones	Whether the thesis or rival R2 wins
3. Common cause	Mutants surviving tests from the same AI, another AI, and tests written from the specification	H3, the most original result and the cheapest to produce
4. Estimate δ	Linear versus exponential fit of debt per repository	Whether growth is really exponential

Only with these results will it make sense to say how much to invest in each lever.

Limitations

ρ̂ counts approvals, not hours of verification. It is a trend indicator, not a direct measure of verification capacity.
The simulation parameters are illustrative. They show the shape of the phenomenon, not its size in a specific team.
Public GitHub does not represent private enterprise software, where review practices tend to be stricter.
Agents signing their PRs is optional, so real AI usage is underestimated.
The concept of "verification debt" already exists (Sonar, 2026). What this work contributes is the formalization, the derived results and the evidence, not the term.

Sources

GitHub Search API and GraphQL API, our own collection on October 16, 2026.
SmartBear and Cisco Systems: a study of 2,500 code reviews. Review is effective at 200 to 400 lines per session, and detection drops above 500 lines per hour.
DORA, State of DevOps: delivery metrics and change failure rate.
GitHub, Octoverse: annual contribution volume.
Sonar, What is AI code verification debt? (2026).
Ehsani et al., TOSEM (2026); Jin and Chen (2026); Leu et al. and Nam and Yang, ESEM (2026); Cheung (2026).

Calculate your team's verification debt

Enter your team's numbers. Everything is calculated in your browser: nothing is sent or stored.

Changes per dayPRs or commits merged on a normal day

What it is: How many changes reach the main codebase on a normal day: merged PRs or, if you don't use PRs, commits to the main branch.
How to get it: Count the PRs merged in the last 4 weeks and divide by the working days (about 20). On GitHub, search your repository for: is:pr is:merged merged:>=YYYY-MM-DD.
Example: 80 PRs merged in 4 weeks ÷ 20 days = 4 changes per day.

Hours to verify one changeReview, testing and validation of a typical change

What it is: The hours it would take to properly verify a typical change: read it, test it and check that it does what it should.
How to get it: Take 10 recent PRs, estimate the review and testing time for each and use the average. If you don't track it, a reference point: careful review covers about 300 lines per hour (Cisco and SmartBear study), plus manual testing time.
Example: 150-line PRs: 0.5 h of review + 0.5 h of testing = 1 h per change.

Verification hours per dayFor the whole team, not per person

What it is: The hours your team actually spends on verification each day, across all people. Not the full working day.
How to get it: Ask each person how much time a day they spend reviewing PRs, testing and validating, and add it up. Automated verification only counts if it is independent and replaces human work.
Example: 4 people × 1.5 h a day = 6 h of verification per day.

Daily debt growth rate (%)0.05 loosely coupled · 0.2 typical · 0.5 tightly coupled

What it is: How much more expensive unverified work gets each day: the longer it waits, the more code depends on it and the more it costs to review or fix.
How to get it: Measure it through rework: in a month, what percentage of pending work had to be reviewed again or redone because something changed underneath it (conflicts, repeated reviews, chained fixes)? Divide that percentage by 30. If you don't measure it, use a reference based on coupling: 0.05 for well-isolated modules, 0.2 for a typical system and 0.5 for a tightly coupled monolith.
Example: If 6% of pending work has to be redone every month: 6 ÷ 30 = 0.2% per day.

Current debt (hours)Verification hours pending today; 0 if you don't know

What it is: The verification hours that are already overdue today.
How to get it: Count the changes that went in without a thorough review or are still waiting for one, and multiply by the hours per change. If you don't know, leave 0: the calculation starts from today.
Example: 25 pending PRs × 1.2 h = 30 h of current debt.

Unsustainable threshold (%)Extra capacity your team could not realistically get

What it is: How much extra verification capacity your team could get, at most and in a short time. Beyond that, stopping the debt is no longer realistic.
How to get it: Think about how much you could increase review hours without stopping delivery: overtime, reassigning people or hiring. 50% is a prudent starting point.
Example: If at most you could go from 6 h to 9 h of verification a day, the threshold is 50%.

At risk: the debt becomes unsustainable in 6.7 months (203 days).

Debt at 30 days: 928 h · Debt at 1 year: 16,126 h

━ Debt · ╌ Unsustainable threshold · hours of debt

What to apply first

You generate 120 h of verification work a day and have 90 h: 30 h a day are missing. Until you close that gap, the debt keeps growing.
Cut the cost of verifying each change by 20%: small PRs, specification before code, strict types. With this: unsustainable in 33.1 months.
Generate 20% fewer changes: limit work in progress. With this: unsustainable in 33.1 months.
Add 20% of independent verification: property-based and mutation tests, static analysis. With this: unsustainable in 24.7 months.
Keep the debt from rotting (halve δ): modularity, versioned contracts and early review. With this: unsustainable in 13.3 months.
Write the tests before the code, and don't let the same AI that generated the code change them.
Assign human review by risk: full review for payments, authentication and personal data; automated for the rest.

ShareLinkedIn X WhatsApp