A good prompt tells the model what you want and gives it enough information to begin. In this video we'll work through a vague request, improve it through questions, and use examples to show the output we need. We'll also look at giving an agent a goal and a check. Each change to a prompt can change the next-token probabilities the model samples from, so make deliberate changes and check whether they helped.
Let's start with a vague request. Write a function to process the data. The request names a task, but leaves most of the behavior unspecified.
What format is the data in? Which fields actually matter? What should happen when the input is malformed? If we leave those questions unanswered, the model may make its own assumptions. Each assumption is a place where the result can differ from what we intended.
You could write the details yourself. For a task with several open decisions, a short conversation may be easier. Ask the model to interview you before writing the code. For example, ask me questions until the requirements are clear, then write the function. You can also ask it to summarize what you agreed before it starts.
Now the very same gaps come back to you as questions. What format is the data in? Which fields matter? What should happen with a malformed line? You answer the questions one at a time. The model helps find gaps, and you decide the behavior you want. Add anything important that it did not ask about.
Once the questions are answered, the request is specific. It names the function, its argument, and its return type, and it states the exact behavior we want. Read the file as JSONL, and skip any line that doesn't parse. The model has not become smarter. We have removed guesses about the function's type, scope, and behavior before it starts. We can now check the code against those decisions.
Imagine handing the prompt to a colleague. If they would need to ask about the inputs, output, or constraints, the model needs that information too. You can supply it directly or work it out through questions. Ambiguity is one common cause of unwanted results. When the model does the wrong thing, check what the prompt left open, as well as whether the implementation is correct.
The first example was one function, and the open questions were about its behavior. A task for an agent needs two more things. Consider the request, "Improve the code." It does not say what better means, so the agent has to guess. It also gives no way to tell when the work is done.
Now compare that to this. Login fails when the email has capital letters. Add a test that reproduces the bug, and then fix it. This names the problem and a concrete check. A test that fails before the fix and passes afterward is evidence that the change addresses the bug.
This request leaves the implementation details to the agent. It does not prescribe a line-by-line edit. Instead, you give it the goal, together with a way to tell whether it worked.
Include any constraints it needs to respect. If a particular approach is required, say so and explain why.
Now consider a small task that has nothing to do with code. We want the model to label the sentiment of restaurant reviews. A request with no worked examples is called zero-shot prompting. You describe the task and the format you want in words.
Few-shot prompting means we first add a few worked examples. Each one pairs a review with its label. "Best pasta in town" is positive. "Cold soup, rude waiter" is negative. "Great food, but a long wait" is mixed. We are not teaching the model what sentiment is. It already knows that from its training. The examples show the labels we use, including mixed, and that the answer is a single word.
Without examples, the model may answer in a full sentence, and it may lean toward positive or negative. The answer can be sensible and still not be one of our labels. With the examples, the reply is the single word "mixed." It follows the pattern we supplied.
Examples show the model what a suitable answer looks like. Here they demonstrate the labels and the format. Start with a few representative examples. Three to five is a reasonable starting point, and then you can test whether more are useful. Examples can also clarify the task or show how to handle an unusual case. Choose them for what the model needs to learn from this prompt.
A few writing habits make the task easier to understand. First, say what you want the model to produce. Write prose is more specific than don't use markdown, which still leaves several possible formats.
Second, give the reason when it helps explain the requirement. For example, say that the text will be read aloud by text-to-speech. The reason helps the model make a sensible call in the related cases you didn't think to spell out explicitly.
Third, make the requested action clear. Change X asks for an edit. Suggest a change to X asks for advice. Use the one you mean. Politeness is fine. The point is to make clear whether the agent should act, explain, or wait for your decision.
Fourth, ask for structure when you need it. If you want the output as tags, or as JSON, or in some particular schema, say so explicitly in the prompt. Structured output is far easier for the rest of your program to consume, and far easier for you to check.
Fifth, ask the agent to run the relevant checks before reporting that it is done. For a code change, that may mean tests or a type-checker. Look at the results, including anything it could not run.
Sixth, if a detailed prompt feels like too much typing, say it instead. Claude Code has voice dictation for this. Type slash voice to turn it on, then hold the space bar while you talk. Codex offers dictation in its desktop app, but not in its terminal version. Speaking takes far less effort than typing, so you will find it easier to give longer and more detailed prompts.
You can use these habits together: state the task, explain relevant constraints, show the format, and ask for checks. Keep the parts that help on your project.
See you in the next video.