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

16:37Matt Bornstein:But it's a new era of trying to figure out usability.

16:40Scott Chacon:That's so interesting. You know, I'm picturing the consultants showing up with their slide decks saying, you know, here's your persona, you know, Agent Dallas, right? Here's your persona. Just a picture of a bot. Yeah, exactly. You know, at least, actually, I guess you don't need the consultants because you can just ask the models directly, right? Like they're available everywhere all the time. So I think that's actually a really interesting observation. Can you go through some of the sort of reasons that Git Butler, especially the CLI, is a better fit for agentic workflows than kind of plain Git?

17:10Matt Bornstein:I mean, for one, it's because the input and output are built specifically for that, right? So we get to look at what it's trying to do and try to give it feature flags that it's trying to run, right? Or that it asks for or is trying to get around by writing some Python script. and then I can see what the Python script does and be like, okay, here's a new sort of flag that you can give that command so that that's the only output that comes out, right? And sort of optimize for what it's trying to, like we can see what it's trying to do. And I find that really interesting. The other thing that GitBother specifically is really good at, one of the early design decisions that I found really valuable and powerful is doing parallel branches.

17:53Matt Bornstein:So a lot of people are using kind of work trees now to do a lot of stuff in parallel. so the agents don't step on each other. And every, I mean, humans have dealt with this for a long time, right? Of like, you're working on some feature and then you see a bug, you notice a bug, right? That you want to fix and you have to decide, do I stash everything I'm doing, fix the bug, open a branch, you know, push it to that and then go like, you know, go back to my other branch and unstash whatever.

18:18Scott Chacon:Stashing always felt a little hacky, didn't it?

18:20Matt Bornstein:But I mean, it's an artifact of you can only be on one branch at one time, right? There's one head, there's one index, there's one working directory, that you can deal with at a time. And the data model just doesn't really support that very well. And so we built stuff on top of that where we essentially have like a hidden mega merge type thing. And you can have multiple branches and you can take stuff that you've done and assign it to different branches and commit it to different branches orthogonally. And then it doesn't matter what order you merge these branches in, but it's using one working directory.

18:48Matt Bornstein:And so what's really nice about doing multi-agent work, which not everybody's doing, I think some of us are like some people that are really trying to push the boundaries of using a lot of agents constantly. But one thing that's nice about doing that instead of work trees is that the agents can see each other's work, right? And so it's almost like they're kind of, not pair programming, but they're using one working directory. So if one agent modifies a file and then the other agent tries to, it notices that it's been modified and it can pull how it's been modified and then add on top of that, right?

19:23Matt Bornstein:And so, and not create conflicts. And so they don't even, we even experimented with having like a communication between agents. So we have three agents running at one time, give them a little chat channel and they can talk to each other about what they're doing. Hey, I'm editing this file now and stuff. And it was super cool. I wanted to ship it so badly. I'm like, this is awesome. This is so, we had a little Tui, you could see them talking to each other and stuff. And I'm like, this is amazing. And we put it like through, like very sadly, we were all devastated. it does not help right like they they will see that something else is happening i see they'll figure out what why right like it'll be like looks like somebody's working on this some other feature because they added this stuff so i'm gonna leave that alone and i'll put my my changes somewhere else and it's faster right because they don't have the overhead of the communication so unfortunately we we're not shipping that because i i really wanted to to be able to show that off

20:17Scott Chacon:because it's very it's very fun but just to sort of parse what you're what you're saying a little bit. Like if I have, you know, five agents operating on the same repo at the same time, same code base, the work tree solution is basically making five copies of the working directory with some sort of smart, you know, storage optimizations, but basically five separate copies. The idea behind parallel branches with Git Butler is that everybody's operating on the same code base directly at the same time.

20:43Matt Bornstein:And they're surprisingly good at not stepping on each other. And they can't make merge conflicts because they only have, they all have the same files to edit, right? That's super interesting. And so that, but when they're done with their loop, right? Or when they have an agent stop and they try to commit stuff, if they have our skill, then they'll look at it and they'll be like, okay, I'm just going to create my own branch. Like each one of them can work in their own branches and they can commit their stuff into their own branches. And now it's sophisticated enough where if one agent really wants to edit something that another agent did, it can see that it's locked and it can stack the branch instead, right?

