111 AI Prompt Engineering Examples That Actually Move the Needle in 2026

Prompt Engineering: Three Moves, One Honest Record

By Tom Morgan · ~8 min read · Writing, code, data, support & marketing

What v5 changes from v4

v4 was honest about its limits. v5 is honest about its limits and restructured around them:

1. The six moves became three. v4’s taxonomy was a compression device that gradually became the thing itself — a list of named moves presented at equal confidence, which is exactly the “taxonomy worship” the article mocked in its own asides. Three of the moves (scope fence, negative constraint, audience lock) are one move seen from three angles: cap the output’s degrees of freedom. Worked example and verification pass stand on their own. Decomposition is demoted — not because it doesn’t work, but because it’s established engineering practice predating this article, and presenting it as one of “Tom’s moves” was borrowed glory.
2. The record is demoted from evidence to procedure. Details below. The table stays, but it now says what it can and cannot show.
3. The unverifiable number is gone. v4 carried a “~21 percentage points” model-gap figure it told you not to quote. A claim you can’t cite is a rumour with formatting. Removed.

What carries over unchanged: the failure-first loop, the evidence tiers, and the position from page one — prompt wording is one layer of a larger stack (model, retrieval, history, tools), and usually not the biggest one. These moves do one job: single-message output quality. For anything beyond that, the levers are elsewhere — Lilian Weng’s LLM-powered autonomous agents remains the best single map of that larger stack, and Anthropic’s prompt engineering documentation plus OpenAI’s prompt engineering guide are the official references worth bookmarking before any blog post — including this one.

The evidence, ranked by strength

Solid. Microsoft Research’s randomized trial: developers using GitHub Copilot completed a standardized HTTP server task 55.8% faster, 95% CI 21–89% (arXiv:2302.06590). Note the interval: “somewhat faster” and “almost twice as fast” are both defensible readings. The careful claim: the strongest controlled result in this space, with a wide confidence interval. AI assistance plausibly helps; the size of the help is genuinely uncertain.

Solid. Position bias. Liu et al., Stanford/UC Berkeley (arXiv:2307.03172): a U-shaped curve — facts at the start or end of context get used; facts in the middle get lost. Attenuated in newer models, not eliminated. License: critical instructions first or last. Costs nothing.

Solid. Examples teach structure, not content. Min et al., UW / Meta AI (arXiv:2202.12837): corrupting few-shot labels barely hurt performance on classification tasks — the model extracts the shape of the demonstration. License: one well-formatted example beats a paragraph of adjectives. Corollary: specify what to extract, or the model will extract the wrong thing. (For a practitioner-curated tour of the broader evidence here, Eugene Yan’s Prompt Engineering guide is the best starting point — it tracks the papers rather than the folklore.)

Solid, but reported better than it performs. Chain-of-thought prompting (Wei et al., arXiv:2201.11903) and self-consistency (Wang et al., arXiv:2203.11171) are real, replicated effects — for arithmetic, logic, and multi-step reasoning tasks. The overextension is the problem: practitioners report “let’s think step by step” as a general fluency tonic, which the studies don’t support. It’s a reasoning scaffold, not a quality dial.

Directional. Practitioner consensus from people running production systems: most agent failures are context failures (broken retrieval, stuffed history, missing tool definitions), and identity priming (“You are an expert…”) barely moves frontier accuracy. This matches what Hamel Husain and others report from eval work in production, and what Simon Willison has documented consistently: the interesting failures are rarely the prompt’s wording. Reported experience, not controlled study — weight it accordingly.

Removed from v4. The “~21 percentage points” frontier-vs-open-source gap. One unverifiable preprint, no stable citation. The directional claim it supported — model choice matters more than format cleverness — survives without it, because it falls out of the tiers above.

How the cards were built

1. Write the best “before” I can — the prompt a thoughtful person actually sends on a Tuesday.
2. Run it. Watch the output.
3. Name the specific failure.
4. Fence exactly that failure. Run again.
5. Keep the card only if the failure was real and the fence fixed it.

Two honest consequences. First, selection bias: cards survive only where the move demonstrably helped, and “demonstrably” meant “in my runs.” Second: my models, my tasks, 2024–2026. The loop transfers better than the cards do. If you internalize one thing from this article, make it the loop, not the cards — it is the same discipline Eugene Yan describes in his writing on evals: look at outputs, name failures, change one thing, look again.

Move 1: Cap the degrees of freedom

Warrant: strong (practitioner consensus + the position-bias literature).

Most prompt failures are over-delivery, not under-delivery. The model doesn’t ignore your instructions because it can’t follow them; it ignores them because you gave it seventeen things to care about and a good-faith instinct to be thorough. “Focus on” is a suggestion; “only” is a fence; “if you find none, say so” is permission to stop performing thoroughness. Three cards, one principle.

1.1 — code review

