Every "best VS Code extensions" list is the same 30 icons with a one-line blurb. This isn't that.
A few months ago my Extensions panel had crept past 40. Startup was sluggish, half of them I'd forgotten installing, and a good chunk were AI helpers all fighting to finish my sentences. So I did the thing you're supposed to do once a year: I disabled everything and turned them back on one at a time, only when I actually reached for one.
I ended up keeping 10. And when I looked at the survivors, they had one thing in common — a filter clean enough that I now install by it:
A good extension makes the decision faster to make. A bad one makes the decision for you.
Every extension below shows me something I'd otherwise have to go dig for, then gets out of the way and lets me choose what to do about it. The ones I deleted were the opposite: they decided, then told me after (if at all). Hold that line and the list writes itself.
Here's the 10.
The single highest-leverage extension in my setup. It takes the diagnostics VS Code already has and prints them inline, at the end of the line, instead of hiding them in the Problems panel or behind a hover.
That sounds cosmetic. It isn't. It collapses the loop between "I wrote something wrong" and "I know I wrote something wrong" from go-hunt-for-it to zero. You stop context-switching to a panel forty times an hour. The error is just… there, red, next to the thing.
It's the purest example of the filter: it makes the problem impossible to miss, and does nothing about it. You still decide the fix.
git blame as an ambient sense. Put your cursor on any line and GitLens tells you who last touched it, when, and in which commit — inline, without leaving the file.
The reason it earns a permanent seat: the question it answers isn't "who do I blame," it's "what was the author thinking, and is that still true?" Before you rip out a weird-looking guard clause, you can see it was added in the commit titled "fix: race when webhook acks before the row is persisted" — and now you don't rip it out. That's judgment the tool fed you, not judgment it made for you.
Non-negotiable, and not for the style nits. A good ESLint config catches a whole class of real bugs before you run anything — the floating promise you forgot to await, the exhaustive-deps you missed, the === you meant. Wire it to fix-on-save for the mechanical stuff (import order, quotes) and leave the logic rules as warnings you read and act on.
The distinction matters: auto-fix the things with one correct answer; surface the things that need a human call. Same filter again.
I stopped having opinions about formatting in 2019 and I've never been happier. Prettier on save means every diff is a content diff — never a "someone's editor re-tabbed the file" diff. Pair it with ESLint (eslint-config-prettier so they don't fight) and code review stops wasting its first ten minutes on whitespace.
This one does decide for you — and that's fine, because formatting is the rare case with no judgment in it. That's exactly why it's safe to automate. Keep that in your back pocket; it's the whole test for what you let a tool own.
If you write TypeScript, this gives back hours of your life. It takes those 40-line, deeply-nested "Type 'X' is not assignable to type 'Y'" walls and formats them into something a human can actually read — indented, syntax-highlighted, with the actual mismatch pulled out. It doesn't fix the error or guess your intent. It makes the compiler's own message legible so you can. Perfect fit.
Renders the size of every imported package right next to the import line. You import { format } from 'date-fns' and it quietly tells you that just cost you 20KB.
It won't stop you. It won't rewrite it to a lighter import. It just makes the cost visible at the moment you're making the choice — which is the only moment the information is useful. Nine times out of ten you shrug and move on; the tenth time it saves you from shipping a 300KB date formatter.
Autocomplete for filesystem paths in your imports and src attributes. Small, boring, and I'd riot if you took it away. It removes an entire category of dumb typo bugs (../../ off by one) by showing you what's actually there as you type. Pure surfacing, zero magic.
Scans your workspace for TODO, FIXME, HACK, NOTE and lists them in a tree in the sidebar, colour-coded by tag. It turns the notes-to-self you scatter while heads-down into an actual, visible worklist you can't pretend you didn't leave.
I add a // REVIEW: tag for "I wrote this fast, come back with fresh eyes." Todo Tree makes future-me's judgment call impossible to lose. That's the whole job.
Underlines typos in your code — variable names, comments, strings. Sounds trivial until the day it saves you from shipping recieveWebhook as a public function name that then lives in your API forever, or a retreive that breaks a string match three files away. It flags; you decide if it's a real word or your weird domain term (and you add it to the dictionary). Surfacing, not deciding.
Write HTTP requests in a plain .http file, hit send, see the response — without leaving the editor or opening a separate app. The .http file lives in the repo, so your API calls are version-controlled, diffable, and right next to the code that serves them.
The reason I prefer a file-based client over the big GUI apps: the request is text I can read and own, sitting in git, not state trapped inside another program's cloud. Same instinct as the rest of the list — keep the thing you need to reason about in front of you and under your control.
Here's where the filter earns its keep. Most of what I removed was AI assistance, and I want to be precise about why, because I am not anti-AI — I let a model write most of my code.
I killed the extensions that decide silently: the ones that auto-accept a completion before I've read it, the "fix all problems" button that rewrites logic I didn't inspect, the assistant that quietly refactors on save. Not because they're wrong often — because when they're wrong, they're wrong invisibly, and they were training me to approve instead of decide.
The AI tooling I kept is the tooling that behaves like Error Lens: it shows me its reasoning and waits. Suggests the diff, explains the risk, and leaves my hand on the button. That one distinction — surfaces vs. decides — sorted 40 extensions into 10 in about an hour.
It's the same rule I hold one level up, for the agents that write the actual code. I never let the tool that writes something be the tool that blesses it. There's an author, a separate skeptic whose only job is to try to break the diff, and a human on the merge button who can see the blast radius the model can't. Your extensions shelf is that same architecture in miniature: keep the tools that make you a better decider, delete the ones quietly relieving you of the decision. (That separation is the whole idea we're building xenition around — but you can apply the filter tonight without us.)
Your turn for the comments: what's the one extension you'd fight to keep — and does it surface something for you, or decide something for you? 👇
(If this thinned out someone's Extensions panel, a ❤️ and a 🔖 help it reach the next dev whose editor takes nine seconds to open.)