What Is Linting (and Why Does the AI's Code Keep Failing It)?

Quick answer
A linter statically analyzes code for bugs, style violations, and dangerous patterns — without running it.
It catches typos, unused imports, unhandled errors, and anti-patterns in milliseconds instead of at runtime.
AI-generated code has lint errors at a comically high rate; running a linter after generation is the cheapest review you can do.

What does a linter do?

A linter parses your code and checks it against a rule set: syntax errors, undefined variables, unused imports, unreachable code, dangerous constructs (SQL built by string concatenation, bare except clauses), and style conventions. It runs in milliseconds without executing the program. Rules range from trivial (consistent quotes) to genuinely safety-relevant (detecting f-string SQL, missing error handling). Formatters like Prettier and Black handle style; linters handle correctness and smell — most projects use both.

Why does linting matter more with AI-generated code?

Because generated code is statistically fluent but often wrong in exactly the ways linters catch: imported-but-unused modules, variables typed wrong, functions called with the wrong arguments, security anti-patterns copy-pasted from training data. A human reviewing 200 lines of generated code misses things; a linter reviews it instantly and objectively. Running the linter after every generation is the cheapest quality gate available — it turns ‘looks fine’ into ‘actually fine’ for the mechanical part of review.

How do I set one up?

Install the linter for your language and add it to the project: ESLint (with typescript-eslint) for JS/TS, Ruff or Flake8 for Python, golangci-lint for Go. Add the config file to the repo, run it in CI so a lint failure blocks the merge, and wire it into your editor so problems surface as you type. Start with the default rule set — you can tune it later, but defaults catch the important stuff. The AI assistant can generate the config, but the config should live in the repo and run in CI regardless.

# Python: Ruff, one command, zero config for common rules\npip install ruff\nruff check .\n# 2 errors, 1 warning found:\n#   app.py:14: SQL injection risk — f-string in execute()\n#   app.py:22: unused import 'os'

Where this bites vibecoders
The fastest way to see how much garbage an AI generates: pipe its output through a linter. The error count is usually embarrassing, and each error is a bug that would have shipped. The vibecoder habit that pays for itself: after every generation, run the linter and paste the errors back at the assistant with ‘fix these’. It closes the loop mechanically, and it’s how you keep generated code from degrading the codebase.

Where AI coding assistants get this wrong

Generating code that never passes a linter — unused imports, bare excepts, unsafe patterns.
Fixing lint errors by disabling the rule instead of fixing the code.
No lint config in the repo, so every contributor’s style drifts.
Running lint only locally, so CI merges code that never passed.

Checklist

Install a linter for your language with sensible defaults.
Add it to CI so lint failures block merges.
Wire it into the editor for instant feedback.
Run lint on AI-generated code and fix the errors before review.

FAQ

What is the difference between a linter and a formatter?

A formatter (Prettier, Black) rewrites code to a consistent style — spacing, quotes, line length. A linter checks for bugs and dangerous patterns. They complement each other: the formatter makes code uniform, the linter makes it correct. Most setups run both.

Can a linter replace a code review?

No — linters catch mechanical problems, not design flaws. A linter won’t tell you the architecture is wrong or the authorization check is missing. Think of it as the first, automated layer of review: it handles what’s objectively checkable, leaving humans (or a more thoughtful AI review) for judgment.