VS Code won the editor wars by becoming the Walmart of IDEs — everything available, nothing optimized. That worked fine until AI coding assistants started making the underlying editor speed matter again. When your workflow involves spinning up Claude Code sessions, running agents in the terminal, and context-switching fast between files and inline edits, the latency VS Code buries in its Electron shell adds up in ways you start noticing.

I switched to Zed about four months ago. Not as an experiment. It stuck.

The Architecture Problem VS Code Has Always Had

VS Code runs on Electron. That means Chromium, Node.js, and a JavaScript UI layer between you and your code. The performance is acceptable until you're doing multiple things at once — a language server running, a terminal process active, an AI suggestion loading, a second file open in a split view. At that point you're paying an overhead tax on every action.

Zed is written in Rust. It uses GPUI, a custom GPU-accelerated UI framework the Zed team built themselves. The editor renders to the GPU directly. That's not a marketing claim — you can feel it in scroll performance, file switching, and cursor response. On the same machine, the same files, the same tasks, Zed is noticeably faster.

This matters more now than it did three years ago. AI-assisted coding means the editor is doing more per session: streaming inline completions, rendering diffs, managing multi-file context. Every millisecond of unnecessary latency compounds.

Multiplayer and Collaboration That Doesn't Feel Bolted On

Zed was built with multiplayer from the ground up. Two people can edit the same file simultaneously with real-time cursor visibility, which is what you'd expect. What's less obvious is that the architecture that enables this also makes the whole editor snappier for single-user work — the concurrency model is built into the core rather than being an extension layer.

For solo work, the multiplayer infrastructure mostly stays out of the way. For pair sessions or async collaboration on a security research writeup or a shared script, it's actually useful without requiring a plugin, an account handshake, or a service tier.

LiveShare in VS Code always felt like a plugin duct-taped to something that wasn't designed for it. In Zed it's structural.

The AI Layer: Where the Switch Actually Made Sense

This is the part that moved me. Zed has native AI integration — not through an extension, but built into the editor's architecture. The AI panel, inline completions, and the assistant pane are first-class surfaces.

You can run Claude as your AI backend in Zed directly. Configure it in your settings.json:

{
  "assistant": {
    "default_model": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514"
    },
    "version": "2"
  }
}

The assistant pane in Zed operates as a persistent context window alongside your editor. You can reference files directly in the conversation with @filename, pull in diagnostics, include the current selection, or reference your entire project tree. The context insertion is manual and explicit — you decide what goes in.

That explicitness is actually a feature. With Copilot-style autocomplete you're always guessing what the model has in context. In Zed's assistant pane you know exactly what you sent.

Inline completions work through the same model backend. The latency from a Claude-backed inline completion in Zed is lower than the same request through a VS Code extension because there's no extension host middleware adding overhead.

Claude Code Integration: The Part Nobody Talks About

Claude Code runs in the terminal. Zed's integrated terminal is fast, persistent across sessions, and handles split panes cleanly. That's table stakes. The part that actually changed my workflow is that Zed's file watching and editor state integrate well with Claude Code's filesystem operations.

When Claude Code writes a file, Zed picks it up instantly. No reload prompt, no stale buffer warning, no "file changed on disk" dialog to dismiss. The file just updates. When you're running a Claude Code agent loop that's touching ten files across a project, that frictionless sync is significant.

The workflow I run most:

1. Zed open on the project
2. Claude Code in the integrated terminal with claude at the project root
3. AI assistant pane open for specific questions and code review
4. Inline completions active for fill-in work

This is three AI surfaces in one editor, with no extensions involved. VS Code can approximate this with Copilot + Claude extension + a terminal session, but you're managing three different context models and three different latency profiles. In Zed it's one coherent system.

The Extension Ecosystem Gap (and Why It Matters Less Than You Think)

