The space between the Commits with Zed and DeltaDB's Nathan Sobo

Speaker A: Foreign.

Speaker B: Hi, I'm Scott Hanselman. This is another episode of Hansel Minutes. Today I have the pleasure of speaking with Nathan Zobo. He is the founder of zed, and they're working on something amazing called Delta db. How are you, sir?

Speaker A: Um, I'm doing awesome. Glad to be here. Thank you for having me on.

Speaker B: Yeah, thanks for hanging out. So you're kind of a serial founder who kind of ice skates uphill. You're always doing stuff that's like, nope, we're going to do it this way. And I really admire that about you and the folks at zed, and I think it's cool that you are unapologetically doing stuff, because I feel like there's a monoculture in technology where we all want to drive towards standardization. And then we tell ourselves that having only one choice is standardization. You know, like, did you actually download Chrome in order to do this, this talk?

Speaker A: I did, yeah.

Speaker B: Right.

Speaker A: I had gotten a new computer and neglected to get it, uh, because I use Safari just because I don't use the web that much as I used to, basically. And then I like the. Yeah, I like the integration Safari offers, et cetera. So I just hadn't done it. So I guess they're holding. The web's holding out a little bit against this, uh, all normalizing on one thing, but not really. I guess it's all kind of.

Speaker B: Well, I mean, like, there was a time, though, when there was like, 10 browsers to choose from and we would all talk about, like, are you trying Opera? Did you get the new build of Opera? And it's like, I really admire the work that folks like that do, but somehow we all decided. And then when Edge. When Edge became Chromium, it's just all chromium. So we're effectively in this browser monoculture with some outliers like Brave and things like that. And, um, 20 years ago, there were, gosh, 10, 15 different editors to pick from, and there was no clear winner. Right. There were lots of winners. Maybe, uh, you could briefly kind of like, walk us through a little bit of history, starting when maybe a lot of people in their 30s will remember there was an editor called Atom A T O M M. And then out of nowhere, Visual Studio code came along. And then Microsoft bought GitHub and things got a little confusing.

Speaker A: Yeah, Uh, I mean, so Adam was an editor that I created at GitHub with a small team at GitHub. Uh, and it was always kind of. Chris Wanstrass, the founder of GitHub's passion project. He kind of reserved some resources, not a ton, for us to always push this editor forward. Um, but it was very much inspired by my early experiences liking a little, liking different things from a bunch of different editors, but not having a single editor that combined everything that I wanted. And to be fair, like Atom didn't even get there for me either. Uh, but we created that with, and in the process of creating Atom, we created Electron. Electron was the shell, right? The orbital shell around Atom that gave it its life. That you know, basically started this trend of dressing up a web browser as if it's a desktop app. And that of course Microsoft, my understanding you may be no more, uh, uh, based on your connection, um, they were working on Visual Studio for the cloud, basically like a browser based version of Visual Studio which gave rise to this Monaco editor and the stuff around it. And they saw what we were doing with Electron and Atom and picked up Electron and that became Visual Studio code. The truth was, uh, when I started Atom, I really did not know what I was doing. Um, luckily that's different. Thanks to a decade plus of grinding on these problems and learning about the fundamental data structures that makes text editing actually work and building a UI framework, all these other things. But back then, um, yeah, VS code just took over and I think then it just becomes a tale of feedback loops, right? That everything went there, all the extensions went to VS code. We use it because everybody else uses it and everybody else uses it because everybody else uses it and it's a cycle. Um, but I didn't like it. That was my problem. I tried to use VS code for a while. I wrote Zed with my co founders, um, in VS code that was. I'd used Vim, I wrote Adam in Vim, but I wrote Zed in VS code for the tooling, integration. But it wasn't enough for me. I don't know, I didn't want to use a web browser dressed up as a desktop app as many hours as a day as I sit in my IDE writing software, right. Like, it's just, was not a good experience for me.

Speaker B: I feel like, um, I've historically picked the wrong um, the way. I guess it depends on what the, what you call a winner. But I'm thinking about like there was Betamax and I was like, I'm all about Betamax and I got all my tapes for Beta and then it's VHS became it and everyone acknowledges that VHS won, but Betamax was better. And then I got uh, you know, HD DVD and then Blu Ray, Blu Ray One, um, what do you say when people say, well, they won and even though they're not better, we should still do it anyway? Because I think that's the thing that I admire is that when something has 80% market share or more and someone says no, I can still do it better, like that's just so badass.