21:18Matt Bornstein:And so now it doesn't really matter if they're stepping on each other or not. They can kind of figure out. My co-founder, Kirill, today was showing me this thing where the two agents had, you know, they were both trying to sort of vie for the same file and edit it in a way that wasn't really compatible. And so they, one stack hit their branch on top of the other one, and then they kept working and they kept committing, but they commit to their part of the stack, right? Oh, that's cool. And so, like, that's the type of thing that you can't, it's really, really difficult to do that with work trees or really any other type of, like you can't do it with Git, right?

21:50Matt Bornstein:Like just plain Git doesn't allow for that very, it doesn't really allow for it at all, right? Like you can't do rebasing and sort of amending commits or moving commits down the stack or something like, or squashing stuff. So it's just not possible. So part of it is that we have that solution, but the other part is we're really trying to make the tools accessible for agents in the first place, right?

22:13Scott Chacon:That's super interesting. So I still get the sort of logical isolation of the branch, but the agents, like, can kind of see each other's work and, like, you don't, you know, it kind of makes sense, right? It's like if you completely isolate them each in their own working directory, they, by definition, don't have any awareness of what the others are doing.

22:30Matt Bornstein:And, I mean, there's other ways of getting around that as everybody, you know, finds out, right? Like, if two work trees create merge conflicts, they won't figure it out, and then they get a merge conflict, you know, on GitHub when, you know, the second person merges or whatever, and then you can get the agent to pull it down and fix it and try it again or something like that. So it is doable, but it's kind of nicer to just not have them in the first place and be able to kind of review everything sort of from a high level standpoint and be like, okay, that's all of these have done what I want.

22:57Matt Bornstein:And I have these two stack branches and then two independent branches. And these all three of these stacks can be merged in any order. And we're really going to end up with my working directory now. Right. That's kind of where it started. Right.

23:09Scott Chacon:And so this functionality is all built into the CLI now, and so agents can, different types of agents can use this just by calling out to the CLI, basically. That's very cool. So what do you think happens to GitHub in this world, right? Like Git clearly is still the backbone everyone's building on. You're even extending sort of Git. You're not like building a whole thing. But GitHub in some ways seems less relevant than it was before. I'm curious what you think will happen next.

23:36Matt Bornstein:I mean, I think it depends on GitHub, right? I think it's actually mostly framed as what's the next GitHub, because I think people feel like GitHub's not going to be able to pivot fast enough to keep up. I mean, it's a rocket, it's a behemoth, right? That is both its advantage and disadvantage, is that its advantage is it has everyone in the world using it. And so whatever it does, it does at scale, which is awesome, right? But it can, it has the obvious capability of being able to introduce something to most of the world, of all of the agendic users in the world, no matter if they're using Copilot or not.

24:10Matt Bornstein:The question is, do they care enough to do that? Or do they have the vision to do that? Do they know? The other question is, do any of us even know what that should be, right? I feel like we're in an interesting sort of Cambrian explosion of workflows now where it's like, who knows, right? Like, and to put time and resources into doing that in a way that's very hard to pivot around is really difficult. For a startup, you know, we don't have the audience in the same way, clearly, but we can, you know, mess around more and kind of follow things faster and try to figure out, okay, this is, because, I mean, it changes every month now.

24:44Matt Bornstein:Like I was saying, the tools that we're writing, we think work, they don't work, we can ditch them, there's no, whatever, right? Like, it's fine. So it's kind of an idea of, you know, what are people going to more or less settle on and then how can you give that to the most people or capitalize on that to some degree. Like, I found GitHub's evolution really interesting because people ask, what is the next GitHub? And I find that interesting to look at from the point of view of what was before GitHub. Like, what was GitHub the next one of, right? Yeah, yeah, yeah. And it wasn't really anything.

25:21Matt Bornstein:Like, there was nothing like a GitHub before GitHub. And so I think whatever is the next GitHub is going to be the same problem set, right? It's not going to look like GitHub, right? Like, I think GitHub will be more like a source forge or something that maybe you could say was kind of before GitHub. But, like, it didn't really have collaboration tools, right? It wasn't about sharing patches or, like, track or, you know, issue tracking systems was kind of before GitHub. So, like, it just, the entire programming community changed so fast. And I think GitHub took advantage of that and was able to grow and provide tooling that nobody had, right?

