What Is Prompt Engineering? A Working Definition

Prompt engineering acquired a reputation as either a serious discipline or a temporary artifact of immature models, depending on who was asked. Both positions contain something true, which is why the argument has not settled.

The practice itself is straightforward to define:

Prompt engineering is the design of inputs to a language model — instructions, context, examples, and output format — to make its outputs reliable enough for a given purpose.

The operative word is reliable. Getting a good answer once is not engineering; it is luck. The discipline concerns getting an acceptable answer consistently, across varied inputs, at a cost and latency that work in production.

This article covers the techniques with actual published provenance, the ones that mattered more in earlier models than they do now, how prompting relates to the broader problem of assembling context, and the honest answer to whether this is a job.

Why Prompts Need Engineering at All

A language model predicts likely continuations of text. It has no access to intent beyond what the input encodes, and no mechanism for asking what you meant. Everything it knows about the task arrives in the prompt.

Two consequences follow, and they drive nearly every technique below.

Underspecification produces variance. "Summarize this" leaves length, audience, tone, and what counts as important entirely undetermined. The model picks something reasonable, and picks differently next time. Most prompting work is closing that gap.

Format must be stated to be relied upon. A model asked for JSON will often produce JSON, and occasionally produce JSON wrapped in explanation. If downstream code parses the output, "often" is a bug. This is why constrained decoding and structured-output modes exist.

The Techniques That Have Held Up

Explicit Role and Task Framing

Stating who the model should behave as and what it is doing narrows the distribution of plausible outputs. "You are reviewing this contract for termination clauses" produces different attention than "read this document."

This is the least glamorous technique and among the most reliable. It is also where most real gains are available, because underspecified tasks are extremely common.

Few-Shot Examples

Including worked examples of input and desired output demonstrates the task rather than describing it. The GPT-3 paper (Brown et al., 2020) documented that models could perform tasks from examples in the prompt alone, without weight updates — the observation that made in-context learning a design surface.

Examples are particularly effective for format and tone, which are difficult to specify in prose but obvious from a demonstration. They cost tokens on every call, so there is a real trade-off between reliability and price.

Chain-of-Thought Prompting

Prompting a model to work through intermediate reasoning before answering improves performance on multi-step problems. Wei et al. (2022) documented the effect and gave it its name.

The important caveat: newer reasoning-focused models perform this internally, and explicitly demanding step-by-step reasoning can be redundant or counterproductive with them. This is a clear case of a technique whose value depends on which model you are using — which is itself the general lesson.

Structured Output Constraints

Rather than asking for JSON and hoping, most providers now support forcing a schema — via function/tool calling or a response-format parameter. Where available, this eliminates a whole class of parsing failures.

This is arguably not prompting at all but an API capability. It belongs in the list because it replaced a large amount of prompt text that previously existed to beg models for clean output.

Explicit Negative Constraints

Stating what not to do — do not invent citations, do not answer outside the provided context, say "I don't know" when the context is insufficient — measurably narrows failure modes. Models do not reliably infer prohibitions.

Negative constraints work best when specific. "Be accurate" is not actionable; "if the answer is not in the provided documents, say so rather than using general knowledge" is.

What Has Become Less Important

Being honest about this matters, because a great deal of prompting advice was written for models that no longer represent the state of the art.

Politeness and incentive framing. Elaborate courtesy, or offering the model a fictional tip, circulated widely as tricks. Whatever effect these had on earlier models, they are not a sound basis for a production system, and there is no mechanism that would make them robust.

Rigid magic phrasings. Prompts built around exact incantations tend to be brittle. They were often overfitted to one model version and broke on the next.

Elaborate jailbreak-style framing to unlock capability. Convoluted role-play to get a model to attempt a task is largely a symptom of using a model poorly suited to it.

The pattern is that techniques grounded in a mechanism — showing rather than telling, constraining the output space, stating prohibitions explicitly — have held up. Techniques that were empirical quirks of a particular model have not.

From Prompting to Context Engineering

As applications grew beyond single prompts, the harder problem turned out not to be wording but what information reaches the model at all.

A retrieval-augmented system's output quality depends far more on whether the right documents were retrieved than on how the instruction is phrased. An agent's reliability depends more on how its tools are described and how its history is managed than on its system prompt.

This broader activity — deciding what goes into the context window, in what order, at what cost, and what gets dropped when space runs out — is sometimes called context engineering, and it is where most difficulty now sits in non-trivial applications. Prompting remains a component, but treating it as the whole discipline leads teams to tune wording when their retrieval is the actual problem.

