Transcript: ‘Can GitHub Be for Everyone?’

The transcript of AI & I with Mike Taylor and GitHub COO Kyle Daigle is below. Watch on X or YouTube, or listen on Spotify or Apple Podcasts.

Timestamps

1. Introduction: 00:00:52
2. The agentic PR flood: 00:03:27
3. GitHub’s approach to helping open-source maintainers manage the surge: 00:04:33
4. What 14 billion commits means for code quality: 00:06:15
5. Moving from per-seat licensing to usage-based pricing: 00:08:03
6. Kyle’s dual role as GitHub COO and Microsoft’s chief marketing officer for developers: 00:09:45
7. Developer choice as competitive moat: 00:13:03
8. How to balance dogfooding your own tools with staying honest about the competition: 00:14:57
9. Hill climbing, frontier tuning, and solving the model-routing problem: 00:19:45
10. Kyle’s agentic communication hack: 00:24:45

Transcript

(00:00:52)

Mike Taylor

First thing I wanted to ask about—and we were touching on it yesterday—is that the demographics of your customer are changing, right? A lot of people who previously would never have used GitHub, or never used developer products before, are now using them. How has that changed the way you decide the product roadmap?

Kyle Daigle

For GitHub in particular, we’ve always had this really expansive view of what a developer is. I started as a developer before I would have ever called myself one. I was just writing code for myself, and I went down 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, as an adult now, seems like a very silly decision.

But I had that journey of realizing: I can create tools and deliver them to people who can have that same experience of just wanting to build an app for themselves or their 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 using AI every day, running multiple projects, all kinds of agent sessions at the same time. I also see our legal team at GitHub using the Copilot app, or our finance team. I was meeting with a customer today and they were saying the same thing. A lot of the folks the industry would call knowledge workers, or non-by-trade developers, are using these tools to build little apps or assets for themselves.

So while our focus is very much on developers, 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, now with things like the GitHub Copilot app.

(00:03:27)

Mike Taylor

And then how do you help developers deal with the burden of all that extra volume? Open-source maintainers I talk to are drowning in PRs. What needs to happen to help them?

Kyle Daigle

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 comment and the agent will take that on and go implement the change if you want. 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.

The agentic merge in the app is another place where we see a lot of value—both internally and in the community. You may comment on something that has a code review, you go through and get it almost all the way there, but then there are all those manual steps 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, wait for CI, wait for policies’—all of that. That’s a big part of it.

On the open-source side, it’s a unique set of needs because you don’t control who’s sending everything in, and that’s really where we’ve been focusing—giving maintainers more tools to decide: do you want to accept all of these PRs? Who do you want to accept them from? How much work does someone need to do to prove they’re going to contribute something meaningful to this project? We want to provide those tools while leaving maintainers in control.

(00:04:33)

Mike Taylor

Every community is choosing a slightly different way to approach the problem—

Kyle Daigle

For GitHub, we’ve always wanted to leave that in their hands. Give them tools and enable them, but if a standard emerges or most communities settle on a certain practice, we’ll lock that in. But we don’t really ever want to be the first to create a standard or an approach.

Mitchell Hashimoto shared the vouch system they use, and I was getting questions like, ‘Well, why aren’t you rolling this out to everybody?’ But there are just as many communities that don’t want that system because they have their own ideas of how it should work. For now we’re focusing on the building blocks of controls for maintainers, and as we all learn together and maintainers send feedback in, we’ll cement an entire system if one emerges.

(00:06:15)

Mike Taylor

I feel like you have a front-row seat to this new agent economy. You said publicly on Twitter that you’ve had more pull requests submitted per month than you did all of last year. How are those stats exploding?

Kyle Daigle

We’re seeing way more activity on GitHub. We’ve always talked about user growth, but this year we’re seeing the growth of developers building with agents. Last year at GitHub Universe in October, we shared there had been a billion commits on GitHub for the full year. We’re on track to be 14 billion if the growth were linear—which it won’t be. In March, there were 17 million pull requests created by agents. That’s just the agent pull requests.

There’s so much more code being created, and I think at times everyone goes, ‘Oh, this is all just slop—it’s code being pushed up and no one cares.’ That’s not really true. We’re all just actually getting to the point where we’re no longer in super-early adoption. We’re definitely not at the peak, but we’re climbing that hill, seeing what we can build when it’s not just Kyle building, but Kyle plus one, two, to N agents that are using my skills, using my resources, using my context, and so on. We’re investing heavily in preparing for the next wave of growth because it doesn’t seem to be growing and plateauing. It’s just going to continue because no matter what you’re building or what tools you’re using to build, all of that code ends up on GitHub, or that’s where you’re sharing it with the world, or that’s where you’re collaborating in a PR. We need to be able to support everyone’s agent moment—not just GitHub Copilot.

