Why IDEs Won't Die in the Age of AI Coding: Zed Founder Nathan Sobo

[00:00] It just doesn't make sense to me that human beings would stop interacting at all with source code until we get to like AGI, I guess, where human beings aren't going to be doing a lot of different things. But until then, I think we need to. We need to look at code. And so then the question is, what's the best user interface for doing that? [00:30] Bye. [00:35] Today, we're talking with Nathan Sobo, founder of Zed, who spent nearly two decades building IDEs, first building Atom at GitHub, and now Zed. Zed is a modern IDE written in Rust, used by more than 150,000 active developers, and also creates and maintains the ACP, or Agent Client Protocol, which connects different coding agents to different coding surfaces, including Zed. Nathan shares a contrarian take. Despite all the hype around chat and terminal-based AI coding tools, he argues that source [01:03] code itself is a language meant for humans to read, and that we'll always need visual interfaces to understand what AI agents are doing. We dig into whether LLMs can actually code, what the richer collaboration layer between humans and AI might look like for coding, and Nathan's vision for turning code into a metadata backbone where conversations, edits, and context all hang together. [01:23] Enjoy the show. Nathan, thank you for joining us here today. Yeah, thanks for having me on. I want to start with a hard-hitting question. There is a lot of internet talk, chatter about, is this the death of the IDE? So if you roll back two years, everyone was coding primarily in the IDE. Right. And now it seems like as people move towards the terminal and more of these conversational experiences, there's a question in the air, is this the death of the IDE?

[01:53] you know, different states of anxiety of like, is it the death of the idea I've spent my entire life grinding toward building the ultimate tool for this? [02:02] And is it not going to matter? Are these people right? But after mulling it over seriously, because I definitely don't want to be gold plating a buggy whip, I think the... [02:12] Those takes are not realistic. It is... [02:15] Mind-blowing. [02:17] that you can sit down at a terminal and speak English with... [02:23] a script talking to an LLM and make real progress on a code base. And they're, [02:29] millions of people doing that, apparently, including me on occasion. Um, [02:34] But the problem I ran into whenever you use, you know, Claude Code was the thing I think I spent the most time with, is when it wants to show you what it just did and you're reviewing it, you sort of view it through this 10-line or, you know, tiny little excerpt in the terminal. And as soon as you want to see more, you know, [02:52] What do you do? And so I think [02:56] If you believe that the IDE is going to die, then I think that requires you to believe that... [03:01] human beings are not going to need to interact with source code anymore. Like I don't need to take a look and... [03:07] see the context of this edit that the agent just made and all the different things that it's connected to and understand that and load that into my brain. [03:16] And I just fundamentally think that source code is a language, just like natural language is a language. So we have this revolutionary new tool for processing natural language that we've never had. But it's not like source code is...

[03:30] binary that we feed to a processor, right? Like it is intended for human consumption. Like one of my heroes that I learned a lot from Harold Abelson, he's a computer science professor. I think he was at MIT. He has this great quote that I've always loved, which is like, programs should be written for humans. [03:48] people to read and only incidentally for machines to execute, which is an extreme stance because it's like why you're writing the program if you don't want a machine to execute it. There are like a lot of people that program in Haskell and stuff that seem to not actually care about what gets done with all of this stuff. [04:05] programmatic machination. I tend to, but I also... [04:09] see a lot of wisdom in that and that like [04:11] Fundamentally, programs are about us expressing some abstract process in a very precise way. And there is no better language for... [04:22] talking about a lot of different sort of Turing-complete programmatic concepts than source code itself. So it just doesn't make sense to me that [04:30] human beings would stop interacting at all with source code until we get to AGI, I guess, where human beings aren't going to be doing a lot of different things. But until then, I think we need to. We need to look at code. And so then the question is, what's the best user interface for doing that? And is the best user interface a GUI then? [04:52] I think so. Or, you know, there are a lot of different ways of... [04:56] representing an interface to code? Does it need to be graphical? I mean, there are a lot of people...

