Your boss texts you: "call me."
That's it. No context. No urgency level. No clue what's coming. Your brain immediately runs 500 simulations: got fired, broke prod, deployed on Friday, parents calling about something serious, the cat. You sit there for forty seconds pretending to read Slack while picking a vibe.
Now imagine you're an LLM and someone sends you: "fix this."
Same panic. Same 500-branch decision tree. Same shrug of an answer five seconds later.
A surprising amount of prompt engineering boils down to one line: please stop making everyone guess. The named techniques — zero-shot, few-shot, role, chain — are just five flavors of "here's the context you needed."
1. Zero-shot is the "call me." of prompts.
You wrote three words and hit enter. The model now picks a path from training-distribution priors. It might nail it. It might confidently misread you. You will not know which one until the response is in front of you.
Zero-shot isn't bad. It's the right tool when the task is famous (summarize, translate, classify) and the model has seen ten thousand examples of exactly that shape. It's the wrong tool the moment your task has any flavor — your tone, your schema, your edge case.
2. One-shot and few-shot — show, don't describe.
Telling a model "return clean JSON, no markdown fences, no preamble" works about 70% of the time. Showing it one well-formed example works about 95%. Showing it three works about 99%.
This is the part most people skip because it feels lazy. "I shouldn't have to give examples, the model is smart." The model is smart. Your description of "clean JSON" is still ambiguous. The example is not.
// What most people ship
const prompt = `
Classify this support ticket
as bug, feature, or billing.
Return JSON.
Ticket: "${ticket}"
`;
// returns: ```json
// { "category": "Bug Report" } ```
// (wrong shape, wrong case, fences)// What actually works
const prompt = `
Classify the ticket. Return JSON.
Ticket: "App crashes on login"
{"category":"bug"}
Ticket: "Add dark mode"
{"category":"feature"}
Ticket: "Charged twice"
{"category":"billing"}
Ticket: "${ticket}"
`;
// returns: {"category":"bug"}But examples aren't free.
Every few-shot example is tokens you pay for on every single call. The math gets ugly faster than people expect — especially when you're at scale and someone else is footing the bill.
How much do those few-shot examples actually cost?
3. Role and chain — staging the room before the conversation.
Role prompting is "you are a senior SRE reviewing this incident report." It primes the model to weight different priors — vocabulary, level of detail, what it pushes back on. Doesn't replace good instructions; sharpens them.
Prompt chaining is admitting one prompt can't carry the whole task. Step 1: extract the entities. Step 2: classify each one. Step 3: write the summary using only the classified entities. Each step is small, debuggable, and the model isn't holding ten things in its head at once.
You're building a tool that turns a customer's chaotic Slack message into a clean Jira ticket with the right project, labels, priority, and a tidy summary. Which approach is the best starting point?
So what's the real shape?
Prompt engineering is not a mystical skill. It's removing ambiguity. The named techniques are five different ways to do that:
- Zero-shot — trust the model's priors. Cheap, fast, lossy.
- One-shot / few-shot — show the exact output you want. Expensive but precise.
- Role — set the lens before the question. Free, underused.
- Chaining — break a hard task into small ones with clear handoffs. Slower, debuggable.
Pick by how famous the task is, how much you'll pay per call, and how much you can afford to be wrong.
Which technique do you abuse the most?
The shortest message that ever caused you unnecessary panic is also the prompt you keep sending your LLM. Please call me back. With context this time.
What do you push back on?