The Vibe Coding Hangover: A Recovery Playbook for CTOs

●TL;DR

89% of CTOs reported production disasters from AI-generated code. Year 2 maintenance costs are running 4x traditional levels. GitClear analyzed 211 million lines and found a 60% decline in refactoring activity alongside an 8x increase in copy-paste code. CodeRabbit's data shows AI-generated code carries 1.7x more bugs, 75% more logic errors, and 2.74x more security vulnerabilities than human-written code. Forrester projects 75% of tech organizations face moderate-to-severe AI technical debt by end of 2026, with accumulated debt reaching $1.5T by 2027. This post is the triage, audit, and remediation playbook for codebases that shipped fast with AI assistance and now nobody understands.

Part of the AI-Assisted Development Guide ... from code generation to production LLMs.

●The Morning After

You shipped it. The MVP launched on time. The demo worked. The investors were impressed. AI-assisted development let your 4-person team build what used to take 12 engineers and 6 months. Everything looked great.

Six months later, it doesn't look great.

Your senior engineer just spent 3 days debugging an authentication flow that nobody can explain. A new hire has been onboarding for 5 weeks and still can't make changes without breaking something. The billing integration has a race condition that shows up under load, but nobody knows why the code was structured that way in the first place... because nobody wrote it. The AI did, and the developer who accepted it left two months ago.

This is the vibe coding hangover. And based on the data, you're not alone. 89% of CTOs reported production-impacting issues traced to AI-generated code. The question isn't whether you have this problem. It's how severe it is and what to do about it.

●The Hangover Symptoms: How to Recognize You Have This Problem

Not every AI-assisted codebase develops a hangover. The ones that do share specific symptoms. If three or more of these describe your situation, you're dealing with it.

Nobody Can Explain the Auth Flow

Ask three engineers on your team to whiteboard the authentication and authorization flow from login to API request. If they can't do it without reading the code... or if they read the code and still can't explain the decision architecture behind it... you've got cognitive debt in a critical path.

Auth is the canary. If your team doesn't understand auth, they don't understand the security boundaries of your system. Every production incident in that path becomes a crisis.

Incident MTTU Is 3x What It Should Be

Mean Time to Understand (MTTU) is the time between "we know something is broken" and "we know why it's broken." In a healthy codebase, MTTU for a module your team built is 15-30 minutes. For AI-generated modules that nobody deeply understands, MTTU stretches to 2-4 hours... sometimes days.

The METR randomized controlled trial found experienced developers were 19% slower with AI assistance on complex tasks. Debugging a vibe-coded system is definitionally complex... you're reverse-engineering decisions that were never made by a human. The 19% slowdown is the optimistic scenario. In my advisory work, I've seen incident resolution times 3-5x longer in codebases with heavy unreviewed AI generation.

New Hires Take 2x Longer to Onboard

Standard onboarding for a mid-level engineer in a well-documented codebase is 2-4 weeks to first meaningful contribution. In AI-heavy codebases without comprehension infrastructure, I've seen 6-10 weeks. The code runs, but it resists explanation. There are no Architecture Decision Records. Comments describe what the code does (which the engineer can read) instead of why it does it (which is what they need to know).

Refactoring Attempts Introduce More Bugs Than They Fix

This is the most dangerous symptom. When your team tries to clean up AI-generated code and the cleanup creates more problems than it solves, you've crossed a threshold. The codebase has accumulated enough opacity that well-intentioned improvements backfire because the team doesn't understand the invariants they're violating.

GitClear's data backs this up. The 60% decline in refactoring activity across AI-assisted codebases isn't laziness... it's learned helplessness. Teams stop refactoring because refactoring keeps breaking things.

The Dependency Tangle

AI-generated code tends to over-import. It pulls in libraries for tasks that could be handled with 10 lines of custom code. It creates abstractions that look clean in isolation but create circular dependency chains when composed. Your package.json or requirements.txt has 40% more dependencies than a team-written equivalent, and nobody has audited which ones are actually necessary.

●The Triage Framework: Assess Severity Before Acting

