DEV Community: Utkarsh Bansal

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal — Wed, 10 Jun 2026 15:54:26 +0000

Utkarsh Bansal

Jun 10

You Don't Need Another Agent. You Need a Linter.

#javascript #ai #webdev #programming

9 min read

You Don't Need Another Agent. You Need a Linter.

Utkarsh Bansal — Wed, 10 Jun 2026 15:49:20 +0000

In my last post I complained — a lot — about product managers and how they made my life hell with vibe code. PS: apologies, manager, if you're reading this — but it's true.

Now, I'm not here just to complain. There were a lot of learning opportunities too, like how to handle legacy / vibe code. Because at the end of the day, both are the same: no one knows how they work, but somehow they keep working. Touching them is like defusing a bomb — you never know how your change might cascade and break the core logic.

The good news is that vibe code is much simpler than legacy. AI, in all its glory, tries to write perfect-looking code — proper function names, comments, the works — not like legacy code where a single function runs 500 lines, with spaghetti names all over that make no sense and comments that are out of date.

And that makes it something I can actually handle. I still don't have a perfect, step-by-step playbook — but I've got pieces.

The first one. The cheapest and the oldest one. The one the industry solved decades ago and the whole "AI built my app in a day" crowd somehow forgot exists.

A linter.

Yes, you heard me right. A linter. ESLint.

Most people who've been in this industry already know it. It's the most boring, reliable tool in the box.

But in an era where the answer to every problem is "add another AI," it's worth saying out loud why the boring tool still wins.

What a linter actually is

If you vibe-coded your way into this world, or you're new to web dev in general and have never heard the word "lint", here's the honest version.

A linter is a set of rules you add to your repo. It reads your code without running it, checks it against those rules, and flags everything that's broken, sloppy, or about to bite you in production.

The detail people get wrong: it's not a grep for bad words.

A real linter parses your code into a syntax tree and actually reasons about its structure — what's imported, what's called, what's reachable, what types flow where.

That's why a rule like no-unused-vars can tell "you imported this and never used it" apart from "you used this without importing it."

It's also why eslint-plugin-unicorn can quietly rewrite array.indexOf(x) !== -1 into array.includes(x) (unicorn/prefer-includes), or flag a new Array(...) call that's going to bite you — without ever executing a single line.

Three properties matter:

It doesn't run your code. No side effects, no flaky network, no "works on my machine."
It's deterministic. Same code in, same result out, every single time. No temperature, no vibes.
It costs nothing. No tokens. No API bill. It runs in seconds on a laptop or a CI box.

In 2026, that last one is the whole argument.

Why this matters more than it used to

We have AI to write code. AI to review code. AI to verify code. Agents stacked on agents, each one quietly spending tokens to do something a free tool already did better.

And honestly? Most of those agents are re-solving problems that were solved long before "agent" meant what it means today.

You do not need a language model to notice that you left a debug log in production (no-console). Or imported a module you never used (unused-imports/no-unused-imports). Or wrote a function nobody calls (knip). Or forgot to await a promise (@typescript-eslint/no-floating-promises). Or made two files import each other in a circle (import/no-cycle).

A linter catches every one of those instantly, deterministically, for free — before any AI even wakes up.

So before you bolt another agent onto your pipeline, ask the boring question:

Does the free, battle-tested tool already do this?

Usually it does.

Use what already exists.

A linter is a Quality Gate

This is the real reason linters matter. Whether you're a big company or a freelancer just starting out.

A linter is a quality gate. A line in the sand that says:

This code does not get in unless it clears the bar.

Where I work, we wired this straight into the pull-request flow. A check a PR has to pass before it can merge.

Not a suggestion. Not "we'll clean it up later." A hard gate on the merge button.

The result was the kind of number that sounds made up until you live it: production issues and bad merges dropped by roughly 80%.

Magic? No.

