Why vibe-coded apps are sitting on a $4B hidden tax

A founder we spoke with last month showed us a Lovable-built MVP that had pulled in 4,000 paying users in nine weeks. Beautiful Stripe integration, slick onboarding, real revenue. It also had its Supabase service-role key sitting in the client bundle, Row Level Security disabled on every table, and a production database anyone with browser dev tools could read end-to-end. The founder had not written a line of the code and could not, in any meaningful sense, read it either.

That app is not the whole category. It is the failure mode we keep seeing when non-technical teams ship generated code straight to production. AI coding tools were reported at roughly $2.7B-$3B of combined ARR by early 2026, with Lovable alone claiming 100,000-200,000 new projects per day. The cohort of apps now in production looks enormous from the top, and looks like a pile of unpaid invoices when you zoom in.

Our rough math, walked through below, puts the near-term remediation tax on this cohort at around $4 billion over the next 12-18 months. That is a scenario model, not an audited market size. This post is not an argument against AI in coding, we use Claude, Cursor, and Copilot every day, and our AI practice is core to our work. It is an argument against the specific habit of shipping production software no human on the team understands, and a look at what that habit costs when the bill arrives.

Vibe coding feels fast because typing was never the bottleneck

The pitch is honest about the pleasure. You describe an app, the model writes it, you click Deploy, you have something on the internet inside an hour. The dopamine hit is real and the demos are not faked.

The problem is that typing has not been the bottleneck in software for at least two decades. Reading, debugging, refactoring, deciding what not to build, that is where the time goes. Eliminating typing while adding a generator that confidently produces near-misses is exactly the trade that breaks down once your code starts colliding with real users.

METR ran the cleanest study we have on this. Sixteen experienced open-source developers, 246 real issues on their own repos averaging 22,000 stars and over a million lines of code. The developers using AI took 19% longer to complete the work than the developers without it. They expected AI to make them 24% faster. After finishing the tasks slower, they still believed AI had sped them up by 20%. The productivity is a vibe; the slowdown is in the data.

METR later cautioned that early-2026 measurement is harder because AI-heavy developers and AI-suited tasks increasingly select out of no-AI experiments. Treat the 19% result as a clean early-2025 warning about perception, not a permanent law about every model and every task.

Now imagine you are a non-technical founder who has never run that study and has never had to maintain code at scale. The feeling of speed is the only signal you have. You ship. The bill comes later.

The debt is not small and it is not theoretical

Four source categories point in the same direction.

GitClear analyzed 211M lines of code from 2020 through 2024. Code churn, lines reverted or rewritten within two weeks of being committed, rose from 3.1% in 2020 to 5.7% in 2024, a near-doubling that tracks the rise of AI assistants. Copy-pasted blocks rose from 8.3% to 12.3% of all new code. Refactored ("moved") lines collapsed from 24.1% to 9.5%. 2024 was the first year on record where copy-paste outnumbered refactoring in the codebases they track. Engineers are no longer cleaning code; they are layering it.

Security looks worse. The original NYU Tandon study on Copilot found around 40% of generated programs contained exploitable bugs or design flaws, XSS, SQL injection, hardcoded credentials, path traversal, the bread-and-butter CWE list. That was a 2021 Copilot/Codex-era baseline, not a verdict on every current model. The pattern did not disappear: Veracode's 2025 GenAI Code Security Report found AI-generated code failed security tests in 45% of cases across 100+ LLMs and common languages.

The app-level evidence is just as uncomfortable. Autonoma cites survey data that 53% of teams shipping AI-generated code later found security issues that passed initial review. Escape.tech's scan of 5,600 public vibe-coded apps found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 PII exposures. Wiz framed the platform risk differently: it found that one in five organizations were building on these platforms and exposing themselves to recurring risk patterns like client-side auth, hardcoded secrets, weak RLS, and public internal apps.

Then there is the supply-chain attack surface. A USENIX paper on package hallucinations across 16 LLMs found 21.7% of packages recommended by open-source LLMs and 5.2% from commercial ones simply did not exist. The study produced 440,000+ hallucinated package references, including 205,474 unique fake names. The hallucinations were repeatable: about 45% of fake packages were regenerated on every retry for the same prompt. This is no longer a stochastic curiosity; it is an attack primitive called slopsquatting. One researcher registered the hallucinated package huggingface-cli and watched 30,000+ downloads roll in inside three months.

