Rethinking Git for the Age of Coding Agents with GitHub Cofounder Scott Chacon

**Matt Bornstein** (0:00)
If you ask almost any software developer, when you do code review, do you really read the whole PR? Like, do you go through every line and think it through? Do you pull it down and test it out and then leave the good feedback on each line? Agents are very good at that, right? If something goes wrong, that's very human. It's actually a thing that's never been done in software development is inter-team communication. And so it's a very interesting UX problem set that I think nobody's really thought through, really even now. What does that tool look like in a way that is easy to use and easy to learn? Software developers that will be the best producers of product in the near future are the ones who can communicate, the ones who can write, the ones who can describe. That is, I think, the next superpower. And I think if we could talk to each other in more real time about what we're doing, that's a lot of overhead.

**Scott Chacon** (0:47)
The most widely used developer tool in the world was never designed. Git started as plumbing commands for the Linux kernel team. Unix primitives meant to be wrapped in whatever scripts each developer preferred. A volunteer wrote a unified interface. It got pulled into core. And for 20 years, almost nothing has changed. Now coding agents are the fastest growing users of command line tools, an entirely new persona. They struggle with interactive rebasing. They run status after every command. The assumptions baked into Git's interface no longer hold for humans or machines. The question is whether the tool underpinning nearly all modern software can adapt, or whether something new has to replace it. Matt Bornstein, general partner at a16z, speaks with Scott Chacon, co-founder of GitHub and CEO of GitButler.

