DEV Community

Cover image for I Audited My VS Code Setup for 2026. Here's What I Deleted, Added, and Why.
Jubril Bilal
Jubril Bilal

Posted on

I Audited My VS Code Setup for 2026. Here's What I Deleted, Added, and Why.

#vscode #webdev #productivity #tutorial

I clocked my VS Code startup time: 4.2 seconds. That's with 34 extensions installed, 11 of which I hadn't touched in six months.

So I ran a full audit. Removed, replaced, reconfigured. Startup time after: 1.1 seconds.

Here's exactly what I changed and why.

Step 1 — The audit process

Open the command palette (Cmd/Ctrl + Shift + P) and type:

Show Running Extensions
Enter fullscreen mode Exit fullscreen mode

This shows every extension currently active, its activation time, and which ones are actually slowing your startup down. Mine flagged three extensions taking over 200ms each, none of which I used daily.

Step 2 — What I deleted

Extension Why it went Startup cost recovered
Bracket Pair Colorizer VS Code has this natively now — it was actively conflicting with the built-in feature ~180ms
Auto Rename Tag Native HTML editing improved enough that I rarely needed it ~140ms
Rainbow CSV Used once, forgot about it. You probably have three of these. —
REST Client Replaced by Thunder Client — better UX, more actively maintained —
Indent Rainbow Pretty. Useless for my actual workflow. Novelty wore off by week two. —

Step 3 — What I kept, and why

  • GitHub Copilot — GitHub's own research put task completion 55% faster with it. The data's real; it stays.
  • GitLens — the interactive rebase editor alone earns its keep, plus the Copilot integration for commit messages.
  • Error Lens — errors shown inline means less context-switching. This should honestly be a VS Code default.
  • Pretty TypeScript Errors — TypeScript's raw error messages are close to unreadable without it. Non-negotiable.
  • Todo Tree — working across more AI-generated code means more scattered TODOs to track.
  • Project Manager — six active projects. This is basically my sanity check.

Step 4 — What I added

Continue — open-source Copilot alternative
I switch between Copilot and local models depending on how sensitive the code is, and Continue makes that switch seamless.

ext install Continue.continue
Enter fullscreen mode Exit fullscreen mode

SonarQube for IDE (formerly SonarLint)
I was shipping AI-generated code with security issues I wasn't catching manually. This flagged three real issues in the first week alone. Enough said.

ext install SonarSource.sonarlint-vscode
Enter fullscreen mode Exit fullscreen mode

GitHub Pull Requests and Issues
Full PR review workflow inside the editor, comment on lines, approve, merge, without switching to the browser for every review.

ext install GitHub.vscode-pull-request-github
Enter fullscreen mode Exit fullscreen mode

Bookmarks
Working with AI across multiple files means constantly losing your place. This fixed it. Alt+Click to mark a line, Alt+J / Alt+K to jump between marks. Simple, and hard to give up once you're used to it.

Step 5 — The settings changes

These mattered just as much as the extension list:

// settings.json

// Exclude heavy folders from search
"search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/.next": true
},

// Exclude from the file watcher too
"files.watcherExclude": {
    "**/node_modules/**": true,
    "**/.git/**": true
},

// Update extensions on your own schedule, not VS Code's
"extensions.autoUpdate": false,

// Bracket pairs — use the native feature, not an extension
"editor.bracketPairColorization.enabled": true,
"editor.guides.bracketPairs": "active",

// Sticky scroll — underrated
"editor.stickyScroll.enabled": true,
"editor.stickyScroll.maxLineCount": 5
Enter fullscreen mode Exit fullscreen mode

A quick callout on Sticky Scroll

This deserves its own mention. Sticky Scroll is a native VS Code feature, no extension required, that keeps the current scope visible at the top of the editor as you scroll.

Reading a 500-line function? The function name stays pinned at the top the whole time, so you always know where you are in the call stack. It's a small feature and it's genuinely changed how I read unfamiliar code. Turn it on:

"editor.stickyScroll.enabled": true
Enter fullscreen mode Exit fullscreen mode

Before vs. after

Before After
Extensions installed 34 18
Startup time 4.2s 1.1s
Extensions used daily 6 14
Idle memory usage 890MB 560MB

The math is simple: fewer, better extensions beat more mediocre ones and the "extensions used daily" jump from 6 to 14 is the number I actually care about, not the raw count.

One more thing — Profiles

If you're not using VS Code Profiles yet, this is the single highest-leverage feature you're skipping. Different project types get different extension sets, five minutes to set up, worth it immediately.

File → Preferences → Profiles → New Profile

What's in your VS Code setup that you couldn't live without? Genuinely curious — some of my best extension finds have come straight from comment sections like this one.

Top comments (1)

Collapse
 
marcusykim profile image
Marcus Kim •

Dropping startup from 4.2s to 1.1s by paring your VS Code setup is a clean example of shipping performance as an engineering choice, not a wishlist preference. I like that you tied removals to real activation cost-Bracket Pair Colorizer around ~180ms, Auto Rename Tag ~140ms-instead of gut feelings, and then added Continue plus SonarSource.sonarlint-vscode to match your AI workflow. The "extensions used daily" shift from 6 to 14 is the other signal I'd track too: it's easy to overfit to tiny startup gains and forget daily friction. For teams, the profile-level lesson is strong-separate extension sets per project type so local.