Why I Switched to Zed, and Why You Should Too

I did not switch editors because I wanted a new theme, a different sidebar, or another place to install the same extensions.

I switched because my editor had started competing with the work I was trying to do.

Modern development already asks a lot from a computer. I might have a browser full of tabs, local servers, databases, containers, language servers, terminals, and one or more AI coding agents running at the same time. I do not want the application I use to edit text taking a large share of the remaining memory or making every interaction feel heavier than it should.

That is why I started using Zed. It is fast, relatively light in my daily workflow, comfortable with the terminal, and designed for the way AI-assisted development now works.

I still respect VS Code and the JetBrains IDEs. They are mature tools with huge ecosystems, and there are projects where I may still need them. But Zed has become the editor I want to open first.

Performance was the first thing I noticed

Zed feels immediate.

It opens quickly. Files appear quickly. Switching between tabs, searching a project, typing, and scrolling all feel direct. That may sound like a small improvement, but an editor is an application I touch hundreds or thousands of times during a working day. Tiny delays become part of the mood of the whole workflow.

Zed did not reach that feeling by wrapping a web application in a desktop shell. Its interface is built with GPUI, Zed's own GPU-accelerated UI framework. The team wrote about designing it to render like a video game and target smooth, responsive interaction, including high-refresh-rate displays.[1]

I do not care about the architecture simply because Rust and GPU rendering sound impressive. I care because I can feel the result. The editor stays out of the way.

A code editor should not make itself the main event. It should respond so quickly that I stop thinking about it.

It leaves more room for the work

Memory use was another reason I moved.

In my workflow, Zed usually feels less demanding than the heavier editor setups I used before. That matters because the editor is only one part of my development environment. The browser, development server, build tools, Docker, WSL, databases, and AI agents all need memory too.

Saving memory in the editor and avoiding unnecessary extension processes can decide whether the whole system stays responsive. I would rather give that memory to the application I am building or the agent running my tests.

I want to be careful with this claim: Zed is not guaranteed to use less RAM in every project. Language servers, debuggers, terminals, extensions, and AI agents are part of the total footprint. Long AI threads can grow, and huge repositories can require serious indexing.

Zed uses separate language servers for features such as completion, diagnostics, navigation, and refactoring. Its settings let you choose, prioritize, or disable those servers when a project does not need them.[2] That is why I treat low RAM use as an observed benefit of my setup, not a universal benchmark that every developer will reproduce.

My reason is personal and practical: with the projects and tools I run, Zed gives me more breathing room. My computer feels like it belongs to my work again, not to the editor.

Zed understands that AI is now part of development

Many editors added AI after the fact. Zed increasingly feels as if the editor, terminal, codebase, and agent were meant to share the same workspace.

Zed's native agent can read and search a project, edit files, run terminal commands, use MCP tools, follow reusable skills and instructions, and present its changes in a review interface.[3] That is much closer to how I use AI now. I do not only ask for autocomplete. I ask an agent to investigate a bug, trace related code, make a change, run the tests, and show me exactly what it touched.

Zed also supports more than its own agent. Its documentation describes three paths: the native Zed Agent, external agents connected through the Agent Client Protocol, and terminal-based agent threads. External integrations can include tools such as Claude, Codex, OpenCode, Copilot, Cursor, and others that support Zed's agent workflow.[4]

This flexibility matters to me. I do not want my editor to force me into one model company, one subscription, or one interface. Sometimes I want an agent inside a panel. Sometimes I want the original CLI in a real terminal. Sometimes I want multiple agents working in parallel while I review the changes.

Zed gives AI a useful place in the workflow without pretending that the chat box should replace the code, terminal, diff, or developer judgment.

The terminal feels like a first-class part of the editor

I spend a lot of time in the terminal. Git, tests, package managers, build scripts, deployment commands, database tools, AI coding CLIs, and project automation already live there. I do not want to abandon that environment just because I opened an editor.

Zed's terminal can live in the bottom panel or open as a center tab beside regular files. It supports multiple terminal instances, custom shells, task integration, and AI help for explaining errors or suggesting commands.[5]

That center-terminal option sounds minor until you use it. A terminal is not always a little utility panel that deserves one quarter of the screen. Sometimes the terminal is the work. Logs, test failures, interactive tools, and coding agents need space. Zed lets me treat them that way.