Most of our incidents were the same boring handful — an unhandled promise that swallowed an error, a stray debug log left in, a circular import that only broke in prod. The gate caught every one of them at the door — we just stopped letting broken code through.

That's the whole trick.

A gate doesn't make anyone smarter. It just raises the floor.

A tip if you're at a big company: when you introduce the ESLint check, you'll hear a lot of pushback from devs — especially at a startup or midsize company. So be ready for a fight, and roll it out gradually: a warning gate first, then an error gate.

It doesn't stop at "missing semicolon"

Here's the common misconception people hit when they first add ESLint and see all those errors: "this thing is bad, it just nags me like my annoying brother." That's a huge underestimation.

Once you treat the linter as a real gate instead of a nag, you can teach it your specific mistakes. And it never forgets them.

Every painful bug in an AI-assisted codebase is also a pattern. And patterns are exactly what static analysis is good at.

A surprising amount of this is one config file away. Modern ESLint flat config plus a few community plugins covers most of it:

// eslint.config.js — a starter "quality gate", not a missing-semicolon nag
import unusedImports from "eslint-plugin-unused-imports";
import importPlugin from "eslint-plugin-import";
import unicorn from "eslint-plugin-unicorn";

export default [
  {
    plugins: { "unused-imports": unusedImports, import: importPlugin, unicorn },
    languageOptions: {
      // type-aware rules need the TS program, not just the syntax tree
      parserOptions: { projectService: true },
    },
    rules: {
      // ~100 perf + hidden-bug rules in one line; downgrade the churny ones
      ...unicorn.configs["flat/recommended"].rules,
      "unicorn/filename-case": "off",       // Vue files are PascalCase by convention
      "unicorn/prevent-abbreviations": "off", // trips on `ref`, `props`, store names
      // dead code the model left behind — auto-fixable
      "unused-imports/no-unused-imports": "error",
      "unused-imports/no-unused-vars": "warn",
      // the silent killer (see the circular-deps post) — crank maxDepth up
      "import/no-cycle": ["error", { maxDepth: 10, ignoreExternal: true }],
      // dropped awaits that swallow errors — needs the type info above
      "@typescript-eslint/no-floating-promises": "error",
      "@typescript-eslint/no-misused-promises": "error",
      // dynamic code execution: off by default in eslint:recommended, turn them on
      "no-eval": "error",
      "no-implied-eval": "error",
      "no-new-func": "error",
      "no-script-url": "error",
    },
  },
];

That's the floor.

On top of it, every time something hurt us, we added a rule so it could only hurt us once. Three of them earned their place the hard way:

Circular dependencies — import/no-cycle with maxDepth: 10 (the default of 1 only sees direct A↔B cycles), backed by dependency-cruiser for the whole-graph view. AI refactors love making two modules import each other until the build breaks only in prod. It's the single most common AI-induced bug I've seen — enough that it deserves a post of its own.
Dropped awaits — @typescript-eslint/no-floating-promises and no-misused-promises. A missing await on a file or network call silently swallows the error, and you find out when a user does. Needs type-aware linting (parserOptions.projectService) — the one setup cost worth paying.
The free-wins pack — eslint-plugin-unicorn's flat/recommended: ~100 rules for one import. A mix of performance wins (prefer-includes, prefer-set-has), real hidden-bug catches (no-array-push-push, no-thenable), and some opinionated style. Turn off the churn (unicorn/filename-case, unicorn/prevent-abbreviations, unicorn/no-null) and keep the rest. Best caught-mistakes-to-config ratio you'll find.

The rest are quieter, but each one caught something once. Skim them:

