The prototype cliff

I run a pipeline that collects stories about clinicians that build software; three times a week it drags in fresh signals from forums, launch pages and research feeds. One entry from this spring is a typical vibe-coding story. A founder spent $8,000 and a string of late nights building a healthcare MVP with AI tools. The demo glowed: real screens, real workflows, a pilot ready to go. Then the clinic asked for a business associate agreement (BAA), the paperwork that makes a vendor legally accountable for patient data, and the pilot stopped dead. One reply was almost tender: "Welcome to the world of compliance. You can't vibe code compliance."

That story is the 2025-26 building wave in miniature. Vibe coding removed exactly one barrier: the technical skill to write software. A clinician with a laptop and about twenty euros of AI credits can now produce in a weekend what a development team would have quoted six figures for. Every other barrier is still standing where it always stood.

The demo is the easiest 10% of clinical software, and it now takes a weekend. The invisible 90% (compliance, security, validation, maintenance) is unchanged, untaught, and is where most clinician-built tools quietly die.

The 90% has numbers now

John Brownstein of Boston Children's Hospital put it plainly at a Harvard Chan panel in July: "It's very easy to vibe code a prototype. It's very different to have it deployed in the enterprise." That distance has started to acquire hard measurements. HIPAA Vault, a compliance host that audits AI-built healthcare apps, prices the gap between demo and deployable at 20 to 100+ engineering hours, and reports the same five debts in nearly every audit: permissions checked in the interface instead of the data layer, no tamper-evident audit logs, session tokens sitting in localStorage, an unencrypted local database, and no map of where patient data really flows. A Wiz security audit of 1,645 apps built on Lovable found roughly one in ten leaking personal data. A widely shared benchmark on X made the sharpest point: 57 to 80% of AI-built apps shipped a hidden failure while looking finished.

Looking finished is the trap. Last week a builder confessed on X that an internal tool he vibe-coded in March now has two organisations depending on it, one of them a hospital procurement team. There's no support plan, no agreement, no tests. Nobody decided any of that; it accreted, one useful link at a time. Over on r/HealthTech, a thread asking whether anyone else is nervous about AI-built healthcare apps skipping compliance drew its answers within hours.

The wall is conditional

The wall does not stand in front of every build, which is the part the doom-scroll version leaves out. The lane is set by what your software touches.

• Green lane. Your build touches synthetic or sandbox data, admin and backoffice work, no live clinical decisions. The 90% demands almost nothing: build freely, learn loudly.
• Amber lane. Your build touches real patient data or a real care workflow. Now you owe the compliance basics: a BAA or EU processing agreement, access control, audit trails, a data map.
• Red lane. Your build touches real diagnosis or treatment decisions in production. That means clinical validation, safety cases, medical-device territory.

Two things about these lanes almost nobody tells clinicians. First, the green lane is enormous: you can prototype anything there, even a patient-facing clinical app, as long as it runs on synthetic data in a sandbox. The regulatory questions arrive only when real patients and their data enter the picture. Second, for European builders the red lane has a little-known door in it: Article 5(5) of the Medical Device Regulation exempts software built and used inside one institution, for its own patients, from notified-body assessment, and that in-house status matters again under the AI Act. The wall stands at "placing on the market", not at "writing code".

One decision closes lanes before you write a line: where the code can live. A framework published on 11 August makes portability the pass-fail test. If a platform will not let you export your application, there is no compliant environment to move it into, and a walled garden turns remediation into a rebuild. Lovable, behind those 1,645 audited apps, says its standard plans may not carry HIPAA-covered data.

Guidance is only now catching up. VIBE-HI, the first governance framework for clinical vibe coding, appeared in 'Frontiers in AI' this year; it grades builds green to red and names the core hazard "comprehension abdication": shipping a tool you can't explain or safely modify. The whole field of clinician-shaped guidance is roughly one paper old. The teaching, meanwhile, has arrived in volume: SIIM runs vibe-coding webinars for imaging professionals, Johns Hopkins a two-part series, Harvard Chan a full "beyond vibe coding" course. We teach the joy of the demo. The step after the demo still goes largely untaught.

If you lead a healthcare organisation, your builders are already building; a 2026 survey found 57% of healthcare professionals have encountered or used unauthorised AI tools at work. A ban would switch off exactly the people closest to the problems worth solving. Lanes work better: name the green lane publicly, make the amber checklist explicit, and put an experienced escort on anything red.

And if you're the clinician with the weekend build: run the lane test before your colleagues start depending on the link. What does your tool touch today? If the answer includes real patient data, the 90% has already started, whether you've noticed or not. I collect the paths across the cliff (the builders who crossed it, the tools that will actually sign a BAA) at Clinicians That Code.

💥 May this inspire you to finish what the demo started.