Phrasing is the easy half. This module is about what the model can see when it works — which artifacts, which conventions, which examples, and what to deliberately leave out — plus the iteration patterns and reusable prompt assets that turn a good result into a repeatable one.
You already know the basics: assign a role, give examples, specify the format. If you've spent any time with AI tools, you've absorbed prompt engineering's first chapter. This module is the second chapter — the one employers are actually hiring for when postings ask for "prompting, context engineering, agent architectures" in the same breath.
The shift is this: as models got better at inferring intent, the bottleneck moved from how you phrase the instruction to what information the model has when it executes it. Phrasing is prompt engineering. Deciding what the model gets to see — which docs, which examples, which code, which history, and just as critically what it doesn't see — is context engineering, and in 2026 it is the higher-leverage skill. Demand for it is measurable: prompt-engineering skill mentions in job postings grew over 135% year over year in this program's research base, and the phrase "context engineering" now appears verbatim in engineering job descriptions.
A 2026 model rarely fails because your wording was clumsy. It fails because it was missing information you had, drowning in information it didn't need, or free to guess where you should have constrained it. Engineer the context first, the phrasing second.
A professional prompt is a work order with three load-bearing parts. You know them individually; the discipline is never shipping a prompt that's missing one.
Role prompts work, but experienced users under-spec them. The high-leverage move is encoding how to think, not just credentials — and for professional work, the thinking you usually want is skeptical:
Weak: You are an expert Java developer.
Strong: You are a staff engineer reviewing code for a payments
service. You care about idempotency, failure modes, and
observability more than elegance. You flag anything you
would not let ship, and you say "this is fine" when it is.
The last clause matters more than it looks: explicitly authorizing the model to approve reduces invented nitpicks, and explicitly demanding flags reduces sycophantic waving-through. You are tuning the model's disagreement threshold — something a bare role never does.
Constraints are the difference between an answer and your answer: versions and stack ("Python 3.12, no new dependencies"), scope ("modify only this function; do not refactor the callers"), banned moves ("no mocking the database in these tests"), audience and length. Unstated constraints don't default to sensible — they default to the training distribution's average, which is precisely what your codebase and your client are not.
Specify the deliverable's structure like an interface: sections, fields, allowed values, a missing-data rule ("if the log doesn't contain the answer, say NOT FOUND — do not infer"), and a chatter ban ("output only the table"). Contracts do double duty: they make output usable downstream, and they make verification faster — a fixed structure means your eye knows where to look for what's wrong. This is the same idea as structured outputs at the API level, applied at the chat level.
Role, constraints, contract — if a prompt you're about to send is missing one of the three, you haven't finished writing it. Thirty seconds of framing routinely saves three rounds of correction.
A model's context window is its entire working memory for your task. It has read the internet, but it has never seen your codebase, your client's requirements doc, your team's conventions, or last quarter's numbers — unless you put them there. Context engineering is deliberate curation of that window.
Ask: what would a competent new hire need on day one to do this task without asking questions? That's your inclusion list:
AGENTS.md, CLAUDE.md, Copilot instructions) — write one for your project and every agent session starts pre-briefed.Exclusion is the half professionals skip. More context is not monotonically better: irrelevant material dilutes attention, invites the model to "use" what you pasted whether or not it applies, and buries the signal. Leave out the 400-line file when 30 lines are relevant (state that you've excerpted). Leave out three conflicting old drafts. Leave out the long prior conversation — a fresh chat with curated context beats a stale chat with accumulated contradictions. Context is a budget, not a bucket: every token you include is a claim that it matters.
Few-shot examples remain the highest-bandwidth way to communicate format, tone, and edge-case policy — two or three input→output pairs teach what a page of rules can't. One caution from the field: examples override written instructions when they conflict. If your instruction says "concise" and your examples run 300 words, you'll get 300 words. When a few-shot prompt misbehaves, audit the examples before the instructions.
Frontier windows fit hundreds of thousands of tokens, which makes "just paste everything" genuinely viable for a single spec, a substantial log dump, or a handful of files — and for one-off tasks it's the right call: simple, complete, no infrastructure.
It stops being right at scale, for three reasons:
The engineering answer is retrieval — indexing the corpus and fetching only relevant chunks per query — which is RAG, covered properly later in this track. For now, the practitioner's rule of thumb:
| Situation | Strategy |
|---|---|
| One task, material fits comfortably | Paste it all; instruct "answer only from the provided material" |
| One task, material is huge | Excerpt the relevant sections yourself — you are the retrieval step |
| Repeated queries over a stable corpus | Tool with built-in retrieval (assistant "projects"/knowledge features) or a RAG pipeline |
| Corpus changes constantly | Retrieval, always — pasting is stale on arrival |
When you paste reference material, fence it and say what it is: <requirements>, <logs>, <style-guide> (or markdown headers). Labeled blocks let you write instructions that point — "follow <style-guide>; treat <logs> as ground truth" — and measurably reduce the model blending sources it should keep separate.
First outputs are drafts. Professionals differ from casual users not in getting better first outputs (they do, but marginally) — but in what they do next. Two patterns cover most of it.
Never re-roll and hope; make the model attack its own work with a specific adversarial lens, then revise against the critique:
Act as a skeptical SRE reviewing the runbook you just wrote.
Assume the reader is paged at 3 a.m., stressed, on a phone screen.
List every step that is ambiguous, assumes unstated access, or
could make the incident worse if followed literally.
Then rewrite the runbook fixing everything you found.
The lens is the technique: a generic "critique this" yields generic praise-plus-nitpicks; a persona with stakes yields findings. Chain different lenses for important work — correctness pass, then security pass, then audience pass. And run the same trick on your prompts themselves: paste a prompt plus its disappointing output and ask the model to diagnose the prompt. It is startlingly good at spotting the ambiguity you can't see because you know what you meant.
When output quality craters, the task was usually too big for one prompt — too many goals competing in one context. Decompose along inspection points, exactly as you'd decompose an engineering task along interfaces: extract → analyze → draft → critique, where each step's output is reviewed (by you, or by the next prompt's contract) before becoming the next step's input. Errors get caught where they're cheap, at the seams, instead of compounding silently inside a mega-prompt. This is also, not coincidentally, how agent pipelines are architected — decomposition skill transfers directly to the agents module later in this track.
Don't iterate by piling corrections onto a long conversation — "no, shorter… no, without the preamble… no, in Python" accumulates contradictory instructions that keep leaking into output. After two or three corrections, fold everything you've learned into a revised prompt and restart clean. The revised prompt, not the conversation, is the asset.
An iterated prompt that works is engineering output. Throwing it away and re-improvising next week is the single most common waste in professional AI use.
[bracketed slots] for the variable parts, one line on when to use it, and a sample of known-good output (the sample is what lets future-you verify the prompt still works after a model update). Ten curated entries covering your recurring task types — code review, log analysis, doc drafting, meeting-notes-to-actions, test generation — beat a hundred hoarded chat links. Every mature AI tool also has a native home for the standing subset: custom instructions, projects, styles (chat assistants) or repo instruction files (coding agents). Put durable preferences there once; stop re-typing them.Date-stamp library entries with the model/tool they were tested on. Prompts are calibrated against a model's current behavior; after a major model update, re-run your top five against their saved sample outputs before trusting them. Five minutes, quarterly, and it has caught real regressions.
Vendor-neutrality doesn't mean pretending models are interchangeable. Techniques transfer; calibration doesn't quite. Expect differences along these axes when you switch between ChatGPT, Claude, and Gemini — or between model versions from one vendor:
The practical protocol: when you switch models, re-run three prompts from your library against their saved samples. The diff is the calibration you need to learn — and it's why the library carries model annotations.
Assessment questions on model differences test the protocol, not vendor trivia — given "prompt worked on model A, misbehaves on model B," the correct answers are tighten the contract, add an example, and recalibrate against saved outputs; never "model B is worse."
Named failure modes, so you can catch them in your own usage and your team's:
Build three reusable, role-specific prompt assets. Use real work — the point is a library you'll use next week, not a homework artifact. For each: draft → run on a real input → critique-and-revise once → save with slots, usage note, sample output, and model annotation.
Then: re-run exercise 1's prompt on a second model (any vendor's free tier) and note every behavioral difference in the library entry. That note is your first calibration record.