Five Prompts You Should Delete Tomorrow

Most AI systems carry more prompt than they ever use. Time to simplify it before the model starts quietly ignoring half of what you wrote, because that is what happens once an instruction set gets long enough: the model does not fail loudly, it just stops weighting the buried parts.

Every quarter someone adds a new instruction. Handle this edge case. Never say that word. Always cite the source. Match this tone. Three months later half of those instructions contradict each other, nobody remembers why the third one is there, and the prompt has become an archive of every incident anyone was ever worried about, rather than a clear brief for the task at hand.

Repeat that pattern across a year and three people who touched the prompt, and you end up where most AI systems are: a wall of instructions nobody dares to shorten, half of them dead weight, and output that quietly gets worse each time one more line is added.

Why prompt bloat happens

Prompts grow the way attics grow. Nothing is ever the trigger for a full rewrite, so instructions accumulate through small, reasonable-looking additions instead. A bad output happens once, so a rule gets added to prevent it specifically, instead of fixing the underlying ambiguity. Nobody removes the rule later, because nobody can prove it is safe to remove, and removing something that might matter feels riskier than leaving it.

So the prompt only grows. And a model given forty instructions does not carefully weigh all forty. It pattern-matches on the ones that are clearest, most recent, or most repeated, and quietly deprioritises the rest. A long prompt does not make a model more careful. Past a certain point, it makes the model less predictable, because you no longer know which instructions it is actually using.

Five prompt patterns to delete tomorrow

1. The instruction for an edge case that never happened again. Something went wrong once, a rule was added to prevent that exact scenario, and it has not recurred since. If nobody can point to a second occurrence, the rule is not a safeguard. It is a monument to a single bad day.

2. The tone instruction repeated three different ways. “Be concise.” “Keep responses short.” “Avoid unnecessary length.” Three lines saying the same thing do not triple the effect. They just take up space that could hold an instruction that says something new.

3. The reference to a tool or API that was replaced months ago. The system moved to a new provider, a new endpoint, a new internal tool, and the old name is still in the prompt because rewriting that paragraph felt like more effort than it was worth. The model does not know it is stale. It just tries to use something that no longer exists.

4. The few-shot example nobody checks anymore. An example was added to demonstrate the right format, written for a version of the task that has since changed shape. The format it demonstrates is now subtly wrong, and because it is an example rather than a rule, the model treats it as more authoritative than the text around it.

5. The instruction that contradicts a newer one. “Never mention pricing” from six months ago sits two paragraphs above “always state the price range when asked” from last week. Nobody deleted the first when they wrote the second, so the model resolves the contradiction however it resolves contradictions, which is inconsistently.

An instruction you cannot explain the reason for is an instruction you should be able to delete.

What a lean prompt actually looks like

A working prompt is not the one with the most coverage. It is the one where every line earns its place, and where someone can explain, without checking a changelog, why each instruction is there. That means someone has to own it: read it end to end on a fixed schedule, ask of every line whether it is still true, and delete on sight anything that answers a question nobody is asking anymore.

The uncomfortable part is that this takes longer than adding a new line. Deleting requires understanding why something is there in the first place, and understanding takes more effort than typing one more sentence “just in case.” That is exactly why it does not happen on its own, and exactly why it has to be a scheduled discipline rather than a hope.

The ODB Way

At ODB Growth, every prompt, every glossary rule and every piece of system context gets the same question on a fixed review: can you explain why this line exists, and is it still true. If not, it goes, not because deleting is glamorous but because a system nobody can fully account for is a system nobody can fully trust.

That discipline is not a one-time cleanup. It is a habit built into how the system is maintained, because a prompt that only ever grows will eventually cost more in unpredictable output than it ever saved in coverage.