Prompts only grow. A failure appears, someone adds a sentence to fix it, the failure goes away, and the sentence stays forever. A year later the prompt is a sediment of patches, and nobody can say which lines still do anything.
That has a real cost. Every instruction competes for the model's attention, can collide with others, and adds tokens to every single call. Some of those lines were written for a model version you no longer use, or for a failure that a later change already fixed.
Here is a small habit that helps: once a quarter, pick one instruction and delete it. Then run your eval set and compare.
There are only three outcomes, and all of them are useful:
- Nothing changes. The line was dead weight. Leave it deleted, and enjoy a shorter, cheaper, clearer prompt.
- Something specific gets worse. Now you know exactly what that line protects. Put it back, and write a comment beside it naming the failure it prevents and the eval case that covers it.
- Something gets better. The instruction was causing harm, perhaps colliding with another one. This happens more often than people expect.
Two things make the exercise work. First, you need an eval set that is good enough to notice a regression; if you cannot tell whether the deletion hurt, that is the more important finding. Second, delete one line at a time, so the result is attributable.
You don't need to do this for every line. Start with the oldest instructions, the ones nobody remembers adding, and the ones phrased as emphatic warnings in capital letters.
The aim is not a minimal prompt for its own sake. It is a prompt where every remaining line has earned its place with evidence, so the next engineer can edit it without fear.