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

Nathan Sobo has spent nearly two decades pursuing one goal: building an IDE that combines the power of full-featured tools like JetBrains with the responsiveness of lightweight editors like Vim. After hitting the performance ceiling with web-based Atom, he founded Zed and rebuilt from scratch in Rust with GPU-accelerated rendering. Now with 170,000 active developers, Zed is positioned at the intersection of human and AI collaboration. Nathan discusses the Agent Client Protocol that makes Zed "Switzerland" for different AI coding agents, and his vision for fine-grained edit tracking that enables permanent, contextual conversations anchored directly to code—a collaborative layer that asynchronous git-based workflows can't provide. Nathan argues that despite terminal-based AI coding tools visual interfaces for code aren't going anywhere, and that source code is a language designed for humans to read, not just machines to execute. Hosted by Sonya Huang and Pat Grady, Sequoia Capital

• 0:00Speaker 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?

• 0:35Speaker 01

  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 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

• 1:20Speaker 01

  where conversations, edits, and context all hang together. Enjoy the show.

• 1:26Speaker 01

  Nathan, thank you for joining us here today.

• 1:28Speaker 00

  Yeah, thanks for having me on.

• 1:30Speaker 01

  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.

• 1:41Speaker 00

  Right.

• 1:41Speaker 01

  And now it seems like as people move towards the terminal and more of these conversational experiences,

• 1:46Speaker 00

  Yeah.

• 1:46Speaker 01

  there's a question in the air, is this the death of the IDE?

• 1:49Speaker 00

  Yeah, and I've actually asked myself that question at different times and, you know, different states of anxiety of like, is it the death of IDE? I've spent my entire life grinding toward building the ultimate tool for this. And is it not going to matter? Are these people right? But I, after mulling it over seriously, because I definitely don't want to be gold-plating buggy whip, I think that those takes are not realistic. It is mind-blowing that you can sit down at a terminal and speak English with

• 2:23Speaker 00

  A script, talking to an LLM and make real progress on a code base. And there are millions of people doing that, apparently, including me on occasion. 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, what do you do like? And so I think if you believe that the ID is going to die, then I think that requires you to believe that human beings are not going to need to interact with source code anymore.

• 3:05Speaker 00

  Like, I don't need to take a look and 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. 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 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

• 3:47Speaker 00

  for people to read and only incidentally for machines to execute." Which is an extreme stance, because it's like, why are you 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 programmatic machination. I tend to. But I also see a lot of wisdom in that, in that like fundamentally, programs are about us expressing some abstract process in a very precise way. And there is no better language for talking about a lot of different sort of Turing-complete programmatic concepts than source code itself.

• 4:28Speaker 00

  So 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?

• 4:48Speaker 02

  And is the best user interface a GUI then?

• 4:52Speaker 00

  I think so, or you know, there are a lot of different ways of representing an interface to code. Does it need to be graphical? I mean, there are a lot of people that are using 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 looking at the software, looking at the best human-engineered synthetic language we can derive for expressing this abstract process. Sometimes the best way of expressing it is just to write it directly. And I'm not here to say that I'm

• 5:37Speaker 00

  particularly a big fan of grinding through repetitive work, or having something that could be written by an LLM. Like, I have no desire to write that necessarily, but I do think that there are often, oftentimes still in software, where the clearest way to articulate something is just to write 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 what I want to express, sometimes source code really is the most efficient way to do it. And in that world, a tool designed for navigating and editing source code still seems like

• 6:19Speaker 00

  a really relevant tool. And I have a feeling that even people that are heavily vibe coding with a tool in the terminal are probably running an editor alongside that tool to inspect what's going on.

• 6:31Speaker 02

  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 what on your background.

• 6:40Speaker 00

  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. 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 all those things into one package.

• 7:25Speaker 00

  And so it was like, yeah, 2006, when I decided I want to build an editor that has the same power or more power as the most 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 TextMate 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 like pet that I'm feeding every weekend or whatever in my spare time to make sure that, you know, my Vim configuration doesn't break. I wrote Atom in Vim. So anyway.

