"A vibe-coded application that handles protected health information carries the same regulatory exposure as one written by a team of professional developers following a formal process."
— Cloud Security Alliance, Vibe Coding Governance research note
Vibe coding, the practice of building working software by describing what you want in plain English and letting an AI write the code, has gone from a novelty to a genuine way millions of people now make their own apps. The Swedish platform Lovable, which calls itself a vibe coding platform, reported 60 million projects hosted and reached a $13.3 billion valuation in August 2026. You really can describe an idea over coffee and have a running app an hour later. But there is a trap hiding inside that convenience, and the numbers are sobering: a security scan of 5,600 publicly deployed vibe-coded apps found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets, and 175 instances of exposed personal data including medical records and bank account numbers. This is what vibe coding your own apps is genuinely great for, where it quietly fails, and how to do it without becoming one of those statistics.
What Vibe Coding Actually Is Now
The term describes a workflow more than a technology: you prompt an AI tool in natural language, it generates the app, you look at the result, and you refine by describing changes rather than editing code line by line. The ecosystem has split into two broad camps. On one side are app builders aimed squarely at non-developers, like Lovable, Bolt, Replit, and v0, where one compilation found roughly 63% of users are not professional developers. On the other are developer-focused tools like Cursor and GitHub Copilot, which remain overwhelmingly used by professional software engineers to go faster, not by beginners starting from zero. The money has followed the momentum: Lovable went from being renamed out of the GPT Engineer project in December 2024 to $200 million in annual recurring revenue reported by Bloomberg in November 2025, one of the fastest climbs software has seen.
It is worth being precise about who this serves, because the hype flattens an important distinction. For a professional developer, these tools are an accelerator layered on top of existing judgment about architecture, security, and testing. For a non-developer vibe coding their own app, the AI is not just writing the code, it is making every one of those judgment calls invisibly, and you have no way to check its work. That gap is the whole story. We explored the professional-developer side of this shift in our look at what happened to prompt engineering, and the same lesson applies here: the skill is moving from writing syntax to knowing what to ask for and what to verify.
The Core Distinction
Vibe coding is extraordinary for getting from idea to working prototype. It is dangerous when that prototype quietly becomes production software handling real people's data, because the AI made hundreds of security and architecture decisions you never saw and cannot audit. The problem is almost never the first version. It is the moment the first version goes live.
Where Vibe Coding Genuinely Shines
None of the risk below should obscure how real the upside is for the right use cases. Vibe coding is excellent for internal tools that never touch sensitive data, for prototypes you build to test an idea before committing real engineering, for personal utilities and automations that run just for you, and for learning, because seeing a working app assembled from your description is a genuinely good way to understand how software fits together. In all of these, the blast radius of a mistake is small, and the speed is transformative. A marketer building a campaign dashboard that reads from a spreadsheet, or a founder mocking up an interface to show investors, is getting enormous value with essentially no downside.
The trouble is that the same ease that makes those use cases great also makes it frictionless to cross the line into territory where the stakes are completely different. The platform does not stop you, and nothing in the smooth "describe it and ship it" flow signals that you have just moved from a weekend project to something holding customer records. That is a structural problem, not a user-error problem, which is exactly why it keeps happening at scale.
The Security Trap, in Hard Numbers
The evidence that this goes wrong at scale is now substantial and comes from independent scans, not just opinion. The security firm Escape.tech scanned 5,600 publicly deployed vibe-coded applications and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets such as API keys and access tokens, and 175 instances of personal data exposure that included medical records and bank account numbers. A separate effort by RedAccess identified roughly 380,000 publicly accessible applications and assets built with popular AI tools, of which about 5,000 were exposing sensitive corporate data, with some protected by authentication so weak it amounted to simply entering an email address. Independent testing by Veracode has repeatedly found that around 45% of AI-generated code samples introduce known OWASP Top 10 vulnerabilities, with no clear improvement over successive testing cycles.
The root causes are consistent and, importantly, mostly not about the AI writing "bad code" in isolation. The recurring culprits are insecure defaults and missing guardrails: apps deployed public-by-default on the open internet unless explicitly set otherwise, secrets hardcoded into client-side code where anyone can read them, and missing authorization checks because the AI generated the feature that works without the access control that makes it safe. One widely tracked example, CVE-2025-48757, involved Lovable-generated apps connecting to a database without row-level security configured, so the database returned every row to any authenticated request. The flaw is not exotic. It is the kind of thing a security review catches in minutes and a vibe coder never sees at all. This is the same category of risk we detailed for professional teams in our guide to safeguarding agentic AI coding, and it applies with even more force when no professional is in the loop.
| Finding | Source |
|---|---|
| 5,600 apps scanned: 2,000+ high-impact vulnerabilities, 400+ exposed secrets, 175 personal-data exposures | Escape.tech scan |
| ~380,000 publicly accessible AI-built apps; ~5,000 leaking sensitive corporate data | RedAccess |
| ~45% of AI-generated code introduces OWASP Top 10 vulnerabilities | Veracode benchmark |
| ~20% of AI-generated code references packages that do not exist (supply-chain risk) | Reported across security research |
| CVE-2025-48757: database returned all rows due to missing row-level security | Tracked CVE (Lovable + Supabase) |
The Myth That Prompting Harder Fixes It
A common assumption among people vibe coding their own apps is that you can simply ask the AI to "make it secure" and the problem goes away. The research says otherwise, and in a particularly uncomfortable way: one analysis found that iterating with AI on existing code increased critical vulnerabilities by around 37.6% rather than removing them, and multiple security write-ups conclude that prompting for security is not a reliable control. Security has to be a first-class objective tested independently against the running application, not a line in a prompt. The AI has no persistent model of your app's threat surface; it responds locally to each request, and a request to add a feature will cheerfully reintroduce the hole a previous request closed.
There is also a productivity myth worth puncturing, because it cuts against the "just vibe code everything" instinct. A controlled METR study of 16 experienced open-source developers found they were actually 19% slower when using AI tools on tasks in codebases they knew well, even though they believed they were faster. The lesson is not that the tools are useless, it is that the felt speed of vibe coding and the real, verified outcome can diverge sharply, especially once a project has any real complexity. Speed to a demo is not the same as speed to something correct and safe.
Remember This
You cannot prompt your way to security. The regulators agree: a vibe-coded app handling health or financial data carries the exact same legal exposure as one built by a professional team, except the vibe coder almost certainly has no security review, no penetration testing, and no audit logging. The law does not care how the software was written.
How to Vibe Code Your Own Apps Safely
The practical guidance that recurs across every serious source is refreshingly concrete, and you do not need to be an engineer to follow most of it. Keep a clear line between prototype and production, and treat anything that holds other people's data as production. Deploy private-by-default, so your app is not live on the public internet until you have deliberately decided it should be. Never let secrets like API keys sit in client-side code where a browser can read them. If your app connects to a database, make sure row-level or equivalent access controls are switched on, since that single setting is behind a startling share of the exposure incidents. And if the app will ever hold sensitive data, get a real security review before launch, not a prompt asking the AI to check its own work.
For anyone doing this inside a company rather than at home, there is an additional layer: governance. The enterprise version of this problem is shadow AI, where employees build useful tools that nobody has inventoried, secured, or assigned an owner. One cited survey found 33% of people admit to putting sensitive information into unapproved tools. The answer is not to ban vibe coding, which both wastes the upside and simply drives it underground, but to give it a sanctioned path: an inventory of AI-built apps, a named owner for each, private-by-default hosting, and a lightweight review gate before anything handling real data goes live. This is the same clean-architecture and governance discipline we argue for when companies ask whether you can vibe code something as serious as an ERP, and the honest answer is the same at every scale: vibe code the idea freely, but put real guardrails between the idea and anyone else's data.
Vibe coding is one of the most genuinely empowering shifts in software in years, and the right response to the security numbers is not fear, it is discipline. Build freely, prototype everything, learn by making. Just draw a bright line at the moment your creation starts holding data that belongs to someone else, and treat crossing that line as the serious engineering decision it actually is. Do that, and you get almost all of the upside with almost none of the exposure that put 175 people's medical records and bank details on the open web.