Prompt engineering did not die. It got narrower

Same model, same emails, same extraction task. Prompt one: Extract the customer's name, the issue category, and a priority score from this email. Return it as JSON. Prompt two: the same request with an explicit JSON schema, an enum on the category field, and a "no preamble" instruction. Over a thousand calls, the first prompt produced parse failures on roughly 12% of the responses. The second produced parse failures on 0.3%. Nothing about the model changed between the two runs — only the prompt.

Most of the 2023-era prompting toolbox has been absorbed into the frontier models, and most of what trained engineers did two years ago happens automatically now. A small set of techniques still moves the needle in 2026, including everything covered in Anthropic's prompt engineering overview and the equivalent OpenAI prompt engineering guide. That set is narrower than it used to be, but it still earns its place.

This piece covers three of them with before-and-after examples, all on Claude Opus 4.7, all on tasks drawn from production working sessions. The "before" is what comes back when you write the prompt the way you'd describe the task out loud; the "after" is what comes back once the technique is applied. In each case the gap is large.

Technique one: structured output schemas

When the model is supposed to produce machine-readable output, hand it a schema rather than describing the shape in prose. The frontier models in 2026 follow structured-output instructions well when those instructions are concrete, and they get noticeably sloppier when the structure is only implied.

Before: Extract the customer's name, the issue category, and a priority score from this email. Return it as JSON.

That works most of the time. The failure mode is that the JSON keys are inconsistent across calls. Sometimes customer_name, sometimes customerName, sometimes just name. The priority-score format drifts. Sometimes an integer, sometimes a string, sometimes wrapped in explanatory prose before the JSON object even starts. Over 1,000 calls, parse failures downstream run around 12%.

After:

// Before
Write a product description for the markdown export module.

// After
Constraints: 150 words exactly. No marketing words ("revolutionary,"
"cutting-edge," "seamless"). The tone respects the reader's intelligence.
Now: write a product description for the markdown export module.

For the JSON extraction case: Extract the following fields from this email and return ONLY the JSON object, no preamble. Schema: { "customerName": string, "issueCategory": "billing" | "technical" | "feature_request" | "other", "priority": integer 1-5 }.

Same model, same emails, parse failures drop to roughly 0.3%. The enum on issueCategory alone cuts drift a lot. The model commits to one of four allowed values instead of inventing a fifth. The no preamble instruction kills the chatty intro paragraphs that used to wrap half the responses.

The lesson is concrete: spell out the schema, the constraints, and what the model shouldn't output. None of this is new, and it still works.

(A small side-quest: the community has tested whether "take a deep breath and think step by step" still produces measurable improvement on a reasoning test. It doesn't, on the frontier models. It also doesn't hurt. Most of the 2023-era prompting tricks have been absorbed into the model defaults: they aren't banned, they're just no longer the source of the lift.)

Technique two: few-shot examples for unusual formats

Few-shot prompting was the hot technique of 2023. The narrative since has been that the models don't need examples anymore. That holds up for common formats. For unusual ones it falls apart.

If the format is something the model has seen a million times — Markdown, JSON, a numbered list, a structured email — examples aren't needed. The model already knows it. Domain-specific formats are the other story: a particular kind of changelog entry, a custom XML schema, a writing style with its own rhythm. There, examples are still essential, and the model's output without them is far worse.

A representative example: changelog entries that follow a particular format. A single paragraph that opens with the change category in brackets, names the affected module, describes the change in present tense, and closes with a small parenthetical noting the issue number where applicable. The format has 200+ examples in the existing log.

Before: Write a changelog entry for this PR that follows the established changelog format.

The model knows a format exists but has no idea what it actually is. The result is something close to a generic changelog entry: a bullet point with a verb, sometimes carrying categories that aren't part of the real format, often missing the module name. Maybe 30% of outputs are usable as-is.

After: Three production changelog entries from the existing log, followed by: Write a changelog entry for this PR in the same format as the examples above.

