The hidden risks of vibe coding in healthcare software

Vibe coding means building software by describing what you want in natural language, then letting an AI tool do the work and write most of the code. If you can explain the problem clearly enough, you'll get a solution that works. Moreover, you could be using it the same day. It's a far cry from traditional software development or procurement timescales.

The appeal in healthcare is not hard to see. The people who understand an operational bottleneck best are usually the ones living with it. But they're short on time and software development skills. If a referral coordinator can build the tool or system they need on a Tuesday afternoon, they can potentially solve a problem that could have sat in a queue of requests for months.  

The speed and power of vibe coding is seductive, but there's a safety risk. Researchers at Georgia Tech have been tracking security flaws traced directly to AI coding tools, noting a significant rise from January to March 2026. Veracode's 2025 report tested more than 100 AI models across 80 coding tasks, finding that around 45% of the code produced contained a common security weakness. The flaw could let someone reach information they shouldn't, such as pulling records out of a database through a form that was never meant to allow it, or seeing another user's data. The tools are not improving on this measure, even though they're constantly getting better at producing code that performs its primary function well.

The risk may not show itself for weeks or months

Take an operations manager at a private healthcare group. Outstanding insurance authorisations keep slipping through, so she uses vibe coding to build herself a small tool to track them. It's intended to pull in an export of patient names, procedures, insurers and dates. It sounds simple and logical and it works.

Within a few weeks the group's other sites are using it as well. Patient data now sits in a system that nobody has assessed. Access credentials are quite possibly written into the code itself. Nobody specified who should be able to see what, so everyone can see everything. Only the operations manager who built it knows how it was briefed and how it works. There's no documentation, because there was no development process that mandated it.

As the teams use the tool more, the manager adds a rule that highlights the patients who have been waiting longest. Over time, this starts to influence the order in which patients are seen. But waiting longest is not the same as needing to be seen first. A rule that nobody has assessed clinically is now shaping clinical priority, with no record of who decided it or on what basis. The tool has now evolved to expand its scope, but there's no accountability for the decision.

"When the same person is the user, the builder and the reviewer, the checks that are built in to a professional software development service don't exist. There's nobody whose job it is to ask what happens when the tool changes, or to notice when it starts doing something it wasn't built for," says Fay, Head of Information Security at Semble.

Regulatory obligations still apply to vibe coded software

Financial services, insurance and other regulated sectors all carry duties around software that handles customer information. Healthcare adds a further layer, because software can potentially shape clinical decisions as well as hold data. What counts is what a tool ends up doing, not the job it was intended or created for. The prioritisation rule in the example above is a small change with a significant consequence: the tool takes on a clinical function behind the scenes without anyone formally approving it.

In England, DCB0129 and DCB0160 set out clinical risk management requirements for organisations that make and deploy health IT systems. Since July 2025, the duty has been to comply with them rather than simply to "have regard to them". They apply where a provider delivers NHS-funded care; for many enterprise providers this is a significant share of their activity. Other countries handle clinical safety through their own frameworks, but the expectations are broadly comparable.

Data protection duties also apply when patient-identifiable information is involved, whether the tool or system is vibe coded or traditionally developed. Once software starts actively doing something for patients, beyond recording information, organisations may need to apply the MHRA's test for whether it counts as a medical device.

Building in-house and at pace using AI doesn't escape from any of this. The health institution exemption allows organisations to make tools for their own use, but it comes with conditions: quality management, traceability, technical documentation and monitoring once the solution is live. It's a big ask to consider and meet these robustly in an afternoon's work.

Clear rules work better than a blanket vibe coding ban.

Banning vibe coding could move it underground. It may be better to draw a clear line between tools that touch patient data and tools that don't. When people are motivated to vibe code a tool, it usually means there's a frustration in the current process or system. It's worth thinking about how people can raise these and get them fixed efficiently without taking matters into their own hands.

Fay adds, "For vibe coded tools of any kind, a manager with appropriate knowledge should review and authorise. Treat AI-generated code carefully: read it, test it and scan it before it goes near live data."

The reason platforms built for healthcare come with clinical safety documentation, data protection assessments and ongoing monitoring is that somebody has to take that responsibility, to protect patients and comply with the law. This is the space Semble operates in, working with providers who need technology that adapts to how they deliver care, with trusted safety and compliance.

Teams can build their own tools now, and for some tasks and processes it's a huge advantage. But in a clinical setting, organisations have to know when there are healthcare-specific duties and obligations to meet. If your operational staff are using vibe coding, make sure you have oversight and transparency. Informing and educating people is key, so they understand why a simple and rapid fix may carry hidden consequences.