Vibe Coding Is a Loan: The Production Bill Arrives

§ 01 — Where the term came from

A weekend-project idea that became a methodology

We keep having the same conversation with founders and engineering leaders. It starts with “we shipped in three weeks” and ends, six to eighteen months later, with “nothing can be changed without something else breaking.” That arc now has a name, a dictionary entry, and — as of 2026 — a substantial research record.

Karpathy was explicit about the context — throwaway weekend projects. He even flagged the cost in the same post: “The code grows beyond my usual comprehension, I’d have to really read through it for a while.” That caveat did not survive contact with the market. The term went viral within days. By November 2025, Collins Dictionary had named vibe coding its Word of the Year. A social media aside had become a methodology in under twelve months.

Simon Willison — co-creator of Django, and one of the most careful voices on this subject — drew the line that matters: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.” Vibecoding, in his later formulation, is “irresponsibly building software through dice rolls, not caring what code is produced.” He proposed a name for the disciplined counterpart: vibe engineering.

This post is about what happens when organisations run the first mode at production scale — including the two objections we hear most: “our architecture is modular, we’re fine” and “we review everything anyway.” Neither survives the data.

§ 02 — The adoption wave

Everyone is using a tool half of them distrust

The adoption numbers explain why the caveat got lost. In Y Combinator’s Winter 2025 cohort, roughly a quarter of startups reported codebases ~95% AI-generated. Google’s DORA 2025 report (nearly 5,000 professionals) put AI adoption at 90% of developers, with the median user spending two hours a day with these tools. Gartner projects that by 2028, 40% of new enterprise production software will be created with vibecoding techniques — and, in the same breath, warns that ungoverned prompt-to-app development could increase software defects by 2,500% over the same horizon. Both are forecasts, not measurements. But note who is making them.

Adoption at 90%, trust at 29%. That spread — everyone using a tool almost half of them distrust — is the defining statistic of this era. The #1 frustration in the Stack Overflow survey, cited by 45% of respondents: “AI solutions that are almost right, but not quite.” The economic promise was real: the marginal cost of a working demo collapsed. The mistake was assuming the marginal cost of a maintainable system collapsed with it. It didn’t. It moved downstream — with interest.

§ 03 — The trend now

The bill arrives: four research lines, one conclusion

By 2026, the research stopped being suggestive and became convergent. Code structure is measurably decaying. GitClear’s 2026 “Maintainability Gap” report — 623 million changed lines analysed, 2023 through 2026 — is the most complete longitudinal record we have.

Developers are now roughly 5× more likely to duplicate a block than refactor one — a full inversion of the pre-AI preference. Cross-file connectivity of new code is down 35% since 2023: new code increasingly talks to nothing.

Quality and security are measurably worse per unit of code. CodeRabbit’s December 2025 study of 470 real pull requests: AI-co-authored code carried ~1.7× more issues overall, with XSS vulnerabilities 2.74× more likely and performance inefficiencies ~8× more frequent. Veracode’s benchmark of 100+ LLMs: 45% of generated code introduced OWASP Top 10 flaws, with 86% failing to defend against XSS — and larger models did not fix it. Their conclusion: the problem is systemic, not a scaling artifact. Georgia Tech’s tracking shows CVEs attributable to AI coding tools rising from 6 to 35 per month in the first quarter of 2026 alone. And remember the backdrop from our previous post: the window between a CVE being published and being exploited has collapsed to hours. Shipping the statistically expected vulnerability now means shipping it into an environment where AI-assisted attackers find it the same day.

Perceived speed and real speed have decoupled. METR’s randomised controlled trial remains the study we cite most. Experienced developers predicted AI would make them 24% faster; afterward they believed it had made them ~20% faster. Measured reality on their own mature codebases: 19% slower. A ~39-point gap between feeling and fact — and the reason “it feels faster” is not evidence.

Delivery stability is the casualty. DORA’s 2024 analysis found each 25% increase in AI adoption associated with ~7% lower delivery stability; the 2025 report shows throughput gains finally materialising but the instability persisting. DORA’s verdict: “AI doesn’t fix a team; it amplifies what’s already there.” An amplifier plugged into a weak verification layer amplifies exactly what you’d expect.

§ 04 — Maintainability

The slow variable that decides everything

Speed of initial delivery is the fast variable. Maintainability is the slow one — and over a system’s lifetime, the slow variable dominates: 60–80% of total cost of ownership is maintenance, not construction. Vibecoding optimises the 20% and mortgages the 80%. Here is the decay, mechanism by mechanism.

1. The mental model never exists. When a human writes code, an imperfect-but-real model of the system lives in someone’s head. When code is generated and accepted unread, no such model exists anywhere — not in the author, not in the docs, not in the tests. Every future maintenance task begins as archaeology on a codebase with no author to ask. This is the root defect; everything below compounds it.

