What Vibe Coding Actually Is
Vibe coding is a term that describes building software by describing what you want in natural language and letting an AI coding assistant write the code. You provide the vision, the requirements, the constraints, and the feedback. The AI writes the implementation.
The term was coined by Andrej Karpathy in early 2025 and has since become shorthand for a broader shift in how non-developers can participate in software creation. For healthcare professionals, it means you can build tools that fit your specific workflow without waiting for a developer or paying for a generic SaaS subscription.
This post covers what vibe coding can realistically produce, what it cannot, and the specific workflow that was used to build a deployed functional medicine education platform without a traditional development background.
What You Can Realistically Build
In a single session with Claude Code, a non-developer with a clear vision and a well-written CLAUDE.md file can produce:
A functional web application with authentication, database integration, and multiple pages. It is deployable code that can go live on Vercel or Netlify within hours, and that speed is exactly where people get into trouble. If the app touches identifiable client health information, the free tier is not an option. Vercel offers a BAA to Pro and Enterprise teams and requires that you qualify as a covered entity, and Hobby is not eligible. Netlify offers a BAA on its enterprise plan. HHS has stated plainly that a cloud provider maintaining ePHI is your business associate, that encrypting the data does not change that, and that using the provider without a signed BAA is itself a violation.
Automation workflows in n8n that route form submissions, send emails, and log data to Google Sheets. Keep identifiable client health information out of these unless every hop is covered. n8n's legal page lists no HIPAA business associate agreement, so n8n Cloud is not a destination for that data and self-hosting is the only route. On the Google side, a consumer Gmail or personal Google account is never covered: you need Google Workspace, a super administrator has to accept the BAA in the Admin console, and only the products on Google's HIPAA Included Functionality list are in scope. And if you are not a covered entity at all, you are not off the hook. The FTC Health Breach Notification Rule reaches health apps outside HIPAA, and it treats an unauthorised disclosure as a breach even when nobody was hacked. A sheet set to anyone with the link is a reportable event.
Custom HTML reports that visualise client data. Weight charts, habit streaks, supplement adherence grids. Before you build any of these, answer the FDA device question first. FDA's General Wellness guidance covers products that keep to general states of health and make no reference to a specific disease or condition. The moment your tool measures or trends a clinical parameter like blood glucose, interprets a reading, or flags a value as concerning, you have likely left the general wellness lane and built a device software function that needs a regulatory answer. Run your idea through FDA's Digital Health Policy Navigator before you write the first prompt. Whatever you build, it is client data with a name attached, so it is not a file you drop into a shared folder or email as an attachment.
What you cannot realistically build without deeper involvement: complex real-time systems, custom mobile apps with native device integrations, or anything requiring deep infrastructure expertise. These are possible with vibe coding but require more iteration and a clearer understanding of what you are asking for.
The CLAUDE.md File Is the Key
The single most important thing you can do before starting a vibe coding session is write a good CLAUDE.md file. This is a plain text file that lives in the root of your project folder and tells Claude Code everything it needs to know about your project.
A good CLAUDE.md includes:
- What the project is and who it is for
- The tech stack and why it was chosen
- The design system (colors, fonts, spacing rules)
- The compliance rules, stated as hard stops and kept separate from style preferences. Write out which lane holds identifiable client health information and which holds none, and name the exact tables, buckets and log files in each. Define PHI correctly in the file so Claude applies the right test: under HHS guidance, PHI is any individually identifiable information about a person's health status, their care, or payment for their care. There is no diagnosis threshold and no lab value threshold. A client's name next to an appointment date is PHI. Style preferences belong in their own section, because a style miss is an edit and a PHI miss is a breach
- The file structure and naming conventions
- What has already been built and what still needs to be done
- The writing style rules for any copy Claude generates
When Claude Code reads a thorough CLAUDE.md at the start of a session, it behaves like a senior developer who has been briefed on the project. When it does not have one, it makes assumptions that often conflict with your requirements.
The Workflow That Actually Works
Here is the workflow used to build Hunters Holistic Health:
Step 1: Define the project in plain language. Write out what the app does, who uses it, and what the most important features are. Do not worry about technical terms. Write it the way you would explain it to a smart friend who is not a developer.
Step 2: Research the compliance requirements before writing a single line of code. For healthcare applications, this means understanding HIPAA and the cloud provider BAA requirement, the FDA device question for anything that measures, trends or interprets a clinical value, FDA's Clinical Decision Support criteria if the tool will ever put a recommendation in front of a clinician, the FTC Health Breach Notification Rule if you are not a covered entity, the FTC endorsement guides for testimonial or affiliate content, your state's regulations, and your own board's scope of practice rules. These constraints shape the architecture. You cannot add compliance as an afterthought.
Step 3: Write the CLAUDE.md. Include everything from Step 1 and Step 2. Add the design system, the writing style rules, and the hard stop rules (things Claude should never do without asking you first).
Step 4: Start with the data model. Before building any UI, define what data the app stores, how it is structured, and who can access what. For Supabase, this means writing the SQL schema and the Row Level Security policies first. Two things have to happen before any client health data reaches that database. Sign the BAA with Supabase, and confirm you are on the hosted platform, because Supabase states the HIPAA controls are built into the hosted platform and not into self-hosted deployments. Supabase describes this as a shared responsibility model: they act as your business associate, and you still carry the Privacy, Security and Breach Notification Rule obligations yourself. Row Level Security written first is the right instinct and it does not replace the agreement.
Step 5: Build one feature at a time. Do not ask Claude to build the entire app in one prompt. Build the authentication flow first. Then the dashboard. Then the first feature. Review each piece before moving to the next.
Step 6: Use the largest-context model for heavy lifting, Claude Code for iteration. Claude Fable 5.1 has a 1 million token context window and can hold your entire codebase, the CLAUDE.md, and reference documents all at once. Use it for the initial build and major refactors. Use Claude Code in VS Code for live iteration where you can see the browser in real time.
The Limits You Need to Understand
Vibe coding produces code that runs. That is not the same as code that works. Access control in particular tends to look fine when you are the only person logged in and fail the moment a second user or an unauthenticated request arrives, which is exactly the failure you will not notice from your own browser. It does not always produce code that is optimally structured, secure by default, or easy to maintain as the project grows. The larger the codebase gets, the more important it becomes to review what Claude produces rather than just accepting it.
The specific risks for healthcare applications:
- Claude may suggest storing data in a way that creates PHI exposure, and if you ship it, the exposure is yours. HIPAA liability sits with the covered entity and the business associate, not with the tool that wrote the line. The HIPAA hard stop rule in CLAUDE.md is worth writing and it is a prompt, which means it is probabilistic. Back it with something deterministic: Row Level Security enforced at the database, identifiable health data in its own tables with its own policies, and a manual check of every storage and logging decision before it goes live.
- Claude may generate copy that makes health claims. Review all user-facing text before publishing.
- Claude may use third-party libraries with security vulnerabilities. Run npm audit regularly. That is the easy one. The failures that actually leak health data are these, and you have to look for each by hand before you launch. Row Level Security switched off or written so permissively that any logged-in user reads every row. A service role key placed in client-side code, where every visitor can read it. Any secret in a variable your build tool compiles into the browser bundle, which for Vite means anything prefixed VITE_ is public by design. Session checks written on the client and missing on the server. API routes with no authentication at all. Before anything goes live, log in as a second test user and try to read the first user's records. Try the API routes with no token. Open the deployed bundle and search it for the word key. If you cannot do that review yourself, pay someone who can.
These risks do not rule out vibe coding for every healthcare application, and they do rule it out for some. Administrative tools, education pages, intake routers and scheduling helpers are well inside what a careful non-developer can build and review. Anything that meets FDA's definition of a device software function, or that fails the Clinical Decision Support criteria, carries a regulatory pathway you cannot satisfy from a weekend build, and that is a conversation with a regulatory consultant, not a longer prompt.
The Takeaway
Vibe coding is a legitimate path to building useful tools for your practice, with one line you should not cross without advice. The moment a tool puts a clinical recommendation in front of a clinician, you are in Clinical Decision Support territory, and FDA has four criteria in section 520(o)(1)(E) that determine whether that software is a regulated device. Software that supports time-critical decisions, or that hands over a recommendation the clinician cannot independently review the basis for, is a device. An interaction checker, a dosing calculator, a deprescribing prompt: these are the tools our profession reaches for first and they are the ones most likely to need a regulatory answer. Build the scheduling tool, the intake router and the education page yourself. Get advice before you build the one that tells a clinician what to do. Technical skill is not the main barrier. Two others are, and you have to clear both. The first is scope of practice. Build only what you are licensed to do offline. A tool that assesses, screens, interprets or recommends does not become acceptable because software is doing it. The second is which privacy regime you fall under. If you are a licensed clinician billing electronically, you are almost certainly a covered entity and HIPAA applies. If you are a health coach or wellness practitioner, you are probably not covered, and that is not a lighter obligation. It means the FTC Health Breach Notification Rule applies to your app instead, and under it an unauthorised disclosure is a reportable breach even when nobody was hacked.
After those, the work is defining what you want clearly, setting the right constraints, and reviewing what gets built before it goes live. Write the CLAUDE.md before you start and update it as the project changes.
This post is general information, not legal advice.