GitHub CEO: The AI Coding Gold Rush, Vibe Coding & Cursor

Matt, thank you so much for having me.

That sounds good. Sounds great. Yeah. And it's also, I think, one of the oldest use cases for AI.

$7.5 billion seems cheap now that we're in 2025 and you see all these startup valuations. I think Microsoft has always seen itself as a developer tools company. It's a platform company, and to be successful with a platform, you need to have developers on your platform that build apps, services, products on top of it, but also build an ecosystem around the platforms. And Microsoft, back 50 years ago, started with a BASIC interpreter for the Altair. And then you fast forward, and in the 1990s, Visual Studio came.

.NET and that ecosystem. And in 2018, a lot of things had changed under Satya Nadella, Microsoft's current CEO, who came into the role in 2014, had changed that. Microsoft started embracing open source. .NET was already an open-source project. VS Code, the editor, was already on GitHub and, in fact, one of the biggest projects on GitHub in terms of number of contributions. And so we felt it was time for Microsoft to fully embrace its roots as a developer company and bring in all these web developers, those that are building apps, what's now called cloud-native, and bring them into the Microsoft ecosystem.

So I think that was the primary motivation: bring those developers that are on GitHub, that are building in the open, or on startup projects, their private projects, and increasingly in the enterprise, as GitHub, in the late 2010s, more and more also embraced the enterprise and started selling a server, GitHub Enterprise Server, and a business product in the cloud. And so bring that into the Microsoft ecosystem. And two years before the GitHub deal, the LinkedIn deal had happened. So in 2016, Microsoft had acquired LinkedIn and had kept LinkedIn somewhat independent from the big mothership.

And so we also had a template of how to do such a deal where we retain a lot of the value of the deal by keeping the company independent. And the three principles that we set back in 2018, they're actually still true today, which is GitHub always puts the developer first. And so that's what drives all the decisions, the design, the product processes, how we think about marketing, blogs, our conference. We have Microsoft accelerate GitHub, and I think that is a crucial part of how everybody should think about acquisitions, which is the buyer should accelerate the target company.

It's almost like a venture capitalist investing into a startup, right? You invest money to accelerate the company you're investing in. When you're acquiring companies, I think you should have that same mindset. I'm buying a company to accelerate them so they increase their value, and as such, I'm increasing the value of the buy side. And then lastly, we also thought about GitHub accelerating Microsoft. And here we are in 2025, and the easiest example I can give you of how GitHub accelerated Microsoft is, of course, GitHub Copilot.

The Azure business within Microsoft came out of a division called Server and Tools. Today, that division is called Cloud and AI. And the Server and Tools team also had the developer division, with its core product back in 2018 being Visual Studio, the old-school IDE, in itself a billion-dollar business, and had a bunch of new stuff like Visual Studio Code. It had a platform for DevOps, back then called Visual Studio Team Services, nowadays called Azure DevOps.

And so that tools division within the cloud, within Azure, had the job of providing the ecosystem, the tools, the platform for developers to build on top of Azure, to build on top of Windows, to build on top of other Microsoft platforms. And GitHub snapped into that developer division, bringing basically the open-source platform, the home of all developers, into that same ecosystem. From a business perspective, that meant the GitHub revenue became part of the Azure KPI that is reported in earnings calls every quarter for Microsoft.

And we announced last July, so almost a year ago, that GitHub had passed $2 billion in annual revenue run rate, ARR. And you can go back in time: 2017, a year before the deal, the GitHub leadership team had announced $200 million in ARR. So those are not exactly snapping to the timing of the deal, but you get an idea: between 2017 and 2024, revenue went 10x, right? And as such, the first thing I want everybody to think about when you ask, how is GitHub contributing to Azure?

Well, it contributes to Azure's revenue number by increasingly generating more and more cloud revenue. And of course, Copilot is a big part of that cloud, or an increasing part of that cloud revenue. We bring developers, new developers, students, even high schoolers, sometimes even middle schoolers, and increasingly younger kids as well. Often the motivation is actually less that they want to learn coding. That is also true. But I was in one of my son's middle schools last year, and I asked them about GitHub, and they're like, yeah, that's where we find an old Minecraft build that works on the school laptops and isn't detected by IT, probably because it runs on some older file that isn't fingerprinted by school IT or what have you.

But it brings developers into the platform, into the Microsoft ecosystem, and the ultimate hypothesis is that they go through their career journey on GitHub and learn about Microsoft tools, whether it's VS Code and Visual Studio, whether it's the cloud and Azure. And of course, we have within GitHub a number of integration points where you can deploy your repository to Azure, and through something called GitHub Actions, our CI/CD service, where it suggests the Azure Kubernetes Service, for example, to deploy a Dockerfile.

