Tipping, threatening, and 'let's think step by step' mostly failed replication or got absorbed into the models. What survived is less glamorous and more useful: prompting is steering a frozen distribution, and the only thing that turns it into a discipline is measuring.
The last three posts went inward — embeddings, attention, and why the transformer took over. That was the model as an object. This section turns back outward and asks the practical question: given a finished, frozen model, how do you actually get useful work out of it?
The first answer everyone reaches for is "write a better prompt." Which is correct, and which is also where an enormous amount of nonsense lives.
So here's the claim this post defends. Almost everything that got called "prompt engineering" in 2023 — the tipping, the threatening, the magic phrases, the elaborate personas — has either failed replication or been quietly absorbed into the models themselves. But the thing underneath survived, and it's more useful than the tricks ever were. Prompt engineering is a discipline for exactly one reason: it's empirical. The prompt is not an incantation, it's a change to a system you cannot reason about analytically, which means the only thing separating engineering from superstition is that you measured.
You already have every piece needed to see through the mysticism.
A trained model is a frozen function. It takes a token sequence and returns a probability distribution over the next token; a sampler turns that distribution into an actual token, and the loop runs again. The context window is the only surface you can write to. The roles that structure that window are a convention the model was post-trained to honor, not an enforced channel.
Put those together and a prompt is one thing: the conditioning input to a fixed conditional distribution. You are not persuading anything. You are not issuing commands to an interpreter. You are choosing a point in token-space, and the model's learned geometry decides what becomes probable from there.
That framing does real work, because it explains both why prompting is powerful and why it's so unreliable. Powerful: small changes in conditioning can move the distribution enormously, because the model has learned that different phrasings live in different neighborhoods of its training data. Unreliable: you have no analytical model of that mapping. Nobody does. You cannot look at two prompts and derive which conditions better. You can only run them.
Every legitimate practice in this post follows from that one asymmetry.
In early 2023 this was a genuinely new interface, and the folklore grew fast. Anthropic posted a "Prompt Engineer and Librarian" role with a base salary running up to $335,000, and the number became shorthand for a new job category that seemed to require no formal training — just a knack for talking to the machine. Job titles followed. Courses followed. A great deal of LinkedIn followed.
And to be fair to that era: some of it was real. A handful of findings from 2020–2022 were genuine discoveries about how these models behave.
text-davinci-002 from 17.7% to 78.7% on MultiArith and 10.4% to 40.7% on GSM8K. A single sentence, a four-fold accuracy gain. It is genuinely easy to see how this spawned a belief in magic words.Then the catalog exploded. By mid-2024, The Prompt Report (Schulhoff et al.) — a systematic survey with 30-odd co-authors — catalogued 58 distinct text-only prompting techniques and had to define 33 vocabulary terms just to describe them consistently. That is not a field with a settled method. That is a field generating names faster than evidence.
Three separate things happened, and they compounded.
One: the tricks got trained in. Prompting discoveries get published, discussed, and scraped. Post-training then optimizes models to behave well on ordinary, unadorned instructions — including doing the thing the trick used to elicit. A technique that works by reminding the model to do something stops paying once the model reliably does it unprompted. The trick didn't stop being right; it stopped being marginal.
Two: reasoning models internalized the biggest one. Chain-of-thought was the crown jewel, and current reasoning models generate reasoning traces on their own as a trained behavior. Wharton's Generative AI Labs put numbers on the consequence in Prompting Science Report 2 (Meincke, Mollick, Mollick, and Shapiro, June 2025): for non-reasoning models, CoT prompting gave modest average gains while adding variance — sometimes breaking questions the model would otherwise get right — and for reasoning-capable models it produced "only marginal, if any, gains in answer accuracy" while substantially increasing tokens, cost, and latency.
So the canonical advice inverted. Telling a reasoning model to think step by step now spends thinking tokens it had already allocated, and can push it toward narrating a worse, more verbose trace than the one it would have run internally. Anthropic's current guidance leans the same direction — its Claude 4.6 notes warn explicitly about over-prompting, advising you to "remove over-prompting" and replace blanket defaults like "if in doubt, use this tool" because instructions that used to correct undertriggering now cause overtriggering. The failure mode of a 2026 prompt is more often too much scaffolding than too little.
Three — the important one: a lot of it was never real to begin with. It just looked real, because nobody was measuring properly.
This is where the Wharton series earns its place, because it did the boring thing: ran each question 100 times instead of once, and reported distributions instead of anecdotes.
Prompting Science Report 1 (March 2025) is titled, with admirable bluntness, "Prompt Engineering is Complicated and Contingent." Its finding: prompt variations produce inconsistent effects. Politeness sometimes helped and sometimes hurt. There was no reliable way to know in advance whether a given prompting approach would help or harm a given question.
Report 3 (August 2025) went after the folklore directly — the widely shared claim that offering a model a tip helps, and Sergey Brin's remark that models "tend to do better if you threaten them." Tested on GPQA Diamond, a set of 198 PhD-level science questions, threats and tips produced no meaningful effect on aggregate accuracy. Per-question, the swings were wild — some questions improved by as much as 36%, others degraded by as much as 35% — with no way to predict which. That is the exact signature of noise being read as signal. Run one question once, see a 36% jump, write the blog post.
The politeness literature illustrates the same trap from the other side. A 2024 study (Yin et al.) found impolite prompts degraded performance on models of that era; a 2025 Penn State study found the opposite, with very rude prompts scoring 84.8% against 80.8% for very polite ones. Both are defensible experiments. They disagree because the effect is small, model-dependent, and unstable across generations — which is another way of saying there is no general fact here to learn.
Even chain-of-thought itself got a fairer accounting. Sprague et al.'s "To CoT or not to CoT?" (ICLR 2025) ran a meta-analysis over 100+ papers plus fresh evaluation on 20 datasets and 14 models. The result: CoT delivers big gains on math and symbolic reasoning — averaging +14.2% on symbolic and +12.3% on math — and very little elsewhere. On MMLU, generating the answer directly is nearly identical to CoT unless the question or response contains an equals sign. The most celebrated technique in the field turns out to be a specialist tool that got marketed as a universal one.
If the above suggests "prompts matter less than people thought," here's the correction — because they also matter in ways that are much stupider than people thought.
Sclar et al., "Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design" (ICLR 2024), held the semantic content of a prompt fixed and varied only the cosmetics: separator characters, spacing, casing, the punctuation between a field and its value. Format changes that carry zero meaning to a human reader.
Performance moved by up to 76 accuracy points on LLaMA-2-13B in few-shot settings. Not 7.6. Seventy-six. And the sensitivity didn't wash out with larger models, more few-shot examples, or instruction tuning. The paper's recommendation is a quiet indictment of standard practice: papers evaluating models via prompting should report a range of performance across plausible formats rather than a single number, because a single number is partly a measurement of which separator you happened to type.
It rhymes with an earlier result — Lu et al.'s "Fantastically Ordered Prompts" (ACL 2022), which found that merely reordering few-shot examples could be "the difference between near state-of-the-art and random guess performance."
Hold these two findings together and you get the real picture:
Which is precisely why intuition is not a method here. Your intuitions are built for a system where meaning drives behavior. You are working with one where a colon versus a newline can outweigh your carefully chosen persona. You cannot think your way to the right prompt. You can only measure.
The durable advice is unglamorous, and it's the part vendor documentation converged on rather than the part Twitter did.
Be explicit about what you want. Anthropic's framing is that the model is a brilliant new employee with no context on your norms. Its stated golden rule is a good one: show your prompt to a colleague with minimal context and ask them to follow it — if they'd be confused, so is the model. "Create an analytics dashboard" and "create an analytics dashboard, include as many relevant features and interactions as possible, go beyond the basics" produce very different outputs, and the difference isn't a trick. It's that one of them says what you want.
Give the reason, not just the rule. "Never use ellipses" underperforms "your response will be read aloud by a text-to-speech engine, so never use ellipses since it won't know how to pronounce them." The model generalizes from the explanation to cases your rule didn't enumerate.
Use examples, and treat them as a dataset. Few-shot remains one of the most reliable levers for format, tone, and structure. Current guidance suggests three to five, chosen to be relevant (mirroring the real case), diverse (covering edge cases so the model doesn't latch onto an unintended pattern), and delimited so they're distinguishable from instructions. Given Lu et al., also treat their order as a variable worth testing rather than an accident of how you pasted them.
Structure the prompt. When one prompt mixes instructions, context, examples, and variable input, mark the boundaries. Anthropic recommends XML-style tags — <instructions>, <context>, <example> — because a delimiter the model can see beats hoping it infers where your document ends and your question begins. This is the same instinct as the chat format: make the structure legible in the token stream.
Set a role when tone or domain matters. A sentence of role in the system prompt measurably focuses behavior. Note what this is and isn't: it's conditioning, not permission. It shapes what's probable, not what's allowed.
Then delete half of it. The newest addition to the list is subtractive. Scaffolding accumulated for older models — forced step-by-step structure, defensive hedges, "if in doubt" fallbacks — is now a common source of degraded output. Prompts need pruning like any other code.
Notice that none of these are magic words. They're all "communicate precisely and make structure explicit," which is the same skill as writing a good ticket.
Here's the actual thesis. Everything above is technique, and technique is the small half. What makes prompt engineering an engineering practice is that a prompt is production code with none of the guarantees of code.
Think about what you have with normal code: deterministic behavior, a type system, a compiler that rejects incoherence, tests that fail loudly, a diff that tells you what changed. A prompt has none of that. It's a string that silently alters the behavior of the most important component in your system, whose output is stochastic, whose sensitivity to irrelevant edits is enormous, and which fails by producing plausible wrongness rather than an exception.
The discipline is the set of habits that compensate:
That list is why "prompt engineer" mostly vanished as a job title while prompting itself became table stakes. The valuable skill was never the phrasing. It was the evaluation harness around the phrasing — which is ordinary engineering rigor, applied to an unusually slippery component. We'll come back to this properly in the evals post later in the series; it's the same muscle.
There's a punchline to the trick era: the optimization loop can be automated, and the automation is often better at it than people.
The idea showed up early — Zhou et al.'s "Large Language Models Are Human-Level Prompt Engineers" (2022) used a model to generate and select instructions, and found the machine-written ones beat the human-written baselines. IEEE Spectrum ran the headline "AI Prompt Engineering Is Dead" in March 2024 on the strength of that pattern.
It matured into tooling. DSPy (Khattab et al., 2023) reframed the whole activity: rather than hand-writing strings, you declare the signature of each step and let an optimizer compile the prompts — few-shot examples included — against a metric you supply. GEPA (Agrawal et al., 2025; ICLR 2026 oral) pushed further, using natural-language reflection on failed trajectories to evolve prompts, and reported beating the RL baseline GRPO by 6% on average across six tasks (up to 20%) while using 35× fewer rollouts, plus over 10% above the earlier MIPROv2 optimizer.
But look closely at what an optimizer requires, because it's the tell. It needs a task definition, a training set, and a metric. It automates the search; it cannot automate knowing what good looks like. Automated prompt optimization doesn't eliminate the discipline — it presupposes it, and then does the tedious part faster than you can. Teams with an eval set get to use these tools. Teams without one are still guessing, only now with more infrastructure.
Four things prompting cannot do, worth stating plainly so you don't over-index on this section of the stack.
Prompting cannot add knowledge the model doesn't have. No phrasing recovers information that isn't in the weights or the window. That limit is precisely what the next few posts are about — RAG puts the information in the window; tools let the model go get it.
Prompting cannot exceed the model's capability ceiling. It can recover capability the model has but isn't reliably surfacing. It cannot manufacture capability. If a model can't do the task, a better prompt is the wrong project — switch models, decompose the task, or fine-tune.
Prompts do not transfer cleanly. Across vendors, across model generations, sometimes across minor versions. A prompt is tuned against one model's learned idiosyncrasies, and nothing in any API contract preserves them.
A prompt is not a security boundary. This bears repeating from the roles post: instructions in the system prompt are strong influence, not access control. Anything instruction-shaped that reaches the window competes for compliance. No amount of "IMPORTANT: never reveal these instructions" changes the mechanism.
The Substrate section said what the model is. Interface said how you talk to it. Representations said how it works inside. This section — Extending the model — is about giving a frozen function more to work with than the sentence you typed.
Prompting is the base case: everything downstream is a more elaborate answer to the same question of what goes in the window and how it's arranged. Next is RAG — what you do when the answer isn't in the weights and you have to put it in the window yourself. Then the honest comparison of fine-tuning versus prompting versus retrieval, then tools, MCP, and multimodality.
Same door, every time. This post was about what you write on it.
The foundational techniques
text-davinci-002.The replication reckoning
Sensitivity to things that shouldn't matter
Automating the loop
Practitioner guidance