Sequoia Backs Zed
Original: Sequoia backs Zed
Key topics
Regulars are buzzing about Sequoia's backing of Zed, a coding platform that's generating excitement around its potential to revolutionize the way we code with AI. Commenters riff on Zed's DeltaDB innovation and Nathan Sobo's prediction that 90% of today's code will be generated by LLMs within months, with some sharing personal anecdotes of AI-assisted coding that suggest we're already getting close to that reality. As the discussion unfolds, concerns about code quality and the potential for "disposable" code emerge, with some commenters sounding the alarm on the dilution of coding standards. The thread feels particularly relevant right now as it taps into the ongoing debate about the role of AI in software development.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
95
0-12h
Avg / period
22.9
Based on 160 loaded comments
Key moments
- 01Story posted
Aug 20, 2025 at 8:13 AM EDT
5 months ago
Step 01 - 02First comment
Aug 20, 2025 at 9:42 AM EDT
1h after posting
Step 02 - 03Peak activity
95 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 26, 2025 at 5:46 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Seems to solve a real problem which is growing rapidly, both in the old way and in the new way ... if it can overcome _slop_ in LLM chats, and the sheer enormity of code/data ahead. Trying to picture how coherence will survive.
With claims/hype/concern floating around that >90% of code will be LLM-generated within 3-6 months, with the insinuation/tone [1] that the same amount of code will be written by humans as now ( at least at first ) but LLM code will radically grow to dilute the space ( as is happening ) ... seems like DeltaDB being done right/well is going to be do-or-die on whether coherence remains possible!
[1] https://www.businessinsider.com/anthropic-ceo-ai-90-percent-...
>I think we will be there in three to six months, where AI is writing 90% of the code.
They're going to keep saying it because it's a juicy sound bite and they're sales people. That doesn't make it any more true than "9 out of 10 dentists recommend our socks" or how we surely have all had flying cars for decades now.
Despite the article being salesmanship hype ( at WEF no less ) we are now in the time mentioned, and can feel this
The idea that the code is GOOD or even being used is not necessary to be saying that it exists, strewn everywhere
https://allthatsinteresting.com/wordpress/wp-content/uploads...
The thing wrote at least 80%, so we aren't far off in this anecdotal instance. There are citizen devs who are building fun things for themselves where the AI does 100%
It made me realize these things are more capable than I knew, though they still do dumb stuff reliably. But, it is easy to undo those changes, so the productivity boost remains
I miss some of his old posts that he took down from his website, in particular the one on learning statistics, that was a great one.
I don't want chat with coworkers in my IDE, nor do I feel the pains they describe with conversations spread between tools. It's not a top 5 problem
What I also have not used is vim emulation, though I have a vim background
As mentioned elsewhere, Zed is still very configuration-dependent to get the full power of it, and a lot of its functionality is never discovered for that reason
What pushed me to try it was Ollama integration which is not an afterthought, then I realized I loved it _way_ more than SublimeText, especially on performance, at first, then everything else once that won me over
I have ~10 running instances at any given moment, and >99% of the time never feel any lag, whatsoever
Another unexpected benefit is that terminals, code editor panels, and assistant chats, get to be sized and fit wherever you want, so it is also kind of a window manager... I often have more terminals open in Zed than in the Window Manager of the OS itself
I give lots of feedback to Copilot in the hopes it makes the agents better in the long-run. I want them to read my code and train on it, along with the interactions with copilot, which is the next frontier in (post) training
I currently have 19 instances of Sublime Text open, each to a separate folder containing a mix of C++ and Python code bases (some tiny some huge). Like ~8 of those have the clangd LSP plugin enabled. I don't think I've ever experienced lag in Sublime. KDE System Monitor is reporting 2.0 GiB of ram being using by sublime currently.
The clangd LSP plugin in Sublime isn't perfect, and it does occasionally break, and rarely spikes in CPU usage for no reason (although the editor always remains responsive). But, if I ever switch away from Sublime Text, I cannot imagine it ever being due to performance reasons.
The issue is again people, they don't wanna change their _archaic_ workflow, stuck with inefficient -copy/paste- loop to the chat (ie. Slack) and back.
The story in the article went a bit too far that I agree, but I guess that is their north-star vision. Current implementation allows you to "join" a workspace session shared by someone, edit the same or different file, follow/watch a certain person, as well as have a chat (without requiring copy-paste) about certain piece of code. (both written or via voice)
If something, large enterprises generally don't support smaller and ambiguous licenses. Therefore, if Zed will allow enterprise licensing (ie. via on-prem license server or volume ordering, SSO, whatever) that would increase their adoption quite well...
He seems to be saying he spent $350k making this. I guess it's some tooling for writing parsers.
He has this to say about Zed:
> Zed: Founded by Atom’s dev team, Zed was the rewrite that Atom always wanted to be able to do but couldn’t when Microsoft bought Github and made the executive decision to kill a product it might otherwise have had to compete with. Unfortunately Zed decided to do that rewrite in Rust. This has slowed their iteration speed, caused much of their dev effort to go to cross-platform support instead of innovation, cut them off from being able to offer their experience on the web, severely limited their hackability, and generally made theirs a niche tool for enthusiasts. What’s worse, their reliance on LSP — a product which believes that the presentation layer should be the primary abstraction layer — means their product is forever doomed to look like a VSCode knock-off. [1]
1. https://docs.bablr.org/architecture/prior-art/#ides
We're approaching the problem by drawing from browser design. We want to see an editor with a DOM API for code documents. BABLR is a parser framework meant as a direct answer to Tree-sitter.
A standardized DOM for code would provide a universal way of changing code documents using scripts and would allow many different code-oriented tools to interoperate naturally where they never could before.
It's not clear to me how you could substantially replace the capabilities/benefits of what LSP provides with BABLR either.
- Our core and grammars are relatively tiny and can easily be loaded into any web page as a syntax highlighter, except actually a bit more: more like being able to embed ASTExplorer directly into your docs page or blog post to help people understand code examples.
- We support runtime extensibility of languages, e.g. TS can extend from JS at runtime. Tree-sitter only supports static linking, so every shipped language extended from their JS grammar contains a complete copy of the JS grammar.
- Our grammars are much easier to debug. They're written as plain scripts, and they can be run and debugged in exactly the form they're written in.
- We can parse inputs with embedding gaps. An example of such an input would be the content of a template tag before interpolations have been applied. Parsing after interpolation opens the door to injection attacks, but parsing before interpolation allow safe composition of code fragments using template tags.
- We emit streaming parse results on the fly, and can parse infinitely long data streams with ease or syntax highlight. within large single-line files without freezing up
- Tree-sitter is half an IDE's state solution: "just add text buffer". Our solution is the whole thing. One stop shop. IDE in a box.
- CSTML lets us do round trip serialization of any tree and also gives our trees stable hashes. Tree-sitter could trivially represent its parse results as CSTML if it cared to, giving it competitive compatibility with BABLR. A rising tide lifts all boats.
- While they're setting out to make version control for the first time now, we're already basically as powerful as git thanks to the combination of hashed trees, immutable data, and btree amortization within nodes for maximum structural reuse of data.
- Did I mention you don't have to deal with this? https://github.com/tree-sitter/tree-sitter-typescript/blob/m...
- We can probably literally just run the Javascript source code for Tree-sitter grammars on our runtime. The only problem is the C lexers, but C lexers are one of the great annoyances of tree-sitter anyway since any context in the grammar requires you to hand-write the lexer
Having said that, I don't think an editor should be VC backed. It's the obvious pragmatic choice to get a team together to support a thing, but I'm concerned by it.
Here I am on my free-as-in-freedom operating system, making commits with my free DVCS tool in my free programmable text editor, building it with my free language toolchain, using my free terminal emulator/multiplexer with my free UNIX shell. VC backed tools like Warp and Zed that seek to innovate in this space are of zero interest to me as a developer.
Please please please, get paid rather than holding on too tightly to making things free forcing future enshittening.
You can pay for Zed today if you'd like - https://zed.dev/pricing - and also the editor itself is open-source under the GPLv3 license. So if at any point in the future Zed changes direction in a way you don't like, you are perpetually free to build the version you liked from source (or make a community fork and take it in a different direction).
I'd also much rather have a means of paying a single flat fee to indicate my support than yet another subscription which is misleading because I have zero interest in the AI components of Zed.
Since switching from Emacs last year, I have absolutely loved how this editor has evolved, and I am looking for any way to directly support the effort. I have been a Zed Pro subscriber for quite a while now, and I have started trying to contribute to the codebase, but I really wish there were monetization options beyond making a spread on Anthropic API pricing.
Zed is fast, easy to configure (so far, maybe some hard parts I haven't run into yet), works well with the languages I care about via LSPs, and the collaboration features are compelling. I want to pay to support that, I don't want to pay for an LLM feature I don't care about that ends up distracting from the progress on the things I want to see maintained or improved.
You don't have to give me any more features than what's in the free editor. I would gladly pay up to $300 just to have a "license".
So here's my ask: let me pay for it without paying for AI! None of my use cases will stress your servers; I have `"disable_ai": true` in my settings.json. Give me a $5/mo "support the devs tier" or a $10/mo tier with some random app quality-of-life features and I'm there. I specifically want to pay for good software without paying for AI to signify the value proposition that still exists there cause I don't think a VC would believe me otherwise.
If I'm wrong I'd love to know, but I think that we need to start talking about what funding really implies more honestly. It's traditionally met with unabashed enthusiasm and congratulations, which I totally understand, but it's a mutual exchange, not an award or a grant. I absolutely believe that everyone wants to make good on their promises, but promises made to users are not legally binding, and the track record for upholding those has not been great. Plus, as a user, I want to pay for software, but nothing feels worse than paying, then watching enshittification unfold anyways... When this happens, the investors should send you a nice postcard thanking you for paying back some of their money.
Can $20/mo sustain a text editor company with a massive multimillion dollar valuation? Well, we'll see. Good luck Zed Industries, we're all counting on you.
To clarify, I use AI agents, but I absolutely hate them submitting code in my editor. Chatting is fair enough and useful, but I need to turn off the auto-generating code part.
Not sure how many people would use that though
All they have to do is only permit official builds to talk to official builds (for security, of course ;-), and forking Zed becomes a lot harder.
Authoring plugins is a lot more attractive in lua, imho.
it's a software company. they sell software.
https://github.com/zed-industries/zed/discussions/36604
This is 100% pure virtue signaling. This brigading is not helping a single Palestinian. These people just want to feel and show the world that they are “the good guys”, while not actually doing anything or helping anyone. To me, that is absolutely a joke.
This is far fetched and that's why it cannot be taken seriously.
It's also faster than Zed, works on Linux/Win/MacOS, and is decently customizable.
Although at least to me, Sublime Text 4 feels like a "finished" product.
> Nor was I happy about the new 3-year-of-updates license model that ST4 adopted.
I'm curious what you don't like about this model? The most common complaint with regards to updates was the long waiting period between major versions, which we've now eliminated, and without changing the perpetual nature of our licenses.
I have had experience with quite a few projects switching to recurring billing, occasionally justifying it with "to support development of great new stuff" and then... just keeping the same rate of updates as before, resulting in a de facto steep upgrade. That said, three years of upgrades for 99$ is reasonable, even if there were only bugfixes
Thanks. I guess I'm just not really seeing how that is any different to what we did before? You'd buy a ST3 license with no knowledge of what improvements would be made to ST3.
Personally, I'm OK with using an old build so I don't mind that much about the limitation. Although if my 3 years elapses right before ST4 introduces first-class LSP support and an official Debugger, I may be very peeved. :)
That's correct, but it could be the day after you buy the license is when ST3 stops receiving any updates and we dedicate all work to ST4. With a ST4 license you're always getting 3 years of updates, ST3 it was anywhere from 3 to zero (not counting the beta period, ST3 only got 3 years of updates).
> Although if my 3 years elapses right before ST4 introduces first-class LSP support and an official Debugger, I may be very peeved. :)
I think we can all sympathize with some buyer's remorse. Unfortunately the line needs to be drawn somewhere. Maybe you can take solace in that we probably can't put multiple huge features in a single update, at least not a dev release. :)
You got everything in the current Major Release and every minor and patch update to it. If it took more than three years to release a new Major it was not a big problem, because you were still covered.
The new model might leave you without bugfixes before a new major version is out.
I lost track of what happened there (moved to Vim back then), was it VSCode that killed it?
I remember the extremes of the utter unconstrained chaos of Emacs and the rigid ultra-high-boilerplate approach of the Eclipse IDE. Emacs was fun to hack on, but impractical to use as an IDE, because if you installed enough plugins to make it useful as an IDE, it was broken half the time (my experience, many years ago.) Eclipse had a robust architecture, but writing plugins for it was a dispiriting slog, even when I got paid for it (again, my experience, many years ago.)
Unironically, maybe VS Code.
Everything simple you can do with it, either comes built-in, or within Github/Microsoft ecosystem, or has an official plugin that gets recommended and featured by the editor itself. Plugins from individual hobbyist developers I have, I can almost count in one hand. (VSCodeVim being the most important one)
Now I compare this to my Neovim setup, and that one is basically running on charity from OSS developers.
I have completely opposite experience with [modern] Emacs. Of course, it wasn't smooth from the day one, but neither was my ride with different IDEs. Somehow, I keep coming back to Emacs because no IDE ever provided all the machinery I need to be productive. For me (and I suppose for many other people), Emacs is far more sweeter spot of an IDE than any other alternative.
For what it's worth, I went from ST3 -> VSCode -> ST4, and have been happy since. I've found that I prefer my text editor with minimal extensions, and with Sublime Text's LSP Plugin, I'm pretty content. The performance and customizable UI make it more worth it to me than VSCode.
Well, OK then. Back to Emacs I went.
There needs to be a critical mass of people using it for things that aren't core to stay updated
The key plugins I use are some LSP servers, and they work wonders. The few languages I mainly use (yaml, json, TS/JS, python and Go) I get great language support for via the LSP servers and the editor is blissfully fast always.
I could live without even the LSP stuff, but the one feature I can't live without is Sublime's excellent recovery support. Every once in a while my system will crash, and even though I've had multiple unsaved buffers Sublime recovers them every single time. Saved my butt more times than I want to know!
With that being said, just a quick look at, for example Stack Overflow 2025 survey tells me it doesn't have the same mindshare it once had.
As for people in general, safe bet in almost any topic is that most people won’t care. :) So yes most people use VSCode.
I still use it, it is maintained and it is very good and fast, and that it didn't try to reinvent itself is a good thing for me. But it is not a full IDE (not Jetbrains), it didn't jump on the AI bandwagon (not Cursor), and it is not free (not VSCode), so it is not surprising that it lost some market share. But it is not dead.
In reality 70% of the people I see are using Cursor (Subscription), Vscode (Free) or some JetBrains products (Subscription). I only know of some people including myself that have ST for opening large files, where performance matters.
I'm a fan of indie software and native apps but I know zero people in the past 10 years that switched to ST. I know plenty of people of people who switched to Vscode and all the other free or paid competitors. It's probably enough to sustain a small company, and not everyone has to strive for a monopoly. But I wouldn't call that thriving.
People are 7x more likely to be using VS Code, which means that a niche tool is far more likely to have a VA Code plugin than an ST plugin.
Other than that, if the 11% of people using it are happy then there’s no issue.
They switched to a subscription model (3 year licenses are still subscriptions), and since the release of ST4 in 2021, there has been exactly one release with new features (May 2025). All other releases have been bug fixes and "improvements".
I get that developers need to make a living, but 4 years of fixing bugs in your products is probably not what I want to be paying for, at least not when that is the only thing I'm getting. Speaking of releases, they're also usually 6-12 months apart.
I have used ST ever since the first version replaced TextMate for my use (TM2 spent something like a decade catching up to ST2), but I've since switched to Code and Zed (mostly Zed as of late, Code on windows until Zed is ready there).
ST was great back when it was still an actively maintained product, but in recent years (ever since ST2) it has felt like it was mostly on the back burner and other editors have passed it in functionality.
As for VC funding, it has done miracles for Code to have Microsoft sponsor it (and others). Code is currently the editor to beat for anything that doesn't involve opening large files.
vscode seems to have totally taken over dev mindshare these days.
I'd be interested to know how much data DeltaDB accumulates over time - because the level of granularity is so high - and are they going to want to use that data as training data?
165 more comments available on Hacker News