Git is holding us back

Great Pods

Git is holding us back

Key Points

Git is essential to modern software development and the entire open source ecosystem, but it's time to rethink version control systems
AI agents are now contributing to codebases alongside humans, creating new challenges that Git wasn't designed to handle
Git's complexity makes it difficult for newcomers, with unintuitive concepts like rebasing that require significant learning
Current workflows force programmers to spend mental energy on version control mechanics instead of focusing on programming
Git was originally built for Linus Torvalds' specific needs - decentralized email-based patch submissions for Linux kernel development
GitHub's centralized platform and pull request system were necessary innovations to make Git practical for most developers
Merge conflicts create a problematic state between commits where normal Git workflows break down
There's a gap between small commits and large pull requests, with no good primitives for intermediate-sized changes
Stacked pull requests are painful in Git, despite being a natural way to work when shipping fast with proper code review
Code review tools like GitHub's interface are inadequate, forcing developers to use workarounds or third-party solutions
Version control should capture the context of why code changed, including AI prompts and agent interactions
Conversations about code are scattered across different tools instead of being linked to the code itself
Zed IDE raised $32 million to build Delta DB, an alternative version control system that tracks operations instead of just snapshots
Delta DB uses CRDTs (Conflict-free Replicated Data Types) to enable real-time collaboration and fine-grained change tracking
The new system aims to preserve the entire dialogue of development - every edit, discussion, and decision linked to the evolving code
Character-level permalinks will survive code transformations, allowing discussions to remain anchored to specific code locations
Zed built their editor from scratch in Rust with collaboration as a first-class feature from day one
The team demonstrates exceptional dedication to quality, even debugging performance issues directly on users' machines

Full Transcript

