Over the next fourteen parts we're going to build one real application — a clinic booking-and-queue system with Blazor Server, PostgreSQL and SignalR — and an AI is going to write most of the code. We'll show every prompt, keep every mistake in, and count every dollar. This first part is the map: the tools, the models, and what you can honestly expect before we type a single prompt.
Two ways to use AI for code
If you've never used AI tooling, here's the landscape in one paragraph. The first way is chat: you open a chat window, paste some code, ask a question, and copy the answer back into your editor. It works — plenty of developers learned a lot this way — but notice who's doing the manual labour. The model only knows what you paste, it can't run anything, and you are the clipboard, ferrying code back and forth and hoping you pasted enough context.
The second way is agentic: a tool that lives in your project folder, reads your files itself, proposes edits as reviewable diffs, runs your build and your tests, and asks permission before doing anything. You stop being the clipboard and become the reviewer — which, as we'll see, is the job that actually matters.
This series uses Claude Code, Anthropic's agentic tool. It comes in whichever shape suits you: a command-line tool, a desktop app for Mac and Windows, a web version at claude.ai/code, and IDE extensions for VS Code and JetBrains. Everything in this series works the same in all of them; we'll set it up properly in Part 2.
The method: prompt, review, refine, commit
Before tools and prices, the thing that actually decides whether AI development goes well. Everything we build in this series follows one loop:
You describe what you want and why. The AI writes code you didn't type. Then comes the step that separates professionals from headlines: you read it, run it, and test it. Code that isn't right doesn't get argued with — it feeds a sharper, smaller prompt. Code that is right gets committed in a small, reviewable piece. That's the whole method. Every part of this series is this loop, applied to a different problem, and the review step is the one we never skip.
Which model, when — and what it costs
"AI" isn't one thing you talk to; you choose a model per task, and the choice is mostly about money and thinking depth. Models are priced per token — roughly three-quarters of a word — and you pay separately for what the model reads (input) and what it writes (output). Here's the current Claude line-up:
| Model | Price in / out | What it's for |
|---|---|---|
| Claude Opus 5 | $5 / $25 | The deep-work default: hard design, debugging, code review |
| Claude Sonnet 5 | $3 / $15 | The everyday coding workhorse |
| Claude Haiku 4.5 | $1 / $5 | Quick questions and mechanical edits |
Each model also takes an effort setting, from low to max, which controls how hard it thinks before answering. High effort on a hard problem buys real quality; high effort on "rename this variable" buys you a more expensive rename. Our rule of thumb, which the whole series follows:
| The task | The pick | Because |
|---|---|---|
| Writing a spec, designing a schema, reviewing code | Opus, high effort | Mistakes here compound for months; thinking is cheap by comparison |
| CRUD features, scaffolding, tests | Sonnet | Well-trodden ground; the workhorse handles it |
| "Rename this everywhere", formatting, tiny edits | Haiku | Mechanical work deserves mechanical prices |
Note: everything above is true as of August 2026. Models and prices churn faster than any other fact in this series — this is the one section you should re-check against current pricing before trusting the numbers. The method — match the model to the stakes of the task — outlives any price list.
Model pick: every part of this series opens its toolbox in a box like this one — which model, what effort, and why. This part is all reading, so nothing was billed to the build yet; the standing picks are the table above, and you'll see us follow it: Opus for the spec and schema in Parts 3–4, Sonnet for the scaffolding in Part 5.
Honest expectations
Here's the part most AI content skips. These tools are genuinely, sometimes shockingly good at a specific set of things:
- Boilerplate — the code you've written a hundred times and never enjoyed once: DTOs, mappings, configuration, test scaffolding.
- Translation between technologies — "this is how I did it in SQL Server, show me the PostgreSQL way" is a question AI answers better than most search results.
- First drafts — a working starting point in minutes, for you to shape.
- Explaining errors — paste a stack trace and get a plain-English account of what went wrong, and usually why.
And there's a set of things it reliably gets wrong, no matter how impressive it looks while doing them:
- Your business rules — the AI has never met your clinic, your users, or your edge cases. It will guess, confidently.
- Time zones — AI-written date handling that compiles and demos fine can still be quietly wrong about what "today" means. Ask us how we know (Part 10).
- Security defaults — it happily ships whatever a template ships, including the parts a hostile reviewer would circle in red (Part 11).
- Its own blind spots — it can't tell you what it doesn't know, and it repeats its habits. Wait until you see it make the exact same compiler error in two different parts.
What the AI got wrong: nothing yet — we haven't asked it for anything. But this box appears in every part, because keeping the mistakes in is the point of this series. Coming attractions, all real: an SMS feature nobody asked for (Part 3), timestamps without time zones (Part 4), a chat design that fails authentication forever (Part 8), and a test that passes because the code is wrong (Part 9). The human stays the pilot. That's not a disclaimer; it's the method.
What we're building: ClinicLive
A real app needs a real problem, so meet ClinicLive: front-desk software for a small clinic. Patients book a 15-minute appointment from their phone — no account, no password, just a short confirmation code. A tablet at the door lets them check in with that code. A waiting-room screen updates by itself the second someone checks in. And behind the login, reception and practitioners see today's schedule, call the next patient, and chat with each other — with presence and typing indicators — instead of shouting down the corridor.
That little diagram is the whole build: three browser surfaces, one Blazor Server app, one PostgreSQL database, and SignalR pushing changes out so nobody ever presses refresh. It's small enough to finish and real enough to hurt — bookings can race, queues can be ordered wrong, and time zones can lie. Perfect.
The finished code lives in the companion repository at github.com/rahulvyas777/clinic-live, and it has one unusual property: every commit message contains the actual prompt that produced the commit. The repo's history is the series. From Part 3 onward there's a tag per part, so you can check out the code exactly as it stood at the end of any chapter.
What about Copilot, Cursor and the rest?
Alternatives absolutely exist — GitHub Copilot, Cursor, Google's Gemini CLI, and more arriving monthly — and they're good tools; the loop in the figure above applies to all of them. We use Claude Code for this series for an unexciting reason: going deep on one tool teaches you more than a survey of five, and depth is what you can carry to whichever tool your team ends up using. If your instinct is to comparison-shop first, our beginner's guide to AI-assisted coding surveys the field; this series is the deep end.
The meter: our build so far: $0.00. Every part reports the running total, honestly. And a spoiler worth having up front: the entire fourteen-part build — spec, schema, features, real-time, tests, debugging, hardening and deployment — lands at about six dollars of model usage. Hold that number next to any hype you've heard, in either direction.
Checkpoint: before Part 2 you should be able to say what separates chat from agentic tools, name which Claude model you'd pick for a schema design versus a mechanical rename, and sketch ClinicLive's three surfaces from memory. No installs yet — but having an Anthropic account ready (a paid Claude plan or API billing, either works) will make the next part a straight run.
The map is drawn. In Part 2, Claude Code goes onto your machine, learns your project's house rules from a file called CLAUDE.md, and makes its first change to real code — reviewed, understood, and committed like you mean it.