Writing prompts your team can maintain
Prompts behave like code — they change behaviour, they regress, they accumulate — but arrive with none of the usual discipline. Keeping them in version control, recording why each rule exists, reviewing changes against an eval set and separating instructions from data makes them maintainable by a team rather than by whoever wrote them.
A prompt determines what your software does. That makes it code in every sense that matters, and it typically receives none of the treatment code gets — no review, no tests, no history, and often no agreement on where it even lives.
Put them in the repository
In files, in version control, next to the code that uses them. You get diffs, blame, review and rollback — all the things that make a change traceable six months later when the behaviour is mysterious.
Storing them in a database so they can be edited live sounds like agility and behaves like an untracked deployment. If someone non-technical must edit them, build that path deliberately with its own review and history.
Say why, not what
"Never mention competitors by name" is a rule. "Never mention competitors by name — legal asked for this after the March incident" is a rule the next person can evaluate. Without the reason, every line is permanent, because nobody dares remove something they do not understand.
Review them as changes
A one-word edit to a prompt can move accuracy several points. It should go through the same review as a one-word edit to a conditional, and it should be run against the eval set before merging.
Without that, prompt changes are the only part of the system that ships on vibes.
Separate instructions from data
String-interpolating user content into the middle of your instructions makes the prompt hard to read, hard to cache and easy to inject. Keep the instruction block fixed, pass content in its own clearly marked section, and say in the instructions that the marked content is data rather than direction.
It is better engineering and better security at once.
Prune deliberately
Prompts only grow unless someone makes them shrink. Schedule the pruning: remove a rule, run the evals, keep the removal if nothing moved.
A prompt half the length that scores the same is strictly better — cheaper, faster to cache, and considerably easier for the next person to reason about.
Frequently asked questions
Should prompts live in the database so they can be edited without a deploy?
It is tempting and it usually costs more than it saves: no diff, no review, no rollback, and a behaviour change nobody can trace. If non-engineers must edit them, give that editing a review step and a version history of its own.
How do I stop a prompt growing forever?
Require that every rule names the failure it prevents, and periodically delete one to see whether anything regresses. Prompts accumulate by default because removing a line feels riskier than adding one.
