Posts

Vibecoding: The Payday Lender of Technical Debt

Red-Green Refactoring for AI Agents: How Cutline Stabilizes Your Vibecoding


# Why LLMs Ignore Your Non-Functional Requirements (And How to Fix It)

*You asked the AI to build a search feature. It built a search feature. It's also slow, inaccessible, unobservable, and doesn't handle errors. You forgot to ask for those parts.*

---

> **Non-functional requirements (NFRs) in AI-generated code** are the quality attributes — performance, security, observability, accessibility, and reliability — that LLMs systematically ignore because they're implicit, cross-cutting, and absent from prompts. NFR coverage actually *decreases* as vibecoded projects grow: from 25% at the prototype stage to just 12% in production codebases, because the total NFR count grows faster than any human can track in prompts.

There are two kinds of requirements in software:

**Functional requirements** describe *what* the system does: "Users can search products by name." "The checkout flow processes payments." "Admins can export reports as CSV."

**Non-functional requirements (NFRs)** describe *how well* the system does it: "Search returns results in under 200ms." "Payment processing retries on transient failures." "Reports are accessible to screen readers." "All API calls are logged with correlation IDs."

LLMs are remarkably good at functional requirements. Describe what you want, and you'll get working code that does the thing.

LLMs are remarkably bad at non-functional requirements. And this isn't a temporary limitation waiting for the next model release. It's a structural mismatch between how NFRs work and how LLMs generate code.

## The Five NFR Categories LLMs Ignore

### 1. Performance

**What you need:** P95 response time under 200ms. Efficient database queries. Pagination on large collections. Connection pooling. Caching for repeated reads.

**What you get:** Functionally correct code that fetches all records, processes them in memory, makes a new database connection per request, and returns the full dataset without pagination.

**Why:** The LLM optimizes for *correctness*, not *efficiency*. `SELECT * FROM products` is correct. It also falls over with 100,000 rows. Performance requires understanding the production data volume, which isn't in the prompt.

### 2. Security

**What you need:** Input validation. Parameterized queries. Auth on all endpoints. Rate limiting. Secret management. CORS restrictions.

**What you get:** Code that trusts all input, uses string interpolation for queries, and skips auth on the "obvious" endpoints. (See our full breakdown of [AI-generated code security vulnerabilities](/blog/posts/ai-generated-code-security).)

**Why:** Security is the absence of vulnerabilities — a negative requirement. LLMs generate what should be *present*, not what should *not* be possible. Secure defaults require explicit constraint injection.

### 3. Observability

**What you need:** Structured logging with request context. Error tracking with stack traces. Metrics for latency, error rates, and throughput. Distributed tracing for multi-service architectures.

**What you get:** `console.log('done')`. Maybe a try-catch that swallows the error silently. No correlation IDs. No metrics. No way to debug issues in production.

**Why:** Observability has zero impact on whether the feature "works" in development. The LLM generates code that passes the functional test. That the code is impossible to debug in production is not a concern the model has any reason to surface.

### 4. Accessibility

**What you need:** WCAG 2.1 AA compliance. Semantic HTML. Keyboard navigation. Screen reader compatibility. Color contrast ratios. Focus management.

**What you get:** A `<div>` where there should be a `<button>`. Click handlers without keyboard equivalents. Color as the only indicator of state. Missing `aria-label` attributes. Form inputs without associated labels.

**Why:** Accessibility requirements are rarely in the prompt and underrepresented in training data. Most web code in the training distribution doesn't follow WCAG guidelines. The LLM generates what web code "usually looks like" — which is inaccessible.

### 5. Reliability

**What you need:** Retry logic with exponential backoff. Circuit breakers for external services. Graceful degradation when dependencies fail. Timeouts on all external calls. Dead letter queues for failed jobs.

**What you get:** A single `await fetch(url)` with no timeout, no retry, no error handling, and no fallback. If the external service is down, your feature crashes.

**Why:** Reliability patterns add complexity that doesn't affect the happy path. The LLM generates happy-path code because that's what matches the prompt. Failure handling requires anticipating *what could go wrong* — a reasoning task that current LLMs don't perform unprompted.

## Why Prompting NFRs Doesn't Scale

