The Clinician-Coder Manifesto
Why a Manifesto
Manifestos are declarations of intent. They exist to draw a line in the sand -- to say clearly what you believe and why. The clinician-coder movement needs a manifesto because the default trajectory of clinical AI is toward centralized, proprietary, cloud-dependent systems controlled by companies whose primary obligation is to shareholders, not patients. This document outlines five principles that define a different path: one where physicians control the tools, the data stays local, and the source code is open for inspection.
Principle 1: Privacy is Non-Negotiable
Patient privacy is not a feature to be weighed against convenience. It is a prerequisite. Every clinical AI system should be designed with the assumption that patient data is the most sensitive data it will ever handle. This means local processing by default, encryption at rest, and zero external network access for inference. If a tool cannot operate without sending patient data to a third party, that tool is architecturally flawed -- regardless of how good its model performance is.
Principle 2: Physicians Must Build
The most effective clinical software is built by people who understand clinical workflows from the inside. This does not mean every physician needs to become a software engineer. It means that physicians must be actively involved in the design, specification, and testing of the tools they use. Vibe coding and AI-assisted development make this more feasible than ever. The clinician who can describe a workflow precisely enough for an AI assistant to implement it is a clinician-coder -- and that role is becoming essential.
Principle 3: Open Source is the Standard
Clinical AI tools that affect patient care should be inspectable. Open-source licensing ensures that any physician, researcher, or regulator can examine the code, verify the model behavior, and identify potential issues. Proprietary black-box AI in clinical settings is not just a philosophical problem -- it is a safety problem. When a model produces an unexpected result, the clinician needs to be able to understand why. Open source makes that possible. Proprietary systems make it a matter of trust in a vendor's documentation.
Principle 4: Vendor Independence
A clinical practice should never be dependent on a single vendor for its AI capabilities. Vendor lock-in creates operational risk, limits negotiating power, and constrains future options. The clinician-coder principle of vendor independence means building on open standards -- Docker for deployment, standard APIs for integration, portable data formats for storage. If your AI vendor disappears tomorrow, your clinical workflow should continue operating with minimal disruption.
Principle 5: Evidence-Based Development
Clinical AI development should follow the same evidence-based methodology that governs clinical practice. This means validating models against known datasets before clinical deployment, measuring real-world performance against defined benchmarks, documenting failure modes, and publishing results -- positive and negative -- for peer review. The fast-move-and-break-things ethos of Silicon Valley has no place in clinical software. We validate first, deploy second, and measure continuously.
A Call to Action
This manifesto is not a finished document -- it is a starting point. The clinician-coder movement is young, and the principles will evolve as the technology matures and the community grows. What matters now is that physicians who believe in these principles start building, start sharing, and start demanding better from the clinical AI ecosystem. The tools to build physician-controlled AI exist today. The open-source models are available. Docker is free. The only missing ingredient is the clinician willing to take the first step.