Vibe Coding For The Win? True or False?

Last time I wrote about AI and data theft, and the response made one thing clear — people want the story behind the headlines, not another panicky hot take. So let’s do it again, this time with the trend that’s either “democratising software” or “the beginning of the end,” depending on which LinkedIn post you scrolled past over your morning cuppa.

I’m talking about vibe coding.

If you haven’t come across the term yet, well done you — your digital hygiene may be impeccable. For everyone else, let’s have a proper look at what it is, why it’s not quite the shambles the clickbait brigade would have you believe, and the bits you genuinely do need to know before you ship your weekend project to thousands of paying users.

So what on earth is “Vibe Coding”?

The term was coined in early 2025 by Andrej Karpathy (ex-OpenAI, ex-Tesla, generally someone worth a listen). The idea is simple: instead of writing code line by line, you describe what you want in plain English, and an AI assistant writes the code for you. You read it, run it, ask for changes, and iterate.

“Build me a task tracker with a Kanban board, dark mode by default, and let users drag cards between columns.”

Sixty seconds later, there’s a working app. You tweak, you iterate, you ship. That’s the vibe.

By 2026 this has stopped being a novelty. Surveys suggest around 92% of developers use an AI coding assistant at least monthly, and roughly 46% of new code on GitHub is AI-generated, with that figure climbing. Y Combinator startups are openly admitting their codebases are 95% AI-written. So whatever you make of vibe coding, it isn’t a fringe movement — it’s how an awful lot of software is being built right now.

Why it’s not the villain the clickbait claims

Here’s where I’ll gently push back on the doom crowd. Vibe coding is genuinely brilliant for a fair few things:

Learning to code. If you’ve ever wanted to understand how a login form actually works, having an AI generate one and then explain it to you line by line is the best tutor most of us will ever have. Free, endlessly patient, and doesn’t tut when you ask the same question twice.
Prototyping ideas. You’ve had a business idea rattling around for two years. Vibe coding gets you from “wouldn’t it be smashing if…” to a clickable prototype in an afternoon. That alone is a revolution for founders, product managers, and anyone fed up with hearing “we’ll scope it next quarter.”
Internal tools and automations. Small scripts, dashboards, quick integrations between two systems your company uses — the sort of thing that’s been languishing in the backlog since forever. Perfect vibe coding territory.
Giving the non-technical a seat at the table. Operations folk, marketers, analysts — people who know their problem better than any developer — can now build the thing themselves.

The productivity bump is real. Research from AWS published earlier this year (2026) put the average gain at roughly 10%, which doesn’t sound like much until you multiply it across every developer on the planet.

So no, AI-assisted coding isn’t inherently evil. Anyone telling you otherwise is either flogging consultancy or hasn’t actually tried it.

BUT (you knew there was a but)

Time to be grown-ups about this. The same speed that makes vibe coding feel like magic is exactly what makes it dangerous when you don’t know what you don’t know.

Let me give you a very recent, very real example.

Case Study

The Moltbook saga

In early 2026, a developer built a viral “social network for AI agents” called Moltbook. The founder tweeted, essentially, “I didn’t write a single line of code, AI made it a reality.” The tech world absolutely lapped it up.

Within days, security researchers at Wiz found that the app had exposed 1.5 million API keys, 35,000 email addresses, and thousands of private messages. Not because of some fiendishly clever hack. Because of a single missing configuration setting in Supabase — Row Level Security wasn’t switched on, which meant the “public” API key sitting there in the browser’s JavaScript was effectively an admin password to the entire database.

The AI happily generated working code. What it didn’t generate was a question like “hang on, have you thought about who should actually be allowed to read this data?”

That’s the pattern. Independent research consistently finds that 40–62% of AI-generated code contains security flaws. Georgia Tech’s Vibe Security Radar tracked publicly documented vulnerabilities (CVEs) attributed to AI-generated code going from 6 in January 2026 to 35 in March. That’s not a trend — that’s a trajectory.

What you actually need to know

If you take nothing else from this article, take these:

Functional and secure are not the same thing. “It works” means the happy path runs. It tells you absolutely nothing about what happens when someone with bad intentions turns up. AI is optimised to make the demo run. You’re the one who has to ask “and what if they send this instead?”
Secrets do not belong in your code. API keys, database passwords, authentication tokens — these go in environment variables or a proper secrets manager, never hardcoded and certainly never pushed to GitHub. AI assistants will cheerfully pop them straight into the code if you don’t tell them not to.
Your database needs a bouncer on the door. Whether it’s Supabase, Firebase, or anything else, there’s almost always a setting that controls “who can read what.” Find it. Turn it on. Test it by trying to get at the data without logging in — if you can, so can everybody else.
Review the code, even if you didn’t write it. Ask the AI to explain what it generated. If you can’t follow the explanation, that’s a sign you’re not ready to ship that bit. It’s also a cracking way to actually learn.
Commit early, commit often. Use Git from day one, even if it’s just you on the project. When the AI confidently rewrites half your app and breaks it (it will), you’ll want a way back.

A few tools worth knowing about

You don’t need an enterprise security budget to look after yourself. A handful of free or low-cost tools will catch most of the common howlers:

GitGuardian / Gitleaks — scan your code for accidentally-committed secrets. Run them before every push.
Dependabot — built into GitHub, free; flags known vulnerabilities in the open-source libraries your AI pulled in without asking.
Snyk & Semgrep — static analysis that catches common security anti-patterns like SQL injection or dodgy input handling. Both have free tiers.
Supabase RLS policies — (or the equivalent for your backend) non-negotiable if you’re using a cloud database.
OWASP ZAP — a free, open-source way to prod at your running app the way an attacker would.

Whichever you pick, wire them into your CI/CD pipeline so they run automatically on every commit. If that sentence made no sense, no need to worry — it’s on the list for the next article.

A quick word on cloud infrastructure (for the SaaS-curious)

If you’re vibe-coding your way to an actual SaaS (Software as a Service) product, the cloud layer is where the Moltbook-class mistakes tend to lurk. A few rules of thumb:

Assume everything is public until you’ve made it private. Every bucket, database, and endpoint. Cloud defaults have improved over the years, but “better” isn’t the same as “safe.”
Use managed services where you can. A managed database from AWS, GCP, Azure, Supabase, or Neon handles patching and backups. You fretting about whether you remembered to update PostgreSQL is one fewer problem.
Principle of least privilege. Every service account, API key, and user role should have the absolute minimum permissions it needs to do its job. If your app only reads from a table, don’t give it write access “just in case.”
Turn on logging and billing alerts. If someone nicks your API key at three in the morning and starts racking up charges, you want to hear about it before the invoice lands.

So, Vibe Coding for the win?

True. Mostly.

It’s democratising software in a way we haven’t seen since the early web. It’s teaching people to build who never thought they could. It’s collapsing the distance between “I’ve had an idea” and “I’ve got a product.”

But it isn’t magic, and it doesn’t let you off the hook. The AI didn’t sign your terms of service. Your users didn’t agree to trust an LLM with their data — they agreed to trust you.

Build fast. Have a bit of fun with it. Learn as you go. But before you let anyone else’s data anywhere near the thing you’ve built, take the extra hour to make sure the doors are properly locked.

Your future self — and your users — will thank you for it.

Next in the series — Part 2 of 5

Secure prompting: how to ask the AI for secure code in the first place — and the surprising things you can just tell it to do.