[05:01] that are using [05:02] Vim, for example, Vim's not a graphical user interface, but is an interface, right? That's optimized around presenting source code, navigating source code. And yes, sometimes editing that source code manually, because I think in the same way that the best way to understand software is often... [05:21] Looking at the software looking at the the best [05:24] human-engineered synthetic language we can... [05:28] derived for it [05:29] expressing this abstract process, sometimes the best way of expressing it is just to write it. Yeah. [05:34] directly. And I'm not [05:36] Here to say that I'm particularly a big fan of grinding through repetitive work or having something that could be written by an LLM. I have no desire to write that necessarily, but I do think that they're often... [05:51] oftentimes still in software where the clearest way to articulate something is just to write [05:55] the code, define a data structure. You know, I could write a sentence to an LLM describing, I want a struct with the following four fields, or even zoom out and describe that on a more abstract level. But if I know [06:09] what I want to express, sometimes source code really is the most efficient way to do it, and in that world, [06:14] a tool designed for navigating and editing source code still seems like a really relevant tool. And I have a feeling that even people that are heavily vibe coding with... [06:25] a tool in the terminal are probably running an editor alongside that tool to inspect what's going on. You mentioned at the start that you've been working on IDEs for your whole career. You are a legend in the IDE space. Just maybe for our listeners, just say a word on your background.

[06:41] When I graduated from college, I decided I wanted to build my own editor. That was 2006, the year after I graduated college. And I've been working my whole career to build the editor I envisioned, which was always sort of at the time, TextMate was a really popular tool. I learned about TextMate from DHH demoing Rails or whatever. It was just lightweight, simple, approachable, fast. [07:06] I'd used Emacs. I'd used Eclipse. I'd used the JetBrains products, which are still really powerful. And all of them brought something to the table in terms of either extensibility or responsiveness or feature richness. But none of them synthesized everything. [07:23] all those things into one package. And so... [07:26] It was like 2006 when I decided I want to build an editor that [07:30] has the same power or more power as... [07:34] The most. [07:35] capable IDEs that take 10 years to start up, you know, and feel kind of sluggish under my fingertips, but then have the same kind of responsiveness as a text may have. [07:47] or a Vim, but also be really extensible, but not have to be extensible in this arcane Vim script language where I'm having to have this pet that I'm feeding every weekend or whatever in my spare time to make sure that my Vim configuration doesn't break. I wrote Adam in Vim. So anyway. Talk about Adam, actually, and then lessons from that and then why you started Zeb. Yeah. The first attempt at delivering this IDE of my dreams was Adam.

[08:11] And I joined GitHub as the [08:15] you know, first one of the first two engineers to work on that project and [08:19] We wanted it to be extremely extensible. And so we decided, why don't we build it on web technology? So in the process of creating Atom, we built the shell around Atom, which we ended up naming Electron. And Electron went on to be the foundation. I just caught that reference. [08:36] Yeah. That was Chris Wandsworth's idea, actually, but not mine. Yeah. And so what we did is we sort of married Node.js, which was getting really popular at the time with Chrome, and then delivered this framework that kind of let you build a web page that looked like a... [08:53] desktop app. And it went on to be really successful. Adam had its day in the sun, then Microsoft kind of copied our idea, took Electron, took code they already had that was running on the web and moved it over. And then the rest was history. I mean, VS Code went on to take over the industry. But at some point, I'd kind of gotten to the point where I felt like Adam had run its course, I'd learned some hard lessons there. Some of them were just about like, [09:20] how do you design a data structure to efficiently represent large quantities of text and edit it, which are as [09:26] a language-neutral lesson, honestly, to some extent. And some of the lessons were about [09:33] not inviting people to bring code onto the main thread and destroy the performance of the application by just running random extension code. We made it very extensible. We were very open, which sort of made it very popular quickly, and then we drowned under the...