Speaker A: Yeah. I just knew that I could build something that I personally would be a lot happier using now. I knew I couldn't do it alone. I knew that in order to do it I would need to get the level of resources, uh, you know, that a founding a company would require basically and build a business model, et cetera. But yeah, I was passionate enough about this vision that I had for a better way of doing it, which involved basically reinventing the whole stack that we decided to build on top of last time. Right. So we invented, invented, I mean, came up with Electron. Someone would have come up with that idea, I think, had we not eventually. But like the idea of we have this browser, it's a cross platform UI framework basically that runs everywhere. The only problem is it eats so much ram. It's your. All these abstractions are kind of lowest common denominator, need to support web standards across, you know, multiple, all those different browsers. I guess maybe, maybe now, no, it's just Chromium and that's all you need to do. But like still there's this legacy baggage I think of all these APIs and the APIs don't really give you the control that you need made to really build something truly exceptional. Right. So just knowing that, um, seeing fairly clearly like how something better could be done, but just that it would be a lot of work. Yeah, I was just sitting there one day, the cursor was blinking in VS code and I just said, I can't do this. Any problem I solve, I'm going to need a code editor to solve it. I mean, uh, now that that's shifting, I still think I'm going to need a user interface for interacting with software on some level that's facilitated by agents, et cetera. I personally am not yet signing up for. I'm not even going to look at code at all and don't care about the architecture at all. Like that seems it's not uh, a reality for me yet. So I still need this environment and for me it was just like, I can't move on. I don't know, maybe some people get that about a programming language, which would be crazy. It's like I can't write any more programs. Until I build the perfect programming language. But for me, it was like, there's nothing better for me to do than build this tool. That's. It really just came from that.

Speaker B: That's really cool. One thing I note, though, is that you say things like the way you're phrasing things, you say, I. And I built this for me. And I was watching, I forgot whether it was a documentary or a TED Talk, and the person was saying, customers don't actually know what they want. So I'm going to build the best thing I can for myself. And if I'm right for myself, it will be right for other people. I'm curious how the idea of building something that's exclusively for you and not as. As opposed to like via consensus, where you go out and interview a bunch of customers, how does that inform your product design process?

Speaker A: I mean, it's certainly not exclusively for me. Like, I, uh, mean as soon as I took on the amount of resources to bring members of my team, and they're all users of Zed as well, and what they care about also matters to me. And then there's all these people using Zed, which, you know, I'm sharing now in the dream of Zed with them. So it's certainly not that it's exclusive, but it's that that's where it starts. Like, I really view myself as user zero of the product, and all the rest of it is just kind of an excuse to justify being able to make the product exist for me in a weird way. But as I've done that, I've taken on, uh, obligations, right? I've taken on obligations to my investors and to my teammates and to the community around Zed. It's not just about me, but it, like, started there, if that makes sense.

Speaker B: No, that makes sense. But it's also, uh, the singular passion of, like, you know, that you have good taste. And if your good taste can extend to other products, then. Then it'll be. It'll be good.

Speaker A: Well, yeah, I guess I know that, like, in the past when I built something that I think is really good, truly in my heart, other people have liked it too. That's what I know. You know, so. And that's basically what we've done with Zed and what we're doing with some of the other stuff we're working on, like, um, building. Building the thing we're really excited to use, um, and holding ourselves to a really high standard. It almost doesn't matter what other people are doing with forks, uh, of VS Code Et cetera. To me, I don't know. I'm not doing this to reach some monetary objective or whatever. For me, what's exciting is actually advancing the state of the art for all of this tooling. And to do that actually takes a lot of time. It's a lot of work. You've got to go question fundamental foundations and be willing to go there.

Speaker B: Okay, see that is exciting. So questioning fundamental foundations, whether it be questioning the status quo or who has the market share or. Well, yeah, this is just the editor. We don't need to write editors anymore. The editor is finished. People feel the same thing about source control. Like I grew up in a time where there was Source Depot and there was Source Safe and there was cvs, uh, and SVN and Mercurial and like, and Git and like now they just teach Git in school. So Git may be the user interface, it may be the FTP for code. Like we may have all standardized on it from like a pure API perspective. But now uh, the folks at Zed and you are turning your eyes towards Delta db, which is a version control system that is like using what we, what we now know about how to write software. And it's going up against effectively the biggest vhs, which is Git. Help me understand where, how ZED turned into Delta DB and where the future.

