As long as humans still need to read code, the IDE is not dying

In 2006, freshly out of college, Nathan Sobo set himself a single goal: build the code editor he actually wanted. Nearly two decades later he is still on that quest. He was one of the first two engineers on GitHub’s Atom, helped create Electron along the way, watched Microsoft take the same idea and turn VS Code into the industry default, then started over in 2017 with Zed, a Rust IDE now used by about 170,000 active developers. Then AI arrived, and the question hanging over every editor maker became the same: if you can type English in a terminal and an agent does the work, is the IDE dying?

On Sequoia’s Training Data podcast, hosted by Sonya Huang and Pat Grady, Sobo says he has asked himself that question in different states of anxiety. He does not want to be gold-plating a buggy whip. After taking the claim seriously, he still thinks it is unrealistic. Sitting at a terminal and making real progress on a codebase with an LLM is mind-blowing, and millions of people — including him, on occasion — are doing it. The IDE dies only if humans no longer need to look at source code. He does not believe that day is close.

What bothers him about the terminal workflow is the review step. When Claude Code wants to show what it just did, you see it through a tiny excerpt — maybe ten lines. The moment you want more context, or to see what the edit connects to, you leave the terminal and open an editor. If you believe the IDE will vanish, he says, you also have to believe people will stop loading those connections into their brains. Source code is a language, just as natural language is a language. The new tools process English; they do not turn source into opaque machine code that humans can ignore.

He has carried a quote from Harold Abelson, the MIT professor and co-author of *Structure and Interpretation of Computer Programs*, for years: programs should be written for people to read, and only incidentally for machines to execute. It is an extreme stance — why write a program if you do not want a machine to run it? Sobo takes the wisdom underneath it. Programs are how we express an abstract process with extreme precision, and there is no better language for many Turing-complete ideas than source code itself. Humans stop interacting with it only at something like AGI, when they have stopped doing a lot of other things too.

Does that mean the best interface has to be a GUI? Not necessarily. Vim is not a graphical user interface, but it is an interface optimized for presenting, navigating, and sometimes hand-editing source. Sometimes the clearest way to express an idea is to write it: you can ask an LLM for a struct with four fields, but if you already know what you mean, typing the code is often faster. He has no love for repetitive grind he could hand to a model. He still wants the right to articulate the idea himself. His offhand observation is that people who vibe-code heavily in a terminal are probably running an editor alongside it to inspect what the agent did.

The obsession has a date. In 2006, TextMate was the fashionable lightweight editor — Sobo learned about it from DHH demoing Rails. He had used Emacs, Eclipse, and the JetBrains suite. Each brought extensibility, responsiveness, or feature richness; none put all three in one package. He wanted the power of the slowest, most capable IDEs with the feel of TextMate or Vim, plus extensions that did not require feeding a fragile Vim config every weekend. He wrote Atom in Vim. The first attempt at the dream was joining GitHub as one of the first two engineers on that project.

They chose the web for extreme extensibility. The shell they built around Atom became Electron: Node.js married to Chrome, a GitHub co-founder Chris Wanstrath idea, so a web page could look like a desktop app. Atom had its day. Microsoft copied the approach, moved existing web code onto Electron, and VS Code took over the industry. Sobo learned two lasting lessons. One was general: how to design a data structure that can represent and edit large quantities of text. The other was painful. Do not invite extension code onto the main thread. Atom’s openness made it popular fast, then the team drowned under promises that had been premature.

There was also a private exhaustion with the web. He would open Electron’s profiler — Chrome DevTools — stare at a flame graph, and know he could not get inside those lines. He had hit the ceiling. In 2017 he decided to start over. A web browser was not a suitable foundation for the tool he wanted. Performance, he says, is not a feature you go back and add later. Choose an architecture and you accept its performance envelope. The web was not it.

Zed was built, originally, to make it easier for humans to pair with other humans. Sobo had been at GitHub while the current collaboration style became popular: go off in a corner, take a snapshot, upload it, collect comments in a browser, reply an hour or a day later. That email-like, Git-shaped flow fits Linux-scale work spread across the world. For a team that is already on the same page, he always believed the better mode was being in the code together, able to interrupt each other and relate as people. Zed’s own team uses Git constantly and does less code review than most, preferring to talk in real time inside the code. Screen sharing fails because one person sits in the passenger seat while keystrokes round-trip.

The two problems he wanted to solve, before he knew AI was coming, were performance and collaboration. Press a key and pixels should respond on the next monitor refresh, with zero perceptible lag. Zed is not perfect, he says, but it is far closer than a browser can get. The whole application is organized around delivering data to GPU shaders that draw the UI the way a game renders a 3D world — he has rewritten the graphics backend to that end. The second pillar is presence in the authoring environment, the thing Figma gave designers: you look at the thing you are making, and other people are there with you. That is why he wanted to own the UI at a deep level.

The old obsession now matches a new need. Everyone is having conversations in the code; the other party is often an agent. When the agent makes changes and you give feedback, where does that feedback live? There is no Git for it. You will not commit every token and run a pull request on each one. Zed is still a work in progress, and Sobo says the team first had to earn the right to ship this by building an editor people would use alone. Phase two is a fine-grained tracking mechanism, roughly a commit on every keystroke or every streamed agent edit, with conversation anchored to those records. The stack is meant to be vertically integrated: UI and infrastructure designed together so you can interact with another being directly in the code.

Earlier this year Zed shipped a first-party agent. The surprise for Sobo was that the hard part was the AI. Tuning prompts and wrestling models is a different kind of difficulty from the algorithmic, data-structure, performance work of an IDE. The Turing-complete software is comparatively easy; the team is still learning the AI side. Meanwhile every lab is shipping an agent. Anthropic has Claude Code. Google’s Gemini CLI was the first one Zed integrated. All of them, in his view, render a fairly impoverished terminal experience that still needs an editor beside it.

Zed’s move is to be the interface for all of them. The reference is the Language Server Protocol, one of the things Microsoft got right with VS Code: pull the intelligence that used to be bundled into a JetBrains-style IDE out into the community, so PHP and TypeScript each have a language server anyone can plug in. ACP, the Agent Client Protocol, is the same idea for agents. Agents will specialize, compete, and leapfrog one another. Rather than bet on a single vendor, let any agent get a great UI inside Zed. The reception has been better than he expected. JetBrains, a theoretical competitor, joined. Aligning with that effort, he says, beats fighting it.

Asked whether he vibe-codes, Sobo says sometimes — and then tells a success story. Zed needed to replace old server-side infrastructure and move it to Cloudflare. In an afternoon he vibe-coded a simulator for the Cloudflare API: feed it JavaScript API docs, ask for Rust bindings, then an abstraction you can plug a simulator into. He knew exactly what he wanted and did not have time to write it, or to produce a vague document for the team. He handed the generated pile to the cloud engineers with a warning not to judge the weird bits too hard. They ran with it. The line he draws for himself is that he will be a vibe-coding boss, but an aware one. The failure mode is thinking you solved 95% of the problem when you solved 5%, then dumping slop on the team.

Zed’s users are not the median developer. Huang estimates on the order of 100,000; Sobo corrects her to about 170,000, with open-source metrics biased low because people can opt out. They tend to be seasoned, hardcore engineers. Roughly half of users use edit prediction — the programmer still in the driver’s seat. About a quarter use some form of agentic editing. When Zed leaned into AI, some people showed up in the comments to object. He does not care. Something is happening, and the company is not going to pretend otherwise. Experienced developers, he thinks, notice when a tool they touch for hours a day drops frames. His daughter’s classmate’s mother, a dentist vibe-coding practice software, may not know she needs an editor that feels good under her fingers. Making her know, he says, is his job.

Zed engineer Conrad Irwin wrote “Why LLMs Can’t Build Software,” which hit number one on Hacker News. Sobo forwarded it to Huang almost apologetically. He is more optimistic than Conrad and less willing to declare what models will never do, but he can say what has worked and what has been frustrating. Before agents, with GPT-4, he rewrote Zed’s graphics backend. The whole UI is drawn by GPU shaders, like a game. Configuring the rendering pipeline and GPU stages is knowledge he did not have; it used to mean Stack Overflow and obscure docs. This time he generated it. He also needed Rust procedural macros to pull Tailwind CSS ideas into Zed’s graphics framework — generate a method for every Tailwind class. He had never learned those macros. The model had.

He calls the feeling a knowledge extruder. The knowledge is in the model’s distribution; he does not want to read a book and digest it slowly. He wants it squeezed into the shape he needs. It is copy-and-paste, but far beyond copy-and-paste, still borrowed from a global knowledge set. Where he gets frustrated is DeltaDB, a system for fine-grained tracking and real-time sync of individual edits on top of Git. It is the first time in a while he has had to load a pile of constraints into his head at once and hold them there. LLMs have not been much help writing the code, because the code is not the constraint. There are not that many lines. He is proud of how few there are. The work is getting the thinking right; the code is a record of that thinking.

He still uses models on that project — to explore ideas, even to generate code he never intends to run, just to feel a direction quickly. Huang restates the boundary, and he agrees: in-distribution tasks where you already have the abstract model go fast; out of distribution, or when the task is thinking rather than typing, the models are not there yet. The other pain is waiting. You can watch the agent, go make coffee, or try to race it; all of them are a little annoying. Watching is sometimes necessary so you can yell stop — he has watched an agent write tests he did not ask for and make those pass while the tests he wanted still failed. For someone who engineered next-frame keystroke feedback, the wait is the worst part. He wants faster models, and tool builders need to know when to switch to a quick one like Haiku versus a smart one. If you could get something almost correct in a tenth of the time, the workflow might shift again. The jury, he says, is still out.

IDEs have looked the same for a long time: tree on the left, tabs in the middle, Git or an agent panel on the right. That layout evolved for one human, one working copy, one problem, solved by hand, maybe with edit prediction. If agents become the primary way of working, the layout has to be rethought. Sobo wants the IDE as a collaborative environment for multiple humans and multiple agents. A conversation with an agent should be something you can pull a teammate into, using the agent thread as background context and a fast way to load the relevant code. He also wants permanence: stable references to locations in the code, and a continuous record of how the code evolved, not a punctuated sequence of snapshots.

Today a codebase is almost naked. You can put comments in the files and hang discussion on GitHub snapshots, but the code itself carries little metadata. He wants the codebase to become a backbone that related data can hang on — conversations, edits, context, all anchored to specific places, a continuous history rather than a stack of diffs. An LLM could then ask, of a stretch of code, what conversations happened behind it, and pull that context. When you bring a colleague in, the agent’s record is already the briefing. He calls this a fundamental abstraction, the foundation for building interaction with LLMs.

In Zed’s prototypes the conversation is not just a chat log. It is also a document that evolves: code references get injected, edits happen, the log unrolls over time. He wants that surface to stop being read-only. Move the cursor up out of the “what do I say next” box and into the earlier conversation, and do real work there. Rendered code windows, when the content is fresh, should be editable in place, synced to the real file, with context expandable the way a GitHub pull request is. Zed already has multibuffers: pieces of code from across the tree combined into one editable surface. He wants the conversation to become that — code pulled toward you, so you can reach out and change it. Select two points in the thread and review the edits in that span. The new editor is not a file. It is a conversation plus pieces of many files, keyboard-navigable, including with Vim bindings. Huang closes by calling him someone on a long quest for the perfect tool for his craft. From 2006 to now the tools have changed twice. The problem has not: humans and code still need a better interface. AI only added another speaker.