The Basics of Claude Coding for Physicians

Build a working app from scratch with Claude — no coding experience required. Ten hands-on lessons from a plain-English idea to a running app.

Who it's for: Physicians with zero coding background who want to build a real, working app with Claude

Build a working app from scratch with Claude — no coding experience required. Across ten hands-on lessons you go from a plain-English idea to a running app on your own computer, directing Claude every step of the way. You'll set up your machine, write a spec, scaffold a website, build a backend and database, and wire in Claude itself to power 'The Consult Room' — a council of AI advisors that weigh in on a question and explain the answer plainly. Educational only, not for clinical decisions.

10 lessons · $299 · lifetime access · certificate of completion

Syllabus

  1. Lesson 1: What Coding with Claude Means: You Direct. Claude Builds. From Idea to Localhost. (22 min)

    • Describe the Claude development loop — how you and the assistant trade off.
    • Name the parts of a web app and the path from idea to a running program.
    • Know what “localhost” means and what you'll have built by the end of the course.

    Takeaway: Coding with Claude is a loop: you describe what you want, Claude writes the code, you run it and refine — and you stay the architect throughout. An app is three parts — a frontend, a backend, and a database — and this course walks one idea all the way to a working program on your own laptop. No computer science degree required; your clinical judgment is the rarest input.

  2. Lesson 2: Setting Up Your Machine: Four Free Tools, Installed and Verified, in One Sitting. (20 min)

    • Open a terminal on your Mac or Windows machine and type a command into it.
    • Install the four free tools — Node.js, Claude Code, VS Code, and Git — and verify each one.
    • Read an exit code to tell, instantly, whether the last command succeeded or failed.

    Takeaway: Your workshop is built. You opened a terminal, you installed four free tools — Node.js, Claude Code, VS Code, and Git — and you verified each one with a version command instead of hoping it worked. And you learned the simplest possible success signal: an exit code of zero means the last command succeeded; anything else means look closer. You only do this once, and you've done it. From here on, we build.

  3. Lesson 3: From Idea to Spec: Turning a Clinical Wish Into Instructions Claude Can Build From. (20 min)

    • Describe what makes a spec something Claude can build from — the four parts it needs.
    • Read the one-paragraph spec for The Consult Room and the simple data model behind it.
    • State the rule that keeps this a learning tool: educational, never for clinical decisions.

    Takeaway: You turned an idea into a plan. A spec Claude can build from answers four things — what it does, the one page, the data, and the stack — and our whole app fits in one paragraph. Underneath it sits a simple data model: a Question, the Answers, and a Verdict. And written into the spec from the start is the boundary that keeps it honest — this is a learning tool, educational only, never for clinical decisions, and no real PHI. The blueprint is done. Next, we build.

  4. Lesson 4: Your First Website: Scaffold the App, Run It, and See a Page on Localhost. (20 min)

    • Scaffold a Vite React app with Claude using one create command.
    • Run the dev server and open your page at localhost:5173.
    • Lay out the front door of The Consult Room — a title, a textarea, and a button.

    Takeaway: You just built your first website. One create command scaffolded a Vite React app; 'npm run dev' put it on localhost:5173; and a plain-English request turned the starter page into the front door of The Consult Room — a title, a textarea, and an 'Ask the Room' button. The button doesn't do anything yet, and that's exactly where we're headed next. You directed every step. Claude did the typing.

  5. Lesson 5: Anatomy of a Web App: Frontend, Backend, Database, API — and How They Talk. (20 min)

    • Name the four parts of a web app: frontend, backend, database, and API.
    • Map each part onto The Consult Room and the stack we're using.
    • Trace a single button click from request to response on the screen.

    Takeaway: A web app has four parts: a frontend you see, a backend that thinks, a database that remembers, and an API that lets the frontend and backend talk — using HTTP to make requests and JSON to carry the data. Map that onto The Consult Room: a React page on 5173, a FastAPI backend on 8000, a SQLite file behind it. Every button click is one round trip — click, request, work, response, screen. See that shape once, and you'll see it in every app you use.

  6. Lesson 6: The Backend: A Route That Listens, Answers, and Remembers (20 min)

    • Explain what a route is and what FastAPI does for the backend.
    • Read a POST /ask route that takes a question and returns an answer.
    • Understand how the question gets saved to a small SQLite database — and run the server.

    Takeaway: The backend is where your app does real work. We built one route — POST slash-ask — that takes a question, saves it to a single-file database called SQLite, and returns an answer. For now that answer is a placeholder, and that's on purpose: we proved the whole pipe works before adding anything clever. One command, uvicorn, brings it to life on localhost port eight thousand. You now have a server with a memory — and every future feature is just another route shaped like this one.

  7. Lesson 7: Adding AI: Your Backend Calls Claude — and Starts to Think (20 min)

    • Install the Anthropic SDK and store your API key safely in a .env file.
    • Read the call that sends a question to Claude and gets an answer back.
    • Understand what a system prompt does — and how /ask now returns Claude's real answer.

    Takeaway: Your app thinks now. You installed the Anthropic SDK, stored your key safely in dot-env — and never commit that file — and made one call to Claude with a model, a system prompt, and the question. The system prompt decides who the advisor is, and changing it changes the whole answer. Your slash-ask route returns Claude's real reply where the placeholder used to be. The real apps reach the same Claude through AWS Bedrock for data control — but the direct API you used today is exactly right for where you are.

  8. Lesson 8: Setting Up the Council: One Advisor Becomes Three — and a Chair to Judge Them. (20 min)

    • Define three advisor personas as short system prompts in your backend.
    • Loop one question through all three to collect three answers.
    • Add a Chair call that synthesizes those answers into a balanced verdict.

    Takeaway: A council is just one model wearing three hats. You define three advisors — the Generalist, the Skeptic, and the Specialist — as three short system prompts, loop your question through all three to collect three answers, then add a Chair that weighs them into one balanced verdict. Four Claude calls, almost no new code, and your app now reasons like a room instead of a single voice. That's the LLM-Council pattern — and you built it.

  9. Lesson 9: Adding Feynman: Turn the Verdict Into Plain Language a Bright Student Could Follow. (18 min)

    • Write a Feynman persona that re-explains text in plain language with an analogy.
    • Add a final Feynman call so /ask also returns a “feynman” field.
    • Render the council, the verdict, and Feynman together on the React page.

    Takeaway: Feynman is the council's clarity step: one more system prompt that takes the Chair's verdict and re-explains it with no jargon and a single good analogy — the way you'd teach a bright beginner. You added one Claude call, returned one new field from /ask, and rendered one new section on the page. The pipeline is now complete: question, council, Chair, Feynman, page. You've built a real multi-step AI app — and it explains itself.

  10. Lesson 10: Running It Locally & Next Steps: Two Servers, Debugging With Claude, Safety, and the Road Ahead. (20 min)

    • Run both servers together and open your app at localhost:5173.
    • Debug problems by pasting the error straight to Claude.
    • State the PHI rule for learning apps and outline the road to the cloud.

    Takeaway: You can now run your app with two commands, fix what breaks by pasting the error to Claude, and you know the bright lines: no real patient data in a learning app, and this is a tool for understanding, not a clinical decision-maker. You took one idea from a blank screen to a working, multi-step AI application — and you understand every piece. The method is yours now: describe, build, run, refine. Keep going.

Related guides