Dead code — eslint-plugin-unused-imports sweeps the imports the model added for an approach it then abandoned (auto-fixed on --fix).
No eval — no-eval, no-implied-eval, no-new-func, no-script-url. Off by default; zero legit uses, infinite ways for generated code to sneak one in.
XSS sinks — vue/no-v-html / react/no-danger, plus eslint-plugin-no-unsanitized for raw innerHTML. Any HTML injection has to pass through a sanitizer, enforced at lint time.
Hardcoded strings — eslint-plugin-i18next, so the day you add a language nothing's baked into the markup.
Test hygiene — no-focused-tests as an error, so a stray it.only can't silently shrink the CI suite.
Leaked secrets — eslint-plugin-no-secrets flags high-entropy literals that look like committed tokens.
Design drift (custom) — a ~40-line AST script that fails the build when a raw hex/size/shadow shows up where a named token should be.
Layer boundaries — eslint-plugin-boundaries to stop one layer importing another, plus a custom rule forcing risky mutations through a single function.

Each of these is a lesson we only had to learn once.

After that, the linter remembers it for us. Forever, for free, on every commit, for every contributor — human or AI.

The trick that keeps the gate from being annoying

Most people give up on linting for one reason. They turn on every rule at error on day one, drown in ten thousand warnings, and rage-quit.

Don't do that.

Run new rules warn-first. Let them report without blocking. Get the count to zero on your own schedule. Then ratchet that rule up to error so it can never regress.

Here's the reframe that matters: those warnings aren't a to-do list you owe the linter today. They're a map of where the mines are buried. You freeze the count, stop anyone from planting new ones, and clear the field at your own pace.

For the handful of legacy offenders you can't fix today, keep an explicit allowlist. And treat adding to that allowlist as the thing you're not allowed to do.

The list only ever shrinks.

That's how a gate stays strict without crying wolf — and how you tame inherited code without it blowing up in your face.

Gotchas

A linter only sees what's static. Dynamic imports, string-built code, and values resolved at runtime are invisible to it. Know the blind spots. A green lint is not "provably correct."
--fix is not free thinking. Auto-fix is great for unused imports and formatting. It is not great at deciding whether a flagged thing was a real mistake. Read the diff.
Gate on the trend, not the absolute count. Failing CI because the repo has any warnings is untenable in a vibe-coded codebase. Fail when the count grows past the baseline. That's actionable. "Be perfect" isn't.
A rule you suppress everywhere is a rule you deleted. If every other line has a disable comment, you didn't pass the gate — you removed it. Fix the code or kill the rule honestly.

The mild jab

Here's the irony I can already see coming. You've read this whole piece on why bolting AI onto already-solved problems is wasteful — and your very next move is to open a chat window and type "add ESLint and all the plugins to my repo." Or worse: "build me a code-review agent that flags unused imports and circular deps."

Stop.

Both are the wrong move. The first one drops you into a rabbit hole of 1000+ errors you'll be digging out of forever. Start with the base recommendation, then slowly work toward the rest.

As for the code-review agent — I'll pretend I didn't hear that. We just spent this whole article on why a linter beats an AI reviewer here. So why are you still reaching for it? Look, if you hate your tokens that much — if you're really itching to spend them on a problem a free, decades-old tool already solves deterministically — just send them my way. I'll put them to better use.

AI is genuinely good at the fuzzy stuff — turning an idea into reality, that dopamine hit of making something from nothing. Let it do that. Leave the heavy judgement of code quality to linter.

And let me be honest about the other side: a linter won't fix your architecture, won't catch a wrong business rule, won't tell you the feature was a bad idea. That part is still on you. What it will do is take the boring, mechanical, never-ending category of mistakes off your plate — so your brain is free for the part that actually needs one.

Takeaway

A linter is the cheapest reviewer on your team. Free, deterministic, tireless, and completely unimpressed by hype.

Make it a hard gate on merge, and you raise the floor for everyone at once.

Then teach it your own recurring mistakes — token drift, hardcoded strings, circular deps, unsafe HTML, dropped awaits — one custom rule per bug class, warn-first then ratcheted to error.

Add the linter first.

Then, if you still want an agent, at least it's reviewing code that already cleared the bar.

The cheapest reviewer you'll ever hire has been sitting in your repo the whole time.

Frontend Is Not That Simple

