You will be able to write a one-page spec an AI coding assistant can build from.
The second time Priya started her app, she typed one line into her coding assistant: "Build a web app that summarises customer feedback using AI." It produced something in two minutes. It had a chat interface she did not want, called the model directly from the browser with a placeholder for the key, and returned paragraphs of prose rather than her table. None of that was the assistant's fault. A one-line request leaves every decision to the assistant, and it filled them in with the most common answers it knew.
A spec is where you make those decisions yourself, before any code exists.
A spec, short for specification, is a short document describing what the app does, precise enough that someone else could build it without asking you questions. For a small app, one page is enough. Write it in plain words, because what you are describing is behaviour, and the code comes later.
Cover five things.
The user: who uses the app, in one or two sentences, from lesson 6.1, Pick a project small enough to finish.
The job: the single task the app does for them.
The screens: each screen, and what is on it. Priya has one: a text box for pasting feedback, a submit button, a results table with columns for sentiment, issues and summary, and an area for error messages.
The data: what the app stores, if anything, and where. Priya's version one stores nothing. Saying so explicitly stops the assistant from adding a database "to be helpful".
The actions: what happens when the user does each thing. When the user presses submit, the browser sends the text to the server. The server splits it into individual feedback items, one per line, and rejects the request if there are more than 50. It calls the model for each item with the system prompt and the schema from module 2, validates each reply, and returns the results for the page to show as a table.
Then give examples. Lesson 2.1 of Working with AI assistants, One good example beats a paragraph of description, made that point about prompts, and it holds just as well for a spec.
Priya included three feedback lines and the exact row each should produce. She also wrote down what should happen when things go wrong, because a spec that only describes the happy path produces an app that only works on the happy path. Empty box: show "Paste at least one piece of feedback" and do not call the model. Over 50 items: show "Please paste 50 items or fewer" and do not call the model. One item fails validation twice: show that row as "Could not summarise" and carry on with the rest. Model call times out: show "This is taking longer than usual, please try again" and keep the pasted text in the box. Those rules come straight from lesson 2.3, Handle a bad response without crashing.
Include one line about the API key, every time. Priya's reads: "The model API key is read from an environment variable on the server. It is never sent to the browser and never written in any file in the repository."
That line exists because, as you saw at the start of this lesson, assistants sometimes default to calling the model from the browser, especially for quick prototypes. Stating the rule in the spec means the assistant builds the right structure from the start. It also gives you something concrete to check every change against in lesson 6.3, Work in small steps and read every change.
Once the spec is written, do not ask for code yet. Give the assistant the spec and ask it to do two things: restate the plan in its own words, including the files it would create and how the browser and server talk to each other, and list every question or ambiguity it sees.
The restatement shows you whether it understood. If it describes a database you never mentioned, or the browser calling the model directly, you have caught a misunderstanding before it became a hundred lines of code.
The questions show you what you left out. Priya's assistant asked how to split feedback items if one contains a line break, what to do with feedback in languages other than English, and whether results should be downloadable. She answered the first two in the spec and added the third to her later list.
Revise the spec with the answers and ask again. Stop when the questions that come back are only about small details. This is the same "plan before the work" habit as lesson 3.2 of Working with AI assistants, Ask for the plan before the work. The difference is that here the plan becomes a file in your repository, which you and the assistant will keep referring to.
The activity below asks you to write your spec, put it through this question round with your assistant, and revise it.
Write a one-page spec for your app and have an AI coding assistant restate it and ask questions, then revise the spec.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).