[09:52] the promises we had made that were kind of premature. But one of the things was I was just sick of web technology. Like, I remember opening up the performance profile that was built into Electron, Chrome's dev tools, basically, and just looking at something that I was trying to optimize. And I'm just like, I need to get inside of whatever these little lines are in this [10:12] in this flame graph and figure out what's going on inside there, and I just hit the [10:17] the ceiling, I guess, on how fast I could make this thing. And so it was the I think 2017 that [10:23] I decided we need to start over, that a web browser is actually not a suitable foundation for the tool that I really wanted to build, which had a lot to do with [10:33] performance, which sounds like a no big deal. I mean, but performance is not a feature that you can really go back and add later. [10:41] if you've chosen an architecture, you're going to accept the performance capabilities. [10:46] of that architecture and the web wasn't it for me. You built Zed originally to make it easier for humans to pair program with other humans. Right. That ended up being very convenient as AI agents came about and humans started to need to collaborate with AI agents. Talk about that dynamic a bit. [11:03] I think the whole industry has this... [11:05] idea of how we should all be collaborating together. And I was actually at GitHub for [11:11] the current way that we collaborate becoming popular. And it's all about being asynchronous, that you kind of go off in your corner and do a bunch of work, take a snapshot of that, upload it.

[11:24] And then in a web browser, someone writes comments on your snapshot. And then maybe an hour or maybe a day later, you reply. And it's this very like-- [11:33] email oriented experience, asynchronous experience, which [11:38] When you're all on the same page, or maybe when you're working on Linux, which is what Git was designed for originally, and there's people all over the world working on these very disparate things, maybe that's an appropriate modality. [11:51] But I always believed that the best way to collaborate on software was including a lot more times where we're in the code together, writing code together or talking through code together and getting on the same page in a format where we're actually talking to each other and can interrupt each other and also relate to each other as... [12:10] human beings in a way that I just don't see happening on top of the Git-based flow. We use Git [12:18] all the time. And we don't do as much code review as a lot of teams because what we prefer to do is just talk to each other in real time in the code. [12:27] But there just wasn't [12:28] good tool that enabled that. You could use screen sharing [12:31] But the problem with screen sharing is one person is very much in the passenger seat because you've got a round trip keystrokes. [12:39] Yeah, the two big problems when I not knowing that AI was coming. Right. The two big problems I wanted to solve at the outset were. [12:48] Fundamentally better performance. You know, when you type a key, I want [12:51] Pixels responding to you on the next sync of the monitor. So there's zero perceptible lag.

[12:57] We're pretty close. I can't say we're 100% perfect, but we're a hell of a lot closer than you could ever get in a web browser. And can you say a word about how you've achieved that? Yes, I'm on a digression here. Go ahead and say your second thing and then say a word about how you achieve performance. But then the other big pillar, other than performance at the outset, was... [13:16] changing the way that [13:17] developers collaborate on software. And so to do that, [13:22] I really feel like we need to bring the... [13:25] the presence of your teammates into the authoring environment itself in much the way that Figma did for designers. Now designers didn't have a lot of good options to, [13:35] didn't have anything as good as Git, for example, as a compelling alternative. But I still think that vision of... [13:42] You're in the tool looking at the actual thing you're creating, and there are other people there with you, was something that even before I saw Figma, I wanted to bring to the experience of creating software. And so that's why it felt appropriate to own the UI on this deep level. Now, on to the rest of your question about what are the implications of that for AI? [14:03] The vision with Zed was always, I want to link conversations to the code. [14:08] in the authoring environment where the code's being written. And so I actually think that [14:14] conversations in the code, that used to be a kind of a weird idea, right? Because, oh, why would you need to have a conversation in the code? You write it by yourself and you push a snapshot, and then we'll have a conversation on a website about the code you wrote, right?

