Prompt engineering: writing instructions that survive production

Prompt engineering is the craft of writing the instructions a language model receives so that it does something useful, repeatably. It isn't a trick or a collection of magic phrases sold in a PDF: it's specification work, much like writing the procedure you'd hand to a new joiner on day one — except this new joiner never asks when something is unclear. It just fills the gap with whatever seems reasonable.

That's the distance between the prompt that works for you in a chat window on a Tuesday afternoon and the one that holds up across a thousand automated runs with nobody watching. This guide is about the second kind: what goes into a production prompt, where the context comes from, how you tell whether it's working, and why past a certain point the problem stops being the prompt.

What is prompt engineering, and what isn't it?

A language model generates the most likely continuation of what you give it. It doesn't have your context, it doesn't know what your ERP is called, it has never seen your discount policy, and it can't tell the difference between what's obvious to you and what's obvious to nobody. Anything you don't write down, it will invent from whatever it has.

Prompt engineering is therefore the exercise of removing ambiguity. It's good for:

• Fixing the output format so the result can be processed by another system instead of being a nice paragraph.
• Bounding the scope, saying explicitly what it should do and what it must never do.
• Supplying the missing context: company vocabulary, rules, edge cases.
• Making behaviour stable, so two runs with similar inputs produce similar results.

And it is not good for what many people expect. A prompt doesn't add information the model doesn't have: if the answer depends on your catalogue, the catalogue has to go in. It doesn't fix a badly defined process: if nobody in the company knows when an incident gets escalated, the prompt won't know either. And it doesn't replace validation — a text can be beautifully written and completely false.

If you can't explain the task to a sharp intern on one page, you don't have a prompt problem. You have a process problem.

What goes into a prompt that works?

Prompts that survive in production almost always have the same six pieces. It isn't a closed formula, but when one is missing you tend to notice.

| Piece | What it solves | Typical mistake | |---|---|---| | Role and objective | Sets the register and the standard | "You are an expert in everything" | | Concrete task | Defines exactly what gets produced | Asking for two different things at once | | Context | Supplies data the model doesn't have | Pasting 40 pages "just in case" | | Output format | Makes the result machine-readable | Asking for JSON without giving the schema | | Examples | Teaches the nuance that's hard to explain | Examples all drawn from the easy case | | Limits and escape hatch | Prevents invented answers | Not saying what to do when data is missing |

The piece most often forgotten is the last one. A production prompt has to say, literally, what to do when the information isn't there: "If the document doesn't contain a due date, return `null` for that field; do not infer it." Without that sentence the model will infer, because inferring is exactly what it does.

On examples, a practical note: two or three well-chosen ones beat fifteen. And they should be the awkward cases, not the easy ones. The easy case is already handled; what the model needs to see is the invoice with two order numbers, the email where the customer says three things at once, the delivery note scanned crooked.

How does a prompt become a reusable template?

In a chat window you retype the whole prompt each time. In production you don't: you have a template with slots filled from each run's data. That step — from loose text to parameterised template — is what separates an experiment from a system.

A template for classifying inbound email, say, has the instruction fixed, the list of valid categories fixed, the examples fixed; only the email body and the sender metadata vary. Three consequences matter:

1. The template is code. It lives in the repository, gets reviewed before it changes, and has a history. If someone edits the category list, there's a record of who and when. 2. It has a version. When results get worse on Monday, the question "which prompt version was live on Friday?" has an answer. Without that, debugging is guesswork. 3. It can be tested on its own. A slotted template can be run against a saved set of cases and compared with the expected output. A prompt typed by hand into a window cannot.

Separate what changes weekly from what doesn't, too. Volatile business rules — thresholds, supplier lists, exceptions — are better injected as context from a data source than written inside the prompt, where they go quietly out of date.

Where does the context come from?

This is where 80% of the result lives, and the part least discussed. Answer quality depends far more on what information accompanies the question than on how the question is phrased.

There are three ways to supply context, from least to most effort:

• Fixed in the template. Fine for the stable stuff: company glossary, tone, categories. If it fits on half a page and changes once a year, it goes here.
• Injected from your systems. For case-specific data: the customer record from the CRM, order history, ticket status. It's an ordinary query against your databases, not magic.
• Retrieved from a document repository. When the answer could be in any of ten thousand documents and you don't know which in advance. That's what RAG solves, and it's worth reading up before building it, because it fails when the repository is messy.

One warning that saves money: more context is not better context. Passing a whole document when two paragraphs would do makes every call more expensive, slows the response, and — this surprises people — reduces accuracy, because the instruction that matters gets buried under irrelevant text. Trimming context usually raises quality and lowers the bill at the same time.