How to Actually Do It

The mechanical process matters more than any individual technique.

Write the evaluation before optimizing the prompt. A set of representative inputs with known-acceptable outputs is what distinguishes improvement from the impression of improvement. Without it, prompt iteration is vibes.

Change one thing at a time. Prompts interact in unintuitive ways; simultaneous edits make attribution impossible.

Version prompts like code. They are load-bearing application logic. Treating them as configuration strings that anyone can edit in a dashboard causes exactly the problems you would expect.

Re-test on model upgrades. A prompt tuned for one model is not guaranteed to transfer. Upgrades are usually improvements, but not uniformly across every task.

Prefer the simplest prompt that passes. Long prompts cost tokens on every call and accumulate contradictory instructions over time. Elaborate prompts are frequently compensating for a fixable structural problem.

Is Prompt Engineering a Real Job?

The honest answer is that it is a real skill and an increasingly rare job title.

Around 2022 and 2023, when models were more sensitive to phrasing and structured-output support was limited, dedicated prompt-engineering roles were advertised. As models improved and tooling absorbed the fiddly parts, the standalone role became less common — not because the skill stopped mattering, but because it was absorbed into other jobs.

What replaced it: AI engineers, machine learning engineers, and applied AI developers who prompt as one part of a wider role that also includes retrieval systems, evaluation harnesses, cost management, and application integration. Domain experts — lawyers, clinicians, analysts — who prompt well within their field are also valuable, because the hard part is often knowing what a good output looks like.

Anyone evaluating this as a career path is better served by treating prompting as one skill within AI engineering than as a destination.

Conclusion

Prompt engineering is designing model inputs so outputs are reliable enough to depend on. The techniques that endure share a mechanism: demonstrate rather than describe, constrain the output space, state prohibitions explicitly, and specify what underspecification would otherwise leave to chance.

The techniques that faded were empirical quirks of specific model versions. That distinction is the most useful filter to apply to any prompting advice, including advice written recently.

For teams building on models today, the leverage has largely moved from wording to context — what information reaches the model, and whether there is an evaluation set to tell whether a change helped. A mediocre prompt with good retrieval and a real eval will beat an elegant prompt with neither.

Frequently Asked Questions

What exactly does a prompt engineer do?

In practice, they design and maintain the inputs that production systems send to language models: writing and versioning system prompts, building evaluation sets to measure output quality, diagnosing failures, managing token cost, and re-validating when models are upgraded. In most organizations this is part of a broader AI or ML engineering role rather than a standalone position. The work is closer to test-driven development than to creative writing.

Is prompt engineering difficult?

Basic prompting is easy to learn — clear instructions, examples, explicit constraints. What is difficult is making outputs reliable at scale: building evaluations that detect regressions, handling inputs you did not anticipate, controlling cost, and diagnosing why a prompt that works on ten examples fails on the eleventh. The gap between "I got a good answer" and "this works in production" is where the actual difficulty lives.

How do I become an AI prompt engineer?

Treat it as one skill inside AI engineering rather than a standalone target, since dedicated prompt-engineering job titles have become less common. Useful groundwork: build a real project that calls a model API, write an evaluation set for it and measure changes, learn retrieval and structured output, and read the primary sources on the major techniques rather than aggregated tip lists. Domain expertise in a field where you can judge output quality is a genuine advantage.

What is prompt engineer salary?

Advertised figures varied widely during the period when the standalone title was common, and the role has since largely merged into AI and ML engineering positions, so current listings under that exact title are sparse and unrepresentative. Compensation depends heavily on location, seniority, industry, and whether the role is research or product-focused. Checking current listings for AI engineer or ML engineer roles in your specific market will give a more reliable picture than any single quoted figure.

What is the difference between a system prompt and a user prompt?

The system prompt sets persistent behavior — role, constraints, output format, tone — and applies across the conversation. The user prompt is the specific request for one turn. Stable instructions belong in the system prompt so they are not repeated or accidentally varied; anything specific to a single request belongs in the user prompt. Models generally weight system instructions more heavily, though this is a tendency rather than a guarantee.

Is prompt engineering going to become obsolete?

The narrow version — hunting for magic phrasings that unlock capability — has already declined as models improved. The broader skill of specifying tasks precisely, constraining outputs, and evaluating quality has not, because it addresses the permanent problem that a model only knows what its input tells it. What has changed is where the difficulty sits: increasingly in deciding what information reaches the model, rather than in how the instruction is worded.