[14:28] But it's starting to feel a lot more relevant in a world where you're having this conversation all the time with this like spirit being or whatnot. Right. Ghost. Yeah. All of us, even me included, as a big fan of this more synchronous mode of collaboration, we're going to be a little bit more. [14:44] are having a lot more conversations about code in the code. And that's where I see sort of this snapshot-oriented paradigm, [14:54] really breaking down. Like, when... [14:58] I'm interacting with an agent and it goes off and make some changes and I want to give it feedback on those changes. Ideally, I want to kind of permanently store the feedback that I gave on those changes and have a record of that. [15:13] What tools... [15:15] And there's no sort of get for that, if that makes sense. Right. I'm not going to commit on every token the thing emits and then like do a pull request review on that. Right. And so to be real, like that is very much a work in progress. And I think to earn the right to deliver this experience, we first just had to build. [15:32] a capable editor that someone would just want to use to create software on their own. Um, [15:38] I think we've made a ton of progress there and are now starting... [15:41] more earnestly on this phase two of this fine grained tracking mechanism that's sort of the equivalent. [15:50] It's not exactly how it works, but it's kind of the equivalent of having a commit on every keystroke or a commit on every edit that the agent streams in. And then being able to anchor interaction or conversation with.

[16:02] directly to that. [16:03] So that's something that... [16:05] The tech we're building, I think, is something maybe we could have built. [16:08] in isolation. [16:10] Um, [16:10] But then the problem is, well, what [16:12] experience to deliver on top of that. And I always thought the best possible experience would be this vertically integrated, [16:19] We designed the UI and all the infrastructure, top to bottom, to deliver this immersive experience. [16:26] ability to interact directly in the code [16:30] Yeah, with another being. And so you've made the choice to make the IDE almost this... [16:35] Switzerland. [16:36] For humans to collaborate with different AI agents. Right. Talk about the role that agentic coding protocol, is that what it is? Yeah. ACP plays in that vision. I really view... [16:49] Our job is to provide the ultimate interface between the human being, [16:53] the source code, [16:55] other human beings or other artificial human beings, basically. And we built our first party agent. [17:04] like earlier this year, [17:06] and then [17:07] But as we're doing that, and it's quite challenging as, you know, tuning the prompts, I mean, none of it feels like... [17:15] challenging in the same ways that [17:18] building an IDE is in terms of algorithmic complexity and, [17:22] getting the data structures just right and making sure that things are performant. [17:27] The actual Turing Complete software parts of that [17:31] are fairly easy. The hard parts are like,

[17:33] the AI parts. And that's still something that I think... [17:37] we're learning as a team. Like we come from a very different perspective. Meanwhile, I see all these teams [17:44] with that all seem to be quite well funded from some of the big AI labs like Anthropic and Google, Google with Gemini CLI, that they were the first people that we integrated with. [17:57] cloud code. Everyone's building an agent, it seems. And all these agents are rendering what I consider to be a fairly impoverished kind of terminal based system. [18:06] Experience that would need to be supplemented with an editor. So the thought is okay. We've got a great editor And all these people are trying to solve this problem like what needs to happen here is the same thing that I [18:18] the language server protocol did. So one great thing that Microsoft did with VS Code is they took all the intelligence of the IDE that was typically bundled in, like JetBrains style, right, where the IDE comes pre-configured knowing everything, and they moved it out [18:34] to the community. So the PHP has a language server now and, you know, there's the TypeScript language server, et cetera. We wanted to do the same thing with agents. The thought being there's probably going to be different kinds of agents experimenting in different domains. Maybe there's certain agents that are optimized for particular problems, um, [18:53] They're agents competing with each other. So sometimes one will be the best only to be leapfrogged by another. [18:59] externalizing all that and trying to democratize that and say, "Hey, [19:03] Whatever agent you want to use, we want to deliver a great UI for you to interact with that agent and your software.

[19:09] That was the thinking behind it. And so far, it's working out... [19:14] Better than I might have expected, actually. Like, I didn't really know how many people are going to resonate with this idea, but JetBrains got on board. And so that, I think, is really exciting. They're theoretically a competitor, but it's nice to have someone on the other side. [19:29] And now there are a bunch of different agent developers that are getting on board on the other side. We're going to continue working on our own agent. [19:38] But it's nice to be aligned with all that effort. [19:41] Instead of competing with it. Do you vibe good? [19:44] Sometimes. But, yeah, I mean, I have... [19:48] So one successful case of vibe coding is... [19:52] We had some very old... [19:55] Like, [19:56] server-side infrastructure that needed to be replaced. [20:00] And so I decided to move all of our server-side infrastructure to Cloudflare, and I vibe-coded a simulator for the Cloudflare API. Hmm. [20:10] And so basically, we have a trait in Rust that abstracts away everything Cloudflare can do. And I had an afternoon, basically, [20:19] and an idea. [20:22] That was an amazing use case of agentic coding. Of just like... What did you use for it? I just described the idea to the agent. [20:33] I think I fed it some API docs from... [20:37] CloudFlare's JavaScript APIs, and I said, I want to build a Rust, Rust bindings to these APIs, but then I want to, you know, build an abstraction that sort of

