I Used AI to Debug My Mac's Performance. Here's What It Found.

My Mac has 128 GB of RAM.

It was completely maxed out. That should never happen.

So I did what any reasonable person in 2026 would do — I asked AI to figure out what was wrong. I opened Claude Code in my terminal and started debugging.

What I found surprised me. And the meta irony of using AI tools to debug AI tool overhead is not lost on me.

Activity Monitor Is the Wrong Tool

If you’re a developer and your Mac is slow, your first instinct is probably to open Activity Monitor. Mine was too. But here’s the problem: Activity Monitor is almost useless for debugging modern dev tools.

It shows you process names like “Google Chrome Helper” repeated 50 times with zero context about which tab or extension is responsible. It shows “Code Helper (Plugin)” burning CPU but doesn’t tell you which VS Code extension is the culprit. It’s a maze of cryptic process names that tells you something is wrong without telling you what.

The key insight I landed on — and the reason I’m writing this post — is that modern apps like browsers, code editors, and AI CLI tools are basically operating systems running inside your operating system. They have their own process models, their own memory management, and their own diagnostic tools. You need to debug them from the inside, not from the outside.

How I Used AI to Debug This

Before I get into what I found, it’s worth explaining the workflow because I think it’s a pattern more developers should adopt.

Claude Code was my investigator. I ran it in the terminal and asked it to help me figure out why my machine was crawling. It didn’t just give me generic advice. It gave me targeted, specific instructions I didn’t know existed — like Chrome’s built-in Task Manager (I had no idea Chrome had its own task manager), VS Code’s Process Explorer (never used it), and how to trace MCP server processes in the terminal.

That’s what makes AI-assisted debugging different from Googling. When I Google “Mac slow,” I get 10 articles about clearing caches and restarting. When I asked Claude Code, it looked at my actual processes and told me exactly where to go.

That’s the new debugging workflow — one AI tool as a hands-on systems investigator, pointing me to the right places instead of giving me generic advice.

Finding #1: Chrome — YouTube Is the Final Boss of RAM

Activity Monitor just showed “Google Chrome Helper” eating 5GB+. No context. No breakdown. Completely useless.

Claude Code told me to open Chrome’s own Task Manager: Window → Task Manager (or Shift + Esc on Windows). I’d been using Chrome for years and never knew this existed.

When I opened it, the answer was obvious. YouTube tabs were the #1 offender by a wide margin. Not a surprise in hindsight — video content is heavy — but I never had visibility into this before because Activity Monitor doesn’t give you tab-level granularity.

The fix:

1. Use Chrome’s Task Manager (not Activity Monitor) to see which tabs and extensions are eating RAM.
2. Turn on Memory Saver in Chrome Settings → Performance. It suspends inactive tabs automatically. The difference was immediate.

This alone is a tip that most developers don’t know. Browsers have become so complex that you need to use their internal diagnostic tools to understand what’s actually happening.

Finding #2: VS Code — Code Helper (Plugin) at 101% CPU

When I checked Activity Monitor, I saw three “Code Helper (Plugin)” processes each running at 101% CPU with 99+ hours of CPU time. That looks terrifying. It looks like malware.

I asked Claude Code what “Code Helper (Plugin)” actually is. Turns out it’s just VS Code’s extension host — it runs your extensions, language servers, linting, indexing, and all the background plugin work. High memory there usually means one or more extensions or language services are going rogue. Not malware. Just bloat.

The fix Claude Code gave me:

Go to Help → Open Process Explorer in VS Code. This breaks down exactly which extensions and language servers are consuming resources. Sort by memory, find the culprit, and disable or reload it.

Again — a tool built into the app that most developers never use because they default to Activity Monitor, which just shows the generic “Code Helper” label with no actionable detail.

Finding #3: Claude Code MCP Server Sprawl

This one caught me completely off guard, and it’s the most relevant finding for anyone using Claude Code with MCP (Model Context Protocol) servers.

Every Claude Code session spawns separate npx processes for each MCP server listed in your config. If you have Notion, YouTube Data, ElevenLabs, and Remotion MCP servers configured, each session spins up all of them. Leave a few terminal tabs open with claude --dangerously-skip-permissions running, and you end up with 20+ duplicate MCP server processes running silently in the background.

I found this by looking at the VS Code Process Explorer (which I only knew about because of Claude Code’s suggestion). The process tree showed it clearly — every claude session had its own full set of MCP servers underneath it, each one duplicated.

What I did about it:

I ripped out the MCP servers I rarely use — Notion, ElevenLabs, and a few others. MCP sprawl was only part of the problem. The broader issue is that MCP servers have real costs beyond just process count: token pollution (every MCP server injects tool descriptions into your context window whether you use them or not), startup latency, and the silent resource accumulation I just described. If you’re not actively using a server, it’s pure overhead.

The fix for anyone running into this:

1. Audit your MCP server configs ruthlessly. If you haven’t used a server in the last week, remove it.
2. Kill orphaned sessions. Don’t leave Claude Code terminal tabs sitting around.
3. Check regularly. These processes stack up silently over time.

This feels like something the Claude Code team should address — maybe lazy-loading MCP servers only when they’re actually invoked rather than spinning them all up at session start. But for now, being intentional about which servers you keep is the first step.

The Bigger Lesson: Debug Apps From the Inside

Here’s the takeaway I want you to walk away with:

Stop using Activity Monitor (or Windows Task Manager) as your first debugging tool for modern applications. These OS-level tools were designed for a world where each process was a distinct application. Today, Chrome is an operating system. VS Code is an operating system. Claude Code with MCP servers is an operating system. They all have their own internal process managers that give you the detail you actually need.

If you’re a developer running all three of these (and in 2026, you probably are), you’ve got three mini operating systems layered on top of macOS, each spawning dozens of processes. Activity Monitor will show you a wall of “Helper” entries. The app’s own tools will show you which YouTube tab, which VS Code extension, and which MCP server is the actual problem.

The Meta Commentary

There’s something poetic about using AI tools to debug AI tool overhead. Claude Code helped me discover that Claude Code’s own MCP server architecture was one of the things slowing my machine down. It also taught me about diagnostic tools in Chrome and VS Code that I’d been completely unaware of despite using these apps daily for years.

This is what I mean when I talk about AI making everyone an engineer. I didn’t go deep into process management or read man pages. I asked Claude Code a question, it gave me specific, actionable guidance, and I followed it. That’s the new debugging workflow — not replacing knowledge, but surfacing the right knowledge at the right time.

My 128 GB Mac is breathing again. And I have a new rule: when something is slow, don’t start with Activity Monitor. Start inside the app.

Have you found similar resource hogs in your dev setup? I’d love to hear what surprised you — find me on X.