GitHub’s COO Explains Why AI Hasn’t Replaced Developers

**Mike Taylor** (0:00)
Hi, I'm Mike Taylor, I'm the Head of Tech Consulting at Avery, and I sat down with Kyle Daigle, the COO of GitHub, and talked to him about what is happening on the front lines of coding agents. We have 17 million pull requests coming in every month to GitHub now, it's growing exponentially, and that puts them at the forefront of what's happening in this new economy. We talked about how that affects their users, as well as how this affects open source maintainers, and we covered a topic which is dear to everyone's hearts. How do I stop my $200 a month coding agent subscription from ballooning into a $2,000 a month usage limit? In this interview, we did something a little bit different, which is I told Kyle I had made an AI clone of him to practice the interview, and he revealed something surprising in return. Here's the conversation.

**SPEAKER_3** (1:00)
Every is the only subscription you need to say at the edge of AI. If you care about being on top of the latest models and using the latest tools, you have to subscribe to Every to separate out the signal from the noise. Go to every.to slash subscribe today.

**Mike Taylor** (1:12)
Hey, Kyle, thanks for spending some time with me at the conference. Yeah, of course. Yeah, it was good to meet you as well on the day before, and I feel like we already kind of covered a few of these questions, but I think it'll be good for the wider audience so they can understand what's going on here.

**Kyle Daigle** (1:26)
Absolutely.

**Mike Taylor** (1:26)
Yeah, so the first thing I think is, we were talking about, it's really interesting, is that the demographics of the customer are changing, right? Like a lot of people who previously maybe never used GitHub or never used developer products before are now using them. So how has that changed the way that you decide the product roadmap?

**Kyle Daigle** (1:46)
Yeah, I think for GitHub in particular, we've always really had this really expansive view of what a developer is. I started as a developer before I would have ever called myself a dev, where I was just writing code, but it was just for me and I went personally, a completely different career path. I didn't go to school for computer science. I was going to art school. I wrote code to pay for art school, which was a very silly decision as an adult now, I guess. But at that, that sort of journey of just like, I can create tools with the team and deliver them to people who can have that same experience of like, I just want to build an app that's for me or for my family, maybe as a startup, maybe as a business.
We very much have serious developer tools, all the largest businesses are using GitHub. But when I look at something like the GitHub Copilot app, I see just as many developers that are using AI every day, running multiple projects, all kinds of agent sessions at the same time, and I see our legal team at GitHub using the GitHub Copilot app, or the finance team, or I was meeting with a customer today and they were saying the same thing. A lot of the folks that the industry would call knowledge workers, or just non-by trade developers, are using these tools to build little apps or assets for them. So while our focus is very much on developers, I think we want to make it easier for people to choose, to try, to write some code, and make sure there's always an on-ramp into writing some software, now with things like the GitHub Copilot app.

**Mike Taylor** (3:26)
Yeah, and then how do you help developers deal with the burden of all of that extra? There's a flood of PRs now, like open-source maintainers I talked to are drowning. Yeah, what needs to happen to help them?

**Kyle Daigle** (3:38)
Yeah, I think for all developers, we're building tools like the Copilot Code Review. It's now agentic, so it finds a lot more novel vulnerabilities, and you can just comment, and the agent will take that on, and go implement the change if you want to. So I think that code review step is in some ways overlooked as a really great way to get PRs to a place that are much more easily reviewed.
I think that the agentic merge in the app is another place where we see a lot of times internally and in the community. You may comment on something that might have a code review, and you might go through and get it almost all the way there, but then there's all those manual steps just to finish processing the PR. Instead, I can go in and set exactly what I want to allow GitHub Copilot to do and say, okay, now go merge this PR, and wait for CI and wait for policies and all of that. I think that's a big part. On the open-source side, it's a unique set of needs because you don't control who's sending everything in, or you haven't really historically, and that's been really where we've been focusing, is giving maintainers more tools to decide, well, do you want to accept all of these PRs? Who do you want to accept them from?