It's the other way around, which is the Azure teams obviously also leveraging GitHub for their work, whether it's GitHub itself, whether it's GitHub Copilot, GitHub Actions, all the open source on GitHub, consuming that, contributing back to it. So when we think about developers at Microsoft and developer tools at Microsoft, we should also think Microsoft is one of the biggest software development companies itself. So it benefits from every innovation that we're building into GitHub for its own backlog, for its own shipping velocity.

Quality, et cetera.

Tying it back to the acquisition, one story I can give you is that beyond all the other reasons I gave you that were part of the strategy document that we had to write to send it to Satya, and then for Satya to go to the Microsoft board and ultimately get approval for the deal, one additional thing was in fact AI and saying, we believe there is a future where we can train AI models on the graph, is I think what we called it, of all the source code that is stored on GitHub, but also on the relationships between the developers, how they work together.

And so in 2018, obviously, we didn't know anything about Copilot. But AI was certainly a reason to do the deal. Comes 2020, and in the meantime, Microsoft had invested into OpenAI. I think that was in mid-2019. And GPT-3 was on the horizon. And we got early access because of the partnership between Microsoft and OpenAI. And we played with the model, just like today you play with a new model whenever a new one comes out, which feels like it's every other day.

And we asked it to write methods like prime number detection, sorting algorithms, those coding exercises, if you will. In fact, through that process, we looked at our own coding exercises that we use for our interview loops. And I think we collected about 230 or so of them and ran them through the model, which then was called Codex. So OpenAI fine-tuned a model based on the open source code on GitHub and other sources. And I think there's a paper still on arXiv, or whatever the page is called, that describes exactly how Codex was trained.

I think the model was able, with multiple attempts, to solve more than 90% of these coding exercises, of these 230 coding exercises. And that ultimately gave us the confidence we can build a product here. So this is 2020, two years and a bit before ChatGPT. But actually, conversational coding was one of the ideas we had. And the only reason we didn't ship that was that it wasn't good enough. And we were quite skeptical of shipping something where everybody looks at this and asks in a chat interface, describe this method, or asks the typical chat scenario that we are all now used to.

And it often gave incomplete answers or wrong answers. And so we felt like we can't really do this and ship this to developers. We're going to get all the ridicule on social media. The other thing that's easy to forget is autocompletion has been around forever. Microsoft, I think, shipped IntelliSense, which is like the somewhat intelligent autocompletion, in the 2010s. And in fact, even that was debated by developers because the worry was that if it can predict the next word in the method name, I have, I think the term was, brain rot.

I'm going to forget my skills. And so that question of, is AI going to replace the developer and make us all less skillful, at a lower level of craft? That goes as far back as IntelliSense. And I remember first using TextMate in 2004 or 2005. And it felt magical to me that it could autocomplete even stuff that wasn't in a Ruby on Rails app, that wasn't even in the documentation, because it would parse the file and create a dictionary of the file I'm working in.

And so it could predict the method name that is actually part of the code I wrote. And then Microsoft evolved IntelliSense into IntelliCode, which was IntelliSense with AI using a local model to do better predictions. So that was already AI. It just wasn't a large language model, a transformer model as we used for Copilot. But all these steps ultimately set us up to ship Copilot, the original Copilot, in June 2021, more than a year and a half before the big bang of AI.

And then we brought that into production within a year. And it feels strange looking back now to summer 2022, three years ago, when Copilot GA'd, and how many people were still doubting that this technology is any good and will become a standard tool for developers. And here we are in 2025, and all of that has happened. And you see many CEOs in AI and outside of AI predicting these copilots are going to write 90, if not 100%, of all code.

The way I'd like to start describing what GitHub Copilot does is to describe what a developer job actually is, which is writing code. And so most developers in the morning, they go somewhere where they have their backlog, the tasks that they define themselves, or often that comes from their manager or from their product team. They pick up a task, and then they go into an editor, which is ultimately a program where I can edit files with plain text. And the key skill of a developer is to take this description that is in human language, because that's what all the specs, all the issues, all the bug reports are in, right?

Like, they're in English, German, French, whatever language the stakeholder used. The key job of the developer is to translate that language into code, and to take human language and transfer it into programming language. And so, they type code. And as any writer, whether it's a coder, or whether it's a journalist, or a VC writing a blog post, it's really hard to do that because you're getting stuck when you have an empty file. You're getting stuck because you don't remember specifically how to call a method or how to do a certain algorithm connecting to some backend system and so on.

And so what you did before Copilot was Command-Tab or Alt-Tab on your computer into a different application, often the browser, and try to find that information. And you do that by opening a new tab and using Google or Stack Overflow, GitHub, lots of platforms, Reddit, that have developers talking about these problems and then figuring out what's the answer to the problem I'm trying to solve. And 10, 15, 20 minutes later, you're back in your editor and you copy and paste that code snippet that you found somewhere, and then you make it work within the file that you were working on.