[20:48] lets me then plug in a simulator for these APIs as well. And I knew exactly what I wanted. I had a vision, uh, [20:56] And I didn't have a ton of time to express that vision. So in the past, maybe I would have either done it myself, which I definitely didn't have time for. There were other things going on at the time. [21:06] Or written some... [21:08] amorphous document trying to or try to explain it to engineers on my team what I had in mind. [21:15] But what this Vibe coding session enabled me to do was get somewhere in between, if that makes sense. So I sort of apologetically handed this pile of generated code to... [21:25] to the, [21:25] guys working on cloud and was like... [21:28] I generated this. [21:30] This is directionally the way that I want to go. Don't judge me too hard if you find some weird stuff in here that doesn't quite make sense. Like it's generated just so you know. [21:40] That was a huge success, though. I mean, they were able to run forward with it. Yeah, I think I maybe avoided the, like, I never want to be, like, you know, the boss, the vibe coding boss or whatever. Why not? [21:53] What I mean is I want to be the vibe coding boss that's doing it well, but I don't want to be the vibe coding boss who's sort of clueless and thinks that they've solved 95% of the problem when really they've solved 5% of the problem and they're just deluding themselves. I want to do it in an aware way and make sure that I'm actually moving the ball forward and not being annoying. [22:12] uh... [22:13] handing off a big mess of slop to somebody and being like, here you go, clean it up, my great idea.

[22:19] Actually, speaking of, so your user base is on the order of 100,000 active developers in Zed. [22:27] It's 170. [22:28] I think, well, anyway, depends how you measure. 170,000 active developers at the time. And they tend to be pretty hardcore engineers, like elites have been coding for a long time. [22:40] What is your user base's overall perspective on AI? And are they embracing it? Are they using... [22:47] You know, I just listened to the Karpathy interview where he's, you know, he uses autocomplete, but doesn't really use the agentic loop as much. What are your users doing in terms of adopting AI? [22:55] Based on the metrics we have, which are not perfect because it's an open source IDE, it makes it very for people to opt out. [23:04] about half of [23:05] The people using Zet are using our edit prediction capability, which is, you know, I'm coding along and it suggests the next thing. So very much programmer in the driver's seat. And about a quarter of our active users are using Zet. [23:20] agentic editing in some shape or form. We had some haters in the crowd. And I think as we began to embrace AI, there were definitely people who let us know what they thought about that, that we weren't [23:33] whatever, but I don't care about that. It's just like, hey, this is happening. Something's happening here. Like, we're not going to just not go toward that. Like, I'm not like that. And so if they signed up for Zed for being a Luddite or head in the sand or like... [23:49] Right. I'm just clinging to tradition with all our might. Like we're not on board. Like I want to move toward the future. We attract a more professional. Yeah. Like you're saying, hardcore audience, because I think at least at the moment.

[24:03] And again, the full vision isn't built yet. One of the things we have to offer is this extreme performance while [24:10] you know, with every passing day, [24:12] the same features as the other things, but just much better performance. And so I think as a developer becomes more seasoned, they start to care about the tactile experience of the tool they're using under their hands. You use something 40 hours a day, [24:28] it starts to bother you when it's dropping frames or just not being able to keep up with your... [24:34] With your hands, basically. Yeah. So just the kind of people that tend to gravitate towards that now are the kind of people that just care about a really well crafted, fast tool. My daughter goes to school with a girl. Her mom is a dentist and she's vibe coding stuff. [24:49] some software for her dental practice right now, right? [24:52] Does she know that she needs a fast editor that feels good under her fingers? [24:58] I don't know. I'd like her to. I mean, it's kind of my job to I think we have bigger plans and they're going to be things that speak to that wider audience over time. But for now, the people that really. [25:10] tend to be people that are quite experienced. I remember one of your engineers, Conrad... [25:15] wrote this article and you texted it to me almost like sheepishly or apologetically. It was number one hacker news. Why LLMs can't build software. What is your kind of mental model for what LLMs are doing? [25:27] good at in software versus where they're lacking? And how quickly do you think that's changing? I'm less convinced that Conrad, that LLMs can't build software. I think his mental model of the things they're incapable of is maybe...

