What Is Prompt Engineering?

🧩 The techniques the practice actually consists of

The recurring moves are few and mostly unglamorous. State the task explicitly instead of implying it. Specify the output format, and where the format is consumed by another program, supply a schema. Give worked examples when the shape of an answer is easier to demonstrate than to describe. Separate instructions from supplied data with an unambiguous delimiter, so that content cannot be read as a command. Say what should happen when the input does not support an answer, because an unstated case is answered anyway.

Two structural choices sit above the wording. The first is where an instruction lives: a system instruction, a developer message and text inside a user's own content are weighted differently by most deployments. The second is whether a task is one prompt or several — splitting a request into ordered steps with checked outputs is usually more reliable than one long instruction, at a cost in latency and tokens that has to be paid on every request.

The part of the practice that survives contact with production is the least written about, because it is not about wording at all. A prompt is an artefact and needs the treatment any other artefact gets. It belongs in version control rather than in a console, so that an output can be traced to the exact text that produced it. Its variable parts are interpolated through a template rather than concatenated into a string, so that the boundary between instruction and supplied data is enforced by the code instead of by the author's care on the day. And it is changed one thing at a time against a fixed set of cases, because a revision that altered three things and improved the result has not established which of the three did the work.

None of these are guarantees. Each is a change whose effect has to be measured on the cases that matter, rather than assumed from the technique's reputation.

🗃️ How the Registry classifies a prompt revision task

Rewriting a production prompt template in an application repository and committing the change is filed as a code modification task in this registry's classification. The class follows the artefact: the thing edited is source under version control, whatever the edit is made of.

The Registry's canonical brief for this entry is filed as: Rewrite a production prompt template in the application repository to enforce a fixed output format, and commit the change. Submitted for assessment it is classified as Code modification, and its wording is hashed once — to 2c621f253ff282cb…, the first sixteen of sixty-four hexadecimal characters — with the wording itself never stored. The hash is what the derivation reads. That class's own page is /tasks/code.

Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.

❓ Questions about prompt engineering

What is prompt engineering?

Prompt engineering is the practice of writing and structuring the input to a language model so that its output is more predictable. It consists of explicit task statements, specified output formats, worked examples, delimiters separating instructions from data, and stated fallback behaviour, each kept or discarded on measured evidence.

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

A system prompt carries the operator’s standing instructions and is sent with every request. A user prompt carries the specific request being made. Most deployments weight the system instruction more heavily, but the separation is a convention of the interface rather than a security boundary.

Does prompt engineering replace fine-tuning?

They address different problems. A prompt is changed instantly and costs tokens on every request; a fine-tune costs a training run and then costs nothing extra per request. Prompting is usually where a behaviour is first established, and fine-tuning is where a stable, repeatedly demonstrated behaviour is moved once the prompt carrying it has grown expensive.

How do you know whether a prompt change helped?

By running it against a fixed set of cases with a scoring rule decided in advance, and comparing. Without that, a prompt revision is a change with no way to tell an improvement from noise, which is the failure mode the practice is most prone to.

Where does prompt engineering end and application design begin?

At the point where the fix stops being text. Splitting a task into ordered steps, validating an output against a schema and retrying when it does not conform, or fetching material rather than describing it, are all changes to the program around the prompt instead of to the prompt itself. The whole activity is habitually filed under prompt engineering, but the parts that make a system dependable usually sit outside the string.