A prompt that has been refined over weeks often behaves differently after a provider updates the underlying model. Keeping it working is a matter of how the prompt was written, not of monitoring the release notes.
Refinement encodes version-specific workarounds
Iterating on a prompt means adding lines until a particular failure stops. Each of those lines is a response to how one model version behaved.
When the version changes, the failure may be gone while the workaround remains, and the workaround can now cause its own problem by pushing behavior somewhere unnecessary.
The accumulated result is a prompt that solved a set of problems, most of which no longer exist, using instructions nobody remembers the reason for.
Separate the task from the coaxing
Write the prompt in two clearly marked parts. The first states the task, the inputs, the required output format and the genuine constraints of the job.
The second holds behavioral corrections: the reminders about tone, the instruction not to add a summary, the emphasis added because one version kept drifting.
After an update, the second part is the part to test by removal. The first part should not need to change, because the job did not change.
Keep the test set from the original tuning
The reason a prompt drifts unnoticed is that nobody reruns the cases it was built to handle. Those cases are the only evidence of what it used to do.
Storing the inputs alongside the prompt turns an update from an investigation into a ten-minute comparison against known-good behavior.
Without the set, evaluating a new version means forming an impression from a few outputs, which is exactly the method that misses regressions.
Pin the version where the output feeds something else
Where a prompt's output is consumed by another system, an unannounced behavior change is a breakage rather than a quality shift.
Most providers allow addressing a specific model version rather than a moving alias. Using the pinned name converts a surprise into a scheduled migration you perform when ready.
The tradeoff is that pinned versions are eventually retired, so pinning buys time rather than permanence and should be paired with a note about when to revisit.
Rewrite rather than patch when drift is large
If a prompt needs several new corrections to work with a new version, the accumulated old ones are probably fighting it.
Rewriting from the task description alone frequently produces something shorter that works immediately, because the new version does not need the old scaffolding.
Keeping the previous prompt in a comment preserves the reasoning without letting stale instructions continue to act on the model.