[25:41] better than mine or he's just more confident than I am in his take. I'm less convinced of what they're not ever going to be capable of doing, but I can tell you what they've worked well at in my own experience and where [25:53] things get frustrating or go wrong for me. I mentioned earlier that generating the cloud flare, um, [26:00] Another earlier experience that I had pre-agentic, pre-agent anything, it was just with GPT-4. [26:08] I generated a new backend for... [26:12] for our graphics framework that we had to write. Like, so we, you were asking earlier about how we achieve our performance. One of the things we do is [26:20] the entire... [26:21] Zed application is organized around delivering data to shaders that run on the GPU that render the entire UI in much the same way that a video game works. [26:32] Render frames of its UI or its... [26:35] experience, I guess it's not a UI, rendering a 2D UI with some of the same techniques that video games use to render their 3D worlds. Interesting. So anyway, I was rewriting the... [26:46] graphics backend. And though I did, you know, write the original, uh, [26:51] you know, graphics back in, uh, I was rewriting it. The old one was like working well enough, but it wasn't in the shape I quite wanted. Um, um, [27:01] And so I was able to just generate like a rendering pipeline that configured, you [27:06] the GPU and all the different stages and all these things that like I would have in the past been searching around on Stack Overflow or digging around and obscure documentation to do.

[27:17] I was able to just go, whoop! [27:19] Because [27:20] All that knowledge, I didn't have it, but it's definitely out there in the distribution of these models. Another thing I did during that same rewrite or fundamental change of our UI framework was... [27:32] I wrote a bunch of procedural macros and macros are, [27:36] in Rust, are really powerful. There are ways to do things that [27:40] You can just put a little annotation on the top of something, and it'll generate all this code behind the scenes before the compiler runs. Yeah. [27:47] But I never really learned to write Rust macros, definitely not these procedural macros that I needed to write. [27:53] in order to basically pull all the ideas from Tailwind CSS into our Rust graphics framework, which really delighted me, this idea that we're pulling... [28:04] these pop culture kind of like tailwind web ideas into the systems programming language and combining these two things together. [28:13] But... [28:14] Tailwind's definitely in the distribution of the LLM. It knows Rust well enough, and it knew how to generate these procedural macros that I didn't know how to generate. And so like... [28:24] Faster than... [28:26] I never would have even attempted to do what I did of like, OK, I'm going to write some macros that generate a method for every single tailwind class. [28:35] and [28:36] but by kind of feeding some docs into it here, I view it as like a knowledge extruder of like, [28:43] There's all this sort of generalized knowledge out there and sure, I could go read about it and learn about it. But no, I want it to be like squeezed out in exactly the shape that I want it. And so that was like a perfect use case for it, I think, of...

[28:57] It was all pretty well-known... [29:00] standard stuff, but I just didn't have it in the shape that I needed. So that was like, I think what they're really good at is it's like copy and paste. [29:10] but way, way beyond. But you're still sort of [29:13] So [29:14] borrowing from the global knowledge set where I've gotten more frustrated. [29:19] is like right now we're working on this Delta DB system, which is trying to do fine grain tracking and real time syncing of individual edits as they occur that layers on top of Git. It's fun because it's been a while since I had some of these moments of just sitting in front of a problem. [29:38] and just struggling to load all the different constraints that need to be solved simultaneously in my head and hold that all in there long enough. LLMs have not been... [29:48] that helpful, David. [29:50] at least not in writing the code, because the code is not the constraint when we're solving this. Like, yes, we're writing code, but [29:57] Much more important is the thinking going behind... [30:01] What is actually not that many total lines of code, they're just the right lines. And I'm proud of how few lines there are. It's like people get excited about how many lines of code they're generating, but... [30:12] And for different kinds of software, maybe that makes sense. But I'm still using LLMs. I'm just not using them to write the code. I'm using them to go explore an idea or even have it generate some code that I never intend to run to just see how it feels. [30:27] quickly. So it's not that I don't use them as a