(00:08:03)

Mike Taylor

And how does the business model change? Freemium makes sense in a human-centered world where we go to bed. But agents are still working while we’re asleep now. Does that shift to usage-based pricing? Is that where things are going?

Kyle Daigle

I don’t think we know yet, ultimately. Right now it’s very much: Kyle has a license, or Kyle’s using GitHub.com for free. We’ve always had API rate limits and things like that, and that’s usually where folks are seeing the agent back pressure.

The goal is that if you want to do way more—if you want, as Peter Steinberger says, 150 agents doing everything all at once—great, we want to enable that. But at the same time, I want you to have a great core GitHub experience, and at the very least there’s some amount of agent usage as part of that that’s necessary.

It’s similar to how way back you’d have free public repos but not free private repos. Then we said, ‘Okay, it’s fair for an individual to have some code they don’t want to put into the world, and we’ll give you free private repos.’ GitHub’s always evolving as the industry and community does. But we’re always focused on: I need to make sure you, the dev, have what you need to be successful—and then work with enterprises to make sure they have what they need at scale, which is usually a little bit different from what an individual dev is doing.

(00:09:45)

Mike Taylor

The business model and pricing all leads back into the wider Microsoft orbit. You now have a dual role—partial responsibility for the wider marketing org as well. Can you talk through how that’s changed and how you prioritize between the two?

Kyle Daigle

I’ve been at GitHub for 13 years—as a developer myself and leading engineering teams for a lot of that time. What’s always been unique about GitHub is we really, really focus on the developer. We’re building tools for developers, and the fact that enterprises are buying them is awesome. But we’re not building for the buyers. We’re building for the developers.

That’s been my focus as the COO of GitHub, and now as the chief marketing officer for developer at Microsoft, my goal is to look across all of Microsoft’s tooling—their developer tools, the technology they’re bringing to developers—and make sure we’re bringing holistic solutions that are authentic to developer experiences. At events like this, we’ve taken a very different approach to Build this year. We’re in San Francisco, first off. The vibe is a bit different from the conference hall setup. It’s really focused on: Can I go to a session? Can I use the thing? I don’t want to be pitched on a thing—I have to be able to use it. It’s bringing that expertise and love and focus on the developer that GitHub’s always had to have an even broader impact throughout Microsoft.

Mike Taylor

Did I hear you say this is the first Build that’s had external contributors?

Kyle Daigle

It’s the first Build that by intention we’ve focused on having speakers from the community in these primary sessions. That includes the keynote, where we had a bunch of folks like Peter. There are sessions from Swyx and others as well.

I think it’s important—software development is a team sport. It seems silly to think there’s any one company, one group, inclusive of GitHub and Microsoft and everyone, that can answer every single question. That’s not how software gets made. We’re all at least using open source and building on the backs of these giant open-source projects. Let’s invite people in who can help tell their part of the story, because I deeply believe that’s what developers want. I know that’s what I want. I know that’s what my friends who are developers want. When we look at the events and hear the feedback, they’re excited to see people from Microsoft, from GitHub, and then, oh, I also get to see this outside perspective at this event.

(00:13:03)

Mike Taylor

It’s a very competitive market—maybe the most competitive market. How do you differentiate given the pace of change is so quick?

Kyle Daigle

We continue to focus on our roots, which is that we care a lot about developer choice. It’s always been true. We care about building for builders and enabling builders. We’re in a moment that’s really interesting because we went from an era of having a ton of APIs and all this access to—kind of unintentionally—a walled garden setup. Where you get a certain affinity, sometimes I’ll call it a little bit of a mousetrap, and then you realize, ‘Oh, this thing is really interesting over here,’ and then you have to go learn a new tool or create a new account.

For us, we always want to enable developers building with GitHub to go use other tools, and we’ll partner with everyone to make that as simple as possible. I think the ability to do that across the entirety of building software—not just the code-gen side or just the collaboration review side, but across everything—is a real superpower of ours.

