Prompt Engineering
Prompt engineering is the practice of designing what a language model is given — the instructions, the role, the context, the examples, the output format and the constraints — so that it produces reliable, correct and correctly formatted output for a task; it moved from tricks in 2022 to a discipline by 2024, with versioned prompts, evaluation sets and review, and it is the first tool to reach for before fine-tuning. A prompt cannot guarantee safety or add knowledge.
- Also known as
- Prompt design, Prompt optimisation, Prompting techniques, Context engineering
- Used at
- every application built on a language model — assistants, extraction, classification, summarisation, code generation, agents — where the prompt is the specification of the task; also by individual users, whose skill at prompting decides what they get
- Binding
- none on the practice; the outputs a prompt produces are subject to whatever rules govern them, and a prompt that makes a model produce advice, promises or discriminatory output is the deployer's problem; prompts containing customer data are subject to data protection and the vendor's terms
- Typical techniques
- clear task and role statements; explicit output formats and schemas; few-shot examples for unusual tasks; chain-of-thought instructions for multi-step problems; decomposition of complex tasks into steps; separation of instructions from data with delimiters; constraints and refusals stated positively; retrieval to supply facts; and system prompts distinct from user messages
- Typical discipline
- prompts stored in version control, changed through review, tested against an evaluation set on every change, with metrics for accuracy, format validity and failure modes; A/B tests in production; documentation of what each prompt is for and what it was measured to do
- Parties
- the engineers and product people who write prompts, the domain experts who specify what good output is, the evaluators who build test sets, and, since 2024, the models themselves, which are used to draft and optimise prompts
How prompt engineering works in practice
A team needs a model to extract fields from invoices into a schema. Version one, "extract the fields from this invoice", produces prose with the fields in varying order and invented values for missing ones: 71% field accuracy. Version two states the role, lists the fields with definitions and formats, requires JSON matching a schema, instructs "null if not present — never guess", adds three examples including one with missing fields, and asks the model to quote the source text for each field: 92% accuracy, valid JSON on 99.5% of documents, and the quotes let a verifier check each value. Version three adds a chain-of-thought step for the total (the model was miscalculating tax) and moves to a structured-output API: 95%. Each version was measured on the same 400 invoices; the prompt lives in the repository with its evaluation results; and a change to the schema goes through the same process.
The craft is specific and the discipline is what makes it engineering. Specificity beats length: a precise format instruction outperforms a page of guidance. Examples teach what words cannot. Asking for the reasoning improves hard tasks and costs tokens on easy ones. Separating instructions from the data the model reads reduces injection. And every prompt has a ceiling set by the model and the task: when a prompt has been optimised and the accuracy is still short, the next steps are retrieval (if the model lacks facts), a larger model (if it lacks capability), or fine-tuning (if the task is narrow and the volume high). For a fintech, prompts are control documents — the specification of what the model does with customer data and what it must refuse — reviewed like policy; for a buyer, a target's prompt library, its evaluation results and its version history are the evidence that its AI features are engineered rather than improvised.
For a fintech founder, prompt engineering is where most language-model value is captured and the cheapest tool available; its discipline — versions, tests, review — is what turns a demo into a product.
Example
A payments company's dispute team uses a model to draft chargeback responses (representments) from the transaction record, the merchant's evidence and the scheme's reason-code rules. The first prompt produces fluent letters that cite evidence the merchant did not provide: a 35% rate of unsupported claims found in review. Engineering over three weeks: the prompt lists the reason code's required evidence from the scheme rules, instructs the model to include only evidence present in the provided documents and to cite each item, requires a structured output with an evidence checklist, adds four worked examples, and adds a self-check step listing any required evidence that is missing. Unsupported claims fall to 2%; drafts that pass review without edits rise from 20% to 74%; win rates on represented disputes rise 9 points because the drafts are complete. The prompt is versioned with the scheme-rule updates it embeds.
Common mistakes
- Vague prompts and long ones; be specific and short. - No evaluation set, so every change is a guess. - Trusting the prompt for safety; controls belong outside the model. - Fine-tuning before the prompt has been engineered. - Prompts in a notebook rather than in version control with review.