Prompt engineering

How it works

A production prompt reads like a brief for a new hire. It states the role and the task, the inputs the model will get, the rules it must follow, what to do when information is missing, and the exact output format. Good prompts usually include:

• 2 to 5 worked examples of real inputs and correct outputs
• A defined output structure, often a JSON schema the model API can enforce
• Explicit edge cases, such as "if the invoice has no PO number, return null"
• Permission to say it does not know

Writing the prompt is the easy part. The engineering is the testing: a fixed set of 30 to 200 real cases, scored automatically where possible and rerun on every change. Without that set, an edit that fixes one case can break 5 others and nobody notices until a customer does. Anthropic's prompt engineering guide (opens in a new tab) starts from the same place: define success criteria and a way to test against them before you tune a prompt.

How businesses use it

On our builds, prompts are treated as code. They live in version control with their test set beside them, and both are handed over with the runbook, because you own them.

For staff, prompting is a skill worth an afternoon of training. Our AI workshops teach teams to give context, show an example, ask for a format and check the result, using their own documents. The AI acceptable use policy template covers what staff may paste into public tools.

Where it goes wrong

The common failures are untested edits, prompts that grow into 4-page lists of special cases, prompts tuned for one model that degrade after a provider upgrade, and customer data written into prompts that end up in logs.

Prompting also has limits. If the model lacks facts, retrieval fixes that; see RAG. If outputs must be exact, add validation code. And no prompt fully stops prompt injection. That takes permissions and checks outside the model.