We audited 35 vibe-coded apps
Since early 2025, we have audited and remediated 35 applications built largely with AI coding tools - Cursor, Lovable, Claude, Codex, Gemini and others. Every one had issues serious enough to block production use; a typical app carried 15-30 distinct problems. Here is the data.
How often each problem appeared
100%
No rate limiting
Not one app limited how often an endpoint could be called - open doors for abuse, scraping, and runaway API bills.
100%
No automated tests
Zero apps arrived with a meaningful test suite. Every change was a gamble against silent regressions.
95%
SQL injection vulnerabilities
User input reaching queries without sanitization - the oldest vulnerability class on the web, reintroduced at scale.
85%
Unprotected API routes
Endpoints with no authentication or authorization checks. Anyone who found the URL could call it.
80%
Hardcoded secrets and config
Credentials, connection strings, and environment config committed straight into the codebase.
80%
Junk and dead code
Significant volumes of code that no execution path reaches - noise that hides real bugs and slows every future change.
70%
Unused components in production
Entire components and dependencies shipped to users without ever being rendered or called.
25%
API keys exposed client-side
Secret keys visible in the browser bundle, ready to be lifted and abused on someone else's bill.
Share of the 35 audited codebases in which each issue class was present. Percentages rounded. A typical app carried 15-30 distinct issues across these categories.
Which tools built them
Cursor was identifiable in roughly 35% of the codebases and Lovable in about 10%. In the majority we could not attribute a single origin: the code showed traces of several tools used together - Claude, Codex, Gemini, and editor assistants layered over each other. That is itself a finding: by the time an app reaches an audit, the question is not which tool wrote it, but whether anyone ever reviewed what was written. Nothing in the data suggests one tool produces meaningfully safer unreviewed output than another.
Overengineered, not underengineered
The stereotype says AI-generated apps are too simple. We found the opposite: most were overengineered - layers of abstraction, premature infrastructure, and dependencies far beyond what the product needed. It shows up on invoices, not just in the code: several clients came to us because simple applications were generating outsized infrastructure bills. Generated code defaults to more; without a goal to evaluate against, nothing ever says less.
Two stories from the audits
On one project, our first step was simply enabling the linter. It reported over 1,000 errors - failures that had been silently swallowed all over the application. Features looked like they worked because the errors never surfaced anywhere a human would see them.
Another client was drowning in spam. Their forms had client-side-only protection: bots bypassed the captcha entirely and pushed spam and injection attempts straight through the front door. The forms had worked flawlessly in every demo - demos do not include attackers.
What happened before they called us
Many owners did not come for prevention - they came after an incident: applications failing in production, runaway resource usage and infrastructure costs for what should have been cheap apps, and vulnerabilities discovered on public marketing sites. The audit confirmed what the incident already suggested; the cheaper order is the reverse.
Technical founders did better - but not enough
Apps built by technical founders were in noticeably better shape. The binding constraint was not skill but time: every issue in this report is fixable by a competent engineer who reviews the generated code, and each finding costs review time the founders did not have. That is usually the moment they brought us in - not because they could not fix it, but because they could not fix it while also running the company.
Why this keeps happening
AI is a compiler, not a runtime - but a compiler needs a goal to evaluate against. Vibe coding skips that step: nobody writes down what good looks like, so generated code is judged by "does the demo work" and drifts into slop. The fix is not abandoning AI tools; it is adding the goal - defined requirements, tests, and review - and hardening what was generated into deterministic, tested code. Wondering where your app stands? Run the free Vibe Code Health Check.
Methodology
Data covers 35 codebases audited or remediated by Teyrex between early 2025 and mid-2026. All were brought to us by owners who suspected or had experienced problems, so the sample is likely biased toward troubled apps - this is not a claim about all AI-generated code, but about what production-bound vibe-coded apps look like when no one has reviewed them. Issue percentages indicate the share of apps where at least one instance of the issue class was found, rounded to the nearest 5%.
Is your app on this list and does not know it yet?
Get an audit