• 8:04Speaker 02

  Talk about Atom, actually, and then lessons from that and then why you started Zeb.

• 8:07Speaker 00

  Yeah. The first attempt at delivering this IDE of my dreams was Atom. And I joined GitHub as the, you know, first, one of the first two engineers to work on that project. And 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.

• 8:35Speaker 02

  I just caught that reference.

• 8:36Speaker 00

  Yeah. That was Chris Wansross'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 webpage that looked like a desktop app. And it went on to be really successful. Atom 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 Atom had run its course. I'd learned some hard lessons there. Some of them were just about like.

• 9:20Speaker 00

  How do you design a data structure to efficiently represent large quantities of text and edit it? Which is a language neutral lesson, honestly, to some extent. And some of the lessons were about 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 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.

• 10:05Speaker 00

  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 flame graph and figure out what's going on inside there. And I just hit the ceiling, I guess, on how fast I could make this thing. And so it was the, I think, 2017 that 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 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. If you've chosen an architecture, you're going to accept the performance capabilities of that architecture. And the web wasn't it for me.

• 10:49Speaker 02

  You built Zed originally to make it easier for humans to pair program with other humans.

• 10:55Speaker 00

  Right.

• 10:56Speaker 02

  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:03Speaker 00

  I think the whole industry has this idea of how we should all be collaborating together. And I was actually at GitHub for 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, 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 email oriented experience, asynchronous experience, which 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.

• 11:48Speaker 00

  Maybe that's an appropriate modality. 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 human beings in a way that I just don't see happening on top of the Git based flow. We use Git 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. But there just wasn't a good tool that enabled that.

• 12:30Speaker 00

  You could use screen sharing, but the problem with screen sharing is one person is very much in the passenger seat because you got to round trip keystrokes. And so, 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 fundamentally better performance. You know, when you type a key, I want pixels responding to you on the next sync of the monitor. So there's zero perceptible lag. 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, but. Go ahead and say your second thing and then say a word about how you achieve performance.

• 13:12Speaker 00

  But then the other big pillar, other than performance at the outset, was changing the way that developers collaborate on software. And so to do that, I really feel like we need to bring the, 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. Didn't have anything as good as Git, for example, as a compelling alternative. But I still think that vision of 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 the steep level.

• 13:57Speaker 00

  Now, on to the rest of your question about what are the implications of that for AI? The vision with Zed was always, I want to link conversations to the code in the authoring environment where the code's being written. And so I actually think that 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? 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.

• 14:40Speaker 00

  All of us, even me included, as a big fan of this more synchronous mode of collaboration, are having a lot more conversations about code in the code. And that's where I see sort of this snapshot-oriented paradigm really breaking down. Like, when I'm interacting with an agent and it goes off and makes 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. What tools? There's no sort of Git 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?

• 15:24Speaker 00

  And so, to be real, like, Zed is very much a work in progress. And I think to earn the right to deliver this experience, we first just had to build a capable editor that someone would just want to use to create software on their own. I think we've made a ton of progress there and are now starting more earnestly on this phase two of this fine-grained tracking mechanism that's sort of the equivalent

• 15:50Speaker 00

  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 directly to that. So that's something that the tech we're building, I think, is something maybe we could have built in isolation. But then the problem is, well, what experience do you deliver on top of that? And I always thought the best possible experience would be this vertically integrated. We design the UI and all the infrastructure, top to bottom, to deliver this immersive ability to interact directly in the code. Yeah, with another being.

• 16:31Speaker 02

  And so you've made the choice to make the IDE almost this Switzerland for humans to collaborate with different AI agents.

• 16:40Speaker 00

  Right.

• 16:41Speaker 02

  Talk about the role that agentic coding protocol, is that what it is? A C P plays in that in that vision.

• 16:47Speaker 00

  I really view our job as to provide the ultimate interface between the human being, the source code, other human beings or other artificial human beings, basically. And we built our first party agent like earlier this year. And then, but as we're doing that, and it's quite challenging as, you know, tuning the prompts. I mean, none of it feels like challenging in the same ways that building an IDE is in terms of algorithmic complexity. And, you know, getting the data structures just right and making sure that things are performant. The actual like touring complete software parts of that are fairly easy.

