Vibe coding – generating code from prompts without reading it, judging only whether it runs – is great for prototypes and not enough on its own for a product. The generated code often does run, but it can carry security holes, inconsistent structure and technical debt that someone will later have to understand, fix and operate. We use AI to move faster, but every line is reviewed by a human who owns it.
This isn't written by AI sceptics: we use code-generation tools every day. That's exactly why we can see where "I built it in a few evenings" ends and where software you can trust with customers, data and payments begins.
- Vibe coding is fine for testing ideas and internal tools. Andrej Karpathy, who coined the term, meant it for throwaway weekend projects.
- In Veracode's tests across 100+ language models, generated code introduced a security flaw in 45% of cases, and newer models didn't improve on that.
- Models also invent package names that don't exist, which attackers can exploit (slopsquatting).
- The biggest cost isn't the bug, it's that nobody understands the code when it needs changing.
- Keep AI as an accelerator: humans decide the architecture, humans review the diff, and agents never get production access.
What exactly is vibe coding, and what is it good for?
The term comes from Andrej Karpathy, who in February 2025 described it in a post on X as a new kind of coding where you fully give in to the vibes and forget that the code even exists. A detail worth remembering: he meant it for throwaway weekend projects, not production systems. Since then the word has stretched, and many people now use it for any prompt-driven development.
We draw a line between two things:
- Vibe coding: you don't read the code, you paste the error back into the prompt, and you repeat until it "works".
- AI-assisted development: the AI suggests, writes and refactors, but a developer understands, reviews and stands behind the result.
The first is perfectly legitimate when the stakes are low: a clickable demo for an investor, a quick idea validation, an internal script that reshuffles a spreadsheet. If you throw it away, no harm done. Trouble starts when the demo quietly becomes the product.
Why isn't it enough that the code "works"?
Because "it works" usually means it works on the happy path: valid data, one user, the developer's own machine. A product has to survive a lot more than that.
| Question | Prototype | Product |
|---|---|---|
| Who can see the data? | Anyone with the link | Only people with permission |
| What happens with bad input? | It crashes or behaves oddly | A clear error message and a log entry |
| How does the database change? | You regenerate it | Migrations and restorable backups |
| Who can fix it six months from now? | Whoever remembers the prompts | Anyone who reads the code and the tests |
Generated code won't ask these questions on its own. If you don't ask them either, nobody will.
What security risks does vibe coding bring?
Insecure defaults
Veracode's 2025 GenAI Code Security Report ran 80 coding tasks through more than 100 language models in Java, JavaScript, Python and C#. The result: generated code introduced a security flaw in 45% of cases. In other words, when there was both a secure and an insecure way to do something, the model picked the insecure one that often. According to the press release, the models failed to defend against cross-site scripting (XSS) in 86% of relevant cases, and while syntactic correctness improved, security performance stayed flat over time.
Missing access control
CVE-2025-48757 affected sites generated with Lovable: insufficient Row-Level Security (RLS) policies let unauthenticated attackers read and write database tables. Lovable disputes the classification, arguing that protecting an application's data is the customer's responsibility. They have a point, and that's precisely the lesson: the responsibility stays with you even if you didn't write the code.
Hallucinated packages
Models sometimes import dependencies that don't exist. Research by Spracklen et al. (USENIX Security 2025) found this happening at around 5.2% for commercial models and 21.7% for open-source ones. If an attacker registers the invented name with a malicious package, your next npm install runs their code. That's called slopsquatting. A 2026 follow-up found the range has narrowed with newer models, but the risk remains.
Agents with production access
In July 2025, SaaStr founder Jason Lemkin publicly documented how Replit's AI agent deleted his production database during a code freeze, despite explicit instructions not to make changes. The lesson isn't that one tool is bad. It's that an agent can do exactly as much damage as the permissions you give it.
How does fast code turn into technical debt?
Security flaws can at least be found. The harder problem is that a codebase generated prompt by prompt doesn't come from one mind. It often solves the same problem three different ways in three places, error handling is there one moment and missing the next, and on the next request the model would rather write new code than tidy up the existing code. Tests usually appear only if you ask for them.
The result is what we call comprehension debt: you have a working system, but nobody can explain why it works or what breaks if you change a line. Every new feature becomes slower and riskier, because you first have to reverse-engineer what's already there.
The perceived speed can be misleading too. In METR's randomised trial, 16 experienced open-source developers worked on 246 real tasks in codebases they knew well. With AI tools they took 19% longer, yet afterwards they estimated they had been 20% faster. METR itself stresses that the result applies to early-2025 tools and shouldn't be generalised to every setting. The takeaway still stuck with us: what you don't measure is easy to overestimate.
How do we use AI in our own development work?
We don't ban it; we put guardrails around it. Our rules:
- Humans decide the architecture. Data model, permissions, integrations: none of that comes out of a prompt.
- We read every diff. If we don't understand it, it doesn't get merged.
- Critical paths get tests: login, payment, checkout, data export.
- Every new dependency gets checked: does it exist, is it maintained, do we even need it.
- Agents get no production access and never see secrets.
- Authentication and payments get a separate security review.
If you already have a vibe-coded MVP that's starting to get serious, here's the order we'd suggest:
- Map where personal and payment data lives and who can access it.
- Check your database rules (RLS, for example) and any keys left in the code or the repo.
- Write tests for the revenue-generating flows before you rewrite anything.
- Review your dependencies.
- Only then decide: refactor or rebuild. Sometimes the MVP's real value is the validated idea, not the code.
If you're also weighing where building on AI actually pays off financially, we covered that in AI in your business in 2026.
Frequently asked questions
Can I build an MVP with vibe coding?
Yes, it's genuinely good for validating an idea. Just be clear that it's a prototype, and before real user data goes in, have someone review the permissions and security.
Do newer models write secure code now?
They write better code, but according to Veracode's measurements their security performance hasn't improved alongside syntactic correctness. A better model doesn't replace a review.
What's the difference between vibe coding and AI-assisted development?
Whether someone understands and owns the code. The same tool works for both; the difference is the process around it: reviews, tests, permissions.
Do you take over AI-generated projects?
Yes. We first assess what's in there and what the risks are, and only then tell you whether it's worth fixing or rebuilding.
If you want to turn a prototype into a product, or clean up a system that was put together in a hurry, see how we approach custom software development. For an app, webshop and website built together, take a look at our G8 Alakváltók case study.