• Before: “Review this diff for correctness, security issues, and anything you’d flag in code review. [diff]”
• After: “Review this diff for one thing only: data races in the shared state between these two functions. Don’t comment on naming, style, or anything unrelated to concurrency. If you find none, say so directly — don’t pad with minor notes to look thorough. [diff]”
• The failure: the before is fine, and it will produce twenty findings, nineteen trivial, with the race condition somewhere in the middle. The fence doesn’t add information; it removes competition for attention — consistent with what we know about how models weight context (arXiv:2307.03172).

1.2 — thread

• Before: “Turn this blog post into a Twitter/X thread — keep it engaging, max 8 posts. [post]”
• After: “Pull the single strongest claim from this post — not a summary of all of it. Max 6 posts, each standalone enough to be quoted alone, building to the claim rather than restating the headline. If you can’t identify one claim that’s clearly stronger than the rest, say so; that means the post shouldn’t be a thread. [post]”
• The failure: “max 8 posts” is a length cap, not a scope decision. The after forces the actual editorial choice — which claim — and the refusal condition protects against a thread that’s a table of contents.

1.3 — subject lines(the negative constraint, same move)

• Before: “Give me 10 subject lines for our Black Friday email to past customers who bought once and never returned. Keep them under 50 characters, avoid spam triggers. [details]”
• After: “8 subject lines, under 45 characters. Banned: emoji, ‘last chance,’ exclamation points, ‘don’t miss out.’ At least 2 should reference that they haven’t been back, framed as curiosity, not guilt. Then mark your top 2 and say why, one line each. [details]”
• The failure: the model knows what “spam triggers” means and avoids the obvious ones. The after names the actual lazy defaults — and note it also applies the audience lock (one-time buyers, a specific situation, not a demographic) and turns a list you must judge into a decision you can react to.

1.4 — support reply

• Before: “Draft a reply: this customer’s order arrived broken — second time in a month. Acknowledge the repeat failure, offer a replacement shipped today with no return needed. [email]”
• After: same, plus: “(1) Lead with the fix, then the policy explanation — not the other way around. (2) The register is ‘someone on our side is annoyed at our process on your behalf,’ not ‘we apologize for any inconvenience.’ Do not use the word ‘sincerely’ or the phrase ‘any inconvenience.'”
• The failure: the before already has the facts, the history, and the resolution — genuinely good. What’s left is ordering and register, exactly where models regress to template. Facts → fix → words, in that order of instruction.

(v3/v4’s data-cleaning and brand-voice cards remain cut. The befores already contained the one habit that mattered, and the afters mostly tied in my runs. Competent baselines tying your cleverness to information, not an inconvenience.)

Move 2: The worked example — with an extraction instruction

Warrant: strong (direct experimental support, arXiv:2202.12837).

Min et al.’s result cuts both ways: examples are powerful because models extract structure, and dangerous for the same reason — they will extract some structure, and without guidance it may be surface features (tone, warmth, length) rather than the load-bearing ones.

2.1 — support macro

• Before: “Rewrite this canned macro to sound less robotic. Here’s a reply someone wrote by hand that customers responded well to: [example]. Keep the steps accurate. [macro]”
• After: same, plus: “Match the hand-written reply’s structure — sentence length, where the empathy lands — not its content. Do not add empathy phrases the example doesn’t use. Do not remove or reorder the actual steps.”
• The failure: without the extraction instruction, the model imitates surface warmth and quietly distorts the steps — the one thing you asked it to preserve. The example is the instruction; the extraction sentence is the example’s instruction.

Move 3: The verification pass

Warrant: moderate-to-strong for narrow, checkable constraints (Self-Refine, arXiv:2303.17651, is real but modest); weak for open-ended “is this good?” self-critique. This distinction matters, and most coverage of self-verification elides it: models check against a stated constraint far better than they judge quality. Ask for the former, not the latter.

3.1 — SQL

• Before: “PostgreSQL: users who logged in at least once in the last 30 days and aren’t soft-deleted. Table users, columns last_login_at, deleted_at. Give me the query and note any assumptions. [schema]”
• After: same, plus: “Specifically tell me what the query does with a user whose last_login_at is NULL — never logged in. I want that case handled or flagged, not silently excluded.”
• Stated honestly: this card is the least magical in the article — it’s not prompt engineering, it’s knowing your data, with the prompt forcing the model to address your suspicion out loud. The generalizable kernel: a model verifies a named case far better than it finds an unnamed one. (Related silent failure: number-drift in fluent AI-written stakeholder updates. “Re-scan your draft against the notes and confirm each figure matches” costs one sentence and closes it.)

3.2 — the A/B test

• Before: “Did variant B win? It converted 4.1% vs 3.8% control, n=1,200 per arm, 14 days. [data]”
• After: “Before answering: is a 0.3-point gap on n=1,200 per arm large enough to trust? Then name the most likely way this result reverses if I run 2 more weeks. If the honest answer is ‘too early to call,’ say exactly that.”
• The failure: the before is a good prompt — the data is all there, no leading. The after activates statistical judgment the model already has but doesn’t volunteer. The shape rhymes with the Copilot RCT: a real effect, a wide interval, and the temptation to quote the point estimate.

