In brief
- A prompt can contain the task, background, examples, boundaries and output format.
- Good prompts are versioned application components and are tested against fixed cases.
- Prompts cannot reliably prevent hallucinations or unauthorised actions.
- Data access, permissions, calculations and approvals belong in the surrounding software.
What belongs in a useful instruction?
A useful instruction makes its objective and expected result testable. It supplies only necessary context and clearly separates binding rules from untrusted user content. Examples help where style or structure is difficult to describe in words alone. The comparison also shows where better wording ends and technical controls begin.
| Requirement | Vague prompt | Structured instruction | Control outside the prompt |
|---|---|---|---|
| Task | ‘Handle the complaint well.’ | Audience, tone, required information, length and escalation cases are specified. | Test cases measure completeness and permitted response types. |
| Facts | ‘Use correct customer data.’ | Only supplied sources may be used and missing facts must be stated. | An authorised API or RAG supplies current data with provenance. |
| Calculation | ‘Calculate the refund exactly.’ | The expected result and required input fields are described. | A validated function calculates amount, currency and limits. |
| Permission | ‘Show only information the user may see.’ | The instruction states the permitted purpose but is not an access barrier. | Identity and rights are enforced before data access and model transfer. |
| Action | ‘Send the response only when safe.’ | Criteria for drafting, clarification and escalation are defined. | Server-side rules and human approval control sending. |
Why is prompt engineering more than writing?
A professional prompt is not optimised by intuition alone. The team defines quality criteria, collects representative cases, compares variants and documents changes. Only this connection between instruction and evaluation makes improvements traceable.
- Step 1
Define success
Specify which claims, formats and boundaries must be satisfied.
- Step 2
Collect cases
Cover normal, difficult and deliberately unanswerable inputs.
- Step 3
Test variants
Compare prompt changes under identical conditions.
- Step 4
Version
Keep prompt, model and test results traceable together.
Which problems cannot a prompt solve?
A prompt is an instruction to a probabilistic model, not a technical security boundary. Content from documents or users can conflict with it or be deliberately manipulative. The model can also apply rules incorrectly even when they are worded clearly.
- Missing or outdated facts need a reliable data source
- Permissions must be enforced technically outside the model
- Exact calculations belong in validated functions
- Irreversible actions require server-side rules and approvals
- Quality needs evals and monitoring rather than trust in wording
When should the solution change instead of the prompt?
If the same errors persist despite clear instructions, the system often lacks context, an appropriate tool or a controlled process stage. The team should then review the architecture and task instead of endlessly refining wording.
- Use RAG when current internal sources are missing
- Use an API or calculation function when exact live values are required
- Enforce structured output when downstream software processes fields
- Choose a workflow over free generation when steps are mandatory
- Narrow the task when quality cannot be assessed reliably
Example: drafting responses to complaints
The prompt specifies tone, required information and cases that must go to a specialist. Customer data and contract status come from an authorised interface, refund limits are checked by business logic and sending requires confirmation. Test cases cover several languages and disputed cases. The prompt guides the draft, but it does not control permissions or payment.
What to remember
Optimise prompts with measurable cases and recognise their boundary. As soon as facts, permissions or consequences matter, technical controls outside the model are required.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed