AI Rules vs Code Formatters: Overlap and Gaps

Formatting vs Logic: Different Problems Entirely

Code formatters (Prettier, Biome, dprint) answer: how should the code look? Indentation: 2 spaces or 4? Quotes: single or double? Semicolons: yes or no? Line length: 80 or 120 characters? Trailing commas: yes or no? Object bracket spacing: yes or no? These are: aesthetic decisions with no impact on code behavior. Formatters enforce them automatically: save the file, the formatter rewrites it to the configured style. No human decision needed. No AI guidance needed.

AI rules (CLAUDE.md, .cursorrules) answer: what should the code do and how? Architecture: Server Components by default or Client Components? Patterns: async/await or .then() chains? Libraries: Zustand or Redux? Error handling: throw or return Result type? Testing: unit tests for every function or integration tests for features? These are: logic decisions that determine code behavior. The AI needs guidance: the rule file tells it which approach to take. The formatter cannot make these decisions.

The division is clean: formatters own style (how it looks). AI rules own substance (what it does and how). The problem arises when: AI rule files include formatting instructions that the formatter already handles. "Use 2-space indentation" in CLAUDE.md: redundant (Prettier handles this). "Use single quotes" in .cursorrules: redundant (Prettier config handles this). These redundant rules: waste tokens and may conflict with the formatter config if they disagree.

Redundant Rules to Remove from Your AI Rule File

Remove from CLAUDE.md if you use Prettier/Biome: indentation rules ("use 2-space indentation" — Prettier config: tabWidth: 2), quote style ("use single quotes" — Prettier config: singleQuote: true), semicolons ("always use semicolons" — Prettier config: semi: true), trailing commas ("use trailing commas" — Prettier config: trailingComma: "all"), line length ("max 100 characters per line" — Prettier config: printWidth: 100), bracket spacing ("spaces in object braces" — Prettier config: bracketSpacing: true), and JSX quotes ("double quotes in JSX" — Prettier config: jsxSingleQuote: false).

Why remove: the formatter runs after the AI generates code. Whatever formatting the AI produces: the formatter overwrites it to the configured style. The AI rule is: overridden on save. The tokens spent on the formatting rule: wasted (the formatter ignores what the AI generated and applies its own style). If the AI generates single quotes and Prettier is configured for double quotes: Prettier changes them on save. The AI rule about quotes: had no lasting effect.

The exception: if you do not use a formatter (some projects intentionally avoid auto-formatting), the AI rule is: the only formatting guidance. In this case: include formatting preferences in the AI rules. But: most modern projects use Prettier or Biome. If a formatter runs on save or pre-commit: remove all formatting rules from the AI rule file. Every removed formatting rule: frees tokens for a logic rule that actually affects the AI output.

• Remove: indentation, quotes, semicolons, trailing commas, line length, bracket spacing
• Why: formatter overwrites AI formatting on save — the AI rule has no lasting effect
• Each removed formatting rule: frees tokens for a logic rule that actually changes AI behavior
• Exception: no formatter in the project — then AI rules are the only formatting guidance
• Test: change a formatting AI rule, generate code, save — does the output change? If not, remove it

Rules to Keep: Logic That Formatters Cannot Handle

Keep in CLAUDE.md (formatters cannot handle): import ordering logic ("group imports: external, then internal, then relative" — some ESLint plugins handle this, Prettier does not), naming conventions ("use camelCase for functions, PascalCase for components, SCREAMING_SNAKE for constants" — formatters do not rename variables), file structure ("co-locate component, test, and styles in one directory" — formatters do not create files), and code organization ("export types at the top, then constants, then functions" — formatters do not reorder declarations).

Keep: pattern preferences that affect behavior. "Prefer early returns over nested if-else" — changes code structure, not just formatting. "Use object destructuring for function parameters with 3+ fields" — changes the function signature. "Prefer const over let for variables that are not reassigned" — changes mutability semantics (ESLint can enforce this too, but the AI rule prevents it at generation time). These rules: change what the code does or how it is structured. A formatter cannot make these decisions.

The clean division: AI rule file = logic, architecture, patterns, conventions, library choices. Formatter config = indentation, quotes, semicolons, line length, bracket spacing. Linter config = syntax enforcement, unused code, type safety, import restrictions. Three tools, three domains, zero overlap when configured correctly. Each tool does: what it does best. No tool duplicates: what another tool handles.

