Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
The space between the Commits with Zed and DeltaDB's Nathan Sobo
1 Plays3 seconds ago
Scott talks with Nathan Sobo, CEO and co-founder of Zed, about what comes after the traditional code editor. They start with Zed’s vision for a fast, collaborative, AI-native development environment, then go deeper on DeltaDB: a new approach to versioning software at the operation level, not just at the commit level. Nathan explains why so much important software work happens “between commits,” how agent conversations and code changes can become durable shared artifacts, and what it might mean for Git, collaboration, and the future of programming tools. Nathan previously helped build Atom at GitHub, and Zed describes DeltaDB as operation-level version control for human and AI collaboration.
https://zed.dev/deltadb
Recommended
Transcript
00:00:00
Speaker
yes If I'm understanding what you're saying, get versions the checkpoints of the artifacts that you create. The 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. Great. Not only do we want to coordinate it, but we want to make it available to multiple participants.
00:00:27
Speaker
across any range of time scales so in real time so the basic idea is like right now the status quo is assuming that your team is using an agent to write you know some percentage of their software when they're doing that they're having a one-on-one kind of dm session with an agent the byproduct of that is these snapshots that the user creates 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 Zedd, and they're working on something amazing called DeltaDB. How are you, sir?
00:01:03
Speaker
I'm doing awesome. Glad to be here. Thank you for having me on. 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, no, we're going to do it this way. And I really admire that about about you and the folks at Zed. And I think thank you it's cool that you are unapologetically doing stuff because I feel like 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.
00:01:36
Speaker
You know, like, did you to actually download Chrome in order to do this, this talk? I did. Yeah. I, I had gotten a new computer and neglected to get it ah because I use Safari just because I don't use the web that much as I used to basically. And and I like the,
00:01:53
Speaker
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 all normalizing on one thing, but not really, i guess. 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,
00:02:21
Speaker
It's just all chromium. So we're effectively in this browser monoculture right with some outliers like Brave and things like that. And 20 years ago, there were, gosh, 10, 15 different editors to pick from.
00:02:36
Speaker
And there was no clear winner. but There were lots of winners. Maybe 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.
00:02:49
Speaker
And then out of nowhere, Visual Studio Code came along and then Microsoft bought GitHub and things got a little confusing. Yeah. I mean, so Adam was an editor that I created at GitHub with a small team at GitHub.
00:03:04
Speaker
And it was always kind of Chris Wanstras, the founder of GitHub's the passion project. He kind of reserved some resources, not a ton, for us to always push this editor forward.
00:03:16
Speaker
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.
00:03:29
Speaker
And to be fair, like Adam didn't even get there for me. either, ah 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,
00:03:51
Speaker
And that, of course, Microsoft, my understanding, you may be no more ah based on your you know connection. 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.
00:04:15
Speaker
and the truth was like when i started out i might really did not know what i was doing 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 yeah vs code just took over and i think then it just becomes a tale of feedback loops right that You know, everything went there. All the extensions went to VS Code. Like it just, it you know, we use it because everybody else uses it and everybody else uses it because everybody else uses it and it's a cycle.
00:04:53
Speaker
But I didn't like it. That was my problem. It's like I tried to use VS Code for a while. I wrote Zed with my co-founders in VS Code. That was, you know, I'd used Vim. but I wrote Atom in Vim, but I wrote Zed in VS Code for the tooling integration.
00:05:10
Speaker
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 just was not a good experience for me.
00:05:25
Speaker
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 Betamax and then VHS became it. And everyone acknowledges that VHS won, but Betamax was better.
00:05:44
Speaker
And then i got ah you know HD DVD and then blu way Blu-ray one 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.
00:06:05
Speaker
Like that's just so badass. Yeah. I just knew that I could build something that I personally would be a lot happier using.
00:06:16
Speaker
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, but you know, founding a company would require basically and build a business model, et cetera.
00:06:27
Speaker
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 he 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
00:07:16
Speaker
to really build something truly exceptional, right? So just knowing that, seeing fairly clearly like how something better could be done, but just that it would be a lot of work.
00:07:28
Speaker
yeah i Yeah, I was just sitting there one day, the cursor was blinking in VS Code, and I just said, I can't do this. i i Any problem I solve, its I'm going to need a code editor to solve it.
00:07:40
Speaker
I mean, ah 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 a reality for me yet. So I still need this environment. And for me, it was just like, I can't move on.
00:08:03
Speaker
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, I, there's nothing better for me to do than build this tool.
00:08:14
Speaker
That's, it's really just came from that. 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.
00:08:32
Speaker
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 of as opposed to like via consensus where you go out and interview a bunch of customers? How does that inform your product design process?
00:08:50
Speaker
I mean, it's certainly not exclusively for me. Like, I 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.
00:09:04
Speaker
And then of 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.
00:09:28
Speaker
But as I've done that I've taken on obligations, I've taken all obligations to my investors and to my teammates and to the community around Zed. ah It's not just about me, but it like started there, if that makes sense. Now that makes sense. But it's also 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 good. It'll be good. 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.
00:09:59
Speaker
that's 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 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 of VS code, et cetera. To me, like it's not, I don't know. I'm not doing this.
00:10:23
Speaker
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.
00:10:37
Speaker
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. there We don't need to write editors anymore. The editor is finished. People feel the same thing about source control.
00:10:51
Speaker
Like I grew up in a time where there was Source Depot and there was SourceSafe and there was ah CVS and SVN and Mercurial and like and and Git. And like now they just teach Git in school. so get maybe the user interface it may be the ftp for code like we may have all standardized on it's from ah 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
00:11:27
Speaker
the the the big vhs which is git help me understand where how how zed turned into delta db and where the future move 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 jet brains products etc because i think the good news about git is it's very modular or it's very easy to build on top of git right 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 garbage for a living right it's just like
00:12:11
Speaker
There was just no 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. and Nothing's wrong with that. you know Moving files around in these pack files, blob-oriented way, like efficient ah forms of transfer for ah bulk data. There's all kinds of problems that Git solves.
00:12:44
Speaker
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 Wonstroth why we should build a code, you know, why you should hire me and we should ah 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, that were left behind from the process of writing the code and more directly to the very moment of writing code itself.
00:13:20
Speaker
That was always something that I really cared about because I came from a pair programming background. And like the way we wrote Atom in the early days, the way we wrote Zed 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, but we do use it and it is useful. It's like a big part of my co-founder 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.
00:13:53
Speaker
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 exists in between these discrete moments where we take a snapshot?
00:14:07
Speaker
How can we refer to those in a stable way? and 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 um yeah there's the assumption that the only code worth talking about is the green and red lines.
00:14:33
Speaker
And we don't believe that. Yeah. let me 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 DP.
00:14:47
Speaker
Right, right. But it's but it's a lot. There's a lot of context in history that people need to understand. So like yes if I'm understanding what you're saying, get versions, the checkpoints of the artifacts that you create. But DeltaDB 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. 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
00:15:27
Speaker
your team is using an agent to write you know some percentage of their software. When they're doing that, they're having a one-on-one kind of DM session with an agent.
00:15:38
Speaker
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.
00:16:00
Speaker
By versioning everything together, by versioning the conversation itself, along with any edits that occur on embedded work trees, and versioning 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.
00:16:21
Speaker
So bringing... the people upstream into the conversation 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, ah ready to like store it up in the cloud.
00:16:35
Speaker
Your colleague comes along three hours later, 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.
00:16:47
Speaker
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 add ask some other agent, you know ah some other GitHub associated product or whatever to answer a question for you. But like, why not just 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 with the agent and you potentially.
00:17:18
Speaker
Right, right, right. Because I'm seeing like, you know, gi GitHub 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.
00:17:47
Speaker
that can be 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, of 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,
00:18:09
Speaker
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? there are The repository is a collaborative artifact.
00:18:24
Speaker
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. Yeah, so I'm working currently on OpenClaw on Windows, and i'm I'm introducing my team, some of which are younger younger folks, to WorkTrees and the importance of like how interesting things become when you start to parallelize across WorkTrees. But ultimately, the WorkTrees are on my machine and the branches, there's there's a
00:18:56
Speaker
proliferation of branches and they don't see my conversations. I'm not giving them my sessions. They see before dots C sharp and after dot C sharp. 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.
00:19:15
Speaker
Stack tracing, if you kind of conversational stack tracing and how the agent and I carved or sculpted the code. Right. um All of that could be really useful, but it also could be very noisy.
00:19:26
Speaker
It could be just slop. Like, how do you decide or do you just store it all and let the machine figure it out? 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, know, it's like, 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.
00:20:00
Speaker
But that that's 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,
00:20:15
Speaker
I kind of like my, kind 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.
00:20:30
Speaker
I just asked 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.
00:20:42
Speaker
But that the conversation is this entity that becomes inherently multiplayer, collaborative. someone pops into it, they could 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.
00:21:04
Speaker
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, where you can design the thing multiplayer from the start.
00:21:26
Speaker
right And I'm feeling like my first question was like, oh, DeltaDB 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.
00:21:40
Speaker
Right, 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 thing that happened and then index it. 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.
00:22:00
Speaker
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, it's basically once you can locate a character in one version of Delta DB, 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 and losslessly, basically. It's not based on sort of squinting through a diff.
00:22:38
Speaker
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. And that can be used as the basis of understanding that in this file,
00:22:51
Speaker
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.
00:23:07
Speaker
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, anyway.
00:23:18
Speaker
Okay, so this is really good. I'm overwhelmed, 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 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?
00:23:45
Speaker
Yeah. and one If you're editing manually, which is like still some part of the time, some people do, some people are foliogentic, yeah, then one keystroke is a delta. If you copy... a you know, 10K of text and paste it, that's also just one delta, right? Covering that entire unit of text that you've inserted. What was the other question though? Sorry, remind me.
00:24:08
Speaker
So how are you going from character level truth? I'm like, I sometimes you get overwhelmed with like, I've changed a byte and that's a delta. Right. Like I intend it because the developer doesn't change, doesn't care that like these characters 400 to 526 were replaced.
00:24:24
Speaker
They care that like the authentication check was moved below the cash lookup. 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 wanna add an annotation to the source code itself, you're gonna go find a particular character in the file potentially to anchor that annotation to.
00:24:51
Speaker
And that character was part of a Delta. It was part of an insertion Delta that inserted 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, know, I want to find the same offset from this particular version, you know down to the individual delta.
00:25:22
Speaker
Like, yeah, so there's a couple different, yeah, I'm actually muddling it here because there's a couple different. Let me try to ask a more clarifying question. If you preserve everything, yeah how do you decide what moments are meaningful semantically?
00:25:35
Speaker
You can still commit because the git commit dag is still a subset of the delta db causal dag. ah We're also and going to introduce these this idea of creating moments or waypoints in the conversation with an agent, which are basically like lightweight commits, but you can create them continuously.
00:25:55
Speaker
Like it's sort of lightweight to create one. You're not actually creating a snapshot, you're just naming delta version in time basically like you're naming a fine-grained version okay 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 correct thank you for that correct right so it's like Yeah, so 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 going to enable you to do is anytime the the agent is creating a reference to the code,
00:26:38
Speaker
you're gonna be able to step through that portal. it's 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.
00:26:53
Speaker
And there's no real like name for that moment, right? like 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? where But our point is like we can just explicitly model this in terms of deltas.
00:27:11
Speaker
And so then once you jump to that point in the code, ah we can also put you give you a timeline that says, keep my cursor exactly in the same logical position as I scrub this timeline.
00:27:24
Speaker
where is that code now, right? Which might even mean it was cut and pasted to another file or something. You would move there with it. But our understanding of the evolution of the code lets us execute that.
00:27:35
Speaker
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 gonna ask you, this is great. I was gonna 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 wanna go back in time and I wanna follow the semantic chunk of code.
00:27:59
Speaker
right And I wanna see that it moved from here to here and it switched over to this entirely different module. Doing that in Git would be, I don't know how you'd even do it. 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 like rapidly answer these kinds of questions. Yeah, DeltaDB is hard to explain because it feels like this very...
00:28:26
Speaker
foundational abstraction that enables a lot of different things that we're excited to sort of bring together or hopefully in rapid succession, like find some minimal scope that demonstrates some very exciting, unique things that Delta does and then keep building on that potential.
00:28:42
Speaker
But yeah, that's one of those things. But, you know, remember that when Git came out, everyone was like, this is never going to work. This is insane. Like, no one, this makes no sense. And and 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 clipped. And everyone's like, oh 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 why didn't we always do it that way? Because merge conflicts suck. And we should have done it this way.
00:29:13
Speaker
The good news is so far, if you're using Git and you're used to a 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.
00:29:32
Speaker
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, which I think is really exciting. But yeah, I derailed, i derailed a bit. i But in general, you should not need to think a lot about DeltaDB, if that makes sense. you You can commit, you can, 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.
00:30:09
Speaker
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 Yeah, it's Git where we're tracking the, you know' we're a superset of Git in a way, we track all the commands and we track everything in between as well.
00:30:26
Speaker
So then ah how who gets to see the internal reasoning trail? Like there's the author, of the team, the company. Like I've i've pasted you know keys and ah connection strings that I shouldn't have pasted in before. you know thes There's a thin line between like code provenance and a 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?
00:30:51
Speaker
Totally. Well, right now, and 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, do I want everybody seeing that? i don't know. I don't know. At this point. I think about like, I have no idea what I'm doing. I'm typing that to the agent. Like I'd rather not ah yeah have my part of the process, my panic attacks be part of the shared history of the code. Right.
00:31:17
Speaker
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. um which works pretty well and like ultimately i just swallow my 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, ah can we hide the paper trail a little bit and just jump straight to the board where I've...
00:31:47
Speaker
and 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 cognitive cognizant of that we can, then 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. My hope is we can thread that needle and not feel workplace surveillance because that's not my goal. I don't want to create that in the world. Yeah.
00:32:21
Speaker
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 LLM's text summarization is like the cheapest and the least invasive thing that you can do. Like the TLDR of like, take the last two hours I'm about to commit and TLDR it would be a really cool cool. 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,
00:32:55
Speaker
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.
00:33:07
Speaker
To me, having it all, then you can take away. Yeah, that's, I think, going to lead to more compelling experiences than just assuming that you must always pick these discrete points in times and must always summarize. Yeah.
00:33:22
Speaker
Yeah, very cool. Well, so folks can check it out at zed.dev. That's zed.dev slash Delta DB. You can go and sign up, put in a request for early access, put in your email and your GitHub username. It promises to rewind to any edit, branch to any moment. And I really like the idea of tracing code back to conversations because it it fits in how I work. So I'm excited to see where you all are going to take Delta DB.
00:33:48
Speaker
Thank you. Thank you. yeah Thanks so much for hanging out with me today. This has been super fun. I agree. Yeah, really stimulating conversation. Great questions. i had a great time. I'm so glad. We have been chatting with Nathan Silbo, the founder at Zed.dev, Z-E-D.dev. And you can check out Delta DB at Zed.dev slash Delta DB. This has been another episode of Hansel Minutes, and we'll see you again next week.