Near-miss testing, absorbed: if you ask for a regex, require match/no-match strings that look almost identical — that’s where regexes actually fail. This is verification applied at authoring time rather than after, and it’s the highest-leverage version of the move for code.

Established practice, stated without glory: decomposition

Split “do the thing” into “propose a plan, stop, then execute.” This is not a move from this article; it’s how working practitioners have used these systems since 2023, and it’s covered better in the official docs (Anthropic, OpenAI cookbook) than here. One addition that earns its place: for writing projects, require every outline point to carry named supporting evidence — a study, a statistic, a concrete example — or be marked “opinion, needs sourcing.” Unsupported claims cost a sentence at the outline stage and 1,500 words later.

6.1 — flaky test(kept because the diagnosis pattern is genuinely useful)

• Before: “This test fails intermittently, not every run: [test + code]. Help me diagnose before we change anything.”
• After: same, plus: “Give me your top 2 hypotheses ranked by likelihood, each with the specific code evidence supporting it. Propose no fix yet — I want the diagnosis first. If the evidence is equally thin for both, say so.”
• The failure: the after adds ranking, evidence-anchoring, and a tie acknowledgment, which stops the model from laundering a guess into a confident single hypothesis.

6.2 — content brief

• Before: “Write a content brief a freelance writer could execute: our angle, what to avoid, target length, sources. [materials]”
• After: same, plus: “Also include: one detail only we would know to include (the thing that makes this ours and not a rewrite of page one), a word count with a reason for that number, and explicitly exclude a keyword list — that’s not the writer’s job. End the brief with the single belief we want the reader to leave with.”
• The failure: “word count with a reason” is the sleeper — it forces you, not the model, to know why the piece is that length, which is the actual editorial decision.

The record, honestly labeled

Here is what v4’s table was reaching for, with the framing it needed.

What this record is: four cards run through the failure-first protocol — before ×2, after ×2, blind-judged against the named failure criterion. It demonstrates that the protocol is runnable and discriminative: when I looked at the outputs, I could usually tell which version produced them, and the differences were the ones the cards predicted.

What this record is not: evidence that the moves work. With n=2 per cell, two judges, one task-set, and the same person selecting tasks and interpreting results, this table cannot distinguish a real effect from noise, luck, or judge expectation. Claiming otherwise would be the exact overclaim this article exists to warn against. The 3–1–0 record is a diary entry with a procedure, not a dataset. It is the difference between “looked at the outputs” and “didn’t look at the outputs” — which, in this genre, is unfortunately a high bar.

Feuilles de calcul

If you want a record worth trusting, the protocol generalizes even though the numbers don’t: pick one card, run it on your tasks with more than two samples, write down what happened, including the ties. Simon Willison’s writing on AI-assisted workflows and Eugene Yan’s work on evaluation-driven development are the model here — they’ve been publishing their outputs and mistakes in public for years, which is the actual standard. Riley Goodside’s publicly posted prompt work is worth following for the same reason: it’s demonstrations with outputs attached, not technique in the abstract.

Where these stop working

Saturation is common. On many tasks the competent before already gets 80–90% of what’s available; the after buys marginal polish at the cost of ceremony. When an after ties a before in your testing, that’s not a failed card — it’s a task class where prompt structure has stopped being the lever. The lever is elsewhere: model, retrieval, examples. This is the practitioner consensus finding above, and it’s the one I’d bet on outliving everything else in this article.

Attribution is fuzzy. Most afters combine two or three moves. What I’ve presented as three moves are still a compression device — just a smaller one.

Model-version decay is real. Verified against mid-2026 frontier behavior. If an after underperforms a before on your model, believe your run, not my card.

When you need none of this

A plain, clear, competent ask already works for most tasks. “Draft a reply acknowledging their refund is processed and apologizing for the confusion” will produce a fine reply. The moves earn their keep on a specific subset — outputs where an error is expensive (numbers in a stakeholder update), where the model’s defaults actively fight you (unscoped reviews, generic summaries), or where a wrong answer looks identical to a right one (that A/B test). For everything else — a first draft, a brainstorm, a rephrase — three minutes of fencing is wasted ceremony.

If you find yourself reaching for a scope fence on every message, you’ve inverted the tool. The moves are for known failure modes, not decoration.

And no — “You are an expert” is not a move. It’s a tic.

A good prompt doesn’t sound smarter. It leaves the model fewer ways to be wrong about the specific thing you’re actually asking — and the way to know you’ve succeeded is to run both versions, look, and write down what happened. Including, especially, on this article’s own cards. The standard is not my record. The standard is Willison’s, Yan’s, and Goodside’s: show the outputs, admit the ties, publish the failures.

A closing note on the links: I deliberately linked to primary papers (arXiv), official documentation, and practitioners who publish outputs and failures publicly. I did not link to other prompt-engineering listicles — v5’s entire thesis is that the genre is the problem, and linking it would be arguing against itself. If you’d like, I can also produce a version of this with inline footnotes, or a checklist version for team distribution.