25:58Matt Bornstein:And nobody was really thinking about, you know, short enough time spanning and get that audience. And I think there definitely probably will be something. The question is, can GitHub do that like the way that, you know, SourceForge couldn't or Google Code or whatever was kind of before us? or is there going to be a startup, you know, like us or like somebody else? You know, I'm sure there's a lot of people trying to do this type of thing right now because they see the need. It's just that nobody's agreed on what the solution is, right? Like where to go. And it doesn't have to be perfect. It just has to be good enough that people don't want to write it themselves and are like, okay, I'll give you some money so that I can use that instead of re-implementing it from, you know, reinventing that particular wheel.

26:40Scott Chacon:So do you, you mentioned before that the original Git developers didn't like the GitHub primitives, you know, PRs and issues and all this. Do you think now the primitives need to be re-evaluated? Do we need issues or like is there some like agent native issue format that, you know, is better than what we have now?

26:58Matt Bornstein:I think we've needed it for a long time. And it's just too much friction for too little value really to change to. like I would really prefer patch-based review rather than branch-based review, right? Like PRs made things really easy, but you get a lot of commit slop, right? Like there's a lot of oops sort of things added on the end because it's the branch that matters in the review context and it's the branch that matters in the merge context. And so the commit message doesn't make any, like nobody really looks at them. And so -

27:31Scott Chacon:Suhail once posted an old commit log and like half the messages were like, ah, this is not working. and they're like, yes, I made it work.

27:38Matt Bornstein:Yeah, I mean, it doesn't provide value that way, right? Like in the mailing list days, it did because that was the way that you reviewed stuff. You had to have a good commit message because that was your PR description, right? Now it's the PR description was not kept in Git, and so, but people don't care that much, right? Just once it's merged and out there, who cares, right? There's not a lot of sort of, you know, code archaeology or whatever that people really depend on for that. And so what I think, I think review changes a lot because we're going to, you know, I mean, like just to go back to sort of the problem with the primitives right now, PRs, if you ask, I think almost any software developer, like when you do code review, do you really read the whole PR, right?

28:23Matt Bornstein: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 or whatever, or say this is working or not working? Or do you give it a cursory glance and say, yep, fine, right? Like, it doesn't look badly broken or like, you know, you're introducing, you know, API keys or whatever, right? Like, if you can pull it down and compile it and run it and test it, and I feel like that's almost better reviews. If something doesn't work right, fine, go to that piece of the code and do it. Now agents can do this for us or can augment us in a very nice way.

28:55Matt Bornstein:I think review, it would be nicer if it was patch-based and it was local and you could actually run stuff, right? Or your agent can run stuff and then give you sort of a short list and then you can look at that. And so I think a sort of centralized online URL for a PR is something that was not the greatest. It was a better tool. I think it was better than a tracker, looking at patch files or whatever, certainly. but it's unfortunate that it hasn't evolved more, right? I think there was still a lot of room to grow in that space and it hasn't changed that much and I think there's definitely room for that.

29:30Matt Bornstein:So the question is, like we even talked internally about trying to do like our own forge, right? Or our own review system, which we actually shipped one and then kind of took it back off because it wasn't solving the problems that we really, really needed. But I 100 % think that, and I'm sure we'll do other approaches to the review system and other people will as well. I'm really fascinated where it goes. Like, what do we really need as code writers, whatever that means in the near future? Like, what do we really want to accomplish from review of code by whoever does it, right? And what does that tool look like in a way that is easy to use and easy to learn, right?

30:09Matt Bornstein:And it's a very unsolved problem right now that is, for me, incredibly fun to tinker around with. I have lots of opinions here and I want to try out lots of stuff and I want to see what feels right to me as a software developer. But there's lots of possible answers to it. But I definitely think it's an unsolved problem. I don't think the primitives are the right thing anymore.

30:29Scott Chacon:Yeah, it's sort of interesting, right? Because people are reading the code less. I mean, there's even sort of an extreme view that, you know, like, you know, JavaScript is the new assembly, right? where it's like, you know, it's there and, you know, something compiles down into it, but it's like not really, you know, so it's like if we're not writing JavaScript directly, if we're not reading JavaScript directly, like should the code review actually be code review or should it be prompt review or something else?