• 17:32Speaker 00

  The hard parts are like the AI parts. And that's still something that I think we're learning as a team. Like, we come from a very different perspective. Meanwhile, I see all these teams with, that all seem to be quite well funded from some of the big AI labs like Anthropic and Google. Google Gemini CLI, that they were the first people that we integrated with.

• 17:57Speaker 00

  Claude 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 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 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 JetBrain style, right? Where the IDE comes pre-configured, knowing everything. And they moved it out to the communities. So the PHP has a language server now. And, you know, there's the TypeScript language server, et cetera.

• 18:41Speaker 00

  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. There are agents competing with each other. So sometimes one will be the best, only to be leapfrogged by another. Externalizing all that and trying to democratize that and say, hey, whatever agent you want to use, we want to deliver a great UI for you to interact with that agent and your software. That was the thinking behind it. And so far, it's working out better than I might have expected, actually. Like, I didn't really know how many people are going to resonate with this idea, but JetBrain's got on board. And so that, I think, is really exciting.

• 19:24Speaker 00

  They're theoretically a competitor, but it's nice to have someone on the other side. 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, but it's nice to be aligned with all that effort instead of competing with it.

• 19:42Speaker 02

  Do you vibe code?

• 19:44Speaker 00

  Sometimes. But, yeah, I mean, I have... So one successful case of vibe coding is we had some very old, like, server-side infrastructure that needed to be replaced. And so I decided to move all of our server-side infrastructure to CloudFlare. And I vibe-coded a simulator for the CloudFlare API. And so basically, we have a trait in Rust that abstracts away everything CloudFlare can do. And I had an afternoon, basically, and an idea. And... That was an amazing use case of agentic coding of just like. What did you use for it?

• 20:30Speaker 00

  I just described the idea to the agent. I think I fed it some API docs from Cloudflare JavaScript APIs. And I said, I want to build a Rust bindings to these APIs, but then I want to, you know, build an abstraction that sort of lets me then plug in a simulator for these APIs as well. And I knew exactly what I wanted. I had a vision. 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. Or written some amorphous document. Trying to or try to explain it to engineers on my team, what I had in mind.

• 21:15Speaker 00

  But what this vibe coding session enabled me to do was get somewhere in between, if that makes sense like. So I sort of apologetically handed this pile of generated code to the guys working on cloud. It was like, I generated this. 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 like, doesn't quite make sense like it's generated, just so you know. 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.

• 21:50Speaker 02

  Why not?

• 21:53Speaker 00

  What I mean is I want to, 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:14Speaker 00

  Handing off a big mess of slop to somebody and being like, here you go, clean it up. My great idea.

• 22:20Speaker 02

  Actually, speaking of, so your user base is on the order of 100,000 active developers inside.

• 22:27Speaker 00

  It's 170, I think. Well, anyway, depends how you measure.

• 22:31Speaker 02

  170,000 active developers a time. And they tend to be like pretty hardcore engineers, like, you know, elites have been coding for a long time. What is your user base's overall perspective on AI? And are they embracing it? Are they using, you know, I just listened to the Karpati 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:55Speaker 00

  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, about half of the people using Zed 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 agentic editing in some shape or form. You know, 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, you know, that we were whatever, but I don't care about that. It's like, hey, this is happening. Something's happening here.

• 23:38Speaker 00

  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 leadite or head in the sand, or like, or I don't know, 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, and getting the full vision isn't built yet, one of the things we have to offer is this extreme performance while, you know, with every passing day, the same features as the other things, but just much better performance. And so I think as a developer becomes more seasoned,

• 24:19Speaker 00

  they start to care about the tactile experience of the tool they're using under their hands. You use something 40 hours a day. It starts to bother you when it's dropping frames or just not being able to keep up with your with your hands, basically.

• 24:35Speaker 01

  Yeah.

