AI can reduce cost of producing code. It does not automatically reduce cost of proving that code belongs in production.
That gap is verification debt: required evidence deferred when a change is accepted because it looks plausible, passes a narrow check, or produces a convincing demo. Debt may be harmless for a disposable prototype. It becomes dangerous when code has users, data, permissions, dependencies, or an on-call owner.
Quick answer: vibe coding creates production risk when generation outruns verification. Manage that risk by tracking which claims about a change have evidence, assigning checks by consequence, and counting review, rework, incidents, and operational load as part of delivery cost.
Evidence Supports Caution, Not a Universal Failure Story
There is no credible basis for a fixed “month one to month six” collapse narrative. Outcomes depend on model, task, developer experience, repository context, and quality bar.
Current evidence is mixed and should be read narrowly:
- Stack Overflow’s 2025 Developer Survey reported broad AI-tool use alongside more respondents distrusting output accuracy than trusting it. It also found “almost right” answers and time spent debugging generated code among common reported frustrations. This is self-reported survey evidence, not an incident rate.
- A peer-reviewed CCS 2023 user study, Do Users Write More Insecure Code with AI Assistants?, found participants using a Codex-based assistant produced less secure solutions in studied security tasks and were more likely to believe their code was secure. Results concern that model, study design, and task set; they do not establish that every modern assistant makes every developer less secure.
- METR’s early-2025 randomized study found experienced open-source developers took longer on its sampled tasks with then-current AI tools. METR’s February 2026 update says those older results no longer represent current tools and that its newer estimates are unreliable because of selection and measurement effects. Useful lesson: productivity claims need current, task-specific measurement.
- NIST Secure Software Development Framework 1.1 recommends integrating secure development practices into each software development lifecycle. It does not create a separate lower standard for AI-generated code.
These sources support verification discipline. They do not support fabricated production incidents, universal timelines, or claims that AI-generated code is inherently defective.
Verification Debt as a Ledger
For each change, separate implementation from claims that must be true.
| Claim | Evidence before merge | Debt if skipped |
|---|---|---|
| Requirement is correct | Acceptance criteria and owner sign-off | Product debt |
| Behavior is correct | Tests and manual scenario checks | Functional debt |
| Change fits architecture | Diff review by code owner | Comprehension debt |
| Inputs and permissions are safe | Threat-focused review and security tests | Security debt |
| Dependencies are acceptable | Lockfile review, provenance, and scanning | Supply-chain debt |
| Change can run reliably | Logs, metrics, failure handling, and rollback plan | Operational debt |
| Team can maintain it | Clear ownership and explainable design | Ownership debt |
Debt is not number of generated lines. A large generated test fixture may create little risk. A one-line authorization change may demand extensive evidence.
How Debt Accumulates
Unstated requirements
Prompt describes desired happy path but omits tenancy, accessibility, localization, retries, or retention rules. Generated output can satisfy prompt while violating system requirement never provided.
Plausibility substitutes for comprehension
Fluent code is easy to skim. Reviewer recognizes familiar patterns and misses incorrect assumption. Risk rises when no one can explain data flow, failure behavior, and blast radius without asking model again.
Tests mirror implementation
If same prompt or model generates implementation and tests, both can share same missing assumption. Passing tests show consistency with tested examples, not completeness of requirement.
Local success hides system effects
Component renders in one viewport while changing shared styles elsewhere. Query works on sample dataset but lacks production index. Retry handles timeout but duplicates non-idempotent write. These are illustrative failure modes, not claims about specific Frontman users or incidents.
Ownership stays implicit
Generated change merges, but no person becomes accountable for future behavior. When alert fires, team first reconstructs intent and design before diagnosing fault.
Match Verification to Risk
Use risk tiers rather than one rule for all AI output.
Tier 1: Reversible presentation changes
Examples: copy, spacing, approved token, static layout.
Evidence:
- Focused diff review
- Relevant viewport and accessibility check
- Existing CI
- Clear rollback
Tier 2: Application behavior
Examples: state transitions, forms, caching, API integration.
Evidence:
- Explicit edge cases and failure paths
- Unit and integration tests independent of generated implementation
- Architecture-owner review
- Logs or metrics for new failure modes
Tier 3: High-impact boundaries
Examples: authentication, authorization, billing, personal data, migrations, infrastructure.
Evidence:
- Threat model or abuse-case review
- Security and domain-owner approval
- Migration and rollback rehearsal where relevant
- Staged rollout and operational monitoring
- Independent validation beyond model that generated change
This approach follows ordinary software risk management. AI changes production economics of authorship, not accountability.
A Verification-Debt Review
Ask these questions before merge:
- What user or system requirement does change satisfy?
- Which assumptions came from prompt, repository, or model guess?
- Can reviewer explain changed behavior without relying on generated summary?
- Which happy paths, edge cases, abuse cases, and rollback paths were tested?
- Did tests come from independent requirement or merely mirror implementation?
- What shared components, data, permissions, or dependencies can change affect?
- What evidence will reveal failure after deployment?
- Who owns correction if assumption proves false?
Any unanswered question is visible debt. Team can decide to accept it, but decision should be explicit.
Measure Net Delivery, Not Generation Speed
Useful measures include:
- Lead time through review and CI, not time until first generated patch
- Review rounds and rejected diff size
- Escaped defects and reverts by change risk
- Time spent understanding or rewriting generated code
- Security findings and dependency exceptions
- Operational alerts attributable to recent changes
- Percentage of changes with named owner and rollback path
Compare AI-assisted and non-assisted work within similar task classes. Model capability, tooling, and team practice change quickly, so publish date and context with any result.
How Frontman Fits
Frontman can narrow some visual verification gaps by connecting selected rendered elements, screenshots, DOM context, source locations when available, source edits, and hot-reload feedback. Result remains ordinary code in project working tree.
That helps answer “did this edit target visible element and produce intended visual result?” It does not answer every question about security, accessibility, shared-component impact, business logic, or production operation. A reviewable diff is evidence, not approval.
Use AI for speed where it helps. Keep evidence bar tied to consequences. Verification debt becomes dangerous not when it exists, but when team mistakes unverified output for completed work.
For browser-context limits, read The Runtime Context Gap. For review controls around UI edits, read How Teams Review UI Changes From Non-Engineers.