Vibe Coding in Medical Devices: Faster Build, Same Burden of Proof

Objectives

• Define “vibe coding” and safe scaffolding boundaries for MedTech teams.
• Separate responsibilities for AI as a code assistant vs AI features in the device.
• Map requirements to regs/standards (IEC 62304/81001-5-1, FDA PCCP, EU AI Act, NTIA SBOM).
• Provide a pragmatic validation approach (CSA/GAMP 5), plus prompt-logging patterns.
• Offer a concise checklist and primary reference links for implementation.

• Two tracks: AI as dev tool vs AI in the device
• Gaps vibe coding doesn’t close (and how to close them)
• If AI ships in the product (PCCP, AI Act)
• Postmarket surveillance duties
• Scaffolding: definition + safe examples
• GAMP® 5 for EU/GxP teams
• Prompt provenance (how to log)
• Quick regulatory & standards references

Two Tracks — Keep Them Separate in Your QMS

1) AI as a developer tool (code assistant). You are still shipping conventional software. Prove process control under IEC 62304 (software lifecycle) and IEC 81001-5-1 (secure health-software lifecycle). Add NIST SSDF (SP 800-218) for secure development practices and SLSA for build provenance.

2) AI in the device (AI/ML features). Treat the model as regulated functionality. In the US, plan a Predetermined Change Control Plan (PCCP) so you can update models post-market. In the EU, the AI Act (Reg. (EU) 2024/1689) stacks on top of MDR/IVDR obligations (risk management, data governance, transparency, human oversight).

What Vibe Coding Doesn’t Do (and How to Close It)

1) Design Controls & Traceability (IEC 62304 + ISO 14971)

• Maintain SRS/SDS, architecture, hazard/risk analysis, and a requirements→tests trace matrix.
• Classify software safety (A/B/C) and match verification depth to risk.
• AI-generated code never replaces formal design inputs/outputs; it must be reviewed and verified like any other code.

2) Secure SDLC & Supply-Chain Integrity (IEC 81001-5-1 + NIST SSDF + SLSA)

• Threat-model; run SAST/DAST; use software composition analysis (SCA).
• Treat any AI-introduced package as SOUP/dependency with provenance and CVE monitoring.
• Adopt NIST SSDF controls and SLSA build attestations for tamper-resistant, provenance-stamped builds.

3) SBOMs: Make Them Reviewer-Friendly (and Machine-Readable)

• Provide an SBOM aligned to the NTIA Minimum Elements and deliver it in SPDX or CycloneDX.
• Include operational “support” fields your team actually uses: maintainer/contact, update policy, coordinated vulnerability disclosure (CVD) intake, and end-of-support dates.
• Submit vulnerability monitoring and patchability plans consistent with FD&C Act §524B and FDA’s latest cybersecurity guidance.

4) Explicit Validation Protocol for AI Code Assistants (Inside Your QMS)

Qualify AI code assistants as production/QMS tools using a risk-based, outcomes-focused approach (GAMP® 5 and FDA’s CSA draft spirit):

• Allowed vs. prohibited uses: allow scaffolding and boilerplate; prohibit safety algorithms, medical calculations, and crypto.
• Gates: SCA = no high-severity vulns; SAST = no high-severity findings; unit coverage ≥ agreed threshold; property-based tests for algorithmic modules.
• Independent reviews: require second-person review for Class B/C code and two-person sign-off on risk controls.
• Audit trail: PR checklist with reviewer notes, test reports, and scan results filed to the DHF/Device File.

5) Testing That Matters

• Unit + integration + hazard-scenario tests tied to the ISO 14971 risk file.
• Usability verification when UI affects safe use (IEC 62366-1).

6) Documentation for Submissions

• Demonstrate human control of design and verification of risk controls.
• Include your NTIA-aligned machine-readable SBOM, vulnerability handling, and patch plan (per §524B).
• Use FDA’s Q-Submission program early for novel approaches.

If AI Is In the Device (SaMD/SiMD with ML)

• US — PCCP (final): Define what may change, how you will validate deployable changes, and how you will assess impact so model updates do not require a new submission each time.
• EU — AI Act + MDR/IVDR: Treat AI safety components as high-risk systems and meet AI-Act documentation on top of MDR/IVDR technical documentation.