Don't start fixing code randomly. Triage first. The severity framework below prioritizes by blast radius and change frequency.

Severity 1: Critical Paths Nobody Understands

What qualifies: Authentication, authorization, billing, payment processing, data pipeline integrity, user data handling (GDPR/CCPA-relevant), core business logic that directly generates revenue.

Why it's Severity 1: A bug in these paths loses money, loses data, or loses compliance. If nobody on your team can explain how these systems work without reading every line of code... you have an active liability.

Action: Stop feature development on these paths. Begin comprehension sprints immediately. Document every decision. Write integration tests that prove the invariants hold. This isn't optional.

Severity 2: Core Business Logic With No Documentation

What qualifies: Domain-specific algorithms, workflow engines, notification systems, integrations with third-party services, reporting and analytics pipelines.

Why it's Severity 2: Bugs here don't lose money directly but degrade the product. Nobody understands why the recommendation engine weights certain signals, or why the notification system retries 3 times with exponential backoff starting at 2 seconds. These decisions exist in code but not in anyone's head.

Action: Schedule comprehension sprints in your next 2 planning cycles. Assign ownership. Create ADRs retroactively.

Severity 3: Non-Critical Features With High Complexity

What qualifies: Admin dashboards, internal reporting, developer tooling, non-core UI features.

Why it's Severity 3: These systems can break without customer impact. But high complexity means they consume disproportionate debugging time when issues arise.

Action: Log it. Prioritize when Severity 1 and 2 are handled. Accept some ongoing friction.

Severity 4: Internal Tooling

What qualifies: Build scripts, CI/CD pipelines, developer environment setup, seed data generators.

Why it's Severity 4: Low blast radius. Even if it's incomprehensible, it only affects developer experience, not production.

Action: Add to the backlog. Fix opportunistically when someone's already in the code.

●The Codebase Audit Protocol: A 4-Week Plan

Once you've triaged, you need a systematic audit. This isn't a sprint. It's a 4-week protocol that produces artifacts your team will reference for the next 12 months.

Week 1: Map the System

Goal: Produce a dependency graph and data flow diagram that the team agrees represents reality.

Start with tooling, not reading code:

# Generate dependency graph (TypeScript/Node)
npx madge --image dependency-graph.svg --extensions ts,tsx src/

# Find circular dependencies
npx madge --circular --extensions ts,tsx src/

# Count files by directory (identify concentration)
find src -name "*.ts" -o -name "*.tsx" | \
  sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -20

# Identify largest files (complexity proxies)
find src -name "*.ts" -o -name "*.tsx" -exec wc -l {} + | \
  sort -rn | head -20

The dependency graph reveals structural issues that code review misses. Circular dependencies, god modules, and phantom abstractions (interfaces that exist but serve no real purpose) show up visually.

Deliverable: System architecture diagram, dependency graph, data flow diagram for Severity 1 paths. All three reviewed and approved by the team.

Week 2: Identify Comprehension Gaps

Goal: Find the modules where your team's mental model diverges from what the code actually does.

Run pair debugging sessions. Take a Severity 1 or 2 module and have two engineers walk through it together, explaining the code as they go. Record where they disagree, where they guess, and where neither can explain the reasoning.

// Comprehension gap tracking
interface ComprehensionGap {
	module: string;
	file_path: string;
	line_range: [number, number];
	description: string;
	severity: "critical" | "high" | "medium" | "low";
	gap_type:
		| "no_one_understands"
		| "conflicting_understanding"
		| "missing_context"
		| "undocumented_invariant";
	discovered_by: string[];
	date: string;
}

// Real example from an audit I conducted
const auth_gap: ComprehensionGap = {
	module: "auth",
	file_path: "src/lib/auth/session-manager.ts",
	line_range: [47, 112],
	description:
		"Token refresh logic uses a sliding window that nobody can explain. " +
		"Why 15 minutes? Why not use the provider's built-in refresh?",
	severity: "critical",
	gap_type: "no_one_understands",
	discovered_by: ["eng_1", "eng_2"],
	date: "2026-03-15",
};

