The AI Acceleration Gap
The speed of AI code generation, exemplified by tools like Claude Code and Codex, is rapidly outpacing the feedback loop provided by traditional linters such as ESLint. Developers find themselves in a workflow where an AI can generate hundreds of lines of code in moments, only to be bottlenecked by a linter that takes significantly longer to validate the changes. This delay frustrates the rapid iteration cycle essential for productive development.
The author of the original piece switched from ESLint to Biome specifically because linting had become the slowest part of their development process. AI tools could deliver complete code patches, but the subsequent wait for ESLint to confirm their validity rendered the entire process sluggish. Biome, in contrast, offered an immediate save-and-check experience, albeit with a compromise on some highly specific, type-aware rules that were rarely scrutinized closely by the developer.
ESLint's Architectural Limitations
ESLint was not architected for the modern development paradigm where AI generates massive code changes in single commits. Its plugin-based framework inherently introduces overhead at each layer. A typical ESLint setup involves:
- A parser (e.g.,
@typescript-eslint/parser, Babel, or both) to transform code into an Abstract Syntax Tree (AST). - Multiple plugins that extend ESLint's capabilities, often with configurations that themselves extend other configurations, creating complex dependency chains.
- Optional type-checking integration, which requires resolving the entire TypeScript type graph.
The optional type-checking feature is particularly performance-intensive. Rules like @typescript-eslint/no-floating-promises necessitate that ESLint first resolves the complete TypeScript type graph for the project. On medium-sized projects, this process alone can consume considerable time, often exceeding 15 to 30 seconds, which is an unacceptable delay in an AI-driven development environment.
Biome's Performance Advantage
Biome represents a new generation of developer tools designed with performance as a core tenet. Unlike ESLint's plugin-heavy architecture, Biome is built as a single, integrated binary. This architectural choice significantly reduces overhead. It handles parsing, linting, and formatting within a unified process, eliminating the inter-process communication and repeated parsing that can slow down monolithic setups like ESLint.
Biome's design prioritizes speed for common development tasks. By streamlining the workflow and optimizing critical paths, it achieves near-instantaneous feedback. This aligns with the expectations set by AI coding assistants, where developers anticipate immediate validation of generated code. While Biome may not support every niche ESLint rule out-of-the-box, its speed advantage for the majority of linting and formatting tasks makes it a compelling alternative for teams embracing AI-assisted development.
The Trade-offs and Future of Linting
The shift towards faster linters like Biome highlights a critical trade-off: performance versus rule comprehensiveness. Developers must weigh the immediate benefits of a rapid feedback loop against the potential loss of highly specific, type-aware rules that might have been used infrequently or were redundant. For many, the immediacy of knowing whether an AI-generated patch is syntactically correct and adheres to general style guides outweighs the need for exhaustive type-checking during the initial save-and-check cycle.
This trend suggests a future where linters are not just static analysis tools but integral components of a high-speed, AI-augmented development workflow. The focus will shift from exhaustive rule sets to efficient, incremental analysis that can keep pace with AI-generated code. Tools that can provide rapid, actionable feedback will become indispensable. The question remains: will traditional linters adapt, or will new, performance-first tools like Biome dominate the landscape?
What nobody has addressed yet is how the broader ecosystem of custom ESLint plugins and configurations will migrate or be replaced. Developers who have invested years in building bespoke ESLint rule sets may face a significant refactoring effort if they decide to switch to newer, faster tools.