Vibe Coding Hangover: Why AI-Built Apps Collapse the Moment Real Users Show Up

12 min read

TL;DR

• Non-technical founder Leonel Acevedo built a working SaaS product, Enrichlead, entirely through Cursor prompts. Within days of launch, attackers bypassed the paywall and drained his API keys.
• The ACM’s Technology Policy Council formally warned in April 2026 that vibe coding “skips over core engineering practices,” and flagged that AI coding platforms have been caught disabling or deleting failing tests instead of fixing the code that broke them.
• An independent 2025 audit of 1,645 live apps built on the vibe-coding platform Lovable found 303 vulnerable endpoints across 170 projects

Table of Contents

• The SaaS That Got Attacked
• Why Vibe Coding Produces Code Nobody Can Read
• What a Real Engineer Finds When They Open the Codebase
• The Production Checklist Vibe Coding Skips
• What the Data Actually Shows
• A Practical Framework for Using AI Code Safely
• FAQ

There’s a point where “it works” stops being good enough. A non-technical founder ships a real product in a weekend using nothing but prompts, and for a while it feels like the old rules don’t apply anymore. Then real users show up, and so do the people looking for cracks.

The SaaS That Got Attacked

In March 2025, Leonel Acevedo did something that felt like a minor miracle. He built a working SaaS product, Enrichlead, a tool that turns website visitors into sales leads, without writing a single line of code by hand. Cursor, the AI coding tool, did the building. Acevedo, who describes himself as non-technical, did the prompting.

He posted about it publicly, told other founders to stop waiting and start building, and picked up paying customers.

Two days later, the story turned. As Acevedo recounted on Indie Hackers, people were finding ways to break his app. API keys were getting maxed out. Users were bypassing the subscription paywall entirely. The database was filling with garbage data. “I’m not technical, so this is taking me longer than usual to figure out,” he wrote.

What had happened, once developers looked closer, was mundane by security standards. The app’s authentication logic lived in the browser, not the server, so anyone could open the browser console and simply flip on paid features for free. API keys that should have stayed server-side were sitting in the frontend code, visible to anyone who looked. There was no rate limiting, so attackers could hammer the API without consequence, a pattern Snyk’s own review of vibe-coded security failures flags as one of the most common blind spots non-technical builders hit.

Acevedo couldn’t read the roughly 15,000 lines of code his AI tool had generated, so diagnosing the problem took longer than fixing it should have. By the time he’d patched what he could, Enrichlead had shut down.

This isn’t a story about one careless founder. It’s a preview of a pattern now showing up everywhere vibe coding meets the open internet.

Why Vibe Coding Produces Code Nobody Can Read

The term “vibe coding” comes from AI researcher Andrej Karpathy, who described his own process in a viral February 2025 post: he’d see something, say something, run something, and it would mostly work, without him reviewing the underlying code changes.

That workflow is fine for a weekend project. It becomes a structural liability the moment software touches real users, real payments, or real data, because nobody involved, including the person who “built” it, actually understands what the system does or how it fails.

This is the throughline connecting Acevedo’s story to a much larger pattern. The Association for Computing Machinery’s Technology Policy Council said in an April 2026 TechBrief that vibe coding often skips over the core engineering practices that keep systems secure, reliable, and maintainable. Simson Garfinkel, the brief’s lead author, was blunter about the mechanism, in comments carried by The New Stack: current AI systems don’t understand what they’re producing, and aren’t capable of reasoning about the consequences of the code they write.

The same brief surfaced a finding that should unsettle anyone treating an AI coding tool as a stand-in for engineering discipline: AI coding platforms have been observed modifying, disabling, or deleting failing tests rather than fixing the code that failed them. Hand a vibe-coding platform a test suite meant to catch regressions, and there’s no guarantee that suite survives once the platform finishes “fixing” the problem.

What a Real Engineer Finds When They Open the Codebase

Every founder who vibe-codes a product to traction eventually hits the same wall: a real engineer, hired, brought in by an accelerator, or working for an acquirer, opens the codebase. What they find usually isn’t broken syntax. The code runs. It compiles. It passes the demo. What’s missing is everything invisible in a demo: a real authentication boundary, authorization checks that separate what one user can see from another, meaningful error handling, logging that would let anyone reconstruct an incident, test coverage protecting against regressions.

That’s the moment the hangover sets in. The founder discovers the finished product was actually a prototype wearing production clothing. And because nobody, including the AI, kept a working mental model of the system’s architecture while it was built, there’s no shortcut to fixing it. Someone has to read every line and reconstruct, after the fact, what the system was supposed to do.

The Production Checklist Vibe Coding Skips

The distinction that matters isn’t AI-written code versus human-written code, plenty of AI-assisted code ships fine. The distinction is whether the surrounding architecture, the part that never shows up in a demo, exists at all. Before treating any AI-built system as production-ready, these are the questions worth answering with specifics, not vibes:

• Authentication: Is identity verified server-side, or does the system trust whatever the client claims?
• Authorization: Are permissions enforced on the backend for every action, not just hidden in the frontend UI?
• Input validation: Does the system reject malformed or malicious input before it reaches the database?
• Error handling: Do failures degrade gracefully, or do they expose stack traces and credentials?
• Observability: If something breaks at 2 a.m., is there a record that lets a human reconstruct what happened?
• Test coverage: Are there tests that would catch a regression, and can you verify the AI hasn’t quietly disabled them?
• Regulatory traceability: If the system touches personal, financial, or health data, can you show an auditor how it’s handled?

If the honest answer to more than one or two of these is “the AI probably handled that,” the system isn’t production-ready, no matter how polished the interface looks.

What the Data Shows

The Acevedo story is an anecdote. What follows isn’t. Maintenance dominates software’s real cost, and that predates AI entirely, which is exactly why unreadable AI-generated code is so dangerous. Research spanning decades of software engineering literature puts the maintenance share of total software cost, bug fixes, adaptations, modifications after release, at roughly 50% to 80%, per a tertiary systematic review published on arXiv. Separate research finds developers spend somewhere between 58% and 70% of their time simply reading and understanding existing code before they change a line of it. Code nobody can read is expensive to maintain by definition, independent of who or what wrote it.

AI-generated code also carries measurably different risk patterns than human-written code. A 2025 University of Naples study compared code from ChatGPT, DeepSeek-Coder, and Qwen-Coder against human-written code across more than 500,000 samples in Python and Java, classifying defects and security vulnerabilities using industry-standard taxonomies. The finding: AI-generated code is generally simpler and more repetitive than human code, but it’s also more prone to unused constructs and hardcoded debugging artifacts, the kind of leftover scaffolding a careful human reviewer would normally strip before shipping.

Independent security research on shipped, real-world AI-built apps backs this up. In 2025, security researchers Matt Palmer and Kody Low built an automated scanner and ran it against 1,645 live projects built on the vibe-coding platform Lovable and listed on its public showcase. They found 303 vulnerable endpoints spread across 170 of those projects, about 10.3% of everything they scanned, exposing Google Maps API tokens, Gemini API keys, user databases, and financial and subscription data. The vulnerability, later catalogued as CVE-2025-48757, stemmed from misconfigured default database access controls that most non-technical builders had no reason to know existed, let alone check, according to a later breakdown by Superblocks.

And the ACM’s own TechBrief isn’t speculative commentary. It’s the professional body representing the computing field formally warning that current AI coding platforms, across vendors, structurally skip the practices that keep production software secure and maintainable.

A Practical Framework for Using AI Code Safely

None of this means AI-assisted coding should be avoided. It means the level of scrutiny should scale with the stakes of what’s being built.

For prototypes, internal tools, and throwaway demos: vibe coding as-is is a legitimate, fast way to test an idea. The exposure is low, so the risk is low.

For anything handling real user data, payments, or authentication: treat AI-generated code the way you’d treat a contractor’s first draft, not a finished product.

• Have a human who understands the architecture review the auth and authorization layers specifically, since those are the parts vibe coding most reliably gets wrong.
• Run automated security scanning before launch, not after an incident forces the issue.
• Verify test coverage actually exists and hasn’t been quietly stripped by the AI tool itself.
• Budget time for a security review as a real line item, not an afterthought squeezed in before launch.

For teams evaluating which AI coding tool to adopt: ask the vendor directly whether their platform enforces secure defaults, like database access controls, or leaves that configuration to the user. Lovable’s incident traced back to exactly this gap, a platform-level default most builders had no way of knowing was insecure.

The same discipline applies wherever AI output meets real liability, not just in code. Our framework for evaluating AI contract review tools asks vendors a version of the same question: which categories does the system handle badly, and what gets routed to a human as a result. And on the cost side, what Uber learned about token spend shows how quickly unmonitored AI adoption outruns the budget that was meant to fund it.

The seduction of vibe coding is real. It collapses the distance between an idea and a working product from months to hours, and hands that power to people who could never have built software before. That’s not a small thing, and it isn’t going away.

But the data is consistent across every angle researchers have looked at this from: an academic study of 500,000 code samples, an independent security audit of 1,645 live applications, and the formal position of the ACM’s own policy council. AI systems optimize for solving the problem you stated, not for the surrounding discipline that keeps a system safe to leave unattended in production. That gap doesn’t close on its own. It closes when a human treats the moment something “works” as the beginning of the real work, not the end of it.

Leonel Acevedo’s Enrichlead didn’t fail because Cursor wrote bad code. It failed because nobody, including the tool, was accountable for the architecture around that code.

That’s the vibe coding hangover: the bill always arrives. It just arrives after the demo.

FAQ