And so Copilot does all of that without that context switch. It keeps you in the flow. Developers often call this the magic flow state, where you have an idea, you know what you're doing, and it's just flowing from top to bottom in the file, and it feels like you're changing the world. And you want to stay in that state for as long as possible. You want to surf the wave, if you will, without falling into the water and having to paddle back and find a new wave.

And so Copilot, the original Copilot, did that by suggesting multiple lines of code. Instead of just the next word, it could complete five, 10, 20 lines of code. And you would just accept that with the Tab key, or you would keep typing until it was good enough for you to say, okay, I can now press Tab and then edit this a little bit to make it work, because most developers also are very used to trial and error, trial and error.

That's how we all learn coding. And so Copilot does that autocompletion, and that continues to be the most used feature because it is always there. The magic of Copilot in the early days was that it wasn't really about AI, it wasn't about large language models, it was about giving you a feature in your editor that keeps you in the flow state and makes you more productive and ultimately more happy. And then came ChatGPT. And of course, we added the chat scenarios.

And that allows you to do all kinds of exploratory things, like asking questions and describing code, telling the chatbot to fix a bug. And I bought both my kids a Copilot license because before they would always come to me and say, "Hey, if I need—"

I pay for them, of course. That also let me test the payment and the billing flow. And so I get three emails from GitHub every month, one for my own account and then one for each of my sons. And so I'm customer zero, as we would call that. And before that, they would come and say, "Hey, I'm building this Python Pygame, a little jump-and-run platformer, and I have a bug and I can't figure out how to solve that bug."

And then I was like, "Well, I'm talking with Matt right now, but I'll come to your room in an hour." And of course, they don't like that because their stuff is way more important than your podcast, Matt.

And so I bought them Copilot. And now they're just asking Copilot, "Help me to fix the bug." And it doesn't have to be perfect. I'm not perfect either when I help them, right? I try to understand what they did. So does Copilot. And so that's the second scenario. And then the third one, and that's really what 2025 is all about, is agentic scenarios. We call it agent mode in the IDE. We have the coding agent on the platform where, instead of just asking questions and getting answers, you can give it tasks and it does that task for you.

In 2024, we did two things. GitHub Models was early August, and that gives developers access to a catalog of models integrated into the GitHub platform. And in fact, last month, in May 2025, we brought these models into the repository. And so you can integrate these models into your repository to build AI scenarios into your own applications. And that's really cool, because you don't have to go to another place and sign up for a new account. And then you have your model stuff here and your code on the other side.

GitHub ultimately was always about millions of developers collaborating on a project together. And so our philosophy is we bring what we call the primitives that developers need into the repository: issues, wikis, pull requests, actions, and now models. And then late—I think it was late October—we announced multi-model choice for Copilot, moving from just having one model provider, OpenAI, to having multiple model providers for Copilot Chat and, for now, Copilot Agent Mode. Claude 3.5 Sonnet, and now it's Anthropic Claude Sonnet 4 and Opus 4.

GPT-4.5 Pro. And what really it is about is choice. We fundamentally at GitHub believe that we need to offer developers choice, right? You wouldn't be using GitHub if it only had one open-source project or one programming language or one ecosystem. Node.js or whatever the next thing in the JavaScript ecosystem is, whether those are the ones to pick. We are offering all these projects a home where they can collaborate and innovate. And we let the developers, teams, organizations choose which of these ecosystems they want to participate in or consume.

And we believe the same is true for models. There is never going to be one single model that rules them all. But the world of software development is just way too broad for this. And that's also, I think, where the benchmarks—is the right word—are dangerous, I guess. Because, of course, there's a big difference between writing code in C, C++, or even assembler, to writing code in TypeScript or Python. And often, if you look at these benchmarks, the devil is in the details.

You have to do the double-click and see: how does it do for my language, for a documentation scenario, or for a test-generation scenario? And in fact, nowadays in VS Code, we not only have the models that we offer on our inference API, we also have bring your own keys. So you can connect Copilot to OpenRouter or Ollama. It can run a local model and try out that model in Copilot to build your own agentic behavior into your developer workflow.

And so that's what it's all about. And that also enables us to move really fast, which has become incredibly important in the AI space. I've never seen anything like that in my 30-year career as a software developer. There's so much innovation, so much change happening, that just sticking with one model will ultimately mean you either are really, really good at change management with all these tens of thousands of enterprise customers—that's the hard nut to crack—or you offer the choice, and then the enterprises can stick with the model that they feel is the one that is the best for them and approved and reviewed by security and compliance and all that.