Same model, and 95%+ of outputs are usable as-is. The few-shot prefix runs around 200 tokens, which costs almost nothing, and it carries the format knowledge the model lacks natively. In working sessions this is the technique that gets reached for most.

Few-shot examples transfer format knowledge into the prompt, and a strong model benefits from that the same way a weak one did.

The reasonable prior going into 2026 is that prompt engineering has been fully absorbed into model defaults. The structured-output schema technique pushes back on that prior. The lift from a JSON Schema with enum constraints is reported at 30-40× on the parse-failure rate, even on Claude Opus 4.7 (the same model documented at Anthropic's Claude API docs). It's an old technique posting a real number.

Technique three: constraint-first prompting

The least-known of the three, and the one worth reaching for most. The structure is to lead with the constraints, then describe the task — the reverse of how most prompts get written, where the writer lays out what they want and tacks the constraints on at the end as caveats.

The reason it matters: the model produces tokens left to right, so whatever shows up early in the prompt informs what comes next. Constraints buried at the end arrive after the model has already formed most of its understanding of the task. Put them first and they shape that understanding from the start.

Before: Write a 150-word product description for the markdown-export module. Don't use marketing jargon. Don't say "revolutionary" or "game-changing." Write in a tone that respects the reader's intelligence. Avoid clichés.

That works most of the time. The failures are predictable: the model writes the description first, then notices the constraints, and either edits inadequately or produces output that reads like marketing copy with a few hedges thrown in.

After: Constraints: 150 words exactly. No marketing jargon. No use of "revolutionary," "game-changing," "cutting-edge," "seamless," or "robust." The tone is plainspoken and respects the reader's intelligence. Now: write a product description for the markdown-export module.

With the constraints loaded before the task, the model produces output already inside the constraint space. The word target is hit more reliably — within 5% in testing, versus 15% with the constraints at the end — the banned phrases stay out, and the tone holds through the paragraph instead of drifting back to marketing copy in the second half.

This is just an artifact of how the models generate output, and it applies broadly. The constraints that matter belong at the start of the prompt.

One open question: whether constraint-first prompting will stay valuable as models get better at instruction-following late in their context. Current models clearly weight early context more heavily than late context for shaping output. Whether that's a fundamental property or a tuning artifact is an open research question.

What's obsolete

Three techniques that are really gone in 2026. Stop using them.

Persona preambles. You are a senior software architect with 20 years of experience. The frontier models already calibrate their output to the task, so the persona instruction adds nothing — and occasionally pushes the tone in the wrong direction.

"Take a deep breath" and similar chain-of-thought primers. The models think step by step now without being asked. The bare prompt produces equivalent results in testing.

Threat or reward framing. If you don't do this perfectly, a kitten dies. we will tip you $200. These never had a solid evidence base and the current models don't respond to them in any measurable way.

The half-obsolete category

Some techniques have moved from required to optional. Chain-of-thought still works but is mostly automatic. Self-consistency (run the prompt three times, take the majority vote) still helps on hard reasoning at a 3× cost. Asking the model to critique its own output still produces measurable improvement on long-form writing, but the gain is smaller than it was two years ago. For where benchmarks fail to measure these gains, see why benchmarks stopped telling you anything.

Prompt engineering as a craft isn't dead. The techniques that pay off have narrowed to a small set, and the rest of the toolbox has been absorbed into model defaults. Structured output schemas, few-shot examples for unusual formats, and constraint-first prompting are the three worth defending as still essential. Most of what's left is ritual you can drop.

If you're shipping AI features in 2026: build a small library of prompts that work for the specific tasks your system runs, with the techniques above applied carefully, and stop reaching for the framework of the week. Most of the productivity gain from prompt engineering comes from doing the basics carefully on the prompts that fire a thousand times a day, not from chasing the new technique.

The right way to think about prompting now is as a software engineering discipline. Version your prompts, test them on held-out cases, measure the failure rate, and improve the ones that are costing you the most. The novelty has worn off, but the engineering work is still there to do.