Dr. Ryan Hungate is an orthodontist and serves as Chief Strategy and Clinical Officer at Henry Schein One. He leads the company’s revenue cycle management automation and One Platform strategy. Dr. Hungate is also the founder of Simplifeye Inc. Prior to his career in dentistry, he worked at Apple, where he helped design the retail workflow.
For years, the limit on internal software in healthcare was engineering capacity. Vibe coding removes that limit and exposes a problem most IT organizations aren’t prepared to handle.
Picture a Tuesday morning huddle where someone points out that the numbers the team needs are scattered across three disparate sources and dashboards. Now, picture a tool that fixes it by that afternoon and provides a more holistic view of that information.
In enterprise software, noticing the problem was never the hard part. But getting anything built took a business case, a queue, and months or manhours. That asymmetry has defined technology in healthcare for two decades, and everyone involved has learned to work despite it. Eventually, clinical and operational staff stopped asking. IT learned to triage, and vendors filled the space with one-size-fits-all products that didn’t quite fit anyone.
That equilibrium is breaking. Vibe coding, describing a desired outcome in plain language and letting an AI system produce working software from it, removes the code-writing requirement. Most of the associated media coverage on this topic treats this as a speed story. In healthcare, speed is the least interesting part of it. Engineering capacity is no longer what limits how much gets built. Something else is, and it’s a function known most commonly as governance.
The bottleneck moved
Consider what a review process was implicitly built around. A finite number of engineers produce a finite number of products, each moving through security review, compliance sign-off, and validation at a pace the function can absorb. The queue was frustrating, but it was also a filter. Everything reaching production had passed through a number of hands.
Take away the coding requirement, and the input volume changes by an order of magnitude, while the professional review and oversight capacity remains the same. A practice administrator, a clinic manager, or a clinical coordinator can now produce something functional in an afternoon. The review function, calibrated for a dozen releases per quarter, is now the narrowest point in the system.
This matters more in healthcare than in most industries, and I’d be doing the topic a disservice if I didn’t plainly explain why. It’s because what the software touches is highly valuable and protected information. The failure mode worth planning against isn’t badly written code. Badly written code tends to break early and loudly, and someone fixes it. The failure mode is protected health information (PHI) moving into a system nobody sanctioned, with no owner of record, audit trail, and plan for the day the person who built it changes jobs. Nothing about that announces itself. You find it during a breach investigation or an audit.
Why the queue reflex won’t hold
The natural response is to route this new volume through the existing gate, which requires review and approval and prohibits the rest. It’s the correct instinct, but an insufficient plan, for a specific reason.
Gates hold when the sanctioned path is good enough that going around it isn’t worth the effort. In healthcare, the sanctioned path is slow for mostly legitimate reasons: integration surface area, compliance review, and clinical validation are real work. Added together, though, a modest internal tool can take most of a year. The person who identified the problem waits four quarters, and by then the workflow has shifted, or the priority has moved on.
People work around slow paths. That behavior predates AI by generations and shows up in almost every organization on Earth. What’s changed is the ceiling on what a workaround can produce. A workaround used to top out at a spreadsheet. Now it can authenticate users, query a database, and run quietly in a browser tab for years. A policy premised on holding the line will be respected mainly by the people who weren’t going to build anything anyway.
Three things that actually hold at volume
The productive question is what governance looks like when the builder population expands sharply, and most of that population has never read a security document.
Defaults instead of settings. Permissions, data boundaries, and audit logging can’t be options that a first-time builder is expected to locate and configure correctly. If a customer can misconfigure their way into a PHI exposure, that’s on the platform, not on them. These controls belong underneath the building experience, invisible unless something goes wrong, and must be designed for someone who will never open a security tab.
Tiering by consequence. A front-office dashboard reading ‘claim aging’ is not the same as an artifact that writes to the clinical record or shapes a care decision. The first can be genuinely self-service. The second needs the same validation and clinical sign-off it would require if a staff engineer had built it. Natural language changes who produces a tool, not what that tool is accountable for. Most organizations haven’t drawn that line. Drawing it in advance is considerably cheaper than drawing it after an incident.
Provenance by default. Every artifact should register itself on creation and identify the builder, the data touched, and the last run. Not because anyone will review all of them, but because the alternative is assembling an inventory in the middle of an investigation.
None of this is novel governance. It’s what most IT organizations already apply to production software, but it is moved earlier in the lifecycle and extended to a much wider population.
The early signal is smaller than you’d expect
The obvious place to look for early evidence is a large health system with an innovation budget. It’s showing up in dental practices instead, and the reasons hold up under scrutiny. A typical practice runs on a handful of people, has no engineering bench, handles PHI every hour it’s open, and absorbs every workflow inefficiency the same day it occurs. There’s no internal queue to escalate into, so when a tool doesn’t fit, the options have historically been to work around it or tolerate it.
Those constraints are loosening. An office manager builds the unpaid-claims view her biller actually uses, instead of filing a request into a vendor roadmap. A practice owner builds a scheduling report that matches how the office really runs, instead of reshaping the office around the software. Individually, none of these registers as significant. Collectively, they’re a preview of the future enterprise version. Because they show organizations with real regulatory exposure and no engineering overhead, working in live environments, what the guardrails need to be. Health systems will arrive at the same questions later, with more zeros attached and less room to experiment.
What’s worth measuring
For most of the past two decades, healthcare technology decisions were made at a structural distance from the patient, and the people closest to the work adapted around whatever arrived. That’s inverting. It’s a better arrangement, and it stays better as long as the safe way to build is also the easiest.
The metric worth tracking isn’t how much faster software gets produced. It’s how much of it gets built safely by people who’d never call themselves software builders. Organizations that invest now in designing that path will spend far less time later reconstructing what got built without one.