From Conversation to Spec: Make the AI Interview You

Claude Code is installed and the commit habit is set — so the tempting next prompt is "build me a clinic app". We're not going to type that. The highest-leverage forty cents of this entire build were spent before any code existed, on a one-page spec — and the trick is that we didn't write it. We made the AI interview us.

Why spec-first beats vibe-coding

Here's the thing about AI and clarity: the model amplifies whatever you feed it. Feed it a clear picture and it produces a lot of the right code, fast. Feed it a vague vibe and it produces a lot of plausible code, fast — confident, compiling, and wrong about everything you never said out loud. Vibe coding has its place (throwaway tools, experiments), but an app with real users deserves ten minutes of deciding what it actually is.

The traditional objection to specs is that writing them is slow and nobody reads them. Both problems just died: with an AI doing the drafting, a spec costs one short conversation — and the AI itself becomes the spec's most attentive reader, because we'll hand it back in every later part as the source of truth. Cheap to re-read, expensive to get wrong: that's exactly the kind of work you want done first.

The technique: make the AI interview you

Describe the app in plain words — no jargon, no table names, just what you want as you'd tell a friend — and then end the prompt by reversing the roles. Here is the actual prompt that started ClinicLive, verbatim from the companion repo's first commit:

I run the front desk at a small clinic. I want: patients book
appointments from their phone without creating an account, a tablet
at the door where they check in, a waiting-room screen that updates
by itself, and a way for reception and practitioners to chat.
Blazor, C#, PostgreSQL. Before any code: interview me about what's
unclear, then write a one-page spec with user stories, non-goals,
and the data model. Cut everything that is not needed for version 1.

Three moves in that prompt do all the work. The description is plain words from the user's chair — "a tablet at the door", not "a check-in module". The constraints are stated once — Blazor, C#, PostgreSQL — so the AI doesn't helpfully propose a React rewrite. And the ending flips the interview: ask me what's unclear, then write the spec, then cut everything v1 doesn't need. That last sentence is the difference between a spec and a wish list.

The interview

The AI came back with nine clarifying questions before writing a word of spec — and this is where the technique earns its keep, because every question was about something we genuinely hadn't said. A few of the real ones, and where the answers ended up:

Clarifying questions, our answers, and where they landed
The AI asked	We answered	Where it landed
Should booking take payments?	No — front-desk software, not billing	Non-goal: no payments, no insurance, no medical records
Send SMS or email confirmations?	No — the code is shown on screen	Non-goal: notifications are a v2 idea
Multiple clinics or locations?	One clinic, one queue	Non-goal: no multi-clinic tenancy
Do patients have accounts?	Never — the confirmation code is the credential	Non-goal: no patient accounts or passwords

Notice the pattern: every answer became a non-goal. The interview isn't just gathering requirements — it's building the fence around version 1, question by question, while the decisions are still free.

What a one-page spec looks like

The result is docs/spec.md in the companion repo — genuinely one page. Its skeleton is worth stealing for any project:

What we're building — three surfaces in three sentences: public booking, the check-in kiosk, and the staff area with a live queue board and chat.
Personas — patient, receptionist, practitioner, and the one thing each needs. If you can't name who a feature serves, it goes.
User stories — six of them, each verifiable: "as a patient, I can cancel with my code."
Non-goals — the underrated section, and the one AI needs most. More on this in a second.
Data model sketch — five entities in plain words (Patient, Appointment, QueueEntry, ChatMessage, Staff), no column types yet. This sketch is Part 4's entire input.
Definition of done — one paragraph describing a complete walk through the app that either works or doesn't. Ours ends "…and the whole thing survives a server restart with data intact."

Why are non-goals the underrated section? For human teams they prevent scope drift over months. For an AI they prevent it per conversation — because the model's instinct, on every feature request, is to be maximally helpful and build the general version. "No patient accounts" written once in the spec beats correcting the AI about login pages in every prompt from here to Part 14.

Model pick: Opus, high effort. Specs are where thinking pays: this document steers every later part, so it's cheap to re-read and expensive to get wrong — the exact profile of work the rule-of-thumb table from Part 1 sends to the deep-work model.

What the AI got wrong: the first spec draft invented an SMS notification feature nobody asked for, and it kept trying to give patients accounts until we stated the non-goal explicitly. Scope creep is an AI habit, not an accident — the model is trained to be helpful, and "helpful" defaults to "more". The fix is in the prompt above: deliver what was asked, at the scope intended, and cut everything v1 doesn't need.

The meter: our build so far: ≈ $0.40. One short Opus session — nine clarifying questions and the full spec. The cheapest insurance this project will ever buy.

To read the finished spec exactly as this part left it, check out the tag in the companion repo:

git clone https://github.com/rahulvyas777/clinic-live
cd clinic-live
git checkout part-03

The commit message contains the full prompt above — as every commit in this series does. And if this way of thinking appeals to you — turning conversations into designs before code — it's a whole discipline, and our system design hub goes much deeper than one part can.

Checkpoint: before Part 4 you should have a docs/spec.md in your repository — user stories, non-goals, a plain-words data sketch, and a definition of done — produced by the interview technique and committed with its prompt in the message. If your non-goals section is empty, the interview isn't finished.

The spec's data sketch names five entities and zero column types. In Part 4, that sketch becomes real PostgreSQL DDL — and we catch the AI making two mistakes that would have hurt for months, plus one it could never have caught for us.