unknown

AI-generated code is fast but inconsistent, making linters more valuable than ever. Custom lint rules can enforce translation key validity, prevent hardcoded strings, ban specific imports, enforce architectural boundaries, and eliminate entire categories of repetitive review comments. Unlike AI code review instructions (CLAUDE.md, AGENTS.md), linters are deterministic — they either pass or fail every time. The post also covers configuration best practices: run linters in the editor with autofixes on save, use CI as a safety net, and be cautious with pre-commit hooks that slow down frequent commits.

Linters: The Most Underabused Tool In The AI-Slop Era

Fabian Letsch

<h1>In the grim darkness of the far future, there is only code reviews</h1>
TDD + Linters is the way forward.
<img src="https://media.daily.dev/image/upload/s--wXYkyrTL--/f_auto/v1776247211/ugc/content_0cbba94b-8f7c-44f5-aae5-5d8d78b7a4d9?_a=BAMAMiWQ0" alt="image.png">

I found it very useful with ClaudeCode to apply tool use hooks to ban deployment and builds via bash and instead provide it with a tool/MCP (MCP basically interpreter with a bunch of discoverable tools, Claude writes code in a scratch file and asks the MCP to eval it, I use files because Claude can diff edit them and promote into a snippets storage if they are reusable) .
This way it can’t bypass lints, test gates + I log all the ops in db and sometimes review with LLM to see if we can optimize the API (tool surface) also I gave it a rule to write md files with reviews on our tasks when it ended up struggling and detected an issue with our flow.
SessionStart hooks are also cool to smoke test the system, check for stale deps, zombie containers. I auto generate workspace report for Claude and inject into its session context but ClaudeCode has very small limit for this (token count) so instead I inject file path to the report. But then Claude usually ignores it and doesn’t read the file (even with the rule that “forces” it to) so I ended up banning all tool use until it reads it (the text of the report contains name of the flag file that it needs to create to unlock the tools) - works like a charm 😃
Also I’m considering banning main ClaudeCode instance from writing tests (and altering test files in any way) to reduce cheating (mainly, when it get’s low on context it starts to disable tests) I probably need an agent for test authoring that is intentionally adversarial to the code writer (main Claude) - tries to fail it. You can actually enforce Red/green TDD with this (Well, theoretically) by driving the cycle via script that first unlicks test writer agent that must write a test that fails and then switch turns to the code writer that must write code that make tests pass and this auto switches turn to the testing agent that writes tests (one of another intentionally blocked via hooks) It might be a cool idea but I bet it will go super slow. But then maybe if you run it fully independently :thinking: Yeah and I’m not sure how to force both sides to work granularly. Maybe with dynamic tool call back based of current diff? Like if we got a new function or N lines of code I will block all claude tool actions on all the files except the one that passes the check and/or switch to test agent action (agent call) something like that. It’s kinda getting too hacky.

Great article. Rules are good but people need to think in the terms of the rules.Unless you see the problem linter is solving you do not know why linter is good. The same problem is with AI you can not know something is good or bad unless you first type yourself and create mental model what happens each move you make.

Linters are just a single cogwheel in the whole system of code review. Using LLM code efficiently is a lot about efficiently review code with high quality standards, which you can enforce programmatically.