Postmarket Surveillance Duty (Make It Explicit)

Under FD&C Act §524B and FDA’s TPLC cybersecurity posture, your submission and ongoing operations must cover:

• Monitoring to identify/address vulnerabilities (including CVD processes).
• Timely updates and patches, informed by SBOM-driven CVE watch and threat intelligence.
• Lifecycle maintenance aligned with IEC 62304 (treat security fixes as safety work).

What We Mean by “Scaffolding” (Definition + Examples)

Scaffolding is auto-generating repeatable, non-novel code structures that speed construction without replacing engineering judgment.

• Project bootstraps: repo layout, lint/format configs, CI skeletons.
• Boilerplate services: REST/gRPC endpoints, DTOs, pagination/filtering.
• Data plumbing: ETL glue, schema migrations, serializers/deserializers.
• Test harnesses: unit/integration test stubs, mocks, property-test shells.
• Client SDKs: typed API clients generated from OpenAPI/AsyncAPI.
• Ops artifacts: Terraform modules, Helm charts, Dockerfiles.

Keep out of scope for assistants: safety algorithms, medical-calculation logic, cryptography.

EU/GxP Audiences: Add GAMP® 5 (Second Edition)

• Risk-based “critical thinking”: scale documentation and testing by impact on patient safety, product quality, and data integrity.
• Tool categorization & supplier assessment: classify AI code assistants as tools; document intended use and constraints; assess supplier practices.
• Assurance by evidence: emphasize fit-for-intended-use outcomes over checkbox validation.
• Configuration over customization: minimize bespoke code; track deviations with tighter controls.

Prompt Provenance (Log It When Safety Is Touched)

Log prompts/outputs whenever generated code touches risk controls, safety-related modules, or regulated data paths. Keep it modular and linkable to SDLC artifacts.

A) PR Template Block

• Feature/Change ID (linked to SRS/URS)
• Risk Control IDs (ISO 14971 mapping)
• Prompt text + model/version (+ parameters if available)
• Human acceptance rationale
• Reviewer names/dates
• Evidence links (tests, scans, screenshots)

B) Commit Convention

feat(safety-control RCN-27): LLM-assisted refactor of alarm debounce
PROMPT: <hash-or-link>  MODEL: provider:model@version  params: temp=0.2
SRS: SRS-ALM-004  TESTS: T-ALM-019..025  RISK: RCN-27

C) ADR (Architecture Decision Record) for Bigger Impacts

• Context (hazard, SOUP, interfaces)
• Decision (keep/generated/rewrite)
• Consequences (verification, usability)
• Mapping (SRS ↔ SDS ↔ Tests ↔ Risk)

D) JSON Sidecar (Repo or Artifact Store)

{
  "change_id": "PR-1842",
  "safety_related": true,
  "prompts": [{
    "text_ref": "link-or-hash",
    "model": "provider:model@version",
    "params": {"temperature": 0.2},
    "timestamp": "2025-08-08T06:00:00Z"
  }],
  "artifacts": {
    "tests": ["T-ALM-019","T-ALM-020"],
    "scans": ["sast-2025-08-08","sca-2025-08-08"],
    "reviews": ["RV-62304-B-774"]
  },
  "trace": {"SRS": ["SRS-ALM-004"], "Risk": ["RCN-27"]}
}

Regulatory & Standards Quick Reference

• FDA — PCCP final (Dec 2024). Guidance
• FDA — Cybersecurity in Medical Devices (final, June 2025) & FD&C Act §524B. Guidance · FAQ
• EU — AI Act (Regulation (EU) 2024/1689). Official Journal
• IEC 62304 — Software lifecycle. IEC
• IEC 81001-5-1 — Secure health software lifecycle. IEC
• IEC 62366-1 — Usability engineering. IEC
• NIST SSDF SP 800-218. NIST
• SLSA — Supply-chain Levels for Software Artifacts. slsa.dev
• NTIA SBOM Minimum Elements. NTIA
• ISPE GAMP® 5 (2nd ed.). ISPE

Disclaimer: This article is provided for informational purposes only and does not constitute legal or regulatory advice. Always consult your regulatory and quality teams.