Skip to main content
← Back to blog

Vibe coding with AI: how a 48 GB MacBook brought itself to its knees (and it wasn't Claude's fault)

Four crashes in one session, 97.6% CPU on an unexpected process, and the lesson every macOS dev working on a monorepo should know.

There's an experience every developer who does vibe coding with AI will live through sooner or later: your machine — the one you bought convinced it would never fall short — freezes. The screen locks up. The fan sounds like a reactor. And you sit there wondering whether programming with AI was such a good idea.

It happened to me four times in a single session. Four. On a MacBook with 48 GB of RAM.

This is the story of how I found the real culprit — and spoiler: it wasn't Claude.

The crime scene

I was mid-session with Claude Code, Anthropic's CLI for coding with Claude. If you don't know it, it's essentially having a senior engineer inside your terminal: you describe what you want, it analyses your code, proposes changes, runs commands. That's vibe coding at its peak — you direct, AI implements.

The project is a monorepo with Next.js, several apps, shared packages. Nothing extreme, but a real codebase with real dependencies. I was on a roll: shipping features, refactoring components, running tests. Claude was responsive, the changes worked, everything flowed.

Until it stopped flowing.

First a subtle lag. Then the terminal freezing for seconds at a time. Then the full screen going black. Forced reboot. Everything reopened. Five minutes later — crash again.

My first instinct was to blame the obvious: "Claude is consuming too many resources." Made sense, right? An LLM processing code, a dev server running, the editor open… surely they were saturating memory together.

But 48 GB of RAM doesn't vanish just like that. Something didn't add up.

The investigation

After the third crash, I decided to investigate seriously before reopening the project. I opened Activity Monitor carefully, like someone opening a door to a room where they know something's waiting.

And there it was.

Not Claude. Not Node. Not Next.js. Not even VS Code.

It was corespotlightd — the macOS Spotlight indexing process — burning 97.6% of CPU.

Almost a hundred percent. A single process. Indexing.

Indexing what? The tens of thousands of files that npm install had just generated inside node_modules.

The technical explanation (or: why macOS and monorepos don't get along)

Here's what happens when you do intensive vibe coding in a monorepo:

  1. Claude Code runs commands as part of the natural flow: npm install, npm run build, npm test. Sometimes it regenerates package-lock.json or installs a new dependency.
  2. npm install in a monorepo creates thousands of files. A typical node_modules easily has 50,000 to 100,000 files. In a workspace-based monorepo, multiply that.
  3. macOS Spotlight detects the new files and fires corespotlightd to index them. Spotlight doesn't know those files are code dependencies no one will ever search with Cmd+Space. They're new files to index.
  4. Meanwhile, Next.js in dev mode is compiling, hot-reloading, generating files in .next/. More files for Spotlight to index.
  5. Result: Spotlight enters a massive indexing loop competing with the dev server and Node for CPU and disk I/O. On an SSD, random reads across thousands of tiny files is what hurts most.

The combination is lethal: Spotlight indexing furiously + Next.js compiling + Node running tests + Claude Code processing. Not that each one alone is heavy — it's the perfect storm.

The irony: Claude was the one who helped me find it. I described the symptoms, asked for help, and together we narrowed it down to corespotlightd. The AI that was allegedly crashing my machine was the one who diagnosed the real problem.

The fix

Good news: the fix is simple and takes under two minutes.

1. Exclude the project folder from Spotlight

Go to System Settings → Siri & Spotlight → Spotlight Privacy (older macOS: System Preferences → Spotlight → Privacy). Drag your project folder — or any folder where you keep code repos — into the exclusion list.

This tells Spotlight: "never look here."

2. Create .metadata_never_index files

Belt and suspenders: drop an empty .metadata_never_index file in folders you never want indexed:

# project root
touch .metadata_never_index

# node_modules just in case
touch node_modules/.metadata_never_index

# .next for Next.js projects
touch .next/.metadata_never_index

This is a low-level signal macOS respects to skip indexing the folder and its children.

3. Automate it (optional but recommended)

Add a postinstall script to your package.json so it's regenerated on every npm install:

{
  "scripts": {
    "postinstall": "touch node_modules/.metadata_never_index"
  }
}

4. Verify it worked

Open Activity Monitor and look for corespotlightd. It should be idle or using marginal CPU. If it's still active, give it a few minutes — Spotlight takes a bit to let go of folders already in its queue.

Lessons for developers doing vibe coding

After this adventure, a few takeaways:

Your machine isn't the bottleneck — your configuration is. 48 GB of RAM is plenty for vibe coding with AI. But macOS ships configured for users who keep photos and documents, not developers generating 100,000 temporary files an hour.

The problem isn't AI, it's the ecosystem. Claude Code is surprisingly lightweight. The real drain comes from Node, the dev server, the bundler — and in this case, an OS process nobody watches.

Investigate before you blame. My first instinct was "AI consumes too many resources." Easy explanation, wrong. Activity Monitor is your friend — use it.

Poetic irony: the AI you thought was breaking your machine is the one helping you find what's actually breaking it. If that isn't vibe coding, I don't know what is.


If you're doing AI-assisted development on macOS, take it from me: exclude your code folders from Spotlight before your next session. Your fan will thank you.

Comments

Loading comments…