“Tools will come and tools will go. Only the vibe coder remains.” Rick Rubin said it about software. The producer’s value was never the instrument. It was knowing what good sounds like and steering toward it. For a clinician, that ear is clinical judgment, and judgment is the one thing the machine cannot supply.

Rubin made that line go viral, then turned it into a short book that reimagined the three-thousand-year-old Tao Te Ching for the age of code.¹ Underneath the joke is a serious claim. The tool in front of you keeps changing. The taste that directs it does not. That is the part that lasts, and it is the part you already own.

Vibe coding means building software by describing what you want in plain language and letting an AI write the code. Andrej Karpathy named it in February 2025, describing a way of working where you stay focused on the outcome and let the model handle the code itself.² You do not memorize syntax. You see something, say something, run it, fix it. Within a single year the practice spread far enough that Collins Dictionary made it the Word of the Year for 2025³, and technology leaders started saying the new programming language is human.⁵ The name itself is still being argued over. Because “vibe coding” sounds casual, some practitioners prefer “agentic engineering” for the disciplined, professional version, where you set the goal and the guardrails and an AI agent does the building. Whatever you call it, the habit underneath is the same: you direct, the machine executes, and you stay responsible for the result.

A generation ago, a single misplaced character could halt an entire program and take an experienced engineer to find. That barrier is gone. The skill that matters now is not typing code. It is knowing what the tool should do and judging whether it does it.

For decades the software clinicians use was built by a small number of large vendors. Two of them account for roughly two-thirds of the acute care hospital electronic record market.¹¹ Custom tools were out of reach for most clinicians, who fell back on paper handouts to guide patients between visits.⁹ The limiting factor was never clinical insight. It was the cost of turning insight into working software, and that cost has collapsed. What remains is the ability to define a problem, identify the relevant data, and decide what action should follow. That is what clinicians do every day.

Look at the arithmetic of a chronic condition. You see a patient four times a year for fifteen minutes. That is about one hour of clinical contact across an entire year. For the other thousands of hours, the patient manages the condition alone, with paper and memory. Patients are already filling that gap with whatever is nearest. More than 230 million people ask health and wellness questions on one AI platform every week, usually with no clinical framing and no one checking the answer.⁶ A tool you build puts your judgment into that gap, with your thresholds and your cautions, instead of leaving it to a general chatbot.

You write an order: ceftriaxone one gram intravenously, once daily. You do not synthesize the drug or place the line. You supply the intent and the parameters, and the nurse and the pharmacist carry it out. AI coding tools are the same kind of help. You bring the clinical intent. They handle the execution. The better you state the intent, the better the result, which is the whole subject of the next module.

I have built more than 100 clinical tools this way, all by directing AI rather than writing code by hand. None of it required learning a programming language. If I can do it, the resident who grew up with a phone in her hand certainly can.

Software used to move through a team. Someone defined what to build and why. Someone designed how it should feel. Developers wrote it. Testers decided whether it worked. Each role brought a different kind of judgment, which is powerful, but every change waited on a handoff, which is slow.¹⁰ Vibe coding compresses that loop. You move through more of it yourself: define the goal, generate a first version, test it, give feedback, improve it.

Your role is closest to the product lead. You bring the goal, the audience, the taste, the constraints, the feedback, and the decision about what ships. The machine turns ideas into working software, makes changes, explains its behavior, and debugs. The better you lead, the better it builds.¹⁰

One principle sets direction. The next four repeat as a loop until the tool is good enough.

1. Start with the goal. Describe the outcome before the task. Who is this for, what should they be able to do, what would make it useful. Not “build a calculator,” but “help a patient with high blood pressure know when a home reading should prompt a call to the office.” You do not need to know the technical steps. Start with what should be true when it works.
2. Build in small slices. A slice is a piece small enough to try. Ask for the whole product at once and you cannot review it. Ask for one screen and you can open it, click through it, and decide what to add next.
3. Manage context. Context is the information the model uses to understand you: who it is for, what to include now, what to leave alone. Stay in one conversation while you build one feature. When the conversation gets noisy or you switch features, start fresh with a short summary of what matters.¹⁰
4. Review and test. The machine can build, but you decide whether it works. Open the tool and use it as the patient would. Did anything that should have stayed the same break.
5. Improve with feedback. The first version is a draft. Tell the machine what to keep, what to change, and what to leave untouched. When a change goes too far, narrow the scope and restore what worked.

Communicate clearly. Clinicians are trained to be brief. We compress thousands of data points into a one-line note. The machine cannot read that compression, and it cannot read your intuition. State plainly what you want and why. “Make it better” tells the machine nothing. Compare a real instruction:

Think in systems. Ask how each part connects, the way you map a disease from cause to presentation to plan. Systems thinking keeps a tool lean. It tells you when a simple dropdown menu beats a language model. If a field has five fixed options, a dropdown is faster, cheaper, and more reliable than asking a model to interpret free text every time. The goal is utility, not cleverness.

Iterate. The first answer is rarely the final one. When the machine gets it wrong, push back. Ask the second and the third question. Refining the prompt is also how you learn to speak the language of the machine, and that skill compounds across every later tool.

The product names will change. The categories are stable, so learn the categories. The art is choosing the simplest tool that does the job.

The chat models are your scratch pad. Low stakes. Open one, describe an idea, see if the logic holds, start fresh if it does not. ChatGPT is a reliable generalist. Claude tends to reason through a clinical pathway carefully before it writes anything. Gemini handles very large inputs well, which helps when you paste an entire guideline. Use them to brainstorm and to draft the specification you will hand to a builder.

Claude Code lets you describe what you want in plain English and writes the code for you. You set it up once and then talk to it. Replit is a browser alternative that handles hosting and the database in the background. Google AI Studio offers scale and control, though you host the result elsewhere. The next two modules use Claude Code for a hands-on build; the steps are the same in any of them.

Before you trust a tool’s medical logic, ground it in real evidence. Deep research tools read across many sources, aggregate them, and check facts. NotebookLM answers only from the documents you give it: your protocols, your guidelines, your notes. It stays anchored to your library instead of inventing facts. For a clinical number, grounding is how you keep a fabricated figure out of the tool.

Before you build anything with branching logic, have a strong reasoning model check the plan. Hand it the if-then rules and the thresholds and ask where the logic breaks, what edge cases are missing, and where a value could produce an unsafe output. It is cheaper to fix a flaw in the plan than in the built tool.

Figma and Framer let you sketch the look and feel before you build. Image generators produce diagrams and patient education art, and the better ones place text inside an image correctly, so a labeled diagram comes out labeled. Video tools generate short clips for patient education. All of these connect to the builders.

Learn the rules before you build. Most consumer AI tools are not compliant for protected health information.

A tool that gives a clinical recommendation can be a regulated medical device. The 21st Century Cures Act, as the FDA explains in its 2026 guidance, excludes certain clinical decision support software from the device definition only when it meets four criteria.⁸ In plain terms:

1. It does not analyze a medical image or a signal from a monitor or device.
2. It displays or analyzes medical information about a patient.
3. It supports or offers recommendations to a clinician about prevention, diagnosis, or treatment.
4. It lets the clinician independently review the basis for the recommendation, so the clinician does not rely primarily on the software.

The fourth criterion does the work. A tool that is clinician-facing, transparent, and advisory, where you remain the decision-maker and can see why it said what it said, sits in the safer non-device lane. A tool that is opaque, directive, or built for a patient to rely on without a clinician is far more likely to be regulated as a device. To support independent review, the guidance suggests the tool state its intended use, the patient population, the required inputs, and a plain-language description of how it was developed and validated.⁸

So building a tool is not the same as being allowed to deploy it on patients. The cleanest path is to design the privacy question away. A tool that runs entirely in the browser and stores nothing enters no name, transmits no data, and keeps nothing. Privacy is not a setting you switch on. It is the design.

Take a common problem. A patient with high blood pressure sees you every three or four months. You adjust treatment from a snapshot taken in the office. What happens in between is invisible.⁹ A simple tool can extend your judgment into that gap. Here is the loop on it, with a fictional patient throughout.

1. Define it. The patient enters two home readings a day from an automated monitor. The tool is educational and routes to you. It does not diagnose and it does not change medications.
2. Ground it. Pull the thresholds from the source and confirm them. The 2017 ACC/AHA guideline, reaffirmed in 2025, sets a target under 130/80, and flags a reading at or above 180/120 as markedly elevated.⁷ Every number traces to that guideline.
3. Build it. Hand the builder your specification and your verified numbers, with clear if-then logic. If the seven-day average sits under 130/80, reassure and reinforce diet, activity, and adherence; if readings trend upward over several days, prompt a review and a message to the office; if any single reading reaches 180/120, advise contacting the office or urgent care now.
4. Verify it. Enter test values you already know: a normal week, a creeping trend, a single severe reading. Confirm the tool shows its reasoning, cites the source, and never diagnoses or adjusts a dose.
5. Refine it. Raise the contrast and the button size for older eyes. Translate the output into language a patient can read.
6. Ship it. Publish it, or run it locally when privacy demands.