• 24:35Speaker 00

  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 some software for her dental practice right now, right? Does she know that she needs a fast editor that feels good under her fingers? I don't know. I'd like her to. I mean, it's kind of my job to. I, I think we have bigger plans and there are going to be things that speak to that wider audience over time. But for now, the, the people that really care tend to be people that are quite experienced.

• 25:13Speaker 02

  I remember one of your engineers, Conrad, wrote this article and you, you texted it to me almost like sheepishly or apologetically. It was number one hacker news, why L L Ms can't build software. What is your kind of mental model for what L L Ms are good at?

• 25:28Speaker 00

  Yeah.

• 25:28Speaker 02

  In software versus where they're lacking and how quickly do you think that's changing?

• 25:32Speaker 00

  I'm less convinced that Conrad, that L L Ms can't build software. I think his mental model of the things they're incapable of is maybe 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 things get frustrating or go wrong for me. I mentioned earlier that generating the cloud flare.

• 26:00Speaker 00

  Another earlier experience that I had, pre agentic, pre agent, anything, it was just with G P T four. And I generated the, a new backend for, 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 the entire Z application is organized around delivering data to shaders that run on the G P U that render the entire U I in much the same way that a video game would render frames of its U I or its experience. I guess it's not a U I. Rendering a two D U I and with some of the same techniques that video games use to render their three D worlds.

• 26:43Speaker 01

  Interesting.

• 26:44Speaker 00

  So anyway, I was rewriting the graphics backend. And though I did, you know, write the original. You know, graphics backend, I was rewriting it. The old one was like working well enough. It wasn't in the shape I quite wanted. And so I was able to just generate like a rendering pipeline that configured 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 in obscure documentation to do. I was able to just go, whoop. Cause all that knowledge, I didn't have it, but it's definitely out there like in the distribution of these models.

• 27:26Speaker 00

  Another thing I did during that same rewrite or like fundamental change of our UI framework was I wrote a bunch of procedural macros and macros in Rust are really powerful. There are ways to do things that 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. But I never really learned to write Rust macros, definitely not these procedural macros that I needed to write in order to basically pull all the ideas from Tailwind CSS into our Rust graphics framework, which really delighted me, this idea that like, oh, we're pulling like these pop culture kind of like Tailwind web ideas into the systems programming

• 28:10Speaker 00

  language and combining these two things together. But 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 faster than I, I never would have even attempted to do what I did of like, okay, I'm going to write some macros that generate a method for every single Tailwind class. And, but by kind of feeding some docs into it here, I view it as like a knowledge extruder of like, there's all this sort of generalized knowledge out there and, 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.

• 28:53Speaker 00

  And so that was like a perfect use case for it, I think of, it was all pretty well-known 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. But way, way beyond. But you're still sort of borrowing from the global knowledge set. Where I've gotten more frustrated is like, right now, we're working on this Delta DB system, which is trying to do fine-grained 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

• 29:36Speaker 00

  in front of a problem and just struggling to like 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 that helpful, David, 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 much more important is the thinking going behind, you know, what is actually not that many total lines of code, they're just the write lines. And I'm proud of how few lines there are. It's like, people get excited about how much, how many lines of code they're generating, but, 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.

• 30:17Speaker 00

  I'm using them to go explore an idea, or even have it generate some code that I never intend to run to just like, see how it feels quickly. So it's not that I don't use them as an 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 writing code.

• 30:39Speaker 02

  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 abstract model of, you know, almost the pseudocode of what you want it to do, the models are actually very good at implementing the code.

• 30:52Speaker 00

  Yeah.

• 30:52Speaker 02

  Once you sort of go out of distribution, or when writing the code is not actually the task at hand, it's actually the, the thinking of what you want the code to accomplish, then, then LLMs are just not there yet.

• 31:03Speaker 00

  I think that's right. And

• 31:06Speaker 00

  Another thing I'll say is I think the I'm excited for L L Ms 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 smarter model.

• 31:24Speaker 00

  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 of different choices. Like I can kind of sit there and watch it, which can sometimes be helpful. And sometimes it's important because I'm like, stop.

