what if that setting were an enum every operator started with AiMode::Off so we can consciously opt-in, plus then Zed could have more AI Mode levels besides just on or off?
Maybe there could be a level for experienced programmers and another level for vibe coders, and prompts / permissions could be set accordingly?
The four AI features in Zed (that I'm aware of) are:
* autocomplete -- this can be turned on and off separately from the AI features toggle, and can be put into 'subtle' mode, where you have to hold a key to see the completions.
* inline AI editing -- only activated by hitting ctrl-enter, otherwise you'll never see it.
* agent/chat editing -- you can disable the right-side chat panel, and you'll never see/use this.
* AI generated commit messages -- there's a button you hit in the commit message panel to activate this.
I think it could be made to work better, but as it is now, it feels cumbersome to work with.
Holy shit. It really is that simple.
Thank you.
{ "double_click_in_multibuffer": "open" }I have only tried it a couple of times, but Zed's AI assistant view indeed works as promised, doing about as well as Cursor does.
Now there's just one thing that is a bit annoying... It's kind of heavy on the GPU. I mean it looks and runs great, but it really loves to suck the battery out of a device that's running on battery. But frankly, I've been ready to ditch text editors based on web browsers basically since they became "in vogue" and have just been waiting for the right thing to show up. As time goes on, I think it becomes more and more obvious that Zed is "the right thing".
I don't know if there's anything we can do to make sure Zed succeeds sustainably and doesn't eventually get enshittified, but I'm crossing my fingers that for once we can have nice things.
This is a good conversation to have. We can start by pointing this out and encouraging broader interest. Zed has been my daily driver for over a year.
I'll make a claim -- does anyone disagree (?) -- the incentives are not pointed in the right direction. Unless developers are paying directly for the functionality they want, that's misalignment. So enshittification seems probable, maybe inevitable, unless something structural changes.
OTOH, because they charge for their editor, JetBrains has incentives that are better in line with customers.
Exactly.
AI autocomplete I just don't care about. OK, but they do offer an AI subscription service. I'm using LLMs almost not at all currently, but at least right now this does seem like a viable path to getting a lot of money. I worry, though, that in the long run, the margins will just get squeezed by competition here, especially when a lot of deep-pocketed competitors can charge nearly nothing and get away with it. Zed also very nicely offers the ability to drop in an API key for their AI agent features... which is awesome and the right thing to do, but not good for profitability.
Obviously, the issue with simply charging money like Jetbrains is that Jetbrains already has built a world where they have a super complete IDE package and even then they only really charge a relatively small amount per month for the privilege. It works because for software the development costs for a given piece of software is relatively "fixed" (not entirely, but close enough) whereas the revenue you get grows as you acquire users. But now that the market is saturated, it's going to be hard for someone to jump in and try to be like Jetbrains in any way, and if you're charging money it's even harder to compete with most of the other code editors that are ~free.
Worse, it's hard to charge money and remain completely open source. Linux users will mostly not even realize you're doing it because the packages will just keep working for free since the software is open source. And Zed really does benefit from being open source, maybe more than many other open source offerings; it really seems like the community did a lot of work on making Zed work well on Linux. (By the way, if any of you who worked on the Wayland support for GPUI happens to read this, thank you very much for the excellent work.) So it's hard to say "just go closed source!"
I hope Zed Industries got a good deal on whatever funding they received and are being somewhat conservative with their funding too. Even though it's hard to compete in this market, they've built something that is very hard to build and basically not paralleled as far as I'm concerned. There's clearly something here and finding a less shitty path to monetizing it would be very, very good for us all.
(And I am willing to pay, though I know they need to find something that will make a lot of people want to pay, not just people like me.)
I did not contribute anymore after seeing the CLA
Pretty obvious what's going on here. I hate seeing it happen, though.
I already got bitten by an infected Python library (that used to be legit). I treat plugins the same since they can be used in supply chain attacks.
Are there any modal editors that are not file-based? Maybe it would be better to say this is a problem with its file-based editor emulation?
I think there's also a fork if you can't let go of the VIM bindings.
The fuck-off-if-you-don't-agree-with-me dictator of the project doesn't help either.
As in even if you love AI and use it a lot you should have the ability to turn it off.
They wanted me to architect the solution, but were okay with it filling in basic for loops.
Mind elaborating?
^ Has C# projects on github. Don't think that statement is true.
I use vim, kitty, and arch btw
Why?
I know you can share keymaps but it never works 100%
Like I must’ve been tremendously more disappointed with my current ide to even consider switching
OTOH I was never able to switch to Jetbrains IDEs for long, because everything was too different, even after installing compat keymaps.
At least it is noticeably fast.
I have my entire set of plugins and things installed here and now the productivity that I get off this setup even exceeded my long-loved Jetbrains IDEs. I hope that will be temporary though, seriously. The only thing that I strictly dislike about VSCode is the number of high quality themes available - and there are not that many.
Recently stumbled upon VSCodium which is a clean VSCode fork that can work with any VSCode plugin, but I am yet to try it out.
These days I'm stuck on QTCreator most of the time. It's OK for core editing functionality but there's a lot that I miss, and some things like the generic Language Server support just aren't fleshed out much.
I'm tempted to use another editor whenever I'm not working on UI files but it adds some friction.
Technically yes, but if you care about legally, you can't use extensions from Microsoft's marketplace, which excludes Microsoft's own closed extensions such as WSL/SSH/devcontainer remoting and Pylance. It ships with Open VSX instead.
FWIW, I've yet to find a better text editor than Sublime Text.
It will improve. I'm glad they are at least targeting it as well.
I understand that there are advantages to being a native app from their perspective, but for me, it is even better for my editor to be integrated into my terminal editor. And because they built it the opposite way though, they have to also build a terminal emulator into their editor.
There is a real cost to building zed this way. If they were an embedded terminal app, they would get full terminal support for free and would not have to implement 2d text rendering. They could even have made a bundled package with an oss terminal emulator like kitty. Then they could have focused strictly on their editing features and value adds. Every engineer hour spent fixing bugs/adding features to the rendering framework is an hour that could have been spent on value adds.
Personally, there is no way that latency itself can be that value add for me because I use neovim and don't use any language plugins so every keystroke already renders instantly. Clearly then you can do everything zed does in a terminal app within at worst tens of milliseconds of latency.
Of course their target market uses vscode and not vim and either doesn't know or care that you do not need to write your own rendering engine to make a low latency, featureful text editor. I am admittedly very much not the target consumer for zed though.
I use vim on my servers and for writing git commit messages. For everything else, I use another editor (used to be Sublime Text, then Vs code, now Zed).
At 3am i am not in the mood trying to remember where my 714 page how to save a file and exit vim manial is
For those that are interested, this will get you 90% there:
exit without saving> :q!
exit with saving> :wq
beginning of line> 0
end of line and edit (enter insert mode)> shift-a
delete line> dd
insert mode> i
stop insert mode> ESC
undo> u
show line numbers> :set number
go to line number (e.g line 5)> :5
I still use vim for quick terminal edits, git commit messages, and doing stuff over ssh. But for my day to day heavy text editing, I do not want to sit in a terminal and be limited by what a terminal can display.
I use Golang from JetBrains, and disabling all AI features is only two clicks away. No fuss no muss.
There are some annoying websites that can't manage to display simple text or even a basic image without JS (which is just bad web designers doing bad web design) and some instances where the content I need is obscured by something that doesn't behave without JS (like an expanding menu spewed out all over the place because JS isn't there to hide what hasn't been selected/hovered over) but in those cases it's usually just 2 clicks to solve the issue (either for just that visit or for every visit to that domain in the future as well) so it's not really a big deal. I'm currently using HN without JS and it's great.
Its agent AI assistant isn’t bad but sadly the restore points button in the AI panel seemed to be broken.
The fact it reminds me of sublime text is a big plus for me.
The rust evangelism is annoying. Really. No one cares what language a program is written it.
I think it is annoying if it completes it by itself, but tab completion can be helpful if you have to push the tab key (or whatever other key is mapped to autocompletion) to make the completion to work (although I don't need LLM to do tab completion).
I don't use any of the chat or agent features, but for me Cursor's tab completion is a step forward in work efficiency that Zeta and Copilot were not. Sometimes it's subtle, and sometimes it is very obvious. Cursor seems to have sources of context that the others don't, like file names from the directory tree, and maybe even the relevant .pyi type annotations and docs for python modules. It also jumps to the next relevant problem site very effectively. It feels like the Cursor devs have done a ton of practical work that will be hard to match with anything other than a full-on competitive effort.
I want to see Zed succeed. I think it's very important that VS Code and its ultra-funded derivatives not dominate the modern editor landscape too thoroughly. Tab completion used to seem like a straightforward thing, but if the state of the art requires a very elaborate, whole-workspace-as-context environment to operate in, then I wonder if it's going to become a go big or go home kind of feature.
I can't help wonder what the actual internal API for this kind of thing is going to look like in the future. It used to be something like, what's the current token behind the cursor, and look in a big prefix tree of indexed words. Then maybe it got more elaborate with things like tree-sitter, like what's the incomplete parse tree up to this point. Then when editors started using AI, I stopped having any idea of what the actual inputs are. I'd love to hear about real implementation experience at any stage of this evolution.
Smart context / big context is a really interesting question, I’m kind of surprised Google isn’t building here given how much effort they’ve put into big context (they have Jules and Gemini CLI but no tab completion UX).
On further thought I think one of the big 3 (OpenAI, Google, Anthropic) should partner (ideally not buy) with Zed to get a foothold.
It's fast in neovim.
Maybe they artificially slow down non-official clients somehow? (official neovim plugin, VS Code)
But at the same time, I’m also doing more vibe coding instead of manual coding as time goes on, so Zed might eventually win out.
I used Zed for about a year and a half exclusively, without using any AI features, and then switched to cursor to try AI features out. When Zed released its agent mode, I switched back to Zed.
I absolutely agree that Cursor’s tab completion is far superior to Zeds. The difference is night and day. Cursor’s really is that good. But the Zed agent mode works very well for me and Zed is, IMHO just so much better than an editor. I really hate having to use vscode or a vscode-based editor after using Zed so much (I used vscode exclusively before switching to Zed). And that’s enough for me to give up on the superior tab completion.
I hope Zed eventually improve theirs to a similar experience to cursor, but regardless, I love Zed.
The main feature I really care about is low latency, which is my main gripe about Copilot. There's still a ways to go to match Cursor's quality but I'm chipping away at it!
I never cared for the LLM sidebar.
But the tab completion is basically mind-reading.
I recently found Github Dark Default, which is probably the okay-est of the 10-15 I tried, but there is so much that still looks bad. The autocomplete popover looks far worse than VSCode, the file tree looks much worse, tabs look ugly, etc.
Does anyone have any suggestions here?
It's been a while since I last looked at Zed, so I just started it again, and it ... looks like your average macOS app? Which to me sounds pretty much ideal.
As a data point for the Zed folks: JetBrains' RustRover with vim key bindings is still my go-to. It just "looks and feels" right to me.
I'm sure that they'll get there in time. They're playing the slow, careful, methodical game. Writing it in Rust was the right choice and it'll pay dividends.
- Has icons. These are so useful for parsing information quickly!!
- Shows the type information in a different color than the field name. There is spacing between the type name, and the type is smaller.
The Zed autocomplete popover is a solid wall of (almost entirely) monochrome text, all the same size. It is significantly harder to parse. I use the autocomplete popover probably thousands of times a day. These subtle things make a big difference.
Is the Zed popover bland? Yes. Is the VSCode popover flashy? Not really, it's just utilitarian - clearly designed by someone who understood how important every detail is.
There's also an importer tool [1] that lets you convert any VS Code theme to a Zed theme. You might still need to compile the importer yourself, but it's all pretty straightforward.
0: https://github.com/zed-industries/zed/discussions/7337
1: https://zed.dev/blog/user-themes-now-in-preview#using-a-vs-c...
And then, due to speed, there is no going back to the lag infested chromium derivative made by Microsoft.
- Upgrade our NodeJS version because it just got deprecated
- Upgrade our linter to the newest version, add a new rule, and fix all instances of that rule in our code
- Make minor changes to our UI
- Fix small bugs that I know how to fix, and can tell it exactly what to do
The main pain point they're solving for me is that I have many small tasks I need to do. Coding them isn't the main bottleneck, but creating a new branch and then creating a new PR is the main bottleneck for me. With cursor specifically, I don't even have to check out the branch locally to verify the code.
For any significant work, I'd rather manually do it in editor.
a) all the settings are just in a file, not even a commented skeleton, and with a decent change rate, hard to invest in learning them; I’d love something like the jetbrains settings dialog
b) the stupid placement of the burn mode button; it’s so easy to accidentally turn this on and not realize (done it twice now). Would love an option to just remove said button
c) I wish there was more panel control; I’d like to place outline and project views BOTH in a panel, but you only get two full height tools in the left/right panels.
That creates a system with a potential double negative (disable is false) which is unclear.
It's cleaner to do:
{ "enable_ai": false }
I still have Sublime Text as the backup editor. It's lack of a powerful sidebar and search are the only things that stopped me from using it regularly.
I do use VSCode at times and the CoPilor powered tab completion (which mostly hallucinates and spits out nonsense) is just obnoxious. I've found JetBrains' implementation of full line completion and block completions a lot more thoughtful and reliable.
> Zed is built for engineers who care about their tools. That means giving you control over your development environment, including the choice to work without AI if that's what works best for you.
Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true?
Are there some mechanical semantics I'm missing here that make this beneficial?
Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.
Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.
In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.
Imagine for example you're in a court of law. Which one sounds more damning?
======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?
Defendent: But Enable_AI just means enabling the use of the output! ====
==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?
Defendent: Uh.... ====
> ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?
Defendent: But Disable_AI just means disabling the use of the output
Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.
Defendent: But Disable_AI just means disabling the use of the output! ====
==== Prosecutor: You still have AI tasks running in the background, but AI_Enable is FALSE?
Defendent: Uh.... ====
...it cuts both ways, sorry.
If it was just CGO=true or CGO=false I think so much confusion could have been avoided.
I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.
This is not unique to Go.
That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.
I think it's reasonable to, for example, have a field that is labeled "Do Not Track".
They had AI features that were always on.
Some people complained so they introduced a flag to, wait for it, disable the ai features.
So they didn't think too deeply about it and named the flag "disable_ai" because it mapped into how they were thinking about it.
You overstate the problem with negative booleans. It's trivial for them to add a function:
fn isAiEnabled() { return !disable_ai }
if(disable_ai) { //disable shit }
I spent 20 years without it. That's enough for one lifetime.
I completely hated it when I tried it out. It breaks my flow. Those weird pauses are so painful. Feels like someone grabbing the steering wheel while I am driving.
I heavily use the agent mode but I don't understand the appeal of the autocomplete feature but maybe I am missing something.
It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.
AI autocomplete can generate the entire `match` tree for a very complex Rust enum, and also generate all of the associated tests. It then takes me to the next places in the code where changes need to be made. It's wildly good at knowing exactly what I want to do next.
2002 macros and autocomplete were not that and cannot possibly be compared in the same light.
From a business perspective, investors want to hear that AI is indeed part of the shipped product.
It's all about optics.
"disable_user_tracking: false" vs "enable_user_tracking: true"
"disable_adverts: false" vs "enable_adverts: true"
Fewer people would actively _enable_ user tracking or adverts compared to those who would take extra steps to _disable_ them.
I haven't seen anyone else complain about this so I figure I must be missing something. Does Zed let you set up run configurations like this? If not, how do users actually run their code? Just in the terminal? It seems backwards to me to use a fancy IDE, but then run all your code in the terminal. I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
Does anyone else have this problem?
VS Code can launch a fleet of dev containers but it's just not as good of an experience to restart and debug.
Having literally spent days at a time just to get a working run configuration at various employers and clients over the past decade, I find it backwards to use anything besides the terminal and version-controlled scripts & task runners / CLIs to fire up anything. (: People rarely document their JetBrains setup fully and even if they do, JetBrains IDEs are not exactly known for their reproducible behavior or for not occasionally messing up your configuration (in case you do decide to check in your IDE config & share with your team).
Besides, you will need those terminal scripts for your CI pipeline, anyway.
That being said,
> I love IDE features like clicking on the test I'm editing to run it, and setting breakpoints in the IDE.
I agree, that is very useful. However, to me it's the cherry on top of proper self-contained run scripts for the terminal.
It looks like this should be possible with tasks https://zed.dev/docs/tasks#variables but I haven't put enough time into figuring it out yet.
Maybe my use case is too specific, but I'll spell it out just in case: I try and open a Django project in Zed. I go to a test file. There's a > arrow next to the test to run or debug, but it will only run it with PyTest (I use unittest, but PyTest is backwards compatible, so w/e). When I try to run it, it fails because some environment variables I need are not set. I don't see how to configure them so I'm dead in the water.
I'd also love to run the Django server with a debugger attached. It's not clear to me how to do that. I haven't found the rights docs. Dead in the water again.
Maybe I need to spend more time exploring and reading the docs :)
My other complaint is that pyright (used by Zed) isn’t nearly as good as pycharms type inspection.
Of course the software industry will probably make any desire I might have a moot point anyway.
The term AI is so poorly specified today, and while I don't want my editor using LLMs to predict my next keystroke I do still like the more basic auto complete features.
One thing that goes underappreciated is the input latency and how light on resources the editor is overall. Whenever I switch tabs to a web browser (or any web app), I can feel the lag in typing now, despite the fact I use an M3 Max MacBook Pro. Zed's built-in terminal used to feel high-latency too, but they recently shipped a bunch of performance improvements, and it's just amazing how clunky inputs feel in web apps feel after using Zed for a long time.
Two things I find interesting about this development.
1. This is a long-standing feature request ever since Zed added any AI capability. Adding AI-related functionality at all was a very controversial move at the time. See https://news.ycombinator.com/item?id=41302782
2. Text threads in Zed came out only 11 months ago. At the time, it felt revolutionary being able to effortlessly paste terminal output and entire folders into context. Additionally, being able to stop the LLM, correct part of its output, and have it continue code generation. Around 4 months ago, agentic coding released, and now this once-revolutionary workflow feels quite primitive. In the meantime, Zed also added screensharing, Linux support for collaboration, a Git UI, a debugger, and performance improvements to the editor.
I have it nicely integrated with Zed by defining the following task, which you can then add a keybinding for if you want:
{
"label": "gitu",
"command": "gitu",
"reveal_target": "center",
"hide": "always",
"env": {
"VISUAL": "zed",
"GIT_EDITOR": "vim"
}
}
The other two editors I use a lot are Xcode and Android Studio, and while the first is usually fine, Android Studio (IntelliJ) feels servicable but a touch sluggish in comparison. Given the popularity of JetBrains IDEs I’m a bit surprised that there’s not more demand from customers to make it more responsive.
They can definitely feel a bit sluggish navigating around once you have a giant codebase and you’re using a lot of features, but code editing has been very responsive for me.
However, at least at the time, Zed's extension/plugin ecosystem prevented me from making the jump off vscode. Just like it took me a long while to ween myself off JetBrains and their workflow/plugins, it'll take a long while to do the same here - that's if an equivalent plugin exists (yet).
It seems to me, it would be a killer feature for new IDE's to just embrace vscode's extensions and make them "just work". It would remove a lot of the barriers people have with switching IDE's.
Maybe that's an impossible ask... I have no idea, but it would be pretty sweet.
Usually when I've attempted to explain it to others, people counter with things like "but my IDE already feels smooth", etc. I thought so too, until I tried Zed.
My only "complaint" was/is(?) the plugin ecosystem. It's a fairly new editor, so things might change in time.
"Even if you're skeptical [of genAI], these tools are quickly becoming part of how software gets built."
Yeah, well, you know, that's just, like, your opinion, man.
I am thankful Zed added this feature and most of the post seems reasonable, but it's still the height of weird that they feel compelled to say this—obviously it's not how software gets built by the people who are avoiding these tools intentionally and for good reason!
It's like saying, "marijuana is rapidly becoming a part of how people get through their day, but we understand not everyone wants to spend their day high."
not only that, there's the "jesus christ fuck off" angle. Stop bullying me into using AI when it serves you, not me. Every goddamn surface wants me to click on their "write your email like a fake idiot" button because they get to report X% WAU uptick which is supposed to vaguely correlate with revenue/growth somehow according to some stupid metric. But no matter how much you can twist reality to justify it financially the fact remains that shoving features in your users' face is not the best user experience you could have made, because you could have not done it. Good designers (...picture your platonic ideal of Jobs-era Apple, not that it was actually perfect but it was better than this shit...) would never do that. If only we lived in a world where there was enough market pressure to annihilate a company for designing things badly---unfortunately no one is competing on that angle yet (big opportunity, imo). In the meantime we just have to ask, nicely and then angrily: please, god, fuck off. It should not take angrily asking, or finding leverage, in order to get you to be respectful. You should be respectful by default.
It requires lots of independent thinking (which I value) from founders to refrain from something everyone else is hitting the gas pedal on.
Just look at the amount of excitement in their industry right now. New IDEs are springing up practically by the week. Are any of these new IDEs based on Zed?
No, of course not. GPL closes the door on that, and who would want to own a fork of a tool that's so painful to develop? Developers working on VSCode can probably do an average dev-test cycle in 1-5 seconds. I've no idea how long the Zed dev-test cycle is, but I hear Rust builds are notoriously slow so I assume it's more like 1-5 minutes.
Even without hotpatching, Rust incremental compile times are on the order of 10 seconds, not multiple minutes. Clean compiles still take minutes, but that's a "once-a-week" workflow usually.
Not sure if Zed has gotten it hooked up yet, but things are changing rapidly in the Rust GUI (and games) space because of Dioxus's innovation here.
Not true, Zed goal is
> code editor [with] high-performance collaboration with humans and AI
When investors are involved this immediately changes to:
> Our goal is to build a product which will hopefully return more than our financial investment.
I get the feeling many HN contributors to this discussion forget that Zed is not a software project like Neovim, Nano or Emacs (etc.) which rely on donations and/or sponsors to either pay developers or cover required infrastructure costs.
It's a product backed by investors who - one day - will demand their pound of flesh, and "features" like AI are added to market the product to _more_ investors.
Perhaps the use of AI itself inside the product will also be tracked to steer potential opportunities for the investors themselves.
Like many fellow HN'ers, I use Zed on a daily basis, and it's no different than Google search or Facebook - "If a product from investors is free, YOU are the product"
So my question for Zed users is: does it?
The UI is a tad idiosyncratic on Linux (can't speak for Macs) but DAMN is it fast, I love the generality of tasks.json (haven't played with debug.json yet), by far the best system I've ever used, and everything just works well out the gate.
Please make this!
What? Blockchains and Web3 again? Oh no wait... AI
A few tinfoil-hat questions: I know obviously it needs to phone someone to use functionality like remote dev or certain integrations, but outside of those situations, does it otherwise perform any kind of telemetry by default? Are there situations where it could ship off tokens in files I'm editing to some remote server where one wouldn't be expecting it? Also, I know it's open source, but is it meaningfully open source in the sense that the prebuilt binaries available for download in the obvious places aren't some reskinned proprietary version like is the case with VSCode?
These are meant in good faith -- genuinely interested and curious
palata•11h ago
But the reality is like for JavaScript: it's required by default :D.
Good that Zed fixes this!