What Verification Debt Is
Technical debt describes the future cost of choosing a fast, expedient solution over a better one. Verification Debt is a related but distinct problem: it's the accumulated gap between how fast AI systems can generate code and how fast humans can actually review,understand, and validate it.
The term was popularized by AWS CTO Werner Vogels during his re:Invent 2025 keynote, where he pointed out that AI coding assistants have made code generation nearly free - but human
review capacity hasn't scaled at all. Every AI-assisted commit that isn't properly verified adds to a growing backlog of unvalidated logic sitting in production.
Why It's Different from Technical Debt
Technical debt is about code quality - a shortcut that will need refactoring later. Verification Debt is about trust - code that may be entirely correct, or may be subtly wrong, and nobody has actually confirmed which. You can ship technical debt and know
exactly what you're trading off. You often can't do the same with unverified AI output, because nobody has looked closely enough to know.
Why It's Growing
A few data points make the scale of the problem clear:
- AI coding tools now generate a large share of new code in many teams, but review capacity per engineer hasn't increased proportionally.
- Security scanning research has repeatedly found meaningful failure rates in AI-generated code on standard vulnerability benchmarks.
- Code churn - the rate at which recently written code gets rewritten - has been trending upward in codebases with heavy AI-assistant usage, a signal that more code is being shipped before it's fully validated.
What Reduces Verification Debt
Paying down Verification Debt isn't about writing less AI-generated code - it's about making review as fast and confident as generation.
Some practical levers:
- Context that lets a reviewer (human or AI) understand why code changed, not just what changed
- Local-first validation that runs alongside your existing AI coding tools rather than replacing your workflow
- Evidence trails that make it clear what was actually checked, and what wasn't
Disclosure: I'm building Reality Graph, a local-first tool that works on exactly this problem. Happy to discuss the approach or trade-offs in the comments - genuinely curious how other teams are handling this.
Top comments (2)
What I'd add is that this probably needs a metric before it becomes operational. Otherwise, teams will agree with the concept, sigh, and still fail to manage it.
A practical starting point might be something like: median review time per AI-assisted change, proportion of those changes covered by tests added or updated in the same PR, and post-merge churn within 7 or 30 days. If you can correlate those with escaped bugs or security findings, verification debt stops being a metaphor and becomes something engineering leadership can track.
The harder question for me is whether AI can meaningfully help pay down verification debt without creating a second-order trust problem. AI-generated tests, AI review summaries, and AI security checks are all attractive, but if they share similar blind spots, and similarly reinforce false confidence.
In our case, we adopted a hybrid approach: after AI-assisted review, the PR still needs to be reviewed by two human engineers to merge the PR. But that is only a procedural control. Nothing prevents people from treating it as a formality unless the process also captures what was checked, what evidence was produced, and which parts remain effectively unverified.
Great point. This is exactly the distinction Reality Graph is designed to make: AI-generated review output is treated as an assessment, not as proof of correctness. The architecture is designed to separate the intended change, proposed validation, checks that were actually executed, human review, and anything that remains unverified.
I see two layers here. At the change level, you need an evidence record: what was expected, what was checked, by which mechanism, what evidence was produced, and what remains unresolved. At the team level, you need the operational indicators you described: review latency, test changes, post-merge churn after 7 or 30 days, escaped defects, and security findings.
Reality Graph’s current focus is the first layer. The second still needs to be aggregated and calibrated against real outcomes. I would start with a set of indicators rather than collapsing them into a single score too early, because a premature score could create exactly the false confidence we are trying to prevent.
Your point about two human approvals becoming procedural is especially relevant. Capturing what each reviewer actually checked may be more meaningful than recording the approval alone.
Do you currently capture that evidence in the PR itself, through CI, or somewhere else?