What vibe coding is, and why it sounds great
Vibe coding — using AI to generate code rather than writing it by hand — is having its moment. The pitch is compelling: describe what you want, and the AI produces it. No tedious syntax, no debugging from first principles, faster results. It sounds great. In many respects, it is great.
Experienced developers I work with are using it to handle the mundane stuff — the repetitive, low-value tasks that used to consume expensive technical time. New workflows, more efficiency, better use of skilled people. That's genuinely good.
But like most things that sound great, the story gets more complicated when you look at who's using it and what they're actually building.
What professional software development actually involves
I should be clear about where I sit: I'm a systems administrator, not a developer. There's a significant difference. I build the systems that developers put applications on. I configure those machines to be as robust and secure as possible. What goes on under the hood to get there is considerable.
Developers then have their own part to play. Beyond meeting the functional objectives — and there are usually many — they need to deliver something that is robust and secure. Around them sit network professionals who are trying to stop bad actors getting in through the front door, and also trying to ensure that if someone does get through a vulnerability in the application, they can't get anywhere else. Each of these is a different discipline with a different focus, requiring different expertise.
A developer isn't thinking about network segmentation when they're debugging complex application logic. A sysadmin writing application code would likely produce something very different — possibly more secure at the infrastructure level, but probably not what you'd want your users to interact with. These disciplines exist because they need to.
At an enterprise level, there are layers on top of all this. Code follows guidelines. Changes are managed and documented. Repositories hold the full history of every change. There are rules around how Personally Identifiable Information (PII) is handled — because PII carries both legal obligations and financial liability in most jurisdictions. In larger organisations there's often a dedicated cybersecurity team running security scans against applications before they're allowed anywhere near the public.
This happens for everything from a simple web page to a complex enterprise system. The scale changes; the disciplines don't.
AI transfers efficiency, not responsibility
When experienced professionals add AI to this mix, something important doesn't change: responsibility. We gain efficiency, but we remain entirely accountable for whatever the AI produces when we use it in the course of our work.
I use AI heavily in my work. Many parts of a sysadmin's job involve significant amounts of code — usually the tedious, repetitive kind — and AI handles that well. It lets me do things that were hard to justify before. Like other professionals, my code goes straight into a git repository. It's auditable, repeatable, and backed up.
I also ask a lot of questions that I know to ask. A lot of them are about security. There are things I observe while the AI does its thing that raise my eyebrows — as a sysadmin and as someone who paid attention during their postgraduate study in cybersecurity. The experienced professional knows to question those things. They know when to push back when the AI is proposing something that amounts to accepting an unacceptable risk.
Risk is its own discipline within cybersecurity. At an enterprise level, technical professionals raise risks with risk managers because we see things from an angle that generalists simply don't. Unencrypted PII on a publicly accessible database for a system with negligible financial value but millions in potential liability if compromised? That's a hard no — and you don't need a risk matrix to get there.
The alarming end of the spectrum
Social media is filling up with vibe coders. Some of it is fine. Some of it is genuinely alarming.
Experienced developers finding new efficiency tools: great. People experimenting at home, turning interesting ideas into something tangible: great, actually. Innovation should be encouraged. A nurse who built an app to help colleagues with their workflow: interesting, and if it has merit, the right outcome is for it to be picked up and developed properly by people who understand the full stack of what they're building.
Then there's the other end. Utterly inexperienced "entrepreneurs" producing paid online services that they don't understand. They had an idea, they fed it to an AI, they spun up a server, and they let it run. Their payment processor works, so they're satisfied — at least until something goes wrong.
These people often have little idea how their codebase is held together, no understanding of how to maintain it, and a very limited sense of what could go wrong. Their data is probably not properly encrypted. It's probably not properly backed up. Their dependencies are probably not being updated. And they almost certainly wouldn't know how to respond if they were compromised — or even how to tell if they had been.
For a small venture, a compromise probably just closes them down with a handful of angry customers. That's unfortunate but contained.
The picture changes considerably when one of these "Vibe Code Engineers" finds themselves in a courtroom, being questioned by a forensic cybersecurity expert about the security failures in their product that caused their client significant financial harm. "I asked the AI to make sure it was secure and it said it was" is not a defence. It won't be treated as one.
There are plenty of things that go wrong in systems built by competent, experienced professionals with proper processes, tooling, and oversight. The failure modes in systems built by people who don't understand what they've built are not smaller — they're just less visible until they're not.
The reckoning that's coming
There will almost certainly come a point — probably soon — where a meaningful number of these ventures collide with the harder realities of running internet-facing services. Code they don't understand, sitting on systems they don't understand, architected in ways they also don't understand, gets compromised. Then they have to explain it to whoever has been funding them. Some of it will end up in front of lawyers.
The technology is neutral. What's not neutral is deploying it in contexts where the person holding the wheel doesn't understand the road.
Two warnings worth stating plainly
For consumers and businesses buying AI-built software
Vibe coders may be cheaper and faster to deliver. The question worth asking is whether they have genuine understanding of what they're producing, or whether they understand how to construct a prompt.
A trivial $5 utility app probably doesn't carry much risk. Something that your business depends on, that handles customer data, that needs to stay up under load, or that carries legal obligations if it fails — that's a different situation entirely. Don't let a low price tag or a confident sales pitch substitute for due diligence.
A prompt engineer who happened to have a good idea but no technical background is probably not the person you want to pay thousands a month for a system they don't fully understand. Unless you're buying the idea itself to have it developed properly.
For "AI engineers", "vibe code gurus", and AI enthusiasts
If you don't have a background in IT, you're not a professional — you're a hobbyist who is trying to make some money. That's fine as far as it goes. The problem is that what you don't know is exactly what's most likely to cause you serious problems.
Your idea may have genuine merit. It may not. But it's a reasonable bet that you've missed considerably more than you realise — not because you're careless, but because you don't yet have the context to know what to look for. If it goes wrong, it can go wrong expensively. Innovate by all means, but do it with clear eyes about what you're taking on.
My grandfather's circular saw
The best analogy I can come up with is my grandfather's old circular saw. I remember it as a kid — it lived in my father's cupboard in the garage and was never used. Big, heavy, and absolutely no safety features. In my grandfather's hands, apparently a well-used and effective tool. He was skilled with it.
A modern circular saw has a direction button to hold alongside the trigger, guards over the blade, and various other mechanisms designed to keep less experienced users safe. Years of engineering refinement to achieve the same outcome more safely.
Vibe coding is a bit like my grandfather's old circular saw.
Except it's plugged in, and it's sitting in a crowded bar at 11pm on a Saturday night.
Someone might do something genuinely useful to that table with the wonky leg. Someone else is probably going to be less fortunate.