“If the volume of PRs increases, then the amount of time that we spend on any given PR needs to decrease. And in order to maintain the quality of review without just saying 'forget it, let's just hit accept', we need better tools to get to an understanding of what is happening in this PR faster… The process of development is a session, but the process of review is also a session with an agent, where an agent can help you understand what is happening inside a PR and help you probe and ask questions. A code review is another form of conversation.”

Man, I don't want to say that we figured it out. I think that I think pull requests and just code review is just probably the biggest pain point for every development team. I don't want to sit here and pretend like we've gotten that stuff solved. As I'm talking, we're sitting on 40 open PRs and there's a lot of work that we have to do to figure out how PRs are going to really work for us. Because one thing that we care about, we still care about is we do still read the code. So we try to understand what's happening. We try to make sure that we can reason around these things. And perhaps that's a kind of relic of the past in some ways. And there's arguments for and against that. And it's an interesting conversation, of course. And very much, we're not trying to hold on to something that is maybe not relevant. But right now, for us, it is quite relevant. We're building product that requires us to understand what is happening at every step of the way. Andrew Lisowski pull requests are the things that we're trying are obviously all of the automated review tools we're putting in place. I think one of the things that we are, and this is kind of goes to one of the things that we're building right now, which is called surfaces, is actually just like understanding and visualizing what is actually happening in a PR in a better way…