The practical answer is yes, but only if the AI-generated code is treated as a component inside a regulated system, not as the thing that earns clearance on its own. FDA has already cleared 2,589 SaMD devices since 2016, and 963 of those were AI/ML-enabled; in 2025, clearances reached 390, with AI/ML making up 59% of the total [1].
What FDA Has Already Accepted
Vibe coding creates what some people call Dark Code: software no human has fully read. That is unsettling, but it is not disqualifying by itself; what matters is whether the team can show intended use, boundary, risk controls, and tests [2].
The larger regulatory pattern is even more useful than the label. CLI as Medical Device, SDK-as-medical-device thinking, Agile and IEC 62304 lifecycle work, and containerized submissions all point in the same direction: FDA has repeatedly evaluated software by its boundaries and evidence package, not by whether the code arrived through a conventional development culture [3].
That is why code origin is the wrong place to spend the argument. A model can draft the core logic; clearance still depends on whether the device is bounded, traceable, tested, and risk-managed. GMLP fits here as a bridge from model development to device-quality controls, because it keeps attention on data, validation, intended use, and human oversight rather than authorship [1].
The Wrapper Is The Submission
The most practical route is the one Innolitics describes as wrap, don't rewrite: define the boundary in the SRS, perform ISO 14971 risk management, wrap the core with input validation, error handling, and output verification, then finish with SOUP and SBOM handling plus traceability [1].
| Step | What it has to prove | What usually belongs in the file |
|---|---|---|
| Boundary in the SRS | What the software does, and what it does not do | Intended use, users, inputs, outputs, operating context |
| ISO 14971 risk management | That hazards were identified and controlled | Hazard analysis, mitigations, residual risk rationale |
| Wrapper functions | That the vibe-coded core cannot act unchecked | Input validation, error handling, output verification |
| SOUP and SBOM | That outside components are known and tracked | Third-party library inventory, version control, dependency review |
| Verification and traceability | That requirements map to tests and changes | Trace matrix, test results, prompt provenance, ADRs |
The wrapper is not there to hide a weak core. It is there to make the core replaceable, testable, and reviewable after the fact, which is the only version of speed that survives a submission audit.
That is also where prompt provenance logging earns its keep. PR templates, commit conventions, JSON sidecars, and ADRs do not make the software compliant on their own, but they do make it possible to reconstruct why a control exists and what changed when the model produced a new branch of logic.
Where The Boundary Still Matters
Not every clinician-built app belongs in 510(k), and not every AI-assisted workflow is a device. The first question is still whether the software falls inside FDA oversight at all; if it does not meet the device definition, the clearance question never starts.
If the product is in scope for section 524B, cybersecurity is part of the submission burden, not a decorative extra. Static analysis, dynamic analysis, software composition review, and an SBOM reinforce the same lesson as the rest of the pathway: a clean origin story does not substitute for a controlled system [1].
So the narrow, defensible judgment is this: vibe-coded medical software can pursue 510(k) clearance when the AI-generated code is treated as a potentially useful core inside a wrapper that carries the real regulatory load. The code origin is interesting in the design history, but the wrapper, the evidence package, and the intended use are what do the work.
References
- AI-generated code FDA clearance. Innolitics.
- Vibe coding in biomedical software. PubMed Central.
- AI coding medical devices. Starfish Medical.
Comments
Join the discussion with an anonymous comment.