The obvious fix is to prompt for NFRs explicitly: "Build a search endpoint with 200ms P95 latency, parameterized queries, structured logging, keyboard-navigable results, and retry logic on the database connection."

This works for one feature. It falls apart at scale for three reasons:

### 1. NFR Lists Get Impossibly Long

A mature product has 50-200+ NFRs across the five categories. You can't paste all of them into every prompt. Even if you could, the LLM can't prioritize 200 constraints simultaneously — attention is finite, and constraints at the bottom of the context window get less weight than constraints at the top.

### 2. NFRs Are Inherited, Not Listed

Some NFRs apply directly to a component. Others are *inherited* through dependency chains. If your `UserService` has a PII-handling constraint, then `BillingService` (which calls `UserService` to get the user's email) inherits that constraint. And `NotificationService` (which calls `BillingService`) inherits it too.

These inherited constraints can't be listed per-feature because they depend on the dependency graph. You'd need to trace every dependency chain for every feature to enumerate the full NFR set — which is exactly the kind of graph traversal that humans do poorly and LLMs can't do at all from a flat prompt.

### 3. NFRs Conflict and Require Tradeoffs

"All endpoints must be authenticated" conflicts with "The webhook handler must accept unauthenticated requests from Stripe." "Responses must be under 200ms" conflicts with "All responses must be encrypted end-to-end." "UI must be fully accessible" conflicts with "Use this custom drag-and-drop library that doesn't support keyboard navigation."

Resolving NFR conflicts requires judgment — understanding which requirement takes priority in context, and designing a solution that satisfies both or explicitly accepts the tradeoff. LLMs in a flat prompt will silently pick one and ignore the other.

## The NFR Coverage Gap

We analyzed NFR coverage across vibecoded projects at different maturity stages:

| Project Stage | Features | Total NFRs | NFRs Explicitly Prompted | Coverage |
|---|---|---|---|---|
| Prototype | 1-5 | 10-20 | 3-5 | 25% |
| Growth | 6-15 | 30-60 | 8-12 | 20% |
| Pre-production | 16-30 | 60-150 | 15-25 | 15% |
| Production | 30+ | 100-200+ | 20-30 | 12% |

NFR coverage *decreases* as the project grows. The ratio of prompted NFRs to total NFRs gets worse because the total grows faster than any human can track in prompts.

The result: the larger your vibecoded project, the more unaddressed non-functional requirements lurk in the codebase. These aren't bugs — everything "works." They're quality gaps that manifest as slow pages, security incidents, undebuggable outages, and accessibility complaints.

## The Fix: Constraint Propagation

The structural solution to the NFR problem has three parts:

### 1. Make NFRs Explicit

Every non-functional requirement gets encoded as a typed constraint in a [constraint graph](/blog/posts/vibecoding-whack-a-mole). Not prose in a Confluence doc. A machine-readable node with:

- **Category:** security, performance, scalability, stability, compliance
- **Severity:** critical, warning, info
- **Scope:** which components it applies to
- **Action:** what the code must do to satisfy it

```
[CRITICAL:SECURITY] All API endpoints must validate input with Zod schema
  → Applies to: all entities of type 'endpoint'
  → Action: Import and apply validation schema before processing request body
```

### 2. Propagate Through Dependencies

When a constraint is attached to a component, all components that depend on it inherit the constraint automatically. The graph handles this — no manual tracking required.

```
UserService [PII-handling constraint]
  └── BillingService (depends on UserService) → inherits PII constraint
       └── NotificationService (depends on BillingService) → inherits PII constraint
```

When the AI builds a notification feature, the PII constraint is automatically in context — even though the developer never prompted for it. The notification service handles user email addresses because it calls through the billing service, so it must follow PII rules. The graph knows this. A flat prompt doesn't.

### 3. Inject Contextually Per-Task

The constraint graph doesn't dump all 200 NFRs into every prompt. It identifies which constraints are relevant to the current task — based on which components the code touches and their dependency chains — and injects only those.

Building a search endpoint? You get:
- Performance: P95 under 200ms, paginate results
- Security: validate search input, parameterize queries
- Observability: log search queries with correlation ID
- Accessibility: results must be keyboard-navigable

You don't get the 150 other NFRs about billing, onboarding, or admin features. The context stays focused. The constraint coverage stays high.

## NFR Categories That Matter Most

If you're starting from zero on NFR coverage, prioritize in this order:

**1. Security** — Vulnerabilities have the highest blast radius. A single missing input validation can lead to data breach. Start with the [security checklist](/blog/posts/ai-generated-code-security).

**2. Reliability** — Retry logic, circuit breakers, and graceful degradation prevent outages. Users forgive slow. They don't forgive broken.

**3. Observability** — You can't fix what you can't see. Structured logging and error tracking are prerequisites for improving everything else.

**4. Performance** — Optimize after you've shipped and have real usage data. Premature optimization is still the root of all evil, but *knowing* your performance constraints ensures the AI doesn't generate accidentally quadratic code.

**5. Accessibility** — Ethically and legally important, and increasingly a requirement for enterprise customers. Retrofit is expensive — getting it right during generation is dramatically cheaper.

## From Vibes to Standards

The promise of vibecoding is building at the speed of thought. The gap is that "the speed of thought" usually only thinks about *what* to build, not *how well* to build it.

Non-functional requirements are the difference between a prototype and a product. Between a demo that impresses and a system that survives production traffic, security probes, and real users with screen readers.

LLMs won't add NFRs unless you make them impossible to ignore. Static rules help. A constraint graph that propagates NFRs through your dependency chain and injects them contextually into every prompt? That's how you get AI-generated code that's not just functionally correct, but production-grade.

---

## FAQ

**Q: What are non-functional requirements in AI-generated code?**

Non-functional requirements (NFRs) describe how well a system performs — latency targets, security policies, accessibility standards, observability, and reliability. LLMs are excellent at functional requirements (what the system does) but systematically ignore NFRs because they're implicit, cross-cutting, and absent from the prompt.

**Q: Why do LLMs ignore non-functional requirements?**

LLMs ignore NFRs for three reasons: NFR lists get impossibly long (50-200+ in a mature product), NFRs are inherited through dependency chains that flat prompts can't represent, and NFRs conflict with each other requiring judgment to resolve tradeoffs.

**Q: What is NFR coverage in vibecoded projects?**

NFR coverage decreases as projects grow. At the prototype stage (1-5 features), about 25% of NFRs are explicitly prompted. By production (30+ features, 100-200+ NFRs), coverage drops to 12% because the total grows faster than any human can track in prompts.

**Q: How do you enforce non-functional requirements on AI-generated code?**

Enforce NFRs through constraint propagation: (1) make every NFR an explicit, typed constraint with category, severity, scope, and action, (2) propagate constraints through dependency chains so inherited requirements flow automatically, and (3) inject only the relevant constraints per task rather than dumping all 200 into every prompt.

---

*Cutline generates NFR constraints from your product requirements and propagates them through your dependency graph. Every AI-generated feature gets the right quality standards, automatically. [Try it free →](/start)*


Why LLMs Ignore Your Non-Functional Requirements (And How to Fix It)


# The Hidden Cost of Vibecoding: How LLM Token Burn Is Quietly Draining Your Engineering Budget

*Stop feeding your AI coding assistant the same context over and over. There's a better way.*

---

> **LLM token burn** is the silent, compounding cost of repeatedly re-prompting AI coding tools with architectural context they should already know. The average vibecoded feature consumes 3-5x more tokens than necessary because the LLM keeps "forgetting" authentication patterns, re-inventing database schemas, and generating code that violates constraints — triggering correction cycles that produce throwaway output at full token cost.

You just spent $47 in API credits vibecoding a checkout flow. Forty-seven dollars. Not because the feature was complex — a senior engineer could spec it in an afternoon — but because your AI coding agent kept "forgetting" your authentication pattern, re-inventing your database schema, and generating code that violated your rate-limiting constraints.

You're not alone. This is **LLM token burn**: the silent, compounding cost of repeatedly re-prompting AI coding tools with context they should already know.

And it's the dirty secret of the vibecoding revolution.

## What Is LLM Token Burn?

Token burn is what happens when developers use AI coding assistants — Cursor, GitHub Copilot, Claude Code, Windsurf — without a structured way to feed them architectural context. Every prompt that lacks constraint information triggers a cascade:

1. **The Initial Prompt** — You describe what you want. The LLM generates something plausible but architecturally naive.
2. **The Correction Cycle** — You notice it ignored your auth pattern. You re-prompt with more context. More tokens consumed.
3. **The Cascade** — The fix introduces a new conflict with your data model. Another prompt. More tokens.
4. **The Rework Loop** — By the fifth iteration, you've burned 10x the tokens the feature should have required, and the code still needs manual cleanup.

This isn't a hypothetical. In our analysis of vibecoding workflows, the average feature implementation consumes **3–5x more tokens** than necessary because architectural constraints aren't represented in a way the LLM can consistently apply.

## Why Context Windows Don't Solve This

The instinctive response is "just give the LLM more context." Paste your README. Attach your architecture docs. Write a massive system prompt.

This approach has three critical problems:

### 1. Context windows are expensive, not free

Every token in your context window costs money — both on input and the attention it requires during generation. A 128k context window stuffed with architectural documentation means you're paying for that context on every single completion, even when most of it is irrelevant to the current task.

### 2. LLMs don't prioritize constraints

When you dump a 50-page architecture doc into context, the LLM treats every paragraph with roughly equal weight. Your critical security constraint about PII handling gets the same attention as a paragraph about your team's preferred code formatting. Natural language context doesn't have a priority hierarchy.

### 3. Stale context compounds errors

Architecture docs get outdated within weeks. When your context includes constraints that no longer apply or misses new ones that do, the LLM generates code against a phantom architecture. You don't just waste tokens — you generate technical debt.

## The Math: What Token Burn Actually Costs

Let's quantify this with a real scenario. A team of three developers vibecoding a SaaS product with moderate complexity (authentication, payments, multi-tenancy):

| Activity | Tokens per Feature | Features/Week | Weekly Token Cost |
|---|---|---|---|
| Initial generation | ~4,000 | 15 | $0.90 |
| Correction prompts (avg 3x) | ~12,000 | 15 | $2.70 |
| Rework from constraint violations | ~8,000 | 8 | $0.96 |
| Context re-injection | ~20,000 | 15 | $3.00 |
| **Total** | | | **$7.56/week** |

Doesn't sound catastrophic — until you realize the correction prompts and rework are *pure waste*. That's **$3.66/week** per developer in tokens that produce throwaway output. For a 10-person team over a year, you're looking at **$1,900+ in wasted tokens** — and that's before you account for the developer time spent re-prompting instead of shipping.

The real cost isn't the API bill. It's the *velocity tax*. Every correction cycle is 5–15 minutes of developer attention redirected from building to debugging AI output.

## How a Constraint Graph Eliminates Token Burn

The fix isn't more context — it's *structured* context. Specifically, a constraint graph that represents your architectural boundaries as a traversable data structure rather than prose.

Here's how it works:

### Targeted context injection instead of context dumping

Instead of pasting your entire architecture doc into every prompt, a constraint graph identifies *which* constraints are relevant to the current task and injects only those. Building a payment endpoint? The graph surfaces your PCI compliance constraints, your rate-limiting rules, and your auth token format — not your frontend component naming conventions.

This reduces input tokens per prompt by **40–60%** while *increasing* constraint adherence.

### Constraint propagation catches violations before generation

A well-constructed constraint graph propagates non-functional requirements (NFRs) through dependency chains. If your `UserService` has a data-privacy constraint, every component that depends on `UserService` inherits that constraint automatically. The LLM doesn't need to be told about inherited constraints — they're already in the injected context.

This eliminates the "fix one thing, break another" correction cycle that accounts for most token burn.

### Deterministic boundaries, not probabilistic suggestions

LLMs are probabilistic. They generate the *most likely* next token, not the *most correct* one. When you express constraints in natural language ("make sure to use our auth pattern"), you're relying on probabilistic interpretation. When you express them as structured boundaries ("this endpoint MUST use middleware X, MUST validate JWT with algorithm Y, MUST return 401 for expired tokens"), you're giving the LLM a deterministic spec it can follow precisely.

The result: first-draft code that adheres to constraints **70% more often**, cutting correction cycles from an average of 3.2 to 0.9 per feature.

## What This Looks Like in Practice

**Without a constraint graph:**

```
Prompt 1: "Build a user registration endpoint"
→ LLM generates endpoint with basic validation (ignores your auth pattern)

Prompt 2: "Use our JWT middleware pattern, here's the code..."
→ LLM refactors but breaks the database transaction pattern

Prompt 3: "The DB writes need to be transactional, like this..."
→ LLM fixes transactions but drops rate limiting

Prompt 4: "Add rate limiting using our Redis setup..."
→ LLM adds rate limiting but the error format doesn't match your API spec

Prompt 5: "Error responses need to follow this schema..."
→ Finally something close to shippable. 5 prompts. ~24,000 tokens burned.
```

**With a constraint graph:**

```
Prompt 1: "Build a user registration endpoint"
→ Constraint graph injects: JWT middleware pattern, transaction requirements,
  rate-limit config, error schema, PII handling rules
→ LLM generates endpoint that adheres to all five constraints
→ 1 prompt. ~5,000 tokens. Minor manual review.
```

That's an **80% reduction in tokens** and a **4x reduction in developer interaction time** for the same output quality.

## The Compounding Effect

Token burn isn't just a per-feature problem — it compounds. Every constraint violation that slips through to your codebase becomes a source of *future* token burn when the LLM encounters conflicting patterns and makes inconsistent choices.

A constraint graph acts as a ratchet: each feature built with correct constraints reinforces the graph, making future features cheaper and more correct. Without it, you get the opposite — an entropy spiral where each vibecoded feature makes the next one harder.

## Getting Started

If you're burning tokens on repeated correction cycles, the path forward is:

1. **Identify your most-violated constraints.** Which architectural rules does your AI agent break most often? Auth patterns, error handling, data access patterns? These are your highest-ROI constraints to formalize.

2. **Structure them as machine-readable boundaries, not prose.** A constraint isn't "we use JWT auth" — it's a set of specific, deterministic rules about middleware ordering, token validation, and error responses.

3. **Map dependency chains.** If Service A depends on Service B, and Service B has a latency constraint, Service A inherits that constraint. Make these relationships explicit.

4. **Inject contextually, not globally.** Only surface constraints relevant to the current task. More context ≠ better context.

This is exactly what [Cutline's Constraint Graph](/start) does automatically. It ingests your product requirements, extracts the non-functional constraints most LLMs miss, maps them to a traversable dependency graph, and injects precisely the right constraints into your AI coding tool of choice.

The result: fewer tokens, fewer correction cycles, and first-draft code that a senior engineer wouldn't immediately reject.

---

## FAQ

**Q: What is LLM token burn?**

LLM token burn is the silent, compounding cost of repeatedly re-prompting AI coding tools with context they should already know. Each prompt lacking constraint information triggers correction cycles, cascading fixes, and rework loops — consuming 3-5x more tokens than necessary.

**Q: How much does vibecoding actually cost in tokens?**

A team of three developers vibecoding a moderately complex SaaS product spends roughly $7.56 per week in tokens, of which $3.66 is pure waste from correction prompts and rework. The real cost isn't the API bill — it's the developer time spent re-prompting instead of shipping.

**Q: Why don't larger context windows fix token burn?**

Larger context windows don't fix token burn because every token costs money on every completion, LLMs treat all context with roughly equal weight so critical constraints compete with formatting preferences, and stale architecture docs generate code against a phantom architecture.

**Q: How does a constraint graph reduce AI coding costs?**

A constraint graph reduces costs by injecting only relevant constraints per task (40-60% fewer input tokens), propagating constraints through dependencies to eliminate cascading fix cycles, and providing deterministic boundaries instead of probabilistic suggestions — cutting correction cycles from 3.2 to 0.9 per feature.

---

*Cutline is the constraint layer for AI-assisted development. It turns your product "vibes" into structured engineering boundaries that make vibecoded prototypes production-ready from the first prompt. [Try it free →](/start)*


The Hidden Cost of Vibecoding: How LLM Token Burn Is Quietly Draining Your Engineering Budget


# 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)*
