A prompt is the only real interface for controlling what a model does, there's no separate settings panel for "be more careful with dates" or "always respond in JSON." Everything the model needs to know about the task has to arrive as text, and how that text is structured matters as much as what it says.
Learning Objectives
- Explain the difference between a system instruction and a user message.
- Turn a vague request into a well-specified one.
- Use a small number of examples to lock in a consistent output format.
How a Request Actually Reaches the Model
System Instructions
sets the rules
User Message
the actual request
Model
Response
The system instruction sets standing behavior for the entire conversation (tone, format, constraints), while the user message is the specific ask. Both are just text handed to the same model, there's no functional wall between them, just a convention both roles are expected to respect.
System vs User: What Each Is Actually For
| System Instructions | User Message | |
|---|---|---|
| Purpose | Standing rules for the whole conversation | The specific request for this turn |
| Changes how often | Rarely, set once per application or session | Every single message |
| Example | "Always respond in valid JSON, no extra text." | "Extract the name and date from this email." |
Specificity Beats Length
"Summarize this."
"Summarize this in exactly 3 bullet points, each under 15 words, focused only on financial figures mentioned in the text."
The second prompt isn't just longer, it removes decisions the model would otherwise have to guess at: how long, what format, what to prioritize. Every ambiguity left unresolved in the prompt gets resolved by the model's own guess instead, which may not match what was actually wanted.
Locking In a Format with Few-Shot Examples
Describing a desired format in words sometimes isn't as reliable as simply showing 2-3 examples of exactly the input-to-output mapping wanted. This is called few-shot prompting, as opposed to zero-shot (just an instruction, no examples).
Instruction
2-3 Examples
input → output pairs
Model
Consistent Format
Convert each name to "Last, First" format. Input: John Smith → Output: Smith, John Input: Maria Garcia → Output: Garcia, Maria Input: Wei Chen → Output:
The model completes the pattern from the examples rather than reinterpreting a written description of the rule each time, which tends to produce more consistent formatting than instructions alone, especially for an unusual or very specific format.
Common Beginner Mistakes
- Writing a longer prompt assuming length alone improves results, when unresolved ambiguity, not brevity, is usually the actual problem.
- Giving contradictory instructions across the system and user messages (e.g. "always be concise" alongside a request that explicitly needs a long, detailed answer).
- Assuming the model remembers something mentioned once, several turns ago, without it still being present in the current context window.
- Describing a desired output format in prose when 2-3 concrete examples would communicate it far more reliably.
FAQ
Should instructions go in the system message or the user message?
Standing rules that should apply to every message in the conversation belong in the system message. The specific task for this particular turn belongs in the user message. Repeating the same standing instruction in every user message works but wastes tokens compared to setting it once.
How many examples does few-shot prompting actually need?
Often just 2-3 well-chosen examples are enough to establish a pattern clearly. More examples cost more tokens on every request; past a certain point, additional examples usually add cost without meaningfully improving consistency.
Is a longer, more detailed prompt always better?
No, only if the added detail actually resolves a genuine ambiguity. Padding a prompt with restated or irrelevant detail adds token cost without improving the result, and can occasionally dilute the actually important instructions.
Interview Questions
What's the practical difference between a system instruction and a user message?
A system instruction sets standing behavior for the whole conversation (tone, format, constraints) and is typically set once. A user message is the specific request for that particular turn, sent fresh every time.
Why does a more specific prompt tend to outperform a longer, vaguer one?
A model resolves any ambiguity left in a prompt by guessing, and that guess may not match what was actually wanted. Specificity removes those decision points from the model's guesswork rather than just adding more words.
What is few-shot prompting, and why might it outperform a written format description?
Providing a small number of concrete input-output example pairs alongside the instruction, rather than only describing the desired format in prose. The model completes the demonstrated pattern directly, which tends to produce more consistent results than reinterpreting a written description each time, especially for unusual formats.
Give an example of contradictory instructions that could confuse a model.
A system instruction saying "always answer in one sentence" combined with a user request asking for a detailed, multi-paragraph explanation. The model has to resolve the conflict itself, and the result is unpredictable rather than reliably following either instruction.
Summary
System instructions set standing rules for a whole conversation, while user messages carry the specific request for each turn. Specificity resolves ambiguity the model would otherwise have to guess at, and a small number of concrete examples often communicates a desired format more reliably than describing it in prose.
What's Next?
That completes LLM Basics. The next section covers RAG in depth, starting with embeddings, the technique that lets a model search by meaning instead of exact wording.