• Keep: import ordering logic, naming conventions, file structure, code organization
• Keep: early returns, destructuring preferences, const vs let — behavior and structure
• Three domains: AI rules (logic), formatter (style), linter (enforcement) — zero overlap
• AI rule: guides what code to generate. Formatter: auto-fixes how it looks. Linter: catches violations
• Clean division: each tool does what it does best, no duplication

Your Formatter Config Is Already an AI Rule

An insight most teams miss: the AI reads your project files including .prettierrc and biome.json. When the AI generates code: it may read the formatter config and generate code matching the formatter style — without any explicit AI rule about formatting. Claude Code: reads .prettierrc when exploring the project. Cursor: has access to all project files including formatter configs. The formatter config is: already an implicit AI rule for formatting preferences. Writing the same preference in CLAUDE.md: is doubly redundant.

The implication: you do not need to tell the AI your formatting preferences at all. The formatter config tells it implicitly (the AI may read it). The formatter enforces it explicitly (the formatter runs on save). The AI rule about formatting is: unnecessary at both the guidance level (formatter config is visible) and the enforcement level (formatter rewrites the output). Remove all formatting rules from AI rule files. The formatter handles formatting end-to-end.

This frees up significant token budget: a typical rule file with formatting rules is 30-40% formatting (indentation, quotes, semicolons, spacing). Remove formatting: the file is 30-40% shorter. Those tokens: can now hold logic rules that actually change AI behavior. A 1000-word rule file with 400 words of formatting: becomes a 600-word file with 400 words of pure logic guidance. The logic density increases. The AI guidance quality improves. The formatter still handles formatting perfectly.

• AI reads .prettierrc: formatter config is already an implicit AI rule for formatting
• Formatter enforces on save: explicit enforcement regardless of what AI generated
• AI rule about formatting: unnecessary at both guidance and enforcement levels
• 30-40% of typical rule files is formatting: remove it all, free tokens for logic rules
• 600 words of logic > 1000 words of logic + formatting — higher density, better guidance

The Optimal Three-Tool Setup

Tool 1: Prettier or Biome (formatting). Config: .prettierrc or biome.json. Handles: indentation, quotes, semicolons, line length, trailing commas, bracket spacing. Runs: on save (editor integration) and pre-commit (lint-staged). The AI-generated code: is formatted automatically before it enters the repository. Zero formatting rules in CLAUDE.md.

Tool 2: ESLint or Biome lint (validation). Config: eslint.config.js or biome.json lint section. Handles: unused variables, floating promises, import restrictions, naming enforcement, code complexity. Runs: on save (editor) and CI (GitHub Actions). The AI-generated code: is validated for correctness after generation. Linter rules complement AI rules — they catch what the AI misses.

Tool 3: CLAUDE.md or .cursorrules (generation guidance). Content: architecture, framework patterns, library choices, convention preferences, security rules. Handles: what code to generate and which approach to take. Runs: at AI generation time (loaded as context). The AI-generated code: follows project-specific conventions from the first line. Logic rules only — no formatting, no syntax enforcement (those are handled by Tools 1 and 2).

• Prettier: formatting on save + pre-commit. Zero formatting in AI rules
• ESLint: validation on save + CI. Catches what AI misses with 100% enforcement
• CLAUDE.md: generation guidance. Logic, architecture, patterns only — no formatting or syntax
• Three tools, three stages: generation (AI rules) → formatting (Prettier) → validation (ESLint)
• Each tool: does one thing well. No tool duplicates another tool's responsibility

Comparison Summary

Summary of AI rules vs code formatters.

• Formatters: style (how code looks) — indentation, quotes, semicolons. Auto-applied on save
• AI rules: substance (what code does) — architecture, patterns, library choices. Guide generation
• Redundant: formatting rules in CLAUDE.md when Prettier runs — remove all, free tokens for logic
• .prettierrc is already an implicit AI rule: the AI may read it, the formatter enforces it
• 30-40% of rule files is formatting: removing it increases logic rule density by 50%+
• Three-tool setup: Prettier (style) + ESLint (validation) + CLAUDE.md (logic) = complete coverage
• Each tool owns one domain: no overlap, no conflict, no redundancy
• The test: remove a formatting rule, generate code, save — if output unchanged, the rule was wasted