The Vibe-Coding Mistakes That Bite You After Launch

The vibe-coding mistakes that bite after launch are a small, repeating set: API keys hardcoded into the browser, authorization checked only in JavaScript, no rate limits, no cost caps on AI calls, client-side paywalls anyone can edit, over-broad database permissions, wide-open CORS, verbose errors that leak internals, and piles of unaudited dependencies. They all share one root cause — the AI wrote the simplest code that made the feature work, and safety was never part of "work." None of them show up in the demo. All of them show up when a real user, or a curious one, arrives.

The mistakes, and why the AI makes them

1. Secrets shipped to the browser

The AI puts an API key where the code works, and the browser can't read server environment variables — so the key goes in a file that ships to the client. Anyone with dev tools reads it in under a minute. This is consistently the highest-leverage thing to fix; the secrets guide covers it in full.

2. Authorization checked in the browser

The app hides the admin page in JavaScript, but the server returns the data no matter who asks. The model treats "the user can't see the route" as "the user can't get the data." They're not the same — curl or the network tab gets the data directly. Authorization has to live on the server, on every request.

3. No rate limits

Every endpoint accepts unlimited requests because the model built the happy path, and throttling is a defensive layer you have to ask for. Without it, a single script can take the app offline — and it compounds with the next one.

4. No cost ceilings on AI calls

An app that calls OpenAI, Anthropic, or Gemini with no per-user limit or daily cap is one recursive bug or one bad actor away from a runaway bill. Adding cost controls is a deployment concern the model doesn't think about, so it doesn't.

5. Client-side paywalls

Premium features gated by a JavaScript variable, with API endpoints that don't check payment state on the server. The model builds the visibility logic next to the UI logic — in the frontend — so anyone who edits the page unlocks the paid tier. Feature access has to be verified server-side, same as auth.

6. Over-permissioned credentials

Service roles and database users granted admin-level access, because broad permissions make every code path "just work." The principle of least privilege — each credential gets only what it needs — is skipped, so one leaked credential becomes a compromise of everything.

7. Wide-open CORS and missing CSRF protection

The model kills a CORS error by setting the most permissive policy (Access-Control-Allow-Origin: *) and doesn't add CSRF tokens, because that's a separate framework concern. The result: other sites can call your authenticated API on behalf of a logged-in user.

8. Verbose error messages

Errors return stack traces, database schema, or internal paths — useful in development, dangerous in production. The model doesn't switch to sanitized errors by default, so an attacker maps your architecture just by triggering failures.

9. Unaudited dependencies

AI tools add packages liberally to solve problems. The dependency tree grows, the audit never runs, and known vulnerabilities accumulate. A single vulnerable transitive dependency can expose the whole app — and npm audit / pip audit would catch most of them if anyone ran them.

How much does this actually happen?

Enough that it's the norm, not the exception. Veracode's testing across 100+ models found roughly 45% of AI-generated code introduced an OWASP Top 10 weakness. Rather than lean on any single number, the safer assumption is simple: if AI wrote a meaningful part of your app and you didn't do a hardening pass, assume several of the mistakes above are present until you've checked. They're common precisely because they come from how the tools work, not from any one careless developer.

Fixing them

The good news in a boring-but-real way: because the mistakes are patterned, the fixes are too. Most are a specific instruction you paste back to your AI builder ("read this key from a server-side environment variable instead of hardcoding it") or a small config change. Work in priority order — secrets and server-side auth first — using the pre-launch checklist to confirm each one actually holds. The Vibe-Coded App Hardening Kit ($79) ships all ten antipatterns with both the paste-back prompt and the manual code fix for each, so you're not reverse-engineering the solution from a blog post. For a genuine line-by-line review of the code itself, that's the Codex Code-Review & PR-Hygiene Pack ($79).

Most of these are app-layer mistakes; the model layer keeps its own list. The free LLM Security Audit covers it in 21 questions and skips anything your deployment shape has no surface for rather than counting it against you. Self-declared, not an audit of a running system.