Can You Use Vibe Coding for Medical Device Software?
Vibe coding, the practice of generating working software by prompting an AI rather than writing it line by line, is fine for proving a concept and has no place in the final build of a regulated medical device. That is the line Christian Espinosa, founder and CEO of the medical-device cybersecurity firm Blue Goat Cyber, drew on Open Door Salon. The FDA does not recognize vibe coding as a proven methodology, the governing software standard does not reference it, and the hidden vulnerabilities it introduces are exactly what a device cannot carry into a patient.
Is vibe coding ever acceptable in medtech?
Espinosa is not against the tool, only its misuse. For an early prototype or to prove an idea, he sees a place for it. The problem starts when that same code is treated as the real product.
"I think vibe coding is fine to come up with a minimum viable product or prove your idea, but it introduces a lot of vulnerabilities and challenges for a final product."
The distinction is between exploration and delivery. Vibe coding can help a team learn whether something works. It cannot be the thing that ships inside a device a clinician relies on.
Why does vibe coding fail FDA scrutiny?
Two reasons, and both are structural. First, the FDA expects manufacturers to follow secure software development for medical devices, captured in the standard IEC 62304, and that standard does not reference vibe coding at all. Second, the way the code is generated undermines security by design.
"I don't believe the FDA accepts vibe coding as a proven methodology. Technically, you're supposed to follow secure software development for medical devices, which is the standard IEC 62304."
When you vibe code, Espinosa explained, the model tends to pull in a range of libraries you did not ask for, each carrying its own vulnerabilities that then have to be tracked and managed. A device built this way starts life with an unknown attack surface. Unknown components are also what turn a software shortcut into a review problem, which is part of the wider question of whether the FDA is still the gold standard for getting a product cleared.
What is the real-world stakes test?
Espinosa uses a blunt question to cut through the enthusiasm. At an industry event, he heard an innovator describe using vibe code for an implantable device, so he asked whether that person would trust the device in someone they loved.
"Would you trust that device you're developing with vibe code in your grandmother if her life depended on it? He said no."
His point lands hard: this is not Silicon Valley, where you ship fast and patch later to chase revenue. In a regulated industry, a software flaw can harm or kill a patient, and patients have died from cyberattacks on medical devices. The tolerance for "build it quickly and hope it works" is zero.
How can an investor or buyer spot the risk?
The tell is simple and fast. Espinosa's diagnostic for anyone evaluating a medtech company is to ask which software-development standards the team follows and whether their developers actually work to those standards.
"They don't have an answer for the standards and you know that's a red flag right there."
A team that can name its standard and show how it follows it is managing its software as a regulated product. A team that cannot is treating a life-critical device like a consumer app. For an investor, that answer separates a fundable company from a future deficiency letter.
Where does that leave AI in the medtech stack?
Before any of that applies, a team has to settle a USB port is enough to make it a cyber device, and the bar is lower than most manufacturers expect.
The honest position is not prohibition but discipline. AI-assisted coding can accelerate the messy early work of figuring out what to build. The failure pattern is rarely the model itself and almost always the absence of a process around it, which is the same reason government AI projects fail even when the technology works. Once the goal is a device that will be submitted, cleared, and put near patients, the software has to be developed and documented to the recognized standard, with every third-party component accounted for, and traced back to its origin, which is the same discipline that answers whether a Chinese-made device is inherently less secure. The same discipline applies to the commercial path, where leaving reimbursement strategy until after clearance is its own version of shipping fast and patching later. The tension is real, and it is worth sitting with rather than resolving too quickly, which is the spirit of the full Open Door Salon conversation with Christian Espinosa and regulatory consultant Edwin Lindsay, drawn from the recorded, on-the-record discussion. Companies working through where AI fits in a regulated build can work with Open Door Salon to reach an audience living these decisions.