Posts


# SlopBurn: The World's First Vibecoding QA Roguelike RPG

*What if debugging, hardening, and verification felt less like cleanup and more like dungeon descent?*

As many people have noted, vibecoding has breathed new AI life into the tried-and-true Unix-style CLI. I am fond of saying that AI UXes are moving slower than we might expect because communicating AI capabilities to users in an intuitive way is really freaking hard. So AI systems bootstrap from the most familiar UXes, and those familiar UXes end up exerting an unusual gravitational pull.

Games are powerful metaphors. Many of the game metaphors being applied to agentic software development read like management sims: move your Sims around the simulation with breadth-first parallelism, modularity, and perfect information.

I want to present a competing game metaphor for agentic software development:

- depth first over breadth first, to reflect the level of technical debt left behind by agentic coding today
- path dependence, to reflect the increased role of context and previous decisions in software engineering
- imperfect information and progressive discovery, to reflect the role of emergent user expectations

Depth-first, path-dependent, imperfect-information, text-based games are not a new genre. Gary Gygax first developed D&D for the tabletop fifty years ago. MUDs came to PLATO and then Unix systems shortly after, increasingly inspired by D&D.

So I sought to leverage D&D-style UX metaphors for a refactor and reskin of the Cutline QA Engineering MCP Server. Use the structure and narrative conventions of a D&D game to, well, trick users into enjoying debugging and securing their vibeware with the same delight they felt while creating it. Also give users a ready vocabulary of metaphors for the unfamiliar aspects of vibe debugging and vibe hardening as they navigate the dungeons of their technical debt.

That is the core metaphor behind **SlopBurn**: a complete agentic engineering system is not about fanning out in massive parallelism. It is about iterative, depth-first exploration of the structures you have summoned.

The structure of post-MVP vibecoding is simply like a roguelike RPG:

- it is text-driven
- it is iterative
- it rewards judgment under uncertainty
- it punishes shallow greed
- it turns tiny decisions into cascading consequences

And, most importantly, it is not really about moving broadly across the map. It is about choosing where to descend, what to engage, and how to survive contact with complexity.

SlopBurn takes that metaphor seriously and turns it into an interface for software quality.

## Vibecoding As Dungeon Descent

Most of the time, AI coding tools present software work as a flat surface. You ask for something, the model gives you something back, and the interaction repeats.

But that is not what the work actually feels like.

What it actually feels like is descent. You enter a system. You find signals of danger. You try to identify the active threat. You inspect weakpoints. You prepare an attack. You commit code. You run tests. You survive or you do not. Then you decide whether to push deeper or retreat to regroup.

That is a roguelike loop.

And once you see vibecoding that way, a lot of design choices become obvious. Bugs are monsters. Test obligations are weakpoints. Verification is combat. Rooms and routes represent different kinds of engineering pressure. Recovery, progression, and build identity all become meaningful instead of decorative.

The metaphor stops being skin-deep and starts becoming a better map of the work itself.

That is what SlopBurn is trying to do: not gamify coding from the outside, but reveal the game structure that is already there.

## Why Quality Belongs At The Center

If vibecoding is a dungeon, then software quality is what determines whether the run is real or fake.

Anyone can generate code. The hard part is knowing whether the system still holds. The hard part is discovering what is actually fragile, what proof counts, what regressions are still alive, and what kind of move the current room justifies.

That is why SlopBurn is a **QA roguelike RPG**, not just a coding game.

It is built around the idea that quality work should be the main loop, not an afterthought. You are not just summoning code out of a language model. You are scouting, testing, verifying, hardening, and clearing chambers in a living system.

The point is not output volume.

The point is whether you can descend into a codebase and come back with stronger guarantees.

## Depth-First, Not Breadth-First

This is the first strong stance of SlopBurn on agentic orchestration: **depth, not breadth, is the bottleneck of production-quality agentic coding.**

Too much AI tooling today encourages a breadth-first mode of work: many branches, many suggestions, many parallel directions, lots of surface area. That has value, but it also makes it easy to mistake expansion for progress.

SlopBurn takes the opposite stance. It is built around **depth-first descent**.

Pick the chamber. Study the threat. Stay with the problem. Earn real proof before moving on.

