Skip to content

Prompt Engineering: What Still Works in 2026

5 min read · updated August 3, 2026

The prompting tricks that stopped working have something in common, and it is not that they were unscientific. It is that they never carried any information. Once you sort techniques by that one criterion, which advice aged well stops being a matter of taste.

Two classes of technique

Every prompt technique does one of two things. It either changes what the model conditions on — a fact it did not have, an example of the output shape, a constraint it could not infer, a tool result — or it tries to move the model to a better part of a distribution it already has, without adding anything: you are a world-class expert, this is very important to my career, offering a tip, threatening a penalty.

Call the first class information and the second elicitation. Information cannot be absorbed by better training, because no amount of instruction tuning supplies a fact the model was never given. Elicitation can be, and largely was. The 2023 catalogue of elicitation phrases — Bsharat et al.’s Principled Instructions Are All You Need enumerated twenty-six of them, tipping and penalty threats included — was assembled against models whose default behaviour was much further from “careful and thorough” than a current chat model’s is. There was headroom to claw back. Most of that headroom is now the default, which is why the phrases feel inert.

The test for a line in your own prompt is one question: what could a competent person not do without it? “The schema version is 4.2” passes, because nobody could guess it. “Be thorough” fails, because thoroughness is what you asked for by asking. Lines that fail the test are not neutral. They occupy the instruction budget, they are paid for on every call, and they are the ones most likely to end up quietly contradicting a rule somebody adds next year.

What survived

  • Supplying the information. The unglamorous one, and the one that fixes most failures. A model cannot know your schema version, your customer’s tier, or that “the API” means the internal one. Nothing in the context does not exist.
  • One exemplar of the exact output. A single correctly-shaped example beats a paragraph describing the shape, because the description has to be interpreted and the example only has to be imitated. This is the durable core of few-shot prompting.
  • Constraints stated positively and checkable in code. “Reply with one of: approve, reject, escalate” is enforceable by a three-way in test. “Don’t be vague” is not enforceable by anything.
  • Decomposition. Splitting a task into steps whose intermediate outputs you can validate turns one opaque failure into several locatable ones.
  • Structure in long prompts. Delimiters, headings and tags let the model tell your instructions from the document you pasted. This matters more the longer the prompt gets.
  • An explicit licence to abstain. A model with no permitted way to say “not in the document” will invent something, because the highest-probability continuation of a question is an answer.

What the models absorbed

Three things happened between the first prompting guides and now. Instruction tuning got much better, so effort phrases stopped adding effort. Structured output became an API parameter, so format-coaxing became unnecessary where a schema is accepted. And reasoning moved inside the model: a reasoning model spends tokens working before it answers whether or not you asked, which makes let’s think step by step redundant at best. Vendors say so themselves — OpenAI’s published guidance for its reasoning series has advised against adding chain-of-thought instructions, on the grounds that the model already does it and the instruction can interfere.

Persona prompting is the clearest case, because the null result is published rather than folklore: Zheng et al. (2024), When “A Helpful Assistant” Is Not Really Helpful, evaluated 162 personas across several model families and found no reliable improvement over no persona at all.

The order to try things in

When a prompt underperforms, work down this list. It is ordered by expected value per hour, which is roughly the reverse of the order most people try.

  • 1 · Read a failing output in full. Not the summary of the failure — the actual tokens. Half of all “bad prompt” reports are a truncation (finish_reason of length) or a retrieval that returned the wrong document.
  • 2 · Add the missing information. Ask what a competent human with only this context would answer. If they would also get it wrong, the prompt is not the problem.
  • 3 · Show the output, do not describe it. One exemplar, exactly the shape you want to parse.
  • 4 · Enforce the shape mechanically if the model supports a JSON schema, so parsing stops being a prompting problem at all.
  • 5 · Decompose if a single call is being asked to retrieve, decide and format at once.
  • 6 · Change model. Cheaper than a week of prompt archaeology, and often the actual answer.
  • 7 · Only now, wording. Micro-copy is real but small, and it is the step that cannot be transferred to the next model you try.

Working out which era your model is in

Three checks tell you which half of this page applies. Does the model accept a response schema? Then formatting instructions are mostly waste. Does it bill separate reasoning tokens, or expose a reasoning-effort control? Then it is doing chain of thought whether you asked or not. Does its own documentation tell you to omit step-by-step instructions? Then omitting them is not a preference.

And none of this is knowable for your task without a small evaluation set — thirty to fifty real inputs with known-good outputs, run before and after every change. Without it you are comparing anecdotes, which is precisely how the folklore accumulated in the first place.

The uncomfortable part is that all three checks are about the model rather than about your task, and the model changes underneath you. A prompt is a fitted object: fitted to one family’s post-training, one API’s feature set, one generation’s defaults. Treat “what works” as a claim with an expiry date, and keep the eval set precisely so the next expiry costs you a morning instead of a quarter.

Prompt Engineering: What Still Works in 2026 · Multigrid