How do you evaluate a prompt without fooling yourself?

"It works well" isn't a measurement. If this is going into a real process, you need to know when it gets worse, and for that you need a test set. Nothing sophisticated:

1. Collect 30 to 50 real cases. From your own history, not invented. Deliberately include the odd ones and the ones that went wrong. 2. Write down the correct answer for each. This is done by whoever owns the process, not whoever writes the prompt. It's the expensive part and the one you can't skip. 3. Define what counts as correct. For extracted data, exact field match. For text, a checklist of three or four criteria: does it answer the question, does it cite the source, does it respect the format, does it avoid asserting what it doesn't know? 4. Measure before touching anything. Run the whole set and record the result. That's your baseline. 5. Change one thing at a time. If you change three things and it improves, you don't know which one worked or which one was making things worse at the same time. 6. Re-run the whole set on every change. That's your regression test: fixing one case and breaking two that were fine is the normal outcome.

With this in place, the conversation shifts from "it feels like it answers better now" to "we went from 41 to 46 correct out of 50, and the four new failures are all the same type". The second sentence supports a decision; the first doesn't.

Watch for drift as well. Models get updated, and a prompt that behaved beautifully in March can behave differently in September without anyone changing a comma. Running the test set once a month costs little and stops you finding out through a customer complaint. It's the same monitoring logic we describe in MLOps for business.

Why the prompt doesn't replace the process

There comes a point, usually around the third or fourth iteration, where the prompt stops being the bottleneck. The signs are recognisable:

• The prompt runs to three pages and every new exception adds a paragraph.
• Two people on the team disagree about the correct answer for a case in the test set.
• The remaining failures are all down to information that isn't recorded anywhere.
• Nobody can say who reviews the output before it reaches the customer.

None of those four is fixed by better writing. The first is fixed by splitting the task into two smaller steps. The second is a business disagreement dressed up as a technical problem: it gets resolved in a meeting, not in an editor. The third is a data problem. And the fourth is process design: who validates, against what criteria, and what happens when the system isn't sure.

That last point deserves a hard rule: define the human-review threshold before anything goes live. Which cases pass through automatically, which go to review, and who reviews them. Leaving that decision for later means, in practice, that nobody reviews anything. The same goes for what information is allowed to leave the building, which belongs in your AI use policy rather than in each person's head.

Mistakes we see over and over

• Asking for two jobs in one prompt. "Summarise and classify and draft the reply" gives you three mediocre outputs. Three chained steps give you three separately measurable ones.
• Prohibiting in the negative without giving the alternative. "Don't make things up" works far worse than "if the figure doesn't appear in the text I gave you, answer: not stated".
• Collecting prompts in a shared document. You end up with fourteen versions, none dated, nobody sure which is current. Repository or nothing.
• Confusing sounding right with being right. These models write with total confidence whether they're correct or not. Confident tone is not a signal of anything.
• Not measuring cost per run. A prompt with generous context multiplied by twenty thousand runs a month is a budget line, not a detail.
• Training the team on tricks instead of judgement. What helps isn't the list of magic phrases, it's understanding what information the model needs. We cover it in AI training for teams.

Frequently asked questions

Do we need to hire a prompt engineer?

As a standalone role, almost never. What works is pairing the person who owns the process — who knows when an invoice is correct or how a complaint gets answered — with someone who can build the template, the evaluation and the integration. The hard-to-find knowledge is the business knowledge, not the instruction writing.

Does a longer prompt give better results than a short one?

Not by virtue of being longer. What improves results is relevant information and absence of ambiguity, and that sometimes needs length and sometimes is hurt by it. If you add a paragraph and the test set doesn't improve, take it out: you're paying for tokens that contribute nothing.

Do prompts still work if we switch models?

The structure transfers reasonably well; the fine-grained behaviour doesn't. When you change model you have to re-run the test set and usually adjust the output format and the examples. That's an afternoon's work if you have the evaluation in place, and a blind week if you don't.

Where should company prompts be stored?

In the same place as the code that uses them, with version control and change review. A shared document is convenient for the first month and a source of incidents from the third, because there's no way to know which version produced which result.

---

If you're at the point of moving this from scattered experiments into something that works inside a real process, what decides the outcome isn't the wording: it's what data is available, who validates the output, and where it fits in the flow that already exists. That's what we look at in the audit, and it produces a plan with prioritised cases and what each one requires. If you've already identified yours and want to pressure-test the design with people who have put a few into production, let's talk.