Vibe Coding: Why the Security Warnings Are Justified – and What They Miss

Few terms have moved from niche to mass phenomenon as fast as "vibe coding" – building software by describing in natural language what should exist, instead of writing every line yourself. A study is currently making the rounds showing how risky that often turns out in practice: injection vulnerabilities, exposed databases, hardcoded credentials. A case from February made it tangible – a social network built through vibe coding lost one and a half million API keys and 35,000 email addresses through a misconfigured database.

At Luftschloss we build custom software ourselves with exactly these tools – Claude Code, Codex – and we even teach vibe coding in our seminars. Taking the criticism seriously instead of waving it away is, I think, the only honest way to deal with it.

What's true about the criticism

The numbers are unambiguous: injection attacks are by far the most common vulnerability category in the vibe-coded projects examined, followed by path traversal flaws, authentication errors, and credentials stored directly in the code. These aren't exotic attack vectors – they're the classics of web development, mistakes that have been known for twenty years and still happen when nobody is specifically looking for them. A language model writes code that works, when in doubt, not necessarily code that's secure. Those two goals only align when someone explicitly pays attention to the second one.

What's notable about the current study is the distribution: there's no even mediocrity, but two camps. A large share of projects sits in the critical range, a small group reaches a very high security level. That polarization is actually the more interesting finding – not the average, but the gap between the two groups.

Why this reminds me of the 95-percent debate

I recognize that polarization from a different context: why most corporate AI projects deliver no return. There too, it's not the model that separates the successful projects from the failed ones, but process discipline, integration, and accountability. With vibe coding the pattern is identical, just applied to code instead of business processes: whoever lets a language model write code and deploys the result unreviewed eventually gets an open database. Whoever surrounds the same process with review, standards, and clear boundaries gets something different.

What this means for our own practice

That's exactly why we've never dropped standards for our internal tools just because development got faster. In our central tool index, every tool gets deployed, documented, and made visible the same way – even if it was built in an afternoon with AI assistance. That discipline isn't a contradiction to the speed of vibe coding, it's its precondition. The mistake the failing 46 percent of examined projects presumably made isn't using AI to write code – it's dropping the part of software development that was never delegable to a model in the first place: taking responsibility for what goes live.

The same principle applies to the question of when custom software is even worth it, which I've described elsewhere: AI writes code, but it doesn't take on the decision of what the software should deliberately not be able to do – and that decision is exactly what closes security gaps before they exist, instead of patching them afterward.

The market reaction that goes too far

The worry that vibe coding fundamentally undermines the SaaS business model, because everyone now builds their own software, strikes me as premature. What's actually happening is a shift: standard software for standardized processes stays sensible, but the threshold for custom solutions has dropped. That changes who builds software – it doesn't suddenly make security, maintenance, and operations obsolete. The companies that capitalize on this shift will likely not be the ones that build fastest, but the ones that operate most reliably.

Conclusion

The security warnings around vibe coding are justified, and the numbers behind them are no reason to downplay them. What they miss is the conclusion many headlines draw from them: that the problem lies in the technology. As is almost always the case with AI-assisted work, it lies in the discipline around it – and that can be built, regardless of how fast the code itself gets written.