Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code: Now in Beta in Zed

zed.dev

Post reply on HN
Print view View original

141–150 of 431 posts

Re: Claude Code: Now in Beta in Zed

#141

Post by ppeetteerr »

I love Zed and I'm glad you now have native support for Claude. I previously ran it using the instructions in this post: https://benswift.me/blog/2025/07/23/running-claude-code-with...

One thing that still suffers is AI autocomplete. While I tried Zed's own solution and supermaven (now part of Cursor), I still find Cursor's AI autocomplete and predictions much more accurate (even pulling up a file via search is more accurate in Cursor).

I am glad to hear that Zed got a round of funding. https://zed.dev/blog/sequoia-backs-zed This will go a long way to creating real competition to Cursor in the form of a quality IDE not built on VSCode

Re: Claude Code: Now in Beta in Zed

#142

Post by cedws »

srid wrote: post #117

Note: if you use SSH-based remote development, this doesn't work. https://x.com/sridca/status/1963271904384401886

That's unfortunate. I use Zed and I'm moving towards containerising my dev environment (using SSH remote dev to connect Zed to the container) because all this agentic stuff seems like a security nightmare. At the very least I want to restrict the blast radius to my repos dir.

Re: Claude Code: Now in Beta in Zed

#143

Post by manuhabitela »

IshKebab wrote: post #113
pimeys wrote: post #68

Earlier quoted context omitted.

It's really interesting point of view. I'm one of those people who avoid using VSCode at any cost. It's slow, it's bloated, the UI is not great, and it's slowly being locked down by Microsoft. If Zed would not exist, I would be using helix, neovim, or emacs as I did before.

VSCode is actually not slow. The problem is to make it useful you need to add quite a few extensions, and those can be slow. That itself wouldn't be too bad but VSCode doesn't expose any information about what is causing the slowness. You end up with "VSCode is slow and it could be due to any one of the dozen extensions I have installed", which effectively means that VSCode is slow. It remains to be seen if Zed can a…

vscode is noticeably slow compared to sublime text or zed, even without any extension. You instantly notice it when switching files or typing things that trigger auto-completions.

In the end the feeling is drastically different. It weirdly makes for a more peaceful experience to have such a snappy editor.

vscode wins thanks to all its extensions, where basically every language is supported and most features you can think of are there. But it's kinda like modern react. You know better alternatives exist, like solid or svelte, but the community is so big, it stays the easier choice in the end.

Re: Claude Code: Now in Beta in Zed

#144

Post by WD-42 »

Barrin92 wrote: post #136
WD-42 wrote: post #123

Earlier quoted context omitted.

VSCode (and all Electron based editors) have undeniable input latency. Zed is built by the same team that developed Atom and Electron and one of their stated goals is to make up for the shortcomings of these technologies. If you don't feel that VSCode is slow, it's because you are used to it.

>If you don't feel that VSCode is slow, it's because you are used to it. I don't think this is a fair claim. When you start doing an apples to apples comparison, that is to say make full use of IDE and auto-completion features it's difficult to see a difference given that the latency and speed of the plugins starts to dominate any millisecond difference in input latency or rendering speed.

No. When a press a character key on my keyboard, it should appear in my editor immediately. All other IDE features like auto-completion happen asynchronously.

Re: Claude Code: Now in Beta in Zed

#145

Post by stouset »

sapiogram wrote: post #24
sirodoht wrote: post #14

Earlier quoted context omitted.

What do you feel is missing from the UI?

Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992

While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.

Re: Claude Code: Now in Beta in Zed

#146

Post by [deleted] »

stouset wrote: post #145
sapiogram wrote: post #24

Earlier quoted context omitted.

Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992

While this is probably annoying, I have to imagine that non-hidpi displays are becoming rarer and rarer. It's probably not a great idea to spend a lot of work on a feature that will only ever see declining use.

[deleted]

Re: Claude Code: Now in Beta in Zed

#147

Post by freehorse »

sapiogram wrote: post #24
sirodoht wrote: post #14

Earlier quoted context omitted.

What do you feel is missing from the UI?

Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992

While I do not doubt that there are people who experience this on some monitor/OS combinations, I have used zed on basic 1080p and 1440p 24" monitors with no issue. Sometimes I have general issues with some monitors in macos, which is usually due to some super-resolution/sharpness setting on the monitor itself that I need to adjust, but nothing specific to zed. All I say is that these issues are far from universal with non-hidpi monitors.

Re: Claude Code: Now in Beta in Zed

#148

Post by Karrot_Kream »

partdavid wrote: post #109
Karrot_Kream wrote: post #71

Earlier quoted context omitted.

I recently un-borked my emacs config and re-downloaded elisp into my brain so I'd be happy to help walking you through the emacs stuff. I haven't used emacs on Windows natively in a long time but I did it for years and found it worked quite well so you may want to try that again. FWIW emacs these days has native LSP support (eglot) and native tree-sitter supported, but you'll need to grab tree-sitter libraries and LS…

I'm extremely interested in pushing along these fronts even in a performative way, because I don't want to get bogged down in "switch away from Emacs" conversations with coworkers. I've done a lot of modernizing on my Emacs setup this year but I would love a current take on "getting close to cursor" that gets me beyond what I'd had set up with copilot and lsp.

Having tried a bit of Cursor and some Zed I still find Claude Code a lot better than the rest (though maybe now the Claude Code Zed Beta will change things.) That means what I'm mostly doing is keeping Claude Code up in the terminal and having it do things. Claude Code has an option to view diffs in your editor which you can configure and works fine with emacs and its various diff modes (and looks great too.)

I usually always make sure everything in my branch is committed before letting Claude Code loose on my code so I can view the changes normally as a magit diff and then choose whether I want to edit any of its changes (90% of the time) or commit as is (10% of the time.) I can also restore files selectively this way and have all of my git tools available if needed.

If you want deep Claude Code integration Cursor style, then check out https://github.com/manzaltu/claude-code-ide.el . The latest releases of emacs support using `vc` blocks to specify packages so you can grab the elisp package straight from the repo and get it working within your emacs.

If you want a chat style interface, GPTel exists but requires some config (not much but not zero either) before it becomes usable as a general chat tool like Claude Desktop or ChatGPT. I'm working on an elisp package to recreate a chat interface atop GPTel and decrease the config burden.

Re: Claude Code: Now in Beta in Zed

#149

Post by jryio »

What most of these comments are missing is the attempt at standardization and unification.

There are a lot of comments that people need X feature in order to switch to Y editor. While that may be true and your particular workflow requires certain features, what is overlooked is the survival pressure for editors.

It appears that our industry is moving towards adoption, sometimes mandatory, of AI coding agents. Regardless of your feelings on the topic, having good tooling to support this effort comes down to: switching costs, compatibility with existing editors, and a strong ecosystem of third party extensions.

While Cursor/Windsurf jumped the gun on bespoke editor integrations with LLMs - the adoption of MCP and other SDKs for coding agents means it's plug and play. The full feature set will be in every editor connected to every agent.

I think Zed wins on having the lowest switching costs for most developers. Paying down generic solutions like Agent Client Protocol (AC) now is a good strategy. It took multiple parties coming together for us to get TLS, OAuth 2.0, and ECMAScript.

I don't see why most editors should behave like hand crafted musical instruments when in reality they are much more akin to high quality knives in a kitchen (sure you have your favorite knife set and bring it from job to job, but at the end of the day you can be just as productive with a different knife when necessary).

Post reply on HN