**Matt Bornstein** (1:45)
We are here today with Scott Chacon, CEO of GitButler, former co-founder of GitHub. Scott, thank you very much for being here today. Of course, thanks for having me on. You are a major driving force behind GitHub. You've literally written a book on Git. You could be doing anything in the world with your life right now. What's brought you back to Startup Land? It's interesting. I feel like if you ask any sort of repeat founders, they probably have similar answers, right? This is the most fun thing to do. So when I started at GitHub, it was a real sort of slog to learn, okay, like it's stressful and it's difficult and stuff. But when you get something working, it's so satisfying and it's so much fun to build and grow and create something that you want to see exist in the world. So I'm sure I'll be doing this when I'm 90 Do you think there's kind of unfinished business for you in version control or what kind of attracts you back to the same space that you know so well? Yeah, I mean, I did a language learning startup post GitHub because I was trying to learn French at the time. And I think this is the other thing that other founders do is they leave and then they think they can solve any problem. And I couldn't solve that problem. I did try very hard. But did you successfully learn French though? I did not. I successfully learned German because I wanted to start from scratch. And so that was what I dog fooded the product with. And so my German's not bad now. And I married a German after that and live in Berlin now. So it did definitely change the course of my life. Yeah, so long-term ROI on that. Yeah, 100%. Totally worth it, even though the company didn't quite work out. But when I went to go look for something else to do after a very short stint of doing some woodworking, like I think most of us do at some point when we have some time off, I started building some stuff and realized that the tooling for Git hasn't changed since I left, right? Since really I started at, started GitHub or wrote the first edition of the book. Like I was approached by A-Press to write a third edition of the book. And I was like, why? It hasn't, it's exactly the same. Nobody's going to care about updating it with a handful of new commands or capabilities it has. So it became an interesting problem set. What would I want this to look like if I could just sort of scrap the porcelain user interface and have a tool that not only did what Git does better or easier or something, but rethinks it a little bit and said, if we had started from scratch, learning everything we had learned in 2008 or 2005, if I'd gotten involved in the Git project and could come in and say, maybe it should work this way, maybe these are the things that it should do for us. I set out to kind of build that because I thought it would be a really interesting, fun thing to do, especially from my background. Is there truth to the story that there was sort of tension between the Git core committer team and the GitHub founding team early on, right? Because on the face of it, it makes some sense that these teams wouldn't have exactly the same objectives. Yeah, I think they didn't think we were very smart because we couldn't write C code, right? And there was a grudging respect over time because so many projects kind of ended up moving to GitHub. But I think you built like the foundational piece of the entire dev stack. So that earned you like a little bit of credibility. I think they only like it because it's fast. Like, I don't think they liked anything else. If you list, like Linus has talked about us, right? Where they're like, well, like he moved his tree, there was some outage or something, and he moved his tree to GitHub. And he's like, they're a good host. I hate PRs and I hate issues. I hate everything else they have, but they're, abuse them as a host if you want to, right? And so I think that's kind of the general, that was kind of the general. I had friends on the core teams and stuff, and I still hang out and go to the Gitmerge conferences and stuff like that. But I think we always try to be supportive and stay out of their way. Like, it's one of the interesting things, like we might talk about this more later, but how hands-off everybody is to Git itself, right? And so, like, it's a very designed-by-committee type thing because it's an open-source project where whatever seems to be a relatively good idea comes in, but there's not sort of a drive to say, here's what the product should look like, right? And so I think over time, it's just kind of become a Frankenstein where it does lots of things very fast and very well, but it's not designed, right? It doesn't have sort of overall sort of an arc of taste. And so that's kind of where I wanted to come in because there is a lot of, I mean, this was the root of GitButler is we don't want to rewrite the whole stack, right? We don't want to rewrite how it soars data or how it transmits data, wire protocols or anything like that. That's all very solid. It's very good. It's very smart. It's just the user interface that we want to inject some taste and say, here's a way that we think people are trying to use Git and make it easy to do, right? So, the world is moving toward sort of agentic coding or AI-assisted coding now. This is obviously a very different set of ergonomics compared to a human writing, all code by hand. It sounds like you're making the argument that Git wasn't even sort of optimally configured for humans before. Right. Right. No one kind of really driving taste of the developer interface. Now with agents, it's sort of this compounding problem. What do you think will happen? Just expand on this point of what you think needs to change, what needs to stay the same. What's interesting about the Git project is that they started with essentially a Unix philosophy. So I think the listeners that are too young may never sort of heard of the Unix philosophy, but when you write tools in a Unix environment, you want to pipe the output of one into the input of another, so you can change stuff. So it's actually kind of funny now seeing how agents work because they use all of these old Unix tools. They're using like sed and grep and stuff, right? And like where a lot of developers would never, like may never have heard it. They may learn it from their agent, then just seeing these things running and they're like, you want to run sed? I guess so. Like what, you know, what does that do? And so it's very good for that type of thing of saying, okay, I want to do this thing, I want to pipe it into something else and then have it take the output of that, and then I can kind of do this set of filters and stuff. And so the original sort of Git plumbing commands, like all of the commands, like Linus and the original team were like, we're just going to do things that do all of these very basic things, and then you can write Perl scripts to wrap all of them and do whatever you want. So they had no, I don't even think they had an intention of writing a user interface to it, right, or making it easy to use. It was completely orthogonal to their goals, right? They were like, whatever you want it to be, here's the tooling that does it well, and we've solved a lot of the hard problems, the APIs or whatever. You write the interface you want. The hard problems are like the storage layer, data, like what are some of the hard problems? Delta compression, algorithms, wire transfer protocols, all of the sort of how the trees are read fast or written fast or stored in a format that's small or can be transmitted quickly. I see. So if you sort of think of the Git history as a fairly complex tree with data attached, like you need an efficient way to represent this. Right. How to move branches around, like what branches even are, like that was a very, all of it was so much different than the way subversion or RCS. Subversion, CVS, RCS, they were all kind of sort of the next step of a philosophy of how to store data, right? Git completely changed that, right? They just thought of it more as tarballs rather than as like a series of patch files and deltas, like a sort of delta series. So they kind of rewrote it and then had people just do their own pro scripts, right? Not thinking a lot of people would be using it, and just sort of the Linux core team or whatever. This guy Pascy, he wrote these pro scripts that gave it a unified. So then the lazier people that came along that didn't want to write all of that stuff themselves, just started using that, and it became popular enough that they just pulled it into core, and they're like, if you want to use an interface, here you go, right? Here's the ports and for it. And that's the CLI tool, basically? That is the CLI. And then most of those commands haven't changed massively, like those original core ones from 2005, 2006, right? Didn't really change a lot and they rewrote them from Perl and to see, they used to just actually send the Perl scripts to everybody. That's another thing that kids listening to this podcast may not be familiar with Perl. Yeah, Perl. Perl 6 is coming out any day now. So yeah, that was kind of how this started. And the other big philosophy of Git that I really do appreciate but has added to this problem set is that they always wanted to be backwards compatible, right? And so anything that existed before, they won't take out. And like, they would wait for a major version, take out a handful of things, but for the most part, everything works exactly the same way that it did. When I wrote the first version of ProGit, which was like 2009, right? There's almost nothing in that book that doesn't work still. I've just added more stuff, more commands or whatever. So, but yeah, if you start with a Unix philosophy, then what you end up with is sort of a middle ground of something a computer can use, but maybe not super well, and something a human can use, right? So if you run Git branch, it's just a list of branches, right? There's no user interface on it by default, and you can add some stuff that makes it slightly more usable. But the point is they kind of need to solve both of these problems with one interface, which is I need a computer to be able to do this, and I also want a human to be able to sort of interpret this. And so how do we bridge that gap, right? And so it's kind of not great for humans, and not all of the ones are particularly good for computers, but like they'll do dash dash porcelain and some of them, if they want to do that, right? And so like blame, for example.