Speaker A: Well, I mean, luckily for us this time around it's a bit different than the fight that we picked with Visual Studio code or the JetBrains products etc. Uh, because I think the good news about Git is it's very um, modular or it's very easy to build on top of Git.

Speaker B: Right?

Speaker A: In a way that electron, you know, I was just like, okay, I can't look at this Chrome Dev Tools profile and see anything that I can do about the fact that I'm trying to write a text editor in a single threaded scripting language that sweats uh, garbage for a living. Right? It's just like there was just no way to build on top of that. We had to go back and start over. But I think in the case of Git, there's actually a lot there that's already a really fine. The reason that Git I think has taken over is there's a lot that just makes sense about the idea of taking snapshots of the code, chaining those snapshots together in a causal graph. Um, nothing's wrong with that. You know, moving uh, files around in these pac files, blob oriented way, like efficient uh, forms of transfer for, uh, bulk data, there's all kinds of problems that Git solves that are just fine. But what we have always. The problem I've always had with Git, since when I started Atom, honestly, and I pitched Chris Wanstroff on why we should build a code, uh, you know, why you should hire me and we should, uh, build a code editor at GitHub was this belief that there was an opportunity to bring the interaction around software off of the snapshots, the artifacts that we left behind, uh, that were left behind from the process of writing the code and more directly to the very moment of writing code itself. That was always something that I really cared about because I came from a pair programming background. And like the way we wrote Adam in the early days, the way we wrote zed, uh, before we built in zed's existing somewhat like, yeah, I wouldn't call them the full fulfillment of the vision that we're. Was what we're actually working on now, the existing collaboration in zed, uh, but we do use it and it is useful. It's like a big part of my co founder, uh, and mine and now the rest of the ZED team's workflow is we talk about software as we are writing it. We always have worked that way. Um, but what feels like so we've always wanted to do this from the very beginning is bring this finer grained understanding of what about all the versions of the code that exist in between these discrete moments where we take a snapshot. How can we refer to those in a stable way and in so doing turn the code itself into the actual canvas on which the rest of the interactions can take place, rather than the snapshots of the code. I think there's this assumption that there's the assumption that, um, the only code worth talking about is the green and red lines.

Speaker B: Okay.

Speaker A: And we don't believe that.

Speaker B: Uh, yeah, let me see if I can paraphrase this because I think that this is one of those. There's an amazing startup story here about like, people that are doing something different and we're on an elevator and I have to do the elevator speech version of Delta db. Right, right. But it's, but it's a lot, there's a lot of context and history that people need to understand. So like, if I'm understanding what you're saying, Git versions, the checkpoints, uh, of the artifacts that you create. But Delta DB wants to version the process between those checkpoints. It wants to the abandoned edits, the prompts, the agent Steering all the little decisions that are between the two commits. There's white space, there's dark matter, that should be versioned as well.

Speaker A: Great. Not only do we want to coordinate it, but we want to make it available to multiple participants across any range of timescales, so in real time. So the basic idea is like right now the status quo is assuming that your team is using uh, agents to write some percentage of their software. When they're doing that, they're having a, uh, one on one kind of DM session with an agent. Um, the byproduct of that is these snapshots that the user creates and they commit and push those snapshots, the byproduct of this conversation, up to GitHub, where the conversation is not, or maybe there are some tools that are not attaching it at the end or something as a pull request to the pull request. Now I start up the separate conversation on these downstream artifacts by versioning everything together, by versioning the conversation itself, along with uh, any edits that occur on embedded work trees, inversioning that entire thing in a continuous way, we're able to actually make the initial conversation with the agent itself a potential opportunity for multiple people to interact as well. So bringing the people upstream into the conversation, uh, as the code's being written or maybe later, right. Like you've interacted with the agent, all the embedded work trees are tied to this conversation, uh, ready to like store it up in the cloud. Your colleague comes along three hours later, you know, after you've gone to bed in a different time zone or something, they pick up your thread right where you left off. Those work trees mirror right down to their disk and they keep going. And they could even ask the agent, what was Scott talking about with you? Can I ask specific questions? Right. The kind of things that you can't really do on a pull request body. I guess you could ask some other agent, you know, uh, some other GitHub associated product or whatever to answer a question for you. But like, why not just cut, cut to the chase, right? You're, there's already a conversation going. Just let other people join it to review your work with the agent and you potentially.

