Prompting & Context Engineering

⏱ ~9 min read · 🎧 9 min listen · ✎ 3 quizzes · 🧪 ~60 min lab

Anthropic's FDE posting doesn't ask for "experience writing prompts" — it asks for production LLM experience including "advanced prompt engineering".⁶ The word doing the work is production. A prompt that works in a playground is a vibe; a prompt that runs ten thousand times a day against a customer's messy data, produces output their billing system can parse, and fails loudly instead of hallucinating quietly — that's an engineering artifact. This lesson gives you the two mental models behind that difference: the prompt as a specification, and the context window as a finite budget.

System prompts are specs, not vibes

Most engineers write system prompts the way they'd brief a smart intern in a hallway: "you're a helpful medical summarizer, be accurate and concise." That's a vibe. A specification, by contrast, defines the things you'd define in any API contract: the role and its boundaries, the exact input it will receive, the exact output shape it must produce, how to behave on malformed or missing input, and what it must never do. Anthropic's own prompt engineering guidance is a checklist of spec disciplines — be explicit and direct, use examples, give Claude a way out ("say you don't know"), structure with XML tags, define output format precisely.² The techniques are public; what separates an FDE is treating them as contract-writing, not decoration.

The spec mindset extends to the output side as structured outputs: instead of asking nicely for JSON and regex-ing the response, you define a schema and the API constrains generation to it — the Claude API's output_config.format accepts a JSON schema and guarantees parseable output.² For customer systems this is the difference between a demo and an integration: downstream code can consume the model's output like any other service response. OpenAI's guidance converges on the same disciplines — clear instructions, reference text, structured decomposition — which tells you this is engineering practice, not vendor folklore.⁴

The context window is a budget, not a bucket

Current Claude models take up to a million tokens of context.³ The trap is treating that as a bucket to fill. Anthropic's engineering guidance is blunt: context is a finite resource with diminishing marginal returns, and the goal is to find the "smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."¹ Every token you spend on boilerplate, stale history, or twelve tool definitions the task doesn't need is budget not available for the customer's actual data — and worse, it actively degrades the answer.

That degradation has a name: context rot. As the number of tokens in the window grows, the model's ability to accurately recall and use any given piece of it decreases — attention gets stretched thinner across more content.¹ The practical countermeasures are budget management: compaction (summarize older history and continue with the summary), structured note-taking outside the window, and curating which tools and documents are in view at all — the Claude API now does compaction server-side when conversations approach the limit.¹³

This is why the field moved from prompt engineering to context engineering — not a rebrand, a superset. Prompt engineering asks "what do I say?"; context engineering asks "what is the full set of tokens the model sees — instructions, retrieved documents, tool definitions, history — and is every one of them earning its place?" Anthropic frames prompt engineering as a subset of this larger discipline, and it's the discipline that matters most for agents that loop over many turns.¹ You'll feel this concretely in Lesson 03, where every tool definition you register is context you've spent.

When prompting beats fine-tuning

Customers ask for fine-tuning constantly — it sounds like "training the AI on our data," which sounds like moats. Your default answer should be the vendor's own: try prompting first. Prompt iteration is far faster than fine-tuning (minutes, not training runs plus data pipelines), needs a few dozen good examples instead of thousands of labeled ones, preserves the model's general knowledge instead of risking catastrophic forgetting, is transparent and debuggable in plain text, and survives model upgrades — you re-run your checks, not your training job.² Fine-tuning earns its complexity in narrow cases: a style or format that survives every prompting attempt, or latency/cost floors that demand a smaller specialized model. Being the person who says "you don't need fine-tuning, and here's the eval that proves it" is the AI-judgment competency from Lesson 01 — cheaper, faster, and it builds the trust that wins the renewal.

🧪 Practical steps: clinical-note summarizer v1 (~60 min)

Meet the course's customer: a fictional Australian virtual-care provider — telehealth consults, triage chat, clinical notes, claims. Over the next nine lessons you'll build them a real system, culminating in the Lesson 11 capstone. Today: a clinical-note summarizer whose system prompt is a spec and whose output is schema-shaped. You'll also get a first taste of a real FDE skill — synthetic data — because in a regulated domain nobody hands you patient records in week one. Full instructions and a starter script are in labs/0002-clinical-note-summarizer.md; the short version:

1. Set up — create D:\Projects\FDE-Portfolio\l02-summarizer\; pip install anthropic; ANTHROPIC_API_KEY set.
2. Generate 3 synthetic telehealth transcripts with Claude — GP-style video consults with Australian texture (Medicare, GP referrals, local medication brands), each seeded with specific facts: medications with doses, symptoms, a follow-up plan.
3. Write the system prompt as a spec — role and boundaries, input description, SOAP-style sections (Subjective, Objective, Assessment, Plan) as a JSON schema via structured outputs, and an explicit escape hatch: "not documented" for anything the transcript doesn't state.
4. Write 5 hand-written checks per transcript in plain Python — must-include facts (the dose that was mentioned) and must-NOT-include facts (the diagnosis that never was). No frameworks yet.
5. Run, fail, iterate the prompt until all checks pass on all three transcripts — and keep notes on which spec line fixed which failure.
6. Save everything — code, prompt, checks, transcripts, and a short README with your failure notes — to the portfolio folder.

Feedback loop: your hand-written checks are a proto-eval — Lesson 05 upgrades this exact artifact into a proper eval harness, so keep it honest rather than pretty. This artifact (key: l02-summarizer) feeds the Lesson 11 capstone engagement and is tracked in the course's artifact tracker. Bring it to me in chat for a rubric review, or use the box below.

You are a senior Forward Deployed Engineer reviewing my work: a clinical-note summarizer v1 for a fictional Australian virtual-care provider. It includes a system prompt written as a specification, structured SOAP-style JSON output, 3 synthetic telehealth transcripts, 5 hand-written checks per transcript (must-include facts and must-not-include hallucinations), and notes on prompt iterations.

Grade each criterion as Strong / Adequate / Missing, with one sentence of evidence:
- Spec quality of the system prompt: it defines role AND boundaries, describes the input, specifies the exact output schema, and includes an explicit escape hatch for undocumented facts — not just "be accurate".
- Check meaningfulness: the checks would actually catch a dangerous failure (a hallucinated dose, an invented diagnosis), not just confirm the output is valid JSON.
- Honest failure notes: the iteration notes name real failures observed and which specific spec line fixed each — not a story where everything worked first try.

Be skeptical — probe the weakest check first: describe one hallucination my checks would MISS. Then ask 2–3 questions a clinical-safety reviewer would ask. Finish with the single highest-leverage improvement before this gets an eval harness in Lesson 05.

My work follows below.

Check yourself — think like an FDE

Scenarios, not recall. Diagnose from the mental models — spec vs vibes, budget vs bucket. Wrong picks stay live.