I didn’t expect to like Zed. I’d switched editors enough times to be cynical about the next fast one, and “written in Rust by some of the Atom people” reads like a pitch deck, not a reason. What kept it open was the cold-start time. On a large repo where VS Code spends a few seconds painting the window and waking extensions, Zed is editing before I’ve let go of the keys. After a week of reaching for it on instinct for quick edits, it earned a permanent spot in the dock.
This is the setup I landed on after moving over from VS Code: the install, the handful of settings that actually mattered, and where the AI features help versus where they don’t yet.
Install#
Zed runs on macOS and Linux. On macOS, Homebrew is the least-fuss path:
brew install zedThen point it at a project from the terminal the same way you would code .:
zed .That zed CLI doesn’t always register on the first launch. If the command isn’t found, open the app once and run zed: install cli from the command palette (cmd-shift-p) — it drops the shim in your PATH.
The settings that made it stick#
Zed’s config is a single JSON file at ~/.config/zed/settings.json — not ~/.zed/, which is where I first went looking and came up empty. Open it with cmd-,. Coming from VS Code, four changes did most of the work of making it feel like home.
Format-on-save and a readable font, the settings I reach for first:
{
"format_on_save": "on",
"buffer_font_size": 15,
"theme": "One Dark"
}The keymap is a separate file (~/.config/zed/keymap.json), which threw me at first — I expected keybindings inside settings.json the way VS Code nests them. The split is cleaner once you accept it. I only rebound a couple of things; Zed’s defaults are close enough to VS Code that muscle memory mostly survives.
The thing I didn’t need to configure: the integrated terminal. Older write-ups say Zed doesn’t have one and to alt-tab to your system terminal. It does now — ctrl-\`` toggles it, and it's been fine for the gitandnpm` I run without leaving the window.
Git, in the editor#
The Git panel is the feature I expected to miss from VS Code and didn’t. Inline blame, a diff view, stage-and-commit from a side panel — it’s all in-box, no extension to install or keep updated. For the day-to-day of staging a hunk and writing a commit message it does everything I used the VS Code Git UI for. For a gnarly interactive rebase I still drop to the terminal, same as I always have.
The AI panel, honestly#
Zed ships an assistant panel, and you can point it at hosted models or a local one. I run it against a local model through Ollama for the small stuff — explain this regex, draft a commit message, rubber-duck a refactor — because the latency is low and nothing leaves the machine. It’s good for the inner-loop work; you’ll still reach for a hosted frontier model when the task is hard.
What I’d temper: the inline assist is younger than Copilot and it shows. It’s useful for a targeted “rewrite this block” with the cursor parked, less so as the always-on autocomplete that finishes your line before you’ve thought it. If you live and die by tab-completion, keep Copilot in the loop for now and use Zed’s panel for the deliberate asks. That balance will shift as the feature matures, but that’s where it sits today.
Worth a look if#
VS Code feels heavier than the work calls for, or you want speed and a Git panel without curating a pile of extensions to get there. The migration cost is an afternoon: install it, point it at a real project, and judge it on how the first hour of actual editing feels rather than the feature list. Keep your settings.json and keymap.json under version control with your dotfiles so the setup follows you to the next machine.
I didn’t delete VS Code. I just stopped opening it first.
Additional resources#
- Zed — downloads and the case for a Rust-based editor
- Zed documentation — settings, keymap, and the assistant panel
- Getting started with VSCodium — the heavier VS Code-style alternative, telemetry stripped
- Dotfiles demystified — versioning your editor config across machines