Pre-procedure preparation. Procedures get delayed when patients misunderstand instructions about fasting, which medications to hold, and which labs to complete.⁹ Build an interactive guide that walks a patient through the steps for their specific procedure and lets them ask clarifying questions.

Post-operative check-in. After surgery, patients get a printout of warning signs and often hesitate to call.⁹ Build a tool where the patient answers a few standardized questions each day, and the tool routes a normal pattern to reassurance and a concerning pattern to a prompt to contact the surgical team, on criteria you set.

That is the loop. The next two modules put it into your hands: you set up the workshop, then build and publish a real tool.

The thing that makes a clinician safe at this is the same thing that makes it dangerous in untrained hands: judgment about what the numbers mean. A layperson who builds a risk tool does not know the threshold is wrong. You do. Lowering the barrier to building also lowers the barrier to deploying unsafe logic without oversight, so the discipline matters more, not less. Hold yourself to four rules.

1. Every number traces to a published source. No invented thresholds, no remembered figures. The failure mode is a model that confidently supplies a plausible but wrong cutoff, which is why you ground the numbers before you build.
2. You check the math by hand before anything goes live. Build a small set of test cases with known answers and run the tool against every one. A normal result, a borderline result, a severe result, a missing value. If any case comes back wrong, the tool is not ready.
3. The tool shows its reasoning. No black box. It displays how it reached its result and cites the evidence on screen. The failure mode is a number with no visible source, which a frightened patient cannot question and you cannot defend.
4. It stores no patient data. A tool that runs in the browser and saves nothing cannot leak what it never held.

Before any tool reaches a patient, confirm: every number traces to a cited source; the test cases pass; the reasoning is visible on screen; nothing is stored; the tool refuses to act outside its scope; and your compliance office has signed off if it will touch protected health information.

None of these are coding decisions. They are medical ones, and only you can make them. The answer to the real risk of unsafe tools is not to avoid building. It is to build with the same evidentiary discipline you bring to everything else in medicine.

The tool you learn today will be replaced within a year or two. Karpathy, who coined the term, already calls vibe coding passe and renames the professional version agentic engineering.⁴ The label keeps changing. The brand of AI keeps changing. The durable skill does not. It is knowing what good looks like and directing the machine toward it. For a clinician, that is simply clinical judgment pointed at a new instrument.

There is a professional stake here too. If clinicians build these tools, the tools carry clinical judgment and answer to the patient. If clinicians sit it out, the future is shaped by vendors and insurers whose incentives are not always the patient’s.⁹ The same low barrier that lets you build also lets others build badly. Leading is the safer path, not the riskier one.

I am not telling you to become a programmer. The opposite. The era of the clinician as the person who memorizes ten thousand facts is ending, because the machine remembers better than any of us. What it cannot do is care for the patient in front of you, or decide what a number should mean for her. That is yours.

Rubin reimagined the Tao for the age of code. I will borrow from a source he would appreciate, Marcus Aurelius: the impediment to action advances action; what stands in the way becomes the way. For clinicians, the tool was never the obstacle. The translation was, the long gap between knowing what a patient needed and getting software that delivered it. That gap is gone. The next three modules close the remaining one, from understanding to doing.

The first seven modules built judgment. The next three put it to work. By the end you will have set up a builder, made a real tool, published it, and learned how to make the second one faster. Start here, with what vibe coding is honestly good for and how to get the tools ready.

Two uses earn their keep. The first is a clickable mockup you hand to a developer or designer so they stop guessing what you meant; they can feel the vision instead of reading a paragraph about it. The second is a small working tool that does one job better than a plain chatbot would, for you, your team, or a few patients, where rough edges are fine because the audience is small. Vibe coding is not a path to riches, and grand promises about it are usually fiction. It is a way to turn an idea into something real, fast.

Claude Code lets you describe what you want in plain English and writes the code for you, so you never touch a line of it. Setup is a one-time job. Check the current steps and pricing in the documentation, since both change.¹⁵

1. Get the app. Install the Claude desktop app and open the Code tab. You will need a paid plan.
2. Make a clean folder. Create one empty folder on your computer, just for this. No passwords, no private files, nothing you would hate to lose, and never any real patient data. Claude only touches this folder.
3. Reduce interruptions, safely. By default Claude asks before each edit, which means many clicks per session. Use Auto mode, a safer middle ground that lets routine edits run while flagging risky actions, rather than turning every check off. Reserve full bypass for an isolated folder, and at a company, ask IT first.¹⁵
4. Connect your plumbing. Add a hosting connector, such as Netlify, so a finished tool can go live with a link. Add a data connector, such as Supabase, only for the day you genuinely need accounts or saved data.
5. Point Claude at your folder, pick the most capable model available (currently Claude Opus 4.8), and you are set.

