Skip to main content

Negative Constraints & Anti-Pattern Prompts

A methodology for formulating prohibitions and explicitly excluding undesirable engineering patterns (Anti-Goals) in system instructions to prevent boilerplate and excessive code (AI Slop).

1. Concept Overview & Systemic Problem

Language models have been trained on trillions of lines of diverse internet code. As a result, they tend to default to the so-called "Mediocre Average" style:

  • The model sees a trivial mathematical operation and immediately adds import _ from 'lodash' to the file, bloating the bundle.
  • The model encounters a complex TypeScript type and resorts to // @ts-ignore or as any to finish generation faster.
  • The model generates outdated and redundant comments like // This function adds two numbers.

Negative Constraints serve as an engineering filter that restricts the model's access to harmful habits and forces it to navigate exclusively through a narrow corridor of clean architecture.

2. Architectural Taxonomy & Mental Model

┌─────────────────────────────────────────────────────────────┐
│                 NEGATIVE CONSTRAINTS MATRIX                 │
├─────────────────────────────────────────────────────────────┤
│ 1. DEPENDENCY HYGIENE:                                      │
│    • NEVER run `npm install <package>` without asking.      │
│    • DO NOT import deprecated libraries (Axios, Lodash).    │
│    • Use native browser `fetch` and ES6 methods ONLY.       │
├─────────────────────────────────────────────────────────────┤
│ 2. CODE QUALITY INVARIANTS:                                 │
│    • BANNED: `any`, `unknown` without type guards.          │
│    • BANNED: `console.log` in production-facing code.       │
│    • BANNED: Commenting obvious self-explanatory lines.     │
├─────────────────────────────────────────────────────────────┤
│ 3. UI / DESIGN SYSTEM RULES:                                │
│    • NEVER invent custom HEX colors (#ff4422).              │
│    • USE predefined Tailwind semantic tokens ONLY.          │
│    • NEVER hardcode strings; use i18n translation keys.     │
└─────────────────────────────────────────────────────────────┘

3. Technical Pipeline & Internal Mechanics

01. Anti-Placeholder Rule

The rules impose strict penalties:

CRITICAL INSTRUCTION:
Do NOT output placeholders like `// ...existing code...` or `/* rest of implementation */`.
Always provide the FULL drop-in replacement. Truncated outputs are considered system failure.

This completely eradicates the model's tendency to slack off on large files.

02. Prohibition on Creating New Files Without Approval

Agents often have a tendency to "multiply entities": creating 5 small utility files for a single line of code. The rule: "DO NOT create new utility files unless explicitly specified in the RFC" keeps the folder structure compact.

4. Production Engineering Scenarios

  • Blind Negation Without Alternatives: If you simply write "Do not use React Router", but do not specify that the project runs on Next.js App Router, the model will get confused and start inventing homemade navigation handlers. Always indicate what to do instead of the prohibited.
  • Inflating the Prohibition List: If there are 200 "DO NOT" rules in the system prompt, the model will start to experience action paralysis (Refusal Loop), refusing to respond even to safe prompts.

5. Pitfalls, Common Mistakes & Security

Negative prompting is a tool for establishing clear red lines. The discipline of explicit prohibitions cuts off 80% of cases generating synthetic garbage (AI Slop), maintaining a high culture of the project's codebase.

/ Frequently Asked QuestionsSchema.org FAQPage

FAQ: Negative Constraints & Anti-Pattern Prompts

Positive formulations are too vague and subjective—the model has millions of interpretations of what 'good code' is. Negative constraints sharply narrow the token choice space, cutting off 90% of typical model temptations (e.g., installing 15 unnecessary npm packages).
/ Internal links
All terms