Doctors in AI: What are we? What do we call ourself? WHAT HAVE THEY DONE TO US?!

Quick framing note before we get into it. The reason I'm writing this now is that I was in a LinkedIn conversation with a colleague at a competitor (not Ambience this time lol, before anyone asks) and we ended up riffing for a while on what to call the work we both do. They'll stay anonymous because I'm not going to put words in their mouth, but I want to flag the conversation happened, because I think it points at something useful: everyone in this space is currently struggling to define it. And I actually think that's good. It means the space is real, growing, and nobody's quite locked in the framing yet. My take after that conversation is that Clinical AI is the term that's going to stick, so we might as well lock it in and start defining it ourselves rather than wait for someone else to.

Anyways. On to the actual thing.

In recent years there's been a trend to be known as Clinical AI, or, you know, doctors that do AI stuff. And every time someone says it, I get the same vague unease I got when I first stumbled into Clinical Informatics.

What the hell is Clinical Informatics? Is it applied informatics in the biomedical domain? Idk, well then how is that different than bioinformatics or computational biology? Is it just being really good at installing Epic and standing up the operational processes around it? Honestly kind of, but I didn't fit that mold, and my PD at UCSF knew it. He was like, "we have this thing called Clinical Research Informatics that's more your speed," and that's a subset of Clinical Informatics. That actually made sense to me.

Brief aside. After being a state university grad and a lower-tier medical school graduate, I was a little surprised when a bunch of "high tier" institutions started interviewing me for informatics fellowship (informatics is NOT that competitive lol but still felt cool). After hearing my future PD at UCSF talk, I realized he'd become my barometer for the kind of person who had epistemic humility but also knew enough to not be narrow minded about the field. When I told other places what I wanted to do (apply transformers and NLP to medicine, no one knew wtf a transformer was outside the car-robots), they'd tell me "well that's actually bioinformatics" or "you should do grad school," and I'm like brother... (it was always a guy) did you read my resume before you interviewed me? Anyways. Only a few programs admitted that Clinical Informatics is this semi-loosely defined space where you can truly choose your own adventure and do research, and that's reflected in what I ranked: UCSF, U Buffalo (wildly smart PD as well), Columbia (obviously beast mode research there), and CHOP (aka Penn). Everyone else, even at big name academic places like Stanford or UW, basically told me I had to become an Epic operational agent, and I didn't like that and felt like that didn't define the field I'd just learned existed a couple years prior (but I WAS RIGHT DUDE, all of the fellows want to do AI research now lol, no one cares about Epic implementations [you still gotta do that and BPA advisory work, sorry fellows it's part of the job]).

Anyways. The space we've now come to call Clinical AI was not really a thing in the early 2020s. The first time I heard the phrase was when my old manager from Ambience (the first one, not the second, both great dudes) invited me to interview. He sent me the JD and it said "Clinical AI Researcher," and I remember thinking, hm, sounds made up, but cool as hell. I'm pretty sure that guy coined Clinical AI, at least in any meaningful sense. No one else was calling it that. Even competitors had things like "Clinician Scientist" or "Clinical Product Lead." I can't be 100 percent certain, but he was the first person I heard say it, and no one else was. Then suddenly the loud academics at Stanford and Harvard started using the term in their research, and it caught on quickly from there.

And so "what the hell is Clinical AI" started echoing through my head the same way "what the hell is Clinical Informatics" had a few years earlier. I'd been doing the work for at least a few years before I got the title, but here came that sinking feeling again. Who am I? What am I? WHAT HAVE THEY DONE TO US?

The four legs (of a unicorn)

Here's how I've come to think about it. Clinical AI is a loose collection of jobs-to-be-done and skills, and there are four of them:

• Clinical medicine
• Science: experimental design with decent stats and quantitative / logical thinking
• Product: figuring out what to build, for whom, and why it matters
• Engineering: actually building the thing, at quality, and shipping it

Quick precision on engineering, because I think the difference between engineering and what I'll call computational experimentalism matters here. Computational experimentalists like me are basically just bad software engineers who happen to be good at stats and can wrangle Python or R well enough to run a study, lol. That skill set lives at the intersection of science and engineering, and it's real and useful, but it is not the same thing as actually being an engineer. Real engineering is the thing that gets you from "the notebook worked once" to "the system runs in production and doesn't fall over." So when I say engineering is its own leg, I mean engineering proper, not "I can write a script that loops over a dataframe."

That's asking even more of one person than the three-leg story I used to lead with, which conflated engineering and the experimentalist-coder bit. In practice most people I meet have two of the four, occasionally three, very rarely four. You're looking for a unicorn, and the same question I used to ask about 2-of-3 now becomes a 3-of-4 question: if you're hiring someone who's strong in three and developing in the fourth, which combinations actually work and how do you support them?

