Software Engineering · AI

Verification bankruptcy

noun · /ˌvɛrɪfɪˈkeɪʃən ˈbæŋkrʌptsi/

The term extends verification debt, a concept popularized by AWS CTO Werner Vogels: every time AI-generated code ships without adequate review, the gap between what a system does and what anyone has confirmed it does grows. Verification bankruptcy is what happens when that debt stops being serviced at all. The team quietly gives up. Code is merged on vibes, tests, and hope.

The analogy is email bankruptcy: the moment someone deletes their entire inbox and starts over because catching up has become impossible. The difference is that an abandoned inbox loses messages. An abandoned review process ships unknown behavior to production.

Why it is happening now

Generation is now faster than comprehension. When humans write code, understanding is built during the act of writing. When machines write it, understanding must be rebuilt during review, which is slower than the generation it is meant to check. The math does not close, and something has to give. What gives is the review.

Warning signs

• Pull requests approved in under a minute regardless of size.
• "LGTM" as the dominant review comment on AI-heavy changes.
• Review queues growing faster than they are cleared, then suddenly emptying without a matching spike in review activity.
• Nobody on the team can explain how a shipped module works.
• Incidents traced to code that no human ever read.

How it differs from related terms

Verification debt is the accumulating gap. It can still be repaid with effort. Verification bankruptcy is the default: repayment has been abandoned. Comprehension debt, coined by Addy Osmani, is a cousin: the cost of maintaining code nobody ever understood. Bankruptcy is the process failure; comprehension debt is what you are left holding afterward.

Avoiding it

• Budget verification like compute. If generation capacity grows 10x and review capacity grows 0x, bankruptcy is a scheduling certainty, not a risk.
• Verify at the spec level, not the line level. Human review should target intent, contracts, and invariants; automated checks should cover the rest.
• Make unreviewed code visible. Track the share of shipped code no human has read, the same way you track test coverage.
• Declare partial bankruptcy deliberately. Some code genuinely does not need human review. Deciding which code that is should be an explicit policy, not an exhausted default.

Sources

• Sonar: data on the verification gap in AI coding
• LeadDev: You can't verify all the AI-generated code
• Addy Osmani: Comprehension debt
• Hacker News: Verification debt discussion