We talk to dozens of engineers and engineering leaders every day, and no one has a clear answer on what they feel about linters; it’s a complex feeling they have towards these tools, depending on which day of the week you ask them.
A linter is a tool to help you improve your code. It analyzes source code to identify and flag potential errors, bugs, stylistic issues, and suspicious constructs. It helps developers improve code quality by catching issues early in the development process, ensuring a more consistent and readable codebase. Linters typically operate by comparing code against a predefined set of rules and notifying the user about violations.
Developers don’t hate rules. They hate dumb rules.
You know the ones - where the linter yells at you for a missing newline, but completely ignores the fact that your function is 200 lines long and named doStuff().
It’s not that linters are evil. It’s just that most of them have the personality of a DMV clerk and the judgment of a coin toss. They enforce style with the confidence of a dictator and the context-awareness of a potato.
If you’ve ever rage-committed a // eslint-disable comment just to move on with your life, you know the feeling.
What Linters Do (and Why They Exist)
At their core, linters are enforcers; they just go about following the rules set. Their job is to keep your codebase consistent, clean, and in an ideal world scenario, less buggy.
They scan your code - not by running it, but by reading it - looking for things that might be errors, style violations, or just generally “not how we do things around here.”
A good linter can:
- Warns you about code that might lead to bugs. (e.g., unused variables, shadowed scopes, missing returns).
- Enforce a consistent style across the team (because tabs vs. spaces shouldn’t be a debate).
- Codify best practices so junior devs don’t have to learn the hard way.
How they work:
- Linters perform static analysis - they read your code without executing it.
- They match it against a set of rules, often configurable.
- These rules get enforced at different points: in your editor, during pre-commit hooks, or as part of CI pipelines.
A few standard lint tools in use:
StandardJSand Prettier for JS style enforcementESLintfor broader JavaScript/TypeScript rulesPylintandflake8for PythonRuboCopforRubygolint,staticcheck, andGosecfor GoStyleCopfor C# and .NET projects
In theory, they keep chaos out of the repo. In practice... well, keep reading.
The Benefits: Why We Still Use Them
For all the grumbling, linters stick around for good reason. They're not just annoying, they're also genuinely useful. Here’s why teams still rely on them:
- Code consistency across teams
Linters make sure everyone plays by the same rules. Whether it’s formatting, naming, or structure, you get a consistent codebase, even if half your team secretly prefers different styles. - Early error detection
Catching a missing await, a forgotten import, or a dangerous global before the code even runs? That’s a win. Linters act as a first line of defense against silly (and sometimes serious) bugs. - Helping junior developers ramp up
Linters quietly nudge newer devs toward better patterns without requiring a senior engineer to leave 17 comments on a PR. They’re like having a style guide that enforces itself. - Automating the nitpicks
No more PR debates over spacing or semicolons. Linters take the low-value, high-frequency arguments off the table so your team can focus on the code that actually matters. - Increased productivity
Developers spend less time debugging and more time focusing on the core functionality of the code, optimising the business logic and making the application run faster.
The Disadvantages: Why Developers Grumble
Linters promise structure, but often deliver stress. This doesn’t mean linters are bad, but they are blunt. What starts as a well-meaning tool often becomes a source of frustration, fatigue, and diminishing returns. Let’s break down where things go wrong both for individual developers and for the teams trying to ship features at scale:
Developer Frustrations
- False positives & developer fatigue
Linters sometimes complain about things that aren’t real problems. A missing semicolon? A variable used just enough times? These warnings accumulate, and devs start tuning them out. Over time, this “warning fatigue” kills the value of the tool altogether. - Loss of flow
Nothing breaks your concentration like a linter nagging you to rename a variable while you’re deep into debugging complex logic. It’s like being asked to vacuum during brain surgery. - Blocked commits for petty issues
Pre-commit hooks or CI pipelines that block code over formatting quirks (like extra spaces) can feel more frustrating than helpful. It slows progress without improving the actual code. - Steep learning curve for new devs
Instead of focusing on business logic or learning the codebase, new hires often spend their first week figuring out how to make the linter stop yelling. - Limited learning value
Linters say what you did wrong, but rarely explain why or how to improve. They teach rules, not reasoning.
Team & Org-Level Issues
- Rule creep with no ownership
Linters tend to accumulate rules like old legacy endpoints; someone adds a new one, no one dares remove it. Eventually, you're enforcing standards no one even agrees with. - Linter debates in PRs
"This rule is dumb."
"But it’s enforced by the linter."
"Yeah, but it’s still dumb."
PRs devolve into arguments about tools instead of code. - Silencing becomes standard practice
When devs routinely reach for#noqa,eslint-disable-next-line, or suppressions in config files, you’re not enforcing quality - you’re enforcing workarounds. - Limited scope & context-awareness
Linters don’t understand architecture, domain logic, or performance tradeoffs. Linters don’t understand context. They treat all code the same, even if certain files are optimized for performance, edge cases, or domain-specific needs. - Hard to scale across languages
Teams working across stacks (Python, Go, JS, .NET, etc.) end up juggling multiple linters; each with its own config syntax, edge cases, and quirks. - Hidden maintenance costs
It takes real time to configure, tune, and maintain linters, especially when they break pipelines, block commits, or conflict with formatting tools. And no one wants to be stuck as “the Linter guy.”
What This Reveals: Linters Aren’t Enough Anymore
The root problem isn’t that linters exist; it’s that they’re stuck in a simpler time from the past and have failed to evolve.
- They operate on syntax, not semantics or intent.
- They can’t see the architecture behind the function, or the tradeoffs that led to that weird-but-necessary bit of code.
- They don’t tell you why a change is good or bad - they just say it violates rule 4.2.1b.
- And in fast-moving teams with growing codebases and evolving practices, they struggle to scale.
Linters were built to enforce, but what teams need now is something that helps them reason, adapt, and move faster without losing quality.
Where We Go from Here: AI Needs to Be Smarter than Linters
An AI code review agent isn’t helpful if it just becomes a supercharged linter with an even bigger ego. It has to understand, not just enforce.
Here’s what modern tools should do:
- Deliver context-aware suggestions, not shallow flags
Linters flag patterns. AI should understand intent. Instead of saying “extract this method,” it should explain why. e.g., improved readability, performance isolation, or preventing edge-case bugs. - Guide without blocking
Linters interrupt with hard stops for trivial issues. AI should surface suggestions, explain their impact, and let the developer decide, empowering judgment instead of enforcing rules.
- Act like a collaborator, not a cop
Where linters feel punitive, AI should feel like a senior teammate, one who offers perspective, not pressure. It should help improve code, not merely enforce conformity.
- Learn and evolve with your team
Linters apply the same rules to every repo. AI should observe how your team works, adapts to its style and architecture, and grows with it, without forcing one-size-fits-all rules.
.png)
Linters Had Their Moment: Now It's Time to Build Better Tools
Linters helped standardize style and catch the basics. But today’s codebases and teams are more complex, more collaborative, and more context-driven.
As engineering leaders, we must ask: Are our tools helping devs ship better code or just getting in the way?
At Hivel, we’re building a code review agent designed for how modern teams actually work. It doesn’t just lint, it reviews. Real code, in a real context, whether it’s written by a human or an AI pair programmer.
- Works across any tech stack
- Reviews real-world code, not just line-by-line rules
- Understands your architectural and product tradeoffs by connecting to your tech stack, be it Git, Jira, or anything else
- Learns your team’s style, evolves with you, and enforces your global guidelines without being annoying
- Helps you ship faster, not just code faster
Because great code review isn’t about catching missing commas. It’s about helping your team move fast, stay aligned, and make better decisions.
Want to see what that looks like? Book a demo or reach out. We’d love to show you how we’re making code review work for modern teams, not against them.
Also, read: What's Inside the Brain of Junior Dev Who Codes With AI vs Senior Dev Who Reviews It With AI
.png)
