The Self-Taught Trap: Why Learning Python Won't Save the Modern Doctor
Anxious young doctors spend their weekends learning to code, sure it is how they survive the AI wave. A rational reaction to a failing curriculum, and the wrong problem. The skill that matters is not building the tool but knowing when it lies to you.

Dr. Sven Jungmann
CEO

On a Sunday morning a resident I know sits at her kitchen table, still half in scrubs from a Saturday shift, working through the third lesson of an online Python course. The pharmacology reference she actually needs for Monday lies unopened beside the laptop. She is not lazy or confused; she is frightened. She has watched predictive models and language systems arrive on the wards while her own training said almost nothing about them, and she has concluded, reasonably, that she must teach herself to code or be left behind.
She is half right. Medical education in Europe has been slow to absorb what is already changing clinical practice, and that gap is real. But the remedy she has chosen is the wrong one. She is learning the syntax of the machine when what she needs is the safety of the tool.
The misallocation of anxiety
The fear underneath all of this is the fear of becoming obsolete. It is worth being honest about the economics, because they do not point where the anxiety assumes. A clinician who writes mediocre code is not an asset. There is a deep and cheap supply of professional engineers who will write better software, faster, than a doctor learning on weekends ever will.
The physician's advantage was never construction. It is context. The danger in front of us is not that a doctor cannot assemble a neural network. It is that a doctor cannot tell when the network is wrong.
“Technological literacy in medicine is not knowing how to write the code. It is knowing where the code is likely to fail.”
Treat the model like a drug
There is a better frame for this energy, and it is already familiar to every clinician. Stop treating artificial intelligence as a computer-science problem and start treating it as a pharmacological one.
We prescribe propofol and lithium every day without the faintest idea how to synthesise either compound in a laboratory. We use them safely because we have memorised something else entirely: their indications, their contraindications, their adverse effects, and the situations in which a reasonable dose becomes a dangerous one. That is the literacy a doctor actually needs in front of a model. What was this system trained to do? And, more importantly, where does it fail?
The failure modes are concrete and learnable. A model carries the imprint of the population it was trained on, so it degrades quietly when the patient in front of you does not resemble that population. The clinical world it learned from drifts away from it over time, as practice and disease patterns change, and its confidence does not drift with it. Some of its failures are not even visible: a measurement that reads less accurately on darker skin, a label that meant something subtly different in the dataset than it does on your ward. None of this requires you to write a line of code. All of it requires you to read the model the way you read a drug.
Put plainly: if you can build a model but cannot name its failure modes, you are dangerous. If you can name the failure modes but cannot build the model, you are exactly what the ward needs.
Map the boundary, not the box
Because the universities have been slow, you will have to be your own teacher for a while. Spend that scarce attention well. The point of opening the black box is not to understand the wiring inside it; you will never out-engineer the engineers, and you do not need to. The point is to find the edge of the box — the boundary beyond which its competence ends and your judgement has to take over.
So when a junior colleague asks whether they should learn to code, the honest answer is usually no. The answer is: learn to audit. Treat a software prediction with the same scepticism you bring to a pharmaceutical sales call. Ask what the number needed to harm would be if you followed it blindly. Ask whether the model has drifted since anyone last checked. Ask whether a given output is a genuine deduction or a confident invention.
We do not need amateur programmers in white coats. We need clinicians who can read the limits of their tools and who know, in the moment that matters, when to overrule them. That skill is older than any algorithm, and it is still the one the patient is counting on.


