The AI Generates, the Formatter Formats
The relationship between AI rules and Prettier: complementary, not overlapping. The AI: generates code with the correct patterns, naming, and logic. Prettier: formats the generated code with consistent indentation, quotes, semicolons, and line length. The AI does not need to generate perfectly formatted code — Prettier fixes formatting automatically in the save hook or pre-commit hook. AI rules for formatting: mostly unnecessary and wasteful of the AI's context window.
Why most Prettier settings should NOT become AI rules: Prettier handles: indentation (tabs vs spaces, 2 vs 4), quotes (single vs double), semicolons (with or without), line length (80 vs 100 vs 120), trailing commas (all, es5, none), and bracket spacing. The AI generating code with 4-space indentation when Prettier enforces 2-space: wastes AI context on a problem Prettier solves in milliseconds. The AI should focus on: what the code does (logic) and how it is structured (patterns), not how it looks (formatting).
The exceptions: a few Prettier-adjacent decisions affect code generation in ways the formatter cannot fix. These: should be in the AI rules. The rest: leave to Prettier entirely.
The 3 Prettier Settings That Belong in AI Rules
Setting 1 — Print width and code structure: Prettier's printWidth (e.g., 80 or 100) determines when lines wrap. The AI: should know the target line length to generate code that does not require excessive reformatting. If the AI generates a 200-character function call: Prettier wraps it, but the result may be uglier than what the AI would have generated if it knew the line length target. AI rule: 'Target line length: 100 characters. For function calls with many arguments: use multi-line format with one argument per line. For object literals with 3+ properties: use multi-line format.' This rule: guides the AI to generate readable multi-line code instead of long single lines.
Setting 2 — JSX patterns: Prettier's jsxSingleQuote and jsxBracketSameLine affect how JSX looks. The AI: should generate JSX in the project's preferred style because the visual structure of JSX affects readability more than plain JavaScript. AI rule: 'JSX: opening bracket on the same line as the component name. Self-closing tag for components without children (<Icon />). Multi-line JSX: closing bracket on its own line, aligned with the opening tag.' These rules: help the AI generate JSX that reads well before and after Prettier formatting.
Setting 3 — Import style (not Prettier, but related): Prettier does not handle import ordering (that is ESLint's import/order). But the visual structure of imports: affects readability. AI rule: 'Imports: one import per line. Group: external → internal → relative. Blank line between groups. No barrel imports from large packages (import { specific } from lodash, not import _ from lodash).' This rule: ensures the AI generates clean import blocks that do not need restructuring. AI rule: 'Only 3 formatting-adjacent rules belong in AI rules. Everything else: Prettier handles better.'
The AI generates: const result = await someService.processOrder(orderId, userId, paymentMethod, shippingAddress, billingAddress, couponCode) — 140 characters. Prettier wraps it, but the wrap point: may be awkward (splitting in the middle of related arguments). With a line length AI rule: the AI generates multi-line format from the start, grouping related arguments logically. The result: better readability both before and after Prettier formatting.
What to Leave to Prettier (Everything Else)
Do NOT add to AI rules: indentation (Prettier: tabWidth: 2 or useTabs: true. The AI's indentation: irrelevant — Prettier fixes it), quotes (Prettier: singleQuote: true. The AI can use either — Prettier normalizes), semicolons (Prettier: semi: true/false. The AI can generate either — Prettier adds or removes), trailing commas (Prettier: trailingComma: 'all'. The AI can omit them — Prettier adds), and bracket spacing (Prettier: bracketSpacing: true. The AI can generate either — Prettier normalizes).
Why not both? Adding these to AI rules: wastes the AI's context window on conventions that Prettier handles automatically. Every rule: consumes attention that could be spent on patterns, logic, and architecture — the things Prettier cannot handle. A rule 'use single quotes': adds zero value because Prettier converts double quotes to single quotes in milliseconds. That rule's slot: better used for an error handling pattern or a security convention.
The verification: if you are unsure whether a formatting convention should be an AI rule, ask: will Prettier fix this automatically? If yes: skip it. Will the AI's output look significantly different from the Prettier-formatted version? If the AI generates 200-char lines and Prettier wraps them awkwardly: add a line length hint. If the AI uses double quotes and Prettier changes to single: do not add a rule. AI rule: 'The test: does Prettier fix it? If yes: not an AI rule. If no: consider whether the AI's output would improve with guidance.'
AI rule: 'Use single quotes for strings.' Prettier config: singleQuote: true. The AI generates double quotes. Prettier: converts to single quotes on save. Net effect of the AI rule: zero. The AI's context window: wasted on a rule that produces no visible output difference. That context: better spent on 'Use the Result pattern for error handling' — a rule that Prettier cannot enforce and that directly improves code quality.
Setting Up AI Rules + Prettier Together
The workflow: the AI generates code (following AI rules for patterns and logic) → the developer reviews (checking correctness and architecture) → Prettier formats (applying consistent formatting) → the code is committed (clean, consistent, and correct). Each step: handles a different concern. No overlap, no conflict.
Editor integration: configure your editor to format-on-save with Prettier. The AI generates code → the developer accepts → the file saves → Prettier formats instantly. The developer: never sees the AI's raw formatting. They see: Prettier-formatted code with the AI's patterns and logic. AI rule: 'Format-on-save with Prettier: mandatory for the team. The developer never commits unformatted code. The AI's formatting: irrelevant because Prettier overrides it immediately.'
Pre-commit hook: use Prettier in a pre-commit hook (via husky or lint-staged) as a safety net. Even if format-on-save was not triggered: the pre-commit hook formats before the code enters the repository. The repository: always contains Prettier-formatted code. AI-generated code: formatted before it is committed, regardless of the developer's editor settings. AI rule: 'Pre-commit Prettier: the safety net. Even if a developer's editor does not format-on-save: the pre-commit hook catches it. Zero unformatted code in the repository.'
With format-on-save enabled: the AI generates code with its default formatting. The developer accepts the suggestion. The file saves. Prettier reformats instantly. What the developer sees: Prettier-formatted code. What the developer never sees: the AI's raw formatting. The AI's indentation, quotes, and semicolons: completely irrelevant. Prettier overwrites them all. This is why formatting AI rules are pointless — the output is reformatted before anyone reads it.
Prettier to AI Rules Summary
Summary of converting Prettier config to AI rules.
- Relationship: AI generates patterns and logic. Prettier handles formatting. Complementary, not overlapping
- Convert (3 settings): line length hint, JSX structure patterns, import grouping
- Skip (everything else): indentation, quotes, semicolons, trailing commas, bracket spacing
- Why skip: Prettier fixes formatting in milliseconds. AI rules for formatting waste context
- The test: does Prettier fix it automatically? If yes: not an AI rule
- Workflow: AI generates → developer reviews → Prettier formats → code commits
- Format-on-save: mandatory. The developer sees Prettier-formatted code, not raw AI output
- Pre-commit hook: safety net. Zero unformatted code in the repository