Copilot, Agent Mode, and the New World of Dev Tools with GitHub’s CEO Thomas Dohmke

Hi, listeners, and welcome back to No Priors. Today we're joined by Thomas Dunk, the CEO of GitHub, a platform used by over a hundred and fifty million developers worldwide to collaborate and build software. As CEO, Thomas is overseeing the development of tools like GitHub Copilot. Before becoming CEO, he helped shape GitHub's product strategy and powered its global expansion, and previously worked at Microsoft. In this episode, we'll talk about the future of software development, the role of AI in coding, open source, and product plans for Copilot. Thomas, welcome to No Priors. Maybe we can start with the meat of it. What is happening with Copilot and the new releases at GitHub recently?

1. Copilot Goes Agentic

You're heading straight into it. We're really excited about making Copilot more agentic. A few days ago, we announced agent mode in Copilot and VS Code. Instead of just chatting with Copilot and getting responses, then copying and pasting the code into the editor, or using autocomplete—the original Copilot feature—you can now work with an agent, and it helps you implement a feature.

When it needs to install a package, it shows you the command in the terminal, and you can just say, “Okay, run this.” You're still in charge, right? That's the crucial part of these agents that we have available today: as the human developer, you still need to be in the loop. But we also showed a teaser of what's about to come in 2025.

We call this Project Padawan because it's like a Jedi and a Padawan. You've got to have patience, and you've got to learn how to use the Force. We think in 2025 we get into a place where you can assign a GitHub issue—a well-defined GitHub issue—to Copilot. Then it starts creating a draft pull request, outlines the plan, and works through its plan. Similar to how you observe a coworker, you can see how it commits changes into the pull request, review this, and provide feedback to Copilot. So Copilot basically graduates from a pair programmer to a peer programmer that becomes a member of your team.

What are the obstacles to that right now? Are they some new model advancements? Is it just building out some other core technology? Is it just the UI? What is keeping that from happening right now?

2. Agents Need To Be Reliable

Yeah, I think the first thing is the model: the full o3 model that's not available yet, but that OpenAI showed as part of Shipmas right before the holidays. We're going to see improved reasoning, and I think as the models get better at reasoning, we're going to get closer to 100% of SWE-bench, which is that benchmark. Out of 12 open-source Python repositories, a team at Princeton identified 2,200 or so issue–pull request pairs that effectively all the models and agents are measured against. That's number one: the model and the agent combination.

I think the second piece is figuring out the right user interface flow. If you think about the workflow of a developer, you have an issue that somebody else filed for you—a user, a product manager, or something that you filed yourself. Now, how do you know whether you should assign Copilot, the agent, to it, or whether you need to refine the issue to be more specific? It's crucial that the agent is predictable, that you know this is a task the agent can solve. If not, then you need to steer it.

Steerability is the next thing. You need to either extend the definition, or the agent needs to come back to you and ask additional questions. Then, at the end of the process, you want to verify the outcome. In our demo, that's why we're thinking the right flow here is actually that the agent works in a pull request, similar to a human developer with lots of commits, and then you can roll back those commits or check them out in VS Code.

We saw with some of the agents that are available that the question is: Do I, as a developer, actually tolerate the agent? Is it actually saving my time, or is it wasting my time? The more often you see it wasting your time and just burning compute cycles, the less likely you're going to use it again. If you're predictable, steerable, verifiable, and tolerable—if you get to that for all 4 criteria to a certain level—I think we're going to see wide adoption of agents.

How far away do you think these agents are from being the equivalent of a median programmer? And how much longer do you think it takes to get to superhuman?

I thought about this this morning. Regardless of what agent you're thinking of—a travel agent, a coding agent, or maybe an agent that designs your house—the fundamental challenge is actually the same as the one you have as a human developer.

You have this big idea in your head, and you can sketch it on a whiteboard, but then you want to start coding, and you have to take this big idea and break it down into small chunks of work. I think that's the part where we're far away from agents actually being good enough to take a very rough idea and break it down into small pieces without you, as a developer or as an architect—or even when planning travel—constantly getting questions back about what decisions you want to make: what database, what cloud.

Imagine you give the agent a task saying, “Build GitHub” or “Build a mobile app” or something. It will just be not specific enough. So that's the systems thinking that I think the median developer will not be replaced by an agent.

Then the flip side of that is that a lot of what developers do is just picking up issues and fixing bugs, finding where to fix the bugs, adding a feature that comes from a customer, and then navigating the codebase to figure out what files you have to modify. I think there we're going to see dramatic progress over the year.

When we recorded the demo for Project Padawan, one of our product managers used an issue and had the agent create the pull request themselves. A PM who usually doesn't code or write code in the codebase was able to use the agent to create a real pull request that was then reviewed by the developer and merged into the codebase. So in some ways, we're already there. In other ways, we need to get to the point where you trust it enough that you're using it day in, day out.

I'm sure you guys were doing a bunch of dogfooding before releasing agent mode and Padawan as well. Maybe if we just zoom out from the evaluation phase, can you describe what the overall development cycle is for Copilot today? How do you do planning and make decisions about what to try and how you improve it?

3. AI Engineering At GitHub

The industry now calls this AI engineering, where we've extended the full stack of back-end and front-end development with AI development. How do we use a new version of a model, a new model, as we now have the model picker in Copilot? We're constantly dealing with multiple models from multiple vendors. How do we integrate that into our stack?

We have an applied science team that runs evaluations. We have a team that builds out these benchmarks. The applied science team uses them to compare models with each other, but so do the teams that build features like code review agents, SWE agents, or agent mode, to validate their work as part of their test suite. So it's no longer just the data scientist and the engineer; those roles have more and more overlap, and they're collaborating day in, day out.

We do a lot of experimentation with A/B testing, where we flight new versions or new fine-tuned versions of a model after offline testing and then online testing, first with GitHub and Microsoft employees and then with sets of the population.

Overall, obviously, we have a roadmap of features that we want to build and a long backlog—not just for Copilot, but overall for GitHub. GitHub is turning 18 this year. I think it's been 18 years since the founders, in late 2007, started working on it, and then it launched in early 2008. Microsoft turns 50 on April 4. We have a long backlog of customer feedback, and we're using Copilot to build those features in agent mode now, to accelerate our feature delivery.

At the same time, the market is moving so fast. Whether we're meeting with OpenAI, Anthropic, or Google, we learn about new model versions, and then our roadmap changes from one day to another. I'm sure you're seeing that as well: the market is moving so fast. We're literally sitting on an exponential curve of innovation, where it's hard to keep up, and you can't really plan more than 1 or 2 months ahead of time.

How do you think about competition being on that exponential curve? I think it’s wild to think that coding agents, as you describe them, didn’t exist as an idea a year ago. We now have a market full of folks experimenting with these products. How do you think about winning the developer over and what they care about in that changing and competitive market?

GitHub is obviously a very dominant force overall, as is Copilot, but how do you think about winning the developer over and what they care about in that changing and competitive market?

The way we think about winning is that we care deeply about developers. That’s always been the heart of GitHub: We put developers first, and we are developers building products for developers. We have a saying at GitHub: We’re building GitHub with GitHub, on GitHub, using GitHub, right?

Everything that we do in the company, including our legal terms, our HR policies, our product management, sales, sales enablement—all these functions—are in GitHub Issues, GitHub Discussions, and GitHub repos. So I think that’s number one: We deeply care about our own product, and we’re using it for everything, day in and day out. The first thing I do in the morning is open the GitHub app on my mobile phone and then Slack, as a lot of our company operations and chat run through Slack.

Number two is—you mentioned competition. We’ve never seen anything like this in the developer space. It’s the most exciting time, I think, for developer tools. I’ve been a developer for over 30 years, and it’s amazing to see the innovation and the news coming out every day.

I think that energy in the market, which is innovation-driven both on the open-source side and on the closed-source side—let’s not forget that it’s not one-sided. As much as there’s innovation in proprietary models and software, there is an equal amount of innovation in open source and on GitHub. That energy obviously gravitates to us.

I’m a big Formula 1 fan, and it’s good when there’s competition because the races are so much more fun to watch if there are multiple teams that can win the championship. I think we feel the same way about the competition. It gives us motivation every single day when we wake up to do better, to move faster, and ultimately to win with the best product in the market.

You have such rich data about how people are actually using Copilot. What is surprising you, even from the last week or so, since Agent mode was released?

The thing that always surprised us, from the early days, was how much code Copilot is writing. Some of the folks from Microsoft and GitHub have been on your podcast in the past, and in the early days, soon after we launched Copilot Preview, it already wrote around 25% of the code. I remember that meeting where we looked at this in a product review, and I said, “That must be a mistake in the telemetry. Go back and validate that. It can’t be true that it’s writing 25% of the code,” because it was just autocompletion.

As cool as that was, at the same time, it still made a lot of mistakes in the early days. But it quickly dawned on us that, A, the number is true, and B, that’s just the learned behavior of software developers, right? You’re typing something, and you’re always reaching the point where you need to look something up, so you go to your browser and find code on Stack Overflow, Reddit, blogs, or GitHub. Then you copy and paste that, and you’re modifying it anyway afterward, right?

The inner loop is always this: You write something, try it out with the compiler and debugger, and then keep modifying until you make it work. That number quickly rose to around 50%, depending on the programming language.

If you look now with these agents, it’s hard to measure that because you can literally go into Agent mode and say, “I want to build a Snake game in Python,” and it writes all the code for you. It writes multiple files, so the denominator becomes zero, right? It’s an infinite percentage because you never—

Yes.

The 15-minute demo from 2 years ago is a 1-minute demo now. I think that’s still surprising in many ways: We are already so far ahead on that curve.

And then the opposite is also true, right? You can get it into a place where it just keeps rewriting the same file or deletes the whole file because it gets stuck somehow in the logic. That grounds us also in the reality that we’re not close to an agent autonomously parsing through all my GitHub issues and fixing my entire backlog for me.

The only thing I’m really doing is validating and becoming the code-review human for the software development agent, right? We are swinging between the excitement of how much it can already do and the reality where it gets stuck in very simple scenarios, where you’re trying to figure out how to prompt it—telling it, “Just do the one thing”—and then you just go into the file and change whatever the background color is yourself.

That makes sense. Outside of a lot of the—

Agentic efforts that you all are doing, and obviously I think that’s amongst the most interesting stuff that’s happening right now, what are other big areas you want GitHub to evolve over the coming few quarters? Are there other big thrusts, or is it all in on AI, and that should be the focus of the company?

4. Code Review Goes Agentic

So far, we’ve only talked about the generic speed agent, where you can assign an issue and it generates a pull request. But if you actually look at the developer’s life day to day, in most companies, that’s maybe 2 or 3 hours of your day that you’re actually writing code, and then you’re spending an equal amount of time reviewing code from your coworkers.

While we don’t believe that goes away from a pure security and trust perspective—you always want to have another human in the loop before you merge code into production—at the same time, we believe code-review agents and code review are big topics where AI can help you, especially when you work with a distributed team in different time zones, where you don’t want to wait for the folks on the West Coast to wake up to get an initial loop of feedback. So I think code review is a big topic for us.

Again, the AI part is one piece to that, but the user interface is equally important. Ideally, you get feedback, and then you can work with the code-review agent on that feedback to iterate, because it won’t always get exactly the right feedback for you to just click accept, accept, accept.

Yeah.

You have to have a user interface and a cloud environment where you can just open this. If you always have to clone the repo on your local machine, install all the dependencies, and switch to a different branch, you’re still having way too much boilerplate work, right?

So moving to a cloud environment where you can just try out the changes that came from code review, modify them to make them work, and have that fast outer loop.

Mm-hmm.

In that same realm of security vulnerabilities, we want your code scanning not only to find vulnerabilities but also to fix them. An even simpler version of that is linter errors—code formatting and those kinds of things. Hopefully, all of that goes away, and the AI just fixes it instead of you going through 100 linter warnings telling you where to put the spaces in the parentheses.

But also, if you look in any decent-sized software project, it has outer dependencies and lots of known software vulnerabilities—hopefully not high-risk, with a lot of them low-risk, or ones where somebody decided that’s not actually crucial to fix right now because the code is not reachable or we have other priorities.

Having AI burn down that security backlog will make both the open-source ecosystem and a lot of commercial software projects so much better, because it brings down that effort that every engineering manager swings back and forth between: the tech debt, the legacy code, security, accessibility, European regulation, whatever, and the innovation backlog.

There isn’t really a balance between the two. It’s just: What is the most urgent issue, the biggest fire drill? Is it your sales team telling you, “If we don’t get that one feature, we can’t sell the product”? Or is it the security team telling you, “You gotta fix that one issue, otherwise we’re going to flag you up to the management chain”?

That’s, I think, the AI side of things. But similarly, GitHub as a platform needs to evolve to support and have all the primitives for these agents and the AI to work in tandem with the human.

Do you think there are problems that people are not addressing yet that emerge from this transition in how software development is done? For example, you feel like we're somewhere between crossing the tipping point of the majority of code—

Mm-hmm.

…being generated this year to maybe all of the code in some cases or on some tasks. How does that change testing, the way we should look at technical debt, or any of that?

5. Software Teams Get Rewritten

To be clear, I don't think all of the code is written by AI. I think the way this will work is that we have 2 layers. We have the programming language layer, which is Python, Ruby, or Rust. Those are effectively abstractions of the chipset, the machine instruction set. That's the last layer that's deterministic. Programming language inherently does exactly what I want it to do.

Human language is inherently nondeterministic. All 3 of us can say the same sentence and mean a different thing. While we will use human language to describe a lot of the features and behaviors that we're going to build, we will still have the programming language layer below that, and we are going back and forth as engineers to figure out: Is the code that was written by AI actually the correct one? Is it the one that aligns with my cost profile, as an example? At the end of the day, we're still running businesses that have to have positive profit margins.

I think, as engineers, we're going to have both of these layers. We're heading into a world of more human language and less programming language. At the same time, we're in a world where lots of financial services institutions still run COBOL code on mainframes, and we are very far away from just taking that code that's 30 or 40 years old and running an agent that magically transforms it into a cloud application.

I think that's coming, but self-driving cars are coming as well, and we don't know when that cutover point actually happens—when you can have a car without a steering wheel that drives you everywhere within the country you live in. It works for Waymo in San Francisco, and it doesn't work for Waymo all the way from SFO to San Jose yet. The scope will increase, but we are still far away from, I think, solving all the tech debt and all the legacy code that exists.

We're still, for at least a decade or so, going to have software developers who work in lots of old-school PHP code, COBOL code, and all that stuff. At the extreme other end of the spectrum, with web development and AI, you're going to be able to—and we're already there. Look at a 10-year-old, give them a tool like Copilot, Replit, or Bolt—you name it—and have them type a couple of prompts. Have them explore how that works and how they can, similar to Stable Diffusion and Midjourney, render software themselves and iterate on that.

You yourself lead a large team of software engineers. As you said, you have more human language and instruction versus machine language. Does it change what you look for or what you want to develop in your own team?

Well, what you're looking at right now is, I think, how you describe a problem specific enough that an agent can pick it up. Basically, the planning and tracking side of software development is the issue, right? That's often the biggest challenge that you have as soon as you have a decent team size. A 10-person startup has no problem, and most 10-person startups don't have a product manager. Uh—

Mm-hmm.

…the founder is the product manager, and the rest is just building the stuff. If you have a problem to solve, you have very short communication paths. If you have 1,000 engineers, their biggest problem is: What do you want to build? How do you build it? What did you actually mean when you wrote up this thing?

If you look into that space, there isn't much AI helping you yet. We ourselves have something in the early phases with Copilot Workspace, where we have a spec and a brainstorming agent that basically looks at what you wrote in a GitHub issue, compares it with the codebase, and describes the before and after to you in human language. Then you can, similar to a Notion doc, modify that and add stuff to the specification.

I think that's going to be a whole set of agentic behavior that we're going to bring into the product management space. It's similar for designers. Today, a lot of designs are hand-drawn in Figma. I think tomorrow, as a designer, you're going to type effectively the same specification as a product manager, and you'll have an AI render the code for the wireframes and then apply grounding from your design system to make it look like your product.

Those disciplines get closer to each other. A product manager will be able to, if they're good at writing a specification, create the whole change set, and the designer will be able to take over part of the product management role. The engineer gets closer to these other roles as well. If they're good at describing the feature, they can take over that part too.

I think that's where a lot of innovation is going to happen—in rethinking how the traditional disciplines in a software engineering team are evolving in the coming years as we have more and more of these agents available and they're actually good at what they do.

As you think about these different agents and these different use cases, do you think it's going to be the same company or product that provides all 3? Do you think it's going to be 1 interface, or is it going to be a different interface? I'm curious how you think about the actual flow in terms of very different users in some sense, although with some overlapping responsibilities or goals.

What is the set of tools that they interact with? Is it a singular tool? Is it many? Is it 1 company? Is it many? Where does it launch from? How do you think about all that stuff?

One of our strongest beliefs at GitHub is developer choice. Imagine GitHub as a platform where you had only JavaScript libraries available, or only React available to you, and we would tell you that's the only open-source library you need to build an application. There would be a set of users using React and GitHub because they love React, and the rest would go somewhere else because some other platform would offer them all these other open-source components, right?

Mm-hmm.

In AI, I think we're going to see the same thing. We're going to see a stack or universe of companies that offer different parts of the software development life cycle, and developers pick the one that they like the most, that they have experience with, and that they are convinced is the future. A lot of that is part of a belief system.

Programming languages, in many ways, are very similar. If you look at the discussion between developers, you get the feeling they're very different—

Mm-hmm.

…to each other, right? At the end of the day, they're all compiling down to an instruction set that runs on your Apple M4 chip, your Intel CPU, AMD, Nvidia, or whatever.

I think we're going to have a stack of different tools, and there are going to be companies that offer all the tools. Well, not all of them, because you're never going to have all of the developer tools from one source anyway. Think about GitHub. We are a big platform, but then you still have an editor, an operating system, a container solution, and a cloud that doesn't come from GitLab. HashiCorp Terraform or Vault are examples, or Vercel and Next.js are another example.

Go into any random company in the Bay Area, and they're all going to have a different stack of tools that they have combined because they believe that's the best stack for them at this point. I think in this AI world, we're going to see the same thing. You're going to have a choice of different agents. We're already there, where you have a choice of different models, and—

Mm-hmm.

…some believe the Claude model is better. Others believe OpenAI's model is better. The reality is somewhere in the middle, and different scenarios are better with different models. I think the same will be true in this agentic future that we're heading into.

Is that true given the generalizability that we're seeing? In other words, if you were to remove X percent of the models and you just got stuck with 1 of the ones you mentioned, up to a point, you'd still be extremely happy given the relative capabilities we had 4 or 5 years ago, right? In other words, it's a little bit like we have so many great options, and some things are better than others.

But fundamentally, any one of these things would be spectacular by any sort of baseline metric.

It depends on what end state we're talking about, right? If the singularity is coming, then none of that matters.

5 years from now. 5 years.

We started Copilot almost 5 years ago, in June 2020.

And that was what? GPT-3 at that point?

GPT-3 was really the early experiments, and then we got this model that eventually became Codex, which was this code-specific—

That's fair.

—version of the model. And today, that no longer really exists, right? Today, everybody sits on top of one of these more powerful base models.

Mm-hmm. Yeah, and that's my point: to some extent, generalizability started to take over. So I'm curious how you think about generalizability versus specialization in a 5-year time horizon for agents.

I can see that happening at the model layer. But it's, again, like predicting when we truly have self-driving cars—

Mm-hmm. Yeah.

—and I've had a Tesla for 10 years with self-driving and Autopilot in one form or another, and it still cannot make the left turn into my neighborhood. I can see that future happening, but I don't know when that is, when the models are basically all about equal.

But I think for software developers, the lowest level only matters until there's differentiation at the higher layer of the stack, right? Programming languages or open-source libraries are great examples of that because, if you zoom out enough, they're all the same, right? At the end of the day, whether you're building an app with Swift, Kotlin, or React Native, what does it matter?

Mm-hmm. Yeah.

That's just the intricacies of software development and the belief system that we have. And so I think the differentiation is going to come from both where the developer gets the best experience in doing their day-to-day: Where can I start my morning, pick up something I want to work on, explore my creativity, and get the job done with the least amount of frustration—

Mm-hmm.

—and the highest amount of ROI in terms of what can I ship.

Software development, over the last 50 years—if you go back all the way to the 1970s, when microcomputers came and all of a sudden you no longer had to share a mainframe with others—has always been about: How can I take all my grand ideas that are way bigger than what I can actually achieve as an individual, and get that done faster?

I don't think we are at the top of that exponential curve. I think there's still a lot to come. The other question you could ask is, when do I, as CEO of GitHub, get to the point where my backlog is empty? I just don't believe that point is ever coming.

Yeah. There's a super-related, interesting question to what you're saying, which is: For how long are humans making decisions on what agents to use? Because if you look at it, there are certain roles—a lot of the ones you mentioned, developers, designers, et cetera—that have traditionally tended to be trend-based.

Mm-hmm.

It's almost memetic what certain developers will use sometimes. And obviously, there are dramatically superior products, and there are clear choices around certain tooling. And sometimes it just feels like it's cool, and so people are using it. Same with programming languages, right?

Mm-hmm.

So it's almost an interesting question: When the human component of decision-making goes out the window, are the decisions that are made radically different because you're getting rid of trendiness? You're not going to use—

Yeah.

Go; you're just going to use Python or whatever.

If I look at my team, how often, as the CEO, do I have to check in with them to see if what they're building is actually what I thought I wanted them to build when I gave them the task, right?

Mm-hmm.

So, number 1, the human who takes over a task—a feature, an epic, whatever—still has a loop with other team members to ensure what they're building is actually the right thing. I don't see a world where we can be specific enough when we give the agent work that it can just do it all by itself, unless the unit size is very, very small.

The other side of that question, I think, is: When do we get to the point where all software is personal software? And, in fact, I no longer install an app from the App Store; I just use a natural-language interface to build all the apps myself, and so have basically completely personal software on my personal computer, on my smartphone, instead of off-the-shelf software that's the same for all of us, where the user interface is effectively completely personalized.

And we have science-fiction movies or action movies like Iron Man, right? Where JARVIS is completely personalized to Tony Stark. And so I think that future will happen in the next 5 years for sure. It's just a question of how good JARVIS is going to be, and whether I can just tell it, "Spring break is coming up, same hotel, same family," and it books me the trip, and the only question I have to confirm is: Do I do the $5,000 trip?

One other thing that's been striking about GitHub and Copilot and everything else is the actual business success of all of it, right? And I think it's been quite striking on the earnings calls more recently. What can you share in terms of business and financial metrics and the impact that Copilot and GitHub more generally are having for Microsoft?

6. Copilot's Economics Take Shape

Not a lot beyond what's in the earnings call.

Sure.

I'm trying to remember. I think the last number we shared, a few quarters ago, was 77,000 organizations using Copilot. And back then, the number of paid users was 1.8 million. We haven't shared an updated number since. I can't share that latest number.

But I think what's really interesting from these earnings calls, if you look at the number of logos that Satya has called out, is that it's across the whole spectrum of industries. It's not just cool startups. It's not just financial services institutions. It's really every industry that has adopted Copilot.

And I don't think there has been a developer tool that has been adopted with such velocity across the whole spectrum of software development, in any company size and in any industry. $20 compared to the salary of an average software developer in the United States is, what, 0.1%, if at all. And then we're talking about 25%–28% productivity gains end-to-end, and 55% or higher on the coding task. But as we said earlier, developers do more than just coding.

That's an incredible ROI on the dollar spend. And I think that's what's driving this adoption curve. Any company is now a software company, and they all have the same problem described earlier. They have long backlogs and way too much work, and every time one of the managers goes to their team and asks them, "How long does it take to implement a feature?" it becomes the Jim Kirk–Scotty joke: How long does it take to repair the warp drive?

You get an estimate that's outrageously long, and then it becomes a negotiation where the captain sets the deadline instead of the engineer actually estimating what's possible. And I think that's where a lot of the business success of Copilot is coming from. All the people writing software are frustrated by how long it takes—not because they don't think the engineers are good, but because of the complexity of building software.

How much do you think this pricing changes—and I know it's just speculation at this point—when you're actually replacing people? And I know in a lot of industries, it could be legal, it could be accounting, it could be coding. People say, "Well, eventually this will shift to value-based pricing."

Because eventually, instead of just paying $20 a month to make a person more productive, you're actually replacing a person who costs $50,000, $100,000, or $200,000 a year, whatever it is, depending on what their role is, across different disciplines. So I'm just curious how you think about this: Is this eventually a rent-a-programmer, and is it priced like a programmer? Does it all get commoditized, and eventually something that would normally cost $100,000, $200,000, or $300,000 a year cost you $1,000 a year? How do you think about where this market goes?

I think it's going to be compute-based or some unit that's a derivative of compute, as a metric.

So it’s going to be cheap.

It’s going to be cheap in the same way that your dishwasher in your kitchen is not a derivative of what a person would cost you when doing your dishes every single day. But I think the buyer persona is not going to be willing to pay for a machine, whether that’s a dishwasher or an agent, a price equivalent to that of a human developer. And I think that’s actually the correct mindset because I don’t believe that the AI agent is actually replacing the developer.

The creative part is still coming from the software developer. The systems thinking and predicting the future are always the fun part of that, as is coming back on the podcast in a year or 2 and having you tell me how wrong I was about my predictions. But I think there are a lot of decisions that are made in software development that a human has to make: what database, what cloud. A lot of that is a function of the business and how it operates.

Which cloud you’re using is not necessarily a question of how much the cloud costs. It’s a strategic decision of the CTO or the engineering leadership team. More and more, we see companies using more than 1 cloud because they don’t want to have a dependency on just 1 single supplier, in the same way that any random car manufacturer has multiple suppliers for airbags because they don’t want to be stuck with their factory line when airbags are not available from that 1 supplier.

And so I think the agents’ price points will certainly go up as these agents become more powerful. We see that with OpenAI, where the highest tier now costs $200 for Deep Research and the o1 Pro model, and clearly people see the value in that. I think 2 years ago, if we had predicted that, you wouldn’t have believed it: you’re willing to pay $200 a month for a chat agent.

The flip side of that is that, in software, people feel like a $5 subscription for a mobile app is a lot of money. You can just see that when you look into the reviews of apps that move from a 1-time payment to a subscription model, and how many people don’t like that model because they feel like software is something that you buy once, like a CD, and then you own it. Definitely, there are going to be price increases that will be based on the value that you’re getting out of it.

Human developers are expensive because there’s limited supply. Agents will have infinite supply that will only be limited by the amount of compute capacity—the GPUs available in data centers.

Speaking of that unlocking of supply, we’ve been talking about what the pricing of code generation is. I think there’s also a question of what happens to the value of software at all. Everybody’s been talking about Jamon's paradox for a while—I don’t want to ask about that. But maybe something more specific: you’re from East Germany.

Mm-hmm.

You remember the Trabant car?

I do. I had 1. Or, well, my parents had 1.

Oh, okay. Right. So you can tell me what it’s actually like. It was the okay car, but it was the default car that ended up having this 10-year waiting list because of the supply constraint with the rest of the world. Then, as soon as the Wall came down, the demand completely collapsed.

Yeah.

Right? Because you had access to the world of cars, and pricing at least did. I guess 1 question I’d have for you is that I’m generally such an optimist about the demand for software being very elastic, but I think of that as volume, quality, and variation. Are there types of software that you think collapse in value when AI takes away some of the scarcity of engineering?

The Trabant waiting list was actually, I think, 17 years in the late ’80s.

Okay, 17, not 10. Yeah.

That road, by the way, still exists today in supercars. Often you can buy a supercar, like the top-end Porsche 911, RS3 or whatever, and then the resale price is higher than the new price because you can’t get 1. To go to a dealer, you have to buy 100 Porsches first before you get a slot for that exclusive, top-of-the-line Porsche. Ferrari is the same thing.

The Trabant that my dad owned, he sold, I think, in ’84 or ’85, to a neighbor at a higher price than we bought it because you could shortcut the 17-year wait to get a car. Often, parents had a “subscription”—quote-unquote, “subscription”—and signed their kids up for a car when the kids were still young. So you could actually get 1 by the time you reached adulthood and could get a driver’s license.

Coming to your software question, we’re going to see it going both ways. If you think about Copilot, Copilot costs businesses $20 per user per month. That’s almost exactly the same price as GitHub Enterprise, which is $21 per user per month. Storing all your repositories, managing all your issues—your whole software development lifecycle—was $21 per user per month, and many used to perceive that as a lot of money for DevOps.

Then we came out with Copilot’s auto-completion, and that was $20 a month. All of a sudden, that subfeature of the software development lifecycle—auto-completion—cost $20. And that goes back to Elad’s question: if there’s value where you get the ROI and you get 25% productivity increases, you’re willing to pay more.

Probably 5 years ago, if I told you auto-completion was going to be that standalone feature driven by AI that costs more than the average selling price for all of GitHub, you would have said, “Well, that sounds unlikely.” I think we’re going to see deflation in software prices. Some things we won’t pay for anymore. Nobody pays for the operating system anymore, and at the same time, you pay way more than ever for your Netflix subscription, your Office subscription, and all those kinds of things.

I think both of these things will be true at the same time, and it’s all about how much value you get for your business by paying for that solution, whether it’s doing it yourself, using something that you manage yourself, or installing it on your own server.

GitHub is foundational infrastructure for open source, so I’m sure you have general opinions about what’s happening in the open-source ecosystem. Today, you can use Claude and OpenAI in Copilot, and Gemini.

Yeah.

But not necessarily open-source models right now.

Correct. In Copilot, we have Claude, Gemini, and then OpenAI. OpenAI has different models. I was just parsing this in my head: “Wait, there are more than 3 models.” But it’s the GPT-4o model and the o1 and o3-mini models.

In GitHub Models, which is our model catalog, we have open-source or open-weights models, like Llama, as an example, and all kinds of other models, like Mistral, Kohya, and Microsoft’s Phi-4 model. The model catalog, while it’s a separate feature within GitHub, lets you add models to Copilot because Copilot has extensions. You can actually reach from Copilot into the model catalog.

Okay.

So if you want to quickly run inference against Phi-4, you can do that by using the Add Models extension in Copilot. That way, we have more models than just the ones that are packaged into Copilot.

What do you think is the relevance of open source versus the proprietary model APIs for developers in the future?

7. Open Source Drives Innovation

The biggest thing, I think, is that open source is going to drive innovation. We saw that with DeepSeek earlier this year—or actually, a couple of weeks ago. It’s not that long ago, even.

Long year, yeah.

It’s been—it feels like half a year has already passed instead of just a month and a half. But I think open source is going to drive innovation. We saw that with image models like Stable Diffusion, and now there’s the FLUX model from a startup, actually, not too far from my home base in Germany, in the Black Forest, in Freiburg. Black Forest Labs is actually the company behind FLUX.

So we’re going to see innovation, I think, in open-source models that drive the other vendors. This back-and-forth between the open-source ecosystem and the proprietary, closed-source companies will, I think, accelerate the whole space.

DeepSeek is the most prominent example right now where you can look into this. The paper is open. The models are open. Some of them are fully open source under the MIT license. Others are open weights, so you can look at the weights, and the code to run them is open source, but the weights themselves are under a somewhat proprietary license and governed by Chinese law and whatnot.

I think that is going to drive innovation, and it’s going to open up that space and democratize access. If you just want to play with a model, you don’t have to run inference against a commercial API. You can try it out yourself on your local machine and play with it. If you think about kids and students and research, that opens up a huge space, and that’s ultimately what has always been part of our DNA at GitHub. Was that a satisfying answer, Sarah?

Yeah. I think the most satisfying answer is somebody wins, right? But I think that’s a very hard thing to predict right now.

One has an iPhone or Android, one has Windows or Linux, or macOS, for that matter. I think we like to think about these binary battles in the tech industry, and the reality is that’s not actually how it works, and certainly not in the developer space, right? React hasn’t won. There’s always going to be the next thing. Before React, there was jQuery or whatever library you preferred.

I think there’s going to be a next programming language after Python, TypeScript, and Rust. Rust in itself wasn’t really a thing 5 years ago. There are going to be more languages that are probably closer to human language, to be more specific about the natural-language layer in AI and the programming-language layer that converts down to the CPU or GPU.

I think there is no winning. There’s always just the—you’re playing the infinite game. It’s like Minecraft. Software is like Minecraft, and there is no winning in Minecraft. You can win little battles, and they’re isolated to a certain subchallenge or whatever quest, but ultimately we’re building a bigger and bigger world of software, and there’s always going to be a next big thing.

That’s a funny analogy. If I think about any individual developer, there’s something people have been saying to me. Developers of a particular ilk—really strong technical people who are more experienced, not all of them, but more experienced, grizzled systems developers, often people very attached to Rust—will say they’re worried about the next generation of developers building the taste and understanding of architectural choices, the trade-offs, and the corner cases of how a particular implementation can fail given some shape of data, given their experiences with the actual implementation.

They’re worried. Obviously, the right thing to do for anybody who wants to win that next…

Mm-hmm.

…level of Minecraft in 2025 is to use AI aggressively. Learn to use it. But does that concern from this segment of—I'm sure you’ve heard it—resonate with you at all? Can you foster the requisite depth of understanding of engineering at an abstract level when we’re not writing the code, or is it a silly concern?

I wouldn’t call it silly, because obviously there’s some truth to that, right? It’s easy to cheat at a programming exercise or Advent of Code and those kinds of things. As these AI models get better, these competitions of who’s the best hacker or coder are going to have to move to a whole different level, where you assume that the developer is using AI to solve the challenges, because otherwise it’s going to be way too easy.

If you think about the next generation of developers—maybe not 2025, but 2035—look, you mentioned me growing up in East Germany. The wall fell, and I bought a Commodore 64, but I had no internet, so I bought books and magazines, and that was it. There was no forum I could go to and ask questions. I went to a computer club every Wednesday or so until nobody there had anything to say anymore that I didn’t know already.

If you compare that to today, the kids of today and those who want to learn coding have an infinite amount of knowledge available to them. They also have an infinite amount of patience, because Copilot doesn’t run out of patience. Parents do. I’m one. It’s incredibly democratizing to have AI available if you want to learn coding. Your parents don’t have to have any technical background. All you really need is an internet connection on your mobile phone and one of these Copilots or ChatGPTs, or whatever you prefer, and you can start asking coding questions.

You can ask about Boolean logic and systems thinking, and you can go infinitely deep on any of those questions and traverse to other topics as you like. I think we are going to see a new generation of humans who grow up with the technology. For them, it’s just natural to leverage their personal assistant, their personal set of agents. I recently called it the orchestra of agents, and you’re the conductor of that orchestra of agents.

They know how to do that, and so they can achieve so much more in the same amount of time than we could in the last 30 years. I think that’s incredibly exciting because, again, find me a developer who doesn’t have this big idea for a computer game or software system or feature that they always wanted to build but didn’t have the time for.

My engineers talk much more about being overcommitted and burned out and not having enough time for all the things I’m asking for, the customer is asking for, and the security team is asking for. I think that’s just where we’re heading and how this is going to be super exciting, both in open source as well—open-source sustainability is another big topic that we could probably spend another hour on—and in any kind of software that people want to build.

I definitely agree with that excitement and optimism. I think about my 3 kids and what they would be able to learn, and at what pace, with the AI resources that people will have, and I’m incredibly jealous. I’m like, “I could be—”

Yeah.

—much better as an engineer, so much faster with, as you said, the infinite patience and understanding of today’s models.

By the way, I was very lucky. My parents are both engineers, right? But it’s a very human dynamic where I’d ask a question, and my dad would be like, “It’s logic, Sarah.” I’m like, “Oh, no.”

Can I ask you maybe a more personal question to close? East Berlin—you have this unique experience of really rapid technological change after reunification. Do you think that informs at all how you think about the speed of the current AI transition and how users and human beings will react to it?

I always wanted to believe that a lot of my life has been defined by that one moment of change in 1989. I remember the night when the wall fell, or when it was announced that the wall would be opened. It was a Thursday night, and Friday was normal school. Saturday was still school as well, a half day, and I think I was one of 4 kids who showed up in my class. Then they sent us home, and we actually crossed over to West Berlin.

The thing that is important for that generation of kids who lived through that change is that they can no longer return to their childhood. Home is gone. There isn’t that store on the corner that’s the same as it was 40 years ago. The schools are all gone. The system is gone. The traditions—all of that resolved into that new world.

It’s a bit like when you’re moving from one country to another, which I did 10 years ago when Microsoft bought my company. Once you’ve taken that step in your life, you gain a whole new perspective on things. I think that unification in 1990, and then the steps of my life, including becoming the GitHub CEO through random decisions—or decisions that felt random at the time—are how I got here.

That’s how I look forward, and I’m optimistic about the future while recognizing my past and taking some of those experiences with me. When I talk with you guys and reflect on what it was like in the ’90s to program on a Commodore 64 before and after the internet, before and after open source, before and after the cloud, before and after mobile, and now before and after AI, there’s no looking back.

The future will be that we have AI for almost everything we do in our lives if we want to. You can still always throw your cell phone into the corner and enjoy a day without the internet.

This has been great, Thomas. Thanks so much for having the conversation.

Thank you so much for having me.

It was great to connect, sir. I appreciate the time and everything else.

Find us on Twitter at nopriorspod. Subscribe to our YouTube channel if you wanna see our faces. Follow the show on Apple Podcasts, Spotify, or wherever you listen. That way, you get a new episode every week. And sign up for emails or find transcripts for every episode at no-priors.com.