Why I Switched from VS Code to Zed: A Case Study

### Introduction For most developers, Visual Studio Code (VS Code) has served as the default go‑to editor for just about every language, from Python and Go to C and web development. Its robust extension ecosystem and minimal configuration requirements made it an ideal everyday tool for me. However, recent shifts in how VS Code handles artificial‑intelligence (AI) features have made the environment feel cluttered, unstable, and increasingly difficult to tailor to a lean workflow. ### The VS Code Dilemma The core attraction of VS Code was its stability and predictability. That perception eroded as the IDE began shipping AI‑centric features with each release. Features such as GitHub Copilot prompts, inline terminal suggestions, and other intelligent assistance popped up by default. I preferred to use a dedicated CLI‑based AI tool (currently Codex) and did not rely on Copilot. Even after disabling the extension, the editor would still display prompts like “cmd+I to continue with Copilot” on every line I edited, and terminal suggestions interfered with my shell completions. To keep the environment working, my `settings.json` ballooned into a collection of opt‑outs. Worse, each update that added more AI hooks led to a noticeable slowdown, increased memory usage, and more frequent crashes – a predictable cost of pushing new Copilot features into every install. ### Why Not JetBrains, Vim, or Emacs? Considering alternatives, I quickly ruled out JetBrains IDEs. While powerful, they feel heavy and do not match the lightweight character I value. On the other spectrum, Vim, Emacs, and their modern derivatives offer unparalleled configurability, but require deep learning and setup that I hoped to avoid. Enter Zed. ### First Impressions of Zed Zed, a modern, Rust‑written editor, immediately appeared familiar. Its UI and most keybindings mirror VS Code, easing the transition. Zed’s design, however, diverges on some fundamental UX points. For example, VS Code displays open files in the left sidebar – a feature I leveraged for navigation. In Zed, the recommended pattern is to use file search (`Cmd+P`) to access files, and there is no dedicated “open editors” pane. I also discovered that Zed automatically imports VS Code settings, but I opted to start from a clean slate. The only configuration I changed was adjusting font sizes, selecting a theme, disabling inline Git blame, and enabling autosave on focus change. What stood out the most was performance. Zed launched in a snap, remained responsive even when editing large files, and did not exhibit the lag or crashes that had plagued VS Code during the past two weeks. All of this revived my enthusiasm for coding. ### Working with Python in Zed Zed employs a language‑server architecture to provide language‑specific intelligence. For Python, it supports several backends, including Basedpyright, the official Rust implementation of the Pyright language server. While Pyright and its sister server Pylance offer robust features, Pylance is not open‑source, which limits its use outside VS Code. #### The Type‑Checking Mode Issue When I opened a Python project, I immediately noticed a flood of type‑checker errors. Zed, by default, configures Basedpyright to run in its *recommended* mode unless overridden. My existing projects used the ` [tool.pyright] ` section in `pyproject.toml`, which sets the default mode to *recommended*. I attempted to override this in `settings.json`: ``` "lsp": { "basedpyright": { "settings": { "basedpyright.analysis": { "typeCheckingMode": "standard" } } } } ``` but the diagnostic volume remained high. The solution I found was to explicitly set the mode *inside* each `pyproject.toml`: ``` [tool.pyright] settings = { "typeCheckingMode": "standard" } ``` This forces Basedpyright to use the *standard* check, which aligns with my typical workflow. The change, though seemingly simple, required careful attention to the project’s tooling setup. #### Pull Diagnostics Delay Another subtle annoyance was that errors were only reported after I switched files. To surface diagnostics for the focused file immediately, I added the following to `settings.json`: ``` "lsp": { "basedpyright": { "initialization_options": { "disablePullDiagnostics": true } } } ``` This setting tells the server to push diagnostics to the editor as soon as any change occurs, rather than waiting for a file switch. With this tweak, the development experience matches the responsiveness of the rest of Zed. #### Virtual Environments and CI Alignment Discovering a virtual environment was effortless; Zed detected the `venv` folder automatically. Moreover, the IDE’s alignment with the CI pipeline – which uses Pyright – ensured a consistent type‑checking experience across environments. #### Emerging Alternatives Zed recently announced a new language server, **ty**, which acts as a beta replacement for Basedpyright. It integrates Ruff‑based linting and uv‑based dependency resolution, making it an attractive option for developers who want a more modern Python tooling stack integrated into the editor. ### Beyond Python and Go While the article focuses on Python migration, I also evaluated Go. Zed supports Go out of the box without additional configuration, thanks to its built‑in Gopls integration. Together with Python, these two languages cover the bulk of my daily work. ### Final Thoughts Zed has become my default IDE for Python, Go, and general-purpose editing. It delivers speed, stability, and a familiar keybinding scheme while keeping its extension ecosystem lightweight – a trade‑off I appreciate given my limited extension usage. The only drawback I currently see is the lack of a powerful side‑by‑side diff viewer akin to GitLens in VS Code. Zed’s AI features remain optional and non‑intrusive, ensuring they don’t interfere with my workflow. Their paid plan for edit predictions is a potential revenue path that seems reasonable for an open‑source project. In closing, VS Code has long been a staple for many developers, but its aggressive AI integration may soon push a growing number of users toward lighter, more configurable alternatives like Zed. For anyone facing similar frustrations, a migration worth considering. ### Minimal Example: Zed Settings Below is a minimal `settings.json` that captures the configuration I use for daily development: ```json { "autosave": "on_focus_change", "git": { "inline_blame": {"enabled": false} }, "icon_theme": { "mode": "light", "light": "Zed (Default)", "dark": "Zed (Default)" }, "base_keymap": "VSCode", "ui_font_size": 22, "buffer_font_size": 18, "theme": { "mode": "light", "light": "One Light", "dark": "One Dark" }, "lsp": { "basedpyright": { "initialization_options": {"disablePullDiagnostics": true}, "settings": { "basedpyright.analysis": { "typeCheckingMode": "standard" } } } }, "languages": {"Python": {"language_servers": ["!ty", "basedpyright", "..."]}} } ```