How to Write a PRD for AI Coding: Maya’s Appointment Form

Consider a founder named Maya who is building an appointment request form in a single evening. She needs customers to submit a request and see confirmation before she stops work. Her first AI coding prompt asks for a “simple booking page,” but it leaves out what information the form needs and what should happen when submission fails. Learning how to write a PRD for AI coding gives her a way to settle those questions before the tool fills in the blanks.

A PRD is a product requirements document. For a small AI-assisted build, it can be a short statement of the user’s goal, the required behavior, the boundaries, and the checks that prove the feature works. Its value is specificity, not length.

The first request left too much open

Maya starts with a prompt that sounds reasonable: “Build a clean booking page for my service.” The tool can produce a page from that instruction, but Maya cannot yet tell whether the result meets her needs. Does “booking” mean an instantly confirmed appointment or a request she will review? Should customers choose a time? Where should their contact details go?

She pauses before building further. Her immediate goal is narrower than a booking system: collect a request she can respond to. That distinction prevents an attractive interface from setting the product rules by accident.

How Maya wrote the PRD for AI coding

Maya writes a compact set of requirements in plain language. She gives the coding tool a behavior to implement and herself a behavior to check:

• User goal: A customer can send an appointment request without creating an account.
• Inputs: Name, email, preferred date, and a short description of the request.
• Submission rule: Required fields must be present, and the email must have a valid format.
• Success state: The customer sees that the request was received, without being told the appointment is confirmed.
• Failure state: The customer sees an error and can retry without retyping everything.
• Out of scope: Payments, account creation, and automatic scheduling.
• Acceptance checks: Submit valid information, leave a required field empty, enter an invalid email, and retry after a failed submission.

This is enough to expose a decision Maya still has to make: where the request is stored and how she will retrieve it. She resolves that before asking for implementation. A PRD is useful precisely when it reveals a missing decision while changing it is still easy.

The second prompt made review possible

Maya gives the tool her requirements and asks: “Implement the appointment request form from these requirements. First identify any missing decisions. Then make the smallest change that satisfies the acceptance checks. Show me which files you changed.” That request does not guarantee correct code. It gives her a way to inspect the proposed work against something more stable than her memory of a chat.

She tests the valid submission and each failure case herself. She also reviews the data write and checks that the confirmation does not promise a confirmed slot. If the tool adds a calendar picker or account flow, she can point to the out-of-scope line and remove it. By the end of the evening, the result is a request form she can evaluate against the behavior she chose, rather than a page she has to interpret after the fact.

What changed, and what carries into your next session?

The short PRD gave Maya two useful things: a boundary for generation and a test for the result. It did not eliminate implementation work or prove the form is ready for every production use. Before deploying a form that handles customer information, she still needs to protect secrets, review how submissions are stored, and test access to that data.

To check those risks systematically, use this checklist for reviewing AI-generated code before shipping.

You can use the same approach for a dashboard, an internal approval flow, or a new settings screen. Write the user goal, the success and failure states, what is out of scope, and a few actions you can perform to verify the result. Add detail when a tool asks a question or a test exposes ambiguity, rather than writing a long document in advance.

Maya keeps the accepted behavior and remaining work in VibeCrumbs so her next session can start from the decision she made. A todo discovered during testing can move into the feature pipeline instead of disappearing beneath later prompts.

Try it with one feature

Take the next feature you were about to describe in a single sentence. Give it a user goal, an explicit success state, a failure state, and a boundary. Then ask your coding tool to flag missing decisions before it edits anything. You will have a clearer basis for deciding what to keep.

To preserve that basis after the chat moves on, save your feature decisions and next actions.