You’ll see us invest in our own tech, like the new Microsoft AI models that we’ll continue to bring to developers. We’re also continuing to partner with Anthropic, OpenAI, Google, and anyone bringing a model to market or a coding agent to market. We’ll partner with them and let you bring that to us, or we’ll surface it through GitHub and GitHub Copilot. That choice is core and something I don’t think we’ll ever back down on. Because if we do, developers will still choose—they’ll just be stuck in another mousetrap, and we don’t want the world of software to be like that.

(00:14:57)

Mike Taylor

When you’re making decisions internally—there was a news cycle recently about Claude Code licenses being canceled—how do you make the trade-off between dogfooding your own products, like using the new models you made or the GitHub Copilot desktop app, versus letting developers experiment with other tools?

Kyle Daigle

We all use a variety of tools, because otherwise you lose track or you get too focused on your own work. For me personally, I’ve been a daily driver of a MacBook for many years. I use Windows PCs on weekends when I play video games. When I got this role, I set up my Mac, my PC, and an Omarky Linux box so I can make sure that every weekend—I code most Saturdays, I do my kids’ sports activities in the morning and then in the afternoon I’m coding—I’m swapping between the boxes because I want to understand each experience.

I only use the GitHub Copilot app on Windows because I want to make sure that developers on Windows also deserve great apps—not just the audience on a Mac. That’s true across our teams, especially when we’re looking at coding agents, harnesses, desktop apps, memory management, everything. We have a really great culture of just experimentation. Everyone is building and using these tools.

While we’re obviously putting most of our energy into our own tools, it’s such a blind spot if you don’t look elsewhere. It’s happened to GitHub in the past—when you’re doing something well, you laser focus, and that’s what every piece of startup energy says: look down and just keep moving fast. I think that’s myopic. While I can’t spend every day using every tool, when something comes out, I want to know why it’s great. Why are people having a great experience with this? Not only so I can understand, but so I can figure out: for our goals, for our goal of developer choice, what do I need here? I want to know why a dev would pick these tools.

Mike Taylor

And how do you filter? Because a lot of these ideas are relatively short-lived, and enterprise product development cycles are longer-lived. How do you decide?

Kyle Daigle

Right now we’re in a moment where we’re really looking at the short term and capturing the ability to have a multitude of agent sessions. This idea of just—because it seems quite clear—everyone’s doing it. How can we cement it?

But it seems clear on the longer-term path that models are going to continue to get better. Token economics are going to be a bigger factor in what models everyone is using. I strongly believe we’re not very far off from having serious ability to use something above a small language model on a local device to do some of our work.

If I assume I have all this optionality when it comes to tokens, the thing that seems to be true from the beginning to Claude to now is this idea of personalization—mine, context, fine-tuning with context, memory. All of these ideas seem to be a truth that’s been there since ChatGPT came out or GitHub Copilot came out. There are experiments, but not a long-term vision for this across the industry.

I think it’s a good example of where I need to get you to use agents incredibly well, a lot of them, because if you’re into using agents you’re not just going to be staring at a single agent working. But that’s not going to give you a long-term great experience. Using an agent that you feel like is completing a thought for you will give you that great experience, especially if you did not have to personally codify that thought. Always remember that I insert that thing, you know? That’s a lot of work. It should be able to intuit that—or potentially post-train, fine-tune, or frontier-tune a model that deeply understands me and how I’m using the work. Sometimes it’s short term, and sometimes you have to take a bunch of attempts at the long term to get to something really tangible.

(00:19:45)

Mike Taylor

I heard the term ‘hill climbing’ about 100 times yesterday. I’m a big proponent of it—I’ve experimented with DSPy, Auto Research, a few others. Can you talk a bit about how that’s become such a big focus?

Kyle Daigle

Satya and Mustafa talk about it a fair bit, and Jacob too, leading the Copilot group. The biggest thing we’ve learned is we need to use the actual use of the tools as a core way to improve the underlying use of the models and our own models—the evals that are necessary to ensure we’re actually improving, from things like using thumbs up and thumbs down data to whether you’re accepting a suggestion and how much you’re accepting.

All of that data is enormous in creating a magical type of experience—not just for you, but for everyone. So every week we’re talking about the hill climbing results. We’re looking at the data, the improvement, both the hard measures and the soft measures—because sometimes the hard measures and evals and rubrics will show that we’ve made an improvement, but user sentiment will crash. Even with the same latency and performance.

Mike Taylor

That’s overfitting, basically.

Kyle Daigle

100%. Being able to do that loop incredibly quickly is the goal, and then the main goal is giving everyone one of these hill climbing machines and not having you do it the hard way we’ve all been doing it.

