A platform's prompts are embedded in application code and changed frequently. What problems arise, and how should prompts be managed?

The problems

1. Outputs cannot be reproduced or explained. A support question about an output from three weeks ago is unanswerable if the prompt has changed and no version was recorded.

2. Regressions cannot be bisected. Quality degrades, and nobody can identify which of forty prompt changes caused it.

3. Changes are unmeasured. Without a version and an evaluation run per version, a prompt change is an unmeasured behaviour change shipped to users.

4. Prompts diverge across features that should behave consistently, because there is no shared component.

5. Iteration requires a deployment, so the people best placed to improve prompts — often not engineers — cannot.

How they should be managed

As versioned artefacts with the properties of code, and a faster release path.

• Versioned and stored, with the version recorded on every output alongside the model version, so any output is reproducible.
• Evaluated before release against a held-out set, with results attached to the version. This is what turns prompt changes from taste into engineering.
• Released independently of code, so iteration does not require a deployment — with the same rigour of staged rollout and instant rollback.
• Composed from shared components — a common safety preamble, a common output format specification — so cross-cutting changes are made once.
• Reviewed, because a prompt change is a behaviour change and deserves the same scrutiny as code.
• Parameterised rather than concatenated, with user content clearly delimited — which is also the structural precondition for injection defence.

The evaluation link

Prompt versioning without evaluation is bookkeeping. The value comes from being able to say "version 14 scored better than version 13 on this set", which requires the held-out set to exist and to be maintained as the product evolves.

The trap

Treating prompts as configuration that anyone can change instantly. They are behaviour, and behaviour changes need staged rollout, evaluation and rollback. A prompt pushed globally without evaluation is a production change with no test — and because the failure is a quality degradation rather than an error, no alarm fires.