Vibe coding pitfalls: 8 ways AI-built apps go wrong (and the fixes)

The quiet failures

The dangerous pitfalls of vibe coding rarely look like errors. The app loads, the buttons work, the demo goes well. The problem is something you can’t see from the front end: who else can read the data, where the keys are, what the code does with unexpected input.

Each pitfall below comes with the evidence for it, a warning sign, and a first fix. There’s a one-table summary at the end.

1. A database anyone can read

This is the pitfall with the worst track record. A vulnerability recorded as CVE-2025-48757 described apps generated by Lovable through mid-April 2025 whose database access rules were insufficient, letting unauthenticated attackers read or write arbitrary tables. It was rated 9.3 out of 10 for severity. Lovable disputes the record, saying each customer is responsible for protecting its own app’s data (CVE record).

Whoever is responsible, the lesson is the same. If your app uses a hosted database such as Supabase, row level security must be on for every table that the app can reach, or any role with access to the table can read and write all of it (Supabase).

Fix: turn on row level security for every table, write a policy for each, and ask the AI to explain each policy back to you.

2. Keys in the code

AI tools will happily paste an API key into a file to make something work. GitGuardian found about 28.6 million new secrets in public GitHub commits in 2025, with leaks of AI-service keys up 81% on the year — and a leaked key can stay dangerous for years: 64% of valid secrets it found in 2022 still worked four years later (GitGuardian).

Fix: move every key into the platform’s secrets settings, then rotate (replace) any key that was ever in a file. Deleting it from the code doesn’t un-leak it.

3. Code that works and is still insecure

“It works” and “it’s safe” are different tests. Veracode gave more than 100 models 80 coding tasks with a secure and an insecure way to solve them. The generated code introduced a known weakness in 45% of tasks, and it failed to defend against two common attacks — cross-site scripting and log injection — in 86% and 88% of the relevant cases (Veracode).

1. Log injection not prevented88%
2. Cross-site scripting not prevented86%
3. All tasks: a known weakness introduced45%

80 coding tasks across more than 100 models. Newer and larger models did not do meaningfully better.

Source: Veracode

Veracode also found that newer and larger models didn’t do meaningfully better, so “use the latest model” isn’t the fix (Veracode).

Fix: for every place your app accepts input — forms, URLs, uploads — ask the AI specifically: “How could someone abuse this input, and is it protected?” Then test the answer.

4. Packages that don’t exist

When AI writes code, it often adds dependencies: packages of someone else’s code that your project installs. Sometimes it invents them. A study presented at USENIX Security 2025 generated 576,000 code samples from 16 models and found that, on average, at least 5.2% of recommended packages from commercial models and 21.7% from open-source models didn’t exist — over 205,000 unique made-up names (Spracklen et al.).

1. Open-source models21.7%
2. Commercial models5.2%

Average across 576,000 code samples from 16 models. The paper reports these as lower bounds.

Source: Spracklen et al., USENIX Security 2025 (arXiv)

An invented name is an opportunity for an attacker, who can register it and wait for someone to install it. This is sometimes called “slopsquatting.”

Fix: before accepting a new dependency, check that it exists on the official package registry, has a real history, and is widely used. If you’ve never heard of it, ask why it’s needed.

5. An agent with the keys to production

Coding agents can run commands, edit files and talk to databases. Give one your live database credentials and a bad step becomes a real loss. In July 2025, Replit’s agent deleted a company’s production database despite instructions to freeze changes; Replit’s CEO called it unacceptable, and the company moved to separate development and production databases (The Register).

Fix: agents get test credentials and test data only. Changes reach production through a step you take deliberately.

6. Feeling faster than you are

AI tools make code appear fast, which feels like progress. METR’s early-2025 study of 16 experienced developers working on real tasks in their own projects found a striking gap between feeling and measurement (METR).

+24%speedup developers expected beforehandMETR

+20%speedup they believed they gotMETR

−19%measured: tasks took longer with AIMETR

16 experienced developers, 246 real tasks, mainly Cursor with Claude 3.5/3.7 Sonnet. METR now calls these results out of date; later data suggests speedups but is weak evidence.

Context matters: METR itself now says those results are out of date. Its later data points to speedups, but METR describes that as very weak evidence, and it found self-reported speedups unreliable (METR). The durable lesson isn’t “AI makes you slower” — it’s that your sense of speed is a poor measure.

Fix: judge progress by features that are finished, tested and in use — not by how much code was generated today.

7. Bills that grow with the project

Builders and AI services often bill by usage, and usage grows with the project: in Bolt, for example, larger projects consume more tokens per message because more of the project is read each time (Bolt).

Fix: set caps and alerts on every usage-billed service, keep requests small, and watch the cost per change as the project grows.

8. No way out

If your code and data live only inside one platform, its pricing and limits become yours. Some builders make leaving easy — Lovable syncs code to your own GitHub repository and lets you deploy elsewhere (Lovable) — but you have to set it up.

Fix: turn on code export or sync on day one, and test exporting your data before you need to.

The one-table summary

Pitfall	Warning sign	First fix
Open database	Tables with no access rules	Turn on row level security; add a policy per table
Leaked keys	A key appears in any code file	Move it to secrets settings, then rotate it
Insecure code that works	User input shown or stored without checks	Ask for a security review of each form and endpoint
Invented packages	A dependency you've never heard of	Check it exists, is maintained and is widely used
Agent with live access	The AI tool holds production credentials	Give it a test database only
Productivity illusion	Lots of code, few finished features	Track features shipped, not prompts sent
Runaway costs	No cap on a usage-billed service	Set limits and alerts before launch
Lock-in	No way to export code or data	Set up code export or sync on day one

The essentials guide walks through setting each safeguard up, in order. If you’re just beginning, start with how to start vibe coding.