That is not just a stylistic preference. It is a theory of software quality.

Most serious quality problems do not get solved by sampling more possibilities. They get solved by staying with the issue long enough to understand its real shape. Reliability problems, test gaps, flaky behaviors, subtle regressions, and missing invariants all reward depth. They do not reward wandering.

The roguelike metaphor makes that natural. You do not win by looking at every corridor at once. You win by surviving the room you chose to enter.

## Real Specialization Through Spec And Prompting

The second strong stance in SlopBurn is that agent specialization should be real.

Most tools talk about specialization loosely. In practice, that often means a prompt with a slightly different tone: be more strategic, be more senior, be more performance-oriented. The label changes, but the underlying behavior barely does.

SlopBurn tries to make specialization structural.

Just as an RPG character levels up in Strength, Constitution, Agility, and Wisdom, a SlopBurn character becomes specialized in dimensions that match the technical debt they are trying to address. The Cutline MCP Server provides calibrated support through custom prompts to your coding agent, specialized by the attributes of your character.

### Strength

Strength represents forceful implementation: big changes, bottleneck-breaking, and the kind of code surgery that actually clears a room.

### Agility

Agility represents precision: surgical edits, careful rerouting, and handling fragile flows without waking three more monsters.

### Constitution

Constitution represents endurance: surviving ugly systems, absorbing setbacks, and staying alive through repeated verification cycles. It naturally fits reliability work.

### Wisdom

Wisdom represents judgment: threat assessment, pattern recognition, and knowing what kind of move the room is really asking for.

What matters is that progression is not just "more output." Leveling up means choosing what kind of engineer, dungeon diver, and agent commander you are becoming.

That is the point of the stat system in SlopBurn: to use RPG character progression to give a metaphorical vocabulary to software quality and skill specialization.

Again, the roguelike metaphor helps. In a real roguelike, a heavy fighter, a cautious caster, and a glass-cannon build should not approach the same room in the same way. SlopBurn applies that idea to agentic software work.

## What SlopBurn Actually Does

At a practical level, SlopBurn turns your software project into a dungeon run.

It scans the terrain, spawns threats from real software-quality issues, organizes those threats into chambers and monsters, and gives you a run-state that evolves over time. You, as a SlopBurn character, inspect rooms, reveal weakpoints, plan attacks, and roll verification. Passing tests can deal damage.

As you keep going, your character advances. Your build sharpens. Your loadout matters more. The system becomes better at helping you in the style your run has earned.

Progression is not just "more AI." It is more situated orchestration.

That makes the workflow feel much closer to the true emotional shape of vibecoding:

- uncertainty
- commitment
- consequence
- recovery
- deeper descent

That is why the text-first form matters so much. SlopBurn works because vibecoding itself already happens through textual intent. The dungeon is made of descriptions, prompts, tests, logs, and choices. It does not need a visual layer to become game-like.

It already is.

## The Bigger Bet

The bigger bet behind SlopBurn is that the untapped metaphor of an RPG unlocks new possibilities in agentic software engineering.

In roguelike vibecoding, the right interface should acknowledge stakes, progression, specialization, and consequence. It should help you understand not just what code could be written, but what room you are in, what threat is active, and what kind of move is justified now.

SlopBurn is the world's first vibecoding QA roguelike RPG.


SlopBurn: The World's First Vibecoding QA Roguelike RPG

Vibecoding: The Payday Lender of Technical Debt


# Vibecoding Whack-a-Mole: Why Fixing AI-Generated Code Keeps Breaking Everything Else

*You fix the auth. It breaks the database. You fix the database. It breaks the error handling. Sound familiar?*

---

> **Vibecoding whack-a-mole** is the phenomenon where fixing one issue in AI-generated code breaks something else, creating an endless cycle of cascading rework. It happens because AI coding agents generate code without knowledge of your codebase's implicit architectural constraints — the accumulated rules about error handling, auth patterns, data flow, and middleware ordering that the LLM can't see.

There's a moment every vibecoder knows. You've prompted Cursor (or Copilot, or Claude Code) to build a feature. It looks great. You start testing — and something from two features ago is broken. You fix it. Something else breaks. Fix that. Another thing. You're not building anymore. You're playing whack-a-mole with your own codebase.

