Quick answer: Prompt engineering is the practice of writing the input to a language model so it reliably produces the output you want. It is not magic words or secret incantations; it is clear communication plus structure. The techniques that still matter are precise instructions, worked examples, explicit output structure, role framing, and breaking hard tasks into steps. What newer models made largely obsolete is the elaborate coaxing people once needed (begging, threatening, stacking "you MUST" warnings) to get basic compliance.
What it is, and what it is not
Prompt engineering has a mystique it does not deserve. At its core it is one idea: the model does what your text leads it to do, so write text that leads well. A good prompt states the task, gives the context, shows the format, and sets the constraints. That is it.
What it is not:
- Not a fixed list of trigger words that unlock hidden ability.
- Not a substitute for the model actually having the information (see grounding, below).
- Not a one-time trick. It is iteration: write, observe, adjust.
The best mental model is that you are briefing a fast, capable, literal colleague who has no access to your intentions except through what you wrote. Everything you leave implicit, they will fill in with a guess.
The core techniques
1. Clear, specific instructions
Vague prompts get vague results. "Summarize this" leaves a dozen decisions to the model: how long, for whom, what to include. Specify them.
Summarize the text below in 3 bullet points for a busy executive.
Focus on financial impact. Do not include background history.
The single highest-return habit in prompt engineering is replacing an adjective with a specification. Not "make it short" but "under 50 words." Not "be formal" but "no contractions, third person."
2. Examples (few-shot)
Showing beats telling. If you want a particular format or judgment, include one or two examples of input and the desired output. The model pattern-matches on them far more reliably than on a description.
Classify the sentiment as positive, negative, or neutral.
Review: "Shipping was slow but the product is great." -> positive
Review: "Broke after one day." -> negative
Review: "It arrived on time." ->
Few-shot is especially powerful for structured extraction and for edge cases the model would otherwise handle inconsistently. Positive examples of what you want tend to work better than a list of what to avoid.
3. Explicit output structure
If you need to parse the output, tell the model exactly what shape to return. Ask for JSON, a table, a numbered list. Many modern APIs also support structured-output modes that constrain the response to a schema, which is more reliable than asking in prose. When you can enforce structure at the API level, do that; when you cannot, describe the structure precisely and give an example of it.
4. Role and context framing
Telling the model who it is and who it is writing for sets a useful prior over tone, vocabulary, and depth.
You are a senior tax accountant explaining to a first-time freelancer.
Use plain language. Assume no accounting background.
Role framing is not about tricking the model into being "smarter." It is about narrowing the enormous space of possible responses toward the register you actually want.
5. Decomposition
Hard tasks fail as one giant prompt and succeed as a sequence. Instead of "analyze this contract and draft a response," split it: first extract the key terms, then flag the risky clauses, then draft. Each step is easier to get right, easier to check, and easier to fix when it drifts. For genuinely multi-step work, this is also where tools and agents come in (more below).
A quick reference
| Technique | Use it when | Watch out for |
|---|---|---|
| Specific instructions | Always | Under-specifying format and audience |
| Few-shot examples | Format or judgment must be consistent | Examples that leak the answer or bias toward one class |
| Output structure | You will parse the result | Asking in prose when the API can enforce a schema |
| Role framing | Tone and depth matter | Treating it as a capability unlock; it is a register knob |
| Decomposition | The task is multi-step | Over-splitting trivial tasks into needless calls |
How prompting interacts with tools and retrieval
Prompt engineering stops at the edge of what the model knows. If the answer depends on a current fact or a document the model never saw, no wording will conjure it, and pushing harder just invites a confident guess. That failure mode is why LLMs hallucinate.
The fix is not a better prompt; it is better inputs. Retrieval and tool use put the real material into context, and then prompting takes over: "Answer only from the sources below, and cite each claim." Prompting and grounding are complementary, not competing. The prompt directs; the retrieved content supplies the facts. If your task involves anything the model needs to look up, the highest-leverage move is often tool calling, letting the model fetch what it needs, and then prompting it to use what came back.
In practice that can be as simple as fetching a page to clean markdown and pasting it in:
curl https://link.sc/v1/fetch \
-H "Authorization: Bearer lsc_your_api_key" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com/policy", "format": "markdown"}'
Now your prompt operates on real content instead of the model's foggy memory, and your careful instructions actually have something accurate to shape.
What newer models made obsolete
A lot of old prompt-engineering folklore was really a workaround for weak instruction-following. Recent models follow instructions far more faithfully, which flips several habits:
- Stop shouting. Stacking "CRITICAL: YOU MUST" and "IF YOU FAIL" no longer helps and now often over-triggers. A plain instruction is followed as written. Aggressive language mostly creates overreaction.
- Drop the begging and role-play tricks. You rarely need to pretend the model is an expert to get expert-quality output; ask directly.
- Trust literal reading. Modern models generalize an instruction less and follow it more precisely, so state the scope you mean ("apply this to every section, not just the first").
- Verbosity is tunable, not fixed. Newer models calibrate length to the task; if you want a specific length, say so with a number rather than assuming a default.
What did not become obsolete: clarity, examples, structure, and decomposition. Those are about communication, not about compensating for model limitations, and communication does not go out of date.
The honest summary
Prompt engineering is a real skill, but a modest one. It is not arcane, and it is getting simpler as models improve. Write clearly, show examples, specify the output, split hard tasks, and ground the model in real sources when facts matter. Skip the theatrics. Most bad outputs trace back to a prompt that was vague, unstructured, or asked the model to know something it never learned, and each of those has a plain fix.
Give your prompts real, current web content to work with. Fetch and search any page as clean markdown with link.sc. Start free.