GitHub CEO on what AI means for developer salaries, SaaS, and more

0:00Where we are today in technology means a company like GitHub or Microsoft needs to be as agile as a 10 person startup. And that is quite hard because we're running a big ship at the speed of a really small boat. The nature of the software that companies are going to ask for is also going to change. We will see a commoditization of software that is so simple that recreating that on the fly will replace those SaaS services. I think software developers are the first class of career where they start their day thinking, how can I automate away the things I did last week? But also they have moved up what I call the abstraction ladder.

0:32All of a sudden, with AI, we were able to get so much closer to how we're actually thinking, the language and the descriptions that we're thinking in. Isn't there a case that we've gone over the hill to a point where we're going to be creating so much code so rapidly that it'll be less inspectable for the human? At least you're already past that point.

0:57My guest today is Thomas Domker. He is the CEO of GitHub. GitHub needs no introduction. It is the platform upon which nearly all modern software development happens, and software development is being revolutionized by artificial intelligence. Now, GitHub is part of Microsoft, and recently Microsoft CEO Satya Nadella said about 30 % of the code in some Microsoft project is written by AI. This means that AI writes one line of code for every two lines of human rights. But that ratio is going to change as AI gets better, and some developers have told me their ratio is closer to four AI to one human.

1:42When it reaches 100 AI lines of code for every one human line of code, Thomas, what is the developer actually going to be doing? Yeah, it's a great question. I think Satya said between 20 and 30 percent of the code in our repositories was written by software. So it was a bit broader in how he framed it. And I think, you know, the developer will do mostly what engineers actually do and how they define themselves, which is they're solving problems, implementing ideas. You know, they're taking the big idea you have in the morning. You know, it's Friday, 9 a.m. here. I'm sure many engineers here in the U.S.

2:22look forward to a long weekend, but still have something that they want to get done. And they're trying to figure out how they do that. The work doesn't start with typing in your editor. The work starts with leading up, you know, a GitHub issue or a specification or just taking what I have in my head and bringing it down into nodes and, you know, models and systems like Copilot play the first role here where you can brainstorm with them and say, hey, you know, I have this problem that I want to solve. Very simple. I want to build an app today. Give me some thoughts of how I can do that. And you can kind of like do this software decomposition part first and take a big problem break into smaller parts.

2:56And I think that ultimately is what engineering means. and then you know where to stop with the decomposition and now you can start coding. And in the past, you had to start at a very low level. Before we started the live stream, you showed me a very old computer and back then it was very hard. You had to go very low level. Today, most engineers actually already start on code written by others, right? They use open source libraries. They use open source app writing systems. They have an editor that they're not building themselves and a debugger and a compiler and a container orchestration like Kubernetes and all these things, right?

3:29So we're already composing different pieces into software and we're moving up the abstraction then and AI will help us to achieve that. And then we will review the work of the AI to make sure it's secure and compliant and runs efficiently and hopefully returns some profit for the corporations or the teams we're working for. I love what you've done there because you've built us a bridge to the past. When people started to write code and I spoke to somebody this morning or yesterday morning when I was in Chicago who worked on medical records. And he said the language they're written in is called Mumps, M-U-M-P-S, which I'd never heard of before.

4:08And I've gone off on research. But, you know, in those early days, you started from a blank page. If it was in basic 10, you know, print hello world. And what's happened over 35, 40 years is libraries, abstractions, reusable components. So an engineer is assembling things almost like Lego, but it's not as straightforward as a Lego. But there is something different about these AI tools, or so we're told by the numbers that come out on grand stages at developer days. How has your own experience as an engineer changed as you've started to use the co-pilot in GitHub? Is there a behavior that you hadn't expected to take on?

4:53I actually have some Legos in my hands and behind me too. In some ways, I actually think it is a bit like Lego, right? Because when you start working with Lego, you're not thinking about plastic, you know, pieces and forms to build bricks first before you assemble the bricks. I think the thing that really changed Google Copilot in my own coding projects, which are mostly hobby projects on weekends is that I match faster back into the flow state. The challenge that most engineers have, and this is where vibe coding comes, is that you have an idea and you want to build something on a Sunday morning.

5:29And the first thing you did in the past is you started research and you maybe looked on GitHub for some open source components, or you looked on maybe something project already existed that you could fork. But before you knew it, it was night and you had maybe done a little bit, got a quick prototype done, but you were nowhere near the thing you actually wanted to build. And maybe you got to 10 % or 5 % and you realized that what you thought is easy to do is actually much more complex. And that has dramatically changed, you know, through the use of open source, through the cloud, through platforms like GitHub, Reddit, Stack Overflow, all these being available to you.

6:07Because when I started coding in the early 90s, it was books and magazines. And then on a Commodore 64, I had to build it all from scratch, right? So we are already at the point where we are taking pieces and we're composing software. But now I open my editor and my project is there and I can just ask Copilot, what's the next step? Or I can, you know, give agent mode the feature I want to build and say, hey, help me to build this feature. And then it looks through the files and it identifies where I have to make changes. So I don't even have to figure that out myself. We're in the code base where I have to implement things.

6:39it runs command and the cool thing when it runs command it actually actually can look at the error message and then see what what is wrong on my system and it might have to install another library or and things like that so it keeps you more in that flow state you know instead of you switching back and forth between research mode and trying to make things work and then things take forever to compile in the meantime you go and make a coffee or get distracted by sub stack Well, if you think about the maybe three orthogonal dimensions about an engineer's output, there's quantity, there's quality, and there's creativity.

7:18Are they producing more lines of code? Are they producing better lines of code within a tighter set of guardrails? Or are they being more creative about the problem specification? which of those has most shifted when you look across the millions of people who've been using GitHub Copilot? I think they you know to some degree have evenly shifted because they're all tied to each other my creativity you know during the coding process is limited by the time that I have available and the energy that I have you know the amount of distraction I get and oftentimes developers describe that as the magical flow state like you're in you're almost in a in the zone of of building something and as long as nobody distracts you you really feel like you're getting a lot of things done and then you know the moment comes where you finish the feature or or you got the distraction and now you're out of the zone and you have to find it back later and i think co-pilot and agent mode keeps you in that zone of creativity and lets you really focus okay i want to take this and implement it.

8:23Similarly, it helps you to review code. So there's the copilot code review agent where you can run your pull request through it and it gives you feedback on that. So you no longer have to wait for your team members, right? So that's not a creative process. That's more like a verification process and copilot helps you with that work. It can write unit tests. And I think most developers, if they're honest to themselves, and then certainly I can speak for myself, if I work on my own hobby projects, I write no tests whatsoever and I don't file a pull request against myself either, right? Because it's like, A, all my code is obviously perfect, haha.

8:56But B, it's like, that's not the fun part of the job. The fun part is to implement something and I can see it appear in front of me on my screen. I have the magic in my hands and I could create something with just code, right? So can I just demystify three terms you've said that may maybe need explanation for non-developers? Because this is a super relevant conversation about how work changes that we're having beyond coding and software development. So you said three things. One is unit tests. So roughly, you know, when a developer writes a component of code in order to know whether they've written the right thing, they should also write a test.

9:30If it passes the test, they've written the right thing, unless, of course, they've specified the test wrongly. So that was one thing you described. The other thing you talked about were the idea of pull requests. This is really about how you file each iteration of your code with a note of the work that you actually did so that you technically have an audit trail to work your way back like Hansel and Gretel when they were meant to leave the sweets trail in the forest. And the other thing you said, which if people haven't worked with engineers, I think is so important, is the notion that an engineer gets into flow state.

10:09They become one with the code because what you're doing is you're taking the amorphous complex world and you're framing it into logical deterministic code. And it requires a class of focus that I don't think you see in any other activities. Now, you're the sort of developer advocate on this call. Is that a fair reflection of those three ideas? You hit the head on the nail. Is that how you say it? You hit the head on the nail. Or the nail on the head, I think. Either way, we're fine. We're friends here. The hammer on the nail. No, but I think software development is a combination of creative work, of art, something that's very similar to what an artist does.

10:53And it's also production, what Bill Gates famously called the software factory. And both of these things are combined. And so part of the job of a developer is being creative, implementing something in software. And the other part is working with the team, developers, product managers, designers to verify the product. And that is both from a UI, UX perspective, like looking if the product actually does and look like it was intended to be. But also from a code quality perspective, from a, does the piece of software I produce, does that align with what the rest of my team has been doing? Or is there now a conflict between those things?

11:29So a lot of the time that developers spending every day is actually on that production side of the creative process. And often that is the more, you know, boring piece for many developers. And that's where automation is great because I actually want to spend more time in the creative part of it. You know, designing ultimately what I'm shipping to my customers and automate as much as I can on the production side. So to give one example, over the last 10, maybe 20 years, almost all production deployment has been automated. So it used to be, you know, in the late 90s and early 2000s when the internet started, you would have some files in your local machine and you would use a protocol like a so-called FTP, file transfer protocol, and upload files to a box somewhere, then replicate that process and maybe had a script to automate that to some degree.

12:19but that was a very manual process and if something went wrong your page went down and and then you had to figure out what did i do wrong or what server has a problem today all you really do is you use this pull request that's that you described so eloquently uh where i i submit my my work uh for review by my team they review it automated tests are running and verification is running and then i click a button that says merge and it merges us into the main branch the main line of our work. And then an automated process starts to deploy all of that into sometimes thousands, if not tens of thousands of virtual machines in the cloud.

12:55And so that's one such example where we have automated the work of a software developer. So we have more time for the ever increasing complexity and demands and innovation on the creative side. Absolutely. I mean, that's a great example where I think software developers are the first class of career where they start their day thinking, how can I automate away the things I did last week? And I've been around so long. You talked about continuous integration and deployment as opposed to manual deployment. I remember the absolute excitement with a development team I was working with when we got something called Doxygen, which helped you create documentation.

13:39This is in the late 90s because if there was one thing developers hated more than unit tests or more than deployment, it was writing docs. And Doxygen came out and helped you with that process. So you've got this career class, right, where people have spent their time consistently thinking about how they automate what they do. I mean, I remember my sysadmin from 10 or 12 years ago, would spend about four days a week managing service. And over the course of three months, he got that down to a couple of hours a day using tools like called Capistrano and Chef. I don't even know if these things still exist now.

14:17And so he started to do much more creative work. And it's one of the things I was wondering about, that desire to automate, whether that is one of the reasons why tools like GitHub Copilot, but also Cursor and Windsurf and Replit and Lovable are growing so fast. If you look at the category of Gen AI tools and the general models, you know, the CLAWs and the chat GPTs are growing at about 20 to 22 % every three months. No other category is growing remotely as fast as that, image generation, text generation, except the coding assistant tools, which are growing 76 % quarter on quarter. I mean, still from a low base, a few million people every day logging in.

15:07I mean, to what extent is that just because software developers are, they like using software? To what extent is it because they're bound to this idea of automating their jobs so they can get onto the interesting projects? We've talked about history already a little bit. And the way Topfer developers have always worked is that they have tried to automate as much as they can of the workflow, but also they have moved up what I call the abstraction ladder. And 50, 60 years ago, there were still punch cards. So we would punch holes into a card because that basically a hole was, you know, transistor open and not a hole was transistor closed or the other way around.

15:49And then, you know, microprocessors came when Microsoft started in 1985. There was a very popular, it's funny to say these days, because it was like maybe thousands of devices in a very small scene of people, but where all of a sudden you could program the computer in a programming language. And so the first Microsoft product was BASIC. And BASIC, what BASIC did is abstracted the instruction set of the chip, you know, which is ultimately, you know, numbers in hexadecimal form, abstracted that into something that is human readable and is pseudo-English, right? If you look at almost all the popular programming languages, Python, Basic, Rust, they all have English keywords.

16:34The reason for that is that obviously our thoughts are expressed in the language that we speak, not in computer instruction sets. And so we abstracted the complexity of the chip into something that is closer to the ideas that we have, the features. But there was still a huge gap between the description and an instruction set. And over the years with open source components and higher programming languages and things like that, we moved closer, but we never got really there until GPT-3 came. And when OpenAI launched GPT-3 in 2020, they created a fine-tuned version of that called Codex, fine-tuned on open source code that for the first time allowed developers to describe their ideas in English and then later in German and almost any major human language.

17:22And then the model generated the code for me. And in 2020, that meant I could say, you know, give me a method to determine prime numbers or do sorting algorithms. And if, you know, if the listeners have gone to university and did computer science, they know that you have to learn all these different sorting algorithms, quick sort and bubble sort and whatnot. And then you never needed that again, because ever since you started your career in a company, you just use some library and do, you know, array.sort, right? And so we've always moved up that ladder, but all of a sudden with AI, we were able to get so much closer to how we're actually thinking, right?

17:58The language and the descriptions that we're thinking in. So I think that's number one of why the adoption, the diffusion of these tools has been so fast in software development because it finally got us to the step where we always wanted to be. But this arc that you describe, right, where we go from assembler language, which is, you know, I recommend people take a look at some if they haven't. I mean, it's pretty indecipherable through to higher, more sort of English natural language friendly languages like Python and Rust makes a great deal of sense. And then, of course, you move in towards open source and open source has these highly inspectable bazaars.

18:40They're not these uninterpretable cathedrals. You can put your library and other people can look at it and people can fork it. They can run their tests. There's a sense of trust in what's going on. But there is an argument that says, as we move to AI writing 400 lines of code for every line I write, that it doesn't become inspectable. I mean, a human couldn't inspect the source code in a modern jet plane, for example. No single human could. So we, you know, isn't there a case that we've gone over the hill, over that point where the languages were high level enough, abstracted enough that we could understand them to a point where we're going to be creating so much code so rapidly that it'll be less inspectable for the human?

19:30I believe we're already past that point. With or without AI, we passed that point a few years ago when it became clear that the majority of projects, commercial or not, are based on 90 %-ish, plus or minus of open source libraries, open source systems. If you look at what runs on a platform like Substack today, it's not only the product itself, it's all the open source libraries. And keep in mind, those open source libraries are maintained by millions of developers around the world that are not part of the organization that sells the product, right? That do not follow a work schedule, that do not the same trainings, that might decide on a Sunday night to push an update to the library.

20:13And so now all of a sudden, you effectively gave commit access to those people because they're part of your stack, all the way down to the operating system that almost nobody builds themselves. And even if you look into the Linux, Windows, or Mac OS operating systems, they're incredibly complex. It's very rare that a single person can navigate that whole code base. So what do companies do? They divide and conquer. And they assign subsystems to individual teams. And that's, you know, in some ways, the funny thing about software development is that what you learn in school and university is the basics.

20:50And then what you really learn is the craft through your journey. When you come into a company, you realize you almost never get to start a new project and start from scratch. You almost always, you know, get to maintain somebody else's work. that might be, you know, there's still many financial services companies that run on COBOL, which is a very old programming language that was invented when Eisenhower was the president in the United States. It runs on mainframes, which is a technology that was, you know, the state of the art in 1975. That still runs, right? And somebody has to maintain that.

21:26So we are, I think what you're saying is absolutely true. We're already at the state where a single person often cannot explain all the different parts of the system. And so AI actually gets us closer to that state again, because now you can just, you know, ask Copilot, you know, where in my code base is the feature implemented? What does this method do? What does that method in COBOL or the struct looks like in a more modern language like Java or Python? And so you can do these transformations. You have an agent, a coding agent that's always available to you. And, you know, this week at our build conference And here in Seattle, we announced the coding agent and co-pilot where you take an issue, literally like a human language description, and the agent does all the work in the background and submits a pull request.

22:12Now, I get that pull request. I still need to understand what that actually does, right? Like, how do I decide whether I can merge this or not? Of course, I can YOLO it, right? I can just, you know, only live once. How do you give some assurance to possibly a complex task that an agent has worked on for 45 minutes or an hour and make sure it's right? And, you know, how does a discipline, what used to happen, I guess, in engineering teams was that, you know, you might show your commits to your neighbor who's a peer of yours and say, this is how I approach it. They might ask you the questions. And maybe once a week, your team manager might sit down with you and ask you to walk through some of the things you've done as a measure or beyond whether you've passed the unit tests.

22:54But how does that team now work where you fired lots of things off to coding agents to go and build? Where do you get the understanding, the assurance from? It starts with the planning process, the process of describing what you actually want to implement and the key new skill that engineers, product managers, designers, whoever is using this orchestra of agents that helps us through our day, you will learn and internalize what is the right level of description that the agent needs to do actually what I want it to be. Now, of course, when you try out an agent like this, you can just give it a very abstract task and see what it does.

23:36And very quickly, we'll find out, and you mentioned earlier image generators. I think image generators are actually the perfect abstraction of that concept, right? Like the first time you used an image generator and you told it you want to render an image of puppies, or a computer on a meadow or something like that, right? You most likely didn't get exactly what you wanted. You got something that was close to the description and then you knew that, okay, I write another prompt and you try to figure out how do I change my prompt to now get closer to the image I want to get to. And the same is true for coding agents, right?

24:09You will try it out. You'll see, okay, it wrote something, but that's actually not what I wanted or it doesn't align with our standards here at GitHub. And so then you go back to a description and adjust your prompt. And as you learn that skill, you're going to get better on describing exactly the task that the coding agent can take. You know, run 45 minutes, submit a pull request, you review the code, and you're like, yep, this actually looks good and it does exactly what I want. And you will be wrong at times. You will be, you know, either too far away, and then you will have to work with the agent and understand, you know, how do I get it now to the point?

24:43And I think what will be crucial here is that developers will want to just take the code on your local machine, on their local machine, and modify it. Because there's always going to be a moment where you're like, this is three lines of code. I know exactly what I'm doing. Instead of me trying to figure out how to tell the agent to change those three lines of code, I just change it myself. So we will switch between the natural language layer and the coding layer all the time. But let me ask you about how this changes as the software changes. You've described that a lot of developers in the world are not working on the next TikTok.

25:18They're actually maintaining a customer database for a shoe factory. And they have to go in and do that work. And what you're doing is you're taking the technologies of tomorrow, which is AI, pointing it at the systems of yesterday and maintaining them. Everything needs maintenance. But of course, we're going to start to build new things. and the word agent, of course, is in vogue and software agents from you and Cursor and Replit and so on are all part of this system. But the nature of the software that companies are going to ask for is also going to change. You know, I would posit that if you're a big company and you've got a system of record like a NetSuite or an SAP, What you probably want to do because you've been basically stuck in this stack is start to build a layer of agents that do the things that you need for your customers, your suppliers, your team, without having to build traditional software.

26:24just talk to them through an API or through browser use, which is getting better and better, and abstract away those old, complex, almost kidnapper-style bits of software and move to a new architecture, which is ultimately about building more agents that work with each other. I mean, is that a reasonable direction of travel, or do you think I've simplified it to an absurdity there? No, I would actually follow your logic, but even layer it a little bit. You mentioned a number of these agents. And so let's say you and I want to build a web page where we sell shoes, right? You can just go to any of these agents and have it build the web page for you and it can even deploy it.