Speaker B: Right, right, right. Because I'm seeing like, you know, GitHub, uh, copilot and Codex and Claude, they all have their own individual notions of sessions. Some remote them, some move them around, some people just put them into markdown files. GitHub Chronicle puts it into like a SQLite database and you can decide whether you want to ship that around or remote that, but you're saying that the conversation, the process in between the commits is itself a valuable artifact that is filled with context and in between activity

Speaker A: that can be used that people might want to be brought in on. Like. Yeah, basically when we're. Yeah, when we, when we ship this. You're never going to have the problem again if you use it. Of, uh, oh, I, I forgot to push and commit my changes. Right. It doesn't matter because what matters is the conversation that you're having. If you invite someone to the conversation, the exact state of the code down to the millisecond that it exists right now in that conversation is available to all the participants. So whereas in Git, the work tree is really a personal artifact. Right. Uh, the repository is a collaborative artifact. It's something you can talk about across machines, but work trees are not. What we're basically doing is making work trees themselves into these inherently collaborative artifacts.

Speaker B: Yeah. So I'm working currently on uh, openclaw on Windows and um, I'm introducing my team, uh, some of which are younger folks, to work trees and the importance of how interesting things become when you start to parallelize across work trees. But ultimately the work trees are on my machine and the branches, there's a proliferation of branches and they don't see my conversations. I'm not giving them my sessions. They see before dots sessions C and after C, they don't see. I asked for this, the developer, the agent assumed that. I corrected the assumption. These edits resulted. Like there's a lot of stack tracing. If you kind of conversational stack tracing and how the agent and I carved or sculpted the code, uh, all of that could be really useful, but it also could be very noisy. It could be just slop. Like how do you decide? Or do you just store it all and let the machine figure it out?

Speaker A: Yeah, I mean, I think obviously, you know, Zed is always very cognizant of how important developers privacy is to them, et cetera. I know that some of the, like, they're like, why would I want to store every single little edit that I do? And it's like, well, we're storing it so that we can index it. And you know, it's like, uh, it's not as simple. Like obviously a feature you could build on top of storing everything is just replaying things from beginning to end. But that is noisy, right? Like it's nice to have that data there and to be able to make that data available at a time of your choosing potentially. But I think more so like When I'm, when we're using this tool internally and I'm joining people's conversations, I kind of like my conver, you know, if I'm running a lot of conversations with agents and I get pulled away and I come back to a conversation and I'm like, okay, let me get my brain booted back up. I don't usually do that by like going to the start of the conversation and reading it from top to bottom. I just ask the agent, hey, can you catch me up here? And maybe it will refer back up to some moments, maybe I'll scroll back up and make some reference. So it's more that it's just there, it's always there for reference, but that the conversation is this entity that becomes inherently multiplayer collaborative. Um, someone pops into it, they can just ask, they could go read it all. But that's not necessarily what we were imagining. It's more just that if they chose, they could choose to stop reading when they want and they have the agent there to help them orient and figure out what's going on as well.

Speaker B: Yeah, yeah, you just scratched my brain a little bit. Because when you said multiplayer, it's like git, everyone talks about how like git's the first source control system that really understands that like multiple people are doing things offline. But like you're describing that like you can have single player games where you tack on multiplayer afterwards or you can design the thing multiplayer from the start. And I'm feeling like, uh, my first question was like, oh, well, Delta DB is a different kind of version control, but it's really this event sourced database for the act of programming, which is by its nature a social and multiplayer event for most, for most people, right?

Speaker A: And in DeltaDB we store a directed acyclic graph, just like git, of everything that happened. It's just that we literally record every single thing that happened and then index it. Uh, and one of the cool things that's unlocked by that index is now I can go to the code itself and flip it around. I have a delta level understanding of every edit and what the conversation that created that edit to begin with or also any reference that any conversation introduced to any version of that code. And because we have basically the ability to translate, once you can locate a character in One version of DeltaDB, our causal understanding of everything that occurs from that point and the fact that we index that means we can locate that character in any subsequent version, um, losslessly, basically. It's not based on sort of squinting through a diff we know everything that happened, we can find it. If it was deleted, we can figure out where it would be. If that makes sense, that can be used as the basis of understanding that in this file, in the past 30 days, these 300 conversations have occurred with agents that reference this particular code. Now it may be that that's so much data that the only person that can make use of it is an agent that would query the code and ask those other context windows questions. Yeah, that's something we're still kind of figuring out in the ui. Like literally right now is how much to surface to the human about the fact that these things are happening elsewhere in the. Yeah.