Utkarsh Bansal — Thu, 21 May 2026 19:15:01 +0000

I guess most of you already have a pretty basic idea of what this post is about — Frontend Engineering.

Why frontend?
“We have AI now. It can create a website in a day. Why do you even care about frontend anymore? Post something about AI blah blah blah…”

I hear you.

But the real question is: Do you actually understand frontend?

Every day, I see product managers and designers trying their hands at AI — creating MVPs in a day and celebrating like, “We don’t need engineers anymore. We can do everything ourselves now.”

And honestly? That part is impressive.

But then that same code gets handed over to engineers for optimization, scalability, maintainability, performance, accessibility, security, deployment, and production readiness.

And that’s where my nightmare begins.

AI generates code based on patterns and existing code available online. It doesn’t magically create great architecture, scalability, performance, accessibility, or production-grade systems out of thin air.

The bigger problem starts when people continuously edit AI-generated code using more AI prompts without understanding the underlying structure.

At first, it works.

Then slowly:

functions start leaking across modules
components become tightly coupled
business logic spreads everywhere
state management becomes unpredictable
abstractions collapse
duplication increases
and eventually the entire codebase turns into spaghetti

A tangled mess held together by vibes, Stack Overflow answers, and “it works on my machine.”

Then comes the question:

“Why hasn’t the app that was created in a day scaled and deployed yet?”

So for the sake of my sanity, let me take you on a small journey into what real frontend engineering actually looks like.

And do note — this is just the tip of the iceberg. Once you go deeper, it becomes an abyss.

Frontend Engineering

As per product teams:
“Someone who creates beautiful websites using the design team’s instructions.”

As per textbooks:
“HTML, CSS, and JavaScript.”
HTML is the skeleton, CSS is the skin, and JavaScript is the brain.

As per me?
It’s much more than that.

Frontend Engineering
├── UI Development — What everyone sees
├── State Management — What no one sees until it breaks
├── Routing — Mostly ignored, but critical unless you enjoy navigation nightmares
├── Design Systems — Design tokens keep the UI consistent
├── API/Data Layer — Most production issues start here
├── Authentication — One of the biggest production concerns
├── Performance — In production, every millisecond matters
├── Accessibility — Most developers ignore this until they shouldn’t
├── SEO — Decides whether people even discover your product
├── Security — Skip this and enjoy your legal/security nightmare
├── Build Tooling — A massive game changer if you truly understand it
├── Testing — Protects both your product and your sleep
├── Monitoring — Users will always find bugs in ways you never expected
├── Analytics — So you can actually measure improvements instead of guessing
├── Deployment — Because shipping localhost to customers isn’t a strategy
├── CI/CD — Automating releases so deployments don’t become rituals
├── Internationalization — Your app eventually speaks more than one language
├── Offline/PWA — Because internet connections aren’t always reliable
├── Realtime Systems — Notifications, chats, collaboration, live updates
├── Architecture — The difference between scaling smoothly and suffering later
└── Developer Experience — Better DX = faster teams and fewer headaches

Now some people will say:
“Come on, this is an over-the-top explanation.”

And honestly?
They’re not completely wrong.

But it’s also true that all of these areas fall under frontend engineering in modern production systems.

Now the next question is:

“Do we really need all of this?”

Most of the time? Probably not.

Modern frameworks already provide many things out of the box.
For example, when you create a Vue project today, you already get tools like Vite, package managers like npm/pnpm/yarn, routing setups, build pipelines, and much more.

But if you want to build something truly great — something scalable, performant, maintainable, and production-ready — eventually you’ll have to understand these layers.

That’s where frontend engineering actually begins.

And if you’re wondering what the “abyss” looks like…

It looks something like this:

