I built my first app on a Tuesday night in the residents' lounge. Not because I'm a programmer — I'm a radiation oncologist — but because I was tired of waiting for IT to maybe, possibly, eventually build the brachytherapy scheduling tool our department needed. Three hours later, I had a working prototype. A week later, people were using it.
That's vibe coding.
Not "no-code." Not "low-code." Vibe coding. You describe what you want, the AI builds it, you iterate until it works. No computer science degree required. No six-month development cycle. Just you, a clear problem, and an AI that can write code faster than you can describe it.
If you're in medicine or research and you've ever thought "someone should build a tool for this," keep reading. Because that someone is you now.
What Vibe Coding Actually Is
The term comes from the coding community, and it's delightfully accurate. You're not writing code from scratch. You're not debugging memory leaks or wrestling with dependency hell. You're describing the vibe of what you want — the look, the feel, the functionality — and AI coding assistants turn that into working software.
It's conversational programming. You talk, it codes. You iterate, it refines. The AI handles syntax, libraries, best practices, and all the technical details that used to require years of training.
Why does this matter now? Three reasons.
First, AI models got good enough in 2024-2025 to write genuinely functional code from natural language descriptions. Not toy examples — real applications with databases, authentication, and deployment pipelines.
Second, the tools matured. Claude Artifacts, Cursor, Windsurf, Replit — they're not experimental anymore. They're production-ready, and people are shipping real products with them daily.
Third, medicine desperately needs custom tools that will never justify a commercial development budget. Your department's specific workflow problem? Your research group's unique data tracking needs? Those aren't venture-backable SaaS products. They're perfect vibe coding projects.
The Tools Landscape
Different tools for different jobs. Here's what actually matters.
My workflow: Start in Claude Artifacts for the prototype. If it works and people want to use it, move to Cursor to build the real thing. Deploy on Vercel or Netlify. Done.
You don't need all these tools. Pick one and learn it deeply. I'd recommend starting with Claude Artifacts — you can have something working in minutes, and it teaches you how to think about structuring your requests.
A Real Walkthrough: Building a Journal Club Tracker
Let me walk you through building something useful from scratch. We'll make a journal club tracker — a tool to manage paper assignments, discussion dates, and presenter schedules. Non-HIPAA, genuinely useful, and representative of what vibe coding excels at.
Identify the Problem Clearly
Don't start coding. Start with the problem. Write down exactly what you need:
"Our journal club happens weekly. Someone presents a paper. We need to track who's presenting when, what paper they're discussing, and who's attended. We email reminders a week before. Right now it's a shared Excel sheet and it's a mess."
That's your spec. Clear, concrete, specific.
Plan the Architecture
Think about what you need:
- A list of upcoming presentations (date, presenter, paper title/link)
- A form to add new presentations
- Attendance tracking
- Email reminders (maybe — this adds complexity)
Start simple. Build the list and form first. Add attendance later. Email reminders can wait — you'll manually copy-paste for now. Don't boil the ocean.
Write Your First Prompt
This is where most people fail. They're too vague. "Build me a journal club app" gets you garbage. Be specific about structure, style, and functionality.
Here's a prompt that works:
Build a single-page web app for tracking journal club presentations.
Requirements:
- Display upcoming presentations in a table (date, presenter name, paper title, paper link)
- Form to add new presentations (fields: date picker, text input for name, text input for title, URL input for link)
- Presentations should be sorted by date, soonest first
- Clean, professional design — think academic department website
- Data should persist (use localStorage for now)
- Delete button for each presentation
- Mobile-responsive
Tech stack: React, modern styling (Tailwind or similar), no backend needed yet.
Make it look professional but not flashy. We're doctors, not designers.
Drop that into Claude Artifacts or Cursor. You'll have a working prototype in under a minute.
The Specificity Sweet Spot
Too vague: "Build a journal club app"
Too detailed: "Use React 18.2.0 with functional components, implement useState for form handling, use Tailwind classes justify-center and items-center..."
Just right: "Build a single-page app with a form and a table. Clean design. Data should persist."
Give the AI room to make technical decisions. Focus your specificity on what you want it to do and how it should look, not how to build it.
Now you iterate. The first version will be 80% right. You'll say "make the table sortable by clicking column headers" or "add a search box to filter by presenter name" or "change the color scheme to match our department branding." Each iteration takes seconds.
After an hour, you have something genuinely useful. Test it with colleagues. Get feedback. Iterate more.
When it's solid, you make a decision: Keep it simple (it's a static page, people can bookmark it), or build it properly with a real database and user accounts. For most department tools, simple is fine.
Planning Tips That Actually Matter
Start with paper and pencil. Sketch the interface. List the features. This sounds obvious, but most people skip it and end up rebuilding things three times.
Think in phases. Phase 1 is the minimum viable version. Phase 2 adds the nice-to-haves. Phase 3 is polish. Ship Phase 1, see if people use it, then decide if Phase 2 is worth it.
Be specific about data structure. The AI needs to know what you're tracking. "A list of presentations" is vague. "Each presentation has a date, presenter name, paper title, paper URL, and optionally a list of attendees" is clear.
Don't reinvent solved problems. Need a calendar picker? Say "use a standard date picker component." Need charts? Say "use Chart.js or a similar library." The AI knows the ecosystem better than you do.
Deploy early. Don't wait until it's perfect. Get it online, share the link, collect feedback. Vercel and Netlify have free tiers and deploy from GitHub in minutes. The AI can set this up for you.
Real Examples from the Field
I'm not selling you a hypothetical. I've built:
BrachyFlight VR — A virtual reality training tool for brachytherapy procedures. Built with Unity and deployed to Quest headsets. Started as "can AI help me build a VR anatomy viewer" and became a teaching tool we actually use.
Brachy Scheduler — The app I mentioned earlier. Schedules procedures, tracks resources, sends reminders. Saved our scheduling coordinator probably five hours a week.
Spine Mets Calculator — Implements a clinical decision algorithm for spine metastases. Takes patient parameters, outputs treatment recommendations based on published scoring systems. Used by residents and attendings.
Annotation Platform — For research. Displays medical images, lets reviewers mark regions of interest, exports structured data. Built because commercial annotation tools cost thousands monthly and did way more than we needed.
Food Decision App — Okay, this one's personal. My wife and I couldn't decide where to eat. Now we have an app that randomly picks from our saved restaurants weighted by how much we like them. Stupid? Yes. Useful? Also yes.
None of these required me to become a software engineer. I described the problem, iterated with the AI, and shipped. Most took a few evenings to build, maybe a weekend for the complex ones.
What Vibe Coding Is Bad At
Let's be honest about limitations.
HIPAA compliance and real patient data. Don't build patient-facing tools with vibe coding unless you're prepared to do serious security work afterward. The AI might write secure code, but you don't know enough to verify it. Stick to non-PHI applications, educational tools, and workflow helpers.
Complex backend systems. Vibe coding excels at frontend applications and simple backends. You can build a REST API with authentication and a database. You probably shouldn't build a distributed system with microservices and complex state management.
Production-grade reliability. The journal club tracker going down for an hour? Annoying. Your on-call scheduling system failing at 2 AM? Unacceptable. Know the difference. For critical infrastructure, you still need professional developers and proper DevOps.
Enterprise integration. Connecting to your hospital's Epic instance or institutional databases requires security reviews, API access, and IT cooperation. Vibe coding won't get you there. It's great for standalone tools, not enterprise plumbing.
Maintenance at scale. If ten people use your tool, you can maintain it. If a thousand people depend on it across multiple institutions, you need a real software team. Know when your side project needs to grow up.
The sweet spot: Departmental tools, research utilities, educational demos, internal dashboards, workflow helpers. Things where "good enough and working today" beats "perfect and maybe next year."
The Bigger Picture: Agency
Here's what this is really about. For decades, if you had an idea for a clinical tool or research application, you had three options:
- Beg IT to build it (wait 18 months, get 40% of what you wanted)
- Apply for funding to hire developers (wait 12 months, maybe get rejected)
- Give up
Now you have a fourth option: Build it yourself this weekend.
That's not hyperbole. You can go from "I wish we had a tool for this" to "here's a working prototype, try it" in hours. Show it to your department. Get feedback. Iterate. If it's useful, people will use it. If it's not, you learned something and lost a weekend.
This is about not waiting for permission. Not waiting for budget approval. Not waiting for someone else to understand your workflow well enough to build the right tool.
You know the problem better than any developer ever will. You can describe it clearly. AI can turn that description into code. That's the entire value chain, and you own all of it now.
Start Small, Ship Fast
Your first project should take less than a day. Pick something genuinely useful but not critical. Build it, share it, see what happens. The goal isn't perfection — it's proving to yourself that this actually works.
Then build something bigger.
Will everything you build be great? No. Will some projects fail? Absolutely. Will you build things that turn out to be genuinely useful and get adopted by colleagues? Yes, and that feeling is worth every failed experiment.
Getting Started Today
You don't need to read more articles. You don't need to take a course. You need to pick a problem and start.
Open Claude or Cursor. Think of something annoying in your daily work. Write a clear description of what would make it less annoying. Ask the AI to build it. Iterate until it works.
That's the entire recipe.
The clinicians building their own tools aren't special. They're not secret programmers. They just started. They had a problem, described it clearly, and let AI turn that description into software.
Your department has problems that will never justify commercial solutions. Your research has workflows that no off-the-shelf tool quite fits. Your education program has needs that are too specific for generic platforms.
Build the tools yourself. It's easier than you think, more useful than you expect, and honestly kind of fun once you get past the first project.
Welcome to vibe coding. Your IDE is ready. What are you going to build?