Speaker B: Anyway, okay, so this is really good. I'm overwhelmed. Uh, which is a good, which is a good sign. So delta, it's very well named because delta, like makes clear we're saving deltas. Now I'm going to pepper you with questions and you can put them together. So like is one keystroke at Delta is a 500 line patch at Delta is if our formatter changes groups grouped. How do you get from character level truth to intention level history?

Speaker A: Yeah, um, one. If you're editing manually, which is like still some part of the time. Some people do, some people are full agentic. Yeah. Then one keystroke is a delta. If you copy 10, uh, K of text and paste it, that's also just one delta. Right. Covering that entire unit of text that you've inserted. Uh, what was the other question though? Sorry, remind me.

Speaker B: Um, so how are you going from character level truth? Sometimes I get overwhelmed with like I've changed a byte and that's a delta.

Speaker A: Right.

Speaker B: Like I intended. Because the developer doesn't change, doesn't care that like these characters 400 to 526 were replaced. They care that like the authentication check was moved below the cache lookup.

Speaker A: Right. And so by. Yeah, it's more that, like the reason that it's valuable to have a delta is that as you've been editing either with the agent or manually, you're doing a bunch of things and then you decide that you want to add an annotation to the source code itself. You're going to go find a particular character in the file potentially to anchor that annotation to. And that character was part of a delta. It was part of an insertion delta that inserted it. It has a unique id. It was an offset into that insertion, then going forward. DeltaDB, because it's indexing, you know, everything that happens after that delta occurred. We're basically storing Enough metadata to enable you to be like, okay, in this version, I want to find the same offset from this particular version, you know, down to the individual delta. Like, yeah, so there's a couple different. Yeah, I'm actually muddling it here because there's a couple different.

Speaker B: Okay, let me, let me try to ask a more clarifying question. If you preserve everything, how do you decide what moments are meaningful semantically?

Speaker A: Um, you can still commit because the git commit DAG is still a subset of the delta DB Causal dag. We're, uh, also, uh, going to introduce this idea of creating moments or waypoints in the conversation with an agent, which are basically lightweight commits, but you can create them continuously. Like, like it's sort of lightweight to create one. You're not actually creating a snapshot, you're just naming a delta version in time. Basically like you're naming a fine grain version.

Speaker B: Okay. And I want to make sure that for folks who may be, uh, listening and they don't know what a DAG is. A DAG is a directed acyclic graph.

Speaker A: Correct. Thank you for that. Correct. Right, so it's like really the, the collection of the deltas is much, you know, it's only partly about the ability to go back to a particular point in time. But again, it is important to be able to do that because if you're looking at a transcript of an agent conversation, what DeltaDB is gonna enable you to do is anytime the agent is creating a reference to the code, you're gonna be able to step through that portal. The feature is called Portals. Step through that and go to that spot exactly in the code as it existed at that moment that the agent was creating that reference. Exactly. And there's no real name for that moment. Right. Unless you want the agent to literally create a commit every single second, which to me, just like, I guess that does end up devolving to deltas. Right. But our point is we can just explicitly model this in terms of deltas. And so then once you jump to that point in the code, uh, we can also give you a timeline that says, keep my cursor exactly in the same logical position as I scrubbed this timeline. Where is that code now? Right. Which might m. Even mean it was cut and pasted to another file or something. You would move there with it. But, uh, understanding of the evolution of the code lets us execute that.

Speaker B: Okay, so that you actually, I didn't even ask this question. And you just answered it. So let's, let's, let's do this again. Because I was going to ask you, this is great. I was going to say, what is a thing that Delta DB can let a developer do that would not just be inconvenient with almost impossible with Git, it'd be structurally impossible. And you just described it like, I want to go back in time and I want to follow the semantic chunk of code and I want to see that it moved from here to here and it switched over to this entirely different module. Uh, doing that in Git would be, I don't know how you'd even do it.

Speaker A: It doesn't feel fluid. You can kind of reconstruct what happened from these snapshots, but by continuously tracking and indexing everything that happened, we're much more able to rapidly answer these kinds of questions. Yeah, DeltaDB is hard to explain because it feels like this very foundational abstraction that enables a lot of different things that we're excited to sort of bring together or hopefully in rapid succession find some minimal scope that demonstrates some very exciting, unique things that Delta does and then keep building on that potential. But yeah, that's one of those things.

Speaker B: But you know, remember that when Git came out, everyone was like, this is never going to work. This is insane. Like no one then this makes no sense. And people are like, I don't understand it and I don't get it. And then it just clicked. Like for the entire world, it just kind of clicked and everyone's like, of course, it should have always been that way. So at some point, like the concept of a conflict free replicated data type is going to be confusing to some people and then they're going to get off the elevator and they're going to go, why didn't we always do it that way? Because merge conflicts suck and we should have done it this way.

Speaker A: The good news is so far, if you're using Git and you're used to a, uh, Git based workflow, you should be able to use DeltaDB without really thinking very much about DeltaDB, meaning the capabilities that it lights up are sort of transparently superimposed on top of Git. And what's cool is we'll watch your work tree on disk, right? So even tools that edit the work tree externally, we will pick that up and conflict free diff to someone else's file system. Actually, even if you have two people completely outside of the tool, uh, which I think is really exciting. But yeah, I derailed. I derailed a bit. Uh, but in general you should not need to think a lot about Delta DB if that makes sense. You can commit, the agent can push for you wherever you'd like to push. But there's certain features and capabilities you'll just get for free without having to do much.

Speaker B: So I can, I can use git. I can feel like I'm getting, I'm doing git. Like it is git compatible. It is Git plus plus.

Speaker A: Yeah, yeah, it's git where we're tracking the, you know, it's, we're a superset of git in a way. We track all the commits and we track everything in between as well.

Speaker B: So then how, who gets to see the internal reasoning trail? Like there's the author, the team, the company. Like I, I've, I've pasted, you know, keys and uh, connection strings that I shouldn't have pasted in before. You know, there's a thin line between like code provenance and workplace surveillance. How do you design it so that I can understand it, but it doesn't become a playback system to judge on how I spent my day totally well right now.

Speaker A: And uh, I've already, I'm even facing this myself because I'm insecure just like everybody else sometimes, right. Like my first fleeting moments talking to the agent, talking. Do I want everybody seeing that? I don't know. I don't know.

Speaker B: Yeah, I think about like I have no idea what I'm doing and I'm typing that to the agent. Like I'd rather not uh, have my part of the process, my panic attacks be part of the shared history of the code. Right.

Speaker A: So in the like you know, kind of pre alpha version we're using internally right now, all you can do is kind of share your entire conversation with the agent, which works pretty well. And like ultimately I just swallow my personal pride and do it when I need to do it. But the plan that I have I think is that you can constrain that, right? Like can I ask share from this moment in the conversation. Right. Like can we hide the paper trail a little bit and just jump straight to the port where I've kind of, you know, maybe there's a compaction that it's occurred or something and we give access to that. So some of that is still in flight. But something that we're cognizant, cognizant of that we can, if we can capture it all and obviously do so in a secure and privacy protecting way and then give the users finer grain controls over exactly how what is captured gets unveiled to their peers. Um, my hope is we can thread that needle and not feel like workplace surveillance, because that's not my goal. I don't want to create that in the world.

Speaker B: Yeah, Well, I really like the idea of being able to say that this part can be verbose and this part can be summarized because we know that, like, in the, in the world of LLMs, text summarization is like, the cheapest and the least invasive thing that you can do. Like the TLDR m of like, take the last two hours I'm about to commit and TLDR it would be a really cool.

Speaker A: But now I could see, like, some skeptical listener might be saying, well, isn't that what a commit is? And like, to some extent that's true, but I just feel like if we can model it continuously and make the identification of these moments just this extremely lightweight thing, that it'll still lead to a more fluid experience. Even in situations where you want to kind of, oh, I want to summarize here, or hide away some of the detail. To me having it all, then you can take away. Yeah, that's, uh, I think going to lead to more compelling experiences than just assuming that you must always pick these discrete points and times and must always summarize.

Speaker B: Yeah, yeah, Very cool. Well, so folks can check it out@zed.dev that's zed.dev deltadb. You can go and sign up. Put in a, uh, request for early access. Put in your email and your GitHub username. Uh, it promises to rewind to any edit branch to any moment. And I really like the idea of tracing code back to conversations, uh, because it fits in how I work. So I'm excited to see where you all are going to take Delta db.

Speaker A: Thank you. Thank you.

Speaker B: Yeah, thanks so much for hanging out with me today. This has been super fun.

Speaker A: I agree. Yeah. Really stimulating, uh, conversation. Great questions. I had a great time.

Speaker B: I'm so glad. We have been chatting with Nathan Silbo, the founder, at zed.dev zed.dev and you can check out Deltadb@zed.dev Deltadb. This has been another episode of Hansel Minutes, and we'll see you again next week.

Speaker A: Sam. Hmm.