Describing what you want

The model cannot read your mind, and it will not say so

Ask for "a booking app for my salon" and you will get a booking app. It will have appointments, times, maybe a calendar. It will also have invented answers to about forty questions you never asked, because it had to pick something: whether two people can book the same slot, what happens at closing time, whether a customer can cancel, what a phone number looks like.

Those invented answers are the bugs you will spend next week chasing. The prompt is where you prevent them.

A specification has four parts

When you describe a feature, cover these:

Things — what exists, and what each one holds. "A booking has a customer name, a phone number, a stylist, a start time and a duration in minutes."

Actions — who does what. "A customer creates a booking. A stylist cancels one. Nobody edits a booking once it has started."

Rules — the constraints that make it yours. "Two bookings cannot overlap for the same stylist. Bookings only between 09:00 and 19:00. Maximum 30 days ahead."

Failures — this is the one people skip, and it is worth more than the other three combined. "If the slot was taken while they were filling the form, show the message 'That time just went. Here are the next three openings.' and do not lose what they typed."

Most AI-written bugs live in the failure paths, because nobody described them, so the model wrote the happy path and left the rest silent.

Adjectives are not requirements

Bad:  Build it production-ready, secure and scalable.
Good: Only the logged-in user can see their own bookings.
      Check that on the server, not in the browser.
      A page must load in under two seconds on a phone.

"Make it secure" produces the appearance of security: a comment saying // validate input, a variable called sanitized. Say what must be true and where it must be checked, and you get something you can verify.

Small steps beat long prompts

There is a widespread belief that the trick is writing one enormous, perfect prompt. It is not. A 900-word prompt produces 900 words of code you have not read, in files you did not know existed, and when something is wrong you cannot tell which part.

Build in slices you can check in under two minutes:

1. 1"Make a page at /book that shows a form: name, phone, stylist dropdown, date, time. No saving yet. Just the form."
2. 2Open it. Does it look right on your phone?
3. 3"Now save a submitted form to the database. Show the saved booking on screen afterwards."
4. 4Submit one. Look in the database.
5. 5"Now reject a booking that overlaps an existing one for the same stylist, with this message."
6. 6Try to make a double booking on purpose.

Each step is small enough that when it breaks you know exactly what broke it.

Decide the stack once, then repeat it

If you never state your tools, the model picks fresh each time, and by Thursday you have three ways of talking to the database. Write your stack down once and paste it into every session, or put it in the file your tool reads automatically — .cursorrules, CLAUDE.md, AGENTS.md, depending on the tool.

Next.js with the app router. TypeScript. Postgres via Drizzle.
Tailwind for styling. No new dependencies without asking me first.
Every database query goes in lib/queries.ts.

That last line matters more than it looks. Without it, database calls end up scattered across twenty files and nobody, including you, can answer the question "where does this data come from?"

Show, do not only tell

The strongest thing you can hand a model is an example of what you already have. "Add a cancel button that matches the edit button in components/BookingRow.tsx" gets you consistency for free. Screenshots work too — for layout, a screenshot with two arrows drawn on it beats three paragraphs of description.

One question to ask before you send

Read your prompt and ask: if a competent stranger built exactly this and it was wrong, what would they have had to guess?

Answer that, and send.