Between 1995 and 2015 I built software for care organisations. An internal portal first, then care management, task management, scheduling, payroll. Two of those tools earned proper names: JPLAN, a web-based planning tool for a 24/7 healthcare workforce, with vertical and horizontal checks and output straight to payroll; and Calblox, a task-assignment and registration platform, cloud-based, tablet-operated, built to be fast and secure.
Every one of them was held to the same standard, which I came to call the 3am nurse test: if a tool could not be used by a nurse at three in the morning, short-staffed, mid-emergency, with no manual and no patience left, it was not finished. Web-based, so it worked on whatever machine was nearest. Encrypted and redundant, because care does not pause for downtime. And roughly 90% of what those tools became was built on the feedback of the healthcare staff who used them.
Here is the part I have to be honest about. Every one of those improvements passed through me. A nurse would explain what was wrong with the roster view; I would translate her problem into code; a couple of hours or days later she would get a fix that was usually right (and occasionally subtly wrong), and the loop would begin again. For over twenty years I was the intermediary between the people who understood the work and the machines that ran their tools. The insight was always theirs. The bottleneck was me.
That bottleneck has just fallen. A nurse can now describe the tool she needs in plain language and watch it take shape the same afternoon. This piece is about what that means, what it does not mean, and why I built this site.
The 10% that gated the 90%
The technique now has a name: vibe coding, coined by Andrej Karpathy in February 2025 and Collins Dictionary's Word of the Year before the year was out. Strip away the hype and it means something precise: describing what you want in natural language while a large language model writes, runs and revises the code. You direct; the machine types.
The magnitude of the change is easy to underestimate and no longer possible to dismiss. By early 2026, clinicians had published vibe-coded teaching tools, a validated clinical nomogram, and an end-to-end omics platform “built in under 10 minutes for under two dollars” in indexed medical journals (Frontiers in AI). Dr Tom Kelly, the vascular surgeon who runs Heidi Health, shipped around 120 pull requests into production code in two months; he built Heidi's evidence-grading feature himself because explaining Cochrane review scoring to an engineering team “would take me to write like whole pages”. On the builder forums, the sober assessment sounds like this: “managed to do 5-10 years of work on my side project in a few months”.
Keep one number in mind, because the rest of this piece depends on it. Writing code was never most of the work of making clinical software real; it was maybe 5 to 10% of it. But it was the 10% that stood in front of everything else. You could not reach the hard parts (the compliance, the deployment, the maintenance) without first paying for that 10% in years of your life or someone else's salary. That toll booth just closed. The road behind it is still long; the point is that you can now get on the road.
You are a cohort, not a curiosity
If you are a clinician that builds, you have probably felt like an oddity: too technical for your ward, too clinical for the developers. The evidence says otherwise. As one observer put it bluntly this month: doctors don't want to vibe-code their own apps? “Wrong, they've been doing it for two years now.”
The cohort is deep and it is not new. 51 of the top 100 healthcare companies founded since 1985 had a physician founder. A single physician-community webinar this July showcased a nephrologist's journal-to-podcast tool, an emergency physician's 10,000-clinician sandbox for matching clinical ideas with engineers, a family physician's decision-support tool with localised guidelines, an AI triage assistant, and a communication-coaching platform built by a physician on top of scribe transcripts.
And this is not an American story. In April 2026, a group of NHS-orbit clinicians (largely from the Moorfields ophthalmology world, with co-authors in Germany and Canada) published Vibe coding for clinicians, a practical playbook written “by a group of early adopter clinicians” explicitly for colleagues with no coding experience. NHS clinicians did not just join this movement; some of them wrote its manual. The NHS has in fact had an organised coding culture for years: the NHS-R community started in 2018 and merged with the NHS Python community into NHS-OA in late 2025, in their own words for “strength in numbers”. Nurses are here too, from award-winning nurse-built tools to Singapore's nurse-specific development programme; which matters, because in my care homes the people who generated 90% of the good ideas wore scrubs, not suits.
But notice what is missing. The NHS communities are analytics-shaped: R, Python, data pipelines. The clinician who wants to build and ship a tool still has no obvious home. On the continent I can find almost nothing organised at all; European participation mostly means individuals joining UK or US clusters. Marcus Baw, a UK GP who has championed this space for years, said it precisely: “there is an appreciable Clinicians Who Code community; except they still mostly don't have a place to all work together.” Many small rooms. No commons.
The institutions just blinked
For as long as I have worked in care, the official answer to a clinician who wanted to build was some polite version of: "don't!". Log a ticket. Wait for procurement. That era is ending in public, and it ended fast.
Harvard's school of public health now runs a course literally titled Beyond Vibe Coding: Building AI Solutions to Transform Health Care, and its July panel argued not for stopping bottom-up clinician experimentation but for giving it pathways with guardrails. John Brownstein of Boston Children's Hospital described AI as changing “who does the building”: when a single clinician can “10 or 100x their capabilities”, the build-versus-buy equation of an entire hospital shifts. Doximity launched a Clinical AI Fellowship with over 150 clinicians from 123 institutions, most of them residents and fellows-in-training: the next generation is self-selecting into building. The Society for Imaging Informatics in Medicine offers continuing-education credit for vibe coding. A paediatric health system in Nebraska wants every clinician trained in vibe coding by 2027. And in Elsevier's survey of 2,757 clinicians across 118 countries, 79% said AI skills will become an essential component of medical education.
Something else follows from this, and it matters for timing. The first governance framework for clinical vibe coding was published this year; the rules, norms and expectations of this field are being written right now, mostly by institutions and vendors. The clinicians that build during this window are not just making tools. They are setting precedents for what clinician-built software is allowed to be. That is the real reason "why now": not because the technology is exciting, but because the norms are still wet.
The honest 90%
Now the part that the excited half of the internet skips, and the part I am perhaps most qualified to write. Vibe coding is the easy part. In my experience it is 5 to 10% of the whole; the other 90% comes after: maintenance, testing, security, privacy, failover and redundancy, support, the unglamorous years of keeping a thing alive while people depend on it. I spent two decades in that 90%. It is real, and no prompt makes it disappear.
The sceptics deserve their say, because their evidence is genuine. A security audit of 1,645 apps built on one popular vibe-coding platform found roughly one in ten leaking personal data: names, emails, phone numbers, and in several cases the builder's own API keys. One benchmark found 57 to 80% of AI-built apps carried a hidden failure; as its author put it, “AI apps look finished before they're ready.” A veteran on a medical forum warns that healthcare is “the most rigidly regulated area where you truly need an engineering mindset over a vibe coding mindset”. An IT leader predicts that after the celebration comes the morning where “IT is staring at 200 ungoverned tools nobody owns”. And the trust floor is real: only 37% of clinicians worldwide call AI tools trustworthy; 19% in the United States, 21% in the UK.
All of this is true. None of it is a reason to stay out. Two things changed that the sceptics' arithmetic misses.
First, speed. The 90% used to sit behind a wall you could not even approach without an engineering budget. Now a clinician reaches the hard part in days instead of years, with a working prototype in hand that proves exactly what is being asked for. The hard part has not shrunk; your ability to arrive at it has been transformed.
Second, fit. Software built by the person who feels the problem fits the workflow in a way procurement-driven software rarely does. I watched this for over twenty years from the other side of the glass: the best specifications I ever received were not specifications, they were nurses telling me what broke at 3am. When 57% of healthcare professionals have encountered or used unauthorised AI tools at work, that is not a discipline problem. That is unmet demand for tools that fit.
So the honest position is this: the sceptics are describing real failure modes, and they are describing the wrong lane.
The three lanes
Here is the framework this site uses for everything, and the single most useful mental model I can give you. The lane your project is in is set by what your software touches, not by what it is.
The green lane: no real patient data, no live clinical decisions. This includes all prototyping, even of fully clinical apps, as long as it runs in a sandbox or on synthetic data. It includes production tools that never touch patient data: rota builders, teaching apps, team communication, admin automation, patient-education materials. This lane is enormous, almost everything starts in it, and nothing stands between you and it tonight. No regulator anywhere objects to you building a triage app against synthetic patients. The joy here is unconditional.
The amber lane: real patient data or a live clinical workflow. Now the compliance basics arrive: GDPR and its national flavours here in Europe, HIPAA in the US, the DTAC if you are in the NHS. Data protection by design, access control, audit trails, a data-protection impact assessment. This is work, and it is learnable work; it is a checklist, not a priesthood.
The red lane: software that influences real diagnosis or treatment decisions in production. This is medical-device territory (the MDR in Europe, the FDA in the US) and it deserves its reputation. But even here sits an escape hatch that almost nobody in this audience knows about: under MDR Article 5(5), software manufactured and used within the same health institution, for its own patients, can stay outside notified-body assessment. The wall arrives when you place a product on the market, not when you build a tool for your own institution. For European clinician builders that is not a loophole; it is the deliberate, legal route by which in-house innovation is supposed to happen, and it is chronically underused because nobody explains it.
Read the lanes again and notice their intent: build freely and joyfully where nothing can be harmed; take the compliance work seriously the moment real patients are touched; respect device territory and know its in-house door. Regulation arrives at deployment to real patients. It does not arrive at building. Anyone who tells you otherwise is gatekeeping, not informing.
The empty middle
If the builders are real, the institutions are turning, and the lanes are navigable, why does this site need to exist?
Because of the shape of what is on offer. At the front of the funnel, abundance: hackathons, intro courses, CE-credited webinars, a fresh cohort of the curious every month. At the far end, abundance again: breach headlines, liability warnings, cautionary tales. In the middle, where a working prototype has to become a safe, maintained, adopted tool: almost nothing. The guidance that does exist for that step is nearly all written by vendors selling the solution to the problem they are describing. Meanwhile, only 32% of clinicians say their institution trains them well on AI, and among clinicians whose organisations already deployed AI, fewer than a quarter received adequate training; the trained and the untrained sit 43 satisfaction points apart on the very same tools.
The middle of the funnel is where I lived for twenty years. It is exactly the part I know how to map.
So that is what Clinicians That Code is: a commons for the middle. A verified directory of clinicians that build, so you can find a peer who matches your role, your country, your stack. A pulse of what is happening, curated three times a week. The Handover, a weekly briefing. And, coming next, the guides for the step nobody teaches: what to do after the prototype, vendor-neutral, clinician-first, and covering Europe as thoroughly as America, because right now almost nobody does.
A word to the organisations
If you lead a healthcare organisation, this last argument is for you, and I will ask the readers of this site to forward it.
Whatever your current position on clinicians building software, understand one thing: an organisation with vibe-coding-capable, trained staff will outperform an organisation without them. Not because the tools are magic, but because the build-versus-buy equation has already shifted underneath you; when one clinician can do the work of a small team, the organisations that harness that capacity compound it, and the ones that suppress it export it to shadow IT.
So free up resources for experimentation and training. Decide, deliberately and organisation-wide, how you will absorb this technology: involve your clinicians, your IT, your legal and compliance people, and develop an actual strategy rather than a policy of quiet prohibition. Boston Children's offers a working template: clinicians paired with IT, legal, finance and compliance to catalogue efforts, assess risk, and decide what moves from prototype to deployment. The failure mode is equally well documented: systems that activate AI tools faster than their clinicians can absorb them, and clinicians that build something valuable and then must, in Brownstein's words, ask for “forgiveness or favors” to deploy it.
Be aware, as with every automation wave before it, that this is an investment. The costs land early; the benefits arrive mid-term and long-term, and they arrive largest for the organisations that trained for them. The Harvard panel calls the executive skill “build literacy”: leaders who can specify a problem, evaluate a claim, and not be fooled by a demo. You do not need to produce clinician coders. You need to be the kind of organisation where the ones you already employ can build safely.
The real question is not whether you can afford to invest. It is whether you can afford not to.
Back to 3am
Somewhere tonight a nurse is fighting a roster tool that was designed by people who have never worked a night shift. For twenty years, fixing that required someone like me: an intermediary, a translator, a bottleneck. It no longer does. The people who have actually been awake at 3am can now build, or co-build, the tools that will pass the test; and every part of this site exists to help them do it safely, joyfully, and together.
If you already build: get yourself listed in the directory; you are the proof and the map for the ones behind you. If you are intrigued but have not started: pick a green-lane problem, the pettiest annoyance in your working week, and build the fix this week; and subscribe to The Handover so you don't walk alone. If you run an organisation: you know the question; answer it.
None of us is doing this for the technology. We are doing it because the people closest to care deserve tools worthy of them; and because healthcare, which is already remarkable, can be made even better than it is today.