Chapter 7: Negative Prompting — Telling the AI What NOT to Do

The Problem With Positive-Only Instructions

When you write a prompt, you instinctively focus on the positive: 'Write a blog post about X. Include Y and Z. Make it engaging.'

But the model's default behaviors — shaped by its training data and RLHF fine-tuning — may not align with what you want. The model might:

• Add a disclaimer you did not ask for
• Offer multiple options when you wanted one definitive answer
• Use hedging language ('it's worth noting that,' 'while there are many perspectives')
• Include a generic conclusion that restates what was already said
• Format things in a way that does not match your system

---

Categories of Negative Constraints

Category 1: Format Prohibitions

Prevent specific formatting patterns you do not want.

Do NOT:
- Start your response with "Certainly!" or "Of course!" or "Great question!"
- End with a summary section that restates the content
- Use bullet points for content that flows better as prose
- Bold more than 3 terms per section
- Add a "Conclusion" header — end the piece naturally

Category 2: Content Prohibitions

Prevent content patterns that reduce quality.

Do NOT:
- Use filler phrases: "it's worth noting," "it's important to remember," "as we can see"
- Include generic advice that applies to all topics
- Add disclaimers about consulting professionals unless the content is genuinely medical/legal
- Mention that you are an AI
- Use passive voice when active voice is available

Category 3: Reasoning Prohibitions

Prevent flawed reasoning patterns.

``` Do NOT:

• Speculate about things you do not have information about — say "I don't know" instead
• Present uncertain information as fact

• Offer multiple contradictory answers — pick the best one and defend it
• Agree with incorrect premises in my question — correct them

### Category 4: Scope Prohibitions

Keep the model focused on the specific task.

• Answer questions I have not asked
• Proactively add context I did not request unless it is critical for safety
• Suggest alternative approaches unless I have asked for options
• Refactor code I have not asked you to change

---

## Building a Negative Constraints Library

The most powerful negative prompts come from observing your model's failure modes and adding constraints that prevent them. Keep a running list for each common task type.

**For code generation:**

• Use placeholder comments like "// your implementation here" or "// handle error"
• Write code that assumes libraries are installed without checking if they are in the tech stack
• Mix async/await with .then().catch() patterns in the same file
• Add console.log() statements for debugging without a comment saying they should be removed
• Use 'any' type in TypeScript unless absolutely necessary
• Write functions longer than 50 lines without flagging that refactoring may be needed

**For content writing:**

• Use these words: leverage, synergy, game-changer, revolutionary, cutting-edge, holistic, robust, seamless, ecosystem, paradigm
• Start sentences with "In today's [adjective] world"
• End with a call to action unless I have specifically requested one
• Write in first person unless I specify
• Quote statistics without a source

**For analysis tasks:**

• Present both sides neutrally when one side has significantly stronger evidence
• Hedge every conclusion with "however, it depends"
• Recommend "further research" as a conclusion — give a best current answer
• Confuse correlation with causation

---

## The "Stop Doing X, Start Doing Y" Pattern

The most effective negative prompts pair a prohibition with a positive alternative:

INSTEAD OF: Adding a disclaimer about edge cases DO: Note the edge case inline where it is relevant, not as a separate disclaimer

INSTEAD OF: "While there are many approaches..." DO: Name the best approach for this specific situation and explain why ```

This pattern avoids leaving a void that the model fills with something equally unwanted.

---

Key Insight: Constraints Are System Design

Negative prompting is not about fighting the model — it is about designing a well-specified system. Every constraint you add is a design decision about what your product's output should look like. The more explicitly you define the boundaries, the more consistently your output falls within them.

Treat your negative constraints list as a living document. Every time the model produces output you did not want, ask: 'Can I write a constraint that prevents this?' Most of the time, you can.