And then there's all the other models that we can offer other customers and individual developers, those that want to stay at the cutting edge. So that's the other part of choice being important. If you want to move fast, you ultimately have to support multiple models because there's always going to be a group of customers that intentionally want to move slow, given the regulated environment they're operating in.

We do not today. We have pursued that path in the past. So I think in 2023, 2024, a number of companies in our space saw fine-tuning as the next opportunity. The challenge from my perspective on fine-tuning is that, A, as there's another model every other day, you're ultimately always going to be behind with your fine-tuned model. And we are putting you then in a position where you have the choice between the model that you fine-tuned that is based on an older version of the base model, or you can pick the new model, but that isn't fine-tuned yet.

B, I think most customers' codebases, especially if you look into the individual project, most companies that are at a certain scale have not just a single programming language and a unified stack. That's the dream every CIO or CTO is talking about, like, I want a standardized stack for all my developers. And then you look into a 30-person startup, and of course, even they don't have that, because as soon as they go from web development to iPhone development to Android development, they already have three stacks.

And so then if you look at the individual repository or set of repositories, that code isn't actually big enough to have a meaningfully fine-tuned model. And lastly, I think this is where fine-tuning kind of got left behind by most companies in the space, is that when customers think about fine-tuning, what they really mean is that the agent understands the codebase and the environment that that codebase sits in. But that's not only the code that was relevant during the fine-tuning process, because you can always have a new open-source library being added, or you're upgrading from one React version to another, and now your API changed, or from one Java version to another, even simpler.

But it's also everything else that's surrounding that project: your database schemas, your whatever solution you're using for feature flagging and experimentation, right? There's all these services that surround your project that provide additional context that the agent needs to know about. And so now in 2025, I think the answer is very clear, which is MCP, Model Context Protocol, and tool—the ability for models to call tools. And so they can call tools on the command line to install a Maven package or an npm package.

They can call an MCP server that connects into your GitHub repository or into your Jira and Confluence institutional knowledge. And then there's 1,000 MCP servers for everything else. So if you want to connect to Figma or you want to connect to your MongoDB database or what have you, you can put in all that context. So the agent actually knows as much about the environment that the codebase sits in as the human developer. And so using MCP, using tool calls, and then whether it's retrieval or just navigating the file tree and doing code search like a human developer does.

And if you have used agent mode or any of these agent modes, you can actually see that working, how it uses the chain of thought to go from, okay, there's three files, or maybe I need to add two more files. So now it has picked five files that it needs to modify. And it figures out that it not only needs to write the code, but also write the test cases for it, and then run the tests and fix it itself. So this iterative process that the agent does with the help of the tool calls and all the context makes it so much more powerful than a fine-tuned model could ever be.

First of all, I think we should recognize how amazing it is that a developer tools company is the fastest-growing startup of all time. Because there were times between 2018 and now where you would go to a startup founder or a venture capitalist, and they wouldn't want to invest into that space. A hundred percent.

There's no money to be made. And here we are. And second, I think it shows that AI is going to accelerate the role of the professional software developer. And it's also going to enable everyone that wants to become a developer to learn coding. And you can see that with Copilot and a bunch of these tools: Vercel, v0, Bolt, Lovable, OpenAI Codex, where folks with a non-technical background can build a quick webpage. Now, and I think this is good to anchor ourselves, we have been living in a world for quite a while where companies were pitching no-code or low-code solutions.

In fact, I think 15 years ago, I set up my first Squarespace webpage. And even though I knew how HTML and CSS work, that was still the faster and cheaper way to just spin up a quick webpage and publish, I think it was the landing page for our startup back then, and just say, here's the signup field. Let us know if you want to get informed when we're launching. With AI, we're going a step further, because now you can use AI agents to generate quite complex applications, from webpages to little games.

My favorite demo is to build a Snake game, because it's quick to build and quick to play without explaining too much how it works. Most people still remember Snake on their Nokia phones, or whatever phone they had. And so if you look into the space now, you have companies that are working in this bootstrapping, or we like to call it greenfield, scenario. You start with nothing, you enter a prompt. It's almost like using an image model: you enter a prompt and it generates you an image, but instead of an image, it generates you a webpage, an application.

And then you either like what you see, or you want to add more or change things, and you keep prompting. And in fact, the image model is a great, I think, comparison, because in the same way that the first output of an image model almost never is perfect and exactly what's in your head, the same is also true for these bootstrapping AI scenarios. So that's, I think, one category. One is IDEs. You already mentioned one. There's a bunch of others that have taken VS Code, forked it, and made it a new version.