Deliverable: Comprehension gap inventory. A spreadsheet or structured document listing every module where team understanding is incomplete, categorized by severity and gap type.

Week 3: Prioritize by Blast Radius x Change Frequency

Not all comprehension gaps deserve equal attention. Prioritize using a 2x2 matrix:

A billing module that nobody understands but never changes is less urgent than an API middleware that nobody understands and gets modified every sprint.

Pull change frequency from git:

# Files changed most frequently in last 90 days
git log --since="90 days ago" --name-only --pretty=format: | \
  sort | uniq -c | sort -rn | head -30

# Cross-reference with comprehension gaps
# Files that are both frequently changed AND poorly understood
# are your highest-priority remediation targets

Deliverable: Prioritized remediation backlog with estimated effort for each item.

Week 4: Begin Targeted Remediation

Start with the highest-priority items from the backlog. Don't try to fix everything at once. Pick 2-3 modules and apply the remediation playbook (next section).

Deliverable: Completed remediation for 2-3 modules. Validated by the team. Template established for remaining work.

●The Remediation Playbook

Remediation isn't refactoring. Refactoring improves code structure. Remediation restores team comprehension. Sometimes these overlap. Often they don't.

Architecture Decision Records (ADRs) for Every Module

Every Severity 1 and 2 module gets an ADR. Not after the fact... during the comprehension sprint. The ADR captures what the team learns about why the code exists in its current form.

# ADR-007: Session Token Refresh Strategy

## Status: Accepted (retroactive)

## Context

The session manager uses a 15-minute sliding window for token refresh.
This was AI-generated during the MVP sprint. No documentation existed.

## Decision

After investigation, the 15-minute window exists because the original
AI-generated code used a generic OAuth2 pattern. Our auth provider
(Clerk) handles refresh internally. The custom refresh logic is
redundant and creates a race condition under concurrent requests.

## Consequences

- Remove custom refresh logic (reduces auth module by ~65 lines)
- Rely on Clerk's built-in token management
- Eliminates the race condition reported in INCIDENT-023
- Reduces session-related support tickets by estimated 40%

## Alternatives Considered

- Keep custom refresh with mutex: adds complexity, still redundant
- Reduce window to 5 minutes: doesn't fix the root cause

The ADR serves two purposes. It documents the decision for future engineers. And the act of writing it forces the team to actually understand the code... which is the real point.

Comprehension Sprints

Allocate 20% of sprint capacity to comprehension work. Not refactoring. Not feature development. Dedicated time for engineers to understand code they didn't write.

Structure:

1. Read session (2 hours): Two engineers read through a module together. No editing. Just reading and discussing.
2. Diagram session (1 hour): Produce a sequence diagram or state machine for the module's behavior.
3. Test session (2 hours): Write tests that document the current behavior... not tests to catch bugs, but tests that serve as executable documentation.
4. ADR session (1 hour): Write the ADR based on what was learned.

// Tests as executable documentation
describe("PaymentProcessor", () => {
	// These tests document CURRENT behavior, not desired behavior.
	// If any test fails, investigate before changing the assertion.

	it("retries failed charges exactly 3 times with exponential backoff", async () => {
		const processor = new PaymentProcessor(mockStripe);
		mockStripe.charges.create.mockRejectedValue(new StripeError("card_declined"));

		await processor.processPayment(validPaymentIntent);

		// Why 3 retries? ADR-012 documents: Stripe's recommendation
		// for idempotent charges. The 2/4/8 second backoff matches
		// their rate limit recovery window.
		expect(mockStripe.charges.create).toHaveBeenCalledTimes(4); // 1 + 3 retries
		expect(mockDelay).toHaveBeenCalledWith(2000); // 1st retry
		expect(mockDelay).toHaveBeenCalledWith(4000); // 2nd retry
		expect(mockDelay).toHaveBeenCalledWith(8000); // 3rd retry
	});

	it("does NOT retry on authentication errors", async () => {
		const processor = new PaymentProcessor(mockStripe);
		mockStripe.charges.create.mockRejectedValue(new StripeError("authentication_required"));

		await processor.processPayment(validPaymentIntent);

		// Why no retry on auth errors? Because retrying won't help.
		// The customer needs to complete 3D Secure.
		// This was a bug in the original AI-generated code that
		// retried ALL errors, causing duplicate charge attempts.
		expect(mockStripe.charges.create).toHaveBeenCalledTimes(1);
	});
});

