What is verification debt?
Verification debt is the gap between what your tests assert and what users actually see on screen.
A test suite can be green while the page shows the wrong currency, a cut-off error message or text nobody can read. Each time code ships without someone or something checking the rendered result, that gap grows. Like other debt, it is cheap to ignore today and expensive when it surfaces in front of a customer.
The term is used here for a specific, checkable thing: visible text that differs from what the code and its tests say should be there.
Why AI-generated UI makes it worse
AI coding tools produce plausible components quickly, and the tests that come with them usually assert on the DOM: an element exists, a string is present in the markup. Both can be true while the screen is wrong. When volume goes up and review time does not, more of that output goes unchecked.
This is a reasoned argument, not a measured rate. There are no public figures here for how often it happens, and we do not claim any.
Five failure types
The AI UI bug gallery and its open dataset group 50 curated failure patterns into five categories, 10 each. They are written examples of the patterns, not a count of real incidents. One of each:
Wrong currency
Expected Total: £99.99, screen shows Total: $99.99.
Currency symbols default to USD without explicit locale handling.
Missing confirmation
Expected Payment Successful, screen shows Redirecting....
The confirmation text is omitted from the success state.
Truncated text
Expected Error: Invalid email address format, screen shows Error: Invalid email addr....
Text overflow is not handled in the error display.
Localisation mismatch
Expected 15/06/2026, screen shows 06/15/2026.
Date formatting does not follow the locale.
Invisible text
Expected Continue to checkout, screen shows (nothing visible).
The text colour matches the background.
Paying it down
- List the screens where wrong text is costly: prices, totals, dates, legal copy, confirmations.
- Add one rendered-text assertion per screen, not one per component.
- Run them in CI. Keep the confidence threshold realistic for your fonts.
import { expect } from '@freetextfromimage/rendercheck/playwright';
await expect(page).toShowText('Total: $14.00', { minConfidence: 85 });Setup guides for Playwright and Cypress. To see where your team stands, try the Verification Debt Score, a short self-assessment.
What this does not cover
- OCR is probabilistic. It can misread unusual fonts or small text, so thresholds need tuning.
- It checks that specific text is visible and legible. It is not a full visual regression tool.
- Layout, colour and behaviour bugs that do not change visible text are out of scope.
FAQ
What is verification debt?
Verification debt is the gap between what your tests assert and what users actually see on screen. It grows when code, especially AI-generated code, ships faster than anyone checks the rendered result.
Is verification debt the same as technical debt?
No. Technical debt is about the cost of code structure. Verification debt is about unchecked behaviour: the code and its tests can be tidy while the visible text is still wrong.
How do I reduce verification debt?
Add assertions that read the rendered screen instead of the DOM. For example, use OCR-based assertions in Playwright or Cypress on the pages that show money, dates, legal copy and confirmations.
Can I measure it?
The Verification Debt Score on this site is a self-assessment questionnaire. It gives a rough band, not a measurement, and everything runs in your browser.