And that's the power of open source, right? The power of open source, of Microsoft making VS Code open source 10 years ago, in 2015. But there's also the traditional IDEs: Visual Studio, the JetBrains family of IDEs, even Apple with Xcode. Everybody is integrating AI scenarios into these IDEs. And many companies like ours are providing Copilot not only for VS Code and VS, the Microsoft IDEs, but also for JetBrains, for Eclipse, for Xcode, for Android Studio. And then there's forks of our codebase to bring it into Emacs and what have you.

So, the IDE is the hardest playing field, I'd say, simply because that's where the majority of professional developers are. And the key of successful developer tools has always been, you've got to meet developers where they are, and then move them into that future that you're seeing as your North Star. But what doesn't work is to give them the new thing and tell them to stop everything that they're doing until now. That's going to create an allergic reaction, like, go away, I know what I'm doing.

I'm used to my shortcuts and my color schemes and all these kinds of things. Then there's the model companies that provide the models that power all these scenarios. But they have entered the space itself, whether it's OpenAI Codex, Claude Code, Mistral Code. And I think part of the reason for that is that AI code generation is a scenario that worked first and has the largest part of the respective workforce having adopted it, as in most developers have adopted some form of AI tooling into their workflow already, while other knowledge workers, other white-collar workers, are still early in that adoption journey.

And they might use a chat agent as kind of like a better version of a search engine to find a document or to summarize an email. But they haven't replaced parts of their workflow with AI. Which brings us to the fourth category, which is agents. And these agents, what separates them from the bootstrapping greenfield scenarios is that these agents work in brownfield, as in they are working within an existing codebase for the coding agent, or within your Azure cluster to monitor all your resources, the SRE agent, and then look at exceptions or monitoring data and then file a GitHub issue and say, hey, the latest deploy has created an exception.

And you can tie those together and have the SRE agent file an issue, and then the coding agent pick up the issue and provide the pull request, and then the human developer comes back in again to review the code change. What's interesting about these four categories is that while there are startups in each of them, there are also companies like Microsoft and GitHub that operate in all of them and try to provide a holistic platform across all these scenarios. I think the key for winning is to have a continuum where you can have an agent write code for you and submit a pull request.

But then if you, as a developer, see that code and you want to make three quick changes, you've got to be able to take that onto your local machine and just make those changes instead of trying to figure out how do I provide now feedback or a prompt to describe in natural language where I already know how to do it in programming language, right? That's basically replacing something that I can do in three seconds with something that might potentially take three minutes or even longer.

And that's obviously not more productivity, that's less productivity. And so enabling developers to move between those categories and being able to pick the agent that provides the best ROI or do it themselves, I think that's the key for winning in the next few years.

It's the DNA of Microsoft to be competing and partnering with many companies in the industry, right? The most classic example that comes to mind is that Microsoft, for the longest time, has sold software or provided software nowadays for the Mac, going back all the way to the Apple II. I think most of us remember Bill Gates appearing in a Steve Jobs keynote, big on screen behind him, to announce that Microsoft is investing in Apple and bringing Internet Explorer and Office to macOS. And then, of course, after Satya became the CEO, the decision was made to bring the Office suite onto the iPad.

And nowadays, we take it for granted that Office, Teams, Outlook, all the modern Microsoft applications run on a Mac and run on iPhone and Android. And as such, I think, and I learned that when I joined Microsoft 10 and a half years ago, it was weird as a startup founder to come into the company and realize that what I considered competitors for the product I owned at Microsoft are often also partners. I can't name any names, but many of these AI code generation companies that compete with GitHub Copilot are running their inference on Azure AI Foundry.

And as such, they're paying Microsoft for the lower parts of the stack. And obviously, Microsoft's cloud business with Azure doesn't want to say to customers, "You can't run on us because you're competing with one of our products." We have so many products that that would hurt Microsoft's business. So it is part of our DNA to both partner and compete. And I think, in many ways, that is the incredible thing about the tech ecosystem, that that is possible. Meta, AWS, Google, they're also all hosting their open source on GitHub.

And as such, they're, in one form or another, GitHub customers. And so we really enjoy being on both sides of that spectrum. And I think it increases the energy that we have within Microsoft and within GitHub to say, okay, we'd love to partner with these companies. And developers, in the developer space even more so, because, like, look, if we would just exclude parts of the ecosystem, that means those developers go elsewhere and pay for a subscription or do their business with somebody else in the industry.

Instead, we see ourselves as part of an ecosystem, with GitHub hopefully being one of the bigger planets, one of the Core planets, in Star Wars. But there's a huge system, Mid Rim and Outer Rim, to stay within the metaphor, and companies that are closer to us and sponsor our conference and have active partnerships and are building active integrations, even though they're competing. Devin, as one such company, comes to mind. And others that are farther away, but obviously still a part of the developer ecosystem and that integrate with GitHub, use GitHub identity, or store their source code.

