ESLint catches problems. That's the easy part. Fixing those problems - that's where the work lives. Run ESLint on a mature codebase and you'll see hundreds, sometimes thousands, of warnings and errors. Each one needs attention. Each one is a context switch. Each one is a small tax on developer productivity.
The irony is that most ESLint fixes are mechanical. Add a semicolon. Remove an unused variable. Convert a function to arrow syntax. These aren't decisions - they're transformations. They're exactly the kind of tedious, repetitive work that shouldn't consume human time.
AI agents can fix linting issues across your entire codebase while you focus on work that actually requires thinking.
The ESLint Maintenance Problem
Every team has experienced the ESLint debt spiral:
- You add ESLint to enforce code quality
- Rules accumulate over time
- New rules flag existing code
- Warnings pile up because fixing them isn't prioritized
- Developers start ignoring warnings
- The linting output becomes useless noise
- Someone suggests disabling problematic rules
The underlying issue isn't ESLint - it's the gap between identifying problems and fixing them. ESLint's --fix flag handles some issues, but many rules require manual fixes. And even auto-fixable issues need someone to run the command and commit the changes.
Beyond --fix
ESLint's built-in --fix flag handles a subset of issues. But many rules can't be auto-fixed because they require understanding context:
- Unused variables need human judgment about whether to remove or use them
- Complex refactoring patterns need semantic understanding
- Cross-file issues need awareness of the broader codebase
- Some fixes introduce new issues that need resolution
AI agents understand context. They can make the judgment calls that simple pattern matching cannot.
@devonair fix all ESLint errors in /src, including those that can't be auto-fixed
The agent reads the code, understands what the linter wants, and makes intelligent fixes.
Types of ESLint Issues to Automate
Auto-Fixable Issues at Scale
Even for issues ESLint can fix itself, automation helps:
@devonair run eslint --fix across /src and commit the changes
This handles the mechanical application and the git workflow around it.
Unused Variables and Imports
ESLint flags them, but can't decide what to do:
@devonair remove all unused variables in /src
@devonair remove all unused imports across the codebase
The agent analyzes each unused item and removes it safely.
Deprecated API Usage
When ESLint warns about deprecated patterns:
@devonair update all deprecated React lifecycle methods to their modern equivalents
@devonair replace deprecated lodash methods with recommended alternatives
Accessibility Issues
ESLint a11y plugins flag accessibility problems:
@devonair fix all jsx-a11y errors in /src/components
@devonair add missing alt attributes to all images
TypeScript-Specific Issues
TypeScript ESLint rules often need context:
@devonair fix all @typescript-eslint/no-explicit-any errors by adding proper types
@devonair resolve @typescript-eslint/no-unused-vars warnings
Import Organization
Messy imports violate linting rules:
@devonair organize imports in all files according to eslint-plugin-import rules
@devonair fix all import/order violations across /src
Fixing Strategies
The Full Cleanup
Fix everything at once:
@devonair fix all ESLint errors and warnings in /src
Best for: Smaller codebases, teams ready for large PRs, comprehensive test coverage.
The Incremental Approach
Fix by directory or module:
@devonair fix all ESLint errors in /src/components
Then:
@devonair fix all ESLint errors in /src/utils
Best for: Larger codebases, manageable PR sizes, gradual rollout.
The Rule-Based Approach
Fix one rule at a time:
@devonair fix all no-unused-vars errors across /src
@devonair fix all prefer-const violations across /src
Best for: High-risk rules, learning how fixes affect the codebase.
The Severity-Based Approach
Prioritize by importance:
@devonair fix all ESLint errors in /src (ignore warnings for now)
Then later:
@devonair fix all ESLint warnings in /src
Best for: Large backlogs, quick wins on blocking issues.
Handling Complex Fixes
Some ESLint issues require more than mechanical fixes.
Unused Variables with Side Effects
// ESLint says unused, but it has a side effect
const initialized = initializeApp();
The agent understands when "unused" variables matter:
@devonair fix unused variable warnings, preserving variables with side effects
Circular Dependencies
@devonair resolve circular dependency warnings by refactoring affected modules
The agent analyzes the dependency graph and restructures imports.
Complex Destructuring
@devonair fix prefer-destructuring warnings with appropriate destructuring patterns
The agent applies destructuring correctly for objects and arrays.
Promise Handling
@devonair fix all no-floating-promises errors with proper await or void handling
The agent understands async context and applies appropriate fixes.
Maintaining Lint-Free State
Getting to zero violations is step one. Staying there is the ongoing challenge.
Pre-Commit Enforcement
@devonair on PR: fix any new ESLint errors before merge
New violations never enter the codebase.
Scheduled Cleanup
@devonair schedule weekly: fix any ESLint violations that have accumulated
Catch anything that slipped through.
Rule Addition Workflow
When adding new ESLint rules:
@devonair we're enabling the prefer-const rule - fix all violations across /src
New rules don't create new backlog.
Upgrade Workflow
When upgrading ESLint or plugins:
@devonair upgrade eslint to latest and fix any new violations from stricter rules
Upgrades don't create debt.
ESLint Configuration Optimization
Beyond fixing violations, optimize your ESLint setup:
Rule Recommendations
@devonair analyze our codebase and recommend ESLint rules we should enable
@devonair identify ESLint rules we have disabled that we could now enable
Configuration Cleanup
@devonair identify ESLint rules in our config that never trigger violations
Remove rules that don't apply to your codebase.
Override Optimization
@devonair consolidate ESLint overrides and remove redundant configuration
Clean configuration is maintainable configuration.
Plugin-Specific Automation
Different ESLint plugins have different fix patterns.
React Plugin
@devonair fix all react/prop-types errors by adding PropTypes or TypeScript types
@devonair fix react/jsx-key warnings by adding keys to list items
Import Plugin
@devonair fix all import/no-unresolved errors by correcting import paths
@devonair fix import/no-default-export by converting to named exports
TypeScript ESLint
@devonair fix @typescript-eslint/explicit-function-return-type by adding return types
@devonair fix @typescript-eslint/strict-boolean-expressions violations
Security Plugins
@devonair fix all eslint-plugin-security warnings in /src
Security-related lint fixes are especially important to automate.
Accessibility Plugins
@devonair fix all jsx-a11y warnings with appropriate ARIA attributes and elements
Accessibility shouldn't be optional because fixes are tedious.
Fixing Without Breaking
Lint fixes should improve code, not break it.
Test Verification
@devonair fix ESLint errors in /src and run the test suite
Verify fixes don't change behavior.
Build Verification
@devonair fix ESLint errors and verify the project builds
Catch compilation issues from fixes.
Type Checking
@devonair fix ESLint errors and run TypeScript type checking
Ensure fixes don't introduce type errors.
Staged Fixes
@devonair fix ESLint errors in small batches with test runs between each
Isolate any problematic fixes.
Handling eslint-disable Comments
Legacy codebases accumulate disable comments:
Audit Existing Disables
@devonair list all eslint-disable comments with their reasons and file locations
Understand what's been disabled and why.
Remove Unnecessary Disables
@devonair remove eslint-disable comments for rules that no longer trigger
Clean up obsolete suppressions.
Fix Instead of Disable
@devonair review eslint-disable comments and fix the underlying issues where possible
Replace suppression with resolution.
Require Justification
@devonair add missing justification comments to all eslint-disable statements
Future maintainers deserve context.
Measuring Lint Health
Track improvement over time:
Violation Counts
@devonair report on ESLint violation count by rule and directory
Identify hotspots and trends.
Disabled Rule Tracking
@devonair track eslint-disable usage over time and flag increases
Prevent disable comment proliferation.
New vs. Fixed Ratio
@devonair report on ESLint violations introduced vs. fixed this week
Ensure you're improving, not declining.
Coverage Metrics
@devonair calculate percentage of files with zero ESLint violations
Track progress toward full compliance.
Team Workflow Integration
ESLint automation works best when integrated into team processes.
PR-Level Fixing
@devonair on PR: auto-fix any ESLint errors introduced by this PR
Developers don't need to run ESLint locally.
Pre-Release Cleanup
@devonair before release: ensure zero ESLint errors in /src
Releases ship with clean code.
Onboarding
@devonair document our ESLint configuration and explain key rules
Help new team members understand the rules.
Configuration Updates
@devonair when eslint config changes: fix all new violations before merging config
Configuration changes include their fixes.
Getting Started
Start with the lowest-risk, highest-volume fixes:
@devonair fix all auto-fixable ESLint errors in /src
This handles formatting, semicolons, quotes - all the trivial stuff.
Then tackle specific high-value rules:
@devonair remove all unused imports in /src
Unused imports are safe to remove and reduce bundle size.
Set up ongoing maintenance:
@devonair on PR: fix any ESLint errors in changed files
From now on, new code stays clean while you gradually address the backlog.
ESLint violations exist to be fixed, not tolerated. When fixing is automatic, your codebase actually becomes the clean, consistent code ESLint promises.
FAQ
Won't automatic fixes introduce bugs?
The agent understands context and makes intelligent fixes. For high-risk changes, it runs tests to verify behavior. Review the PR like any code change - you have full visibility into what changed.
What about ESLint rules that are style preferences?
Automation is especially good for style rules. Consistent style matters more than which style you pick. Let the agent enforce whatever style your config specifies.
How do I handle disagreements with ESLint rules?
If a rule doesn't fit your codebase, disable it in your config. Don't accumulate violations for rules you've decided not to follow. Clean violations from rules you do follow.
Can this work with Prettier too?
Yes. Prettier and ESLint have some overlap, but handle different concerns. Run both:
@devonair fix all ESLint and Prettier violations in /src
The agent respects both configurations.