The task system makes the relationship even better. I can define repeatable commands for builds, tests, linting, or scripts and run them with editor context such as the current file or selected text.[6] I still get the power of the shell without rebuilding every workflow as an editor extension.

This is what I mean when I say Zed is terminal friendly. It does not merely include a terminal. It respects terminal-driven development.

It fits my Windows and WSL workflow

A fast editor would not help me much if it fought the environment where my code lives.

Zed's Windows version supports opening a WSL distribution as a remote target. The interface runs locally while the source code, language servers, tasks, and terminal can run in the remote environment.[7][8]

That model makes sense for how I work. I can keep the responsive native interface on Windows while using Linux tools and project environments inside WSL. I do not need to pretend Windows and Linux are the same machine, and I do not need to give up the convenience of either one.

Zed also supports ordinary SSH remote development. Its documentation says the local interface remains responsive while language servers, tasks, and terminals run on the server, and the AI features continue to work in remote sessions.[8]

For anyone who develops across Windows, WSL, cloud servers, or remote Linux machines, that is a serious feature rather than a checkbox.

It is minimal without being empty

Zed looks clean, but it is not only a text box.

It supports Tree-sitter parsing and language servers for completion, diagnostics, navigation, code actions, and refactoring. Its language documentation now covers hundreds of programming languages and text formats through built-in support and extensions.[9]

It has an integrated debugger built around the Debug Adapter Protocol, with support for breakpoints, stepping, variable inspection, launch and attach workflows, and multiple languages.[10] It can run tasks and tests, use Jupyter kernels for interactive code, work with Git, and install community extensions.

Zed also has real-time multiplayer editing. Multiple developers can work in the same project and see one another's cursors and edits, with channels and voice chat available for collaboration.[11] I may not use multiplayer every hour, but it reflects something important about the product: Zed was designed around shared work, not only solitary text editing.

The interface stays restrained while the capabilities underneath it continue to grow. That balance is difficult. Many tools become cluttered as they become capable. Zed still feels like an editor.

The extension story is getting stronger

The most common reason to stay with VS Code is its extension ecosystem. That is fair. Years of community development created an answer for nearly every language, service, and unusual workflow.

Zed is younger, so I would not tell someone that every VS Code extension has an equivalent. It does not.

What it does have is a growing extension system covering languages, language servers, themes, icon themes, MCP servers, agent servers, debug adapters, and snippets. Zed's public extension directory lists more than a thousand extensions, including support for popular languages and frameworks.[12]

I have also learned that I needed fewer extensions than I thought. Some of the weight in my old setup came from solving every possible future problem in advance. Zed pushed me toward a smaller setup: install what the project needs, keep the terminal close, and let standard tools such as LSP, DAP, Tree-sitter, and MCP handle more of the integration.

That approach will not suit everyone. If your job depends on a particular VS Code-only extension, switching immediately may create more friction than it removes. Check your essentials first.

Zed is opinionated in ways I like

Zed is keyboard friendly. It gives terminals real space. It assumes language servers and command-line tools are valuable. It treats AI agents as workers that should read files, use tools, run commands, and produce reviewable changes. It uses native performance as a product feature rather than accepting sluggishness as the price of extensibility.

Those choices match the direction of my own workflow.

I no longer want an editor that tries to contain the entire software industry inside one application. I want a fast center of gravity that connects my code, terminal, tools, remote environments, and AI agents.

Zed is the closest editor I have found to that idea.

Why you should try it

You should try Zed if your current editor feels heavier than the work deserves. Try it if you regularly keep a browser, containers, local services, and AI tools open and want to recover some responsiveness. Try it if the terminal is already central to how you build software. Try it if you want AI inside the editor but do not want to be locked into one agent or model provider.

Do not switch because someone on the internet posted a startup-time chart. Open one of your real projects. Install only the language support you need. Run your normal server and tests. Open your usual terminals and AI agent. Watch the system memory, but also pay attention to the less measurable part: how often the editor makes you wait or breaks your concentration.

You may find that VS Code, Neovim, or a JetBrains IDE still fits your work better. That is fine. Editors are personal, and ecosystems matter.

But if you have accepted slow startup, crowded interfaces, extension overload, or high resource use as unavoidable parts of modern development, Zed is worth testing. It reminded me that a powerful editor can still feel light.

That is why I switched, and why Zed now opens first when I am ready to build.

References

Originally published at https://blog.jenuel.dev/blog/why-i-switched-to-zed-and-why-you-should-too