Prompts Are Code, So We Stopped Editing Them Like Prose
Our main system prompt reached nine hundred words, assembled by six people over four months. Every line had been added for a reason and none of the reasons were written down.
How It Got There
Nine hundred words, and every one of them defensible in isolation. A line about not inventing order numbers, added after an incident. A paragraph on tone, added after a complaint. Three sentences about date formats that overlap and mildly contradict each other, added by different people in different weeks.
The symptom was not bad output. It was paralysis. A change request would arrive, someone would look at the prompt, and the conversation would end with nobody willing to remove anything in case it was load-bearing.
The Framing We Borrowed
Khattab and colleagues proposed treating language model pipelines as programs to be compiled rather than prompts to be hand-written, with the wording produced and improved against a metric instead of edited by feel.
We did not adopt the framework. We adopted the premise, which is the part that transfers: if a prompt determines behaviour, it is a component, and components get versioned, reviewed and tested. Editing one by feel is editing production behaviour without a test.
What We Actually Do
The prompt is assembled from named fragments, each in its own file, each with a comment recording why it exists and which incident or requirement it came from. The assembled result is what ships; the fragments are what people edit.
Every fragment that asserts a behaviour has at least one case in the evaluation set that fails when the fragment is removed. That is the whole discipline, and it is what makes deletion possible: remove the fragment, run the set, and see whether anything actually depended on it.
| Prompt as prose | Prompt as component |
|---|---|
| One long file everyone edits | Named fragments with an owner |
| Why a line exists is folklore | Recorded next to the line |
| Deletion is a gamble | Deletion is a test run |
| Changes reviewed by reading | Changes reviewed by diff and result |
What the First Pass Found
About two hundred words failed the test: removing them changed nothing measurable. Some were duplicates phrased differently. Some instructed behaviour the model already had. One paragraph addressed a failure mode that a schema change had eliminated months earlier.
We deleted them. Output quality did not move, latency and token cost improved slightly, and the remaining seven hundred words became something a new colleague could read in one sitting.
Where It Costs Us
The discipline is not free. Every behavioural fragment needs a case, and writing a case that genuinely fails without the fragment takes longer than writing the fragment. For small prompts the overhead is not worth it, and we do not apply this below roughly a hundred words.
There is also a failure mode we watch for: a case that passes for the wrong reason, so the fragment looks necessary when the model would have behaved correctly anyway. We catch some of those by removing two fragments at once and seeing whether the failure count matches.
What We Do Not Claim
We do not claim automated prompt optimisation is unnecessary. For pipelines with a clear metric it plainly beats hand-editing, and we would use it where the metric is trustworthy. Ours often is not, which is a statement about our evaluation rather than about the method.
We also do not claim a tested prompt is a correct one. The tests encode the failures we already know about. The prompt is still a set of instructions to a system that can decline to follow them.