Your prompts are code. Stop editing them in a playground and shipping.

The pattern is everywhere and it goes like this. Someone opens the provider's playground, tweaks the system prompt until it handles the three cases they're thinking about, copies the new string, pastes it into the production code or config, and ships. No diff. No review. No test against anything but the handful of examples in their head. A week later something that used to work is subtly broken, and nobody can say exactly when the prompt changed or what it used to say, because the change left no trace.

This happens because of a category error. In an LLM-powered feature, the prompt is not configuration. It is a large part of the program's logic, often the part that most determines behavior, and yet teams apply real engineering discipline to their code, version control, review, CI, tests, and treat the prompt as a disposable string they can edit anywhere and ship from anywhere. The model gets all the respect and the instructions that actually steer it get none.

The fix is to take the reframe seriously: the prompt is code, and it gets what code gets.

It lives in version control. Prompts belong in the repo, as files, diffable, with history, so a change is a commit somebody can see and trace. The instant a prompt has a commit history, the "what did it used to say and when did this break" question has an answer, which is more than most teams can offer today.

It gets reviewed. A prompt change can alter product behavior as much as a code change can, sometimes more, so it deserves a second pair of eyes for the same reason any behavior-changing diff does. "It's just a prompt tweak" is exactly the kind of change that ships a regression precisely because everyone waved it through.

It gets tested. This is the one that matters most. Run your eval set on every prompt change, in CI, and treat a prompt that regresses the evals the way you'd treat a failing test: it doesn't ship. Without this, every prompt edit is a blind bet, because prompts are global and a change made to fix one behavior ripples into others you weren't looking at, the same dynamic that makes model upgrades dangerous. The eval set is the only thing that lets you see the ripple before your users do.

And it gets rolled back the same way. When a prompt change misbehaves in production, you revert a commit, not reconstruct from memory what the string used to be. That alone is worth the discipline.

A couple of structural habits follow from this. Keep prompts as files or templates rather than buried in string literals scattered through the code, so they're findable and editable by the people who actually tune them, who at some companies aren't the engineers. At scale this grows into a prompt registry, but a folder of versioned prompt files is the ninety-percent version and a fine place to start. And because a prompt is also your stable cache prefix, churning it constantly quietly wrecks your cache hit rate, which is one more reason to change prompts deliberately and through a pipeline rather than continuously and by hand.

None of this means you can't use the playground. The playground is the right place to explore, to feel out a change. What it isn't is a deployment mechanism. The exploration happens there; the production prompt ships through the same pipeline as the rest of your program, against the same eval gate, with the same review and the same ability to roll back. The prompt is program logic that happens to be written in English. Give the English the engineering.