And so, if you take it back to AI code generation, all these companies ultimately allow a developer to submit a pull request or have the agent submit the pull request onto GitHub. And as such, we have to be partners to enable those customers that pay us money for their repository, for their pull request, to choose the tools that they want to have as part of their platform stack.

Not at all. And the VS Code team, while they don't report into me as the GitHub CEO, they are part of the developer division that we are also part of. And together with the developer division, we are part of an organization within Microsoft called CoreAI that has the whole AI stack in it as well. And so, under Jay Parikh, who is the leader for CoreAI, we are forming one unit that competes in this age of AI with all these companies across the categories that I lined out.

And as I mentioned, we're also partnering with them. So a different part of the CoreAI team might have one of our GitHub competitors as their customers and have partnership meetings with them and negotiate deals and Azure spend and those kinds of things. Coming back to VS Code, at Microsoft Build in May, we announced that we are open-sourcing Copilot within VS Code, which also means we're moving it from an extension, which is how Copilot originally started, into a core part of VS Code.

And so it becomes open source as part of the VS Code open-source project, or the Code - OSS project. And as such, the VS Code team, and that's been true for a while, is actually the one building the client side of GitHub Copilot. And so, for, I think, the last two years now, the VS Code team owns GitHub Copilot client-side for VS Code. The Visual Studio team owns the Visual Studio Copilot. And then other teams in the developer division own Copilot for JetBrains, for Eclipse, and for Xcode.

And in fact, the Xcode version of Copilot is an open-source project from a maintainer that we took over. And it started as open source with an MIT license. And we did a commercial deal with the maintainer to transfer it into our GitHub organization. But we kept it open source. So the Xcode version of Copilot has been open source for quite a while because it started as an open-source project. And we decided that that open-source maintainer and the contributors to that project did such a good job that it's better for us to pay him some money and take over the project instead of competing with that open-source maintainer.

I think the key for success at Microsoft is to leverage what is ultimately an incredible company. And yes, it is a huge ship. And so changing direction sometimes feels really hard. But at the same time, there's so many incredible people that are working in the developer division, in the cloud division, in the AI division, that we don't feel constrained. If anything, I think the hard part in Microsoft is always going to be you have so many developers and so many employees.

Employees that are supporting these developers in sales and support and what have you, that saying no to ideas is really hard. That's much easier when you're running a 10-person team. Because in a 10-person team, you know exactly what everybody's doing. And you're the 11th man that also is probably coding if you're the CEO. And so it's really easy to say, well, everybody's busy this week. So we don't have time for anything else unless somebody volunteers to work nights and weekends.

But if you're managing an organization with, I think, Microsoft all up has about 70,000 people in research and development, not all of them are engineers. There's some product managers and designers, but the majority are writing code. Saying no to an idea is really hard. And so putting yourself into that mindset, yeah, we are big, but we still have to say no 1,000 times before we say yes again. That, I think, is the constraint that we're having, and then figuring out what are the strategic bets and how we are competing in this market.

How we're ultimately winning the race and realizing that there's always going to be another race and another race, right? We are playing the infinite game. As a 50-year-old company, yes, we want to win the news cycle every month, the Formula 1 season of 2025, but then we also want to still be here and relevant in the next decade and more to come. And that, I think, is ultimately what it is all about at Microsoft. We have always stayed at the forefront of technology.

And we want to keep doing that for as long as we're all here.

I'm not thinking about crushing them, because I think that's not how we are seeing the space. I like for developers to pick the tool they love most. And I like to build the ones that most of them are picking. And so I think realizing that in developer tools and in automation technology, there's always going to be multiple players. And some technologies stay around forever. COBOL on mainframes is one such example that comes up way more often than you would think for me as GitHub CEO, because many companies still deal with that COBOL mainframe.

Now, is that the state of the art and something that coders' kids get excited about? Of course not. But we should realize that once some software is deployed, it sticks around. It's incredibly sticky, and it sticks around forever. And migrating things, migrating even a repository from Subversion into Git and then onto GitHub, those are often very complicated and expensive projects that engineering leadership only wants to fund if they can see the ROI. I think the bear case for any company in our space is missing out on the next big thing.

And there's always going to be a next big thing in software development, whether it's frontend frameworks, whether it's programming languages, whether it's IDEs. Maybe the IDE is going to be replaced by something much more web-based. And you can, in fact, already do that with Copilot and assign an issue to the coding agent on your iPhone with the GitHub mobile app. And then it does its work while you're maybe on a podcast. And then it pings you and says, here, a coding agent has submitted a pull request.