These tests are worth more than any documentation file. They run in CI. They break when behavior changes. They force the next developer to understand the invariant before modifying the code.

Ownership Transfer Protocol

Git blame tells you who last touched a file. It doesn't tell you who understands it. Ownership transfer is the process of ensuring at least two engineers can explain any Severity 1 module without reading the code.

The protocol:

1. Primary owner does a recorded walkthrough of the module (30-60 minutes, screenshare, saved to your team's knowledge base).
2. Secondary owner independently modifies the module (adds a feature, fixes a bug, writes a test) without help from the primary owner.
3. Verification: Secondary owner explains the module to a third engineer. If the third engineer can ask questions and the secondary owner answers correctly, transfer is complete.

This isn't bureaucracy. It's insurance. When your primary owner goes on vacation, gets sick, or leaves the company... and all three of those will happen... you need someone else who can debug the billing system at 2 AM.

The Rewrite Threshold Decision

When do you fix code vs rewrite it from scratch? This is the most expensive decision in remediation, and getting it wrong in either direction is costly.

Rewrite when:

• Comprehension cost exceeds 40 engineer-hours for the module
• The module has 3+ known bugs that the team can't fix without introducing new ones
• The module's architecture is fundamentally wrong for current requirements (not "could be better"... wrong)
• Test coverage is below 20% and adding tests requires understanding code nobody understands

Fix when:

• The module works correctly in production (no known bugs)
• Comprehension gaps are limited to specific functions, not the entire module
• The architecture is sound but the implementation has issues
• Test coverage exists and can be extended

The rewrite threshold in most AI-generated codebases I've audited is ~30% of modules. That's higher than traditional codebases (~10-15%) because AI-generated code tends to be internally consistent but architecturally arbitrary. The patterns work in isolation. They don't compose well.

●Preventing the Next Hangover: Governance That Doesn't Kill Velocity

The goal isn't to stop using AI-assisted development. It's to use it without accumulating the comprehension gaps that cause hangovers.

The Comprehension Gate

Before any AI-generated code merges, the developer must answer three questions in the PR description:

1. What does this code do? (the what... one paragraph)
2. Why does it do it this way? (the why... the architectural reasoning)
3. What invariants must hold? (the constraints... what breaks if these change)

If the developer can't answer #2 and #3, they don't understand the code well enough to own it. Send it back.

The 70/30 Rule

AI generates 70% of the code. The developer writes the remaining 30%: the glue, the error handling, the edge cases, and the architectural decisions. This ratio ensures the developer maintains a mental model of the system while still capturing the speed benefits of AI assistance.

Teams that let AI generate 95%+ of the code are the ones calling me for remediation 6 months later.

Mandatory ADRs for New Modules

Every new module gets an ADR before the first PR merges. Not after. Before. The ADR doesn't need to be long... 200-300 words covering context, decision, and consequences. But it needs to exist, and it needs to be written by a human who understands why the module exists.

Weekly Comprehension Reviews

Spend 30 minutes per week as a team reviewing one module. Rotate which module gets reviewed. The review isn't a code review... it's a comprehension check. Can the team explain the module? Do they agree on how it works? Do the ADR and the code still match?

This costs 2.5 engineer-hours per week for a 5-person team. That's 130 hours per year. A single Severity 1 incident in a module nobody understands costs 40-80 engineer-hours to resolve. The prevention math works.

●When NOT to Recover

Sometimes the right answer is don't remediate. Rewrite.

Don't remediate when:

• Total estimated remediation cost exceeds 60% of a clean rewrite
• The product requirements have changed significantly since the original build
• The team that built the original codebase is entirely gone
• The architecture doesn't support the next 12 months of planned features
• You're pre-product-market-fit and the entire product direction is uncertain

Forrester's $1.5T projected AI tech debt number by 2027 includes companies that will spend more remediating bad code than they would have spent rewriting it. "Rescue engineering" is emerging as a discipline precisely because so many teams need help deciding between recovery and rebuild.

The decision framework:

Remediation Cost = (engineer-hours × loaded rate) + opportunity cost of delayed features
Rewrite Cost = (engineer-hours × loaded rate) + migration risk + data migration cost

If Remediation Cost > 0.6 × Rewrite Cost → Rewrite
If product requirements changed > 40% since original build → Rewrite
If original team retention < 30% → Lean toward rewrite
Otherwise → Remediate

●The Recovery Timeline

For a 10-person team with a moderate hangover (3-4 of the symptoms described above), here's the realistic timeline:

At a $75/hour loaded rate, that's ~$40,000. Compare to the alternative: continuing to operate with 3-5x incident resolution times, 2x onboarding costs, and the ongoing risk of a Severity 1 incident in a path nobody understands.

The teams that delay remediation don't save money. They defer costs while accumulating interest. And cognitive debt... unlike financial debt... doesn't offer a fixed interest rate. It compounds unpredictably, usually at the worst possible time.

●FAQ

How do I convince my board that remediation isn't wasted engineering time?

Frame it as risk reduction, not code cleanup. Calculate the cost of your last 3 production incidents in engineering time, then show how MTTU (Mean Time to Understand) is the primary cost driver. If your MTTU is 3x what it should be, you're spending 3x on every incident. Remediation reduces that multiplier. Present it as: "We're spending $X/quarter on incident resolution. Remediation reduces that by 50-60% within 6 months."

Can we use AI to remediate AI-generated code?

Yes, with constraints. AI is effective at generating tests for existing code, producing documentation drafts, and identifying dead code. It's not effective at producing ADRs... because ADRs require understanding intent, which is exactly what's missing. Use AI for the mechanical parts of remediation (test generation, documentation scaffolding). Use humans for the comprehension parts (ADR writing, architectural review, invariant identification).

What's the minimum viable remediation for a startup that can't afford 530 engineer-hours?

Focus exclusively on Severity 1. Map and document your auth, billing, and data pipeline. Write integration tests for the happy path and the 3 most likely failure modes. Create ADRs for each. That's 80 engineer-hours ($6,000) and covers the paths where a comprehension gap becomes a company-threatening incident. Everything else can wait until you have more capacity.

How do we measure whether remediation is working?

Track three metrics: MTTU (should decrease by 40-60% over 3 months), new hire time-to-first-contribution (should decrease by 30-50%), and "refactoring success rate" (percentage of refactoring PRs that don't introduce new bugs, should increase from ~60% to 85%+). If these metrics aren't improving after 8 weeks of remediation, you're fixing the wrong things.

Is the vibe coding hangover permanent?

No. Every codebase I've helped remediate recovered within 4-6 months. The comprehension gaps are fillable... they just require intentional effort that most teams don't allocate until the pain becomes acute. The permanent damage isn't to the code. It's to the team's confidence. Engineers who've been burned by incomprehensible AI-generated code become reluctant to use AI at all, which overcorrects in the opposite direction. The governance framework in this post is designed to restore confidence alongside comprehension.

Dealing with an AI-generated codebase that nobody understands? I help teams triage, audit, and remediate... with a framework that restores comprehension without killing velocity.

• AI Integration for SaaS ... Responsible AI implementation
• Technical Advisor for Startups ... Engineering governance strategy
• AI Integration for Healthcare ... Compliant AI systems

●Continue Reading

This post is part of the AI-Assisted Development Guide ... covering code generation, LLM architecture, prompt engineering, and cost optimization.

More in This Series

• Stop Calling It Vibe Coding ... What AI-assisted development actually requires
• Cognitive Debt ... The hidden cost your team isn't measuring
• Technical Debt Strategy ... When to accumulate, when to pay down
• AI Code Review ... Catching what LLMs miss

Need a codebase remediation assessment? Work with me on your recovery plan.