I've seen a lot of vibe coded apps recently which are produced by people who appear new to making software. I don't have anything against the democratisation of software per se but there are risks that should be foregrounded when you build software by describing intent to AI.
In terms of risk, it's relatively benign in the context of a personal project or creating a proof of concept. But translated into commercial production contexts and coupled with the presence of sensitive personally identifiable information (PII), it creates risk. Particularly where compliance is not understood and actively managed.
GenAI code is seen to carry almost triple the number of security flaws compared to human-originated code. There are many studies by companies like Coderabbit, varying in method and sample size but they converge on the same conclusion: vibe-coding creates security vulnerability. Speed without understanding also creates risk and any security issue will compound with scale.
Tools are not the problem though, the lack of knowledge on the part of those wielding them is. It's akin to owning a first aid kit and assuming that makes you qualified to operate.
The notion of taste – the instinct that tells us not just what can be done but what should be done – has been a recurring theme in technical and creative contexts over the past year. In the design of an application, it might be a matter of taste on the part of the sponsor to exclude something, but it's also a matter of knowledge to know what you can't exclude or what requires maintenance.
Data Compliance
GDPR, or EU data protection law, imposes mandates on data collection from EU citizens. There are clearly set out legal obligations that apply irrespective of whether you are a commercial organisation in an EU member state or whether you're a vibe coder in Vietnam.
The moment you collect something as innocuous as an email address from an EU citizen, you submit to these obligations. This includes a procedural requirement to notify authorities of a data breach within 72 hours. I'm willing to wager that the majority of vibe coders don't know what a breach response plan is or what penetration and security testing requires in practice. In a typical software development lifecycle, security is the point of departure in architectural design. Secure by design is a far more effective approach than retrospectively patching a code base of indeterminable quality.
GDPR legislation is not token or ceremonial; there are substantial penalties, and the authorities weigh factors like the gravity of the breach, negligence or intent, mitigations and history. The penalty structure exists on two tiers: severe violations (e.g., violating core processing principles, data subject rights, or illegal transfers) carry the highest fines (4% or €20m). Lower-tier violations (e.g., administrative, security, or record-keeping failures) carry lower fines (2% or €10m).
You can calculate your exposure at GDPRfine.com but to reinforce the message that compliance is not optional, the GDPR Enforcement Tracker provides a database of all fines levied with details of breaches and penalties.
Meta have cumulatively incurred nearly €2 billion in fines, largely for unlawful data transfer to the US.
I have a number of heuristics that I use and have developed somewhat of a sixth sense for detecting vibe code apps. The following may help keep you safe:
- If an app looks vibe-coded and requires a login, check whether it uses OAuth from a trusted provider like Google or GitHub. If it does, check the scopes - email and basic profile should be sufficient. If the app wants access to your drive, calendar, contacts, or the ability to send data on your behalf, close the tab and clear your browser cache. If it feels excessive and isn't obvious, it's a red flag.
- If an application asks you to create a username and password, don't. You have no way of knowing whether the builder understands password hashing, session management, or secure storage. Your data will be highly vulnerable.
- Check for general red flag indicators: a page title that holds the name of the coding platform, a random-string URL from the hosting service, or an OAuth screen requesting an excessive number of permissions are all cause for concern.
- Don't assume that because an app functions, that it's secure. GenAI will produce functional code, not necessarily safe code. Working and safe are not the same thing.
If you're building with AI, check your database defaults before you ship. Some database products can create tables with row-level security disabled by default because they assume a level of technical literacy and product familiarity. Left in default configuration, this creates a data exposure risk with other authenticated users able to see all the data in the database. If the tool you use doesn't mention the need for this security, it doesn't mean the non-functional requirement to configure and uphold security doesn't exist.
If your app collects personal data from EU residents, it is incumbent upon you to secure informed consent, declare data use, secure storage and provide a mechanism to enable record deletion on request.
AI tools can convert ideas into working software or a proof of concept quickly enough to build shared understanding. But they don't close the gap between working software and knowing what you've built - how it's configured, whether the code meets professional standards, and whether it applies sound interaction design principles. Security compounds this: it is not a fixed target. Anthropic's Mythos - a model so capable at identifying software vulnerabilities that its public release was considered too dangerous - found thousands of flaws across every major operating system and browser within weeks of limited deployment. Taken as an indication, security is set to become the prevalent software development concern for years to come.
