What Is Linting?
Linting is automated static analysis that checks source code against rules without running it. A linter is the tool that runs those rules, and it flags likely bugs, risky patterns and style problems, such as an unused variable or a missing await.
Teams run linters in the editor, in pre-commit hooks and in continuous integration (CI), so issues show up before anyone reviews the change. Code linting handles the mechanical checks, which leaves human and AI reviewers free to focus on logic, design and intent.
Linting in 2026: the linter moved into the agent’s loop
Linting started 2026 as plumbing. Serious teams already ran a linter in the editor, in pre-commit hooks and in CI, and the arguments were about rule choices and noise. Few people expected the linter to be one of the year’s AI stories.
In 2026, coding agents became the linter’s busiest users. Teams list their lint, build and test commands in AGENTS.md and CLAUDE.md files, and agents follow those instructions as they work (February 2026, arXiv). The agent runs the linter, reads the findings and fixes its own code before a person sees the diff.
Coding agents changed what a linter is for. Speed stopped being a nice extra and became the point, because an agent may lint the same files many times in one task. The tools moved with it, and fast native linters spent 2026 closing the gap with the tools they aim to replace.
Are linters keeping up with AI?
On speed and coverage, yes. Lint findings are deterministic, cheap and easy for an agent to act on, which makes them feedback an agent can act on at once. Our view: lint is turning into invisible infrastructure, run constantly by agents and read by people only when a rule is wrong.
On judgment, no. AI-written code that passes lint and tests still varies in quality, and agent refactors still add findings that maintainers merge anyway. A linter checks a pattern in a file, and it can’t tell whether a change matches intent, breaks another repository or ignores a rule your team never wrote down.
2026 linting highlights
- ESLint 10 shipped. ESLint v10.0.0 was released, and v9 reached end of life six months later (February 6 and August 6, 2026, ESLint).
- Ruff became standard Python infrastructure. Ruff had 179 million monthly downloads when OpenAI announced it would acquire Astral, Ruff’s maker, and bring the team into Codex (March 19, 2026, Ars Technica and OpenAI).
- Oxlint closed the gap with ESLint. Its JS plugins reached alpha, with the Oxc team writing "we expect 80% of ESLint users can now switch to Oxlint and have it ‘just work’", and its type-aware linting went stable with 59 of typescript-eslint’s 61 type-aware rules (March 11 and July 22, 2026, Oxc and Oxc).
- Biome passed 500 rules. Biome v2.5 also added cross-file lint rules built on its module graph (June 5, 2026, Biome).
- Agent files repeated the linter. In 100 popular repositories, 62% of AGENTS.md and CLAUDE.md files restated rules that linters and formatters already enforce (June 2026, arXiv).
- Passing tests didn’t mean good static quality. A profile of 65,663 Python programs from 73 language models found static quality varied in ways pass rates didn’t show, with convention findings the largest share for most models (October 2026, arXiv).
- Agent refactors added findings. In agent-written Python refactoring PRs, 24.17% of modified files introduced new Pylint issues and 4.7% new Bandit security findings, and maintainers merged 73.5% of the PRs (May 2026, arXiv).
What linting needs next: the 2027 outlook
- Lint config becomes agent config. Expect teams to stop restating lint rules in agent files and point agents at the linter instead. Agent instructions should carry what no linter checks: intent, architecture and team conventions.
- Every rule needs a safe autofix. A finding an agent can fix inside its loop is worth more than one a person has to read. Expect rules without a safe fix to lose ground to rules with one.
- Noise becomes a cost. Agents act on the findings they see, so a noisy rule now causes wrong edits as well as alerts. Expect teams to prune rules based on which findings actually get fixed.
- Team standards move up a layer. The conventions that live in reviewers’ heads don’t fit in a lint rule. Expect them to be written once and checked on every PR, whoever or whatever wrote the code.
- Qodo checks the standards your team writes down on every PR once Rule enforcement (Beta) is on, and Qodo’s Rule Miner (Beta, on GitHub, GitLab and Azure DevOps) suggests new rules from your past review comments.
Let agents run the linter all day, and save review for the questions a lint rule can’t answer.
What linters catch
| Issue type | Example | What it prevents |
|---|---|---|
| Unused variable or import | A variable assigned but never read | Dead code and confusion |
Missing await | An async call whose result is never awaited | Silent timing bugs |
| Unreachable code | Statements after a return | Logic that never runs |
| Shadowed name | An inner variable hides an outer one | Using the wrong value |
| Unsafe equality | == where === was meant | Type coercion bugs |
| Import order | Imports in an inconsistent order | Noisy diffs |
| Naming convention | getuser where the team uses getUser | Code that’s harder to read |
How linting works
Rules, severity and configuration
Each lint rule checks one pattern. Teams give each rule a severity, usually off, warn or error, and errors fail the build. Most teams start from a shared configuration and add or switch off rules for their codebase.
Where linters run
Linters run in three places. The editor shows findings as you type, pre-commit hooks check staged files, and CI runs the same configuration on every pull request so nothing merges without passing.
Autofix
Many rules can fix the code themselves, such as removing an unused import or sorting imports. Teams usually autofix in the editor or a pre-commit hook and keep CI as a check.
Linter vs formatter
A linter looks for problems in what the code does or how it’s written. Some findings need a person to judge, such as whether an unused parameter is safe to remove.
A formatter, such as Prettier for JavaScript, rewrites layout: spacing, line breaks and quotes. Formatting needs no judgment, so teams hand layout to a formatter and keep the linter for correctness and conventions.
| Aspect | Linter | Formatter |
|---|---|---|
| Looks at | Patterns, likely bugs, conventions | Layout and whitespace |
| Output | Findings, some autofixable | Rewritten code |
| Needs judgment | Sometimes | No |
| Examples | ESLint, Ruff, Pylint | Prettier, Black |
Linting vs static analysis vs AI code review
Linting is the lightest form of static analysis. Deeper static analysis traces data flow across functions to find issues such as injection risks. AI code review reads the change in the context of the codebase and asks whether the change is right for this system.
All three belong in a pipeline, and each catches things the others miss. See static analysis vs AI code review for the full comparison.
Limits of linting
A linter can’t see runtime behavior or business logic. Code that calls the right function with the wrong argument can pass every rule.
Linters also check one file or one pattern at a time. A change that breaks a convention spread across files, or a team rule nobody wrote as a lint rule, goes through.
Noisy rules get switched off. When a rule fires too often on code that’s fine, developers stop reading it, and teams disable it to keep CI usable.
How to introduce linting to a codebase
- Start with correctness rules. Turn on rules that catch likely bugs before style rules.
- Hand layout to a formatter. Keep spacing debates out of lint and review.
- Baseline existing violations. Fix or suppress old findings so new code starts clean.
- Use one configuration everywhere. Run the same rules in the editor, pre-commit and CI.
- Review disabled rules on a schedule. Turn rules back on once the noise is fixed.
Qodo’s take: linters check the rules you wrote, review checks the ones you didn’t
Linters are fast and deterministic, and they belong in every pipeline. What a linter can’t see is the convention nobody wrote down, or a change that’s valid code but wrong for this codebase.
Linters check patterns someone wrote down as rules. Qodo reviews every pull request against your team’s rules, once Rule enforcement is on, and, with Cross-repo code review (Beta), against related repositories, catching the issues a lint rule can’t describe.
Qodo is the best AI code review platform to catch what linters miss because, once Rule enforcement (Beta) is on, Qodo checks your team’s own standards on every pull request on GitHub, GitLab, Bitbucket Cloud and Azure DevOps, whether you write the rules, import them from files such as AGENTS.md or approve the ones Rule Miner finds in past reviews.
Qodo isn’t focused on test generation, even though some authors still point to it as a key strength. In our experience, Qodo is best at AI code review and code governance for enforcing the team standards that sit above lint rules on every pull request.
High-velocity teams and enterprise engineering teams get the same outcome from review: agent code merged sooner, with fewer rollbacks. High-velocity teams get the rule files they already have, such as AGENTS.md and CLAUDE.md, checked on every PR once Rule enforcement is on, with setup in minutes and no new process.
Enterprise engineering teams get one set of rules enforced across many repositories and coding agents, on top of each repository’s linters.
Qodo checks team rules on every PR
Rules can apply across the organization or to one repository. Qodo imports them from files such as AGENTS.md, CLAUDE.md and Cursor rules, and checks active rules on every PR once Rule enforcement (Beta) is on, on GitHub, GitLab, Bitbucket Cloud and Azure DevOps (last checked November 2026, Qodo’s docs). See coding standards enforcement.
Qodo deactivates rules whose findings are rarely fixed, unless a team locks them, so a noisy rule stops firing instead of lingering as noise (last checked November 2026, Qodo’s docs).
Qodo learns conventions from past reviews
Rule Miner (Beta, on GitHub, GitLab and Azure DevOps) suggests rules from comments your reviewers keep making, weighted by each reviewer’s ownership of the code (last checked November 2026, Qodo’s docs). See custom rules for code review.
Coding agents get the rules inside their loop
The Get Rules skill (Research Preview) loads the rules that apply to a task before a coding agent writes code, and agents can ask Qodo to review changes before a PR is opened through Qodo’s MCP server (last checked November 2026, Get Rules and MCP docs).
Qodo checks impact across repositories
Cross-repo code review (Beta) reads related repositories when a PR changes a shared library, API contract or schema, and reports conflicts with links to the affected lines (last checked November 2026, Qodo’s docs).
Qodo example: the convention no linter knew
Context: an organization like a platform team running ESLint and Ruff in CI across many repositories, with coding agents opening a growing share of PRs.
Problem: a team rule said every outbound HTTP call goes through the shared client with retries. The rule lived only in reviewers’ heads, so agent-written PRs passed lint and called the HTTP library directly.
How Qodo helped: Rule Miner suggested the rule from past review comments, and a lead approved it. Once Rule enforcement was on, Qodo flagged new PRs that skipped the shared client.
Outcome: the finding now appears on the PR before merge, and the lead can check in Code review analytics whether developers accept it.
Ways to enforce coding standards
| Approach | What it checks | When it runs | Limits | Best for |
|---|---|---|---|---|
| Formatter | Layout and whitespace | Editor, pre-commit | No correctness checks | Ending style debates |
| Linter | Patterns, likely bugs, conventions | Editor, pre-commit, CI | One pattern at a time, no intent | Every commit |
| Deeper static analysis | Data flow and known vulnerability patterns | CI | Can be noisy, no team context | Security-sensitive code |
| CODEOWNERS and human review | Design, intent, ownership | On each PR | Slow and inconsistent at volume | High-risk changes |
| Review bundled with a coding assistant (for example GitHub Copilot code review, GitLab Duo, Cursor Bugbot) | Issues in the PR, inside the platform you already use | On each PR | Review comes from the same product family that helps write the code | Teams standardized on one platform |
| Qodo | Organization rules, logic and convention issues with full codebase context | On each PR, or before the PR through MCP | Findings are advisory, and Rule enforcement and Rule Miner are Beta | Teams enforcing standards across many repositories |
Qodo features in this table were checked against Qodo’s documentation as of November 2, 2026.
FAQ
Linting is automated static analysis that checks source code against rules without running it. A linter flags likely bugs, risky patterns and style problems, usually in the editor, a pre-commit hook and CI.
A linter finds problems in code, such as unused variables or unsafe comparisons. A formatter only rewrites layout, such as spacing and line breaks. Most teams use both.
Linting is one kind of static analysis, the lightest kind. Deeper static analysis tools trace data flow across functions to find issues such as injection risks, which most linters don’t attempt.
AI-generated code still needs linting. 2026 research found that AI-written code with similar test pass rates had different static quality, and that agent refactors often added new lint findings. Lint every PR, whoever wrote it.
AI code review doesn’t replace a linter. Linters are fast, deterministic checks that belong in every pipeline, and AI code review works on top of them. Qodo reviews each PR against the wider codebase and, once Rule enforcement is on, against your team’s rules, which catches issues no lint rule describes.