2. Semantic duplication defeats your tooling. AI assistants regenerate logic instead of reusing it, and each regeneration is slightly different. Clone detectors catch identical blocks; they miss near-clones. So a business-rule change must be found and fixed in five places that don’t look alike. Miss one, and the bug ships again. The GitClear numbers (+81% detectable duplication) understate the pain — the visible clones are the easy ones.

3. Refactoring stops, so entropy only accumulates. Refactoring is how codebases metabolise change. As Bill Harding, GitClear’s CEO, puts it: “Refactored systems, in general, and moved code in particular, are the signature of code reuse.” That signature has collapsed from 21% to under 4% of all changes. This is not a style preference — it’s the maintenance immune system switching off.

4. New code is increasingly disconnected. The 35% drop in cross-file connectivity means generated code doesn’t integrate with existing abstractions — it sits beside them. A healthy codebase converges on shared vocabulary: one Money type, one retry policy, one auth middleware. A vibecoded codebase diverges: eighteen months in, “how do we handle timeouts?” has eleven answers.

5. Dependency sprawl and rot. Each generation session pulls whatever library the model saw most in training — often outdated, occasionally fictional. A USENIX study found ~20% of package references in generated code pointed to nonexistent packages, now actively exploited via “slopsquatting.” The dependency tree becomes wide, stale, and partially imaginary — and as we covered in our analysis of the npm supply chain crisis, that tree is already under state-level attack: every unvetted package a generation session pulls in is another postinstall hook running with full privileges.

6. Tests that assert nothing. Generated test suites are coverage-shaped, not behaviour-shaped. Mutation testing — injecting deliberate faults to see if tests catch them — is the honest measure, and the results are damning: LLM-generated tests scored around 20% mutation scores on complex real-world functions. Four out of five injected bugs sailed through. Worse, LLMs tend to generate assertions that capture actual behaviour rather than intended behaviour — meaning they faithfully enshrine the bug. Coverage climbs while defect detection collapses. We call this the safety illusion, and it’s more dangerous than having no tests, because dashboards reward it.

7. Knowledge erosion is a workforce problem, not just a code problem. A 2026 randomised trial from Anthropic researchers found developers who learned a new library with AI assistance scored ~17% lower on comprehension — with the largest gap in debugging, the exact skill needed to catch AI’s errors. A separate study found unrestricted AI users hit a 77% failure rate on subsequent maintenance tasks without AI, versus 39% for users trained with scaffolding. And Stanford’s 2026 AI Index reports employment for software developers aged 22–25 down nearly 20% since 2024. The people you’ll need for the rescue in year three are being deskilled — or never hired — in year one.

8. The compounding pattern. An ICSE 2026 review of 518 firsthand practitioner accounts documents what it calls the “speed–quality trade-off paradox”: velocity gains up front, with QA “frequently overlooked” and debt accruing at a pace practitioners consistently describe as unprecedented.

§ 05 — The modularity myth

Why microservices and modularity won’t save you

The most common counterargument: “That’s a monolith problem. We’re modular. Our services are small, independently deployable, and each one is simple enough for AI to handle.” This reasoning feels right and is wrong — and 2026 gave us both the mechanism and the field evidence.

1. The context window is smaller than your system — structurally. An LLM session sees one repo, one service, one slice. A 2026 arXiv paper formalised what practitioners had been reporting, naming it the productivity-reliability paradox: “the context window creates a bias toward local correctness at the expense of systemic coherence: the generated code works in isolation but fails in the broader system context.” Microservices increase the amount of critical knowledge that lives between repos — precisely the knowledge no generation session has. Modularity concentrates risk exactly where the tool is blind.

2. The dependency graph lives outside every repo. Engineering teams running agents at scale keep converging on the same diagnosis: the graph that determines whether a change is safe spans repository boundaries, so it spans the agent’s context boundary too. The documented result, across multiple 2026 postmortem writeups, is agents shipping locally-correct code that breaks consumers the agent didn’t know existed. One team reported cross-repo “context drift” caused ~40% of their agent failures — and only got it under 5% after hand-building an explicit coordination graph across their 79 repositories. The mitigation exists. Almost nobody has built it.

3. Duplication goes cross-service, where no tool can see it. Inside one repo, duplication is at least detectable. Vibecode six services and the same validation logic, currency rounding, and permission check get regenerated — differently — in six codebases. No linter, no clone detector, no dependency graph spans them. When the rounding rule changes, you are doing archaeology across six repos with six inconsistent implementations. The monolith at least kept the copies in one place.

4. Contracts drift because nobody owns the seam. Service architectures live on interface discipline: versioned schemas, consumer-driven contracts, backward compatibility. These are cross-team, cross-time agreements. A per-session code generator is structurally incapable of honouring agreements it never saw. Each generated service invents its own error envelope, pagination style, and null-handling convention; each passes its own tests; the integration fails — at runtime, in production, in seams no single prompt session was ever responsible for. Researchers now have a name for the agentic version: contract drift, where multi-step autonomous workflows contradict their own earlier decisions.

