Making the model ask before it guesses

Silence is not understanding

A model given an underspecified request does not stop and ask. It fills the gaps and proceeds, in the same confident tone it uses when everything was clear. That is the mechanism behind most of the surprises in this course: the guesses were invisible.

You can change this with one sentence.

Before writing any code, ask me every question whose answer
would change what you build. Number them. Do not start until
I have answered.

Ask for a booking system with that line attached and you typically get eight to fifteen questions, most of them ones you had not considered.

What comes back

For a salon booking app, a real list looks roughly like this:

1. Can a customer book without an account, or is signup required?
2. Are bookings confirmed instantly or does the salon approve them?
3. What is the minimum notice: can somebody book for ten minutes from now?
4. How far ahead can they book?
5. What happens to a booking when a stylist is marked unavailable that day?
6. Can a customer edit a booking, or only cancel and rebook?
7. Is there a cancellation cut-off?
8. Do you take payment at booking, or in the salon?
9. Which timezone are the stored times in, and which is displayed?
10. Should the customer receive an email or an SMS, and who pays for it?

Every one of those is a decision. Left unasked, ten decisions get made by a system that has never met your customers, and each wrong one is a feature you rebuild later.

Question 3 is the one that catches people. Nobody thinks about minimum notice until a customer books a haircut for two minutes’ time and nobody is there.

Answer briefly, in the same numbers

1. No account. Name and phone only.
2. Instant.
3. Two hours minimum notice.
4. 30 days ahead.
5. Existing bookings stand; the salon phones the customer.
6. Cancel and rebook only.
7. Two hours, same as booking notice.
8. In the salon. No payments in the app.
9. Store UTC, display Asia/Kolkata.
10. Nothing for now. Note where it would go.

Two minutes of typing. Save that block: it is the beginning of a specification, and it belongs in your repository rather than in a chat window that will be gone by Friday.

The follow-up question that finds the rest

After the answers, one more:

What decisions did you have to make that I did not specify,
and which of them would be expensive to change later?

This surfaces the second layer: the ones the model did not think to ask about because they felt like implementation. Whether cancelled bookings are deleted or flagged. Whether times are stored to the second or the minute. Whether the phone number is unique. All cheap now, all expensive in a month.

Why this is not just more prompting

There is a genuine asymmetry here. A question costs you ten seconds to answer. The same question, unasked and guessed wrong, costs you the discovery, the diagnosis, the rebuild and whatever the wrong behaviour did to a real customer in between.

So the ratio is enormously in favour of asking, and the only reason people skip it is that the first response feels like an obstacle between them and a working app.

Put it in the rules file

For any new feature, ask clarifying questions before writing code.
If a decision is unstated and would be expensive to reverse,
ask rather than choose.

That second sentence is the important half. You do not want to be asked about button colours. You want to be asked about anything that ends up in the database, in a URL, in an email that has been sent, or in a rule that money depends on: the things that cannot be quietly changed once they exist.

When to skip it

Small, obvious, reversible changes. A colour, a label, a sort order. Asking there is friction with no payoff, and if your rules file turns every request into an interview you will stop using it.

The boundary is the same one as everywhere else in this block: how expensive is being wrong. Cheap and visible, just build it. Expensive or quiet, ask first.