Short answer: Vibe coding means describing the software you want in plain English and letting an AI write the code, which you never read. For physicians, that turns a decade-old idea (the risk calculator, the sign-out tracker, the handout page) into a working app in about 30 minutes on a free tier. The four practical platforms are Lovable, Base44, Replit, and VS Code with Claude Code. The one non-negotiable rule: no patient data, ever.
This article is the written companion to session four of my AI webinar series for clinicians. It covers what vibe coding actually is, the five words of software vocabulary you need, a side-by-side comparison of the four builders, how to phrase a request so you get a usable app, and the safety rules that keep an enthusiastic Saturday project from becoming a privacy incident.
What is vibe coding, and why should a physician care?
Vibe coding is building software by describing what you want in conversational language while an AI writes the code you never read. You judge the running app, not the source code, the same way you judge a draft note before signing it rather than auditing the keystrokes that produced it.
The term was coined by AI researcher Andrej Karpathy in February 2025 with the line that "the hottest new programming language is English." It stopped being a niche phrase quickly: Collins Dictionary named "vibe coding" its Word of the Year for 2025, ahead of every other technology term on its shortlist (CNN coverage here).
The reason this matters clinically is not that physicians should become software engineers. It is that the loop is one you already run every day. Think of the attending and resident relationship. You do not write the orders yourself. You describe what you want, review what comes back, and correct it. In vibe coding, the AI is the resident who writes the code:
- You describe: "An app where the user enters age, weight, sex, and creatinine, and gets a colour-coded creatinine clearance."
- The AI writes the code. You never open it.
- You try the app. Click around. Judge it the way a patient would.
- You correct it: "Bigger button. Add a print option. The units are wrong."
If you attended sessions one through three of this series, you have already run this exact loop three times. In session three the output was a letter or a reusable skill. Here the output is an application with a web address you can text to a colleague.
Why doesn't the tool your clinic needs already exist?
Because the path from idea to software has historically been so long that most clinical ideas die on the way. Every clinic runs on duct tape: the risk score re-derived on paper each week, the equipment sign-out "system" that is a binder by the door, the call rota that lives in one person's head, and the spreadsheet that has slowly become a load-bearing monster.
The old sequence was: have the idea, ask IT or price commercial software, wait months for a budget cycle, receive something that fits about 80 percent of the need, give up and build a spreadsheet instead, and watch the spreadsheet grow tentacles. The idea quietly dies.
The reason this is worth solving is that the administrative layer is where clinician time actually goes. In the landmark time and motion study by Sinsky and colleagues, published in Annals of Internal Medicine, physicians spent 49.2 percent of the office day on electronic health record and desk work versus 27.0 percent on direct clinical face time with patients, plus one to two additional hours of data entry at home each night. The American Medical Association has separately reported that family physicians spend 86 minutes of "pajama time" in the EHR after hours every night.
Small tools do not fix that alone. But most of the friction in a clinic day is not clinical reasoning, it is coordination, lookup, and re-derivation. Those are exactly the problems a 30-minute app solves, and they are exactly the problems no vendor will ever build for your specific clinic.
What are the five parts of an app, in clinic language?
You need five words of vocabulary, and no more. Every builder in this article assembles all five parts for you. Your only job is to recognize the terms when they scroll past in a build log so you do not panic.
| Software term | What it does | The clinic equivalent |
|---|---|---|
| Frontend | The screens: buttons, forms, colours, everything the user sees and touches. | The waiting room and reception desk. |
| Backend | The logic doing the real work out of sight: calculations, rules, decisions. | The back office and the lab. |
| Database | Where information is stored, found, and updated. | The medical records room. |
| API | How one system asks another for something in an agreed format. | The referral fax line between two clinics. |
| Hosting | The computer your app lives on, with an address people can visit. | The building and its street address. |
That is the entire vocabulary. When a builder tells you "I have connected the backend," you now know which room it is talking about.
And what is a framework?
Nobody builds a clinic from raw lumber. You start from a pre-approved floor plan and a parts catalogue: standard doors, standard plumbing, standard exam rooms. A framework is exactly that for software, a set of ready-made buttons, forms, menus, and login screens that the AI assembles rather than inventing from scratch.
You will see names scroll past in the build log: React for screens and buttons, Next.js for full websites, Tailwind for the styling, Node for backend logic, Supabase for the database and logins, Swift or Flutter for phone apps. The AI picks the framework. You will never choose one, and you never need to learn one. It is also why first-draft apps look a bit generic: same parts bin. That is fine for a version one.
Lovable vs Base44 vs Replit vs VS Code: which builder should you use?
All four run the same describe, look, correct loop. They differ on a single axis: how much the platform decides for you versus how much you steer. Learn the loop once and it transfers across all of them.
Lovable: the design studio
Lovable is like briefing a design agency that shows you the finished website while you are still talking. You chat on the left and the app takes shape live on the right. It produces the best-looking results of the four, which makes it the right pick for anything a patient or colleague will actually look at. The code stays hidden by default, though you can peek. If your app needs accounts or stored data, Lovable wires in Supabase for you. One Publish button puts it on a live link.
Best first build: a calculator, a clinic landing page, or a printable patient handout.
Base44: the turnkey builder
Base44 is a turnkey clinic. Walk in and the plumbing, the filing room, and the front desk are already installed. Database, user logins, and email notifications are built in with nothing to wire up, which makes it the strongest choice for internal team tools. Staff log in with their work email and you invite them the way you would share a Google Doc. It is also not a garage startup that will vanish with your app: Wix acquired Base44 for roughly 80 million dollars in cash in June 2025, six months after it launched.
Best first build: an equipment sign-out tracker, a call rota, or a small internal registry.
Replit: the full workshop
Replit is a full workshop in a browser tab, and the workshop is also the hospital where the app lives afterward. Editor, AI agent, database, and hosting sit in one place. The Replit Agent shows you its plan before it builds, then works through it step by step while you watch. The code is right there if you want to peek, learn, or hand-edit later. Pricing is credit-based per unit of build effort, so watch the meter.
Best first build: a tool that has to be live on the internet today, such as a searchable journal club library.
VS Code with Claude Code: the pro's bench
VS Code is Microsoft's free code editor and the industry standard. Add Claude Code or GitHub Copilot and an AI agent edits files directly inside your editor. Everything lives on your own computer, so there is no platform lock-in, and there is no ceiling on what you can build. It also has the steepest learning curve of the four.
Full disclosure on where this ends up: every slide deck in this webinar series, including the one for this session, was built in VS Code with Claude Code. Vibe coded, physician made.
The cheat sheet
| Dimension | Lovable | Base44 | Replit | VS Code + AI |
|---|---|---|---|---|
| Feels like | A design studio | A turnkey app builder | A full workshop | A pro's workbench |
| You write | Chat messages | Chat messages | Chat, code optional | Chat plus code, in your editor |
| Code visible | Hidden, can peek | Hidden | Front and centre | It is all code |
| Accounts and data | Add-on via Supabase | Built in | Built in | You wire it, AI helps |
| Goes live via | One-click Publish | Share a link, invite users | Deploy button | Your choice, AI helps |
| Cost to start | Free daily credits | Free tier | Free credits, then pay as you go | Editor free, AI plan extra |
| Best first build | A calculator or clinic page | A tracker your staff logs into | A tool that must go live today | Anything, after the curve |
How do you actually ask an AI for an app?
The skill inside vibe coding is not technical. It is the same clear handover you already give a locum. Five rules cover almost everything.
- Lead with the job, not the technology. Say "a calculator that takes age, sex, and creatinine and colour-codes the result," never "a React app with a Node backend." The framework is the AI's problem, not yours.
- Describe the screen you imagine. What is on it, top to bottom? What happens when the user clicks the button? If you can describe it to a colleague covering your clinic, you can describe it to a builder.
- One feature at a time. Get the skeleton working first, then add. Ten small requests beat one giant paragraph. Titrate, do not bolus.
- When it breaks, describe what you saw. "The button does nothing" is a perfectly good bug report. Paste the error message if there is one. The AI fixes its own mistakes surprisingly well.
- Ask it to explain itself. "Explain what you built as though I am not a programmer." Free education, and the fastest way to catch something you did not ask for.
Notice that this is the same briefing skill from earlier in the series, pointed at a new target. Vibe coding is roughly 90 percent clear clinical handover, and you have been training that for years.
Is AI-generated code actually safe to use?
Not by default, and this is the section most enthusiastic write-ups skip. Two findings should shape how you treat anything you vibe code.
Security. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that 45 percent of AI-generated code introduced an OWASP Top 10 vulnerability. Cross-site scripting failed 86 percent of the time and log injection 88 percent. Java was worst at 72 percent. Critically, the report concluded that increasing model size did not improve security, so this is a systemic issue rather than something the next model release fixes.
Productivity. Even the speed benefit is less certain than the marketing suggests. In a randomized controlled trial published by METR in July 2025, 16 experienced open-source developers completing 246 real tasks were 19 percent slower when allowed to use AI tools, while believing afterward that AI had made them 20 percent faster. The gap between felt speed and measured speed was the study's central finding.
Read together, those two results do not say "do not vibe code." They say something more specific and more useful: vibe coding is excellent at producing a working first version of something small, and unreliable as a substitute for engineering judgment on anything that matters. That maps cleanly onto the rules below.
What are the safety rules for a physician-built app?
Five rules. They are not optional, and they are the reason this session is deliberately limited to administrative and educational tools.
1. No PHI, anywhere
No protected health information in the builder, in the app, or in your test data. These platforms are not HIPAA or PIPEDA covered by default, and consumer tiers generally do not come with a Business Associate Agreement. Under the US HIPAA Privacy Rule, a vendor that handles PHI on your behalf must be under a Business Associate Agreement. In Canada, commercial handling of personal information falls under PIPEDA plus provincial health privacy legislation. Build and demonstrate with fabricated patients only.
2. A prototype is not a medical device
The moment an app is intended to inform or drive a care decision, it may fall under clinical decision support regulation. The FDA's Clinical Decision Support Software guidance sets out which software functions are regulated as devices and which are not. Building for administration and education first keeps you clearly on the safe side of that line, and that is where the fastest wins live anyway.
3. If it collects data, know where the data lives
Even a humble signup form stores information on someone's server, in some country, under some jurisdiction's law. Think twice before your app collects anything real, including staff names and email addresses.
4. You verify before you share
AI-built is not correct by default. Check a calculator's formula against the primary source, twice, with known input values where you already know the answer. Your name is on the link you send to a colleague.
5. Watch the meter
These platforms sell credits, and an enthusiastic Saturday can spend real money. Start on free tiers, set spending limits where the platform offers them, and treat "one more feature" the way you would treat "one more scroll."
What should you build first? Four starter projects
All four of these are administrative or educational with zero PHI. That is not a limitation, it is where the quickest wins live.
| Build | Platform and time | The prompt to paste |
|---|---|---|
| Your risk-score calculator The score you use weekly, with your own interpretation notes under the result instead of a generic app's. |
Lovable, about 20 minutes | "A single-page CHA2DS2-VASc calculator: inputs as toggles, result colour-coded, my interpretation notes below." |
| The patient handout page Printable, plain language, your clinic's phone number in the footer. Text the link or print it at the desk. |
Lovable, about 20 minutes | "A printable page titled 'Starting letrozole: what to expect.' Grade 6 reading level, our clinic number in the footer, big print button." |
| The equipment sign-out tracker Staff log in with email and check items out and in. The binder finally retires. |
Base44, about 30 minutes | "A sign-out tracker for clinic equipment. Staff log in with their email; show me who has what, and since when." |
| The journal club library Upload your one-page trial summaries; residents browse by tumour group and search by drug. |
Replit, about 30 minutes | "A site where I upload one-page trial summaries; visitors browse by category and search by drug name." |
Two of those consume artifacts you may already have. If you built a summarizing skill in session three, the journal club library is where its output goes to live.
A 30-minute plan for tonight
- Pick one build. One of the four above or your own, administrative or educational only, zero PHI.
- Build version one with a 30-minute cap. Lovable or Base44, free tier. Stop when the skeleton works. Version one is supposed to be ugly.
- Make three corrections. The loop is the lesson: describe, look, correct, three times. "Bigger button. Add a field. Fix the wording."
- Publish it and send the link to one colleague. Bonus: run the same prompt in a second builder and compare the two results.
Frequently asked questions
Vibe coding is building software by describing what you want in plain English and letting an AI write the code, which you never read. You judge the working result instead of the source code. The term was coined by AI researcher Andrej Karpathy in February 2025 and was named Collins Dictionary's Word of the Year for 2025.
Yes. Platforms like Lovable and Base44 build a working first version from a single plain-English description, usually in under 30 minutes on a free tier. You need no programming knowledge, but you do need to verify the output, because AI-written code is not correct by default.
No. These platforms are not HIPAA or PIPEDA covered by default and most do not sign a Business Associate Agreement on consumer tiers. Build and demonstrate with fabricated test patients only. If you want a tool that touches real patient data, involve your institution's IT and privacy office before you build.
Start with Lovable for anything patient-facing or visual, such as a calculator or a handout page. Start with Base44 for internal team tools that need staff logins and stored data, such as a rota or an equipment sign-out tracker. Both have free tiers, and the describe, look, correct loop is identical across every platform.
Often not. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 coding tasks and found that 45 percent of AI-generated code introduced an OWASP Top 10 vulnerability, with cross-site scripting failing 86 percent of the time. Treat a vibe-coded app as a prototype until someone qualified reviews it.
It can. Once software is intended to inform or drive a care decision, it may fall under clinical decision support regulation. The FDA's Clinical Decision Support Software guidance sets out which functions are regulated. Building for administration and education first keeps you clearly outside that boundary while you learn.
The bottom line
The goal here is not an app-store hit. It is the moment you realize that "software person" now includes you, and that every duct-tape spreadsheet in your clinic is officially on notice.
Pick one small administrative annoyance. Describe it clearly. Look at what comes back. Correct it three times. Cap it at 30 minutes, use fake data, and send the link to one colleague. That is the whole method, and it is the same method whether you are using the simplest builder or the most powerful one.