Prompt Engineering

What Is Prompt Engineering?

Prompt engineering is the practice of designing the text sent to an AI model, including instructions, examples, constraints, and output format, so the model reliably produces the result you want. It treats the prompt as an engineered artifact, something written deliberately, tested against cases, and versioned in source control, rather than a question typed casually into a chat box. The field is bigger than it looks from the outside: The Prompt Report, a 2024 survey by Schulhoff et al., catalogs 58 distinct text-based prompting techniques plus 40 more for other modalities [1].

Key Takeaways

• The core skill is specification: most bad outputs trace to instructions that never said what good looks like, not to model weakness.
• The workhorse techniques are stable and few: clear instructions, relevant examples, explicit output formats, and delimiters that separate instructions from data.
• In production, prompts behave like code. They live in version control, run against eval suites, and regress when someone edits them carelessly.
• The discipline narrowed rather than died. Model-tricking incantations aged out; writing precise system prompts and tool descriptions matters more than ever.

How It Works

Language models follow instructions, and the quality of the following tracks the quality of the instructing. A working prompt usually assembles a handful of parts: a role or task framing, the concrete instructions, constraints on what to avoid, the input data clearly delimited so the model cannot confuse it with the instructions, and a specification of output shape. Each part earns its place by closing off a class of failure. Delimiters guard against stray text being read as commands, which is the benign cousin of prompt injection. Explicit format specs, or structured outputs enforced at the API level, stop the model from wrapping JSON in friendly prose.

When instructions alone fall short, examples carry the load. Showing the model two or three worked input-output pairs, the technique known as few-shot prompting, communicates format and judgment more reliably than describing them, because the model imitates patterns better than it obeys abstractions. For tasks with reasoning depth, asking the model to work through the problem before answering still helps on non-reasoning models, though 2026-era reasoning models handle much of that deliberation internally without being told.

What separates engineering from tinkering is the loop around the prompt. A production prompt is written against a target, run over a fixed set of test inputs, scored, and revised, and then it is frozen in version control where changes get reviewed like any diff. This matters because prompts are brittle in unintuitive ways: a sentence added to fix one failure can silently break five other cases, and without an eval you find out from users. The brittleness is measurable, too. A 2023 study by Sclar et al. found that subtle changes in prompt formatting alone caused accuracy swings of up to 76 points in few-shot settings, and the sensitivity did not go away with larger models or instruction tuning [2]. In agentic systems the same craft applies to the system prompt, to tool descriptions, and to instruction files, each of which is a prompt with a long service life.

Example

A team extracts invoice data from supplier emails into JSON. The first prompt, "extract the invoice details from this email," works on tidy invoices and falls apart on real traffic: totals with EU decimal commas, forwarded threads with two invoices, emails with none. The fix is engineering rather than magic words. They specify the exact schema with a null policy for absent fields, add three few-shot examples covering the comma format and the no-invoice case, instruct that only the most recent message in a thread counts, and delimit the email body so nothing inside it reads as instruction. Run against a 40-email eval set, accuracy goes from 61 to 96 percent, and the eval now guards the prompt in CI against future edits.

What People Get Wrong

The persistent misconception is that prompt engineering is a bag of secret phrases, that "take a deep breath" or a threatened tip meaningfully controls quality. Those tricks were always marginal and got flattened by instruction-tuned and reasoning models. What actually moves output is boring and durable: stating the task precisely, showing examples of the target, constraining the format, and testing against real cases. Done systematically, that work is powerful: Microsoft's 2023 Medprompt research used prompt engineering alone to push generalist GPT-4 past 90% on the MedQA medical exam benchmark for the first time, cutting the error rate 27% below the best specialist models [3]. Prompt engineering is technical writing with a feedback loop. Engineers who look for incantations plateau quickly; engineers who treat the prompt as a spec keep getting better results as models improve.

Prompt templates

In production, prompts are rarely written fresh per request. A prompt template is a parameterized prompt stored in code: fixed instruction scaffolding with slots for the variable parts, the user's input, retrieved documents, today's date, filled at runtime. Templates are what let prompts be engineered at all, since a stable artifact can be versioned, diffed, A/B tested, and run through evals, while an ad-hoc string concatenated in four places can only be debugged in production. Mature codebases keep templates in dedicated files with owners and change review, and the sharpest teams treat a template edit like a schema migration: small, deliberate, and verified against the eval suite before it ships.

FAQ

Is prompt engineering still relevant in 2026? Yes, though the shape changed. The standalone "prompt engineer" job title largely dissolved into normal engineering work, while the skill itself spread: anyone building on models writes system prompts, tool descriptions, and templates, and the difference between a sloppy one and a precise one still shows up directly in product quality.

What is the difference between prompt engineering and context engineering? Scope. Prompt engineering crafts the instruction itself. Context engineering governs everything the model sees at inference time, deciding which files, history, and tool results fill the context window across a whole task. In agentic systems the prompt is one carefully written piece inside that larger managed budget.

Do reasoning models make prompt engineering unnecessary? They make it simpler, not optional. Step-by-step scaffolding and elaborate role-play matter less because the model deliberates internally. Clear task definition, constraints, examples, and output contracts matter exactly as much as before, since no amount of reasoning recovers a requirement the prompt never stated.

Sources

1. Schulhoff et al., arXiv (The Prompt Report). "Taxonomy of 58 text-based LLM prompting techniques and 40 techniques for other modalities." https://arxiv.org/abs/2406.06608. Accessed August 2026.
2. Sclar et al., arXiv (FormatSpread). "Prompt formatting changes caused performance differences of up to 76 accuracy points in few-shot settings." https://arxiv.org/abs/2310.11324. Accessed August 2026.
3. Microsoft Research, arXiv (Medprompt). "Prompt engineering steered GPT-4 past 90% on MedQA, a 27% error-rate reduction over specialist models." https://arxiv.org/abs/2311.16452. Accessed August 2026.