Guardrails Beat Guidance: Negative Constraints in Instructions Work, Positive Directives Backfire

This isn't a step-by-step technique but a set of principles for writing instructions for AI. It works anywhere you write rules: ChatGPT custom instructions, a Claude system prompt, Project instructions.

PRINCIPLE 1 — Priming
Add any structured instructions →
Already +7 to +14 percentage points in pass rate (on a hard
subset of SWE-bench Verified tasks), even if the rules are random

PRINCIPLE 2 — Constraints instead of directives
❌ "do X" (positive directive) → hurts
✅ "don't do X" (negative constraint) → helps

PRINCIPLE 3 — Scale isn't scary
1 rule / 10 rules / 50 rules →
Same quality, no degradation

AUDIT (apply to existing instructions):
Read each rule → does it start with "don't"/"no"/"avoid"? → keep it
Starts with "always"/"write"/"think"/"use"? → delete or rephrase

Task: Ryan runs a Substack newsletter about venture capital and uses ChatGPT every day: writing posts, breaking down startups, prepping pitches for investors. His custom instructions say things like "write concisely and with structure", "always think about the reader", "use concrete examples", "be a venture expert". A typical set of positive directives. According to the study, each such rule breaks some of the answers that would have come out fine without it.

Before (a set of positive directives — hurts):

You are an expert in venture investing.
Always write with structure and concisely.
Use concrete examples.
Think about the reader — founders and investors.
Give balanced assessments.
Write in English.

After (constraints instead of directives — helps):

You are an expert in venture investing.

Prohibitions:
— Don't add information that isn't in the request or the provided materials
— Don't write intro paragraphs ("In today's world...", "This is an important question...")
— Don't repeat points you've already made above
— Don't soften criticism for the sake of politeness — say it straight
— Don't add "Summary" or "Conclusion" sections if they duplicate the main text
— Don't use the phrases: "it should be noted", "it is essential", "it is worth mentioning", "it's important to understand"

Result: The model gets clear boundaries of what not to do — and works at full power inside them. It doesn't get competing goals ("think about the reader" + "use examples" + "be structured" — three different goals pulling in different directions). Answers get cleaner and more specific with no extra tuning.

The LLM already knows how to do its job well. A strong model — Claude, GPT-4 — is already trained to write well, reason step by step and structure text. When you write "write concisely," you're not teaching it anything new. You're adding an extra goal that competes with the main task for the model's attention.

A positive directive is a competitor, not a helper. Imagine you asked a colleague to review a contract and then added "and don't forget to think about the reader, and write clearly, and use examples." Now your colleague is reviewing the contract while also trying to follow three instructions about how to do it. Their attention is fragmented. The rule "watch the style" is the same: the model starts spending "horsepower" on style compliance and gets distracted from the substance of the task.

A negative constraint is different. "Don't touch code unrelated to the task" is a rule that only kicks in when needed. If the model is working correctly, the rule stays silent. If the model is about to do something extra, the rule stops it. It's like the brakes on a car: they don't keep you from driving, they prevent the crash.

Control levers: - Number of rules → feel free to add up to 50; quality doesn't drop. If you have 5–10, you can add more, no harm done. - Rule type → read each one: "don't do X" — keep it; "do X" — rephrase as "don't do the opposite" or delete it. - The mere presence of structure → even if you don't know what to write, just add a "Rules" section with a couple of prohibitions. That alone will improve performance.

A custom instructions / system prompt template based on the study's principle:

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}

What to fill in: - {role} — who the model is for you: analyst, editor, lawyer, coach - {unwanted action} — specific things that annoy you in answers: "don't add disclaimers", "don't use the word 'absolutely'", "don't ask clarifying questions if the task is clear", "don't suggest alternatives unless asked" - {context} — briefly about the task: "I run a law practice", "I write content for Instagram"

🚀 Quick start — paste into the chat:

Here's a template for system instructions. Adapt it to my task: {a description 
of what you do with AI}.

Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what annoys you about its current answers — because that's exactly what the prohibitions are built from. It will take the "don't do X" pattern and fill in the prohibitions block for your specifics.

⚠️ Priming, not magic: Having rules improves results, but only if the model can already solve the task. Rules don't make up for a weak core instruction about the task.

⚠️ Strong models only: The study was run on top-tier agents (Claude Opus). For weaker models the "just having instructions helps" effect may be smaller.

⚠️ Not all positive directives are equally harmful: The researchers tested 18 specific rules. The effect doesn't mean every positive directive breaks answers — but 14 of 18 authors' rules each broke at least 2 of 17 already-solved tasks when added alone (suggestive: ~11.8% run-to-run flip chance per task). The risk is high.