A builder is the wrong tool for plenty of jobs. A small widget you will glance at once is faster as an Artifact inside a normal Claude chat. A document or a spreadsheet is a job for Claude Cowork. A single image is quicker in a general image tool. Match the tool to the task.

Stop reading and build one. You will make a real creatinine clearance calculator using the Cockcroft-Gault equation. It is the cleanest first build: four inputs, one verified formula, one citation, and it forces every safety habit at once.¹³ Use a fictional patient throughout. Never enter real patient data in a consumer builder.

Open Claude Code and paste an opening prompt that puts you in charge and bakes the safety rules in from the first word.

Enter a case you can check by hand. A 50-year-old man, 80 kg, serum creatinine 1.0 mg per dL. The formula gives 140 minus 50, which is 90, times 80, which is 7200, divided by 72, which is 100 mL per min. The tool should show 100. Switch sex to female and it should show 85. If the numbers do not match, the tool is wrong. Do not move on until they do.

Confirm the formula, the citation, and the limitation note appear on screen, and that nothing is stored. If any is missing, ask for it by name.

Ask for larger inputs, clear mg per dL labels, and a reset button if it lacks one. Then publish through your hosting connector, get a link, and open it on your phone. That link is a working tool you built.

You can build one tool. Now build them well, keep them safe over time, and leave with a kit so the next one is faster.

• Start from a screenshot. Found a layout you like? Screenshot it, drag it in, and say build me this, for my thing. It is the fastest start there is.
• Describe the end result, not the steps. Say what should exist and let the machine pick how.
• Go one piece at a time. One screen, get it right, then the next. Each message is one small job, not twelve at once.
• Run the loop. After each build, write what is wrong as a numbered list in plain words, paste it back, refresh, and look again. Five or six rounds per screen is normal. Stuck on a bug, screenshot it, paste it, and say fix this. That is usually faster than describing it.

The first build often looks generic, because everyone starts the same way. Taste fixes it without touching code. Bring references and be specific: name the font, give the exact colors, ask for more whitespace, and stop saying make it look good. You can also hand the model a design system file, an open format called DESIGN.md that spells out colors, fonts, and spacing. Free libraries such as getdesign.md and designmd.app provide these files for well-known brands; drop one in the folder and tell the model to use it for all styling. For form-heavy tools, asking for a real component library such as shadcn/ui makes buttons and menus look professional, though it uses more tokens.

A builder re-sends the whole conversation and every file it has read, so long sessions add up. Start a fresh chat for each task, point the model at your files instead of pasting big blocks of text, and ask for a plan before any big change so you do not pay for a wrong turn. Watch your usage as you go.

A clinical tool is not done at launch. Date the evidence on screen. When the guideline changes, update the number and the citation, then re-run your test cases. Retire a stale tool rather than leaving a wrong one live.

When a tool will serve many people or hold private data, bring in a real developer. Because everything lives in one folder, the handoff is easy. Ask the model to write a HANDOFF.md that states what the tool does and who for, what works and what is rough, the stack and where the pieces live, what a developer needs to know to take over, and the honest note that this is a prototype built by description, not production code. Then send the folder.

Each is one line. Fill the brackets, paste it after the opening prompt from the last module, and react to what it builds. All assume the clinical defaults: clinician-facing, browser-only, cite sources on screen, store nothing.

• A patient explainer. A plain-language page that explains [condition] at a sixth to eighth grade reading level: what it is, why it matters, and when to call the office.
• A calculator. A calculator for [the score or formula] using [these inputs], showing the formula and its citation on screen, that returns nothing if an input is out of range.
• A pre-visit questionnaire. A short questionnaire that asks a patient [these questions] before a visit and shows a clean one-screen summary. It saves nothing.
• A guideline reader. A tool that reads [a folder of guideline PDFs] and pulls [the thresholds and recommendations I name] into one clean table I can scan. Reference material only, no patient data.
• A reading-level rewriter. A tool where I paste one patient handout and it returns [three] versions at different reading levels, keeping the facts identical, listed so I can copy one.
• A mockup to brief a developer. A clickable mockup of [the feature I keep failing to explain]: the screens and the flow. It does not have to work. When it is done, write a short plain-English spec so I can hand it over.

Tools that need accounts or saved patient data are the exception, not the default. They trigger the privacy rules from Module 4, so reach for them only with compliance handled. Otherwise, no accounts and no storage.

This starter prompt carries the safety rules with it. Copy it, fill the brackets, and your next build begins safe by default.

The second build is faster than the first, because the judgment transfers and the kit comes with you. Pick the next problem you already wish you had a tool for, and build it.