Your branching strategy never planned for prompt changes

A principal engineer at a marketplace company described the moment they realized their change control had a hole in it. They had a disciplined branching model, every code change went through a branch, a pull request, review, and a merge, with a clean history of who changed what and why. Then someone changed the AI feature’s prompt directly in a configuration store, in production, to fix a bad answer, and it worked, and there was no branch, no review, no history, and no record of why. The most behavior-defining part of the feature was being edited outside every control they had built for code. Their branching strategy governed the code carefully and had never once considered the prompt.

Change control was built for code, and the prompt escaped it

A branching strategy is really a change-control discipline. It ensures that changes are proposed, reviewed, recorded, and revertible, and it works because all the changes that matter go through the code, and the code goes through the branches. The whole apparatus assumes that changing the system means changing the code, which was true for a long time.

AI features break that assumption by putting a large share of the behavior outside the code. The prompt, the model version, the configuration that shapes the output, these define how the feature behaves, and they frequently live in stores that are edited directly, outside the branching model entirely. So a change to the prompt, which can alter the feature’s behavior as much as any code change, happens with none of the controls that every code change gets. No review, because the config store has no review. No history, because it was not a commit. No clear revert, because there is no branch to roll back. The team’s careful change control governs the code and is blind to the prompt, which means the most impactful changes to the feature are the least controlled ones. That is exactly backwards.

The reason this persists is that editing the prompt in a config store is easy and fast, and during an incident that speed feels like a feature. You fix the bad answer in seconds. The cost is invisible until later, when nobody can say what the prompt used to be, why it changed, who changed it, or how to get back to a version that worked. The ungoverned change felt free at the time and turns out to have been borrowed against the next incident.

Bring the behavior-defining layers under control

The lesson is that anything which defines the feature’s behavior belongs under the same change control as the code, because a change to the prompt deserves the review, history, and revertibility that a change to the code gets. The branching strategy has to reach the prompt, not just the code.

What teams do to govern the changes their branching model was missing.

Put prompts under version control, so a prompt change has a history, an author, and a reason, like any commit.
Review prompt changes the way you review code, since a prompt edit can change behavior as much as a code edit.
Track the model version as a controlled configuration, so a change to which model runs is a deliberate, recorded decision.
Make prompt and config changes revertible, so you can roll back to a known-good version instead of guessing what it was.
Close the direct-edit path in production, or at least record every use of it, so the fast fix does not escape the history.

The goal is that every change which affects the feature’s behavior is proposed, reviewed, recorded, and revertible, whether it is a line of code or a line of a prompt. Right now, for many teams, the code is governed and the prompt is the wild west.

How we approach it at Density Labs

The ungoverned prompt is one of the most common gaps we find, and it is a direct consequence of change control being built for a code-only world. The team has excellent discipline around the code and none around the prompt, not by choice, but because their branching strategy predates the idea that behavior could live outside the repo. The most powerful lever on the feature is the least controlled one.

When we help a team put an AI feature on solid footing, we bring the prompt, the model version, and the config under the same change control as the code, so the feature’s behavior changes through a governed path and not through a direct edit nobody recorded.

Your branching strategy controls the code. For an AI feature, that is only half of what changes the behavior, and the other half needs the same discipline.