30:55Matt Bornstein:So right now at the state of, you know, agents and models, the way that we sort of approach stuff I think is somewhat triagey where, you know, if it's a red wristband, like if it's really, if, you know, if something goes wrong, it's bad. right then that's very human like like we look at stuff we hand write stuff like it's very important for us to essentially get the apis right like like we know if we call these apis that we'll do the right thing and it will give us the right errors or it has a like we have high confidence in in this is good code um there are sort of other levels of triage where it's not that important right if they're just calling those apis and it's a ux problem if we add a feature flag for an agent like we refine vibe coding that right and just kind of being like testing it having some you know having it write some tests look at the test be like okay that seems fine right like that seems to work run it through the eval loop it didn't you know it doesn't break anything it makes things fat 10 faster whatever ship it right like so so we we do kind of have this this middle ground but i feel like a lot even internally at get brother and with a lot of companies that are really trying to push the boundaries of this and use LLMs a lot, it's becoming much more of a writing problem.

32:12Matt Bornstein:Like, can you do a good write-up? And not every team is good at that. Like, not every software developer is good at that. Like, can you communicate? You know, I feel like a lot of developers, especially the ones who think that they're very smart or are legitimately very smart, feel like they don't have to describe what they're doing, right? Like, can live in their head and it's fine. And I think almost the software developers that would be the best producers of product in the near future are the ones who can communicate, right? The ones who can write, right? The ones who can describe. And like that is, I think, the next superpower.

32:48Matt Bornstein:And I think you're right, the collaboration of how do we write code is more important of what's the spec, right? Like what is the write-up that we want to be true? And then we can give it to, you know, The implementation details are probably, they become less and less important as the agents get better.

33:04Scott Chacon:So all of us who, you know, were attracted to engineering because we could deal with machines instead of people are now finding out that engineering is like an actual like human discipline after all.

33:15Matt Bornstein:I mean, I clearly have a huge bias because we started this saying I wrote a technical book. So I like the idea of I'm going to be the best programmer because I can write technically, right?

33:24Scott Chacon:Yeah, I mean, we've all had this thought, you know, like there are 10x or 100x programmers out there. All of us have probably thought at some point that we were one of them, which like definitionally is challenging. And so we've all had this thought of like, oh, yeah, I don't need to like explain what I'm doing. I'm right. But the point you're sort of making is like now like right is not sort of as objective as it was or there's just so much activity going on that like kind of managing state across the team is maybe the most important thing.

33:51Matt Bornstein:Yeah, yeah, or yeah, consensus, right? Like the why rather than the how becomes, I think, more and more valuable as the how becomes cheaper.

34:01Scott Chacon:What do you think will happen with coding agents in general next? Like, what do you think is the big hill to climb for them? You know, just because you guys are pretty deep in this.

34:09Matt Bornstein:As they get better, I think it's the problem set of what to work on next, right? Like, I think we're all kind of afraid of just giving it access to linear and being like, do it, right? Like, just solve all of them. And because, I mean, the other problem with that is that most linear tickets are most ticket, like, there's no write-ups, right? Like, it's not a database of write-ups of here's, like, you don't sit, it's actually very hard to sit down and write up, you know, this is how I want the entire product to look in every interesting and important aspect, right? I think what becomes problematic is you build something, you have this downtime where you're using it and trying to figure out, And, you know, I spend most of my time when I'm doing stuff right now.

34:50Matt Bornstein:And again, I'm the CEO. I'm not, you know, writing the important code. But like doing proof of concepts or coming up with ideas or whatever is I'm spending most of my time like testing it, right? And writing up the next thing and not that much. Like there's a lot of wasted cycles, right? Like I almost feel, I don't know if there's a phrase for this, but like you're not spending enough tokens, right? Like you're not having enough things working at the same time.

35:12Scott Chacon:Hey, you're the German speaker. You should have a word for this, a compound word. the token shot if quite up yeah the fear of not consuming enough tokens I think

35:22Matt Bornstein:the problem set becomes training a team to be good at writing right and and and training it like figuring out what that coordination looks like to decide like which of these series of write-ups it describes the product that we want to have and less probably less so how exactly is it is it implemented right but but that that makes things really that makes things really constrained, like the constraint moves not to, can I produce the code, but can we agree on what we want, right? And that's, I mean, it's difficult in some ways, it's easier in some ways. Like I kind of like being able to, like I've been working on this metadata system that we want to, we might talk about this at some point, but like add, like append transcripts to commits or branches or whatever, right?