One asymmetry to flag up front

Before going into the combinations, I want to flag something the rest of this piece is going to lean on. The four legs are not equally develop-able on the job. Three of them are. Science can be built up with the right mentorship and a real eval to run, that's literally how academic science training works: base science knowledge into mentorship under a PI. Product can be built up with reps and a strong PM to learn from. Engineering can be built up by writing code next to good engineers and getting your work torn apart in review. All of those have shortcuts.

Clinical medicine does not, at least not on the timescale that matters here. The training pipeline is years and there isn't a credible shortcut. (Maybe I'm biased here, being the guy who spent the longest time on this leg, but I think this one is just true.) So when I talk about archetypes below, treat clinical as a prerequisite rather than a substitutable leg. If someone has it, they have it. If they don't, the right move isn't a development plan, it's a structural one: a clinical partner who is permanent, not transitional. The other three legs can be coached. This one has to be hired in.

What if you can only pick two

Real quick on the 2-of-4 case, because most candidates are here. If you're hiring an IC who's solid in two legs, that's fine, but you have to be honest with yourself: they're going to need strong partners in the other two, and you have to actually staff those partners, not just put their names on a slide. The default failure mode is hiring a strong 2-of-4 and quietly assuming the gaps will close on their own. They will not.

The weakest 2-of-4 combo I see is Product + Clinical, with no Science and no Engineering to speak of. They tend to be illogical thinkers, basically project managers with clinical chops and "product sense." Part of why I think this is that I find the best product managers to be ex-technical people, usually ex-engineers, because quant and scientific reasoning teaches you how to be a good logician. Maybe that's changing now that everyone has Claude or ChatGPT in the mix, but even then an LLM-thought-first project is always obvious. It's imperative to have clarity of thought first when you're engaging with your LLM thought-partner, otherwise the model just amplifies whatever fuzz you walked in with. Anyways.

What if you can pick three

Now the interesting case. There are four ways to be strong in three of the four legs, and I'll walk through each. For each one I care about what they're naturally good at, where they fail, and the structural support that actually helps. "Mentor them" is not structural support. "Pair them with a person who has formal sign-off authority on the thing they're weak on" is.

The Clinical-Science-Product archetype (no engineering)

The product-leaning clinical researcher. Asks the right questions, designs evals that don't lie, knows what the product should do and why it matters to the clinician on the receiving end. Where they struggle is they can't build it themselves, and that gap is bigger than it sounds. They tend to underestimate engineering effort, design things that don't fit how the system is actually built, and ship slowly because every iteration goes through someone else's queue.

How to support: pair them with a strong engineering lead from the very start of any project, not at handoff. Treat their specs as drafts that engineering edits, not as orders. Get them comfortable enough with the codebase that they can read it, even if they can't write it well. The goal isn't to turn them into an engineer, it's to make sure they're designing things that can actually be built without three rounds of "oh, that's not how this works."

The Clinical-Science-Engineering archetype (no product)

The implementer-scientist. Can design the evaluation and also build the pipeline and the tooling around it. Often the most quietly productive person on the team. Risk: builds technically excellent things that aren't well-aimed. They'll happily spend a quarter on a beautifully-engineered system for a problem that wasn't the most valuable problem to solve.

How to support: pair them with a PM who has actual authority over what they work on, not just suggestions. Force a "why this, why now" memo at the start of any project. Get them in front of users early and often, not as researchers but as observers watching how the product fits into a real day. The goal is to make sure their engineering output is pointed at things that matter to the customer, not just things that are intellectually interesting.

The Clinical-Product-Engineering archetype (no science)

The clinical builder who ships. They have medicine, they have product intuition, they can build it themselves or alongside engineers without friction. Real risk: they ship things based on evaluations that don't hold up, or claim performance gains that are within the noise floor. They'll also tend to be the most charismatic people in the room, which means their loose claims travel.

How to support: require a science partner to sign off on any externally-stated claim. Build a culture where "what's the variance on that" is a normal, non-loaded question. Have them work through a real eval design end to end at least once, with a strong methodologist watching, so they internalize where the pitfalls actually are. Once they get it, they get it, and they become the team's best translator between the eval and the roadmap.

The Science-Product-Engineering archetype (no clinical)

The technical builder with product instincts and great methodology, but limited clinical fluency. Often the most technically sharp person on the team, and often the person most prone to building something that solves the wrong problem because they misread the workflow. The trap is they shadow a clinician twice and feel like they get it. They don't, yet.

