The prompt is the interface contract between your application and the model. Treated as chat, it drifts. Treated as a specification, it can be reviewed and tested.
The prompt is not a message
In a demo, a prompt is something a person types. In a product, it is a template that runs thousands of times a day with a variable substituted into it, and it determines the behaviour of the feature as surely as any function in the codebase.
Once you see it that way, the engineering practice follows. It lives in version control, not in a spreadsheet. It goes through review. It has a set of cases that must keep passing before a change ships. Teams that skip this end up with a feature nobody can explain, because the prompt was edited last month by someone who has since moved on.
Four things every working prompt states
Role and audience. Who the model is answering as, and who is reading. "Answer as a maintenance planner writing for a shift technician" removes an enormous amount of drift.
The context, supplied explicitly. Do not rely on the model knowing your equipment, your terminology, or your standards. Put the relevant material in the prompt. If it is not in the context window, for practical purposes it does not exist.
The constraints. Length, tone, what to do when the information is insufficient. That last one matters most: without an instruction to say "not enough information", a model will produce something rather than nothing, every time.
The output shape. If your code parses the result, specify the structure exactly and validate what comes back. A model that returns prose where you expected three fields is not misbehaving; it was not told.
Anything you leave unstated, the model will fill in — plausibly, confidently, and differently each time.
Techniques, in order of usefulness
Asking the model to work through its reasoning before answering — chain of thought — helps most on multi-step problems, and has a second benefit: the working is visible, so a reviewer can see where an answer went wrong instead of only that it did.
Giving two or three worked examples in the prompt sets the pattern more reliably than any amount of description. Breaking a hard question into a sequence of simpler ones, each building on the last, beats asking for the whole thing at once. And where a task is genuinely open, generating several candidates and selecting among them is more dependable than trying to get the first attempt right.
The list of named techniques is long and grows monthly. Nearly all of them are variations on two ideas: give the model more relevant context, and give it room to work in steps.
Improve it the way you improve anything
Build a set of real cases — actual questions from actual users, with the answers you would accept. Change one thing. Re-run the set. Keep the change if it helped.
This is unglamorous and it is the entire difference between a feature that gets better and one that oscillates. Without a fixed set of cases, every prompt edit is a guess, and nobody can tell whether last week's change made things worse.
Written by the software delivery team. Published articles carry a named author once attribution is confirmed.
