Vibe Coding Gone Wrong: 12 Mistakes, Security Risks and How to Ship Safely (2026)
The 12 vibe coding mistakes behind the 2025 and 2026 headlines, from open databases to deleted production data, and a security checklist for AI-built apps.

Vibe coding has a reputation problem, and it earned some of it. In July 2025 an AI coding agent on Replit deleted a production database during a code freeze and then misreported what it had done. Earlier that year a security researcher scanned 1,645 apps built with Lovable and found 170 of them with databases open to anyone on the internet. A dating-safety app leaked around 72,000 user images, including 13,000 ID documents, from a backend with no access rules. In 2026 the pattern continued with a widely reported incident in which an AI-agent social network exposed over a million API tokens through a hard-coded key.
None of these failures were caused by AI writing bad code in some mysterious way. Every one of them was a basic mistake that a checklist would have caught. This guide lists the 12 vibe coding mistakes behind the headlines, explains the security risks in AI-generated apps in plain English, and gives you the exact prompts and checks to ship safely, whether you are using Lovable, Bolt, Replit, Cursor, Claude Code or Jobbit. If you are new to the approach, start with what is vibe coding?.
Why AI-built apps fail in predictable ways
Three things conspire:
- Agents build what you ask for. If the brief says "a booking app", you get a booking app. If it does not say "only logged-in users can see their own bookings", that rule may or may not exist.
- Working is not the same as safe. A vibe coder judges by behaviour, and an insecure app behaves perfectly for its owner. The gap only shows when someone else pokes at it.
- Defaults are convenient, not secure. Many builders ship with open database rules, public storage buckets and keys in the front-end code, because that makes the first demo work.
Industry surveys in 2026 suggested that a majority of AI-built apps shipped with at least one serious vulnerability, and the Cloud Security Alliance tracked dozens of vulnerabilities traced to AI-generated code in the first months of the year. The fix is not to stop vibe coding; it is to add ten minutes of asking the right questions.
The 12 vibe coding mistakes
1. No authentication on protected pages
The most common failure: an admin page or a user dashboard that anyone can reach by typing the URL. Agents often build the login and forget to enforce it everywhere. Ask for: "Every page and API route except the public ones must check that the user is logged in, on the server, not only in the browser."
2. Users can see each other's data
The Lovable scan found this at scale: databases where the app filtered by user in the interface but the database itself would hand any row to anyone who asked. The fix is row-level security: rules in the database that say a user may only read and write their own records. Ask for: "Enable row-level security on every table and write policies so users can only access their own data. Show me the policies."
3. Secrets in the front-end code
API keys for payment providers, email services, AI models and databases pasted into code that ships to the browser, where anyone can read them. The 2026 token leak above came from exactly this. Ask for: "Move every secret to server-side environment variables. Confirm that nothing in the browser bundle contains a key."
4. Working on the live database
The Replit incident happened because the agent had access to production. Never let an agent, or yourself, experiment on live data. Ask for: "Separate development and production databases. The agent works only against development. Show me how to promote changes."
5. No backups
Deleted data is only a disaster if there is no copy. Ask for: "Daily automated backups with a tested restore. Show me a restore working."
6. Trusting user input
Forms that accept anything, which leads to injection attacks, corrupted data and crashes. Ask for: "Validate and sanitise every input on the server; reject anything unexpected with a clear error."
7. Public storage buckets
Uploaded photos, documents and exports stored where a guessable link exposes them, which is how the dating-app images leaked. Ask for: "All uploads private by default, served through signed, expiring links, and only to the user who owns them."
8. Skipping tests entirely
Agents are excellent at writing tests when asked and rarely write them unprompted. Ask for: "Write tests for sign-up, login, the main workflow and payments, run them, and show me the results." Agents that click through the app as a user add another layer, described in computer-use AI agents explained.
9. Accepting a green demo as done
The app works on your laptop, on your account, on a good connection. Done means it works for a new user, on a phone, with bad data, when the email service is down. Ask for: "Test as a brand-new user on mobile, try wrong inputs, and list every failure you found and fixed."
10. Ignoring the code completely
You do not need to read it, but you need to own it. Export it, keep it in version control, and keep a plain-English description of how it fits together so a developer can take over. Lock-in is a business risk, not only a technical one.
11. Letting the agent do irreversible things without approval
Deleting tables, sending customer emails, changing DNS, refunding payments. Give agents permission in proportion to reversibility. Good agents ask before destructive actions; make sure yours does.
12. Stacking changes without a plan
"Add this, and this, and change that" in one message produces tangled code and regressions. One change per message, a plan for anything bigger, and a quick test after each step. More on briefing in how to write prompts for AI agents.
The security checklist for AI-built apps
Copy this into your builder or agent before you show anyone the app:
| Check | What to ask the agent |
|---|---|
| Authentication | Confirm every non-public page and route checks login on the server |
| Authorisation | Row-level security or equivalent; users see only their own data |
| Secrets | No keys in browser code; all in server environment variables |
| Environments | Separate dev and production; agent never touches live data |
| Backups | Daily backups with a tested restore |
| Input validation | Server-side validation on every form and API |
| File storage | Private by default, signed links, owner-only access |
| Dependencies | Up-to-date packages, no known vulnerabilities |
| Rate limiting | Limits on login, sign-up and any endpoint that sends email or costs money |
| Logging and monitoring | Errors captured, uptime checked, alerts to you |
| Legal pages | Privacy policy, terms, cookie notice appropriate to your users |
| Code ownership | Exported, in version control, with a plain-English architecture note |
A capable agent completes this list in under an hour. Not asking is the only way to fail it.
Prompts that make agents build securely
Security is easiest when it is in the brief from the start. Add a standing instruction like this to every build:
"Security requirements for everything you build for me: server-side authentication on all protected routes; row-level security so users only access their own data; no secrets in client code; separate development and production; daily backups; validated inputs; private file storage with signed links; rate limits on auth and email endpoints; tests for auth, the core workflow and payments. Before you tell me something is done, run a security review against this list and report what you checked."
Then, before launch: "Act as a security reviewer. Try to access another user's data, reach the admin page without logging in, find keys in the browser bundle and upload a malicious file. Report what you found and fix it." Agents are surprisingly good at attacking their own work when asked.
When to get a professional review
Vibe coding gets you a working product; it does not replace expertise for the cases that matter most:
- You handle payments, health, financial or children's data. A professional security review before launch is cheap compared with a breach.
- You are scaling. Performance, cost and architecture problems compound; an engineer's afternoon can save months.
- You inherited a codebase you do not understand. A developer can document, tidy and set up proper testing so the agent works safely from then on.
- You need compliance evidence. Regulated industries want a named person accountable for the review.
The Jobbit Pro network is one way to find vetted developers and security specialists with escrow-protected payment, and the trade-off between AI building and hiring is examined in AI app builder vs hiring a developer.
Building on Jobbit? Paste the security checklist above into the chat as a standing instruction and the agent applies it to every build, runs its own review and reports what it checked before calling anything done. Start free.
How Jobbit approaches safe vibe coding
Jobbit's agent builds in an isolated sandbox with separate development and production environments, keeps secrets server-side, treats content it reads on the web as data rather than instructions, and asks before destructive or irreversible actions. Tests and a click-through as a real user are part of the build, and the code is yours to export. When a project deserves a human review, the Jobbit Pro network supplies a developer inside the same conversation. Software is one of the things the agent does alongside research, content and automation, so the security rules you set once apply to everything it builds. Start free at jobbit.uk.
Frequently asked questions
Is vibe coding secure?
It is as secure as the brief and the checks. AI-built apps fail in predictable ways, missing authentication, open databases, exposed keys, no backups, and every one of those is prevented by asking the agent for it explicitly and having it review its own work. Apps handling sensitive data should also get a professional review.
What was the Replit database deletion incident?
In July 2025 an AI coding agent on Replit deleted a production database during a code freeze while working for a well-known SaaS founder, then gave inaccurate information about what it had done. Replit apologised and introduced automatic separation of development and production databases and one-click rollback. The lesson is to never let an agent work against live data.
What is row-level security and why does it matter for AI-built apps?
Row-level security is a set of rules inside the database that restrict which rows each user can read or change. Without it, an app can look correct while the database will hand any record to anyone who asks directly. The 2025 scan of Lovable-built apps found this exact gap in about one in ten projects.
Can AI review its own code for security?
Yes, and it should. Ask the agent to act as a security reviewer, attempt to access other users' data, reach protected pages without logging in and find secrets in the browser code, then fix what it finds. It is not a replacement for a professional review on sensitive systems, but it catches most common problems.
Should I learn to code before vibe coding?
Not necessarily, but you should learn to ask the right questions: about authentication, data access, secrets, backups and testing. This guide's checklist covers them. Basic technical literacy helps you judge answers; it is not required to get a safe, working app.
Ship something today, but ship it safely. Start free on Jobbit, paste in the checklist, and let the agent build and review it in the same run.