Six months ago I watched a team push a small prompt tweak to production on a Friday afternoon. By Monday, customer-facing quality scores had dropped 18 percent across three surfaces. Nobody knew exactly when the change went in. The old prompt only existed in a Slack thread someone had to scroll back to find. Rollback took six hours. The team was good and not careless. They just had not built any operational layer under their AI product, so a single intern with edit access to a Notion page could break production for everyone. If your prompts live in a Google Doc and get pasted into the codebase by hand, you do not have a product. You have a liability with a UI on top.
The thesis
Prompts deserve the same lifecycle as code: version control, code review, automated evaluation on every change, staged rollout, monitoring, and one-click rollback. A prompt change without an eval run is a deploy without a test.
The five-piece stack
You do not need exotic tooling. You need five things, in order.
A prompt repository. Prompts live in your codebase in version control, in a prompts/ directory. Each is a file with a header for purpose, owner, and last-evaluated timestamp. The prompt that runs in production is the file in main. One source of truth, no Google Docs.
A prompt review workflow. Changes go through pull requests. The PR template requires three fields: what changed, what eval set it ran against, and the score delta. PRs without an eval run cannot merge.
An eval harness on every change. Before merge, the prompt runs automatically against its named eval set. Score, per-slice deltas, and newly failing examples get posted to the PR. This is the AI-product version of a CI test suite. Without it you do not have a deploy pipeline, you have hope.
Staged rollout. New prompts deploy to 1 percent of traffic first, monitored against the offline eval for 24 hours. If live agrees with offline, ramp to 10, then 50, then 100. If they diverge, you found a gap in your eval set.
One-click rollback. Every deployed prompt has a one-command revert the on-call engineer or the PM can trigger without a ticket. Rollback is routine, not heroic.
Who owns the prompt
The PM owns the prompt, engineering owns the wiring, and this is non-negotiable. The temptation is to let engineering write the prompt because they understand the system. That is backwards. The prompt is the spec. It encodes what the system does, who it is for, when it refuses, what tone it uses. Those are PM decisions. If your engineers are writing your prompts, you have not yet translated the product decision into a contract.
Move one prompt into your repo this week. Add a header, wire your code to load it from the file, make a change through a PR so the diff is legible, then add an eval set into CI. That is v1 of prompt ops, half a day of work, and your product gets meaningfully harder to break by accident.