Versioning and Managing Prompts
Where prompts should live, how to version and review them, when a prompt management tool helps, and how to roll back a bad change fast.
It's 4:40 on a Friday. A prompt change shipped at lunch, and now the support team is reporting that drafted replies have started promising callbacks nobody scheduled. You need the old behavior back. How long does that take? If the answer is "find the old text in git history, open a PR, wait for review and a deploy," you're looking at an hour of bad drafts. If the answer is "flip a version number," it's thirty seconds.
This lesson is about building the second setup. You'll decide where prompts should live, make every version immutable and addressable, catch "silent" edits to released prompts in CI, weigh when a prompt management platform is worth adopting, and set up rollback that doesn't need a deploy.
Where prompts can live
Prompts Are Product Code made the case for one module per prompt, holding the text, model, effort, and token limit together with an ID and version. That answers what a prompt is. The next question is where it lives, and there are really five options:
| Location | Good for | Main risk |
|---|---|---|
| Inline strings in feature code | Throwaway prototypes | Prompts scattered, unreviewed, unversioned |
| Prompt modules in the repo | Most teams, most features | Every change needs a deploy |
| Text or Markdown files in the repo | Long prompts edited by non-engineers via PRs | Loading files at runtime on serverless platforms |
| A prompt management platform | Frequent non-engineer iteration, many services | Runtime dependency; prompt and code drift apart |
| Your own database and admin panel | Per-customer prompt customization | Becomes an unreviewed production editor |
The default for most teams is prompt modules in the repo. Prompts get the same review, history, and CI as code, they ship atomically with the code that parses their output, and you need no extra infrastructure. The "every change needs a deploy" downside is smaller than it sounds once rollback is handled by switching versions, which this lesson sets up.
The database option deserves a specific warning. It's common to start with "let admins tweak the tone" and end up with a text field that silently controls production behavior for every customer, edited with no review and no history. If you need per-customer customization, store a small, structured set of settings (tone, sign-off, product names) and render them into a reviewed template, rather than storing whole prompts.