[30:31] inherent part of my process. It's just like, depending on what I'm doing, I'm not always so sure it's like going to make me faster. Hmm. [30:38] Writing code. So just to read that back to you, when the LLMs are doing something that's kind of in distribution of their training data and where you have a good... [30:46] abstract model of almost the pseudo code of what you want it to do, the models are actually very good at implementing the code. Once you sort of go out of distribution or when writing the code is not actually the task at hand, it's actually the thinking of what you want the code to accomplish, then LLMs are just not there yet. [31:03] I think that's right. [31:04] And... [31:06] Another thing I'll say is I think [31:08] I'm excited for LLMs to get faster. I don't know that Haiku, for example, is intended to be used just directly. We have some work to do as tool builders to figure out when to switch to the faster model or the faster model. [31:21] smarter model, um, [31:24] But in general, I think the faster they can go, whilst not being totally silly, unintelligent, that's the trick. But I'm excited for being able to kind of conjure a diff on demand. Because I think some of it is just like if I'm asking the agent to do this thing, I have a couple different choices. Like I can kind of. [31:43] sit there and watch it, which can sometimes be helpful and sometimes it's important because I'm like, "Stop!" Like, whatever you're doing right now, like, writing tests I didn't ask you to write, that you make pass while the tests I want to make pass is still not passing.

[32:02] I can go like make a coffee or, you know, like go take care of some other task or maybe context switch to some company level concern or whatever. I could go try to compete with it. [32:13] and like let it do its thing. [32:18] But all of them are like... [32:19] a little annoying. Like, again, I'm someone who's obsessed with getting fast feedback. Like I literally engineered the tool to give me keystroke feedback on the next frame. And so it's that waiting that I think has been frustrating for me. [32:33] for me, but I think if I could get something almost correct, [32:38] In a tenth of the time? [32:40] Okay, maybe we're talking about [32:42] shift again. That's why the jury is very much still out for me around where it's all going. [32:48] What do you think is the vision... [32:50] for how the IDE [32:52] ultimately will evolve for we're going to have lots of these agents they're going to become increasingly capable right um how does the gui [33:01] evolve. So is the [33:02] couple different pieces of it. I mean, for me, the deeper piece is this notion of [33:07] Treating the idea is this fundamentally collaborative environment and [33:13] Honestly, what's deployed in Zed today is still pretty alpha quality on that front, but we're taking all those lessons and... [33:21] have very good progress on [33:24] on a new way of representing collaboration. And the IDE is going to be the place where that's all surface. So inherently collaborative experience to me is,

[33:33] multiple humans and multiple agents. The idea that when you're having a conversation with an agent, [33:38] That's potentially something you could pull other humans into. And [33:43] use the conversation with the agent as background context or as a fast track to getting all the relevant code you want to talk about or the problem you want to discuss. [33:53] Loaded up in a very easy to digest way to then pull in a teammate and have that conversation and then I [34:00] The idea of permanence, being able to reference locations in the code in a stable way, having a continuous representation of the evolution of the code rather than this punctuated snapshot based representation to me is going to be like a fundamental abstraction that we're going to need to build. [34:20] any kind of interaction with the LLMs around so that we can remember everything. And so that an LLM will be able to ask about a section of the code. What are all the conversations that happened behind this code to go plumb that context in itself? [34:35] I guess the idea is having the [34:36] code base B... [34:38] this backbone on which all the data related to the code can hang in a way that it just isn't today. You can have comments in your code, and you can have stuff tied to snapshots of your code in GitHub. But for the most part, the code itself... [34:52] is devoid of metadata. And so really unlocking that... [34:57] turning the code into this metadata backbone, [35:01] in the UI is a big piece of it.

