Vibe coding & prompting: best practices

1. Start with the problem, not the tool

The best projects solve a small, concrete annoyance you meet every week: a calculation you do by hand, a list you keep in a notebook, a handout you rewrite for every patient. Describe it in one sentence before you open any AI tool: "Residents spend ten minutes per shift looking up phone numbers that are spread over three systems."

Ask yourself: who uses it, how often, and what happens if it is wrong? If the answer to the last question is "a patient could be harmed", read the medical device section first.

2. Write a short spec

Half a page is enough. AI tools build much better software from a clear description than from a one-line request.

Users: who will use it, on which device, in which situation (a phone on a night shift is different from a desktop in clinic).
Inputs and outputs: what goes in, what comes out, with units.
Must-haves: the three to five things version 1 has to do. Everything else goes on a "later" list.
Constraints: no patient data, works offline, Dutch language, accessible, no login, and so on.
Done means: how you will know it works, for example ten worked examples with known answers.

3. Prompting that works

Give context, a goal, constraints and an output format. "You are helping a cardiologist build a simple web app. Goal: … Constraints: … Reply with a plan first, no code yet."
Ask for a plan before code. Review the plan, correct it, then ask it to build step 1.
Let the AI ask questions. End with: "Before you start, ask me up to five questions about anything that is unclear."
Be specific. "Make it nicer" gives random results. "Make the buttons at least 44 pixels high so they work with gloves on" gives exactly what you need.
Show examples. Paste an example input and the exact output you expect.
Keep the AI honest. Ask it to list its assumptions and to say when it is unsure. Never accept clinical facts, dosages or guideline values from an AI without checking the source.
Pick a simple stack. Ask for the simplest technology that solves the problem, such as a single HTML page, before reaching for frameworks, databases and logins.

4. Work in small steps

Build one feature at a time. Run it and test it before asking for the next.
Use version control (Git) and commit after every step that works. When the AI breaks something, and it will, you can go back in seconds.
Ask for small, focused changes: "Only change the validation of the weight field; don't touch anything else."
Read the summary of what changed. If the AI rewrote half your app to fix one button, undo and ask again more narrowly.

5. Test the clinical logic yourself

AI-written code often looks right and is subtly wrong: a unit mix-up, an off-by-one threshold, a "greater than" that should be "greater than or equal to". You are the domain expert, so you are the tester.

Collect worked examples with known answers from the guideline, a textbook or a validated tool, and check every one.
Test the edges: exactly on the threshold, zero, empty fields, extreme values, wrong units (kg versus g, mmol/L versus mg/dL).
Ask the AI to write automated tests from your examples, then check that the tests really test what you expect.
Show the source: display the guideline name and version next to any score or advice.
Have a colleague try to break it before anyone relies on it.

6. Understand what you ship

Ask the AI to explain each file in plain language, and to add short comments where the logic is not obvious.
Keep a README: what the tool does, how to run it, where the data lives and who to contact.
If you can't explain how the important part works, it isn't ready for others to use.

7. When you get stuck

Paste the exact error message and describe what you expected and what happened instead.
If the AI goes round in circles, stop. Start a new conversation with a short summary of the goal, the current code and what you have already tried.
Ask it to add logging or print statements to find out what is really going on, instead of guessing at fixes.
Roll back to your last working commit rather than piling fixes on top of a broken state.

8. Security basics

No secrets in code or in the browser; use environment variables on the server.
Validate all input on the server, and escape anything you show back to users.
Use HTTPS everywhere and keep dependencies up to date.
Ask: "Review this code for security problems as if you were a penetration tester." Then fix what it finds.
Follow the privacy guide for anything that touches personal data.

9. When to call in a developer

Vibe coding is great for prototypes, personal tools and teaching material. Bring in professional developers and your IT department when:

the tool will process real patient data or connect to the health record;
clinical decisions will depend on it;
other people will rely on it every day, or it needs to keep working after you leave;
you need user accounts, payments or integrations with hospital systems.

Your prototype and spec are then a very valuable starting point: they show exactly what clinicians need.

10. Prompt templates

Start a project

I am a [specialty] doctor. I want to build [one sentence].
Users: [who, on which device, in which situation].
Must-haves: [3–5 bullet points].
Constraints: no patient data (use clearly fake demo data),
the simplest possible technology, works on a phone.
First ask me up to five questions. Then propose a plan
in small steps. Don't write code until I approve the plan.

Make a focused change

Only change [specific part]. Keep everything else as it is.
Explain what you changed and why, and tell me how to test it.

Check the clinical logic

Here are 10 worked examples with the correct answers: [examples].
Write automated tests for them and run them. For each failing
test, explain the cause before you change any code.

Security and privacy review

Review this project as a security and privacy expert.
Look for secrets in the code, missing input validation, data sent
to third parties, and anything that could expose personal data.
List the problems by severity and suggest fixes.