Vibe coding is defined as “the act or practice of using an artificial intelligence system to generate computer code.” In practice, it means describing what you want in plain language and letting AI write the software for you.

Vibe Coding: Everyone’s a Builder Now

Not long ago, the ability to create software was the exclusive domain of developers. It was expensive and time-intensive. If someone in a ministry office or a school needed a new tool, they would have to spend extraordinary amounts of capital or settle for something off the shelf that may not have been a perfect fit.

That moat is disappearing. People who have never written a line of code are describing a problem to an AI and vibe coding a solution that makes a genuine impact in their life. I think it’s one of the most hopeful shifts in technology I’ve seen throughout my career so far.

The people closest to a problem have always understood it best. Now they can fix it themselves, often in a very short space of time.

While this will inevitably create some problems and many of these solutions may indeed be slop, some of it will be amazing. We can either try to restrict these practices, which is like trying to hold back the tide, or we can ask ourselves how our governance needs to improve in order to make the most of the opportunity.

You Can’t Deploy a Screwdriver

The best way I can describe what’s happening is this: most vibe-coded tools behave like hand tools.

Think of a screwdriver. Someone finds it useful and lends it to the person at the next desk, who copies it and hands it on again. Within a month there are a dozen of them in drawers around the building, each a little different from the last.

For a screwdriver, that’s fine. For software that’s a problem. You can’t deploy a screwdriver to five hundred people. You can’t update the copies already out there, and you have no idea where any one of them has been or who has modified it along the way.

That is the situation most organisations are in right now with vibe coding. Every person holding one of these tools has their own copy, running their own version. There’s no penetration testing, security policy, no version control and no way to push out a fix when needed. Looking after it isn’t anyone’s job.

The problems that flow out of this situation are only just starting to become apparent now, but I guarantee you they will become more serious as user adoption grows.

The Hidden Risks of Vibe Coding

Key Person Risk

Most of these vibe-coded tools live in one person’s head. They built it, they know its quirks, and they’re the only one who can fix it. Then they change roles, or leave. The tool keeps running for a while (they usually do) until the day it doesn’t, and the team discovers nobody else knows how it worked.

No Way to Scale

Tools that are passed around can’t be deployed. Tools that can’t be deployed can’t be seen. And whatever can’t be seen, nobody can be held accountable for.

The more a tool gets shared without a proper deployment system, the more fragmented it becomes, and the less sustainable its usage will be. This effectively puts all of these new vibe-coded tools into a short boom-and-bust life-cycle, where someone creates a new tool, finds rapid adoption, and eventually it fragments into oblivion.

The Trojan Horse

This is the one that worries me most. A tool that travels by hand is the perfect hiding place for something malicious. If someone slips harmful code into a genuinely useful little tool, it spreads on goodwill. People trust it because a colleague gave it to them. Nobody reviewed it, because there was never a process for reviewing anything. Understanding security risks here is key.

Add it all up and you get a messy internal software landscape: a junk drawer of half-tools that everyone depends on and nobody owns.

Create, Then Curate: A Better Approach to Software Governance

When leaders finally see the mess vibe coding can leave behind, the instinct is to muzzle the builders and send everything back through IT. I understand the motivation, but by doing this, you risk destroying the very advantage all of this new technology provides.

The better path requires you to hold two solutions in tension.

The first is to empower people to create. Every tool someone builds tells you something about what your team actually needs, even the ones that turn out to be throwaway experiments. You want more of them. 

The second is to build a path that professionalises the best of them. When a tool proves its worth, someone needs to pick it up, review it and rebuild it as proper software, with version control, a security review, a deployment pipeline and a person accountable for it.

Governance has its place, and some guardrails will always be needed. Where I see the bigger opportunity is curation: spotting the tools that matter and turning them into software the whole organisation can rely on.

The Uncomfortable Truth

This might seem fairly straightforward for a software company, but most of the organisations that will be affected by this are not software startups. They probably don’t have the internal skills to execute what I’m suggesting.

As uncomfortable as it is for some of those organisations, it is going to mean one of two things:

  1. Adding internal capacity to be able to manage a custom software stack.
  2. Finding a technology partner who can do it on their behalf.

I know this is an extra cost no matter which way you solve it, but there is also a high cost to inaction. Plus the efficiency gains and the fit-for-purpose solutions that your team can identify for themselves will hopefully bring you value that will more than compensate for the extra expense.

Questions to Ask About Vibe Coding in Your Organisation

If you recognise your organisation in this, here are a few questions worth sitting with:

  • Which tools would cause real disruption if they stopped working tomorrow?
  • Who built them, and who could fix them if that person left?
  • How many people use each one, and which version are they on?
  • Has anyone checked what those tools do with your data?
  • Which of them have earned the right to become proper software?

If you are experiencing this in your organisation, I would be interested to know how you are approaching it.