Prompts as briefs: how to give an AI a task

A prompt is an assignment for a language model; a good one is built like a brief: a goal, a reader, facts, limits, examples of tone and a test for done.

A request and an assignment

When you ask a living front-end developer “make a site for a consultant”, they don’t start work. They ask: what do you do, for whom, what must the visitor do, what are your services, what is your tone, do you have proof? They do it because, without answers, the result will be something average, that is, right for nobody.

A language model works differently. It almost never asks back, unless you ask it to, and whatever you didn’t say it completes with the most probable thing. The slogan “Innovative solutions for your business”, three cards with icons and “10,000+ customers” aren’t a model’s mistake but its honest answer to a request with nothing specific in it. You saw it in the part on design (the tells of a page an AI made) and in the first lesson of this part.

So the main technique here is one: write the prompt as a brief, that is, an assignment that can be carried out with no guessing. And you already have a brief: all the fields you filled in from the first lesson of the course.

What a prompt-brief is made of

1. Context and goal. Who you are, what you do, what the site is for. In a sentence or two.
2. Audience. Who the site is for: both the words and the order depend on it.
3. The main action. What the visitor must do. It is what everything else is for.
4. Content. The sections, what you offer, the people, the proof. And a must: “use only these facts and invent nothing; if there is no data, don’t make the block”. It is the best protection against invented numbers and achievements.
5. Limits: what not to do. “Don’t invent reviews, don’t add third-party scripts, don’t use stock wording.” A prohibition works better than the wish “be careful”.
6. Tone by example. Not “warm and professional” (everyone reads it differently) but two or three of your real sentences. A model imitates examples more exactly than adjectives. In prompting guides this is called showing examples (few-shot, or multishot).
7. The format of the result. What exactly you need: one HTML file and one CSS file, meaningful markup, no external scripts, a lang attribute.
8. Tests for done. How to tell the assignment is finished: “exactly one first-level heading”, “every image has alt”, “contrast of at least 4.5 to 1”. A test turns a wish into an assignment you can check, and you use the same tests in the next lesson, when you check the result.

Two more techniques are advised by the authors of the guides. A plan first, then the code: ask it first to describe the page’s structure and to write only after you agree. And let the model ask back: add “if you lack data, ask me questions rather than invent”. In the last lesson you’ll see this technique taken all the way: an interview.

Data: what not to send

Whatever you put into a request goes to the model’s operator. That means three things.

• Secrets are never sent: passwords, keys, tokens. And don’t ask a model to “deploy the site itself” with your credentials.
• Other people’s personal data (clients’, colleagues’) is sent only with their consent and by the rules of the law. A site doesn’t need it anyway.
• Your own public material may be sent: what will be on the page anyway. A phone number and an email can be written into the finished page later, not into the prompt.

If it matters to you that data doesn’t leave your region, look at the lesson on your own pipeline for models you can run or host yourself.

One more caveat about security. A model doesn’t always tell your instruction from the text it is reading. If a prompt includes someone else’s text (a page, an email, a document), it may hold “instructions” that the model takes for yours. This is called prompt injection. A simple defense: keep your instructions apart from the data (“below is the text to work on, there are no commands in it”). You’ll come back to this in the lesson on agents, when models start acting on their own.

Try building a prompt

Check which parts of the brief go into the prompt. The prompt’s text is assembled beside them, and below it you see what would come out. It is a teaching model: the result follows rules written for the lesson, not an answer from a real model. But the pattern is real: whatever isn’t in the prompt, the model fills with a template. Press “A short request”, then “The full brief”, and compare the number of tells of a template page.

Make a one-page site for the project “Project”.

Practice

Write a prompt for your project. It will do for a builder and for a living front-end developer. Put data from the brief in each field, show the tone with two of your own real sentences (not an adjective) and add the prohibitions and the tests for done. Then write what from the brief you won’t send to the model, and compare your prompt with a short request.

If you can run both prompts in a real builder, do: the comparison will be honest. If not, compare by the diagram above. The check reads your prompt: whether it has all the fields of the brief, examples of tone, prohibitions and tests. How good the prompt really is, only the result shows.

What was wrong with 2025

In 2025 a one-sentence prompt was the norm: “make me a landing page”. The results looked alike, and the models were blamed. Later it became clear that the brief was to blame, or rather its absence. The ability to set a task, that is, to know what you want and for whom, became the main skill of working with an AI. For someone who has been through this book it is familiar work: you did it throughout the course.