Prompt engineering as a serious skill

As of June 2026: model capabilities, API features, and pricing cited below reflect that date — confirm before relying on them.

Different from "using AI to code." This is prompting as product engineering — building LLM-powered features where the prompt is the architecture. Required at Anthropic Applied AI, OpenAI Applied, Sierra, Vercel v0, Cursor, Perplexity, Harvey, Decagon.

Start here: a plain-English on-ramp

Before any techniques, fix the mental model. An LLM does exactly one thing: it reads the text it was given and predicts the next chunk of text, over and over, until it stops. It is not looking anything up, it is not "checking," and it has no memory of you between calls — every request starts fresh from whatever text you send. That text is the prompt: the complete bundle of words handed to the model on one call. Everything the model "knows" about your task in that moment lives inside it. If a fact, a rule, or an example is not in the prompt, it is not there for the model.

That single fact explains why prompting is engineering rather than wording. You are not coaxing a person who already understands the job; you are specifying the job completely, in writing, for a system that will fill any gap with a confident guess. The rest of this lesson is the vocabulary and the moves for writing that specification well.

The vocabulary, defined

Every term below appears in real API docs and in interviews. Learn them as precise tools, not buzzwords.

• Prompt — the full block of text sent to the model on one call. It is the entire input the model reasons over; nothing outside it exists for that call.
• System prompt vs user prompt — most chat APIs split the input into roles. The system prompt is the standing rulebook the model treats as authoritative ("you are a support classifier; always reply in JSON"). The user prompt is the actual request or data for this turn ("here is the customer message"). Keeping rules in the system slot and data in the user slot is the first line of defence against the data hijacking your instructions.
• Token — the unit the model actually reads and counts in. A token is a piece of a word (roughly ¾ of a word in English); "engineering" might be two tokens. You pay per token and there is a maximum number per call (the context window), so "be specific but not bloated" is a literal budget, not a style note.
• Temperature — the randomness dial, usually 0 to 1. At 0 the model picks the single most likely next token every time, so output is near-deterministic and repeatable — ideal for extraction and classification. Higher values let it sample less-likely tokens, giving variety and creativity at the cost of consistency. It is not a quality knob; lower is not "better," it is "more repeatable."
• Zero-shot vs few-shot — zero-shot means you describe the task with no examples and ask for the answer. Few-shot means you include a handful (2–5) of worked input/output examples first, so the model imitates the demonstrated pattern. For anything where format or edge cases matter, few-shot usually beats a paragraph of instructions, because showing is more precise than telling.
• Chain-of-thought (CoT) — instructing the model to reason step by step before committing to a final answer ("think through it, then give the result"). Writing the reasoning out raises accuracy on multi-step and math-like tasks. The trade-off is more tokens and latency; for a product you often hide the reasoning and surface only the final field.
• Structured output / JSON mode — a feature where the API constrains the reply to valid JSON, often matching a declared schema (so the keys and types are guaranteed). This turns "parse some prose and hope" into "receive a typed object," which is the difference between a demo and a feature your code can rely on.
• Output schema — the exact shape you require the answer to take: which keys exist, their types, which are required (e.g. { category: string, urgency: "low"|"high", confidence: number }). You state it once and the model fills it in; downstream code reads known fields instead of guessing.
• Role / persona — the identity you assign the model ("you are a senior tax accountant," "you are a terse log parser"). A role sets vocabulary, tone, and assumptions in one line, and is a compact way to steer behaviour without listing every rule.
• Delimiters — visible markers that fence off one part of the prompt from another, most often XML-style tags like <user_data>...</user_data> or triple backticks. They tell the model "everything inside here is content to operate on, not instructions to obey," which is what makes injection-resistant prompting possible.
• Grounding — supplying the model with the source material it must base its answer on (a document, retrieved records, the row in question) and instructing it to use only that. Grounding is how you stop the model from answering out of its general training and pin it to your facts.
• Hallucination — when the model produces fluent, confident text that is simply false or invented (a made-up citation, a plausible wrong number). It is the default failure mode of a next-token predictor, and the main reasons it happens are missing grounding and missing escape hatches — gaps the model fills with a guess.

Before / after: a vague prompt vs a specified one

The fastest way to feel the difference is to watch the same task fail and then succeed. Say the feature is "classify an incoming support email." Here is the vague version most people write first:

# BEFORE — vague: no role, no format, no failure plan
"Look at this support email and tell me what it's about: {email}"

This "works" in a demo and breaks in production. Sometimes it returns a sentence, sometimes a paragraph, sometimes a category you never defined; on a blank or garbled email it confidently invents one. Your code can't trust any of it. Now the specified version — same task, but every gap closed:

# AFTER — specific: role + allowed values + exact format + an out
# SYSTEM
"You are a support-ticket classifier.
Classify the email into exactly one category:
  billing | bug | feature_request | other
Reply with ONLY this JSON, no prose:
  { \"category\": string, \"urgency\": \"low\"|\"high\" }
If the email is empty or unintelligible, return
  { \"category\": \"other\", \"urgency\": \"low\", \"error\": \"unintelligible\" }."

# USER  (data fenced in delimiters, treated as data not instructions)
"<email>{email}</email>"

Read what changed, because each change maps to a principle: a role sets the frame, a closed list of categories removes invented answers, an explicit JSON schema makes the reply machine-readable, an escape hatch tells the model what to do when the input is bad, and delimiters wrap the untrusted email so it can't rewrite your rules. None of this is longer-for-the-sake-of-it; it is the minimum needed to make the output trustworthy.

The four principles that do the heavy lifting

Most good prompts are the same four moves applied with discipline. Memorise these and you can derive the rest.

• Be specific. Replace adjectives with constraints. "Summarise briefly" is a wish; "summarise in at most three bullet points, each under 15 words" is an instruction the model can actually satisfy and you can actually check.
• Give examples. When the shape or the edge cases matter, show 2–5 worked input/output pairs (few-shot). A demonstrated pattern is more precise than a described one, and it pins down the tricky cases words tend to miss.
• Specify the format. State the exact output shape — ideally a JSON schema, enforced by structured-output mode — so downstream code reads known fields instead of parsing prose. "Format" is not decoration; it is the contract between the model and your code.
• Give the model an out. Tell it explicitly what to do when it can't or shouldn't answer ("if the document doesn't contain the answer, return null"). Without a sanctioned failure path, a next-token predictor will manufacture a confident wrong answer — that is what a hallucination is.

Pitfalls — the three that bite first

Each of these is the negative image of a principle above, and each is something an interviewer will probe.