Prompt Engineering as an Engineering Discipline

A prompt in production is code

Prompt engineering gets dismissed as fiddling with wording until the output looks right. That works for a demo. The moment a prompt drives a real workflow it becomes code that happens to be written in English, and it deserves the same discipline as any other code: it lives in version control, it has tests, it ships through review, and you can roll it back when a change makes things worse. Anything less and you are flying blind on a component that shapes every response your system produces.

The anti-pattern is a multi-paragraph prompt pasted as a string literal in the middle of a function, edited live in production, with no record of what the previous version said or why it changed. When quality regresses, nobody can tell what moved. Treat prompts as managed assets and that entire class of mystery simply disappears from your incident reviews.

Structure beats cleverness

Reliable prompts are built, not stumbled upon. A clear structure outperforms a clever turn of phrase nearly every time, and it is far easier for a teammate to maintain six months later. Clever phrasing is also brittle: it tends to work on one model and fall apart on the next, whereas plain, well-organised instructions travel far better across model upgrades.

• State the role and the task up front, then the constraints, then the output format. Models follow front-loaded instructions more reliably than ones buried at the end.
• Show, do not just tell. A couple of worked examples pin down the format and tone better than a paragraph describing them in the abstract.
• Specify the output contract precisely. If you need JSON, give the exact schema and say what to do when a field is unknown rather than leaving it to chance.
• Separate the instructions you control from the user input you do not, with clear delimiters, so untrusted text cannot quietly rewrite the task you set.

Evaluation is what makes it engineering

You cannot improve what you do not measure, and "it looks better to me" is not measurement. Build an evaluation set from real inputs — the messy, ambiguous ones your system actually receives — paired with the outputs you consider correct. Every prompt change runs against that set before it ships, so you catch the edit that fixes one case while quietly breaking five others. Without it, every change is a gamble dressed up as an improvement.

Keep a golden set of hard cases. The prompt that aces the easy examples and quietly fails the edge cases is the one that erodes trust in production.

Versioning and rollback

Store prompts outside application code — in a file, a config store, or a small prompt registry — keyed by version. Then a prompt change is a deploy you can reason about and reverse, not a silent edit lost to history. Pair each version with the evaluation scores it earned so you have a paper trail of what improved and what regressed, and so the next person to touch it inherits context instead of guesswork.

• Tag prompts with a version and log which version produced each output you serve.
• Make rollback a one-line change, not a code edit and a redeploy under pressure.
• When you change models, re-run your evaluations — a prompt tuned for one model is not guaranteed to behave the same on another.

Guarding against injection

Any prompt that includes user input or retrieved content is a target for prompt injection, where text in the input tries to override your instructions. You cannot solve this with wording alone, however carefully phrased. Defend in depth: keep system instructions separate from user content, constrain what the downstream tools can actually do, and validate the model's output before acting on it. The model proposing an action is never the same thing as that action being safe to execute.

One organisational habit ties all of this together: treat the prompt, the model version, and the evaluation set as a single versioned unit. A prompt that scored well last month against last month's model and last month's test cases tells you nothing about how it behaves today if any of those three has shifted. When you bump a model, refresh your hard cases, or rewrite an instruction, re-run the whole bundle and record the result. That discipline is unglamorous, and it is precisely what separates an LLM feature that degrades silently from one that improves on purpose.

How BSH can help

BSH Technologies brings software engineering rigour to LLM systems — prompt versioning, automated evaluation against real cases, rollback you can trust, and injection defences that hold up under real traffic. We help teams move past trial-and-error prompting to a process that improves measurably and behaves predictably. If your prompts are quietly running critical work, our team can help you put them on solid engineering footing.