Language: en
It's genuinely hard to overstate how
important Git is to modern software.
It's essential to the entire ecosystem
that we all build in and love. Open
source would not be what it is today
without Git. Platforms like GitHub would
not be viable without Git. Work at
companies would be obnoxious if every
single company was using their own weird
version control systems. Git has
fundamentally changed how we think about
and ship software. Without it, I don't
know where we'd be. That said, it's time
to rethink things a bit. I've been
saying this for a while. I don't know if
Git is the best possible solution. In
fact, I'm almost certain it isn't. As
great as it is as a standard and as
powerful as it is as a thing we use
every day for managing our source in our
systems, there is potential to make
something better. And the need for
something better is greater than ever
right now. Because all of a sudden,
we're not the only ones coding in our
editors. We have AI agents contributing
as well. Suddenly, we have people who
might not know how to use Git
contributing to our code bases, too. and
making sure we keep track of who's
changing what, where, when, and why, as
well as providing an experience for the
developers that makes actual sense is
really tough. And meanwhile, we're too
busy fighting over merge strategies to
actually make anything happen in the Git
world. I genuinely think there's an
opportunity for some innovation here.
And thankfully, I'm not the only one.
You guys might remember a particular IDE
I covered a while back, the Zed IDE. No,
not Zen the browser. Zed the editor. I
was really excited about Zed. It's not a
VS Code fork. It's a fresh editor from
scratch written in Rust meant to be the
best possible editor experience for
writing code. Recently, they've been
embracing AI really heavily and with
that they're catching more and more of
the issues that exist when you're
building with AI and Git has
increasingly become one of those issues.
Which is why this news was very exciting
to me. Not because Sequoia backed Zed
with $32 million, although that is
really cool. The thing that was exciting
here is that they are waging war on Git.
Talking about code helps us understand
it both individually and as a team. But
with current tooling, these discussions
and all the insights they generate seem
to exist everywhere except the code
itself. Git lets you collaborate by
sharing commits and branches. But
between commits, you work alone in your
own isolated working copy. And this is
why they're introducing Delta DB, their
vision for turning an ID into a
collaborative workspace. It's an
alternative to Git that supposedly will
be compatible with Git. And I'm very
excited because it seems like someone is
finally building the Git alternative
that I've been waiting for for years
now. There's a lot to get into here from
why I don't think Git works well to the
problems many people have with Git to
what a better alternative could look
like. All of that said, I did not raise
$32 million from Sequoia and I've got to
cover some bills. So, quick word from
today's sponsor and then we'll dive
right in. One of the coolest parts of
the AI bubble has very little to do with
AI. There's a sudden interest in big
businesses to try out tools by smaller
companies and teams. It's never been
like that before. Normally big companies
wait until the product is at a certain
level before they'll even look at it and
that's not the case anymore. That said,
they still need to be able to set it up,
which means you have to deal with a lot
of crap in order to get off right for
these companies. Unless you use today's
sponsor, work OS. They are the bridge
between our expected developer
experience as modern full stack
developers using tools like Next and the
things that these weird companies need.
Shouldn't call them weird. They're just
big. But if you've never had to deal
with SAML, Octa, and all the other crazy
abbreviations that this world is full
of, you don't know how painful it is.
We're learning this now, and there's a
reason we're moving T3 to work OS. It's
going to solve a lot of problems for us
over there. The admin portal is such a
killer feature. It lets you just send a
link to the company that's setting up.
They pick the solutions they use, and
now their company's configured to use O
on your app. It really is that easy. Big
businesses like OpenAI, Plaid, and
Carta, as well as small scrappy startups
like Versel and Cursor. Seriously
though, everyone's moving over to work
OS for a reason. One of those reasons is
probably the price. There's no reason to
not start with them. Mistake that we
made with T3 chat because your first
million users are free. Yes, really.
What do you have to lose? Check them out
today at soy.link/workos.
If we're talking about a git killer,
it's only fair to start with what's
wrong with git because if it's fine,
there's no reason to build an
alternative to it. So, what are the
problems with git? There are the obvious
ones like the complexity of the UX like
who understands intuitively what a
rebase is? It makes sense once you're
pretty familiar with Git, but it takes a
while to get to that point. There are a
lot of good arguments against the flow
of Git that I've been hearing from
varying interesting places. One that I
actually really liked was from Casey
Moratori on Prime's podcast. I'll link
this in the description if you want to
watch the whole thing, but I just want
to cover some highlights quick. You have
one piece of work. You break it into a
series of nice, neat little tasks. Each
are individually QA and reviewed, but
they are depending on each other. Is Git
good for this.
why are you asking me?
Because you work with people
because I know I just want you to keep
saying I'll rebut this at the end.
You have any opinions?
You have to. Yeah. My opinion is that
this discussion is why all this stuff is
so freaking ridiculous. like the fact
like your job is to program a computer.
You're supposed to be spending your
mental energy figuring out how to make
good programs, right? And instead like
25% of every programmer's brain now is
occupied with things like should I merge
or rebase that even the fact that that
is something that is now a discussion
means this was a failure. Source code
control should be invisible, right? It
should guide the correct process so that
no one thinks about it. It just tells
you what you need to do to do whatever
it is that you're going to do. I'm just
supposed to program. That's what I'm
supposed to do. And then if there's a
conflict, it should be like, okay,
here's the thing. We send the correct
emails. We we get the, you know,
schedule the meeting. Whatever has to
happen. That source control is supposed
to facilitate programming. But instead,
programmers are facilitating source code
control. It's completely backwards,
right? And so it this needs work. People
should be fixing this instead of
spending all their time arguing about
whether you're going to rebase or merge
or what exactly you're supposed to be
doing for large files. Like, oh, do you
guys use the the virtual file system
thing that they did or do you use this
other plug? How many? It's like, no,
this stuff should have been solved.
Every word is truth. I say this as a
person who actually really really likes
git. If you don't know my history, when
I was first learning code stuff, I was
hosting Minecraft servers and I learned
Git as a way to manage the versions of
the plugins and things I was using
before I'd actually written code. So, I
knew Git and GNU screen, funny enough,
and was very familiar with SSH before I
actually wrote code. And those things
ended up being superpowers for me when I
went to college because I never had the
problem of accidentally deleting code
that like everyone around me and all of
my peers had. Getting good at Git was a
really helpful thing early in my career.
like genuinely really really helpful,
but that doesn't mean it's good enough.
This is git. It tracks collaborative
work on projects through a beautiful
distributed graph theory tree model.
Cool. How do we use it? No idea. Just
memorize these shell commands and type
them to sync up. If you get errors, save
your work elsewhere, delete the project,
and download a fresh copy.
Yep, accurate. That's kind of the
problem, though. The history of Git, I
think, will make it easier to
understand. We started with other source
control options like SVN was the big
one. There was also Mercurial, but I
believe Mercurial happened around the
same time as Git. So SVN was the big
one. The other option was BitKeeper,
which was supposedly pretty good. But
both of these were proprietary.
Honestly, the idea of open- source
software was still kind of new at the
time. So managing the source for an open
source project was not trivial. The way
that you would accept changes is
somebody would email you a patch in an
email chain and people would have a
conversation go back and forth to decide
whether or not that should be merged
into the main code source that people
would access. That was chaos. It was
absolute chaos. And a lot of what made
Git special was Linus' frustration with
these workflows in particular when they
were trying to streamline usage of
Bitkeeper which they had free access to
as like a friendly deal. Their attempt
to reverse engineer it got them banned
from Bitkeeper which pissed off Lionus
so much that he went and made Git. But
Git really feels like what Lionus
needed, which was a decentralized
management system for lots of people
having access to the same source,
perfectly formatting their git history
and their changes so they could submit
them over email to be approved and
merged into this major project. Git was
built out of the specific needs of
Lionus and those specific needs don't
necessarily line up with what most
software developers need today. So much
so that there was the need for a
centralized platform right after Git
started. It's a bit funny to say, but
without GitHub, it's unlikely Git would
have found the success that it has
because as great as the decentralized
model is, it doesn't provide the
experience that we expect as developers
of a centralized source of truth. That
is where everything happens. And one of
the biggest innovations there with
GitHub was the idea of the pull request.
Instead of submitting these changes over
email, you could have your own branch
and then on the GitHub interface, make a
pull request that would suggest the
changes that people could leave comments
on each line, accept it, and then merge
it, creating a whole system for
contributing and collaborating on open
source projects. Git quickly became
essential for open source and GitHub
became the place where all these open
source projects went. Over time, this
ramped up to the crazy world we're in
today where like 95% of developers are
doing the majority of their work in Git.
It fully replaced SVN and BitKeeper in
almost all real workplaces. It's kind of
insane how relevant Git became. So much
so that when I got in a fight about this
on like Hacker News and Twitter a while
ago, people were trying to say that
Git's this new fad that's going to go
away any day now and people are too
expecting of it to be like taught in
schools and whatnot. And I just went in
on this person because it's been the
standard for almost 20 years now. It's
what every job expects you to use and
know. And if you're working on real
software, you have necessarily
encountered and used Git. Not because
you chose Git, but something you're
using chose Git and now you have to know
the basics of it. It's like if you know
how to type on a certy keyboard, you're
probably not very good at CIS admin. If
you don't know how to use Git, you're
probably not very good at coding. That's
just reality. And that reality is
honestly fine. If anything, it's good
because Git is such a powerful thing.
It's such a good open standard that it
has allowed the entire industry to just
stop fighting over the solution and just
have one. That said, there's a lot of
room for improvement despite how good
Git is. We were talking about the
complexity of the UX, but I want to give
more specific examples. Here's one that
I think about far too much because I I
was surprised how bad this was when I
tried to use AI with it. merge
conflicts. When I was working on the
migration for T3 Chat's back end where I
moved basically everything over to
Convex, that PR was massive. It was like
8,000ish lines of code. It had to be
because I was doing a full rewrite of
the backend using a new system entirely.
I'm okay with that and I'm okay with
dealing with merge conflicts. The
problem with merge conflicts is that
they exist in a weird layer of Git. Git
is meant to track the history of changes
that you want to save when you're ready
to save them. Merge conflicts exist
between those changes. Something I do a
lot is partial commits where I'll get
add-p, select the parts I want, ignore
the parts I don't, and then commit
progress or whip or stage one finished
or something like that. And I'll do a
bunch of those incremental commits as I
get things that are good. So I don't
have to worry about nuking it because I
will regularly get stash or get reset
hard because I don't care about what I
have cached because if it wasn't good
enough to commit, it wasn't good enough
to care about. And that's a totally fine
workflow until you hit the edges of git
where it doesn't work. Like merge
conflicts. You can't commit during a
merge. When you commit, it's no longer a
merge. And it's so annoying. Like
absurdly annoying. I ran into this
because I was trying out different AI
tools and agents to see how well they
could handle this merge conflict. And I
was surprised. Most of them got like
half of it right and the other half
wrong. The problem is I can't commit the
part it got right and ignore the part it
got wrong or stash it and put it on
other branch because I'm living between
commits during that window. I could
merge the files that still have the like
git merge conflict in the file itself,
but then everything falls apart and all
of the tooling around git expects that
you're either in a good state or you're
in a merge conflict state, not that you
want to commit during a merge conflict
state. I see people bring up work trees.
I love work trees. They're really good,
but they don't solve this problem at
all. If you think amending the same
commit over and over again somehow
solves this, I don't know if we're
living in the same worlds, but like big
merge conflicts suck hard because
there's no real way to do partial work.
When you are between commits, life gets
really hard in git. The commit is a good
primitive and the pull request is an
okay primitive, but I need something
smaller and I need something between
those two as well because if you're
doing something that is not a full
commit, everything falls apart. And if
you're starting to stack pull requests,
everything falls apart, too. That's why
I'm such a big s for graphite. The idea
of stacked PRs as a way to accept pieces
and then merge the whole pile in when
it's ready is incredible. There's a
reason that Meta doesn't use Git. They
instead use Mercurial with stack diffs.
It's a really good workflow, especially
when you're trying to ship faster. I
love Graphite. They are a sponsor. I'm
not an investor. I probably should have
been, honestly. love these guys and what
they're doing, but what they're doing is
trying to make a better alternative to
the way that we deal with Git's
problems. There are other solutions
built on top of Git. As much as I love
Graphite, I've heard incredible good
things about JJ as well. It's a version
control system built on top of Git that
supposedly solves a lot of these
problems. I don't know. I haven't used
it. Oh Conflicts can be recorded
in commits. Okay, I'm sold. I'll be
trying out JJ next week. Straight up.
That's really cool to see. This is
something I've specifically wanted for a
very, very long time. Yeah. Meanwhile,
GitHub just now announced issue
dependencies where you can have a chain
of issues that block each other. Yes,
just now in August of 2025. Hilarious.
But that doesn't solve the git side of
things. A problem that I run into a lot
is the stacked PRs. If I have a poll
request up and I'm waiting for review,
but I need that for another PR I want to
do, so I just branch off and go work on
it. Then we merge the first PR and we
squash merge it or rebase it or anything
else. The history for the PR I was just
working on is now slightly broken. And
if you know Git well enough to rebase it
properly, cool. You don't, good luck. PR
trains are a very painful thing and they
shouldn't be. It should just it's a
natural way to work especially if you're
shipping fast and also doing a good job
of making sure people like actually
review the code before you merge it.
It's obnoxious that this isn't a first
class citizen in Git because that's not
how Git's supposed to work. Git was
built for peacemeal changes to be sent
to Lionus for review over email and then
merged in by hand. We've been hacking
workflows on top of the Git standard for
a very long time now. And don't get me
started on some of the biggest hacks
like LFS is an insane pile of hacks.
It's incredible that it works, but it's
a lot of hacks. To better frame this,
there's kind of a spectrum of pieces. On
the far left here, you have like a line
of code as like the smallest piece in
your system. And all the way here, you
have the repo. And there are little
pieces that are different sizes that we
work with every day. The pull request is
one of those pieces and it's relatively
large. We also have the git commit which
is relatively small. What we don't have
is something between these two. What we
also don't have is something here that
is tracked. Like once we pass this line,
everything is unttracked until we commit
it. Unless you get really good at
command zing. Like the only way you can
change things pre a commit is with
command z and command shift z. If you
want to track things before commits, you
have to start committing more and that
breaks under a lot of different
workflows. or if you want to do
something different than a poll request
that's like a bit smaller and stackable
but still reviewable, you're kind of
screwed. There's all this space between
commits and pull requests that is
largely unexplored. And there's all this
space before commits that is arguably
even more so unexplored. And this is why
I'm excited about a potential
alternative to Git. The idea that things
in this space can have more metadata,
have a history, and have the ability to
go backwards and forwards in them to
have the context of where this line of
code came from, what agent wrote this,
and what were they doing when they did
it. None of that exists here. And then
between these, as I've been saying, the
idea of like pieces that are ready for
review, but not necessarily ready for
merge, that you could stack up and then
merge all as a group, that just doesn't
exist at all. I mean, it does with
things like graphite or things like
mercurial and the stackive workflow, but
inside of git, they're not native at the
slightest. Again, JJ helps with some of
these things. I haven't used it enough
to confidently say such, but I've heard
enough smart people saying that, but
I've also never actually seen someone
using JJ before, so hard to know for
sure. I've seen more people using their
own bespoke CLIs than I've seen people
using JJ, personally speaking. Doesn't
mean it's not good, just means I haven't
seen it. Code review is a whole separate
mess. A friend from Zed just sent me
this and uh I know I'm going to love
this article and it touches on a lot of
things I am frustrated as hell about. I
honestly kind of want to do a whole
video about code review in the near
future because I have a lot of thoughts.
The current status of Git review is
insane. In particular, this dev was so
frustrated with GitHub that they would
pull down the branch, reset to base so
that all of the changes were staged and
then review it using Magic or their
editor. And then when they want to
actually leave feedback and review the
PR, they go back to GitHub, wait for all
of the back and forth with the GitHub
server for it to actually render the
right thing so they can go finally leave
the goddamn comment. Not fun. I
personally use either graphite cuz I
just really like graphite nowadays. The
GitHub extension for VS Code is highly
underrated. The fact that you can just
open up a PR and review it in your
editor is great, but it's also slow as
Waiting. Waiting. Cool. There's that.
Now I can go look at the files in my
editor and leave comments. It's so much
better than trying to do this inside of
GitHub because the GitHub UI falls apart
when you're trying to do anything with a
big PR in it. I love this workflow. It's
a lot better. So is Graphite to be fair.
The point I'm trying to make here is
that GitHub is not a good enough
platform for reviewing. Some of that's
Git's fault. Most of it's GitHub's
fault. I could go off for a very long
time about the state of code review and
I'm trying to not get sidetracked by
that. So, I will do my best to avoid it
and we will get back to the points I
want to make here. Hopefully, I've
adequately proved the fact that just
because we live in commits, pull
requests, and big repos doesn't mean
there isn't room between these
primitives to make something better. It
would be really nice if I could see what
prompt led to this line of code being
added. Be really nice if I could revert
back a step from my agent without having
to worry about code I was writing
getting overwritten when I go back to
the checkpoint in cursor or claude or
whatever else. If all of these tools
could document the work they're doing as
they do it as part of version control,
you'd have way more control and way more
information. The reason I think that Zed
in particular is capable of doing this
is relatively simply put, but there's a
lot of subtlety to the details.
They have the balls to do it. I say this
because in a world where everybody else
is forking VS Code and adding AI
features and making hundreds of millions
of dollars, Zed built their own groundup
rendering layer in Rust. In a world
where everybody else is forking Klein
and Rue code and kilo code, Zed is
building their own agents and now their
own agent standard that people can use
to add agents into whatever tools they
like. They're helping make Neoim viable
with these AI tools right now with ACP,
their agentic code standard. And they're
doing this all in Rust. By the way, this
is an AI developer tooling company that
writes everything in Rust. Michaela,
who's hanging out in my chat right now,
is one of the few people I've heard say
that AI is actually good at writing Rust
if you do it properly.
And I absolutely believe her because
they are doing it every day. There's one
last piece that really impressed me with
Zed. When I first tried it in a video to
talk about this new VS Code killer, I
had some performance issues. Even though
it was written in Rust, turns out
writing everything in Rust doesn't
magically make it fast, as much as
people like to believe that. There's a
lot of other complications to doing
things well in Rust. One of those
complications is Mac OS, in particular,
the way the metal rendering systems
worked. And they had some assumptions
based on the machines they were using
that weren't true on my M2 MacBook,
which resulted in it being locked at
around 60 fps with weird dips. So
scrolling felt awful. New lines felt
awful. Even just typing to an extent
didn't feel great. And I you not,
the Zed team came to my apartment,
borrowed my laptop, and debugged the
issues on my machine, making custom
builds and airdropping them over so we
could figure out what was wrong. We
spent like 2 hours together fixing the
performance issues I was seeing in Zed.
That's the level of dedication necessary
to do something as bold as a from
scratch groundup new IDE. comes to your
house, fixes perf issues, leaves.
Seriously though, like it's hard to say
how valuable those little things are. As
silly as they might seem, it shows the
level of dedication and care. It's one
of those things where like I'm not an
investor in Zed. If they win, some of my
investments are going to lose out. I
have no financial ties or gains to have
if Zed wins. But I still want them to
because I like the team a lot. I love
how focused and locked in they are on
the problems they're trying to solve. I
like how transparent they are. I love
how they embrace open source. I like how
they're opening all the standards for
all the things they're building. They're
just a good faith player in the space
and they're focused as hell. They get
these problems and they're already doing
what I would consider one of the boldest
possible things. Starting from scratch
in an established open field that you
could have just forked instead. Zed has
everything they need to do this. The
expertise, the care, the focus, the
engineers, the funding, but most
importantly, the balls. They are willing
to do the hard thing no one else wants
to and that's what's necessary to change
Git. You can't just want a Git
alternative. You have to be willing to
kind of die in the trenches for a while
to do it. I actually really like this
way of putting it. Ambush having the
attitude of nothing is beneath me is
very invaluable. Absolutely agree. Hey,
it's not working. Can I come over? Yeah,
seriously though. So, what do they have
in mind? Let's take a look at their
article. This is again their
announcement of their series B. But
that's not what I'm excited about here.
It's what they detail in the series B
announcement. Our ultimate vision is a
new way to collaborate on software where
conversations about code remain
connected to the code itself instead of
being tied to aging snapshots or
scattered across different tools. This
part is so real. the fact that the
reason this code changed or the history
of these changes exists between cloud
code, open code, cursor, GitHub, various
branches that get squashed and destroyed
and all these other things makes it
really hard to track what changed where
and why. The first step was creating a
high-quality editor to serve as the user
interface. Yes, this is the other
important piece here. As I was just
showing, code reviews a lot easier in an
editor than it is in a broken Rails app.
Making yet another web interface that's
yet another code review tool could be
good. It has been with Graphite, but it
also could be not as good. That said, if
you have built an editor from the ground
up to make a better editing experience,
you're no longer trying to force it into
VS Code. I can't tell you how many
things I've seen forced into VS Code
nowadays. Be it the crazy agentic stuff
we do with cursor, winds surf, rue code,
kilo code, augment, or all these other
tools. Be it the attempts to make code
review in editor work like the GitHub
poll request tab, which is a great
feature that you can install as an
extension, but it's still heavily
limited by what VS Code was built to do
and not do. And there's enough
separation between the VS Code team and
the GitHub team that uh they don't kiss.
It doesn't feel great. It feels better
than GitHub, but that's a low bar. But
if you have a company that's focus is a
groundup editor experience and now is
also focused on the collaboration
experience, which they have been since
day one. I remember day one, one of the
big things they pushed was their idea of
collabing live with collab editing,
voice, shared notes, and more. They
built this editor for collaboration from
day one. They're prepared to make a
best-in-class VCS, and potentially even
code review experience, which I'm very
excited to see how that goes. This new
investment allows them to tackle the
next phase of their plan. They're
developing a new kind of operation-based
version control that incrementally
tracks the evolution of your code with
edit level granularity and we're
integrating it into zed to make
collaboration bhold agents and teammates
a first class part of the coding
experience. A lot of what they're
proposing sounds familiar once again
just like Casey I don't want it to tell
me I can't check in. That's absurd. Like
I don't want to create another branch. I
don't want to have to do anything. I
just I made these two changes. When I
type done, I want you to back up what
I'm doing and I want that to be
available on both machines and I'll deal
with it when I deal with it. Okay? Don't
stop my programming because you think
your repository has to be in some
pristine state. I know what I'm doing.
So, just go away. Right? Banger after
banger. I love people who get a system,
use it every day, but know how to argue
against it, too. Zed folks who are
watching this, hit up Casey. Get him on
your side for this. He could be a very
very powerful ally. Very powerful. They
have a breakdown of their thoughts on
why Git isn't good enough. And I want to
go through these cuz this is this is all
bangers. My snapshots constrain our
conversations about code. Real world
software is the product of a neverending
stream of conversations with yourself,
your teammates, and now also with
generative AI models. Talking about code
helps us understand it both individually
and as a team. But with current tooling,
these discussions as well as the
insights that they generate seem to
exist everywhere except the code itself.
I cannot tell you how many times I had
to go hunt through Discord or Slack to
find why we made this change because no
one thought to write it in the commits.
And even if they did, who's going to
read those? I just expect it to not be
there because it's never really made
sense to put it there. No one actually
reads commit history because it's not a
useful artifact. Get let you collaborate
by sharing commits and branches, but
between commits, you work alone in your
own isolated working copy. It's fairly
easy to discuss code that's changing in
a PR. But if you want to have a
conversation about an arbitrary part of
your codebase, you're stuck linking to a
particular version of the relevant code
in a snapshot or worse, pasting text
into a chat app. As snapshots become
stale in message scroll into the past,
your conversations quickly lose their
link to the latest version of the code
and all of that valuable context is
lost. The limitations of snapshots
become even more apparent when working
with AI agents. While you might manage
simple tasks by exchanging comments with
an agent on a pull request, real world
development often requires interaction
between commits. You need to guide
agents, correct their course, and
iterate rapidly. All without the
overhead of creating snapshots for every
exchange, which by the way is again how
most of these tools work. If I command I
and look at my history on something like
T3 chat, I can click this revert button
and go back to a specific state. But
that's an ineditor on my machine thing.
That's not a state that exists in the
source control. It's a state that exists
in VS Code and cursors cache. Our
existing tools were built for humans
trading commits asynchronously, not for
an instant back and forth of synthetic
collaborators. To be clear, Git was
built for an email exchange with Lionus
and the rest of the Linux community.
Chaos. Forcing every AI interaction
through commit-based workflows is like
trying to have a conversation through a
fax machine. Oof. Bars. Yeah, especially
once you get into chaos of like merge
conflicts, it's not a good time. I
almost feel like background agents
became a thing because of how bad these
flows are that just sending off the
agent in the background to go do
something and then come back with the PR
is easier than dealing with this
interop. Today's AI editors patch over
these limitations, but they miss the
core problem. Collaboration is
continuous conversation, not discrete
commits. You can't snapshot every
clarification, every pivot, every back
and forth that shapes the code. And even
if you did, you would squash merge all
of those anyways. We're building a
system that captures this entire
dialogue, every edit, every discussion
linked durably to the code as it
evolves. This frees collaboration from
the rigid structure of commits. And this
is of course delta DB, operation level
version control. Our vision is to turn
your ID into a collaborative workspace
where humans and AI agents work together
across a range of time scales with every
insight preserved and linked to the code
forever. To make this possible, we're
building Delta, a new kind of version
control that tracks every operation, not
just commits. It uses CRDTS to
incrementally record and synchronize
changes as they happen. It's designed to
interoperate with Git, but its
operation-based design supports
real-time interactions that aren't
supported by Git snapshots. Racing
interactions fine grain change tracking
also enables character level permal
links that survive any code
transformation, so we can anchor our
interactions to arbitrary locations in
the codebase, not just to snapshots of
recently changed code. Imagine if
comments were useful. Actually though,
very cool. Oh, they linked a CRDT blog
post. Very interesting. This is from
2022. As I've said, these guys have been
in it for a while. And they cared a lot
about this multiplayer editing
experience. People could share the
editor and work together. Honestly,
multiple humans editing at the same time
never made a lot of sense to me. But AI
working a similar way absolutely does
make sense to me. So, all of the stuff
they built for this suddenly is useful,
but we need better version control for
us to really see the value. And makes
sense. since they're now finally
building that part. Zed's goal is to
make your codebase a living, navigable
history of how your software evolved,
where discussions with humans and AI
agents are durably linked to the code
that they reference, and they're always
up to date. An evolution beyond version
control that incorporates not just the
code, but the background information of
how and why the code got into a
particular state. Context that AI agents
can query to make more informed edits,
understand the assumptions, constraints,
and decisions that shaped the existing
code. Picture a new engineer facing a
production stack, Trace, and Zed. They
highlight a problematic line like an
unwrap that caused a crash. And they see
every related discussion, why the
function was written or what an AI agent
assumed about an invariant. They ping
the responsible human, sparking a quick
chat that turns into a call, all indexed
to the exact code spot, creating a
shared revisitable record without
leaving the codebase. It's also worth
mentioning that Zed is like properly
fully open source. You guys aren't doing
anything weird with your license, right?
GPL3 for the codebase and Apache for the
framework. That is totally proper open
source. Cool. pass my sniff test. And
they plan to do the same with Delta.
Build it, open source it, and offer
optional paid services. I'd imagine that
would be like their cloud. We'll share
more details as development progresses.
This is just the beginning of
reimagining how devs work together, both
with AI agents and with their teams.
If this was almost any other group of
people, I would be so skeptical. But as
they say here, these are the same people
who are making crossos font rendering
and GPU shaders in Rust. They built
their own Tailwind alternative for GPU
rendering in Rust. These guys know what
they're doing. They can actually do
this. And I'm so excited to see what
ends up coming out of it. I was saying
for a while that Git isn't the best
solution for this new AI world. And I'm
excited to see somebody who gets it.
That isn't just yet another AI hype
company, but a business that really
cares about our experience as devs
coming in to try and fix these problems.
What do you guys think though? Am I too
excited or am I being too harsh on Git?
Curious how y'all feel. And until next
time, peace and nerds.

← All Summaries

Watch on YouTube