Prompts are code. Version them like it.
A prompt is the most load-bearing string in an AI feature, and it usually lives somewhere nobody can diff.
Ask a team where their production prompts live and you get a pause. Some are in the codebase. Some are in a console field somebody edited last March. A few are in a shared doc with three tabs of variants and no note about which one won.
That is a strange place to keep the string that decides what your product says to customers.
Treat the prompt as an artifact
The bar is not high. A prompt should have a version, an owner, a diff history, and an evaluation you can run before and after a change. That is the same list you would demand of a pricing rule or a permissions check, and a prompt has comparable blast radius.
The practical payoff is regression. When output quality drops, the first question is what changed — and if the prompt is not in history, you cannot answer it. We have watched teams spend a week blaming a model upgrade for a change someone made in a text box.
Evaluate before you edit
Keep twenty to fifty real inputs with the outputs you want. Not synthetic ones — real traffic, including the ugly cases. Run them before a prompt change and after. Most prompt “improvements” help the case you were staring at and quietly hurt two others, and you will not notice without the set.
Fifty examples in a file beats an elaborate eval framework nobody runs. Start there.
Why we built AlphaPrompt
Our own prompts were scattered across three products and a lot of scratch files. We wanted one library with search that actually finds things, scoring that says what is weak instead of “consider being more specific,” and a way to rebuild an old prompt without starting from a blank box. That became AlphaPrompt.
Use it or do not — but pick somewhere for your prompts to live where two people can see the same version.
Written by Tommy Shrove, BluuAlpha Technologies.