A production prompt is not portable in the way application code is portable. It is closer to a dependency on a specific runtime, and it needs the same kind of maintenance we already expect around packages, APIs, and frameworks.
That has been one of the clearer lessons from building with models every day. The temptation is to think of a prompt as a clean instruction. Write it well once, then move it between models as better ones arrive. In practice, prompts are written against behavior. They depend on what a model notices, what it ignores, how it handles structure, where it drifts, and what it does when the task gets long.
We saw this directly in the Speedrun digest work. The same prompt that worked on one model version broke on another. It did not fail loudly. It put content in the wrong place. Another model change produced a stranger failure. The beginning of the output was strong, then the quality tailed off near the end into weak, bullet-like writing. The fix was not better phrasing. The work had to be split into smaller sections.
That is the useful part. A model upgrade is not just an upgrade. It is a behavior change inside the product.
The same thing shows up even more clearly with images. When the output is visual, model differences become obvious immediately. The same prompt, input, and settings can produce outputs with a different sense of composition, literalness, polish, or weirdness. You stop thinking of prompts as universal and start thinking of them as coupled to a specific model.
That changes how we should treat prompt work. Saved runs matter. The model name matters. The exact prompt matters. The inputs, settings, references, and output all matter. Without that history, you cannot tell whether a new model actually improved the product or just changed it.
This is the maintenance problem we are starting to design around. When a package changes its API, we expect tests, version pins, migration work, and regressions. Model changes need the same discipline. A prompt may still read correctly to a human while failing against the new behavior of the model underneath it.
This is one of the odd parts of building in the open with AI. Some of the real engineering work does not look like code. It looks like running variants, comparing outputs, noticing failure modes, and deciding when a newer model is not worth the migration yet.
The prompt is not just copy. It is a maintained dependency in the system.