How to support: pair them with a clinical informant who has actual veto power, not just advisory input. Set up regular shadowing and have them write up what they saw, not what they think it means. Never let them be the sole voice in a room when the question is "is this clinically meaningful." And keep the asymmetry from earlier in mind: this archetype is not going to grow a clinical leg on the job in any deep sense. They might develop pattern recognition for working with clinicians and a sharper sense of when to defer, which is real and useful, but it isn't the same as having clinical training. The clinical partner here isn't a temporary scaffold, it's a permanent fixture of how this archetype operates well.

Which combo matters most if you have to bet

I tend to bet on Clinical + Science as the non-negotiable core, with Product and Engineering as the two legs you can rotate around it. Clinical I've already flagged as a prerequisite, so it's non-negotiable in that structural sense. Science I treat as the second leg I won't ride without, even when there are good Product and Engineering humans in the room. Maybe that's a chip on my shoulder from never finishing a PhD in Computational Biology, or from the fact that my math and stats are objectively worse than a lot of people I know, and I only have a Masters (I'm fine, thanks for asking). But, drumroll please, the work falls apart fastest when either the clinical grounding or the experimental rigor is weak. Product and engineering gaps are painful and slow you down. Clinical and science gaps make you ship things that are wrong.

By clinical expertise I mean a clinical degree (MD / DO / PA / RN / PharmD) and some clinical experience, and I'm honestly not sure how much clinical experience is strictly necessary. It depends on what they're doing. I've seen fresh med school grads who were obviously sharp on clerkships and would do great here. (Probably the gunners who were smarter than the residents, which, fine, they make great employees. Could never have been me as an MS3. I was still wrastlin' and jiujitsuing then. I wasn't about to do the resident's job, I was there to learn, brah.)

The product part I had to be convinced of. My friend who I realize I reference a lot in this blog talked me into it, partly because he was a big product guy himself (and was, ngl, quantitatively smarter than me and a better doctor than me). His argument was simple: we are building products, so the people doing the work need to understand products. I bought it.

The engineering part is the one I've been most precise about lately, mostly because of the computational-experimentalist conflation I mentioned earlier. Shipping is a verb, and a team that can't actually ship doesn't matter no matter how good the science or the clinical grounding is. It's imperative the same way the others are.

The clinical / medicine piece is obvious enough that I'll spare the justification.

A note on the head of the function

I'll repeat this because I think it actually matters: I don't think you can lead Clinical AI well without all four legs, or at least enough exposure to all four that you can ask the right questions and not get rolled. You'll over-index on whichever one you're strongest in, and the rest of the org will calibrate to your blind spot. Clinical-Science lead with no product/engineering chops, the team will under-invest in shipping. Clinical-Product lead with weak science, the methodology will rot. Science-Product-Engineering lead with no clinical, the team will ship clinically tone-deaf things and not even know it. The lead's job is to keep all four legs balanced, and you obviously can't balance a leg you don't have.

Why I want to keep this definition loose

A short aside on why the fuzziness is a feature, not a bug. The cautionary tale I keep in mind is Data Science.

When I was coming up, "data scientist" was the sexiest job title in the world for nerds like me. The original thing it pointed at was something like: a person who knows enough stats and experimental design to actually find a signal, knows enough programming to wrangle the data themselves, applies all of that to a real domain, and is good enough at all three pieces to be dangerous. That was a cool job. That was the job I wanted.

What actually happened to the title is that it got hollowed out. Over a few years "data scientist" came to mean "business intelligence person who makes dashboards," which, no offense to the dashboard people, is hella lame compared to what the title used to mean. The interesting parts of the original role got abstracted out into other titles (ML engineer, research scientist, applied scientist) and the bag of letters that's left is much less interesting than what it originally pointed at.

I want Clinical AI to dodge that fate. The intentionally loose definition is doing real work. It's a deliberately fuzzy set of attributes aimed at an equally fuzzy goal: doing cool shit in applied ML/AI in the clinical domain. The minute it gets pinned down to "the person at a health system who fine-tunes an LLM," or "the doctor who writes prompt evals," or whatever the narrowing-of-the-month is, it's going to lose what makes it useful. So when people ask me to define it more tightly than this, I push back. Keep it loose.

So what are we

Honestly, Clinical AI is still a young enough term that there isn't a stable definition, and after thinking about it some more I think the right move is to stop treating that ambiguity as a problem and start treating it as the actual point. The job isn't that confusing once you stop trying to over-name it: build useful AI things for clinical contexts, evaluate them honestly, ship them at quality, and don't let any of the four legs go slack. Finding the people who can actually do that is hard, and you should probably go thank your recruiter.

Anyways. If you've gotten this far and you're one of the unicorns (or 2-3 parts of the unicorn), my DMs are open.