The developers themselves are noticing. The 2025 Stack Overflow survey found 84% of developers use or plan to use AI tools, but only 33% trust their accuracy. 46% actively distrust them, and 66% cited "AI solutions that are almost right, but not quite" as their top frustration: the precise failure mode that produces expensive-to-debug code at scale.

What the cleanup actually costs

Here is the math that gets us to $4B. We will show our work so you can argue with the inputs.

First, the methodology note: this is a scenario model, not a measured market. The source-backed inputs are the public tool metrics, code-quality studies, security scans, and market rewrite benchmarks. The appssemble assumptions are the shipped-app filter, the cross-tool cohort estimate, and the percentage of apps that need paid remediation in the next 12-18 months.

Cohort size. Strip out Cursor for this model because most Cursor output still passes through engineering teams that already do code review. Look at the non-engineer slice instead: Lovable, Bolt, Replit Agent, and v0. Lovable's 100K-200K new projects per day implies 36M-73M projects a year. Apply a strict 1% filter for "actually shipped to real users with real data" and you get 360K-730K production-ish apps per year on Lovable. Add a modeled contribution from Bolt, Replit Agent, and v0 paid users, and the scenario lands at roughly 1 million production vibe-coded apps shipped in the 12 months ending Q2 2026. That is an assumption, not a platform-reported count.

Per-app debt. The most defensible founder-level anchor is not abstract LOC theory. It is what a hardening sprint or partial rewrite costs in the market. A lean SaaS remediation starts around $30K. A more complex cleanup or rewrite commonly moves into the $50K-$120K band.

LOC-based estimates are useful only as sanity checks. A $2.82/LOC debt estimate puts an 8,000 LOC app at about $22,500 before project-specific risk. Sonar's $306,000/year per 1M LOC equals about $0.306/LOC/year, not $2.45/LOC/year. For an 8,000 LOC app, that is roughly $2,448/year, or $7,344 over three years before any multiplier. Sonar proves debt compounds; it does not carry an $80K small-app cleanup quote by itself.

So the model uses a $30K low-end remediation cost and treats $50K as the midpoint case. The $80K-$120K scenarios are the expensive end, not the base claim.

Comes-due rate. Not every app gets remediated. Most die quietly. Of the ones that get traction, debt usually becomes visible around month three to six: a scale wall, a procurement review, a security incident, or a feature that cannot be added without understanding the generated code. Apply a 10-15% "comes-due-this-cycle" assumption and you get 100K-150K apps requiring meaningful remediation in the next 12-18 months.

Multiply.

That is the $4B claim: if roughly 1M production-ish vibe-coded apps exist, and 10-15% need paid remediation soon, a low-end $30K cleanup creates a $3B-$4.5B market. IBM's 2024 report put the average breach cost at $4.88M, but breach cost is not needed to make the base model work. It is upside risk, not the foundation.

A top-down sanity check lands in the same neighborhood, but it is illustrative. CISQ pegged accumulated US software technical debt at $1.52T in 2022. If AI-generated code adds even 0.3% to that stock, that is another $4.5B of debt service. The 0.3% is our scenario input, not an independently measured share.

Your founders' speed instinct is rational, but incomplete

We want to be careful here. The reflex to ship fast is correct. Most startups die from never reaching users, not from shipping code that needs cleanup later. If you have to choose between a beautifully architected app no one ever sees and an ugly one that gets to a thousand users in a week, take the ugly one. We have argued this on this blog before.

Vibe coding wins the first move and loses the second one. You ship the prototype in a week. Then a real user signs up, a competitor copies the idea, an investor asks for the architecture, a security researcher finds your Supabase keys, or you simply need to add a feature that requires understanding what the model wrote three months ago. That is where the bill arrives, and where the saved week becomes 90 days of paying down debt or, more often, a full rewrite.

There is a name for the underlying problem: comprehension debt. The gap between how much code your system contains and how much of it any human on the team genuinely understands. Technical debt announces itself through mounting friction; comprehension debt breeds false confidence right up until production breaks and nobody can read the stack trace. It is the harder of the two debts to price because it doesn't show up until you need it.

