Somewhere in your organisation, someone has probably already started vibe coding. A colleague in marketing who put together a sign-up tool with Lovable, an analyst who had ChatGPT write a reporting script. Vibe coding means describing what you want in plain language, after which an AI tool such as Claude, Cursor or Replit generates the code. Whoever uses it doesn’t need to be able to read that code. That explains how fast it’s spreading, well beyond the IT department.
For you as a decision-maker, the question isn’t how to operate such a tool, but what the result is actually worth. Is a self-built application like this allowed to process customer data? Who maintains it in a year’s time? And at what point does it need someone with proper expertise to look it over?
Working screens say little about what’s underneath
A professional developer writes code with an understanding of security, architecture and maintainability. That layer is missing from vibe coding: the AI optimises for a working result, not for safety or durability. As the person commissioning it, you judge what you see, while the risks sit precisely in what you don’t see. How data is stored. Whether passwords and API keys end up in the code. Whether the system holds up with more users than that one demo.
That doesn’t make vibe coding a bad idea. It makes it a tool, not a finished product: suited to some jobs, unsuited to others. The trick is knowing where that line runs.
Jobs it suits
Vibe coding is at its best where speed matters more than solidity. Think of:
- validating an idea before you free up budget for it
- a clickable prototype that shows colleagues or clients what you mean
- a throwaway tool for a one-off job, such as cleaning up a data file
- a small aid for a small team, as long as no sensitive data passes through it
In every one of these cases, the trade-off is the same: if it goes wrong, the damage is small and the lesson comes cheap. An afternoon spent experimenting with an AI tool costs a fraction of a full quotation process. You can read what that kind of build process looks like in practice in our article on building an app with AI without coding experience.
What it shouldn’t be trusted with
As soon as an application becomes business-critical, that calculation tips over. If the system processes customer data, GDPR requirements apply whether or not anyone with security knowledge has looked it over. If it needs to keep running while dozens of colleagues use it at the same time, architecture matters. And if it still needs to be adaptable in two years’ time, the quality of the code weighs more heavily than the speed at which it was produced. On those three points, security, scalability and maintainability, AI-generated code without review by a professional is unpredictable.
So draw that line in advance. For an exploration or a demo, nobody needs to look over your shoulder. For anything that touches customer data or carries a primary process, they do.
We use it ourselves, with craftsmanship on top
This isn’t scepticism from an agency that sees its trade under threat. Our own engineers develop AI-assisted: AI generates a first draft, an engineer reviews every line before it goes into production. That is how we capture the speed without the risk, for instance in projects around AI implementation. The difference with pure vibe coding isn’t in the tools, but in who is reviewing the work.
How to make a sensible start
Want to try it yourself? Pick a job that no customer data passes through and that you can discard without any pain, and treat what comes out as a sketch, not a finished product. If that sketch grows into something your organisation ends up relying on, you don’t need to throw it away: our engineers add the security, architecture and maintainability it doesn’t have yet. You can see what that involves under ongoing development and maintenance.