Four CLAUDE.md Patterns for AI Rule Adherence

Founders can optimize AI coding assistant behavior by applying specific CLAUDE.md prompt engineering tactics. These include strict token limits, glob-scoped rules, and atomic instruction formatting.

The blog post "5 CLAUDE.md Patterns That Make AI Actually Follow Your Rules" from dev.to outlines a critical constraint for AI coding assistants: system prompts have a working memory budget. The primary CLAUDE.md file, intended to guide AI behavior, should remain under 800 tokens, roughly 600 words. Exceeding this limit causes context compression, pushing older rules out of the AI's active memory. This observation, derived from managing production CLAUDE.md setups, highlights that more rules do not equate to better AI adherence.

Limit primary CLAUDE.md to 800 tokens

The foundational error in CLAUDE.md usage is treating it as comprehensive documentation. It functions as a system prompt prefix, subject to the AI's working memory budget. The dev.to post establishes an 800-token heuristic, roughly 600 words, for the main CLAUDE.md file. Beyond this threshold, context compression mechanisms within the AI begin to discard older rules when longer files are open, rendering them ineffective.

To maintain this token budget, the source advises cutting verbose content. Rationale paragraphs explaining why a rule exists, historical context about past practices, and any information obvious from the codebase itself are prime candidates for removal. The rule belongs in CLAUDE.md; its justification, if necessary, should be a comment in the relevant code file or omitted entirely. This ensures the prompt remains concise and focused on actionable constraints.

Scope rules with glob patterns

Claude Code supports scoped CLAUDE.md files, a feature critical for efficient context management. Rules defined in src/api/CLAUDE.md, for instance, apply only when files within the src/api/ directory are actively open. This prevents irrelevant rules from consuming valuable token space. A frontend-specific rule, such as "never use inline styles," does not need to be loaded when the AI is working on backend Express routes. Similarly, a backend rule about parameterized queries is unnecessary when debugging CSS animations.

The recommended practical layout involves a project-wide CLAUDE.md for stack, deployment, and critical invariants. Specific directories then receive their own CLAUDE.md files: src/api/CLAUDE.md for API-specific patterns, src/web/CLAUDE.md for frontend conventions, and scripts/CLAUDE.md for automation requirements. Each of these scoped files should ideally remain under 300 tokens. This strategy ensures that the total tokens loaded at any given time stay within the effective budget, typically around 600 tokens, as cited by the source.

CLAUDE.md # project-wide: stack, deploy process, critical invariants
src/api/CLAUDE.md # API-specific: auth patterns, error formats, rate limiting
src/web/CLAUDE.md # Frontend-specific: component conventions, state patterns
scripts/CLAUDE.md # Automation: env var handling, idempotency requirements

Isolate one concern per rule

Compound rules frequently fail silently. When multiple constraints are combined into a single sentence, such as, "Functions should be small, pure, and well-named, with explicit return types and no side effects unless they are in service files," the AI may selectively adhere to parts of the instruction while ignoring others. This is attributed to a parsing challenge rather than a model quality issue. Compound sentences introduce ambiguity regarding which clauses represent strict constraints versus mere suggestions.

The effective tactic is to split every compound rule into atomic statements. For example, the verbose function rule can be broken down into three distinct, enforceable constraints:

## Functions
- Max 30 lines. Extract helpers if exceeded.
- Explicit return types on all exported functions.
- No side effects except in `*Service.ts` and `*Repository.ts` files.

This approach eliminates ambiguity, presenting the AI with clear, individual directives that are easier to parse and enforce.

Prioritize negative rules over positive

AI assistants tend to weight prohibitions more heavily than recommendations. A positive rule like "Use Zod for all schema validation" instructs the AI on a preferred action but does not convey the strength of the requirement. Conversely, negative rules, such as "Never use any types. Never use untyped JSON.parse() without a Zod schema," establish hard boundaries.

Prohibitions are more effective because they reduce the valid solution space, making them simpler for the AI to enforce. Recommendations, however, merely add a preference, which the AI may deprioritize under other contextual pressures. Reframing positive rules as negative rules where feasible can significantly improve AI adherence. The source illustrates this with a table comparing positive and negative rule formulations.

(Note: The source text for the table ends abruptly here. The full comparison is not available.)

WHAT WE'D CHANGE

The patterns outlined by dev.to offer practical guidance for optimizing AI assistant prompts, particularly for CLAUDE.md. However, several considerations warrant further examination. The 800-token and 300-token limits, while presented as heuristics, are tied to the specific context window limitations of AI models at the time of writing. As large language models rapidly evolve, context windows are expanding significantly. Future iterations of these models may render such strict token limits less critical, potentially allowing for more extensive, yet still well-structured, system prompts. The core principle of conciseness, however, remains valuable regardless of token capacity.

While the source focuses on CLAUDE.md, the underlying principles of prompt engineering — managing context, reducing ambiguity, and leveraging negative constraints — are broadly applicable to any LLM-powered coding assistant or system prompt. Founders should consider these patterns as general best practices for instructing AI, not just as Claude-specific directives. The efficacy of "negative rules" likely stems from how LLMs are trained to identify and avoid undesirable outputs, a mechanism that transcends specific model architectures.

The dev.to post is an observational account from managing production setups, not a formal research paper. Consequently, the "why" behind some of the observed phenomena, such as the stronger weighting of negative rules, is not deeply explored. Future iterations of this playbook would benefit from incorporating insights from LLM research on instruction following, attention mechanisms, and prompt engineering efficacy to provide a more robust theoretical underpinning. Additionally, the incomplete nature of the source, particularly the cut-off example table for negative rules, limits the depth of practical illustration.

LANDING

Effective management of AI coding assistant behavior relies on precise, constrained instruction. These patterns demonstrate that clarity and brevity, rather than exhaustive documentation, maximize adherence to defined rules. As AI models evolve, the underlying principles of context management and unambiguous instruction will remain central to successful integration into development workflows. Founders must adapt their prompting strategies to the AI's operational realities, focusing on what the model can reliably process and enforce.

Pull quote: “AI assistants tend to weight prohibitions more heavily than recommendations.”