[35:03] Some of the stuff I was showing you is – [35:06] asking ourselves the question, and I think a lot of people are asking, IDEs have looked the same for who knows how long, right? Like, it's the typical thing, you got the tree on the left, the tabs in the middle, maybe some Git stuff on the right, or maybe the agent panel, that's where we have our agent panel today. And it's this very... [35:24] It's evolved. [35:25] over time to solve kind of one human in one working copy. [35:31] solving one problem manually, maybe with some edit prediction in the middle. [35:36] But if someone really is working agentically as their primary, like... [35:42] means working, what does it mean to put the conversation front and center? And we're not the only ones thinking about this. Obviously, there are other tools that are also exploring this. The cool thing about us, though, is we are a full-blown IDE. And so... [35:56] I really view it as... [35:58] There's a place for all these different ways of working. And I definitely think that there's a very long-lived place for this traditional way of working. [36:08] I'm in what's going on in this one working copy. And I need to evolve the state of this copy forward until, uh, [36:13] It solves my problem. There's a place for that. [36:16] But then there is a place, I think, for... [36:19] Alright, you've got [36:20] several potential conversations, maybe on different projects going on at the same time. Maybe that becomes less of an issue when the LLM's... [36:30] get faster. But even so, I think then you're going to be just wanting to do even bigger things. And so once you have...

[36:36] this process that takes time, there's this natural desire to multitask. [36:42] And so... [36:43] There's that, like, how do we manage multiple conversations with multiple agents? And then how do we make that conversation? [36:51] more valuable. And so that's really what we're pushing on. And [36:54] in the mockups we've been doing and like [36:57] Right now, I think we model these conversations as very much like a chat. There's more we can do. Let's put it that way. Like, [37:04] in the sense that [37:06] As this conversation is evolving, you could view it as a chat, but it's also sort of a document that's evolving over time. Model is a conversation, but you could also view it as a document. And so inside that document, there are all these references that are being injected from different spots in your code base. Edits are occurring. And that's all kind of getting unrolled over time as this log happens. [37:28] What I really want to do is make that document surface less of a read-only artifact, if that makes sense. Like, more useful as... [37:38] primary editing surface where you could move your cursor up out of the what do you want to say to the agent next and up into the previous conversation to do useful things. So one of the useful things I want to do is [37:51] Right now when we're rendering code, it's like read only. What we're working to do now is when we render [37:56] a window into the code and that code's fresh, [38:00] you should be able to edit right there and have that synchronized with the actual location, expand the context like you can on a,

[38:07] GitHub pull requests, for example. So in Zed, we have this concept of a multibuffer, which is... [38:13] taking little pieces of the code from all of your code base and combining them together into one user interface that you can edit as if it's a single... [38:21] buffer, basically. And so... [38:24] I'm really intrigued that the idea of to what extent is this conversation that I'm having [38:29] pulling code toward me [38:31] potentially making some edits, and why can't I just reach out and [38:35] interact with the code [38:37] directly inside the conversation. And then also, like, when I select between two points, can I review the changes that occurred in that period of time? So it's really like a... [38:48] trying to make that conversation, uh, [38:50] more than just a chat, and more keyboard navigable in a way that someone with their Vim bindings could just, like... [38:57] quickly navigate up through the conversation and make it feel kind of like an editor, a new kind of editor. Having built this thing from scratch and having deep control of all the primitives, an opportunity I'm excited to go grab is like, how can we have this new kind of editor? It's not just showing you a... [39:13] a file in your code base, but it's showing you like a conversation and pieces of all these different files. And you can just reach out and interact with that as you could in an editor. [39:23] Super cool. [39:24] Thanks. Nathan, you've been on a quest to build. [39:27] The perfect tool for your craft for... [39:29] For a long time now, and it's exciting to see what you've done with Zed, and I can't wait to see what you do with agents in the interface and with Delta TV. Thank you. Thanks for joining us today.

[39:40] Yeah, you're most welcome. Yeah, really had fun. [40:10] you