
In most codebases we review, the prompt is a multi-line string in the middle of a service file, edited directly in production by whoever was closest to the problem. It is the single most behaviour-defining artefact in the system and it receives none of the discipline applied to a database migration.
A prompt change is a behaviour change
Rewording an instruction can alter output format, tone, refusal behaviour and accuracy simultaneously, across every feature that shares the prompt. That is a deployment, and it should look like one: reviewed, tested, versioned and reversible. Treating it as a text edit is why so many AI systems degrade quietly.
Nobody edits a database migration in production. Prompts deserve the same respect.
Version and externalise
Move prompts out of application code into versioned files or a prompt store, each with an identifier. Log the prompt version alongside every request so any output can be traced to the exact instruction that produced it. When quality drops, this turns an investigation into a lookup.
Review like code
A prompt change should arrive as a pull request with the evaluation score attached — before and after, on the same golden set. This makes the conversation empirical: not 'this wording feels better' but 'this moves the score from 0.78 to 0.84 with no regression on refusals'.
Structure beats length
Long prompts accumulate contradictory instructions added by different people to fix different bugs. Sections with clear roles — task, constraints, output format, examples — keep them maintainable and make it obvious where a new rule belongs. When a prompt exceeds a screen, the discipline matters more than the wording.
Roll out gradually
Ship prompt changes behind a flag to a percentage of traffic and compare quality signals before full release. Prompts interact with real input distributions in ways an evaluation set cannot fully capture, and a staged rollout catches the difference cheaply.
Pin the model too
A prompt is only half the behaviour; the model version is the other half. Pin it explicitly rather than accepting whatever an alias points at, and treat a model upgrade as a change requiring the same evaluation and rollout. Silent provider updates are a real cause of unexplained quality shifts.