36:09Matt Bornstein:And Git can't really do that very well. And so we're trying to figure that out. And so I've been spending a lot of time writing a proof of concept in a spec and it's most of the time on the spec right and like weeks or like just so much time on the spec and then every time i have a decision i just make it build it and then i try it out and then i go back to the spec and i fix the spec and i tell it okay do it again right and so that's really nice because i don't have to spend all my time implementing it and then seeing what's wrong or or telling i and i don't have to just have a write-up that i'm trying to convince you to read and agree with me or come up with problems or whatever, I can have something, I can have show and tell all the time, right?

36:46Matt Bornstein:Like I can always show you something and be like, is this what we want to productionize or not? And we have a really good idea that it is or it isn't. And I find that a really interesting, powerful thing. So I'm, yeah, I'm really curious kind of where things fall down in the long run. But right now, I mean, I'm using AI to help me write specifications so that we can by hand implement a lot of it if necessary. But we know we're implementing the right thing because we have a very good idea of what it feels like.

37:14Scott Chacon:That's really interesting. So not only will AI coding models and coding agents continue to improve, but it sounds like you're making the case that we're not maximally taking advantage of the agents that exist now, especially in a team setting.

37:28Matt Bornstein:I mean, there's so many things you could do, right? Like our agents could talk to each other. It's actually a thing that's always been, like from, it's never been good in software development is inter-team communication. Like, if you're working on some project and it's modifying a file and I'm working on a project and I'm modifying the same file, neither of us know that until, I mean, we kind of lost that with centralized version control to a degree as well. But like, I think it's obviously much better the advantages that we get. But we've lost some aspects of coordination where it'd be nicer to know that rather than you merge first and so I have 100 % of the work, right?

38:05Matt Bornstein:Like, if we could talk to each other in more real time about what we're doing, but that's a lot of overhead for, you know, but agents are very good at that, right? That is not a problem that agents have. Like it can take their downtime and can talk to the rest of your team's agents and be like, what do I need to look out for or, you know, like tell Scott about so that he can be aware of this, right? When he's working on his feature or the next iteration of this or whatever. Like I feel like that almost would be a better use of sort of the cycle downtime than trying to run five for 20 of them at the same time, right?

38:37Matt Bornstein:Which just becomes hard to manage and hard to figure out, like, is this doing the right thing or going the right direction? I feel like it's almost interesting to help it have you write or suggest things or, you know, be sort of a helper that way, talk to the rest of your team, figure out what the world of things is in that project that could affect you and give you that information so you can make decisions, right? Like, that moves towards what I think would be a really interesting way of writing good

39:02Scott Chacon:product. So this is like the smart, responsible version of using agents instead of like the amphetamine fuel just like pound as many agents at the you know repos at the same time as i can yeah i mean

39:13Matt Bornstein:also i could be biased in that i'm i've just never been able to keep enough of them running at the same time and then review stuff and then find useful data out of it like i like to have a little bit more control and yeah and so i take things slower generally but um but yeah it's it's

39:29Scott Chacon:maybe some people are really good at that right but in all of these scenarios the metadata you're talking about and like appending chat transcripts to the changes and things like that if i guess it feels like that gets increasingly increasingly important right because the like the the like focus of sort of creative control or like engineering insight is is at the metadata

39:47Matt Bornstein:layer even more than the code layer yeah i mean it also becomes a big data problem like like it you would be surprised it's all text but you'd be surprised how quickly that balloons right if you're really trying to keep every transcript or even every i mean every prompt is okay it's kind of commit message-y length, but having all the tool calls or whatever, or everything that the LLM was thinking, it becomes a really, really, really big data problem very fast, even on small projects. So now you have to go into large file, large repository. It's interesting, Git has some things of being able to work with data of the size that Chrome uses or Microsoft Office team uses or, you know, stuff that Microsoft built into Git a long time ago that most people don't use or know about.

40:41Matt Bornstein:And so we're taking advantage of some of those primitives in Git to try to do a metadata system that can scale relatively well without having to worry about it too much. But yeah, so there's a lot of interesting problem sets that are coming up with just trying to keep everything, right? Like we have version control is all about, you know, well, change management, I guess, change control, and history. Like, you want to be able to rewind, you want to have save points, like, and you have to have this balance of how much data do I store in this that has, you know, is there a cost-benefit sort of analysis there of I need all that data because then it's too much data, you can't find anything you want, right?