And then you can review that code. And you can even do that on your iPhone, because reviewing code is fairly doable on a small screen. Writing is harder, mostly because of all the special characters and what have you. Predicting what is the next big thing, and then being able to disrupt yourself, overcoming the innovator's dilemma that ultimately every company will get into that place where they have a moat, where they have an existing revenue stream, even if most of that revenue stream comes from many enterprise customers, to then say, okay, we want to preserve that cash flow, but we also realize we got to disrupt ourselves and move into the next version.

And you have heard many of the startup founders, CEOs, chief product officers of our competitors talking about that likely the world of AI code generation and IDEs will look very different in a year or two from now. And I think we all realize that. And so both the bear and the bull case are actually very similar, which is, can you predict what that looks like and meet developers' expectations and have actually the user adoption that then justifies that disruption to your existing business?

And at Microsoft, that is, given the size of Microsoft, both an easier and a harder task at the same time.

GitHub has been built at least twice, right? GitHub was founded on Git, which wasn't invented by GitHub. It was invented by Linus Torvalds and the Linux kernel team. And a few years later, two years, I think, the GitHub founders, Chris, PJ, and Tom, saw an opportunity to say Git hosting is so hard, let's build a SaaS service. And in 2007, 2008, that was a time when SaaS wasn't as established, and certainly not cloud-based as it is now.

And then we did this again with Copilot, where we again picked a technology that wasn't invented by us. Neither transformer nor the GPT model nor the inference infrastructure came from us. They came from OpenAI and the paper, obviously, from Google, and the infrastructure from Microsoft. And then we built the first Copilot and the first successful product in that space. And so, yeah, the big question is, what's the next wave of that? And we believe it's coding agents. And that's why we are investing heavily into our own coding agent, into Copilot, and getting that from the 20-30% benchmarks.

If you would look at multilingual, or 60-something percent for just Python, getting that to actually a number, I think 90% is going to be the minimum bar for broad adoption and saying, this is now established technology and we need to look for the next big thing. That is going to be the challenge of the years to come.

The coding agent, the way it works is that you can just give it a task: coding tasks, documentation, generating test cases, or simple things like, find all the bugs in my codebase. The agent then goes off in the cloud and spins up a virtual machine, checks out the repository, installs other tools, and solves that task for you. And the magic here is that, in the meantime, you can keep working on your part of the codebase, on a different task, a different issue, on your local machine.

And so effectively, the coding agent is like a new member of your team that can take on certain tasks. And you can obviously not only assign one task to one coding agent, you can assign 10 tasks to 10 versions of that coding agent, and they can all run in parallel. And when they're done with their work, they submit a pull request exactly like one of your human team members would do. And then they alert you and say, hey, this pull request is ready for review.

And then you go in and you review the code, and you can comment on it, and Copilot will pick up those comments and keep iterating. And so, if you don't like the code, I tested it yesterday with one of my hobby projects, and I realized the README is completely outdated because I didn't spend time on writing a README for myself, and just told the coding agent, look at the codebase and write a new README. And then it wrote a README, and I reviewed the README and looked at the headline. It changed the title of the README from README to something else.

And so I gave it feedback and said, hey, I think the README should always be called README, and so revert that change. And it just did that, right? And so that's the most simple explanation that I can give of the coding agent. There is nuance here, because there are going to be scenarios where now you want to take that code generated by the coding agent and check it out on your local machine. And you can do that with the GitHub command line and then keep working in VS Code.

And of course, Copilot agent mode is also available for you there. And so you can then use the agent in synchronous mode on your local machine. And so that's, if you stay with the analogy of your team, that's like you pulled that team member that submitted the pull request onto your desk or into a Zoom call. And now you're working together on that codebase. But now your focus is on that task in synchronous mode while the coding agent works asynchronously.

And so this continuous spectrum of: I can assign tasks, test generation, bug fixes, security vulnerabilities, bootstrapping a new feature to the coding agent; I can take that codebase into my local IDE; or I can keep working just as I'm used to, all these things in parallel, that, I think, is going to be the future of software development. And then the skill of the developer, probably, to know how to describe the task in such a way that the agent can do the job with almost no additional revisions needed.

Because every time you have to review code and correct the agent and wait another 10 minutes, you're interrupting your flow again, and you have to do something else in those 10 minutes. And jumping between different— we're bad at multitasking, and we're bad at context switching. And most developers do not want to work on 30 different things throughout the day. That's stressful and ultimately doesn't lead to great products.

It's prompts when you use it within the IDE. Although even there, you can start with the brainstorming cycle first. And so that, for example, works really great with Claude Sonnet or Claude Opus. And so you can first ask it, how would I build this? And what's the system design for this feature, for example? And then have it first write a Markdown file with bullets, doing the engineering together with the model. And then you take the first task of that and feed that into the agent mode to write the code.

