Negative constraints and failure lists: when "don't" works in a prompt

What negative constraints are

A negative constraint tells the model what must not appear in the output or what action must not be taken: "don't write intro paragraphs", "don't touch code unrelated to the task", "do not use these words". A failure list goes one step further. You write down the typical ways this kind of output goes wrong and turn each one into a rule.

The research splits this family in two. Concrete bans name something you can see in the text or in the agent's actions: a word, a file, a dependency, a shortcut. Several studies find that these work. Abstract bans ask the model to suppress a tendency or ignore information already in front of it: "don't flatter", "ignore the candidate's gender", "ignore what happened afterward". These fade, get ignored, or make things worse. Most of the practical skill lies in turning the second kind into the first.

Why concrete bans work

Three mechanisms show up across the studies.

• A ban does not compete with the task. In the coding-agent rules study, positive directives such as "follow the code style" acted as extra goals that pulled attention from fixing the bug. A ban such as "no unrelated refactor" stays silent until the agent is about to do something extra. Removing that one ban cost the agent 20 percentage points. In ablations of 18 real rules, every rule that helped was a prohibition and every rule that hurt was a prescription.
• A ban can be checked at every token. The format-compliance study found that "don't use commas" or "don't mention X" held up almost perfectly under hard tasks. "End with a JSON block" failed in up to 50% of cases, because a future obligation slips out of focus while the model works on content.
• A failure list replaces a vague ideal. "Do a good job" leaves the model to guess what good means, and it returns the average. In the failure-list study, GPT-4o given a list of typical interviewer mistakes wrote follow-up questions rated above human-written ones for clarity, relevance and informativeness. Asked simply for a good question, it was no better than a human.

Variants that tested well

• Banned actions with a stated consequence. For agents with web and file access, anti-cheat prompting listed specific forbidden shortcuts and said a result reached that way counts as a failure. Cheating fell from 33% to 8.5% across 22 models, and honest solve rates did not drop. A shortcut ban placed in the first message of an iterative "make it better" loop cut metric exploitation from 100% to 8.3%.
• Banned-word lists. Forbidding 20 filler words ("very", "just", "literally") raised reasoning accuracy by 6.7 pp on average in the vocabulary-ban study, and by up to 15 pp for Gemini and Claude. The authors' explanation: monitoring the output for banned words keeps the model out of autopilot. Banning possessive "have" in Umwelt engineering gave +19 percentage points on ethics tasks and +7 pp on classification.
• Banning the default move. For idea generation, TasteGap found that 47–64% of model ideas are "combine A and B". Explicitly banning that move and naming a different idea type made the model switch templates.
• Bans written as settings. The declarative register rewrites "NEVER use emoji" as "Emoji: disabled". Rewriting 3 of 11 instructions this way improved compliance on all 11.
• Blockers as fields. When context is summarized between agent steps, "legal hasn't approved this" tends to soften into "might want to check with legal". Constraint field preservation keeps it as four required fields: status, release condition, owner and fallback.

When bans fail or backfire

The counter-evidence is as strong as the support, and it follows the concrete/abstract split.

• "Ignore X" backfires. In the self-blinding study, telling models to pretend they did not know a candidate's gender or race pushed decisions further from the fair answer, 4x for Qwen and 2.4x for GPT-4.1. Some biases even flipped direction. What worked was removing the information and asking a fresh copy of the model. Hindsight tests found the same: "ignore the outcome" reduced the shift toward the known ending but did not remove it, and up to 5.5% of answers still flipped. Cutting the future data out of the context fixed it.
• "Don't flatter" is unreliable. The SWAY study found that a plain "don't flatter me" made sycophancy worse for some models and caused overcorrection in others. A five-step counterfactual check worked better. A real reflection agent told not to over-praise still praised in half of 17,930 turns, while it kept a length limit reliably. A rule needs a number or an exit condition to be checkable.
• Bans fade in long chats. This contradicts the "prefer don't" advice above. In the long-session study, prohibitions decayed as the conversation grew while requirements held. By turn 16, one model added a required tag in 100% of replies and broke the no-bullets ban in 67% of the same replies. Its fix: turn a ban into a requirement where you can, and repeat the remaining bans every 6–8 messages.
• Strict bans can backfire. For 4 of the 22 models in the anti-cheat study, the strict version increased cheating. E-Prime, the ban on "to be", cost GPT-4o-mini 27.5 pp on calibrated judgments in the Umwelt tests.

The two camps can be reconciled. The coding-agent and format results come from single, focused tasks with bans on visible actions. The decay result comes from long multi-turn sessions. In short, one-shot work, write concrete bans. In long sessions, restate them or rephrase them as requirements. If the "ban" is really about what the model should not take into account, delete that information instead of instructing it to look away. For position effects in long prompts, see instruction placement.

You are a {role}.
Prohibitions (what not to do):
— Don't {unwanted action 1}
— Don't {unwanted action 2}
— Don't {unwanted action 3}
— Don't {unwanted action 4}
— Don't {unwanted action 5}
{optional: 1-2 lines of context about the project or task}

{Model's role / task description}.
CRITICAL: This result must be obtained honestly, through real analysis/solving
of {task substance}, not through workarounds. You will get an automatic "failure" —
even if the result is technically correct — if you do any of the following:
(1) {forbidden action 1, as specific as possible};
(2) {forbidden action 2, as specific as possible};
(3) {forbidden action 3, as specific as possible}.
You must demonstrate genuine work on the task, not just plugging in
a ready-made answer. A result obtained through forbidden means
is a failure, even if it's technically correct.

Session rules reminder:
FORBIDDEN — confirm each item:
- {prohibition_1}
- {prohibition_2}
- {prohibition_3}
REQUIRED:
- {requirement_1}
- {requirement_2}
Reply "Rules updated" and continue: {current task}