For your app, this means the first question is not "should we rewrite?" It is simpler: can a competent engineer prove that users cannot read each other's data, secrets are server-side, payments are verified on the backend, deploys are repeatable, and errors can be traced within minutes? If not, you do not have a production app yet. You have a demo with revenue attached.

A better trade-off: senior engineering from day one

The same speed argument cuts the other way once you stop measuring speed in lines of code and start measuring it in time to a defensible product. Here is how we run our builds, and why we think it produces a better cost curve than the vibe-only path.

1. AI everywhere humans review. Our engineers use Claude, Cursor, and Copilot continuously. METR reported AI suggestions accepted around 44% of the time in its study, but the accept rate is not the point. Every accepted line needs to be read by a senior engineer who can hold the system in their head. The acceleration is real; the comprehension stays intact.

2. Two-week sprints, working software end of each. A small senior team, typically a designer, two engineers, a tester, gets the first version in your users' hands inside four to six weeks. That is slower than the weekend demo and faster than the rebuild, with code you can hire against, audit, and extend.

3. Security audits before production, not after a CVE. Our engineering practice bakes in load testing, query profiling, security review, and a 99.9% uptime SLA before any code reaches real traffic. The cost is built into the sprint, not into a remediation invoice six months later.

4. AI in production, not in the prototype. Our AI practice is exactly the place where AI generation is most dangerous, RAG pipelines, agents, voice systems, so we treat it with the most rigor. Automated evals on every change, hallucination scoring, prompt-injection detection, PII safety. AI ships when it is measured, not when it feels right.

5. Same team, day one to scale. The team that builds your product is the team that maintains it. Grovs (10M+ events daily) and Semaphr (500K+ app sessions) both live this way, same engineers from first commit to current scale. There is no handoff to a "maintenance team" who cannot read what was generated.

"But we cannot afford a senior team, we have to start with vibe coding"

We hear this almost every week. Three responses.

First, run the math on your specific case. A vibe-coded MVP looks free until you price the rewrite. If your app gets to 1,000 users and falls into the modeled 10-15% of the cohort that needs serious remediation, you are looking at $30K-$80K to fix it, often more than the senior-team build would have cost in the first place. The discount is illusory once you account for the probability-weighted cleanup.

Second, use vibe coding for what it is genuinely good at: learning, prototyping, and discovery. Build five Lovable prototypes in a weekend, show them to ten potential customers, find out which idea has signal. That is a legitimate use of these tools and we recommend it. Then, once you know what to build, build it with engineers who can read it.

Third, if you have already shipped a vibe-coded app to real users, do not panic and do not rewrite it blindly. Audit it first. Check five things before you prompt another feature: secrets in the client bundle, RLS and authorization, payment and webhook verification, observability, and deploy rollback. Most vibe-coded apps need a hardening sprint, not a full rewrite, close the obvious security holes, replace the worst three or four files, get a real CI/CD pipeline in place, and you can buy yourself another six to twelve months of runway on the same codebase. The expensive mistake is to either ignore the audit and keep shipping until something breaks publicly, or tear the whole thing down without knowing which parts work.

The bill is being paid either way

Vibe coding did not invent bad code; outsourcing produced its own version for two decades and the cleanup industry that grew up around it (us included) is the same industry now pricing vibe-code remediation. The difference this time is volume and visibility. An offshore shop could produce one mediocre codebase per ~$50K of spend. Lovable reports 100K+ projects a day, many shipped without anyone, including the founder, reading them.

The $4B figure is not a prophecy. It is the low end of a scenario that uses conservative cleanup costs and explicit assumptions. Of the roughly one million production-ish vibe-coded apps in the model, 100,000-150,000 would need professional remediation in the next 12 to 18 months at $30K or more each. The exact market size will move. The invoice already exists.

If you have a vibe-coded app in production and want a straight read on what it would cost to harden, or you are about to ship one and want to understand the trade-off before you do. book a call. We will tell you what we would actually do, in the order we would do it, with numbers attached.

Move fast. Stay small. Build big. The first two are why vibe coding feels right. The third is why senior engineering still wins.