This is the **vibecoding whack-a-mole problem**, and it's the single biggest reason AI-assisted prototypes stall before reaching production.

It's not a skill issue. It's a structural one.

## The Anatomy of Vibecoding Whack-a-Mole

To understand why this happens, you need to understand how AI coding agents make decisions.

When you prompt an LLM to "add Stripe billing to the app," it generates code based on:

1. **Your prompt** — what you asked for
2. **Visible context** — open files, recent edits, whatever's in the context window
3. **Training distribution** — what "Stripe billing" typically looks like across millions of codebases

Notice what's missing: **your specific architectural constraints.** The implicit rules your codebase has accumulated — how you handle errors, how transactions are scoped, which middleware runs on which routes, how data flows between services.

The LLM doesn't know about these constraints. So it generates code that's *locally correct* (this Stripe integration works in isolation) but *globally inconsistent* (it violates your error handling pattern, uses a different database connection strategy, and bypasses your auth middleware).

When you fix the auth middleware issue, the fix changes the request context shape. Now the database query downstream breaks because it expected the old context shape. You fix the database query. Now the error serializer doesn't recognize the new error type. Whack-a-mole.

## Why This Gets Worse Over Time

Early vibecoding feels magical. Your codebase is small, constraints are few, and the LLM's training-data defaults are "close enough." This is the **vibecoding honeymoon**.

But constraints accumulate non-linearly. A codebase with 5 features might have 8 constraints. A codebase with 20 features has 60+ constraints, many of them implicit and interconnected. And here's the critical insight: **the number of potential constraint violations grows combinatorially with codebase size.**

This is the **[vibecoding cliff](/blog/posts/how-to-productionalize-vibecode)**. The point where the cost of fixing AI-generated constraint violations exceeds the time saved by AI-assisted generation. Most vibecoded projects hit this cliff between features 15 and 30.

### The Cliff in Numbers

We analyzed constraint violations across vibecoded projects at different maturity stages:

| Project Stage | Features | Avg. Constraints | Violation Rate per Feature | Rework Hours per Feature |
|---|---|---|---|---|
| Early (prototype) | 1–5 | 3–8 | 0.2 | 0.5h |
| Growth | 6–15 | 15–40 | 1.4 | 2.5h |
| Pre-production | 16–30 | 40–100+ | 3.8 | 6–10h |
| Production-ready | 30+ | 100+ | 5+ | 10–20h |

At the prototype stage, vibecoding saves massive time. By the pre-production stage, you're spending more time on rework than you saved on generation. That's the cliff.

## The Three Patterns of Whack-a-Mole

Not all whack-a-mole is the same. It follows three distinct patterns, each with a different root cause:

### Pattern 1: The Invisible Dependency Chain

**What it looks like:** You change Service A. Service B breaks. You didn't know B depended on A.

**Root cause:** LLMs generate code against local context. They don't traverse your dependency graph. If Service B depends on Service A through two intermediate modules, the LLM has no way to know that changing A's return type will cascade.

**Example:** You ask the LLM to refactor your user model to add a `displayName` field. It updates the model, the API endpoint, and the frontend component. But the notification service — three modules away — parses the user object and breaks on the unexpected field. The LLM never saw the notification service code.

### Pattern 2: The Contradictory Constraint

**What it looks like:** You add a feature that works perfectly, but it violates a constraint from an older feature. Fixing one breaks the other.

**Root cause:** Your codebase has accumulated constraints that partially contradict each other, and the LLM doesn't have a way to detect or resolve these conflicts. This is especially common with security constraints ("all endpoints must be authenticated") vs. usability requirements ("the onboarding flow must work without auth").

**Example:** Your billing endpoint requires admin authentication. The LLM adds it. But your webhook handler — which Stripe calls without auth — uses the same route pattern. The auth middleware rejects Stripe's webhooks. You add an exception for webhooks, but now you've opened a potential bypass path that your security constraint was supposed to prevent.

### Pattern 3: The NFR Erosion

**What it looks like:** Each feature individually seems fine, but gradually, your non-functional requirements (performance, security, data consistency) are eroding.