Particularly if you’re in an enterprise and you’re using Microsoft 365, we know so much about that data—or could know so much—because of all the assets, all the documents, the chats. Being able to turn on something like frontier tuning and using MAI Thinking 1 as the base model shows real results without having to do all that extra work. And it’s been interesting because when I first heard about this, I’ll be honest: I was like, ‘This is like a magic parlor trick that is not going to be real.’ But the reality is that sometimes where the alpha is, is where it feels like this is too simple to work. We all have all this data, and what are we gonna do with it? We have to do all this effort to make it work. But so much has come down the pipe to allow us to just use the data and improve, look at the workflow and improve, and keep doing the hill climbing.

That’s why I think we say it so much—it’s not these moonshots. It’s climb, climb, improve, new eval, improve, new data, improve, and just keep going to get to the point where we’re able to launch these models for ourselves. Then allow customers to use the same or similar tooling to do it.

Mike Taylor

Is that the answer to stopping the $200 subscription from becoming a $2,000 subscription?

Kyle Daigle

I think the $200-to-$2,000 problem is going to be addressed not only by frontier-tuning models so they know you better, but really by helping developers automatically choose the right models—potentially having a model in that step, like the model router in GitHub Copilot. Microsoft Foundry has a model router as well that can do this at an API level.

The more we can help you tell us where your bars are—like, this is an incredibly hard problem and I’m willing to go all the way to the top, or I just want to sit here—and let us help choose the models, the better. Because a lot of the reason tokens are expensive is that we’re all going and choosing our model of the day or week or hour, and those models are incredibly expensive.

My train of thought is slipping in and out of a hard problem to a simple problem. I’ll personally get an agent to do an enormous amount of work, and then there’s always that last step that’s a small thing—like, ‘Oh, just change all the naming of this to that.’ That’s a find and replace. Am I going to actually go save tokens by switching down to Haiku or something? Probably not. But the tools could. And that will really help us, particularly in the enterprise—but even for individual developers and folks building automations using the Copilot SDK to power that.

(00:24:45)

Mike Taylor

I did something a little bit weird. I hope you don’t find it creepy, but I made an AI version of you to practice this interview.

Kyle Daigle

No way.

Mike Taylor

Yeah, and it’s actually been pretty spot on so far, and hopefully you think the questions have been good.

Kyle Daigle

They’ve been great.

Mike Taylor

It’s just in the terminal—I didn’t go the full whack and make a video thing. I’m a bit shy. But I found it immensely useful. I wanted to ask: what other weird things are you seeing people do internally or externally?

Kyle Daigle

It’s so funny you say that because I do a very similar thing. I have both, via the app and then I have a Claude that can’t talk to work stuff—just so I have separation of state. Where I spend a lot of time having it read everything I write and say. This interview will get fed into it ultimately. And every day I get a comms report that’s not like, ‘What Kyle said,’ but like—‘Kyle, you keep saying this.’ ‘This isn’t super clear.’ Based on how you speak, because I find that I write and speak in a very particular way—I want to use a lot of metaphors. So it’ll just give me examples of metaphors that are clear.

I find the self-improvement loop as a human, from these agents, to be incredibly powerful. We used to talk about it way back with Hubot at GitHub, like ChatOps. We used to say: humans are way more willing to take critical feedback from robots than from other humans.

Mike Taylor

It’s less threatening.

Kyle Daigle

100%. And when my Claude instance—which I affectionately named Baxter—tells me how terrible I did at something, I feel way better going, ‘Tell me why.’ And then ensuring that when I’m writing emails, writing a script, or reviewing details, it’s giving me that feedback. So a lot of my agent loop is really about me and less about the software side. I still have all those tools too, but it’s always looking backwards—‘Okay, the last seven days, read all Kyle’s emails and Slack messages and give me feedback.’ Then look back at what the agent told me to do, did Kyle do it, and go back another seven days. That loop is super powerful and I think, honestly, the type of personal consumer experience I want out of AI—to be able to tune these tools that way.

Mike Taylor

We need to recursively self-improve as well.

Kyle Daigle

100%.

Mike Taylor

Thanks so much, Kyle. I appreciate it.

Kyle Daigle

Enjoyed it.

Mike Taylor is the head of tech consulting at Every and a co-author of Prompt Engineering for Generative AI (O’Reilly).

To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.

For sponsorship opportunities, reach out to [email protected].