Prompt Engineering as an FDE Skill

⏱ ~7 min read · 🎧 6 min listen · ✎ 3 quizzes · 🧪 ~30 min lab

Here's the situation this lesson trains you for: the demo works, mostly. The customer's ticket classifier gets it right four times out of five, and the fifth answer is chatty, wrongly formatted, or just wrong. The customer asks "can you make it reliable?" — and the cheapest, fastest lever you own is the prompt. Not folklore, not magic words: a small set of techniques with a mechanical reason for working, applied against test cases.

Why wording works: you're steering a distribution

Remember the machine from Lesson 01: the model turns your input into a probability distribution over next tokens and samples from it. The prompt is the only input. So changing the prompt literally changes the distribution every output token is drawn from.¹ "Prompt engineering" is just the craft of conditioning that distribution on purpose — writing clear instructions, supplying the context the model needs, and arranging both for the best result.²

That mechanism also tells you what prompting can't do. It can't add facts the model never saw (that's grounding — RAG, Lesson 06), and it can't make sampling deterministic (that's a decoding setting). An FDE who knows which failures are prompt-shaped fixes them in minutes instead of proposing a week of engineering.

The five techniques that reliably move the needle

Anthropic's documentation orders its techniques from broadly effective to narrowly effective, and the top of that list is remarkably unglamorous.² These five cover most of what you'll ever need at a customer site.

1. Be clear and direct — write for a brilliant new hire

The single highest-leverage move. Treat the model like a very capable contractor on their first day: state the task, the audience, the constraints, and what "done" looks like. Say what to do rather than what to avoid, and say why — context about the goal measurably improves compliance. Most "the model is dumb" complaints dissolve when the instruction stops being vague.

2. Show, don't tell — use examples (few-shot prompting)

Include two or three worked input→output examples in the prompt and the model imitates their pattern — format, tone, length, edge-case handling. From Lesson 01 you know why: the examples are in the context, so continuations that match the pattern become the most probable tokens. Examples are the most reliable way to pin down output format in particular.¹

3. Fence your data — separate instructions from content with tags

Real prompts mix your instructions with pasted customer content — a ticket, a contract, an email thread. Fence the content in delimiters, e.g. <ticket>…</ticket>, and refer to it by name. Now the model can tell the difference between "text that commands me" and "text I'm operating on" — which is also your first line of defense when a pasted document contains something that looks like an instruction.²

4. Set the frame — system prompts and roles

API calls take a system prompt: standing instructions that frame the whole conversation — "You are a support assistant for Acme; answer only from the provided policy; escalate anything about refunds." Role and framing shift the distribution toward the register you want: terse vs. warm, cautious vs. decisive, domain-expert vs. generalist.

5. Give it room to think — ask for reasoning before the answer

For multi-step problems, prompt the model to work through its reasoning before stating the answer. The mechanism is pure Lesson 01: the model computes with tokens, so intermediate reasoning tokens are literally its scratch space — an answer demanded in the first token gets no computation at all. (Modern "reasoning" modes build this in; the prompt-level version is still the portable skill.)

The real skill: iterate against test cases

Here's what separates an FDE from a prompt hobbyist: treating prompting as an empirical loop, not an incantation. Anthropic's applied-AI team describes the practice as building test cases, finding failure patterns, and encoding the fix back into the prompt — version by version.³ You never ask "is this prompt good?" — you ask "how many of my test cases does version 3 pass that version 2 failed?" Hold that thought; it becomes a whole lesson when we get to evals.

🧪 Lab: upgrade one prompt three times, and measure it

The lab file is labs/0003-prompt-upgrades.py — same setup as Lesson 02 (your ANTHROPIC_API_KEY in the environment, then run it with Python).

The task is real FDE work: extract structured fields from messy customer support tickets. You'll run three versions of the same prompt against the same five tickets: v1 is the vague one-liner most people start with; v2 adds clear, direct instructions and fenced data; v3 adds few-shot examples. A small checker scores every run against expected answers, so you don't vibe the improvement — you watch the pass-rate climb, and see exactly which ticket each version still fails.

You are a senior AI engineer reviewing my work: the output of my prompt-engineering lab (labs/0003-prompt-upgrades.py). My paste includes the pass-rates of three prompt versions on five ticket-extraction test cases, plus my own v4 prompt and its score, and a short note on which technique fixed which failure.

Grade each item as Strong / Adequate / Missing, with one sentence of evidence:
- I can name which of the five techniques (clarity, examples, fenced data, system framing, room to think) each version change applied, and why it moved the score.
- My v4 prompt targets the specific tickets v3 still failed, not a generic rewrite.
- I treated it as an empirical loop: claims are backed by pass-rate changes, not impressions.
- I can say which remaining failures are NOT prompt-shaped (missing facts, sampling randomness) and what lever those need instead.

Be skeptical — challenge my weakest claim first. Then ask me 2–3 follow-up questions a customer would ask before trusting this in production. Finish with the single highest-leverage improvement.

My work follows below.

Check yourself — pick the right technique

Three customer complaints. Don't scroll up — name the technique that fixes each, from the mechanism. Wrong picks stay live.