Zed does not have VS Code's extension library. That's a real tradeoff. Specific language tooling, niche formatters, and workflow plugins that exist as VS Code extensions may not have Zed equivalents yet.

For the security and embedded work I do, the gap is smaller than expected. Rust support in Zed is excellent — which makes sense given the editor is written in it. Python, TypeScript, Go, and C/C++ language servers work via LSP. Tree-sitter syntax highlighting covers the languages I'm actually in daily.

What I lost: a handful of specific VS Code extensions for CAN DBC file parsing, some custom snippets I'd built up over years (portable to Zed with minor restructuring), and a couple of Git blame visualization plugins. What I kept: everything that matters for the work.

If your workflow is deeply dependent on a specific VS Code extension that has no equivalent, Zed will block you. Audit your actual extension usage before switching. Most people have thirty extensions installed and use six.

Keybindings and the Muscle Memory Problem

Zed supports VS Code keymap imports. The translation is not perfect but it's close enough that the first week is not a complete retraining exercise.

// In settings.json, to use VS Code-style bindings:
{
  "base_keymap": "VSCode"
}

The gaps are in edge cases — specific multi-cursor combinations, panel focus shortcuts, some terminal keybinds. The command palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Linux) works the same way and covers most of what the keybinding gaps don't.

Give it two weeks before you decide. The first three days are annoying. By week two, the speed of the editor starts compensating for the occasional muscle memory failure.

What VS Code Still Has That Zed Doesn't

Honest accounting:

The extension ecosystem. This is the obvious one. If you need remote SSH development with full IntelliSense, VS Code's Remote Development extension suite has no peer in Zed yet. Zed has remote editing in progress but it's not at feature parity.

Jupyter notebook support. VS Code handles .ipynb files natively. Zed does not have this as of mid-2026. If your workflow lives in notebooks, this is a blocker.

Debugger GUI. VS Code's debugger UI is mature. Zed's debugging support is improving but the VS Code DAP-based debugger with its variable inspection panel is still ahead for most use cases. For embedded work with openocd and GDB, I'm still using VS Code for that specific context.

For everything else in my actual daily workflow, Zed wins on speed and the AI integration coherence makes the tradeoffs worth it.

The Configuration Surface

Zed is configured entirely in JSON. No settings UI maze, no GUI toggles to hunt through. Your settings.json and keymap.json are the full configuration surface.

{
  "theme": "One Dark",
  "buffer_font_family": "Zed Mono",
  "buffer_font_size": 14,
  "vim_mode": true,
  "format_on_save": "on",
  "tab_size": 2,
  "soft_wrap": "editor_width",
  "terminal": {
    "font_family": "Zed Mono",
    "font_size": 13
  }
}

The configuration lives in ~/.config/zed/settings.json on Linux, ~/Library/Application Support/Zed/settings.json on macOS. Dot-file it, version control it, sync it.

Making the Switch

If you're coming from VS Code with an AI-heavy workflow, the friction is lower than you expect. Export your VS Code extensions list first — identify which ones are genuinely critical versus which ones you installed once and forgot about. Map those to Zed equivalents or decide whether you can drop them.

$ code --list-extensions > vscode_extensions.txt

Run Zed alongside VS Code for two weeks rather than hard-switching. Use Zed for new work, VS Code for anything that requires an extension you haven't solved for yet. By the end of two weeks you'll know whether your workflow maps.

The performance difference is real and it compounds. Fast editor, fast AI responses, clean context management. For AI-augmented work specifically, the architecture choice starts to matter in ways it never used to.

If you want to go further with Zed's configuration and power-user workflows, I put together a playbook at numbpilled.gumroad.com/l/zed-playbook — terminal edition, covers keymaps, AI backend configuration, multi-project setups, and the shortcuts worth learning first.

For the Claude Code side of this workflow, the productivity tricks guide is at numbpilled.gumroad.com/l/claude-code-for-devs — 21 patterns that change how the agent loop actually works in practice.