Prompt Engineering

A prompt is the instruction you give a large language model (LLM). The model reads your text and predicts a helpful continuation. The whole skill of prompt engineering is shaping that text so the output is reliably useful — not left to luck. Press Run below to send your first prompt to a live model (Llama 3.3 70B) and see what comes back:

It works — but a bare instruction leaves a lot to chance. Strong prompts usually contain four ingredients:

Watch what those ingredients do. Run both prompts below and compare the two responses side by side — same task, wildly different usefulness:

The single biggest upgrade to any prompt is specificity. Vague prompts force the model to guess your intent — and it guesses average. Every constraint you add removes a whole class of wrong answers. Run this vague prompt first:

Notice how generic that is. Now pin down the audience, the goal, the count, and the format. Run the sharpened version and compare:

Constraints also include what to exclude. Telling the model what not to do (“no jargon”, “don't mention price”, “avoid clichés”) is often as powerful as telling it what to do. Try editing the prompt below to add one exclusion, then Run:

Assigning the model a role (“You are a senior tax accountant…”) primes it to draw on the right vocabulary, assumptions, and standards. It's the fastest way to shift both the content and the tone of an answer. The same question, three roles — run each and feel the difference:

Roles are even more powerful as a system prompt — a persistent instruction that frames every reply. Below, the role lives in the (hidden) system prompt; the user message is just the question. Run it, then imagine reusing that same system prompt across a whole app:

Compare a generic role with a rich, specific persona — specificity beats a bare job title:

Sometimes the easiest way to describe what you want is to show it. Few-shot prompting means including a handful of input→output examples so the model infers the exact pattern, format, and tone. Zero examples is “zero-shot”; a few is “few-shot”. Run this classifier that learns purely from three examples:

The model matched the label and the format from the examples alone — no rules needed. Few-shot shines when the format is fiddly. Compare describing a format in words vs. just showing one example:

When an LLM feeds another system — code, a database, a spreadsheet — you need output in a predictable shape, not prose. Ask for it explicitly. Run this to get clean JSON you could parse in one line of code:

Two techniques do the heavy lifting here. Delimiters (triple quotes, XML-style tags, or ###) fence off the input so the model can't confuse instructions with data. And an explicit schema tells it exactly which fields to emit. Run this — the delimiters keep the customer's text from hijacking your instructions:

That fence is also your first taste of defending against prompt injection: the customer text tried to hijack the instruction, but fencing + a clear task kept the model on track. Compare a loose format request with a rigid, machine-ready one:

For anything involving logic, math, or multiple steps, models are far more accurate when you let them think step by step before answering. This is chain-of-thought (CoT) prompting. Run this word problem — the instruction to reason first is doing real work:

The magic phrase is literally “let's think step by step.” Compare demanding an instant answer vs. inviting reasoning — on a tricky question the difference in accuracy is stark:

Complex jobs get more reliable when you break them into a chain of smaller prompts, feeding each output into the next — instead of asking for everything at once. Each step is simpler, easier to check, and easier to fix. Imagine turning a raw customer review into a public reply in three steps.

Step 1 — extract. Pull the structured facts out of messy text:

Step 2 — draft. In a real app you'd paste Step 1's output here; then ask for a reply that addresses each point:

Step 3 — refine. Polish tone/length as a separate pass. Splitting the work means when the reply is too long, you only re-run this step. Compare doing it all in one mega-prompt vs. the focused final step:

A prompt isn't “done” when it works once — it's done when it works reliably across many inputs. Prompt engineering is a loop: draft → test on varied cases → spot failures → tighten the prompt → repeat. The mindset that separates hobbyists from pros is testing on the hard cases, not the easy one you had in mind.

The most important failure to guard against is hallucination — confident, made-up answers. Run this: without a safety valve, the model may invent a policy that doesn't exist:

The two anti-hallucination moves: ground the model in provided facts, and give it an escape hatch (“say you don't know”). Compare a prompt that invites guessing with one that forbids it: