The technique of telling an LLM what not to do, in addition to what it should do — used to override the model’s default tendency to produce safe, generic, hedged output.
What it is
A standard prompt tells the model what to produce. A negative prompt tells it what to avoid. Examples: “Do not use bullet points.” “Do not include caveats unless the claim is genuinely contested.” “Do not summarise what you just did at the end of the response.” “Avoid the phrases ‘leverage’ and ‘in conclusion.’”
The mechanism is straightforward. Without explicit constraints, an LLM defaults to safe averages: hedged language, generic structure, throat-clearing introductions, reflexive summaries. These defaults exist because they fit a wide range of tasks well enough — but rarely fit any specific task excellently. Louis Gleeson describes negative prompting as a way to “10x prompt quality” by adding a single sentence — what he calls the end of the basic-prompting era. The empirical claim is large; the underlying observation is smaller and more durable: explicit negatives narrow the default behaviour in directions that positive instructions alone cannot easily reach.
Why it matters
Negative prompts compound. A single negative (“don’t add a closing summary”) shifts one response. The same negative in a project’s CLAUDE.md file shifts every response in that project, indefinitely. Practitioners who have used Claude Code over weeks accumulate dozens of these — terse, specific rules that encode their preferences. The cumulative effect is large: the model behaves much more in line with the user’s taste than a fresh session ever could, without the user having to repeat themselves.
The discipline is to add a negative only after observing the unwanted behaviour, not pre-emptively. A long list of “don’t do X” instructions can leave the model stilted or hesitant. Negative prompting works best when each rule has a concrete past incident behind it.