What is prompt engineering?
Prompt engineering is the practice of designing, testing, and maintaining the instructions sent to a generative AI model so that it performs a specific task reliably. It covers the wording of the instructions, the examples included, the order of the material, the output format requested, and the way retrieved documents are presented. It also covers the less visible work of building a test set, measuring results, and keeping prompts under version control as the application and the model change.
The model’s behavior is fixed at training time. The prompt is the main control a business has over that behavior without fine-tuning, which is why prompt engineering is the first adaptation method teams reach for and the one with the fastest feedback loop.
Common prompt engineering techniques
- Role and audience tell the model who it is writing as and for whom, which sets vocabulary and depth.
- Explicit instructions state what to do, what to leave out, and what to do when the task cannot be completed, in numbered steps where order matters.
- Few-shot prompting includes two to five worked examples of input and ideal output, which teaches format and judgment faster than description.
- Chain-of-thought prompting asks the model to work through the problem step by step before giving the answer, which improves accuracy on multi-step reasoning.
- Delimiters and labels separate instructions from the document being processed, so the model does not mistake document text for commands.
- Structured outputs request a specific JSON schema or table so downstream code can consume the result without parsing prose.
Prompt engineering in practice
A manufacturer’s accounts payable team receives invoices from hundreds of suppliers and must code each line to a general ledger account and cost center. A first prompt that said “assign a GL code” was right about half the time. The team rewrote it to include the chart of accounts with a one-line description per account, the vendor’s past coding history retrieved from the ERP, five examples of correctly coded invoices, and a rule to return “needs review” with a reason when the choice was unclear. Accuracy on a held-out set of two hundred invoices rose to a level the controller accepted, and the “needs review” output routed exceptions to a person.
In Kirk Tech Solutions engagements, every production prompt has a named owner, lives in version control, and ships with a test set of real inputs and expected outputs that runs before any change goes live.
Prompt engineering compared with fine-tuning
| Aspect | Prompt engineering | Fine-tuning |
|---|---|---|
| Time to change behavior | Minutes | Hours to days, plus redeployment |
| Data required | A handful of examples | Hundreds to thousands of reviewed examples |
| Cost per request | Higher, because instructions and examples are sent every time | Lower, because the behavior is in the weights |
| Portability | Mostly transfers to a new model with adjustment | Must be redone for each new base model |
What to watch for
- A prompt that works on ten examples can fail on the eleventh, so build a test set of at least fifty real cases before declaring success.
- Negative instructions (“do not mention competitors”) are weaker than positive ones that say what to do instead.
- Prompts are brittle across model versions, so re-run the test set whenever the model changes, including silent updates from an API provider.
- Prompt caching can offset the cost of long prompts, since the fixed instructions and examples are the same on every request.
- Prompt engineering cannot teach the model facts it never saw, which is the job of retrieval-augmented generation.