GitHub CEO: The AI Coding Gold Rush, Vibe Coding & Cursor
GitHub CEO Thomas Dohmke on Pioneering AI Coding, Navigating Microsoft's Unique Ecosystem, and Redefining the Future of Software Development for Every Coder.
Summary
This Mad Podcast episode features an interview with GitHub CEO Thomas Dohmke, delving into the future of AI coding, GitHub's strategic position in this space, and the foundational rationale behind its acquisition by Microsoft. Dohmke highlights the underestimated potential of current AI models and how GitHub Copilot, through early development and market insight, pioneered the field. He elaborates on GitHub's multi-model strategy and the innovative agent mode for AI coding, while also discussing Microsoft's unique approach to both competing and partnering within the tech ecosystem. The conversation also touches on the profound impact of AI on software development and the SaaS industry, indicating that AI will accelerate the professional developer's workflow and democratize coding, simultaneously pushing SaaS services to increase complexity to maintain value.
Key Points
AI Coding as "Ground Zero": AI coding is identified as the most widely adopted generative AI application, a hub of innovation, and a battleground for tech giants and startups.
GitHub Acquisition by Microsoft (2018): Acquired for $7.5 billion to deepen Microsoft's developer tools strategy and leverage AI (training models on the "graph" of code on GitHub). GitHub remained relatively independent but accelerated Microsoft's broader cloud and AI ecosystem (Azure).
Rise of GitHub Copilot: Developed ahead of the broader generative AI craze (launched June 2021), showcasing Microsoft/GitHub's agility. It provides intelligent code autocompletion to maintain developer "flow state" and has evolved to include chat and agent modes.
Multi-Model Strategy (GitHub Models): GitHub offers choice by integrating various AI models (OpenAI, Anthropic Claude, Google Gemini) into Copilot, believing no single model will dominate the market. This also aids in adapting quickly to the evolving AI landscape.
Beyond Fine-Tuning for Enterprise: Thomas advocates for Model Context Protocol (MCP) and tool calls over traditional enterprise fine-tuning, enabling agents to understand broader codebase environments (databases, CI/CD, etc.) for more powerful, iterative problem-solving.
Categorization of AI Coding Market:
Bootstrapping/Greenfield: AI generates complex applications from prompts.
IDEs: Integration of AI into existing development environments (VS Code, JetBrains, Xcode).
Model Companies: Labs like OpenAI and Mistral entering the coding product space themselves.
Agents: Work within existing codebases ("brownfield") to take on tasks, submit pull requests, and support asynchronous work.
Microsoft's Unique Stance (Compete and Partner): Microsoft's DNA allows it to both compete and partner with companies in the AI coding space (e.g., Azure hosting competitor AI inference services), fostering a larger ecosystem.
Agent Mode (GitHub Copilot Agent): The next evolution, where developers assign tasks (bug fixes, new feature bootstrapping, documentation) to agents that work asynchronously, create pull requests, and can be refined through prompts and human review.
Future of Software Development: AI will accelerate professional developers' work, enable more people to learn coding, and drive SaaS companies to increase complexity to maintain value as prompt-based application generation becomes commonplace.
Action Items
For developers interested in Agent Mode: Should "just go and try it out, because worst case scenario 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."
For product managers: Need to "learn how much do I need to decompose the big problem into a small building block" to better guide AI agents.
For those with strong opinions on AI technology: Should "not 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."
Why AI Coding Is Ground Zero for Generative AI
Thomas Dohmke:
Matt, thank you so much for having me. Great to have you here today.
I’ve been very much looking forward to the conversation because AI coding is such a fascinating area. It feels like ground zero for all things generative AI.
First, it’s arguably the most widely adopted application of generative AI today. It’s where a lot of the innovation is happening. It’s where some of the questions around "is AI going to take our jobs or not?" feel the most real.
And then, it’s like a big battleground as well from a business standpoint between the hyperscalers, the startups, and the big AI labs. So, what I’m hoping to do today is have a very educational and in-depth conversation about all the things, both for coders and non-coders, to understand where it’s all going. Does that sound good?
Matt:
Sounds great. Yeah, it's also, I think, one of the oldest use cases for AI.
The $7.5B GitHub Acquisition: Microsoft’s Strategic Play
Matt:
Yes, perfect segue. Let’s go back in history a little bit. Let’s talk about 2018, which was the $7.5 billion acquisition of GitHub, which had been a startup for over a decade by then, by Microsoft. You were deeply involved in this. Walk us maybe through the strategic thinking behind the acquisition at the time. $7.5 billion seems cheap now that we’re in 2025 and you see all these startup valuations.
Thomas Dohmke:
I think Microsoft has always seen itself as a developer tools company. It’s a platform company, and to be successful with the platform, you need to have developers on your platform that build apps, services, and products on top of it, but also build an ecosystem around the platforms.
Microsoft, back 50 years ago, started with a basic interpreter for the Altair. Then you fast forward, and in the 1990s, Visual Studio came. In the 2000s, there was TypeScript and .NET and that ecosystem. And in 2018, a lot of things had changed. Under Satya Nadella, Microsoft’s current CEO, who came into his role in 2014, he had changed Microsoft to start 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.
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 is 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, the 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. So, bring that into the Microsoft ecosystem.
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. 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.
The three principles that we set back in 2018 are actually still true today, which is GitHub always puts the developer first. That’s what drives all the decisions, the design, the product processes, how we think marketing, and 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 into. When you’re acquiring a company, 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. The easiest example I can give you is how GitHub accelerated Microsoft is, of course, GitHub Copilot.
GitHub’s Role in the Azure Cloud Ecosystem
Matt:
Just to build on those two points, which are super interesting, GitHub helping Microsoft… to what extent does GitHub fit into the Azure broader picture? The hyperscaler business model is generally described as building a bunch of applications that drive demand for the underlying compute. Is that one of the key objectives? What is the intersection between GitHub in general, GitHub Copilot in particular, and the underlying Azure business?
Thomas Dohmke:
The Azure business within Microsoft came out of a division called Server and Tools. Today, that division is called Cloud and AI. The Server and Tools team also had the developer division, with a core product back in 2018 being Visual Studio – in itself, the IDE, the old-school IDE, in itself a billion-dollar business. It 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.
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, you know, 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 from Microsoft.
We announced last July, so almost a year ago, that GitHub had passed $2 billion in annual revenue run rate (ARR). You can go back in time to 2017, a year before the deal, when 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.
As such, the first thing I want everybody to think about when you ask how is GitHub contributing to Azure is, it contributes to Azure’s revenue number by increasingly generating more and more cloud revenue. And of course, Copilot is a big part, 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, though that is also true.
But I was in one of my sons’ 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 through something called GitHub Actions, our CI/CD service, where it suggests, for example, the Azure Kubernetes Service to deploy a Docker file.
It’s the other way around, which is the Azure teams obviously are 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 always also think Microsoft, one of the biggest software development companies itself, benefits from every innovation that we’re building into GitHub for its own backlog, for its own shipping velocity, quality, et cetera.
How GitHub Copilot Beat Everyone to Market
Matt:
The other thing that you mentioned a minute ago that’s fascinating is precisely the fact that the acquisition of GitHub seems to have been so successful in terms of keeping the spirit alive. To put it in full context, one of the things I find amazing about this whole story is that you guys came up with Copilot way ahead of anybody else in the market. In particular, you were before the whole ChatGPT thing, you know, unleashed the entire generative AI craze. So, you’re very much early to this market, which when you think about big companies, that tends to be the other way around, right? Especially for people like me in the venture world, it’s always like, "You know, the startup moves faster than the big company." That was not the case here. What was the secret and the kind of management tricks and techniques that enabled you guys to do that?
Thomas Dohmke:
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 to Satya, and then for Satya to go to the Microsoft board and automatically get approval for the deal, one additional thing was in fact AI. We believed there’s a future where we can train AI models on the "graph," I think what we called it, of all the source code that is stored on GitHub, but also on the relationships between the developers, you know, 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. 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 that we, in fact, through that process, looked at our own coding exercises that we use for our interview loops. 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. I think there’s a paper still on some of these 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, what we called it, was one of the ideas we had. The only reason we didn’t ship that was that it wasn’t good enough, and we were quite skeptical shipping something where everybody looks at this and asks in a chat interface, you know, "describe this method" or asks the typical chat scenario that we’re all now used to. And it often gave incomplete answers or wrong answers. 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 auto-completion 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 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.
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. So, it could predict the next 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 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. 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.
Copilot & VS Code Explained for Non-Developers
Matt:
Again, in an effort to make this interesting to both a developer/coder audience but a broader audience as well, how would you describe GitHub Copilot in two minutes, and how does that interface with VS Code? What is VS Code? If I’m a non-developer, what does that all mean?
Thomas Dohmke:
The way I’d like to start describing what GitHub Copilot does is describe what a developer’s job actually is, which is writing code. Most developers in the morning, they go somewhere where they have their backlog, you know, 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.
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 developers is to translate that language into code, 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.
What you did before Copilot would be to Command-Tab or Alt-Tab on your computer into a different application, often the browser, and try to find that information. You do that by opening a new tab and using Google or Stack Overflow, GitHub, lots of platforms like 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.
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. 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.
So, Copilot, the original Copilot, did that by suggesting multiple lines of code. Instead of just the next word, it could complete five, ten, twenty lines of code, and you would just accept that with a 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.
So, Copilot does that auto-completion, 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.
Then came ChatGPT, and of course, we added the chat scenarios. That allows you to do all kinds of exploratory things like asking questions, describing code, telling the chat part to fix a bug. I bought both my kids a Copilot license because before they would always come to me and say, "Hey, my Python, my Python…" Of course, that also let me test the payment and the billing flow, so I get free emails from GitHub every month – one for my own account and then one for each of my sons. So, I’m the customer zero, as we would call that.
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." Then I was like, "Well, you know, 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! Priorities on 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. 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 a task, and it does that task for you.
GitHub Models: Multi-Model Choice and What It Means
Matt:
You mentioned that initially, GitHub Copilot ran on Codex, which was the early coding model from OpenAI. I think at the end of last year, 2024, you introduced GitHub Models, which feels like a library of different underlying models you can use. Walk us through that. How does that work, and what can you do as a developer?
Thomas Dohmke:
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 so you can integrate these models into your repository to build AI scenarios into your own applications. This is really cool because you don’t have to go to another place, you know, and sign up for a new account, and then you have your model stuff here and your code on the side.
GitHub ultimately was always about millions of developers collaborating on a project together. So, our philosophy is we bring what we call the "primitives" that developers need into the repository: issues, wikis, pull requests, actions, and our 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. So, we added back then Anthropic Claude 3.5 Sonnet, and now it’s Anthropic Claude Sonnet 4 and Opus 4. And we added Google Gemini, back then 1.5, now we are 2.5 Pro.
But really, it is about 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. We are not the ones telling developers whether jQuery or React or Next.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, and 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—it’s the right word, 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, when you look at these benchmarks, the devil is in the details. You have to do the double click and see how it does 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 in our inference API, we also have "bring your own key", so you can connect Copilot to OpenRouter or Llama. You can run a local model and try out that model in Copilot, and to build your own agentic behavior into your developer workflow. 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 a hard nut to crack—or you offer the choice, and then the enterprises can stick with a 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 the 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.
The Reality of Fine-Tuning AI Models for Enterprise
Matt:
And for the enterprise, do you allow people to fine-tune their model based on their data? How does that part work?
Thomas Dohmke:
We do not today. We have pursued that path in the past, so I think in 2023 and 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, as there’s another model every other day, you’re ultimately always going to be behind with your fine-tuned model. We’re putting you then in a position where you’re having 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.
Second, 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/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 codebase isn’t actually big enough to have a meaningfully fine-tuned model.
And lastly, and 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 are 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 calls – 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 Confluence institutional knowledge. And then there’s a thousand MCP servers for everything else. So, if you want to connect to Figma or you want to connect to your database or what have you, you can pull 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. If you have used agent mode or any of these agent modes, you can actually see that working—how it uses the train of thought to go from, "Okay, it’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 in all the context makes it so much more powerful than a fine-tuned model could ever be.
Matt:
All right, amazing. I’d love now to talk about, let’s call it, the political economy of this whole space, for lack of a better term.
The Dizzying Pace and Political Economy of AI Coding Tools
Matt:
You mentioned the incredible pace of innovation, and indeed, it’s dizzying, right? Just what over the last few days, it feels… you know, Mistral announced a coding product that’s a combination of the various underlying coding models that they had. Cursor officially announced their round at, I think, a $9 or $10 billion valuation and said that they were at $500 million in ARR, which is kind of insane and makes them possibly the fastest-growing startup of all times, at least on the enterprise side. You know, the Sonnet 4 that you mentioned earlier, that came out what, two weeks ago? It feels like old news, but that was like two weeks ago. So, the pace is absolutely dizzying. What do you make of it, and how would you categorize it? Like, who does what, and where do you guys fit in? What do you cover? What do you not cover?
Thomas Dohmke:
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, right? Because there were times, you know, 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.
Matt:
100%. I’m so glad you said that. That was such a VC trope: "Don’t invest in developer tools because developers are very cheap people. They will never pay any money for anything." And yep, there you go, there’s no money to be made.
Thomas Dohmke:
And here we are. Second, I think it shows that AI is going to accelerate the role of a professional software developer, and it’s also going to enable everyone that wants to become a developer to learn coding. You can see that with Copilot and a bunch of these tools—Vercel, Zerobold, Lovable, OpenAI Codex—where folks with a non-technical background can build a quick web page now.
And I think this is good to anchor ourselves that 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 web page. Even though I knew how HTML and CSS works, that was still the faster and cheaper way to just spin up a quick web page and publish, I think it was the landing page for our startup back then, and just say, "Here’s the sign-up 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 web pages to little games. My favorite demo is to build the 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.
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 web page, an application. And then you either like what you see or you want to add more or change things, and you keep prompting. In fact, the image model is a great 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.
Category two is IDEs. You already mentioned one; there are a bunch of others that have taken VS Code, forked it, and made it a new version. That’s the power of open source, right? The power of open source of Microsoft making VS Code open source back ten years ago in 2015. But there are 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 VSS, the Microsoft IDEs, but also for JetBrains, for Eclipse, for Xcode, for Android Studio. And then there are forks of our codebase to bring it into Emacs and what have you. So, the IDE is the hottest playing field, I’d say, simply because that’s where the majority of professional developers are. 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 we’re doing until now. That’s just going to create an allergic reaction, like, "Go away, you know. I know what I’m doing. I’m used to my shortcuts and my color schemes and all these kind of things."
Then there are 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 respected 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. They might use a chat agent as kind of 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 scenario, 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 SIE agent, and then look at exceptions or monitoring data, and then file a GitHub issue and say, "Hey, you know, the latest deploy has created an exception." And you can tie those together and have the SIE 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. And 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 a local machine and just make those changes instead of trying to figure out how do I provide now feedback or prompt to describe a natural language where I already know how to do it in programming language, right? That’s not, 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.
Matt:
This is so fascinating in so many ways. To take your third category of the big AI labs…
Competing and Partnering: Microsoft’s Unique AI Strategy
Matt:
…So, there’s this competition and collaboration relationship that’s starting to appear where obviously Microsoft has a very special relationship with OpenAI, but through GitHub Models that we were just discussing, you’ve diversified. I mean, you have offered choice for your users, which is the key driver, but as a side matter, you’ve diversified away from one supplier. That tension also between Anthropic potentially and Cursor, where Cursor has started to diversify away from them. So, how do you view this evolving? Ultimately, everybody competes but also cooperates, or is there a moment when, I don’t know, you guys maybe need to develop your own model specifically for coding? How do you view it evolving?
Thomas Dohmke:
It’s the DNA of Microsoft to be competing and partnering with many companies in the industry. 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 into 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.
As such, I think, and I learned that when I joined Microsoft ten and a half years ago, it was weird as a startup founder to come into the company and realizing 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 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, in one form or another, are GitHub customers. So, we really enjoy being on both sides of that spectrum, and I think it increases the energy that we have within Microsoft, within GitHub, to say, "Okay, we’d love to partner with these companies." And developers in the developer space even more so, because look, if we would just exclude parts of the ecosystem, that means those developers go elsewhere and pay for the subscription or do their business with somebody else in the industry. Instead, we see ourselves as part of an ecosystem, as GitHub hopefully being one of the bigger planets, one of the core planets, if you know in Star Wars. And then there’s a huge system mid-rim and out to stay within the metaphor.
And companies that are closer to us and sponsor our conference and have active partnerships and 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. 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 who enable those customers that pay us money for that repository, for that pull request, to choose the tools that they want to have part of their platform stack.
Matt:
I’m curious what it feels like from the inside, you know, running a very important major division as part of the broader ship when it comes to product decisions.
Does Microsoft Limit Copilot’s AI-Native Potential?
Matt:
A big part of the value proposition of Cursor from the outside is that because they forked VS Code, they can have a product that’s sort of all-in on AI, very AI-native in all aspects of what it does, versus GitHub Copilot, from what I understand, where your plugin is into VS Code, and then another part of Microsoft needs to make sure that VS Code remains very versatile, broadly applicable to lots of different use cases and scenarios. Do you feel constrained by that in terms of how much you can do that’s truly AI-native because you need to operate in that framework where there are other driving factors?
Thomas Dohmke:
Not at all. The VS Code team, while they don’t report into me as the GP CEO, they are part of the developer division that we’re also part of. And together with the developer division, we’re part of an organization within Microsoft called Core AI that has the whole AI stack in it as well. And so, under Jay Parekh, who’s the leader for Core AI, we’re 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 Core AI 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 kind of things.
Coming back to VS Code, at Microsoft Build in May, we announced that we are open-sourcing the 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. 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. 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.
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. We did a commercial deal with a 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 machine. And yes, it is a huge ship, and so changing direction sometimes feels really hard. But at the same time, there are 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 at Microsoft is always going to be: you have so many developers and so many 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 eleventh 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 on weekends." But if you’re managing an organization with, I think, Microsoft (or up) has about 70,000 people in research and development—not all of them are engineers, there are 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 a thousand times before we say yes again," that I think is the constraint that we’re having. And then figuring out what are 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’re playing the infinite game as a 50-year-old company. It’s 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 the forefront of technology, and we want to keep doing that for as long as we’re all here.
Matt:
You anticipated my question, which was what’s a bull case and the bear case. You know, depending on which side you look at it from, on the Cursor side, you could say they have the benefit of being unconstrained and being able to go all in in building one specific product and sort of attracting the kind of developers that already want pure AI.
The Bull and Bear Case for AI-Native IDEs Like Cursor
Matt:
I was curious what the bear case is for them, like the reason why they’re going to be roadkill from the power of Microsoft and perhaps Google. So that’s distribution, that’s developer mind share. You know, a very competitive guy, and Microsoft is a very competitive organization. Like, why, how are you going to crush them?
Thomas Dohmke:
I’m not thinking about crushing them, because I think that’s not how we’re 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. I think realizing that in developer tools and in automating in technology, there’s always going to be multiple players. And some technologies stay around forever. COBOL and mainframes are 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 and mainframe. Now, is that the state-of-the-art and something that college 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.
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 front-end 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 by 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 brings you and says, "Here, the 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, and 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 more so that revenue stream comes from many enterprise customers—to then say, "Okay, we want to preserve that cash flow, but we also realize we’ve got to disrupt ourselves and move into the next version."
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. 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? At Microsoft, given the size of Microsoft, that is both an easier and a harder task at the same time.
Matt:
That’s such a fantastic thought that the pace of progress actually creates an innovator’s dilemma for everyone, not just for Microsoft, but actually probably for Cursor as they grow. They will also have a business to defend given how quick things are changing. That’s such an interesting thought.
Thomas Dohmke:
GitHub has been pulled 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. 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, certainly not cloud-based as it is now.
And then we did this again with Copilot, where we again picked 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.
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, you know, from the 20-30% benchmarks (if you would look at multilingual) or 60-something% for just Python, getting that to actually a number—I think 90% is going to be the minimum 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.
Agent Mode: The Next Step for AI-Powered Coding
Matt:
Yeah, let’s double-click on that for a few minutes. The launch of that agent mode was a major announcement, a major new step in the history of GitHub that just happened at Build 2025 a few weeks ago. What does it do, and what tasks in particular would you suggest people should direct it to?
Thomas Dohmke:
So, the coding agent, the way it works, is that you can just give it a task—a coding task, 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 and checks out the repository, installs all the tools, and solves that task for you.
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. 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 ten tasks to ten versions of that coding agent, and they can all run in parallel. 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." Then you go in and you review the code, and you can comment on it, and the Copilot will pick up those comments and keep iterating.
So, if you don’t like the code, or you know, 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 I told the coding agent, "Look at the codebase and write a new readme." It then wrote a readme, and I reviewed the readme and looked at the headline and changed the title of the readme from "readme" to something else. And so I said, "Hey, I think the readme should always be called readme," and so revert that change, and it just did that, right? 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 a 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.
So that’s, if you stay with the analogy of your team, that’s like you pulled that team member that pulled 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, or I can take that codebase into my local IDE, or I can keep working just as I’m used to. All these things at parallel, that I think is going to be the future of software development. And then the skill of the developer will be 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.
Jumping between different—you know, we’re bad at multitasking, and they’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.
Matt:
And the agent works with prompts, right? It’s vibe coding, where you describe what it is that you want it to do, and it does it. Is that right?
Thomas Dohmke:
It’s prompts when you use it within the IDE, although even there you can start with a brainstorming cycle first. So, for example, that works really great with Claude Sonnet or Claude Opus 4. 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 context. 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, a specification from a product manager, just as they would write for the 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.
Matt:
And when you mention 30% or 40% success, is that across the board, or from your experience using the product and early feedback from users, is the agent particularly good at certain tasks versus other tasks? If I’m a GitHub user, and I want to play with the product, what should I do first?
Thomas Dohmke:
The 30% I was referencing is the SWE bench, the SWE benchmark that was developed by a number of researchers and originally started as Python only. It’s 2,000 issue/pull request pairs out of a dozen Python open-source repositories but was recently expanded to other languages. So, in Python, I think the big best benchmark is 60% to 70%, depending what model-agent combination you take. But if you look at multilingual, yeah, 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 worst case scenario 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 are 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 a better outcome and also to smaller pull requests, which is the best practice.
And over time, the models will get better. We launched the coding agent on Claude Sonnet 3.7, and then three days later came with Claude Sonnet 4. So now the coding agent is running on the four-model. And of course, these models will get better, the context for the model will get better, the tool calls will be better. So, I think the key thing to always remember is whatever your experience was with AI months ago is probably no longer the state-of-the-art. Now, 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.
How AI Coding Will Change SaaS and Developer Skills
Matt:
To close, it feels almost inevitable, when having a conversation about AI coding in 2025, to not ask about what that means for the broader industry and the broader world. So, two questions: What does that mean in terms of the future of SaaS? You know, in a world where anyone can spin up applications quickly, do we all build our own applications ultimately? And then another big, meaty question, which you know, I’m not suggesting we go into it in great detail, but what does that mean in terms of the future of being a coder? What are the skills I need to develop or not care about in the future?
Thomas Dohmke:
The future of coders or of software developers, software engineers is probably the best way of framing it. 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, all the things that we also do when operating clusters. And we have always, as software developers, automated parts of our workflow and moved higher up the abstraction 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. 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 old 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 in 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. 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 kind 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’re making our applications more complex and add 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 Viz, 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 about 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. I think we’re only touching the surface of what’s possible with those 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.
Matt:
Thomas, what a fantastic conversation. Thank you so much for doing it.
Thomas Dohmke:
Thank you.
Matt:
Hi, it’s Matt Turk again. Thanks for listening to this episode of the Mad Podcast. If you enjoyed it, we’d be very grateful if you would consider subscribing if you haven’t already, or leaving a positive review or comment on whichever platform you’re watching this or listening to this episode from. This really helps us build a podcast and get great guests. Thanks, and see you at the next episode.