**Root cause:** LLMs optimize for the stated requirement ("add feature X") and ignore unstated non-functional requirements. Each generated function is slightly less performant, slightly less secure, slightly less consistent than a senior engineer would write. Over 20 features, these slight degradations compound into system-level problems.

**Example:** The LLM generates each database query correctly, but uses `SELECT *` instead of selecting specific columns. Each query is "fine" individually. At scale, you have 40 queries returning 3x more data than needed, and your p95 latency has quietly tripled.

## Why "Better Prompts" Don't Fix This

The instinct is to prompt better. Add more instructions. Write a longer system prompt. Attach your architecture docs.

This helps — briefly. Then it stops helping. Here's why:

### The context window is a flat list, not a graph

Your codebase has a *graph* of dependencies and constraints. The LLM's context window is a *list* of tokens. When you paste architectural docs into context, you lose the graph structure. The LLM can't traverse dependencies it can't see. It can't detect conflicts between constraints that appear 40,000 tokens apart in the context.

### Natural language constraints are ambiguous

"Use our standard error handling pattern" means something precise to your team. To an LLM, it's a probabilistic interpretation that might match your pattern 70% of the time. That 30% miss rate is where whack-a-mole starts.

### Constraint coverage decreases as codebases grow

You can't enumerate every constraint in every prompt. As your codebase grows, the ratio of constraints-in-context to total-constraints decreases. At some point, the LLM is operating without knowledge of most of your architectural rules.

## The Structural Fix: Constraint Graphs

Whack-a-mole isn't a prompting problem. It's a *representation* problem. Your constraints need to be represented in a structure that:

1. **Maps dependencies explicitly** — so constraint violations can be detected *before* code generation
2. **Propagates non-functional requirements** — so inherited constraints aren't lost
3. **Detects conflicts proactively** — so contradictory constraints are surfaced before they cause rework
4. **Injects contextually** — so only relevant constraints are provided per task, preserving the constraint-to-token ratio

This is what a constraint graph does. It's a directed property graph where:

- **Nodes** represent features, components, and data types in your system
- **Edges** represent relationships: DEPENDS_ON, REQUIRES, HANDLES, GOVERNED_BY, BOUNDED_BY
- **Constraints** attach to nodes as typed non-functional requirements (security, performance, data-integrity, scalability)
- **Propagation rules** ensure that when a parent node has a constraint, dependent nodes inherit it

### How This Kills Whack-a-Mole

**Pattern 1 (Invisible Dependencies):** The graph makes every dependency chain explicit. Before the LLM generates code that touches Service A, the graph identifies every downstream dependency and injects their constraints into context. The notification service's expectations are now visible.

**Pattern 2 (Contradictory Constraints):** The graph runs conflict detection across all constraint pairs. "All endpoints authenticated" vs. "webhooks must work without auth" is flagged as a conflict *before* code is written. The developer resolves the conflict explicitly (e.g., "webhooks use signature verification instead of JWT auth"), and both constraints are satisfied.

**Pattern 3 (NFR Erosion):** Every node in the graph carries its non-functional requirements. The LLM doesn't generate `SELECT *` because the performance constraint on the database layer specifies column-level selection. NFRs aren't eroded because they're explicitly present in every relevant prompt.

## The Before and After

**A vibecoded checkout flow without constraints:**

- Prompt 1: "Add checkout flow" — works but uses wrong auth pattern
- Fix auth — breaks session handling
- Fix sessions — error format doesn't match API spec
- Fix errors — payment webhook bypasses rate limiter
- Fix rate limiting — latency spikes from unoptimized queries
- Fix queries — tests break because mock structure changed
- **Total: 6+ correction cycles, 3–4 hours of rework**

**The same feature with a constraint graph:**

- Graph identifies: auth middleware (JWT), session constraints, error schema, webhook signature verification, rate-limit config, query performance bounds
- All constraints injected with the initial prompt
- LLM generates code that satisfies all six constraints
- **Total: 1 prompt, minor manual review, ~20 minutes**

That's not a marginal improvement. It's a category change in how AI-assisted development works.

## Recognizing When You're on the Cliff

You're approaching (or already past) the vibecoding cliff if:

- **Fix frequency is increasing.** Each new feature triggers more fixes to existing features than the last one did.
- **You're writing longer and longer prompts.** Your prompts are becoming mini-architecture docs to compensate for the LLM's lack of context.
- **"It was working yesterday" is becoming a daily phrase.** Code that passed review last week is broken by this week's changes.
- **You're afraid to refactor.** Changing existing code feels dangerous because you don't know what might break downstream.
- **Your AI agent is getting "dumber."** It's not — your codebase is getting more constrained, and the agent doesn't know about the constraints.

If this describes your workflow, you're paying the whack-a-mole tax. The question isn't whether to fix it, but how much rework you'll accumulate before you do.

## From Whack-a-Mole to First-Draft Correct

The vibecoding revolution is real — AI-assisted development is genuinely faster for initial generation. But "faster to a first draft" isn't the same as "faster to production." The gap between those two states is filled with constraint violations, dependency cascades, and NFR erosion.

Closing that gap requires giving AI coding agents the same thing senior engineers carry in their heads: a structured understanding of how every piece of the system relates to every other piece, and what rules govern those relationships.

That's what a constraint graph provides. Not more context. Not better prompts. A fundamentally different *representation* of your system's architectural boundaries that makes constraint-aware code generation the default, not the exception.

[Cutline](/start) builds this graph automatically from your product requirements, propagates constraints through dependency chains, detects conflicts before they cause rework, and injects the right constraints into every prompt you send to your AI coding tool.

The result: vibecoded prototypes that don't hit the cliff. Features that ship without whack-a-mole. First drafts that a senior engineer wouldn't need to rewrite.

---

## FAQ

**Q: What is vibecoding whack-a-mole?**

Vibecoding whack-a-mole is the phenomenon where fixing one issue in AI-generated code breaks something else, creating an endless cycle of cascading rework. It happens because AI coding agents generate code without knowledge of your codebase's implicit architectural constraints.

**Q: What is the vibecoding cliff?**

The vibecoding cliff is the point where the cost of fixing AI-generated constraint violations exceeds the time saved by AI-assisted generation. Most vibecoded projects hit this cliff between features 15 and 30, when the codebase has accumulated 40-100+ implicit constraints and rework hours per feature reach 6-10 hours.

**Q: Why does fixing AI-generated code break other things?**

