Prompt engineering designs the input the model sees at inference time; the model's weights stay frozen across every call.
Imagine a librarian who has read every book in the library and can answer any question. You cannot change what they have read; that knowledge is locked in. But you CAN change how you ask: 'in three sentences, like you would explain to a child, and please cite the books.' The librarian (the model weights) is unchanged. The way you asked (the prompt) is the only thing that moved between a useless answer and a perfect one. Prompt engineering is the practice of asking well.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Prompt engineering has a one sentence definition that hides a precise architectural claim: the model is the function, the prompt is the argument, and you only get to change the argument.
This flashcard tests whether the candidate can name that boundary cleanly. The good answer says two things in the same breath. First, what the prompt covers: instructions, format, examples, constraints, context. Second, what it does not cover: the trained weights. Both halves matter equally, and the rest of the deep dive walks through why.
What the input actually contains
In any real production call, the 'prompt' is a structured bundle, not just the user question. The system message carries the persistent instructions: tone, refusal rules, output schema, role. The user message carries the task and any inline context. Modern APIs also let you pass tool definitions, response format schemas, and per call config (temperature, max tokens, stop sequences).
All of those live in the request payload. None of them touches the model.
When you add few-shot examples, you are extending the context the model sees. The model attends over those example tokens the same way it attends over the user question; nothing is special about 'examples' to the architecture. They are just tokens earlier in the sequence. The same is true of retrieved context from a RAG step. The retriever finds the right chunks, and the prompt assembles them into a section the model reads. From the model's perspective the line between 'instruction you wrote' and 'snippet the retriever pulled' does not exist.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Anthropic Workbench is a dedicated prompt engineering surface; you iterate on the system prompt and few-shot examples while Claude Opus 4.7 stays untouched.
- Cursor and GitHub Copilot rewrite the prompt every keystroke (current file + neighboring files + your cursor context) against a fixed code model.
What an interviewer would ask next. Try answering before peeking at the approach.
QIf the weights never change, why does adding a single example to the prompt sometimes flip the output completely?
Frame as conditional probability. The example shifts which region of the next-token distribution gets mass. Mention attention over the example tokens and the in-context learning literature without claiming any weights moved.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Saying 'I prompt-engineered the model to be better at math' as if the model itself changed. The model is identical; only the input around it changed.
60 second bullets to scan on the way to the call.
What the prompt is, in one sentence
What the prompt explicitly does not touch
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.