Frontend Engineering
├── Rendering Strategies (CSR, SSR, SSG, ISR, Streaming)
├── Hydration & Partial Hydration
├── Reactivity Systems & Virtual DOM internals
├── Compiler Architecture
├── Browser Rendering Pipeline
├── GPU Acceleration & Paint Optimization
├── Edge Computing
├── Caching Layers
├── WebSockets & CRDTs
├── Distributed State Synchronization
├── Micro Frontends
├── Monorepo Architecture
├── Design Token Pipelines
├── Runtime Performance Profiling
├── Web Security Hardening
├── Memory Leak Debugging
├── Service Workers
├── Rendering at Scale
├── Bundle Optimization
├── Build System Internals
├── Accessibility Compliance
├── Observability Engineering
├── Frontend Infrastructure
├── Server Components
├── WASM Integration
├── Compiler Toolchains
└── Browser Engine Edge Cases

And somewhere in between all this, you realize:

Frontend engineering was never just about making buttons look pretty.

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Utkarsh Bansal — Sun, 02 Mar 2025 14:39:22 +0000

Handling Git mistakes is a crucial skill for any developer. Recently, I found myself in a situation where a simple feature branch turned into a mess—too many commits, merge conflicts, and unclear history. Instead of starting over, I took the time to properly fix it.

Here’s what helped:
✔️ git reset — Undo unnecessary commits
✔️ git cherry-pick — Apply specific changes cleanly
✔️ git reflog — Recover lost commits
✔️ git stash — Save work without committing

Learning to manage Git efficiently makes PRs easier to review and keeps repositories clean.

If you’ve ever struggled with a tangled Git history, this article might help.

📖 Read more: https://medium.com/p/19c1f22e29ed

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Utkarsh Bansal — Sun, 02 Mar 2025 14:35:50 +0000

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

Utkarsh Bansal — Sat, 15 Feb 2025 17:23:41 +0000

Another project, another déjà vu moment.

I was about to copy-paste a helper function again when it hit me: “Didn’t I just use this in another repo?” Instead of repeating history, I finally did what I should’ve done long ago—packaged it up and published it to NPM.

Publishing an NPM package is easier than you think, and once you do it, you’ll wonder why you didn’t sooner. No more hunting through old repos, just clean, reusable code.

🛠️ Ready to publish yours? Start here: https://link.medium.com/h2mfQqqn0Qb

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Day 1/100: Exploring Frontend Storage 🖥️

Utkarsh Bansal — Sat, 15 Feb 2025 17:17:05 +0000

Modern frontend development isn't just about UI—it’s about efficient data management. From cookies to IndexedDB, each storage option plays a crucial role in performance, security, and user experience.

This is my first article where I break down key data management, performance optimization, and security best practices — while addressing key security issues and sharing industry insights…

📖 Read: https://lnkd.in/g-A6H87H

DEV Community: Utkarsh Bansal

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

You Don't Need Another Agent. You Need a Linter.

You Don't Need Another Agent. You Need a Linter.

What a linter actually is

Why this matters more than it used to

A linter is a Quality Gate

It doesn't stop at "missing semicolon"

The trick that keeps the gate from being annoying

Gotchas

The mild jab

Takeaway

Frontend Is Not That Simple

Frontend Engineering

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Day 1/100: Exploring Frontend Storage 🖥️

Harnessing Frontend Storage: A Comprehensive Guide to Browser-Based Data Management | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 14, 2025 ・
Medium

DEV Community: Utkarsh Bansal

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

You Don't Need Another Agent. You Need a Linter.

You Don't Need Another Agent. You Need a Linter.

What a linter actually is

Why this matters more than it used to

A linter is a Quality Gate

It doesn't stop at "missing semicolon"

The trick that keeps the gate from being annoying

Gotchas

The mild jab

Takeaway

Frontend Is Not That Simple

Frontend Engineering

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・ Medium

Day 1/100: Exploring Frontend Storage 🖥️

Harnessing Frontend Storage: A Comprehensive Guide to Browser-Based Data Management | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 14, 2025 ・ Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Utkarsh Bansal ・ Feb 14, 2025 ・
Medium