⚠️ Context rules are an exception: Rules like "the API key is in .env" or "the project uses Python 3.11" are neither directives nor constraints — they're context. Such rules are useful and aren't subject to the distortion effect.

The researchers collected 679 real rule files (CLAUDE.md, .cursorrules) from GitHub — 25,532 individual rules in total. That's what real developers write for their AI agents every day.

Then came a tough experiment: more than 5,000 runs of a coding agent (Claude Opus) on real GitHub issues. The agent's job: fix a bug in the repository so the tests pass. They measured a simple metric: fixed or not fixed.

The most unexpected result came from comparing conditions. The agent with curated rules (selected by experts) solved 63.8% of tasks. The agent with random rules — also 63.8%. The agent with rules from the wrong domain (React rules for Python tasks) — 58.6%, which is better than with rules from the right domain (56.9%). This is so counterintuitive that the researchers also tested shuffled rules — sentences in random order — and got the same thing.

The most important experiment was switching off the 18 rules one at a time. When they removed "don't touch code outside the task," the agent lost 20 percentage points. When they removed "read the test files," it got better. All three rules whose removal made things worse turned out to be prohibitions. All four rules whose removal made things better were prescriptions. The probability of this being chance: p=0.029.

Table 1. Non-inert rules from per-rule ablation.
All shaping rules are negative constraints; all distorting rules are positive directives.

Rule            | Polarity | Type    | Effect
----------------|----------|---------|--------
No unrelated    | "don't"  | safety  | shaping
 refactor       |          |         | (removing hurts, –20pp)
No new          | "don't"  | safety  | shaping
 dependencies   |          |         |
No unrelated    | "don't"  | safety  | shaping
 files          |          |         |
----------------|----------|---------|--------
Read test files | "do"     | process | distorting
Follow code     | "do"     | style   | distorting
 style          |          |         |
Handle edge     | "do"     | style   | distorting
 cases          |          |         |
Preserve        | "do"     | safety  | distorting
 compat.        |          |         |

Context: The researchers took a set of 18 rules hand-crafted by the authors to represent best practices, added each one to the agent in turn and watched how the share of solved tasks changed. The table shows only the "non-inert" rules — those with a noticeable effect. A perfect split by polarity: every helpful rule turned out to be a prohibition, every harmful one a prescription.

💡 Adaptation: audit your existing custom instructions

If you already have a system prompt or custom instructions, ask the LLM to audit them:

Here are my custom instructions:

{paste your instructions}

Split them into two types:
1. Negative constraints — rules that forbid doing something 
   (starting with "don't", "no", "avoid", "never")
2. Positive directives — rules that prescribe doing something 
   ("always", "write", "use", "think", "be")

For each positive directive, suggest a rewrite as a negative 
constraint or explain whether it should be removed entirely.

🔧 Technique: a "context layer" instead of a blank chat

The priming effect works even with random structured text. If you're starting a new chat without a system prompt, add at least minimal structure at the top of your request:

Task context:
— I am [role/situation]
— Task: [what's needed]
— Constraints: don't [X], don't [Y]

[the actual question]

This isn't "prompt engineering for prompt engineering's sake" — it literally switches the model into careful-work mode before it even reaches the substance of your request.

🔧 Technique: converting directives via the "antonym prohibition"

A simple algorithm for any positive directive:

Positive directive → ask yourself: "What goes wrong when this is violated?"
→ Phrase a prohibition against that specific violation

"Write briefly" → "Goes wrong": bloated paragraphs, intro sentences, repetition
→ Prohibitions: "Don't write intro paragraphs", "Don't repeat what was said above"

"Be specific" → "Goes wrong": abstract advice with no examples
→ Prohibition: "Don't give advice without a concrete action or example"

"Think about the reader" → "Goes wrong": explaining what's already obvious
→ Prohibition: "Don't explain concepts that are obvious to a professional in the field"

Paper: Do Agent Rules Shape or Distort? Guardrails Beat Guidance in Coding Agents (Preprint, April 2026)

Authors: Xing Zhang, Guanghui Wang, Yanwei Cui, Peiyang He (AWS Generative AI Innovation Center); Wei Qiu, Ziyuan Li, Bing Zhu (HSBC Technology Center, China)

Contact: [email protected]

Benchmark: SWE-bench Verified — swebench.com

Related work: EvolveR (Wu et al., 2026), DSPy (Khattab et al., 2023), Potential-Based Reward Shaping (Ng et al., 1999)