Is Vibe Coding the New Trojan Horse?

If you’ve never heard of vibe coding, the short version: it’s building working software by describing what you want in plain English and letting AI write the code, no development background required. There’s plenty more written on it if you want the full picture.

Here’s the bit that should actually get your attention: whether you’ve heard of it or not, there’s a good chance it’s already inside your company. Someone on your team has quietly built something. It works. People are using it. And you, the person theoretically running the place, might not know yet.

Worth saying plainly: nobody’s being deceptive here. The Trojan horse in this story isn’t malice. It’s neglect. Something useful walks in the front door, and nobody decides whether it should have the keys. Britain’s National Cyber Security Centre has said as much publicly: vibe coding is reshaping how software gets built, and the security risk is real if organisations don’t adapt. Worth five minutes of your Monday. Here’s the twist though: it’s not really a bad news story. Vibe coding, at its best, is one of the smartest things to happen to business in years. It’s also, left unmanaged, a fantastic way to find out the hard way what “single point of failure” means. Both are true. Nobody’s telling you the second half.

One clarification: a developer using AI to code faster is still applying years of judgment to what comes out. That’s engineering. Vibe coding is someone with none of that judgment, prompting their way to a working tool with no one able to catch what’s wrong. Same technology, different risk entirely.

The good bit first, because there is one

Somebody in your team, not a developer, just someone fed up with a broken process, describes what they want in plain English, and out comes a working tool. No dev team. No six-month wait. No fifty-page spec document that three people skim and nobody actually reads.

And here’s the part that should genuinely impress you: it’s often better at capturing what the business actually needs than any requirements document your team has ever produced. People don’t know what they want until they can poke at something real and say “no, not like that, like this.” Vibe coding gets you to that moment in an afternoon.
So yes. Let people build. Encourage it, even. Keep reading, though.

Where the story turns

Nobody ever sits in a meeting and formally decides “let’s run the whole department on the thing Dave built in an afternoon.” It just… happens. One team adopts it. Then another. Then, without a single decision being made by anyone senior, it’s quietly touching customer data, or running a process the business now actually depends on.

And here’s the punchline that’s rarely funny in practice: more often than not, the person who built it can’t fully read the code, and neither can anyone else on the team. It wasn’t written, it was generated. Once it’s running the show, you’re not operating software anymore. You’re operating a black box, and you’ve placed a bet on it without ever being asked to vote.

It’s not hypothetical. In April 2026, a security researcher going by @weezerOSINT found that Lovable, one of the best known vibe coding platforms, had left every project built before November 2025 exposed. A flaw in how it handled access meant anyone with a free account could read other users’ source code, database credentials, and customer data, in as few as five API calls. The researcher had reported it privately weeks earlier, only for it to be closed as a duplicate before going public. The company’s first statement, reported by The Register, called it “intentional behaviour.” That’s not a technology failure. That’s what it looks like when nobody owned the line between experiment and production.

It’s also not a one-off. Georgia Tech’s Vibe Security Radar project, which tracks vulnerabilities specifically caused by AI-generated code, counted six in January 2026. By March, that number was 35. That’s not a blip, that’s a trend line, and it’s climbing while most businesses are still treating this as an edge case.

Two ways this bites you, not one

Most executives, when they finally clock what’s happening, ask exactly one question: “what happens if it breaks?” Fair question. Half a question, though.

Sure, can the business survive if the tool goes down? Can everyone just go back to doing it the old way? Maybe. Assuming the old way still exists, and someone still remembers how to do it. In most businesses, that manual process died quietly the day the shiny new tool took over.

But here’s the one nobody’s asking, and it’s the one that actually costs you money and reputation: what has this thing already been doing while it worked perfectly fine? No security review. No one checking what data goes in or out. If it’s been quietly mishandling customer information for six months, reverting to a manual process tomorrow doesn’t undo a single thing. You can’t roll back a leak. It already happened.

The rebuild nobody gets around to

There’s a sensible version of this whole story. Vibe code the idea. Prove it works. Nail down exactly what the business needs. Then, once real weight is riding on it, rebuild it properly: proper architecture, version control, testing, someone on the payroll who actually understands every line. That’s not box-ticking. That’s the difference between a fling and a marriage.

Nobody gets to step two. Not because they don’t know it exists, but because there’s never a budget line for “rebuild the thing that already works fine,” and there’s never a crisis forcing the conversation, until, one day, there very much is. The tool runs beautifully right up until the moment it doesn’t, and by then the person who built it has left the company, the logic reads like a foreign language, and you’re trying to fix a live outage in code nobody on staff can explain.

A simple test, if you want one

Not every vibe-coded thing in your business needs the same level of scrutiny, and treating them all the same is its own mistake. Three buckets, roughly:

Play with it. Prototypes, internal experiments, anything nobody outside the team touches. Let it run wild, no committee required.
Watch it. Tools other departments now rely on day to day, but nothing customer-facing and no sensitive data involved. Someone should know it exists and check on it occasionally. That’s it.

Don’t touch it, until it’s rebuilt. Anything handling customer data, money, or a process the business can’t function without. This graduates to proper engineering or it doesn’t go near production. No exceptions, no matter how well it’s been running.

Most businesses have things sitting in the third bucket that were never sorted into it on purpose. That’s the whole problem in one sentence.

Here’s the only question that actually matters

Not “should we let people vibe code.” Let them. It’s too good a tool to lock away.

The real question, the one worth asking this week: which of the things quietly running your business right now did anyone actually decide should be running it, and which ones just wandered in and made themselves at home?

If you don’t know the answer, that’s not a technology problem. That’s a governance gap, and a cheap one to close, right now, before anything breaks. Anything disposable, keep building fast, no committee needed. Anything the business is genuinely leaning on moves into the grown-up version: properly built, properly tested, with someone accountable who can tell you exactly how it works, and exactly what happens the day it doesn’t.

Move fast. Let your people build. But decide, on purpose, which things get to matter, before you find out the hard way which ones already did.