41:20Matt Bornstein:Yeah, it has to be indexed or searchable in some way, presumably. First version of GitBuddle that we did, we did like a CRDT-based version where it was just constantly recording every sort of file buffer save, right? Like everything you ever changed so you could just take a timeline and scrub it back to like any point in your working directory. That's amazing. And it was awesome, but, and it actually wasn't even that much data, but it was just the user interface, it was too much information, right? Like, it's not common that I want to go back 17 minutes, right? And so we kind of scrapped it because it was just too much complexity for humans.

41:56Matt Bornstein:It'd almost be interesting to re-implement some of that and have agents take a look like, if you want to get the entire working directory back to what it was, you know, 27 minutes ago, here you go, right? Like, here's a tool to do that. But I think it's still, you know, you have to figure out usability versus what's possible.

42:11Scott Chacon:I watch some of the thinking logs for agents sometimes, just like out of curiosity, and some of them are super unhinged, right? It's like, I see the problem, it's Bubba. Oh, wait, no. Oh, God, I can't believe I missed that. You know, it's like the agent starts to berate itself. And, you know, it's like, don't be too hard on yourself. Yeah, but there's super valuable information in there, right? It's just like, it's a little bit like extracting it out of this, like, junior developers kind of like private freak out.

42:37Matt Bornstein:It's a very difficult problem set because it's so, you know, I don't know. Like, I'll have conversations with other people on my team where it's so subjective. Like, they think, you know, Codex is good at this and I think Cloud Code is good at exactly the same thing. And we have different reasons why on a similar problem set, right? And we're like, okay, well, what is it? Why am I having that particular feeling? Why does it seem to be acting that way for me? And it's kind of difficult to quantify. But yeah, I find it interesting thinking about, I used to do this for the language learning thing, of trying to figure out what's the logical end of the tooling that this will eventually become, and then what's interesting or valuable at that point.

43:21Matt Bornstein:Like for language learning, we used to, you know, Google would come out with like a in-ear translation, auto translation thing or whatever. Yeah, a Babelfish. And they're like, okay, well, language learning is done, right? Yeah, yeah. And I was like, I was always like, it's a dumb argument because there's no, it's not the same, right, to have a Babelfish. Like both people have to have a Babelfish for one. And it has to be very fast and very effective and have cultural context that's very difficult. and I like to think about, okay, like what's the logical sort of end point of this? And for language learning, it was having a human translator, which, you know, I did a tour for GitHub in Japan at some point and I had this translator walk around with me in like four or a week, right?

44:06Matt Bornstein:And every interaction was through the translator and she was amazing. She was very good, but it's still not a good experience, right? Like you're not going to get married with that type of communication, right? Or you're not going to, you know, you're not going to start a business. I don't know. There's a lot of things that you don't really, it's not good, right? But that is the best possible version of a Babelfish, right? And so I always think about that because for this, it's kind of interesting. Like, what is the logical extension of how good agents become, right? Is it having the best engineer you've ever known that can stop time and work on something as long as they want and then start time again and now you have that solution, right?

44:44Matt Bornstein:Which is kind of what it is, right? Like you have the smarter and smarter and smarter people are, you know, people that can write code that can do it faster and faster. And so, but when you have that, what do you want to do with that? Like, how do you manage that time? How do you figure out, like, what tooling do you want to help you, like, figure out what you want to build and what you're happy with at the end result? And that's a very, very interesting question that we're, you know, we're getting closer to, but I still think we have a while before it's that good, right? But it will get that good, I think, or very close to that.

45:18Matt Bornstein:And so what do we do with that? This is one of the big questions in the tech industry

45:24Scott Chacon:and the big question in the world right now. I mean, what does the end state of this all look like? I don't claim to know the answer, but I'm glad people smarter than me are working on the problem. Well, thank you very much, Scott, for doing this talk with us today.

45:38Matt Bornstein:Yeah, thanks for having me, Matt.

45:39Scott Chacon:And yeah, for folks who are listening, try out GitButler, especially with the new command line tooling. Super, super cool. And for folks building startups, try out Andreessen Horowitz. They're awesome. Too kind. As a two-time Andreessen Horowitz founder, hopefully this one even more successful than the last. Thanks, Matt. All right, cool. Thanks, Scott. Thanks for listening to this episode of the A16Z Podcast. If you liked this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family. For more episodes, go to YouTube, Apple Podcasts, and Spotify.

46:16Scott Chacon:Follow us on X, A16Z, and subscribe to our Substack at a16z.substack.com. Thanks again for listening, and I'll see you in the next episode. As a reminder, the content here is for informational purposes only. Should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see A16Z.com forward slash disclosures.