AI-generated fixes break other things because of three patterns: invisible dependency chains (changing Service A breaks Service B through intermediate modules the LLM can't see), contradictory constraints (security requirements conflict with usability requirements), and NFR erosion (each feature is slightly less performant or secure, compounding into system-level problems).

**Q: What is a constraint graph?**

A constraint graph is a directed property graph where nodes represent features, components, and data types, edges represent relationships like DEPENDS_ON and GOVERNED_BY, and constraints attach as typed non-functional requirements. It maps dependencies explicitly, propagates inherited constraints, detects conflicts proactively, and injects only relevant constraints per task.

**Q: How many features before vibecoding breaks down?**

Vibecoding typically breaks down between features 15-30. At the prototype stage (1-5 features), rework is minimal at 0.5 hours per feature. By pre-production (16-30 features, 40-100+ constraints), the violation rate reaches 3.8 per feature with 6-10 hours of rework each.

---

*Cutline is the constraint layer for AI-assisted development. Stop playing whack-a-mole with your vibecoded codebase. [Try it free →](/start)*


Vibecoding Whack-a-Mole: Why Fixing AI-Generated Code Keeps Breaking Everything Else


# The Vibecoding Debt Spiral: Why AI-Generated Code Accumulates Technical Debt 5x Faster

*Your codebase is six weeks old and already feels like a legacy system. That's not normal tech debt. That's vibecoding debt.*

---

> **Vibecoding tech debt** is the accumulation of architectural inconsistencies, implicit design decisions, and non-functional requirement gaps that result from generating code with AI coding tools — like Cursor, Copilot, or Bolt — without a persistent constraint system to enforce cross-session consistency. Unlike traditional tech debt, which is localized and chosen, vibecoding debt is distributed across every file, invisible to standard tooling, and compounds exponentially because the LLM feeds on its own inconsistency.

Every codebase accumulates technical debt. That's not new. What's new is the *speed* at which vibecoded codebases accumulate it — and the specific shape of the debt that makes it uniquely hard to pay down.

Traditional tech debt comes from conscious shortcuts: "We'll refactor this later." You know where it is. You chose to take it on. You can plan to fix it.

Vibecoding debt is different. It's **invisible, inconsistent, and distributed**. You didn't choose it. The LLM chose it for you — one plausible-but-slightly-different implementation at a time — and you didn't notice because each individual feature looked fine.

Six weeks later, you have 15 features built on 15 subtly different patterns, and the codebase fights you on every change.

## What Makes Vibecoding Debt Different

Traditional technical debt has a known shape. You cut a corner on the database schema. You skipped writing tests. You copied some code instead of abstracting it. The debt is *localized* — you know where it lives, and you can estimate the cost of repaying it.

Vibecoding debt has five properties that make it fundamentally harder to manage:

### 1. It's Distributed, Not Localized

An LLM generates each feature independently. It doesn't remember the patterns from the last feature. So your codebase ends up with three different error handling patterns, two authentication approaches, and four ways to validate input — all "correct" in isolation, all inconsistent with each other.

The debt isn't in any single file. It's in the *relationships between* files. And that makes it nearly invisible in code review.

### 2. It's Implicit, Not Chosen

With traditional debt, a developer consciously decides: "I'm going to hardcode this for now." With vibecoding debt, the LLM makes dozens of micro-decisions per feature — which pattern to use, how to structure the data, what to name things, how to handle edge cases — and none of those decisions are surfaced as choices. They just happen.

You didn't choose to have three different error formats. The LLM generated them across three different sessions, and each one seemed reasonable at the time.

### 3. It Compounds Non-Linearly

Each new inconsistency makes the next feature more likely to introduce more inconsistencies. When the LLM reads your codebase for context and finds three different patterns for the same thing, it has to pick one — or invent a fourth. The more inconsistent your codebase, the more inconsistent the LLM's output becomes.

This is a feedback loop. Traditional debt grows linearly. Vibecoding debt grows exponentially.

### 4. It's Hard to Detect with Standard Tooling

Linters catch syntax issues. Type checkers catch type errors. But no standard tool catches "this endpoint uses a different error response shape than every other endpoint" or "this service creates its own database connection instead of using the shared pool."

Pattern inconsistency is a semantic problem, not a syntactic one. It slips through every automated check.

### 5. It Resists AI-Assisted Refactoring

Here's the irony: the same LLM that created the inconsistency can't reliably fix it. When you ask an AI agent to "standardize the error handling," it sees all the existing patterns, picks the most common one (or invents a new one), and applies it — but without understanding *why* each pattern exists, it breaks the edge cases those patterns were handling.

You end up in the [vibecoding whack-a-mole](/blog/posts/vibecoding-whack-a-mole) cycle: fixing one inconsistency introduces two new ones.

## The Five Debt Patterns LLMs Create

After analyzing vibecoded codebases across dozens of projects, the same five patterns appear repeatedly:

### Pattern 1: The Style Drift

**What it looks like:** Inconsistent naming conventions, code organization, and structural patterns across files generated in different sessions.

**Example:** Your user service uses `getUserById`, your billing service uses `fetchBillingRecord`, and your notification service uses `retrieveNotification`. Three conventions for the same operation. Multiply this across every function, variable, and module in a 20-feature codebase.

**Why it matters:** Style drift makes the codebase harder to navigate, increases onboarding time for new developers, and causes the LLM itself to produce increasingly inconsistent output as it reads the codebase for context.

### Pattern 2: The Abstraction Gap

**What it looks like:** Duplicated logic that should have been abstracted, or premature abstractions that don't fit the actual usage patterns.

**Example:** You have five endpoints that each implement their own pagination logic — slightly different cursor formats, different default page sizes, different response shapes. Or the LLM created an elaborate `BaseService` class after the second endpoint, but by the fifth endpoint, three of them have deviated from the base class because it didn't fit their needs.

**Why it matters:** Every duplicated implementation is a maintenance multiplier. Fix a pagination bug and you need to fix it in five places. Miss one and you have an inconsistency that will confuse the LLM further.

### Pattern 3: The Dependency Tangle

**What it looks like:** Circular dependencies, over-coupled modules, and implicit contracts between components that the LLM created without a coherent dependency strategy.

**Example:** Your auth middleware imports from the user service. Your user service imports from the billing service (to check subscription status). Your billing service imports from the auth middleware (to verify webhook signatures). Circular dependency. Each import made sense when the LLM generated it in isolation.

**Why it matters:** Dependency tangles make changes cascade unpredictably. They also make it impossible to test or deploy components independently, which kills your ability to iterate fast — the very thing vibecoding was supposed to enable.

### Pattern 4: The Configuration Scatter

**What it looks like:** Environment variables, magic numbers, timeout values, and configuration scattered across files instead of centralized.

**Example:** Your Stripe API key is in `process.env.STRIPE_KEY` in one file, `process.env.STRIPE_API_KEY` in another, and hardcoded in a test file. Your rate limit is 100 in the API gateway, 150 in the middleware, and 50 in the client-side config. The LLM generated each default independently.

**Why it matters:** Configuration scatter turns routine changes (updating an API key, adjusting a rate limit) into archaeology expeditions. It also creates subtle bugs where two parts of the system disagree on a fundamental parameter.

### Pattern 5: The Silent Contract

**What it looks like:** Implicit assumptions between components that aren't enforced by types, tests, or documentation.

**Example:** Service A returns user objects with a `createdAt` field as an ISO string. Service B parses it as a Unix timestamp. Both work in testing because the LLM happened to generate compatible test data. In production, it fails silently — dates are wrong, but no error is thrown.

**Why it matters:** Silent contracts are the most dangerous form of vibecoding debt because they produce bugs that are correct *enough* to pass testing but wrong *enough* to cause real damage. They only surface under production conditions.

## The Compounding Cost

Vibecoding debt doesn't just slow you down linearly. It compounds:

| Codebase Age | Features | Avg. Inconsistencies | Time per New Feature | Rework Ratio |
|---|---|---|---|---|
| Week 1-2 | 1-5 | 2-5 | 2 hours | 10% |
| Week 3-4 | 6-12 | 15-30 | 4 hours | 30% |
| Week 5-8 | 13-20 | 40-80 | 8 hours | 50% |
| Week 9+ | 20+ | 80+ | 12+ hours | 65%+ |

By week 8, you're spending more time fighting your own codebase than building new features. The rework ratio — the percentage of development time spent on fixing inconsistencies rather than shipping value — crosses 50%.

This is the [vibecoding cliff](/blog/posts/how-to-productionalize-vibecode). Most teams hit it between features 15 and 25.

## The Structural Fix: Enforced Consistency Through Constraint Graphs

The root cause of vibecoding debt is that LLMs have no mechanism to enforce consistency across sessions. Each generation is stateless. The LLM doesn't carry forward "this is how we do error handling in this codebase" as a binding constraint — it carries it forward as a probabilistic suggestion that gets weaker as the codebase grows more inconsistent.

The fix isn't better prompting. It's giving the LLM a **structural representation of your architectural patterns** that persists across sessions and scales with your codebase.

A [constraint graph](/blog/posts/vibecoding-whack-a-mole) does this by:

1. **Encoding patterns as enforceable constraints** — "All API endpoints use the `ApiError` class with standard error codes" isn't a suggestion in a README. It's a typed constraint attached to every endpoint node in the graph.

2. **Propagating constraints through dependencies** — When your user service has a data-privacy constraint, every component that depends on it inherits that constraint automatically. The LLM can't "forget" it.

3. **Detecting inconsistencies before they ship** — The graph compares new code against existing patterns and flags deviations: "This endpoint returns errors as `{ error: string }` but 14 other endpoints use `{ error: { code, message, details } }`."

4. **Providing session-persistent context** — Unlike a README or `.cursorrules` file that competes for attention in the context window, the constraint graph injects *only the relevant constraints* for the current task. The error handling pattern appears when you're building an endpoint, not when you're writing a migration.

The result: each feature reinforces the codebase's patterns instead of eroding them. The debt curve flattens instead of compounding.

## Recognizing Vibecoding Debt in Your Codebase

You likely have vibecoding debt if:

- **Grep reveals multiple patterns for the same thing.** Search for error handling, database connections, or API response formats. If you find 3+ variations, you have debt.
- **New features keep breaking old features.** This is the whack-a-mole symptom of accumulated inconsistency.
- **The LLM's suggestions are getting worse.** It's not the model — it's reading your inconsistent codebase and producing increasingly inconsistent output.
- **You're writing longer and longer prompts.** You're compensating for the LLM's lack of pattern knowledge by manually injecting it every time.
- **Onboarding a new developer (or a new AI agent) is painful.** If a human can't quickly understand "how we do things here," neither can an LLM.

## How to Pay Down Vibecoding Tech Debt

If you're already deep in vibecoding debt, here's the step-by-step triage:

### Step 1: Audit your highest-frequency patterns

What operations happen in every feature? Error handling, auth, database access, API responses. Run `grep` across your codebase and count how many distinct implementations exist for each. If you find 3+ variations of the same operation, that's your starting point.

### Step 2: Pick one canonical implementation

Don't invent a new pattern. Pick the best existing one and designate it as the standard. The goal is convergence, not novelty.

### Step 3: Encode the pattern as a constraint, not a document

A README gets ignored. A `.cursorrules` file competes for context window space. A [constraint graph node](/blog/posts/product-context-for-ai-agents) gets injected into every relevant prompt automatically — "All API endpoints use the `ApiError` class with standard error codes" becomes an enforceable rule, not a suggestion.

### Step 4: Refactor one pattern at a time

Standardize a single pattern in isolation. Don't try to fix everything at once — that's how you trigger a cascade of new inconsistencies. Validate each standardization before moving to the next.

### Step 5: Prevent new debt on every future feature

Once a pattern is encoded as a constraint, every future feature built through the constraint graph follows it automatically. The debt stops growing. Each new feature reinforces the standard instead of eroding it.

## The Takeaway

Vibecoding made building fast. It also made debt accumulation fast. The speed that feels magical in week one becomes a liability by week eight — not because the code is bad, but because each piece of code is *differently good* in ways that compound into systemic inconsistency.

The solution isn't to stop vibecoding. It's to give your AI agent what it's missing: a persistent, structural understanding of how your codebase works, so every feature it generates reinforces the system instead of fragmenting it.

---

## FAQ

**Q: What is vibecoding tech debt?**

Vibecoding tech debt is the accumulation of architectural inconsistencies, implicit design decisions, and non-functional requirement gaps that result from generating code with AI coding tools like Cursor, Copilot, or Bolt without a persistent constraint system to enforce cross-session consistency. Unlike traditional tech debt, it is distributed across every file, invisible to standard tooling, and compounds exponentially because the LLM feeds on its own inconsistency.

**Q: Why does vibecoding create tech debt faster than normal development?**

Vibecoding creates tech debt faster because each AI generation is stateless — the LLM doesn't carry forward architectural decisions across sessions. Every feature introduces subtly different patterns for error handling, auth, data access, and naming. These inconsistencies compound non-linearly: the more inconsistent the codebase, the more inconsistent the LLM's next output becomes.

**Q: How do you detect vibecoding tech debt?**

You can detect vibecoding tech debt by grepping for multiple patterns serving the same purpose (3+ error formats, multiple auth approaches), noticing that new features keep breaking old ones, observing that the LLM's suggestions are getting worse over time, or finding that onboarding new developers or AI agents is painful. Standard linters and type checkers won't catch it because it's a semantic problem, not a syntactic one.

**Q: How do you pay down vibecoding tech debt?**

Pay down vibecoding debt in five steps: (1) identify your highest-frequency patterns like error handling and auth, (2) pick one canonical implementation as the standard, (3) encode it as a constraint in a constraint graph rather than a README, (4) refactor one pattern at a time incrementally, and (5) prevent new debt by running every future feature through the constraint graph.

**Q: Can AI fix its own tech debt?**

Not reliably. The same LLM that created the inconsistency can't fix it without understanding *why* each pattern exists. Asking an AI to "standardize the error handling" often breaks edge cases those patterns were handling, creating a whack-a-mole cycle where fixing one inconsistency introduces two new ones. The fix requires a structural layer — a constraint graph — that persists the architectural context the LLM is missing.

---

*Cutline builds a constraint graph from your product requirements and injects architectural boundaries into every AI coding session. Stop accumulating vibecoding debt. [Try it free →](/start)*
