The orthodoxy is cracking
For two decades, healthcare IT has held a defensible line against self-built code. The argument was coherent and, for its time, correct. Clinical systems handle special category data under Article 9 of UK GDPR. They operate under the Digital Technology Assessment Criteria (DTAC). They sit inside estates governed by the Data Security and Protection Toolkit. When they touch patients directly, they fall under the Medical Devices Regulations and, for software with a clinical function, the expectations of IEC 62304. Code written by someone who is not a professional developer, so the reasoning went, cannot credibly meet these standards. It would be insecure, undocumented, unmaintainable, and untestable. The door was, reasonably, kept shut.
That argument is now fracturing under its own weight. Not because the regulations have softened, but because the premise underneath it has changed. AI-assisted development, the practice informally known as vibe coding, has redistributed who can produce working code. More importantly, it has flattened the quality distribution between the “proper” developer and the clinician with an idea. If we are being honest with ourselves, the in-house developer is using the same foundation models, often the same prompts, and producing output of broadly comparable technical standard. The craftsmanship gap has narrowed to the point where it can no longer carry the weight of the policy built on top of it.
This forces an uncomfortable question. If the code is good enough, what exactly are we still protecting against?
The quality argument has collapsed
It is worth being precise about what vibe coding actually is, because the term invites caricature. It is not “non-technical people typing English at a chatbot and shipping the output to production.” It is a mode of working in which a human with domain expertise drives design decisions while an AI assistant handles syntax, boilerplate, library selection, and increasingly, test scaffolding and refactoring. The human remains in the loop for intent. The machine does much of the mechanical writing.
When the output from this mode is benchmarked against code produced by a professional developer using the same tools, the differences are smaller than most CIOs assume. Both artefacts will typically pass static analysis. Both will usually include reasonable error handling. Both will structure database access through parameterised queries, because the model was trained on corpora where that is the norm. The AI does not know whether the hands on the keyboard belong to a senior engineer or a specialty registrar. It writes to the same standard either way.
This matters because the historical case against citizen-built code rested heavily on assumed quality deficiencies. SQL injection. Hard-coded credentials. Missing input validation. Unmanaged dependencies. These failure modes were real, and they justified a firm posture. They are now substantially mitigated at the point of writing, not because amateur coders have become professional, but because the tool they are using was not available a few years ago and is now ubiquitous. The organisational policy has not caught up with the tooling reality.
If we maintain the old line, we are asking an increasingly difficult question to answer: why is code written by a staff developer using Claude or Copilot permissible, while code written by a consultant haematologist using the same model is not? The identity of the author is doing work that the code itself no longer supports.
What actually remains is compliance, and compliance is tractable
Stripping the old objection back honestly, the residual concerns are governance, assurance, and accountability. These are legitimate and they are not going away. A junior doctor who builds a triage-scoring helper in an afternoon has not performed a Data Protection Impact Assessment. They have not mapped the data flows, written a threat model, produced a software bill of materials, registered the system on the information asset register, logged the processing under Article 30, considered whether the output constitutes a medical device under MDR Rule 11, or thought about decommissioning. They have solved a problem. They have not produced an auditable artefact.
But note what this list actually is. It is a governance and engineering workflow. It is not a statement about whether the underlying code should exist. Every item on that list can be performed, by someone, after the code has been written. None of it requires that the original author be a professional developer. Some of it, particularly the clinical workflow validation, is arguably performed better by the clinician who built the prototype than by anyone else in the organisation.
The honest repositioning is this. The compliance gap is real. It is also a known, bounded, and well-understood gap. We know how to close it. We close it every day for procured systems, for research tooling, for integrations with national services. The machinery exists. What we have not done is apply it deliberately to the class of artefact that vibe coding produces, which is the small, targeted, domain-driven prototype built by someone with a problem and no previous access to the means of solving it.
The expensive thing is not the code. It is the insight that preceded it.
Here is the point that organisations tend to undervalue, and it is the pivot on which the whole argument turns. When a clinician builds a working prototype, the code is the least interesting thing they have produced. The expensive and rare artefact is the design. It embeds a precise understanding of a workflow failure, a patient need, a data bottleneck, a handover gap, or a cognitive load problem that the rest of the organisation may not even know exists. That design knowledge is extraordinarily difficult to extract through conventional requirements gathering. It walks into the office every morning and walks out again, and most of the time nobody asks it what it has noticed.
Moving a database from cloud to on-premises, if that is what compliance requires, is a weekend of engineering work. Adding structured logging, wrapping the service in the right authentication layer, registering it in the asset inventory, producing a DPIA, and pushing it through a DTAC-equivalent review is effort, but it is known effort. The activities are within the competence of any mature digital team.
What is not easily recoverable is the reason the tool was built in the first place. If the organisation rejects the prototype, the insight goes with it. The clinician learns, correctly, that the formal route does not want their contribution, and the idea is lost. What is lost along with it is the evidence that the problem exists at all, because the prototype was also a piece of field research.
We should care about this. Digital transformation strategies across the NHS and comparable systems repeatedly cite clinician engagement as a critical success factor. We have, collectively, a long track record of paying expensive consultancies to interview the same clinicians who are now, independently, producing running code that answers the very questions those interviews were commissioned to ask. The prototype is the interview transcript, and it compiles.
A proposal: sandboxed pathways for clinician-built and citizen-built code
The operational question is not whether to permit this work, because it is already happening in every organisation, visibly or otherwise. The question is whether to bring it inside the governance perimeter, where it can be assured, or leave it outside, where it cannot.
A defensible pathway has a small number of features.
The first is a genuine technical sandbox. Not a shared development server with production data copied into it, but an isolated environment with synthetic or properly pseudonymised data, controlled egress, logging by default, and a clear boundary between what is running inside it and what is not. This is straightforward infrastructure. Most organisations already have the components and need only the intent to compose them. For organisations without mature platform engineering, a modest Proxmox or Kubernetes footprint, carefully segmented, is sufficient to start. That is where we started and these platforms permitted scale into production ready MVPs.
The second is a lightweight intake process that accepts a prototype, not a specification. The clinician or citizen coder brings what they have built. The information governance and clinical safety teams review it against a proportionate checklist: what problem is it solving, what data does it touch, who has seen it work, and does the stated problem actually exist in the workflow as described. That last question is the single most important one. The overwhelming majority of the value is established the moment the problem is confirmed. Everything after that is engineering.
The third is a defined graduation path. Prototypes that survive initial review sit in the sandbox with monitoring, used by a small group of consenting colleagues, while a named engineer performs the hardening. Dependencies are pinned and scanned. Authentication is moved to the organisational identity provider. Logs are shipped to the central stack. A DPIA is written. If the workflow has clinical impact, a DCB0129 hazard log is produced and reviewed. At the end of this process, the artefact is either promoted into the supported estate, retired because the need has been absorbed by a procured product, or parked with documentation that preserves the underlying insight for future procurement.
The fourth, and this is the one most often forgotten, is attribution and credit. The clinician or operational staff member who brought the prototype in should be named in the eventual system documentation, included in the product governance, and recognised in whatever internal mechanism the organisation uses to acknowledge contribution. The incentive structure matters. If the career cost of surfacing an idea is zero and the career benefit is non-zero, the pipeline fills. If it is the other way around, it empties, and the organisation learns nothing.
The objections, honestly considered
There are real objections to this position and they deserve direct engagement rather than hand-waving.
The first is clinical safety. A tool that influences clinical decisions must be assured as a medical device where the regulations apply. This is non-negotiable and the proposed pathway does not loosen it. What the pathway does is provide a route for the prototype to exist safely while that assessment is performed, rather than forcing the choice between premature deployment and outright rejection. Many prototypes will turn out not to be medical devices at all. Some will. The sandbox is where that determination can be made calmly.
The second is supportability. Code written by a non-developer, even good code, may lack the structure that a maintenance team expects. This is true and it is not unique to vibe-coded artefacts. The graduation path includes refactoring as a standard activity. We should stop pretending that procured systems arrive in a maintainable state either. They frequently do not.
The third is scale. If the organisation opens this door, will it be swamped? Probably not, in the early years. The cohort of clinicians and operational staff who both have a problem they want to solve and the time to build a prototype is self-limiting. What opening the door does do is signal that attempts are welcome, which is the precondition for the cohort to grow at all. An organisation that cannot handle ten prototypes a year is, separately, an organisation with a digital capacity problem that needs addressing anyway.
The fourth is shadow IT. The concern that sanctioning citizen development will legitimise existing unauthorised tools is real. The correct response is amnesty with conditions. Existing informal tools that come forward voluntarily enter the sandbox pathway. Tools that remain hidden after a reasonable window are treated as unauthorised processing, which they already are. The amnesty surfaces the estate. The policy then operates on an estate that is visible rather than one that is assumed not to exist.
The closing question
The posture healthcare IT has held towards self-built code was correct for the environment in which it was formed. The environment has changed. Holding the old line now means accepting a specific trade: the organisation forgoes access to a growing body of domain-driven prototypes produced by exactly the staff whose insight it has been trying to capture for years, in exchange for a quality assurance benefit that the underlying tooling has already delivered for free.
That trade no longer makes sense. The remaining gap is compliance, and compliance is something our profession knows how to do. We manage it routinely for systems considerably more complex than the ones a clinician will build in an afternoon. The real scarce resource in healthcare transformation has never been code. It has been attention paid to the right problem. When someone with clinical insight cares enough about a problem to build a prototype in their own time, the correct organisational response is not to decline the artefact. It is to ask whether the problem is real, and if it is, to give the prototype a safe place to live while the governance is put around it.
The passion to fix a problem is the asset. The code is the receipt. We should stop throwing both away.