Vibe coding: the security and scalability risks of AI-built websites
In short: vibe coding —asking an AI to write a whole application and shipping it without understanding or reviewing the code— is great for prototypes, not for products that handle money, customer data or real traffic. The most common failures are exposed keys, endpoints without authorization, open databases, hallucinated dependencies and architectures that collapse as they grow. AI speeds things up, but engineering (review, testing, security and architecture) is still what makes a product work without exposing you.
What is vibe coding?
The term was popularised by Andrej Karpathy in early 2025 to describe a way of programming where you "give in to the vibes": you describe what you want in natural language, accept whatever the AI generates and, if something breaks, paste the error and ask it to fix it. You don't read the code; you only check whether it "seems to work".
For a weekend demo it's fantastic. The trouble starts when that same result is delivered as a business's website or app: with real users, payments, personal data and the expectation that it works the same for 10 people as for 10,000.
Why can a website built "by prompts" get expensive?
Because AI optimises for code that looks right and compiles, not for code that is secure, maintainable or scalable. And someone who can't read that code can't spot what's missing either. Several independent analyses published in 2025 —among them Veracode's report on the security of AI-generated code— found vulnerabilities in a very high share of the code models produce when nobody reviews it.
What we see again and again when we audit projects that come to Key Lab:
1. Keys and secrets exposed in the browser
Payment, email or database API keys written straight into frontend code. Anyone who opens the browser's developer tools can copy them and use them in your name (and on your bill).
2. Endpoints without real authorization
The screen hides the "delete user" button from non-admins, but the server endpoint doesn't check who is making the request. Calling the URL directly is enough to read or change other customers' data.
3. Open databases
Tables without row-level security, public collections in backend-as-a-service tools or connections allowed from any IP. It's the kind of mistake that ends in a data leak.
4. Injections and missing validation
User input reaching queries, commands or templates unvalidated: SQL/NoSQL injection, XSS, file uploads with no type or size checks.
5. Hallucinated or abandoned dependencies
Models sometimes suggest packages that don't exist. Attackers register those names with malicious code (a technique known as slopsquatting). Other times, unmaintained libraries with known vulnerabilities get installed.
6. No tests, no monitoring
Without automated tests, every change "breaks something somewhere else". Without logs and alerts, you learn about a failure when a customer complains —or after you've already lost sales.
What about scalability?
An app can work perfectly with five test users and go down on launch day. Typical symptoms:
- N+1 queries and missing indexes: every page fires hundreds of database queries.
- Everything on the client: heavy logic and full datasets downloaded into the browser, making the site slow on phones.
- No caching or queues: every request recomputes everything; long tasks block the user.
- State and files in the wrong place: impossible to scale horizontally or deploy without losing data.
- Runaway costs: calls to AI or third-party APIs with no limits, retries or usage control.
Vibe coding vs. AI-assisted engineering
| Vibe coding | AI-assisted engineering | |
|---|---|---|
| Who decides the architecture | The model, prompt by prompt | A team, before writing code |
| Code review | None ("if it runs, it works") | Human review + automated analysis |
| Security | Assumed | Designed: authentication, authorization, secrets, validation |
| Testing | Manual, sometimes | Automated on every change (CI) |
| Scalability | Discovered in production | Planned: indexes, caching, queues, limits |
| Maintenance | Every change is a gamble | Readable, documented, versioned code |
| Initial speed | Very high | High (AI speeds this up too) |
| Total cost | Low at first, high later | Predictable |
The difference isn't "using AI or not". At Key Lab we use AI every day. The difference is who is accountable for the result and which controls exist before the code reaches your customers.
Checklist: does your website or app need an audit?
If you answer "I don't know" to two or more of these, it probably does:
- Are API and database keys only on the server, in environment variables?
- Does every endpoint check who is making the request and what they're allowed to do?
- Does the database have access rules and tested backups?
- Are form inputs and file uploads validated on the server?
- Do automated tests run before every deployment?
- Do you know what happens if you have 10× more users tomorrow?
- Do you have logs, alerts and a plan if the site goes down?
- Are dependencies up to date and free of known vulnerabilities?
- Could another person (or team) maintain the code without rewriting it?
- Do you comply with the personal-data regulation that applies to you?
How we work at Key Lab
We're a software engineering studio: we build web, mobile, AI and tokenization products for companies that can't afford to have their platform fail.
- Architecture first: we define data, security and scalability before writing the first line.
- AI as co-pilot, not pilot: we use it to move faster, and every change goes through human review and testing.
- Security by design: authentication, authorization, secrets management, validation and audited dependencies.
- Measurable performance: Core Web Vitals, load testing and production monitoring.
- Project rescue: if you already have a vibe-coded app, we audit it, fix what's critical and tell you honestly whether to refactor or rebuild.
Frequently asked questions
Is vibe coding bad?
Not for prototypes, proofs of concept or internal tools without sensitive data. It's a risk when it's used for production products with users, payments or personal data and no professional review.
Can AI be used to write code safely?
Yes. AI is a great accelerator when it's used by a team that understands the code it generates, reviews it, tests it and applies security practices. What's unsafe is shipping code nobody understands.
How do I know if my website has security flaws?
With an audit: code and configuration review, dependency analysis, authorization tests on the endpoints and a database review. Many critical flaws aren't visible from the interface.
Is it better to fix or rebuild a vibe-coded app?
It depends on the underlying architecture. If data and authentication are sound, fixing and refactoring in stages usually pays off. If not, rebuilding the critical parts is cheaper in the medium term.
Do you have a website or app that "works, but you don't know how"? Book a review with Key Lab and we'll tell you what risks it carries and how to bring it to production grade. You can also see how we apply the same engineering to asset tokenization and to our lab projects.