Why vibe-coded apps break in production, by the numbers
An AI agent generating a working prototype in an afternoon is no longer the interesting part — every prompt-to-app tool does that now. The interesting part, and the part several independent audits have started measuring in 2026, is what happens to that code once real users and real data show up.
What the audits actually found
- Escape.tech's 2026 audit of 5,600 publicly accessible vibe-coded applications found over 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of personal data sitting in the open.
- Veracode's GenAI Code Security Report tested over 100 large language models across Java, JavaScript, Python, and C#, and found 45% of AI-generated code samples contained an OWASP Top 10 vulnerability.
- A 2026 AppSec Santa study of 534 samples across leading models (including GPT-5.2, Claude Opus 4.6, and Gemini 2.5 Pro) confirmed exploitable defects in 25.1% of them.
- Wiz Research disclosed CVE-2025-48757 after finding that 170 of 1,645 production applications built on one popular AI app builder were shipping with missing or misconfigured row-level security — meaning one user's data was reachable by another user's request.
- Aikido Security now attributes roughly 1 in 5 enterprise security breaches directly to AI-generated code.
None of this means the code doesn't run. It means it runs for the person who tested it, with the data they tested it with, and stops being safe to trust the moment real users and real load show up.
Why this specific pattern keeps happening
An agent generating a login flow, a database query, or an API endpoint is solving a local problem: does this specific piece of code do what I asked, right now, with the data in front of me. Whether that endpoint checks the caller actually owns the row it's returning, whether a secret ends up in a client bundle, whether a query that's fine for 50 test rows falls over at 50,000 — those are platform problems, not something a single generated file can guarantee on its own. Multiply that across every endpoint, form, and integration a full app needs, generated independently, and the miss rate compounds. The Wiz-disclosed row-level-security gap is exactly this: not one obviously broken line, but a security policy that has to be applied consistently, everywhere data is queried — precisely the kind of cross-cutting concern that's easy for an agent (or a person) to get right nine times and miss the tenth.
What actually closes the gap
The fix isn't "review the AI's code more carefully" as a permanent operating model — it's not asking each generated endpoint to reinvent access control in the first place. Two structural choices in how DYPAI is built come directly from this:
- Auth is built into
@dypai-ai/client-sdk, not something an agent writes per endpoint. DYPAI's own guidance to agents is explicit: don't write custom login/signup endpoints — use the SDK. JWT for user-facing requests, API keys for server-to-server. That's one enforced pattern instead of a new one per generated file. - Multi-tenancy is a platform convention, not a per-query decision. Data access is scoped through
user_idat the query layer consistently, rather than leaving "does this endpoint check ownership" as a judgment call an agent has to remember to make correctly on every single generated query — which is exactly the class of miss Wiz found at scale. - Backend changes go through draft → publish, not straight to production. A generated flow gets a review step before it's live, instead of an agent's first draft becoming the deployed behavior.
None of this claims DYPAI-generated code is immune to bugs — no platform can honestly claim that. What it changes is the shape of the risk: instead of "did the agent remember to add auth correctly on this specific endpoint, and the next one, and the one after that," the question becomes "is the one enforced pattern actually correct" — a much smaller, much more auditable surface.
The actual takeaway
If you're already shipping with a prompt-to-app tool, the audits above aren't a reason to stop — they're a reason to ask specifically where auth and data access are enforced in your stack, and whether that's a decision made once by the platform or a decision your agent has to make correctly on every single generated file. That question matters more than which tool wrote the code. If you're weighing that question against a specific alternative, we cover it for Supabase and InsForge and for Base44 and Replit Agent.
Sources: Escape.tech 2026 vibe-coding audit, Supabase — the vibe coding master checklist, Wiz Research / CVE-2025-48757.