Real Prompt Engineering Techniques That Actually Work

Part 10 covered prompt engineering's real, general structure. This part covers specific, genuinely testable techniques — real patterns worth reaching for deliberately, not just general good writing advice.

Few-shot prompting: showing real examples instead of just describing the task

Zero-shot (just an instruction):
  "Classify this customer message as: shipping question, product
  question, or billing question."

Few-shot (instruction + real examples):
  "Classify the customer message. Examples:

  Message: 'When will my order arrive?' → shipping question
  Message: 'Does the Ethiopian roast have caffeine?' → product question
  Message: 'Why was I charged twice?' → billing question

  Message: 'Can I change my delivery address?' → ?"

Few-shot prompting — providing real, concrete input-output examples rather than only a written instruction — genuinely improves consistency for tasks with a specific, real expected output format, since the model has real, direct examples of the exact pattern to follow rather than having to infer the format purely from a description.

Chain-of-thought: asking the model to reason through real steps

Direct: "Should this customer get a refund for a stale delivery?"

Chain-of-thought:
  "Think through this step by step:
  1. What does our real refund policy say about stale product?
  2. Does this specific case meet those real conditions?
  3. Based on that, what's the correct real decision?

  Then give your final answer."

For a task genuinely requiring real, multi-step reasoning — applying a policy to a specific case, rather than simple classification — explicitly prompting the model to work through real intermediate steps before giving a final answer measurably improves accuracy on real, more complex tasks. This works because it directly changes what part 4 called the "so far" context at each generation step — the model's own real, visible reasoning becomes part of the context informing its final answer, rather than jumping straight to a conclusion with no real intermediate work.

Explicit output formatting: real, structured requirements

Vague: "Give me a summary of this customer's order history"

Explicit format:
  "Summarize this order history as JSON with these exact real keys:
  { \"total_orders\": number, \"most_recent_product\": string,
  \"total_spent\": number }"

Explicitly specifying a real output structure — JSON with named fields, a numbered list, a specific real word limit — produces measurably more consistent, machine-parseable output than a vague request, which matters directly the moment a real application (like this series' project) needs to programmatically use the model's output rather than just display raw text to a person.

Negative constraints: telling the model what NOT to do

"Do not mention subscription plans that aren't in the list provided.
Do not guess at a real order status if it isn't included in the
conversation. Do not apologize excessively — one brief acknowledgment
is enough."

Explicit negative constraints are genuinely as useful as positive instructions, especially for correcting a specific, real failure pattern noticed during the testing loop from part 10 — if a model consistently does something unwanted (inventing unavailable information, being overly verbose), directly telling it not to is often more effective than only describing the wanted behavior positively.

A real, complete technique combination

System prompt: role, tone, real constraints (part 11)
+ Few-shot examples: for any classification or formatting task
+ Chain-of-thought: for any real, multi-step decision
+ Explicit output format: whenever the response feeds into more code
+ Negative constraints: addressing specific, observed failure modes

These techniques aren't mutually exclusive alternatives — a real, production prompt (exactly what part 16 through 18 builds) often combines several of them deliberately, each addressing a genuinely different aspect of getting reliable, correct behavior out of the same underlying model.

Next: AI hallucinations — why they happen, directly traced back to part 4's generation mechanism, and real, practical techniques for reducing them.