Prompt engineering did not die. It got narrower

Here is the controlled comparison to run: use the same model, settings, emails, and extraction task. Prompt A asks for JSON in prose. Prompt B adds an explicit schema, an enum on the category field, and a “no preamble” instruction. On a held-out set, measure parse failures, schema violations, field accuracy, latency, and cost. This article does not claim a private benchr result for that experiment.

Provider guidance still documents prompt structure as an application concern, including Anthropic's prompt engineering overview and the equivalent OpenAI prompt engineering guide. That supports testing these patterns; it does not establish a universal improvement for every model and task.

This piece turns three patterns into before-and-after test designs that can be run on Claude Opus 4.7 or another candidate model. “Before” is the baseline prompt; “after” changes one feature. Use your own held-out cases and report the resulting metric rather than assuming the direction or size of the effect.

Technique one: structured output schemas

When the model is supposed to produce machine-readable output, a schema is a sensible first variant to test against a prose-only description. The hypothesis is that explicit keys, types, and allowed values reduce format drift. The size and even the direction of the effect remain task- and model-dependent.

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

Possible failure modes include inconsistent keys such as customer_name, customerName, or name; a priority represented as an integer in one response and a string in another; or explanatory prose before the JSON object. Count each type separately on the held-out set so a valid parse does not hide a semantically wrong field.

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 }.

Now run both prompts with the same model settings and emails. For each response, record whether it parses, validates against the schema, uses an allowed issueCategory, and extracts the correct meaning. Also record latency and tokens. The schema earns its place only if the improvement that matters to your pipeline is repeatable.

The practical recommendation is concrete: test an explicit schema, constraints, and an output-only instruction as separate changes when possible. Separating the variables tells you which part helped.

A useful side experiment is a neutral reasoning prompt versus an otherwise identical “take a deep breath and think step by step” variant. Randomize order, run both on the same held-out cases, and score correctness, verbosity, latency, and cost. Remove the phrase if it does not improve the metric you need.

Technique two: few-shot examples for unusual formats

Few-shot prompting is another testable variant. The useful hypothesis is narrow: examples may help when the required format is specific to your organization and is not fully described by a familiar label.

For familiar formats such as Markdown, JSON, or a numbered list, a precise instruction may be enough. For a domain-specific changelog entry, custom XML schema, or house style, compare the instruction alone with the same instruction plus representative examples. Do not assume examples are necessary; measure format compliance and semantic quality.

A representative test case is a changelog entry that must open with a category in brackets, name the affected module, use present tense, and close with an issue number when applicable. Sample held-out pull requests across several change types, and define those four requirements as the scoring rubric.

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

The baseline may produce a generic changelog entry, invent a category, or omit the module name. Those are hypotheses to encode as rubric failures, not reported results.

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.

Run both variants with the same model and settings. Blind-score the outputs against the rubric, then record the extra input tokens and latency added by the examples. Keep the examples only if their measured benefit justifies that overhead.

Few-shot examples are a compact way to express format knowledge; whether they help is an empirical question for your task.

Model defaults can change, so preserve the baseline and rerun the evaluation when the model version changes. A schema with enum constraints is documented as an available control in provider tooling, including Anthropic's Claude API docs, but only your evaluation can establish its effect on your data.

Technique three: constraint-first prompting

The third hypothesis concerns ordering: lead with hard constraints, then describe the task. Compare that with the same wording arranged task-first, changing no other variable.

The proposed mechanism is that earlier instructions can shape how later text is interpreted, but the practical question is simpler: does moving the constraint block improve exact-rule compliance without reducing task quality?

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.

Define the baseline failures before running the test: wrong word count, use of a banned phrase, or a tone score below the agreed rubric. Predefining the rubric prevents a preferred variant from receiving looser judgment.

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.

Run both orderings on the same held-out product inputs. Measure exact word-count compliance, banned-phrase violations, and blind-rated tone. Report the observed result with the model version, settings, sample definition, and uncertainty; do not generalize it to other tasks without another test.

Putting constraints first is a cheap experiment, not a universal rule. If the task-first version works just as well, keep whichever prompt is easier for your team to maintain.

One open question is whether constraint-first prompting stays valuable as models and instruction hierarchies change. Preserve the evaluation so a model upgrade can answer that question on the same held-out cases.

What to test before keeping

Three popular techniques should not be treated as automatic improvements. Give each a neutral baseline and keep it only if it improves a relevant metric.

Persona preambles. Compare You are a senior software architect with 20 years of experience with a prompt that states the required audience, task, and rubric directly. Blind-score correctness and tone.

“Take a deep breath” and similar primers. Compare an otherwise identical neutral prompt and score correctness, verbosity, latency, and cost. Do not request or rely on hidden reasoning traces; evaluate the answer.

Threat or reward framing. Compare we will tip you $200 or a threat variant with neutral wording. Unless a task-relevant metric improves repeatably without harming tone or safety, remove the theatrical framing.

Other task-dependent variants

Self-consistency, answer critique, and extra reasoning instructions are task-dependent variants. For self-consistency, compare one answer with multiple independently sampled answers and include the added cost. For critique, predefine a writing rubric and blind-score the original and revised answer. For where benchmarks can miss product-specific effects, see why benchmarks stopped telling you anything.

Prompt engineering remains useful as a testing discipline. Structured output schemas, few-shot examples for unusual formats, and constraint-first prompting are three practical candidates because they create clear A/B variants. None is essential for every task.

If you're shipping AI features in 2026, build a versioned library of prompts for the specific tasks your system runs. Attach a held-out set, metric, model version, and change note to each prompt. That makes a prompt update reviewable instead of anecdotal.

The Prompt Workbench turns that discipline into a browser-only workflow: make the contract explicit, capture version A, flag multi-section changes, and pass one or both versions to Labs without placing the prompt in the URL.

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.