• 31:50Speaker 00

  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 passes and still not passing.

• 32:02Speaker 00

  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 and like let it do its thing.

• 32:18Speaker 00

  But all of them are like 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. But I think if I could get something almost correct in a tenth of the time, okay, maybe we're talking about a shift again. That's why the jury is very much still out for me around where it's all going.

• 32:48Speaker 02

  What do you think is the vision for how the IDE ultimately will evolve for we're going to have lots of these agents, they're going to become increasingly capable?

• 32:58Speaker 00

  Right.

• 32:59Speaker 02

  How does the GUI evolve?

• 33:02Speaker 00

  So there's a couple of different pieces of it. I mean, for me, the deeper piece is this notion of treating the idea as this fundamentally collaborative environment and.

• 33:13Speaker 00

  Honestly, what's deployed in Zed today is still pretty alpha quality on that front. But we're taking all those lessons and have very good progress 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, multiple humans and multiple agents, the idea that when you're having a conversation with an agent, that's potentially something you could pull other humans into and 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 loaded

• 33:54Speaker 00

  up in a very easy to digest way to then pull in a teammate and have that conversation. And then 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 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.

• 34:34Speaker 00

  And I guess the idea is having the codebase be this like 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 is devoid of metadata. Yeah. And so really like unlocking that, turning the code into this metadata backbone in the UI is a big piece of it. Some of the stuff I was showing you is asking ourselves the question that 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've got the tree on the left, the tabs in the middle, maybe some Git stuff on the

• 35:19Speaker 00

  right or maybe the agent panel. That's where we have our agent panel today. And it's this very, it's evolved over time to solve kind of one human in one working copy, solving one problem manually, maybe with some edit prediction in the middle.

• 35:36Speaker 00

  But if if someone really is working agentically as their primary like means of 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 I really view it as 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 I'm in what's going on in this one working copy and I need to evolve the state of this copy forward until it solves my problem. There's a place for that. But then there is a place, I think, for

• 36:19Speaker 00

  all right, you've got several potential conversations, maybe on different projects going on at the same time. Maybe that becomes less of an issue when the L L M's get faster. But even so, I think then you're going to be wanting to do even bigger things. And so, once you have this process that takes time, there's this natural desire to multitask. And so there's that, like, how do we manage multiple conversations with multiple agents? And then, how do we make that conversation more valuable? And so that's really what we're pushing on in in the mockups we've been doing and like 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:04Speaker 00

  in the sense that 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 codebase. Edits are occurring, and that's all kind of getting unrolled over time as this log. What I really want to do is make the that document surface less of a read only artifact, if that makes sense, like more useful as a primary editing surface where you could move your cursor up out of the what do you want to say to the agent next?

• 37:44Speaker 00

  And up into the previous conversation to do useful things. So one of the useful things I want to do is right now, when we're rendering code, it's like read only. What we're working to do now is when we render a window into the code and that code's fresh. You should be able to edit right there and have that synchronized with the actual location, expand the context like you can on a GitHub pull request, for example. So in ZED, we have this concept of a multi buffer, which is taking little pieces of the code from all over your codebase and combining them together into one user interface that you can edit as if it's a single buffer, basically. And so I'm really intrigued that they have, to what extent is this conversation that

• 38:27Speaker 00

  I'm having pulling code toward me, potentially making some edits? And why can't I just reach out and interact with the code 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 trying to make that conversation more than just a chat and more keyboard navigable in a way that someone with their Vim bindings could just like 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 like new kind of editor?

• 39:12Speaker 00

  It's not just showing you a file in your codebase, 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:22Speaker 02

  Super cool.

• 39:23Speaker 00

  Thanks.

• 39:24Speaker 02

  Nathan, you've been on a quest to build the perfect tool for your craft 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 DB.

• 39:38Speaker 00

  Thank you.

• 39:39Speaker 02

  Thanks for joining us today.

• 39:40Speaker 00

  Yeah, you're most welcome. Yeah, really had fun.