Vibe coding must not become the Wild West

Let me start by saying where I'm coming from, because everything that follows depends entirely on it. For a few months now, I've been building again with vibe coding. AI has given me back something I'd lost, the pleasure of making something and seeing it run that same evening. With Claude Code, I'm migrating all my websites off WordPress this way, I'm building applications that serve me personally or in client and side projects; and what would have taken me weeks now takes me a few hours. So no, I'm not going to tell you it's a bad thing. I do it, I love it, and I think this democratization is good news.

Except that I'm seeing an enormous number of applications go by right now, and with nearly everyone who's getting started, there are two gaping holes. Compliance and security. These are two separate subjects, which almost everyone confuses, and either one can kill a project more surely than a competitor. The problem was never vibe coding itself. The problem is that we're settling on brand-new territory without a single rule. A frontier that's going to fill up whatever anyone says, because it's desirable and no one is ever going back. The only real question is whether we civilize it, or whether we get gunned down on it.

This is no longer about a tinkerer in his garage

You might think I'm talking about a few isolated amateurs. It's the opposite, and that's what makes the subject serious. An investigation by the firm RedAccess, reported and verified in May by Axios and WIRED, counted nearly 380,000 applications built with tools like Lovable, Replit, Base44 or Netlify, all publicly accessible on the web. Around five thousand exposed sensitive data. More than two thousand were leaking corporate, operational or personal information, laid out in the clear, without the slightest access control. Along the way, the journalists verified very real cases: a shipping company whose application listed which vessels were arriving in which ports, the internal financial data of a Brazilian bank, the non-anonymized customer conversations of a British furniture supplier, the clinical trials of a healthcare player. Many of these applications were even indexed by Google, so findable by anyone. No sophisticated attack in any of it, no exploitation needed. Just doors left open.

And look at the detail that says it all. On several of these tools, the privacy settings made the application public by default, leaving it up to the person to switch it to private if they thought of it. Most didn't think of it, because they didn't even know the setting existed.

Above all, these aren't just freelancers. It's also the marketing manager who cobbles together a campaign-tracking dashboard and plugs it into the BI tool where the real numbers live. It's the finance team pulling invoices into a dashboard before Friday's board meeting. Two very different populations, the solo builder shipping their product and the employee solving a problem faster than their IT department can, and exactly the same two holes in both. The most common flaw the investigation surfaced, admin access open by default to anyone who lands on the URL, is word for word the great classic of application security, user A who can read user B's data.

What's playing out here has a name, it's the gap between knowing how to build and understanding what you've built. The tool has erased the friction that used to force you to learn before deploying. We now produce without ever having had the mental model that would prompt the only question that matters, who can reach this and with what rights. The skill hasn't disappeared, it has just stopped being a prerequisite for putting something online. That's precisely where the frontier becomes dangerous.

Compliance, the thing nobody wants to hear about

Let's start with it, because it's the part we'd rather ignore. The moment your application is online, you're collecting data. It starts with a simple cookie banner, and it continues with every form, every sign-up, every purchase you store. From then on, you have obligations, and the idea is not to turn you into a paperwork factory.

At bottom, compliance comes down to one sentence. Someone entrusted you with their data, they trusted you, and your job is to live up to that trust and to be able to prove it. You don't need a multinational's level of legal firepower. You need to live up to what was entrusted to you.

In practice, before pushing to production, write real legal notices and a real privacy policy, not a copy-paste picked up at random from a site that vaguely resembles yours. And be able to answer three questions without hesitation: what data I collect, where it's stored, how long I keep it. If any of the three leaves you speechless, you're not ready to launch, you're ready to get into trouble. One last reflex, if you host outside the European Union, check what that entails, because it entails plenty of things you don't want to discover after the fact.

Security, and the good news that comes with it

The good news is that you can secure an application properly without being an expert. If you look at the major French breaches of recent months, the flaws that were exploited were almost never sophisticated. They were OWASP classics, mistakes you learn to avoid the moment you agree to spend a bit of time on them. You just have to understand what you're deploying instead of blindly copying what the AI hands you.

A few reflexes that change almost everything. Never hardcode an API key or a secret in your code, and turn on GitHub secret scanning, which alerts you if you do it despite yourself. Check your access controls, because the most common leak today remains the one where a user accesses another user's data, and that's exactly what shows up at scale in the investigation cited above. Never trust what the user sends, validate everything server-side. And use AI for defense as much as for building. Ask it to review your code looking for flaws, not just to produce features. It's as good at hunting down a security problem as it is at generating a page, provided you ask it to explicitly.

And the day the application starts generating real revenue, several thousand euros a month, have it tested by offensive-security professionals. A targeted test of three to five days is enough to start. I see too many applications that take in real revenue and keep neglecting this, when a single month of revenue would pay for the test. The math is easy.

Civilize the vibe coding frontier, don't close it

One last distinction, because it will save you from going in circles. Compliance, security and resilience are not the same thing. Compliance proves you handle data the way you should. Security stops it from being taken from you. Resilience keeps you standing the day something breaks anyway. Confusing them means ticking one box while thinking you're covering three, and that's often how you get caught out.

What reassures me is that even institutions have grasped which way the wind is blowing. The head of the British cybersecurity center used the last RSA Conference to call on the industry to make these tools secure by design, openly acknowledging that a ban wasn't a credible option. In other words, we don't close the frontier, we make it livable. It will end up populated either way. The only unknown is whether it's by people who have learned to protect themselves, or the hard way, through leaks and the regulator.

AI lets you build fast. Use it to build solid too. That's the only version of vibe coding that lasts.