As I’ve said in yesterday’s thread[0], contrary to many others I find the AI integration in Zed to be extremely smooth and pleasant to use, so I’m happy they’re doubling down on this.
However, personally, I prefer to have it configured to talk directly to Anthropic, to limit the number of intermediaries seeing my code, but in general I can see myself using this in the future.
More importantly, I’m happy that they might be closing in on a good revenue stream. I don’t yet see the viability of the collaboration feature as a business model, and I was worried they’re gonna have trouble finding a way to sensibly monetize Zed and quit it at some point. This looks like a very sensible way, one that doesn’t cannibalize the open-source offering, and one that I can imagine working.
>However, personally, I prefer to have it configured to talk directly to Anthropic, to limit the number of intermediaries seeing my code, but in general I can see myself using this in the future.
Same. I can kind of feel OK about my code going to Anthropic, but I can't have it going through another third party as well.
This is unfortunately IT/security's worst nightmare. Thousands of excitable developers are going to be pumping proprietary code through this without approval.
(I have been daily driving Zed for a few months now - I want to try this, I'm just sceptical for the reason above.)
Once this is done, you should be able to use Anthropic if you have an API key. (This was available before today's announcement and still works today as of Zed 0.149.3)
That was a part of the reasoning of open sourcing my AI assistant/software dev project. Companies like Google have strict procedures around access to customer data. The same can't always be said about a startup racing to not run out of cash.
I really wanted to try this out with a difficult bug, as I've had Zed installed for a while and haven't actually used it. But I have no idea if I'd get in trouble for that... even though our whole team uses VSCode which I'm sure has scanned all our codebases anyway.
Also, I know some people say “just let me pay for the editor” but I don’t think that’s actually a viable path.
The editor is open-source, and it being open-source is great. Others can contribute, it generally helps adoption, it will probably help with getting people to author plugins, and it means if they go in an undesirable way, the community will be able to fork.
So without making it non-open-source, they’d need to do open-core, which is incredibly hard to pull off, as you usually end up cannibalizing features in the open-source version (even if you have contributors willing to contribute them, you block it to not sabotage your revenue stream).
I would like us as an industry to promote paying for things we use. Crazy idea, I know.
Open source is great and fun and an incredible force multiplier for the world, but when you want to do this stuff for a living, you have to charge money for it somehow, and if you're a software business, and not just software adjacent, it means charging for software.
A lot of Zed users are developers at medium-to-large businesses, so I think full source-available with licensing is very much something they could do.
They could put the code on GitHub, allowing contributions, with a license that turns into BSD or MIT after two years, and with the caveat that you can only run the (new) code if you purchase a license key first.
In companies of reasonable size, the deterent against piracy is the existence of a license itself, the actual copy protection and its strength aren't as important. The reason those companies (mostly) don't crack software isn't that the software is hard to crack, it's that their lawyers wouldn't let them.
Sure, this would make Zed somewhat easier to crack, but I think the subset of users who wouldn't use a Zed crack if Zed was binary-only but would use one if there was source code available is very small.
Leave it open source exactly as it is now, do not put convenient downloadable binaries up on Github. Allow me to either compile it myself or pay for the binaries?
There must be some other way to monetize open source.
I just want a fast programmable text editor with a native GUI and good defaults.
But that seems really tough to find, for some reason.
Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.
In the case of Zed it was always inevitable, a text editor doesn't raise >$10M in venture capital unless there's a plan to stuff it full of premium subscription features.
Warp Terminal is a similar story, >$50M in funding for a terminal emulator of all things...
> I just want a fast programmable text editor with a native GUI and good defaults.
It's called TextAdept. Much of it is itself built on its own Lua extensibility story, which runs on a fairly compact C core. Both native GUI and terminal versions, using the same user config (keybinds etc). Linux, Mac OS, Windows builds. LSP support built in. Plenty of community-produced extensions around (but of course not as vast a range as VSCode's VSX eco-system furnishes).
It doesn't mean your code is NOT being uploaded somewhere. They could add an easy switch to use the editor 'offline', not that they have to. I'll go back to Helix.
This means 100x more effort in the long run for a cross platform editor. Maybe if developers lived for 200 years, this could be possible. Will need to solve human ageing problem before the cross platform "native GUI" problem.
Native GUIs offer far better accessibility (TUIs are not screen-reader accessible, and neither is Emacs' GUI currently), hugely improved UI flexibility and consistent developer APIs (Emacs GUI is inconsistent across platforms and tricky to work with, every Neovim plugin reinvents ways to draw modals/text input because there's no consistent API), reduced redraw quirks, better performance, better debugging (as a Neovim plugin dev I don't want to spend time debugging user reports that relate to the user's choice of terminal emulator this week and not to Neovim or my plugin code).
If a motivated solo dev thought there might be at least 10,000 people who would pay 100 USD a year for a text editor with better extensibility and performance than VS Code and better defaults/richer GUI APIs than vim/Emacs, I can see why it might be tempting for them to try.
Using the same platform-specific graphics API the OS vendor builds their GUI apps with, ideally, but I'll also settle for "not a TUI, not a web application shipped as a desktop app, even if the OS vendor currently builds their GUI apps as web applications shipped as desktop apps".
A GUI that uses native controls and platform UI conventions with the native behavior expected on the given platform, or a near-indistinguishable equivalent of that.
There's two ways to make extensions to Zed, providing context for AI. In the post they show off making a Rust -> WASM based extension and also mention a server based model. There's also a third option -- Zed is open source. You don't have to use their auth, it just makes collaboration easy.
we call the latter a "Context Server", basically any process that communicates via JSON-RPC over stdio can do it. documentation for that is here: https://zed.dev/docs/assistant/context-servers
I recently switched from neovim to zed, and I overall like Zed. I miss telescope, and think some vim navigation was better, but I suspect that it has to do with how much effort I put into configuring one over the other, so time will tell.
My biggest gripe was how bad the AI was. I really want a heavy and well-crafter AI in my editor, like Cursor, but I don't want a fork of the (hugely bloated and slow) vscode, and I trust the Zed engineering team much more to nail this.
I am very excited about this announcement. I hope they shift focus from the real-time features (make no sense to me) to AI.
Agreed about the AI, the last time I tried Zed I was also trying Cursor at the same time, and the Cursor AI integration vs what Zed offered was just night and day. So I got the Cursor subscription. But I haven't used it in 2 months (I don't get to code a lot in my job).
This was maybe 3-4 months ago, so I'm excited to try Zed again.
Have you tried using Codeium in Neovim[0]? It may not have all the features shown in this post, but still quite good. I will admit though that I'm enticed to try out AI in Zed now.
Codeium works well but I really like the copilot chat plugin as well - it generally does a good job of explaining highlighted code, fixing errors, and other code interactions.
After using Cursor for some hobby stuff, it's really good. I was surprised at how well it managed the context, and the quick suggestions as you're refactoring really add up since they're generally exactly what I was about to do.
I’ve been likewise surprised. The code part is fine; I’m impressed but not “worried it will take my job” impressed.
Where it really shines for me is repetitive crap I would usually put off. The other day I was working with an XML config and creating a class to store the config so it could be marshalled/unmarshalled.
It picked up on the sample config file in the repo and started auto-suggesting attributes from the config file, in the order they appear in the config file, even though the config was camel cased and my attributes were snake cased.
The only thing it didn’t do correctly was expand a certain acronym in variable names like I had done on other attributes. In fairness, the acronym is unclear, which is why I was expanding it, and I wouldn’t be surprised if a human did the same.
What were the Zed features that made you to switch? I feel like with todays ecosystem it's easier to complete neovim experience with plugins than wait for Zed devs to catch up.
Interesting that this seems to be the announcement of Anthropic's Copilot alternative:
> A private beta of the Claude 3.5 Sonnet's new Fast Edit Mode, optimized for text editing. This upcoming mode achieves unprecedented speed in transforming existing text, enabling near-instantaneous code refactoring and document editing at scale.
yeah that caught my eye too, looks to me like speculative editing (they mentioned that its faster to each its input) + prompt-caching it would literally build up on all the tech they have
AI assistants just slow me down. Its a very rare case i find them actually useful. I am generally concerned by the amount of devs that seem to claim that it is useful. What on earth are yall accepting.
I find the only "AI" I need is really just "Intellisense". Just auto complete repetitive lines or symbol names intelligently, and that doesn't even require an AI model.
Stackoverflow is used when im stuck and searching around for an answer. Its not attempting to do the work for me. At a code level I almost never copy paste from stackoverflow.
I also utilize claud and 4o at the same time while attempting to solve a problem but they are rarely able to help.
- Does this language have X (function, methods,...) probably because I know X from another language and X is what I need. If it does not, I will code it.
- How do I write X again? Mostly when I'm coming back to a language I haven't touch for a while. Again I know what I want to do, just forgot the minutia about how to write it.
- Why is X happening? Where X is some cryptic error from the toolchain. Especially with proprietary stuff. There's also how to do X where X is a particular combination of steps and the documentation is lacking. I heard to forums in that case to know what's happening or get sample code.
I only need the manual/references for the first two. And the last one needs only be done once. Accuracy is a key thing for these use cases and I'd prefer snippets and scaffold (deterministic) instead of LLMs for basic code generation.
I'm just as baffled by the people who use stackoverflow daily. Its increasingly rare that I use it these days, to the point where I deleted my account a few years back and haven't missed it. Don't people read docs anymore? In many ways I feel lucky that I learned at a time when I only had offline docs, which forced me to become good at understanding documentation since its all I had.
> If it did not then I dont see how looking up with AI can be worse
Looking up with AI is worse because its WRONG a lot more. Random rabbit holes, misdirection. Stuff that SOUNDS right but is not. It takes a lot of time and energy to discern the wheat from the chaff.
Sure you can find misleading or outdated blogposts or forum discussions with a google search but the information is far more grounded in correctness then anything from an LLM.
Some of Cursor's features is appeals to my lazyness, say: "convert to javascript" and hit apply... For now its still a bit slow (streaming words) but when this is immediate? Not a change against the fastest Vimmer. Select code, dictate the change, review, apply - will save my wrists.
The main issue with these set of tools is that I mostly read and understand code more than writing it myself.
Not enough attention is been given to this imbalance.
It is impressive having an AI that can write code for you, but an AI that helps me understand which code we (as a team) should write would be much more useful.
My immediate instinct was to agree with you whole-heartedly. Then I remembered that Copilot has an "Explain this" button that I never click.
Maybe this is because I'm just not used to it, maybe the workflow isn't good enough, or maybe it's because I don't trust the model enough to summarize things correctly.
I do agree that this is an area that could use improvement and I see a lot of utility there.
My issue is not explaining how the code work. My issue is understanding why the code exists at all.
The default workflow is to follow the commit history until I don't get to where and when the code in it's current shape was introduced. Then trying reading the commit message that generally link to a ticket and then acquire from tribal knowledge of the team why it was done like that. If it is still necessary, what can we do today instead, etc...
And similarly when designing new code that needs to integrate on existing piece of code... Why there are such constraints in place? Why was it done like that? Who in the team know best?
This is great feature, but targeted mostly at junior developers who don't yet understand how particular library or framework work. But when I read the code, I spend most of my effort trying to understand what did original developer meant by this, and LLMs are not yet very helpful in that regard.
There are a lot of tools that promise to help you understand existing code. However, it's a really hard problem and to me none of them is production ready.
Personally, I think the problem is that if the AI got it wrong, it would waste you a lot of time trying to figure out whether it's wrong or not. It's similar to outdated comments.
No one should be submitting code that's difficult to understand, regardless of how it was 'written'. This problem exists just the same as a developer who's going to copy large blocks of StackOverflow without much thought.
It isn't always the piece of code that is hard to read. It's about how it fits into the 200,000+ line application you're working with, what it was trying to solve, whether it solved the right problem, and whether there will be unexpected interactions.
Here's roughly what I want. I want to be able to highlight some block of code, ask the AI to modify it in some way, and then I want to see a diff view of before/after that lets me accept or reject changes.
LLMs often get code slightly wrong. That's fine! Doesn't bother me at all. What I need is an interface that allows me to iterate on code AND helps me understand the changes.
As a concrete example I recently used Claude to help me write some Python matplotlib code. It took me roughly a dozen plus iterations. I had to use a separate diff tool so that I could understand what changes were being made. Blindly copy/pasting LLM code is insufficient.
"Here's roughly what I want. I want to be able to highlight some block of code, ask the AI to modify it in some way, and then I want to see a diff view of before/after that lets me accept or reject changes."
That's exactly what this new set of Zed features lets you do.
> I want to be able to highlight some block of code, ask the AI to modify it in some way, and then I want to see a diff view of before/after that lets me accept or reject changes.
If you squint, that's the same as using an IDE with first class git support and co-editing with a (junior) pair programmer that commits each thing you ask them to do locally, or just saves the file and lets you see stageable diffs you can reject instead of push.
Try the /commit workflow using aider.chat as a REPL in your terminal, with the same git repo open in whatever IDE you like that supports real time git sync.
The REPL talks to you in diffs, and you can undo commits, and of course your IDE shows you any Aider changes the same as it would show you any other devs' changes.
That said, I use Zed and while it doesn't have all the smarts of Aider, its inline integration is fantastic.
Ah interesting. I missed that when browsing the page.
Can you make the diff side-by-side? I’ve always hated the “inline” terminal style diff view. My brain just can’t parse it. I need the side-by-side view that lets me see what the actual before/after code is.
> I want to be able to highlight some block of code, ask the AI to modify it in some way, and then I want to see a diff view of before/after that lets me accept or reject changes.
Zed does that - here's a clip of it on some Python code:
Readit News
However, personally, I prefer to have it configured to talk directly to Anthropic, to limit the number of intermediaries seeing my code, but in general I can see myself using this in the future.
More importantly, I’m happy that they might be closing in on a good revenue stream. I don’t yet see the viability of the collaboration feature as a business model, and I was worried they’re gonna have trouble finding a way to sensibly monetize Zed and quit it at some point. This looks like a very sensible way, one that doesn’t cannibalize the open-source offering, and one that I can imagine working.
Fingers crossed, and good luck to them!
[0]: https://news.ycombinator.com/item?id=41286612
Same. I can kind of feel OK about my code going to Anthropic, but I can't have it going through another third party as well.
This is unfortunately IT/security's worst nightmare. Thousands of excitable developers are going to be pumping proprietary code through this without approval.
(I have been daily driving Zed for a few months now - I want to try this, I'm just sceptical for the reason above.)
The editor is open-source, and it being open-source is great. Others can contribute, it generally helps adoption, it will probably help with getting people to author plugins, and it means if they go in an undesirable way, the community will be able to fork.
So without making it non-open-source, they’d need to do open-core, which is incredibly hard to pull off, as you usually end up cannibalizing features in the open-source version (even if you have contributors willing to contribute them, you block it to not sabotage your revenue stream).
Open source is great and fun and an incredible force multiplier for the world, but when you want to do this stuff for a living, you have to charge money for it somehow, and if you're a software business, and not just software adjacent, it means charging for software.
They could put the code on GitHub, allowing contributions, with a license that turns into BSD or MIT after two years, and with the caveat that you can only run the (new) code if you purchase a license key first.
In companies of reasonable size, the deterent against piracy is the existence of a license itself, the actual copy protection and its strength aren't as important. The reason those companies (mostly) don't crack software isn't that the software is hard to crack, it's that their lawyers wouldn't let them.
Sure, this would make Zed somewhat easier to crack, but I think the subset of users who wouldn't use a Zed crack if Zed was binary-only but would use one if there was source code available is very small.
There must be some other way to monetize open source.
But that seems really tough to find, for some reason.
Zed is so close, but I’d much rather see a focus on the “programmable” part and let the AI and collaboration features emerge later out of rich extensibility (i.e. as plugins, perhaps even paid plugins) than have them built-in behind a sign-in and unknown future pricing model.
Warp Terminal is a similar story, >$50M in funding for a terminal emulator of all things...
Also, Spacemacs? It's technically a terminal but definitely has a lot of UI features. Very programmable.
It's called TextAdept. Much of it is itself built on its own Lua extensibility story, which runs on a fairly compact C core. Both native GUI and terminal versions, using the same user config (keybinds etc). Linux, Mac OS, Windows builds. LSP support built in. Plenty of community-produced extensions around (but of course not as vast a range as VSCode's VSX eco-system furnishes).
https://orbitalquark.github.io/textadept/
"assistant": { "enabled": false, }
What would that be for each OS?
Linux: Kate (at least if using KDE; which one would it be for GTK / Gnome?)
macOS: TextMate?
Windows: Notepad++?
It is significantly less featureful than Kate or your other apps though.
I really love the Documents Tree plugin and could never go back to old style tabs.
NotepadNext – a cross-platform reimplementation of Notepad++ | Hacker News https://news.ycombinator.com/item?id=39854182
This means 100x more effort in the long run for a cross platform editor. Maybe if developers lived for 200 years, this could be possible. Will need to solve human ageing problem before the cross platform "native GUI" problem.
Extensibility of neovim or emacs covers all my text editor use cases.
Native GUIs offer far better accessibility (TUIs are not screen-reader accessible, and neither is Emacs' GUI currently), hugely improved UI flexibility and consistent developer APIs (Emacs GUI is inconsistent across platforms and tricky to work with, every Neovim plugin reinvents ways to draw modals/text input because there's no consistent API), reduced redraw quirks, better performance, better debugging (as a Neovim plugin dev I don't want to spend time debugging user reports that relate to the user's choice of terminal emulator this week and not to Neovim or my plugin code).
Deleted Comment
Deleted Comment
This is a great start but it's far from what most would accept as "programmable" or richly extensible.
My biggest gripe was how bad the AI was. I really want a heavy and well-crafter AI in my editor, like Cursor, but I don't want a fork of the (hugely bloated and slow) vscode, and I trust the Zed engineering team much more to nail this.
I am very excited about this announcement. I hope they shift focus from the real-time features (make no sense to me) to AI.
This was maybe 3-4 months ago, so I'm excited to try Zed again.
[0] https://github.com/Exafunction/codeium.nvim
Where it really shines for me is repetitive crap I would usually put off. The other day I was working with an XML config and creating a class to store the config so it could be marshalled/unmarshalled.
It picked up on the sample config file in the repo and started auto-suggesting attributes from the config file, in the order they appear in the config file, even though the config was camel cased and my attributes were snake cased.
The only thing it didn’t do correctly was expand a certain acronym in variable names like I had done on other attributes. In fairness, the acronym is unclear, which is why I was expanding it, and I wouldn’t be surprised if a human did the same.
> A private beta of the Claude 3.5 Sonnet's new Fast Edit Mode, optimized for text editing. This upcoming mode achieves unprecedented speed in transforming existing text, enabling near-instantaneous code refactoring and document editing at scale.
Stackoverflow is used when im stuck and searching around for an answer. Its not attempting to do the work for me. At a code level I almost never copy paste from stackoverflow.
I also utilize claud and 4o at the same time while attempting to solve a problem but they are rarely able to help.
- Does this language have X (function, methods,...) probably because I know X from another language and X is what I need. If it does not, I will code it.
- How do I write X again? Mostly when I'm coming back to a language I haven't touch for a while. Again I know what I want to do, just forgot the minutia about how to write it.
- Why is X happening? Where X is some cryptic error from the toolchain. Especially with proprietary stuff. There's also how to do X where X is a particular combination of steps and the documentation is lacking. I heard to forums in that case to know what's happening or get sample code.
I only need the manual/references for the first two. And the last one needs only be done once. Accuracy is a key thing for these use cases and I'd prefer snippets and scaffold (deterministic) instead of LLMs for basic code generation.
Looking up with AI is worse because its WRONG a lot more. Random rabbit holes, misdirection. Stuff that SOUNDS right but is not. It takes a lot of time and energy to discern the wheat from the chaff.
Sure you can find misleading or outdated blogposts or forum discussions with a google search but the information is far more grounded in correctness then anything from an LLM.
“Aha!” They say, “I only realized my folly after the 25th time someone pointed out googling also takes time!”
Maybe there’s some interesting difference in experiences that shouldn’t just be dismissed.
Deleted Comment
Not enough attention is been given to this imbalance.
It is impressive having an AI that can write code for you, but an AI that helps me understand which code we (as a team) should write would be much more useful.
Maybe this is because I'm just not used to it, maybe the workflow isn't good enough, or maybe it's because I don't trust the model enough to summarize things correctly.
I do agree that this is an area that could use improvement and I see a lot of utility there.
The default workflow is to follow the commit history until I don't get to where and when the code in it's current shape was introduced. Then trying reading the commit message that generally link to a ticket and then acquire from tribal knowledge of the team why it was done like that. If it is still necessary, what can we do today instead, etc...
And similarly when designing new code that needs to integrate on existing piece of code... Why there are such constraints in place? Why was it done like that? Who in the team know best?
Personally, I think the problem is that if the AI got it wrong, it would waste you a lot of time trying to figure out whether it's wrong or not. It's similar to outdated comments.
what? ok. Nice ideals.
Here's roughly what I want. I want to be able to highlight some block of code, ask the AI to modify it in some way, and then I want to see a diff view of before/after that lets me accept or reject changes.
LLMs often get code slightly wrong. That's fine! Doesn't bother me at all. What I need is an interface that allows me to iterate on code AND helps me understand the changes.
As a concrete example I recently used Claude to help me write some Python matplotlib code. It took me roughly a dozen plus iterations. I had to use a separate diff tool so that I could understand what changes were being made. Blindly copy/pasting LLM code is insufficient.
That's exactly what this new set of Zed features lets you do.
Here's an animated GIF demo: https://gist.github.com/simonw/520fcd8ad5580e538ad16ed2d8b87...
If you squint, that's the same as using an IDE with first class git support and co-editing with a (junior) pair programmer that commits each thing you ask them to do locally, or just saves the file and lets you see stageable diffs you can reject instead of push.
Try the /commit workflow using aider.chat as a REPL in your terminal, with the same git repo open in whatever IDE you like that supports real time git sync.
The REPL talks to you in diffs, and you can undo commits, and of course your IDE shows you any Aider changes the same as it would show you any other devs' changes.
That said, I use Zed and while it doesn't have all the smarts of Aider, its inline integration is fantastic.
You can even edit the prompt after the fact if the diff doesn't show what you want and regenerate without having to start all over.
Can you make the diff side-by-side? I’ve always hated the “inline” terminal style diff view. My brain just can’t parse it. I need the side-by-side view that lets me see what the actual before/after code is.
Zed does that - here's a clip of it on some Python code:
https://youtu.be/6OdI6jYpw9M?t=66
Deleted Comment
Dead Comment
> Add build time options to disable ML/AI features
https://github.com/zed-industries/zed/issues/6756
Just give me a good editor.