A prompt that worked reliably six months ago may quietly produce worse output today. The model changed underneath it, the inputs drifted, or someone edited one line to fix a single bad case and broke three good ones. None of this shows up as an error — the model still returns fluent, confident text. It is simply less correct than it was.
The teams that avoid this treat prompts the way they treat code that has no type checker: with tests. A fixed set of ten to twenty real inputs, each with a known-good output, re-run whenever the prompt changes or the model updates. It takes an afternoon to build and it is the difference between engineering a prompt and adjusting one hopefully.
The second failure is ownership. Prompts that live in someone's notes app leave when that person changes team. A library needs an owner per section, a review cadence, and a rule that says an undocumented prompt is not part of the library — regardless of how well it works for the person who wrote it.
None of this is exotic tooling. It is the same discipline applied to any other dependency: pin it, test it, own it, and know when it broke.