AI Engineering · LLM applications that ship
How do you version and ship prompts?
Short answer
Treat prompts as versioned code: store them with the application, review changes, tie each version to eval results and deploy with a rollback path. Avoid editing production prompts by hand.
Prompts change behaviour as much as code does. If they live in a dashboard and are edited ad hoc, nobody knows which version produced a given answer. Versioning makes the prompt part of the release, reviewable and reproducible.
- Keep prompts in the repository or a versioned config service with an owner.
- Record the prompt version on every trace and eval result.
- Require eval results and a reviewer before promoting a change.
- Support canary or staged rollout and fast rollback.
- Document why each version changed, not just what changed.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Where would you store a prompt that non-engineers need to edit?
- 2How do you roll back a prompt in an incident?
- 3What would you include in a prompt changelog?
Say it in the interview
I version prompts like code. They live in the repository or a versioned config service, get reviewed, and ship with eval results. Every trace records which prompt version produced the answer, so incidents are reproducible. I also support staged rollout and rollback. When the provider updates the underlying model, I re-run the evals even if the prompt did not change, because behaviour can shift underneath us.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live AI Engineering mock interview and get scored feedback on depth, clarity and confidence.