5. Distributed failure modes are exactly what LLMs skip. Idempotency keys, sagas, circuit breakers, backpressure, clock-skew tolerance — the hard 20% of distributed systems, invisible in demos and underrepresented in training data. Generated services handle the happy path and fall over on the first partial failure. In a monolith, a missing error boundary crashes a request. In a mesh, it cascades: one service’s naive retry loop becomes its neighbour’s outage.

6. Multiplication, not division. The hope is that N small services divide the problem. In practice you get N × (service-level decay) + N² pressure on integration seams — every service accumulating the § 04 debt individually, plus a combinatorial boundary problem nobody owns.

If the most sophisticated modular architecture on the planet needed to add human review to contain AI velocity, your service mesh is not going to save you either. Microservices are not a mitigation. They are an amplifier with better PR.

§ 06 — The review asymmetry

Verification now costs more than generation

Now the arithmetic most AI-velocity business cases quietly omit — and the part of this argument that went from “our unpopular opinion” to “measured industry telemetry” in a single year.

It has flipped. The 2026 telemetry, from Faros AI’s analysis of 22,000 developers across 4,000+ teams:

Faros calls it Acceleration Whiplash: “AI has flooded a system built around human-paced development and human-quality code with output it was never designed to absorb.” The unreviewed-merge figure is the one they flag as most urgent — teams aren’t solving the asymmetry, they’re surrendering to it. A CMU–Stanford study of an enterprise “2× productivity mandate” (802 developers, 196,000 PRs) found throughput doubled, per-reviewer load roughly doubled, and automated review overtook human review; their companion analysis of 3,100 practitioner documents found agent-authored PRs receive lower review rates, faster merges, and less discussion than human-authored ones. The code that statistically most needs scrutiny gets the least. LinearB benchmarks add the queue-side view: AI-generated PRs wait ~4.6× longer for reviewer pickup.

This is why we hold a position that is no longer unpopular, merely unwelcome: a full end-to-end review of generated code, done honestly, takes more time than the generation saved — and for production systems it is non-negotiable anyway. Consider what “full” means for a generated changeset touching production:

1. Intent reconstruction — what was this code asked to do, and what did it decide to do? Generated code silently makes dozens of unrequested decisions: data shapes, defaults, error swallowing. With a human author you’d ask. There is no author.
2. Line-level review — the traditional pass, on a diff now 50%+ larger than a human would have written for the same feature.
3. Behavioural verification — do the tests assert intended behaviour, or mirror the implementation? Given ~20% mutation scores, this usually means writing the missing edge-case tests yourself.
4. Security pass — mandatory when 45% of generated samples carry OWASP-class flaws and XSS runs at 2.7×. You are not reviewing for style; you are hunting for the statistically expected vulnerability.
5. Architecture fit — does this duplicate an existing abstraction? Violate a cross-service contract? Introduce dependency #341? This pass requires the most senior person you have.
6. Documentation and rationale capture — writing down the mental model the generation process never produced, so the next maintainer isn’t starting from zero.

There are only three coherent responses: pay the review tax in full for anything production-bound and size teams for verification throughput; constrain generation to contexts where review is cheap — small diffs inside established patterns, code with human-written tests first; or treat the output as disposable — prototypes, spikes, mocks — where skipping review is legitimate because the code never graduates. What is not coherent is the popular fourth option: generate at machine speed, review at demo depth, and ship. That is the option 31% of PRs are now taking. It has an incident report attached, on a delay.

§ 07 — Worst cases

No tests, no docs, no mercy

The 2025–2026 incident record reads like a syllabus. We keep the companies anonymous; every case is public and verified.

Notice the pattern. None of these are exotic. Every one would have been caught by the six-pass review of § 06 or by a test suite with real assertions. The common root cause is not the model. It is the absence of a verification layer that anyone was paid to maintain.

§ 08 — What it looks like in code

Happy-path code demos perfectly and detonates on reality

The signature pattern is code that works in the demo and fails in the world. A typical generated handler:

// generated: works in the demo, fails in the world
app.post("/api/orders", async (req, res) => {
  const { userId, items } = req.body;
  const user = await db.users.findById(userId);       // no auth check — trusts the client
  const total = items.reduce(
    (sum: number, i: any) => sum + i.price * i.qty,   // price from the client. really.
    0
  );
  await db.orders.insert({ userId, items, total });   // no idempotency, no transaction
  res.json({ ok: true });                              // no error boundary anywhere
});

The production-grade version is not more clever. It’s more defensive — and defense is exactly what generation skips, because defense is invisible in a demo:

// engineered: boring on purpose
app.post("/api/orders", requireAuth, async (req, res, next) => {
  try {
    const parsed = OrderSchema.safeParse(req.body);    // validate at the boundary
    if (!parsed.success) return res.status(422).json({ errors: parsed.error.issues });

    const prices = await pricing.lookup(parsed.data.items); // server-side truth
    const total = computeTotal(parsed.data.items, prices);  // one shared, tested function

    const order = await db.transaction((tx) =>
      orders.createIdempotent(tx, req.auth.userId, parsed.data, total, req.idempotencyKey)
    );

    res.status(201).json({ orderId: order.id });
  } catch (err) {
    next(err);                                          // observable, not silent
  }
});

Every line of the second version exists because something once went wrong for someone. That institutional memory is precisely what a model optimising for “looks correct” does not carry. Multiply the first handler across forty microservices, each with its own slightly different copy — remember, 5× more likely to duplicate than refactor — and you have § 05 in production.

§ 09 — The positive case

Where vibecoding genuinely wins

We are not anti-AI tooling. We use these tools daily. The argument is about placement, not prohibition — and the quadrant is simple: low cost of failure, short expected lifespan.

Non-coders validating ideas. A product manager or founder who can turn a concept into a clickable mock in an afternoon has compressed weeks of specification ambiguity into a concrete artifact. Educators are framing this well — vibecoding changes the economics of experimentation. The mock’s job is to be argued with, not deployed.

Proofs of concept and spikes. “Can this API do what we need?” is worth answering in hours, not sprints. The measured sweet spot is real: studies put task completion 20–45% faster on greenfield prototyping work. Vibecode the spike, extract the learning, throw the code away. The code was never the deliverable — the answer was.

Internal tools and small automations. A script that reformats a CSV, a dashboard three people look at, a one-off migration helper. Blast radius near zero, lifespan in weeks. Perfect territory.

Scaffolding around validated components. Boilerplate, test harness stubs, config plumbing — generation operating inside patterns your team already owns. Small diffs in established patterns are exactly where the § 06 review tax stays affordable.

The discipline that makes all of this safe is one rule: vibecoded output is either disposable or it graduates. Graduation means the full verification layer — spec, real tests, the six-pass review, documentation. There is no third state where prototype code quietly becomes load-bearing. That third state is where every incident in § 07 lived.

§ 10 — What to do

The operating model we recommend

§ 11 — The bottom line

Borrow for prototypes. Engineer for production.

Vibecoding is not a fraud. It’s a loan. It advances velocity today against maintainability tomorrow, and the 2026 data finally lets us read the interest rate off the statement: duplication at record highs, refactoring collapsed from 21% to under 4% of changes, review time up 441% where adoption is high, incidents per PR up 242%, a third more code merging with no review at all, and generated test suites that miss four out of five injected faults.

Modularity doesn’t refinance the loan — it splits the balance across N services and hides the statements. The largest modular architecture in the world just demonstrated that at Sev-1 scale, and its remedy was not better prompts. It was mandatory human review.

The teams that internalise the difference will spend the next decade shipping. The teams that don’t will spend it doing rescue engineering — reconstructing, at consulting rates, the understanding that was never built.

References & further reading

• init — “Glasswing: AI vs Node.js vulnerabilities” — our previous post on AI vulnerability discovery and the npm supply chain crisis
• GitClear — “The Maintainability Gap: AI Code Quality in 2026” — 623M changes, duplication and refactoring trends
• Faros AI — “The Acceleration Whiplash” (2026) — review time, PR size, incident telemetry across 22,000 developers
• Google DORA 2025 — State of AI-Assisted Software Development — adoption, throughput, delivery stability
• CodeRabbit — State of AI vs Human Code Generation (Dec 2025) — 470-PR issue-rate comparison
• Veracode — 2025 GenAI Code Security Report — 45% OWASP failure rate across 100+ LLMs
• METR — RCT on AI and experienced developer productivity — the 19%-slower finding
• CMU/Stanford — “AI Writes Faster Than Humans Can Review” — 802 developers, 196K PRs under a 2× mandate
• ICSE 2026 — grey-literature review of 518 practitioner accounts — the speed–quality trade-off paradox
• Shen & Tamkin — “How AI assistance impacts the formation of coding skills” — the debugging-comprehension gap
• Stanford HAI — 2026 AI Index — entry-level developer employment trends
• Stack Overflow — 2025 Developer Survey — adoption vs. trust divergence
• arXiv — “The Productivity-Reliability Paradox” — context windows and systemic coherence
• Gartner — “Why Vibe Coding Needs to Be Taken Seriously” (2025) — the 40%-by-2028 forecast
• Simon Willison — “Not all AI-assisted programming is vibe coding” and “Vibe engineering”
• GitHub — Spec Kit — spec-driven development toolkit