For the coding agent, because it sits on the GitHub platform, the starting point is an issue. And the issue can be the description that comes from your product manager or from a user of your open-source project. But it's also all the comments in the issue, attached images, file references, or web pages. And of course, the coding agent and agent mode both can use MCP servers and tools. And so you can then further connect into additional contexts.

But yeah, fundamentally, it's a prompt. It's just that the prompt, when it's no longer just one input field with three lines of code, it can be a long description, specification from a product manager, just as they would write for a human developer. And again, the product manager then is the one that needs to learn how much do I need to decompose the big problem into a small building block.

The 30%, I was referencing the SWE-bench, S-W-E benchmark that was developed by a number of researchers and originally started as Python only. And it's 2,000 issue-pull request pairs out of a dozen Python open-source repositories, but was recently expanded to other languages. And so in Python, I think the best benchmarks are 60% to 70%, depending on what model-agent combination you take. But if you look at multilingual, we are in the 20% to 30% range for these benchmarks. So that gives you an idea of real-life issues in open-source projects and the corresponding pull requests.

How good is the agent at solving that existing issue compared to the original solution? For our coding agent, the way to approach this for developers is to just go and try it out. Because the worst-case scenario here is that you get a pull request that is so far off from what you would build yourself that you close the pull request without merging it. But then that gave you a learning cycle between the description that you gave it and the code it generated.

And then there's multiple ways you can approach that. If you don't want to throw it away, one is to provide custom instructions in a file within the repository to give the agent more context of what you expect it to do. So it's kind of like a how-to that you provide to the agent in the same way that if you would hire a developer into your team, or you would instruct people in open source to contribute back to your project, you would also give them: this is how we expect the coding standards, the libraries, how we're writing unit tests.

So giving the agent more instructions often leads to better outcomes. Scoping it down to a smaller change often leads to better outcomes and also to smaller pull requests, which is the best practice. And over time, the models will get better. And then three days later, Anthropic came with Claude Sonnet 4. And so now the coding agent is running on the 4 model. And of course, these models will get better, the context for the model will get better, the tool calls will be better.

And so I think the key thing to always remember is whatever your experience was with AI a month ago is probably no longer the state of the art.

You shouldn't really form strong opinions, or if you have strong opinions, you should have them loosely held and change your beliefs as AI technology is getting better.

The future of coders, or software developers—software engineers is probably the best way of framing it—is bright from my perspective. And software developers will learn very fast, if they haven't already, to adopt AI within their workflows, not only Copilot and not only in the IDE or on GitHub, but also on the command line, when processing files, when organizing files, when operating clusters, all these things that we also do. And we have always, as software developers, automated parts of our workflow and moved higher up the ladder.

When I started coding on a Commodore 64, there wasn't a debugger. Everything was trial and error, and you would print stuff onto the console to see what the variable content is. And then came Turbo Pascal and Visual Studio and so on, and our tools got more complex. And as such, we moved up and got more done in the same amount of time. And I think for developers, the same thing will happen again. It's in fact already happening.

It happened with the cloud. It happened with containers like Docker and Kubernetes. Today, most developers on the web don't really care about the hardware anymore, certainly not about the chip itself, other than in models where you might know that you're running on an NVIDIA A100 or H200 or whatever the latest generation is when you're listening to this podcast. But for most cloud applications, what's actually below the application layer doesn't matter to the developer, as long as the service scales and is fast and snappy for the users.

Which brings me to the SaaS question. And I think everything that I can easily replace with a single prompt is not going to have any value. It will have the value of that prompt and the inference and the tokens, but that's often a few dollars. And to manage the allowance of my kids, I'm probably not going to pay a $10 SaaS service. And I have a hard time seeing what additional value they can provide instead of just using, for example, GitHub Spark, which is our tool for these kinds of scenarios, and build my own application.

But at the same time, I think existing SaaS services will also increase their complexity. And so, as the AI technology is not only used by you and I to bootstrap applications, it's also used by those SaaS companies that are building software. Like GitHub itself, we are making our applications more complex and adding value that hopefully still motivates customers to pay for the SaaS service. And whether it's for GitHub Copilot or for the fastest-growing startup, or the previous fastest-growing startup, which I think was Wiz, I think there's always going to be companies that use the latest technology to build products that you cannot easily replicate yourself.

And as such, I'm not worried that that value chain goes away. I think we're underestimating how much you can do with the models that are out today, not the ones that are coming next year or next month, the ones that we have today, where I think we're only touching the surface of what's possible with those reasoning capabilities. And there's a whole new generation of products and agents that will offer scenarios that we're easily willing to pay a SaaS price or a mix of seat-based pricing and consumption-based pricing for.

Thank you.