Vibe Coding for Physicians: From Small Idea to Live Clinical Tool

The most important thing about vibe coding is not that the AI writes code.

The important thing is that it lets physicians build the small tools nobody else is ever going to build for us.

Not the enterprise EHR. Not a regulated medical device. Not a patient-facing system handling protected health information. I mean the practical tools that sit in the gap between "this is annoying" and "this is never going to get funded."

A taper instruction generator. A clinic handout builder. A tumor board checklist. A research screening dashboard. A call schedule helper. A patient education page. A calculator. A form that turns a messy workflow into a clean output.

That is the sweet spot.

I want physicians to build things. Not because every physician needs to become a software engineer, but because every physician knows a dozen workflow problems that are too specific, too local, or too small for anyone else to solve.

This is the practical version of the earlier vibe coding overview. I am going to walk through the actual mental model: small idea, dictated spec, PRD, coding agent, design steering, GitHub, Vercel, live version.

The example is DexTaper, a small web tool for generating dexamethasone taper instructions.

Start With a Small Annoyance

Do not start with "I want to build an app."

Start with a sentence you have said in clinic:

"I keep writing the same dexamethasone taper instructions over and over, and it is easy for the dose schedule to become confusing."

That is a good vibe-coding problem. It is bounded. It has a clear user. It has a concrete output. It does not need EHR integration to be useful. It can be built as a standalone web app. It can be reviewed by a clinician before use.

DexTaper is basically this:

• choose a taper protocol
• enter patient-facing details
• select pill strength
• edit taper steps
• generate readable instructions

The public version shows protocol presets such as brain metastases, high-grade glioma, post-op or mild symptoms, and spine metastases. It has fields for patient name, start date, indication, pill strength, provider name, and contact phone. Then it turns taper steps into patient instructions.

That is exactly the kind of tool physicians should learn to build.

Not because DexTaper is complicated. Because it is not complicated. That is the point.

The First Dictation

My workflow usually starts with voice. I dictate the idea into a coding agent or into a notes app, then clean it into a product requirements document.

The first dictation is allowed to be messy:

I want to build a simple web app called DexTaper. It should help a doctor generate patient-friendly dexamethasone taper instructions. It should have preset taper protocols for common scenarios, but the physician should be able to edit every step. The output should be clear enough for a patient to follow. It should not store patient data. It should not connect to the EHR. It should be a standalone tool. I want it to look clean, professional, and calm, not like a startup landing page.

That is not a complete spec. It is a starting point.

The mistake is to send that to a coding agent and say "build it." You might get something functional, but you will also get hidden assumptions. The better move is to ask the agent to turn the dictation into a PRD first.

Turn this dictated idea into a concise PRD for a single-page web app. Ask clarifying questions only if something blocks implementation. Separate required features, nice-to-have features, safety constraints, and design direction.

Now the coding agent is not just writing code. It is helping you think.

Write the PRD Before the Code

A PRD is just a product requirements document. Do not let the acronym make it sound corporate. It is a structured explanation of what the thing should do.

For a physician-built tool, the PRD is the most important artifact. It keeps you from accidentally asking the AI to build five apps at once.

Here is a usable DexTaper-style PRD.

# DexTaper PRD

## Goal
Build a single-page web app that helps clinicians generate patient-friendly dexamethasone taper instructions.

## Intended User
Physicians, advanced practice providers, nurses, or clinic staff preparing steroid taper instructions for clinician review.

## Non-Goals
- Do not diagnose.
- Do not recommend whether a patient should receive steroids.
- Do not store patient data.
- Do not connect to the EHR.
- Do not send instructions directly to patients.
- Do not replace clinician judgment.

## Core Workflow
1. Clinician selects a preset taper protocol or chooses Custom.
2. Clinician enters optional patient-facing details:
   - patient name
   - start date
   - indication
   - pill strength
   - provider name
   - contact phone
3. App displays editable taper steps.
4. Clinician can add, delete, or edit steps.
5. App generates patient-friendly instructions.
6. Clinician reviews and copies/prints the output.

## Taper Step Data Model
Each taper step should include:
- dose in mg
- frequency
- number of days
- calculated tablet count per dose based on pill strength

## Preset Protocols
Include examples:
- Brain metastases - standard
- Brain metastases - rapid
- High-grade glioma during radiation
- Post-operative or mild symptoms
- Spine metastases - standard
- Custom

## Safety Requirements
- Show a disclaimer that instructions require clinician review.
- Do not imply the taper is medically appropriate for every patient.
- Warn patients to contact their care team for worsening symptoms.
- Keep all data in the browser session only unless explicitly changed later.

## Design Direction
Clean clinical interface. Calm typography. Clear sections. Mobile-responsive. No decorative hero section. The main screen should be the tool.

## Deployment
Deploy as a static web app on Vercel connected to GitHub.

Notice what this does. It defines the app and the edges of the app. That matters.

For medical tools, non-goals are not optional. They are safety equipment.

Give the Coding Agent the PRD

Once the PRD is clear, I hand it to a coding agent like Codex, Claude Code, or Cursor.

The prompt is direct.

This prompt does three things.

First, it tells the agent what to build. Second, it tells the agent what not to build. Third, it requires the agent to report its assumptions back to you.

That last part is important. Coding agents are fast, but they are also confident. Make them explain what they did.

Build the First Version Fast

The first version should not be perfect. It should be inspectable.

For DexTaper, the first version might include:

• a dropdown for taper protocol
• a start date field
• a pill strength selector
• a table of taper steps
• generated plain-language instructions
• a print or copy button

That is enough.

