How to Convert ESLint Rules to AI Rules

Your ESLint Config Is a Convention Goldmine

Your ESLint configuration already encodes many of your team's coding conventions: naming patterns (camelCase for variables, PascalCase for components), code structure (no unused variables, no unreachable code, max function length), import ordering (external before internal, alphabetical within groups), and framework-specific patterns (React hooks rules, TypeScript strict rules). These conventions: already agreed upon by your team, already enforced in CI, and already documented in a machine-readable format.

The difference between lint rules and AI rules: ESLint catches violations after the code is written (reactive — find and fix). AI rules prevent violations during code generation (proactive — generate correctly from the start). Both are valuable. Both encode the same conventions. But AI rules: prevent the violation before it exists. ESLint: catches any that slip through. Together: defense in depth.

The conversion: not a 1-to-1 mapping. Some ESLint rules map directly to AI rules (naming conventions, import ordering). Some ESLint rules are better left as lint rules (formatting — Prettier handles this more reliably). And some AI rules have no ESLint equivalent (architectural patterns, error handling philosophy, testing conventions). The conversion: extracts the subset that benefits from AI-level enforcement.

Step 1: Extract Conventions from ESLint Config (15 Minutes)

Read your eslint.config.js (or .eslintrc). For each enabled rule: ask: is this a convention the AI should follow when generating code? Categories: naming rules (camelcase, @typescript-eslint/naming-convention) → convert to AI rules. The AI should generate code with the correct naming from the start. Import rules (import/order, no-duplicate-imports) → convert to AI rules. The AI should organize imports correctly. Pattern rules (no-var, prefer-const, prefer-arrow-callback) → convert to AI rules. The AI should use the preferred patterns.

Rules to skip: formatting rules (indent, semi, quotes, max-len) — Prettier or the formatter handles these. The AI does not need to generate perfectly formatted code because the formatter runs after. Error detection rules (no-unused-vars, no-undef) — these catch mistakes, not conventions. The AI should not be told 'do not create unused variables' — it should not create them anyway. Complexity rules (max-lines, max-params, complexity) — these are code review concerns, not generation guidance.

The extraction output: a list of 10-20 conventions extracted from your ESLint config. Each one: a rule for the AI. Example ESLint: 'camelcase': 'error'. AI rule: 'Variable and function names: camelCase. Component names: PascalCase. Constants: UPPER_SNAKE_CASE.' The AI rule: more descriptive than the ESLint rule because the AI needs context, not just a rule name. AI rule: 'ESLint rules are terse (rule names with options). AI rules need prose (describe the convention clearly). The conversion: expands each lint rule into a sentence the AI can follow.'

💡 ESLint Rules Are Terse — AI Rules Need Prose

ESLint: 'camelcase': 'error'. The linter knows what camelCase means. AI rule equivalent: 'Variable and function names: camelCase (userProfile, getActiveUsers). Component names: PascalCase (UserProfile, OrderList). Constants: UPPER_SNAKE_CASE (MAX_RETRIES, API_BASE_URL).' The AI needs examples and context, not just a rule name. The conversion: expands terse lint config into descriptive prose that the AI can follow during generation.

Step 2: Mapping Common ESLint Rules to AI Rules

Naming: ESLint: '@typescript-eslint/naming-convention' with specific patterns. AI rule: 'Naming: camelCase for variables, functions, and methods. PascalCase for classes, interfaces, types, and React components. UPPER_SNAKE_CASE for constants and enum values. Prefix interfaces with I only if the team convention requires it (check existing code).' The AI rule: more explicit than the ESLint config because the AI generates from the description, not from a pattern matcher.

Imports: ESLint: 'import/order' with groups [builtin, external, internal, parent, sibling]. AI rule: 'Import ordering: (1) Node.js built-in modules, (2) external packages (from node_modules), (3) internal aliases (@/ imports), (4) relative imports (parent then sibling). Blank line between each group. Alphabetical within each group.' The AI rule: describes the ordering in words. The ESLint rule: enforces it with a config object. Both produce the same result — the AI rule prevents, ESLint catches.

Patterns: ESLint: 'prefer-const', 'no-var', 'prefer-arrow-callback'. AI rule: 'Use const by default. Use let only when reassignment is necessary. Never use var. Use arrow functions for callbacks and anonymous functions. Use function declarations for named functions that are hoisted.' The AI rule: combines multiple ESLint rules into one coherent pattern description. The AI: follows the combined pattern naturally. AI rule: 'Group related ESLint rules into single AI rules. The AI understands a coherent pattern better than a list of individual constraints.'

⚠️ Do Not Convert Formatting Rules — Let the Formatter Handle Them

ESLint: 'indent': ['error', 2], 'semi': ['error', 'always'], 'quotes': ['error', 'single']. These rules: should NOT become AI rules. Reason: Prettier (or your formatter) handles formatting after the AI generates code. The AI does not need to generate perfectly formatted code — the formatter fixes formatting automatically. Converting formatting rules to AI rules: wastes the AI's attention on something the formatter handles better.

Step 3: AI Rules + ESLint = Defense in Depth

Keep ESLint alongside AI rules: do not remove ESLint after adding AI rules. AI rules: prevent 90% of violations at generation time. ESLint: catches the 10% that slip through (manually written code, AI output that was modified, edge cases the AI mishandled). Together: near-100% convention compliance. The AI prevents. ESLint catches. Both enforce the same conventions from different angles.

Resolve contradictions: if your AI rules and ESLint rules contradict (rare but possible): the ESLint rule is the source of truth (it is more specific and testable). Update the AI rule to match. If the AI generates code that ESLint rejects: the AI rule is too permissive or vague. Tighten the AI rule until the AI generates ESLint-clean code. AI rule: 'ESLint is the arbiter. If the AI generates code that ESLint rejects: the AI rule needs improvement, not the ESLint config.'

The virtuous cycle: AI rules reduce ESLint violations (fewer violations to fix after generation). Fewer violations: make code reviews faster. Faster reviews: let the team focus on logic and architecture. When ESLint does catch a violation: it reveals an AI rule gap. Add or refine the AI rule. Over time: ESLint catches fewer and fewer violations because the AI rules get better with each iteration. AI rule: 'Every ESLint violation in AI-generated code: is a signal to improve the AI rules. The goal: zero ESLint violations in AI output. Not by disabling ESLint — by making AI rules so good that ESLint has nothing to catch.'

ℹ️ Every ESLint Violation in AI Output = AI Rule Gap

The AI generates code. ESLint reports: 'prefer-const: use const instead of let for variable X.' The AI used let where const was correct. The AI rule either: does not mention const/let preference (gap — add the rule), or mentions it too vaguely ('use const when possible' — the AI did not determine it was possible). Fix the AI rule. Re-test. The ESLint violation: disappears from future AI output. This feedback loop: makes AI rules progressively more effective.

ESLint to AI Rules Summary

Summary of converting ESLint rules to AI rules.

ESLint config: already encodes your team's conventions. Extract, do not reinvent
Convert: naming rules, import rules, pattern rules. Skip: formatting, error detection, complexity
Expand: ESLint rule names → prose descriptions. The AI needs context, not config options
Group: combine related ESLint rules into single coherent AI rules (const + no-var + arrow = one rule)
Keep ESLint: AI prevents 90%, ESLint catches 10%. Together: near-100% compliance
ESLint is the arbiter: if AI output fails ESLint, improve the AI rule (not the ESLint config)
Virtuous cycle: every ESLint violation in AI code → improve the AI rule → fewer future violations
Time: 15 minutes to extract conventions. 15 minutes to write AI rules. 30 minutes total