Vibe coding — building apps by talking to an AI — is the fastest path from idea to working prototype that has ever existed. I build internal tools this way myself and teach it in a course. But there's a flip side the YouTube tutorials stay silent about: an app that works is not the same as an app that's secure and maintainable. And an amateur can't see the difference — precisely because they didn't write the code and don't understand it.
I'm not against vibe coding. I'm against the idea that understanding can be skipped. This article is a list of the mistakes I see most often — from clients who arrived with a "finished" app, and from course participants.
Vibe coding works, but without basic hygiene it's dangerous: 40–62% of AI-generated code contains vulnerabilities, and AI-assisted commits leak secrets at roughly twice the rate of human ones (GitGuardian 2026). The most common amateur mistakes: API keys hardcoded in the code, no server-side validation, a database without access rules, no version control, blindly accepting outputs, zero backups, and being unable to fix the app when it breaks. All of it can be learned in a few hours — but someone has to show you on a real app, not on slides.
Why write about this now
Because the damage has stopped being hypothetical. In March 2026, a vibe-coded app of a heavily hyped startup leaked its entire production database — 1.5 million API tokens and 35,000 emails. The founder had publicly bragged about "not writing a single line of code". And according to GitGuardian, 28.65 million new hardcoded secrets landed in public GitHub commits in 2025 — up 34% year over year, the biggest jump on record. AI-assisted commits leak roughly twice as often as human ones.
In other words: the tools are fantastic, but the average unsupervised output is leaky. Now the concrete mistakes.
Mistake 1: API keys and passwords right in the code
AI loves generating "working" examples with the key pasted straight into the source. An amateur copies it, deploys — and the key is public. Whoever finds it burns your API on your account (with paid AI APIs, easily thousands overnight) or reads your database outright.
The right way: keys belong in environment variables, never in code or the repository. And if a key has ever been in the code, deleting it isn't enough — it's in the history. It must be revoked and regenerated.
Mistake 2: trusting the client — no server-side validation
Vibe-coded apps often validate inputs only in the browser form. But the attacker controls the browser, not you. Anything — prices, roles, record IDs — can be sent to the server manually and modified.
The right way: every input is validated again on the server. A price is never taken from the form, always from the database. The user's role is checked on every request.
Mistake 3: a database open to the world
The classic from the Supabase/Firebase world: the app works because the database allows everyone to read and write. Row Level Security is off because "it kept throwing errors". Result: anyone with the project URL can download — or overwrite — all the data.
The right way: RLS on for every table, rules written from "nobody may do anything" and opened one by one. This is exactly the thing AI won't do on its own — you have to ask for it.
Mistake 4: no version control — "it worked yesterday"
An amateur iterates by rewriting a single live version. When the AI breaks something on the tenth edit (and it will), there's no way back. I've seen people lose two weeks of work this way.
The right way: git from minute one, a commit after every working change. In vibe coding it matters double: AI changes code fast and broadly, and a commit is your only "undo". Bonus: AI editors are much easier to steer with git history.
Mistake 5: blind acceptance and the "regeneration loop"
Two forms of the same mistake. First: accepting code that looks like it works without reading it — that's how hallucinated dependencies enter the app (attackers register packages with names AIs make up) and how security holes ship. Second: when something fails, hammering "try again" until a result happens to pass — instead of understanding what's wrong. After five regenerations the code is a goulash even the AI doesn't understand.
The right way: small steps, read the diff after each one (at least roughly understand WHAT changed), and on an error, read the message first and send it to the AI with context — not "it doesn't work, fix it".
Mistake 6: thoughtless deployment — prototype straight to production
Vibe coding tempts you to release the first version that moves. No rate limits (the API bill explodes), no database backups, no separation of test and live environments, an admin interface on a public URL.
The right way: a pre-launch checklist — rate limits on endpoints, data backup, a separate environment for experiments, admin behind a login. An hour of work that will one day save the company.
Mistake 7: being unable to fix the app when it breaks
This is the expensive one. The app runs, the business starts depending on it — and then the payment gateway stops working, a third-party API changes, a certificate expires. The amateur who "clicked the app together" has no way to diagnose the problem, because they never understood how it works. Best case, they pay a developer; worst case, they lose data and customers.
The right way: understand at least your own app's architecture — what runs where, how data flows, where the logs are. That's not programming; that's an hour of explanation. And it's exactly what anyone teaching vibe coding should teach you.
Does this mean "don't do it yourself"? No.
The opposite. Vibe coding is a skill I recommend to every company — internal tools, calculators, prototypes, automations. Things you used to hire a developer for at tens of thousands, you can now do in an afternoon. But it's a skill, not magic: the difference between a person who has it and a person who clicks "regenerate" is exactly the seven points above.
That's why my vibe coding course isn't "look what AI can do". In 3 hours we build a real app live — and along the way cover git, keys, validation and deployment, on real code, not slides. You leave with an app AND with knowing what you built. For companies I run custom training. And if you've already built an app or website and suspect it has holes — get in touch, I'll go through it and tell you straight what's fine and what isn't.
Summary
Vibe coding is a legitimate, fast path to your own app, but AI-generated code contains vulnerabilities in 40–62% of cases and leaks secrets twice as often as human code. Seven mistakes decide the outcome: keys in code, missing server-side validation, an open database, no git, blind acceptance of outputs, prototypes in production, and being unable to fix what you never understood. All of it can be learned in one afternoon — from someone who actually builds and runs applications.
Sources and links
- GitGuardian: State of Secrets Sprawl 2026 — 28.65M leaked secrets, 2× leak rate in AI commits
- Vibe Coding Has A Massive Security Problem — Forbes on the 1.5M-token incident
- IBM: Vibe Coding Security Risks Aren't Like Ordinary Security Risks
- CSA: Vibe Coding Security Crisis — Credential Sprawl and SDLC Debt
- Vibe coding security: 7 risks and fixes (2026) — the 40–62% vulnerability range