Do not spend the first hour debating the color palette. Do not add login. Do not add a database. Do not add PDF export. Do not add twelve steroid protocols. Build the smallest thing that proves the workflow.

This is the rhythm:

The live URL changes the whole process. Once you can open the tool on your phone, you stop imagining the app and start reviewing it like a user.

Steering the Design Journey

Physicians are better at product design than they think. We spend all day detecting confusing workflows.

You do not need to say "increase vertical rhythm and reduce border contrast." You can say:

This feels too much like a generic startup page. Make it feel more like a clinic utility. The tool should be first on the page. Remove any marketing hero. Make the taper steps easy to scan. The generated instructions should be the visual focus after the form.

Or:

This output is too dense for a patient. Rewrite the generated instruction section so each date range is separated clearly. Use plain language. Add a short warning line at the bottom telling the patient to contact the care team if symptoms worsen or if they are unsure what to take.

Or:

The physician needs to see the math. Next to each taper step, show how many tablets per dose based on the selected pill strength. If the tablet count is not a clean fraction, show a warning that the pill strength may not be practical for that step.

That is design steering. You are translating clinical reality into product behavior.

The agent can handle implementation. You decide whether the output makes clinical sense.

The GitHub and Vercel Path

Once the app works locally, you need it online.

The basic path is:

local project -> GitHub repository -> Vercel project -> live URL

You can ask the coding agent to do most of this.

Prepare this project for deployment on Vercel.

Tasks:
- make sure the app builds successfully
- add a clear README
- add any required package scripts
- initialize git if needed
- create an initial commit
- tell me the exact steps to push this to GitHub
- tell me the exact steps to import the repo into Vercel

If the agent has terminal and GitHub access, it can often create the branch, commit, push, and open the repo. If not, it can still give you the commands.

The commands usually look like this:

npm run build
git status
git add .
git commit -m "initial DexTaper prototype"
git remote add origin https://github.com/YOUR-USERNAME/dextaper.git
git push -u origin main

Then in Vercel:

1. Import the GitHub repository.
2. Keep the default framework settings if it is a standard React or Next.js app.
3. Click deploy.
4. Open the production URL on your phone.
5. Test the actual workflow.

That is how a small idea becomes a live version.

This is also why GitHub matters. It is not just where code lives. It is your version history. Every change becomes reversible. Every deployment has a commit behind it. If the app breaks, you can go back.

What to Review Before Sharing

For a physician-built tool, "it runs" is not enough.

Before you send the link to anyone, review:

• Does the output make clinical sense?
• Are the defaults safe?
• Are the assumptions visible?
• Is the disclaimer clear?
• Does the app avoid storing PHI?
• Is every generated instruction editable or reviewable?
• Does the mobile layout work?
• Does the print layout work?
• Can a colleague understand it without you explaining it?

For DexTaper specifically, I would check:

• Are all taper presets clinically reasonable?
• Are tablet-count calculations correct?
• Are date ranges correct?
• What happens with awkward pill strengths?
• What happens if the start date is missing?
• Does the output make clear that the care team should be contacted for worsening symptoms?

This is where physician judgment matters. The AI can write a date calculation. It cannot decide whether your taper defaults are clinically appropriate.

If the tool touches real patient care, slow down. Keep it clinician-facing. Keep it review-only. Do not store PHI unless the security architecture has been properly reviewed. For more on this mindset, see AI safety for clinicians.

The Best First Projects for Physicians

Pick projects that are useful but not dangerous.

Good first projects:

• patient education handout generator
• clinic checklist
• conference abstract tracker
• journal club dashboard
• call schedule helper
• research screening log with no PHI
• medication instruction formatter for clinician review
• lecture slide outline builder
• study guide generator

Bad first projects:

• autonomous diagnosis
• treatment recommendation engine
• anything that stores PHI
• anything that sends messages directly to patients
• EHR-integrated workflow
• billing or coding automation without review
• critical on-call infrastructure

This is not about being timid. It is about choosing the right first hill.

The goal is to build skill and confidence on tools where the failure mode is manageable. Once you understand the workflow, you can decide when to bring in professional developers, compliance, security review, or institutional IT.

How to Think Like a Physician Builder

The core skill is not coding. It is specification.

A good physician-builder can answer:

• Who is the user?
• What problem are they trying to solve?
• What information do they enter?
• What output do they need?
• What decisions should the tool not make?
• What should be editable?
• What should be printed, copied, or saved?
• What could go wrong?
• What must be reviewed by a human?

That is context engineering applied to software. You are designing the context in which the coding agent works.

The better your context, the better the app.

The worse your context, the more the agent invents.

The Real Point

I want more physicians building small tools.

Not because every tool should become a company. Most should not. Not because every prototype should be deployed across a hospital. Definitely not.

I want physicians building because building changes how you think. You stop seeing clinical workflow problems as fixed facts of life. You start seeing them as design problems.

DexTaper is not interesting because it is technically complex. It is interesting because it shows the path.

Small annoyance. Dictated idea. PRD. Coding agent. Design steering. GitHub. Vercel. Live tool.

That loop used to require a developer, a budget, and a project timeline. Now a physician can do the first version alone.

That does not remove the need for software engineers. It changes when you need them. Instead of asking a developer to interpret a vague idea, you can bring a working prototype and say: "This solves the problem. Help me make it robust."

That is a better conversation.

So pick one small problem. Write the PRD. Give it to a coding agent. Push something live.

You do not need permission to prototype.

You need judgment, curiosity, and a clear sense of what should not happen.

That is enough to start.

Example reference: DexTaper, a small dexamethasone taper instruction tool used here as a running example for physician-led prototyping.