Three engineers run one assistant with six prompts. A vendor is offering a hosted prompt registry with live editing and a dashboard. Where should those six prompts live?
Show the full answer Hide the answer
The deciding property
A prompt change is a behaviour change, so the only question that matters is whether it gets the same review, test and rollback as a code change. At six prompts and three engineers, the repository already provides all three at no cost: pull-request review, CI, a tagged release, and a revert that takes 30 seconds. Nothing needs to be built, and nothing new has to be operated in production.
The registry proposition is different. It exists to decouple prompt edits from the deploy train, which is valuable once the number of prompts, the number of teams touching them, or the edit rate makes a deploy per edit the bottleneck. None of those is true for three engineers shipping daily. The price of adopting it early is a second system on the critical path of every request, with its own availability, its own cache and its own audit gap.
Why the repository wins at this size
- The diff is reviewable. A 40-line system prompt in a file shows up in the PR with blame and a reason in the commit message. The same edit in a web form leaves "modified by, 14:12" and nothing else.
- The prompt and the code that formats it move together. A prompt expecting a new retrieved-context block is useless without the code that supplies it. Splitting them creates a two-system deploy where one half can be older than the other.
- Rollback is already solved. Rolling back the release rolls back the prompt, the model id, the temperature and the parsing code in one move, because they shipped as one artifact.
Why the other options fail
- The hosted registry so product managers can edit live. Right at 50 prompts across nine services with content people owning copy. Wrong here, because it buys a live edit path into production behaviour before any regression suite exists to gate it, and the first bad edit has no review and no revert.
- A database table read at startup. This is the registry built badly: no review, no history, no environment separation, and a restart-ordering bug where instances on either side of a deploy read different rows.
- Environment variables. Prompts are multi-line text with quotes and braces; they get mangled, truncated at platform limits, and stop being diffable. "Changes without a deploy" is the goal of a config-push mechanism, not a side effect you want from your secret store.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Non-engineers own the wording | A registry with review | The deploy train becomes a people bottleneck |
| More than roughly 20 prompts across more than 2 services | A registry | Finding and auditing prompts in code stops working |
| Prompt edits exceed roughly 20 a week | A registry | The deploy train becomes the rate limiter |
| Prompts must change during an incident | A config push with versions | A deploy is too slow when minutes count |
| An A/B test per prompt is needed | A registry with variant assignment | The code path cannot hold the assignment logic cleanly |
When this is the wrong answer
If the business has already committed to non-engineers owning the wording, arguing for files is losing the argument you should be having. Put the prompts in a registry on day one, and spend the effort on the gate instead: every variant pinned to a model snapshot, a regression suite that runs before activation, and an instant revert. The registry is not the risk. A live edit path with no test in front of it is.