Azeem Azhar's Exponential View
Hosted by Azeem Azhar
Thomas Dohmke, CEO of GitHub, joins Azeem to explore how AI is fundamentally transforming software development.
10,250 words · 2 speakers
Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
Where 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.
You'll see commoditization of software that is so simple that recreating that on the fly will replace those test 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. All 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?
I believe you're already past that point.
My guest today is Thomas Domke. 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 a human writes. 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.
When 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 twenty and thirty percent of the code in our repositories was written by software. So it was a bit broader in how he framed it. I think the developer will do mostly what engineers actually do and how they define themselves, which is they're solving problems, they're implementing ideas. They're taking the big idea you have in the morning. It's Friday, nine AM here. I'm sure many engineers here in the US look 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 reading up
a GitHub issue or a specification or just taking what I have in my head and bringing it down into notes and models and systems like Copilot play the first role here where you can brainstorm with them and say, hey, 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 do this software decomposition part first and take a big problem back into smaller parts. And 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 operating 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. So 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 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 and I've gone off on the research. But you know, in those early days, you you started from a blank page. If it was in basic 10, you know, print hello world. And what's happened over thirty five, forty years is libraries, abstractions, reusable components. So as an engineer is assembling things almost like Lego, but not it's not as straightforward as a Lego.
But there is something different about about these AI tools. Or so we're told by the numbers that come out on, you know, grand stages at developer days. How has your own experience as an engineer changed as you've started to use the Copilot in in GitHub? Is there a behavior that you hadn't expected to take on?
I actually have some Legos in my hands and behind me too. In some ways, I actually think it is. 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 the thing that really changed through 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 know, you want to build something on a Sunday morning. And 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. Maybe you got to ten percent or five percent and you realize 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. Because when I started coding in the early nineties, it was books and magazines. And on a Commodore sixty four, I had to build it all, all from scratch, right? So we are already at the point where we are taking pieces in the 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. Where in the codebase we have to implement things. It runs command and the cool thing when it runs command, it actually can look at the error message and then see what is wrong on my system. And it might have to install another library or things like that. So it gives you more on 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 Substack.
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. Are 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 magic of flow state. Like you're in, you're almost in the zone of, 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 Copilot and Agent Mode keeps you in that zone of creativity and lets you refocus. Okay, I want to take this and implement it.
Similarly, 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. And that's where you normally 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. You 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. But 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, with just code, right?
So can I just, 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, a, a component of code, in order to know whether they've written the right thing, they should also write a test. If it passes the test, they've written the right thing, unless of course they've specified the test wrongly. So that was, that was one thing you described. The other thing you talked about were, were the idea of, of pull requests. This is really about how you file each iteration of your, 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. And they were meant to leave the, uh, the, the sweets trail i- 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. They become one with the, 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 that I don't think you see in any other other activities. Now, you're the you're the sort of developer advocate on this call. Is that a fair reflection of those three three ideas?
You hit the head on the nail. Uh, um, is that how you say it? You hit the head of the nail.
Or the nail on the head. I think either way, we're we're fine. We're friends here, yeah.
The hammer on the nail. Um, no, but like the, I think software development is a a combination of creative work of art. Something that's very similar to what an artist does. And it's also production, um, 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 and look like it was intended to be, but also from a code quality perspective. From a, does the, you know, the 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? So 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 what I'm shipping to my customers and and automate as much as I can on the production side. So to give one example, over the last ten, maybe twenty years, almost all production deployment has been automated. So it used to be, you know, in the late nineties and early two thousand, 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 to a box somewhere, then replicate that process and maybe had a script to to automate that to some degree. But that was a very manual process. If something went wrong, uh, your your page went down and and then you had to figure out what did I do wrong or what's up. Has a problem. Today, all you really do is you use this pull request that you described so eloquently. Where I submit my work for review by my team, they review it, automated tests are running, verification is running, and then I click a button that says merge and it merges 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.
Right. And so that's one such example where we have automated the work of a software developer. So with 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, I did last week? And I've been around so long, you talked about, you know, continuous integration and deployment as opposed to manual deployment. I remember the absolute excitement in with a development team I was working with. When we got something called Doxygen, which helped you create documentation. This is in the late nineties, 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 sys admin from 10 or 12 years ago would spend about four days a week managing servers. 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. And 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 and Lovable are growing so fast.
If you look at the category of Gen AI tools and the general models, you know, the Claude and the ChatGPTs are growing at about 20, 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 seventy six percent quarter on quarter. I mean, still from a low base, a few million people every, every day logging in. I mean, to what extent is that just because software developers are, they like using software? To what extent is it because they're, they're bound to this idea of automating their jobs? So they can get on to the interesting projects?
We've talked about history already a bit, a little bit. And the way software 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 fifty, sixty years ago, there were still punch cards. So we'd punch holes into a card because that basically a hole was, was, you know, transistor open and not a hole was transistor closed or the other way around. And then, you know, microprocessors came. When Microsoft started in nineteen seventy five, there was a very pop, 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, into something that is human readable and is pseudo-English, right? Like if you look at all, almost all the popular programming languages, Python, BASIC, Rust, you know, they all have English keywords. The reason for that is that obviously our thoughts are expressed in, in the language that we speak, not in, in computer instruction sets, right?
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 instruction set. And over the years with, with open source components and higher programming languages and things like that, we moved closer, but we never. Never got really there until G P T three came. And when OpenAI launched G P T three in in twenty twenty, they created a fine tuned version of that called Codex, fine tuned on on open source code that for the first time allowed developers to describe their ideas in in English and then later in in German and, you know, almost any major human language. And then the model generated the code for me. And in twenty twenty, that meant I could say, you know,
give me a method to determine prime numbers or do sorting algorithms. And if if, you know, the listeners have gone to university and did computer science, they know you have to learn all these different sorting algorithms, quick sort and bubble sort and 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 and and do, you know, array dot sort, right? And so we've always moved up that ladder. But all of a sudden with A I, we were able to get so much closer to how we're actually thinking, right? The 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 in software development because it finally gets to the step where we always wanted to be.
But this this arc that you, so this arc that you describe, right? Where we go from assembler language, which is, you know, I I recommend people take a look at some if they haven't. I mean, it's it's pretty indecipherable through to higher, more sort of English natural language friendly languages like like Python and and Rust. Makes makes a great deal of sense. And then, of course, you move in towards open source. And open source has these highly inspectable bazaars. They're not these uninterpretable cathedrals. You you can put your your library and other people can look at it and 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 four hundred 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, no single human could. So, 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, for the human.
I believe you're already past that point. With or without AI, we passed that point, you know, a few years ago, when it was became clear that the majority of projects, commercial or not, are based on ninety percent ish, you know, plus or minus of open source libraries, open source systems. If you, you look at what runs, you know, 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, you know, the, the organization that sells the product, right? That do not follow a work schedule, that do not the same trainings, that you know, might decide on a Sunday night to push an update to the library. And so now,
all of a sudden, you effectively gave commit access to those, 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, you know, Linux, Windows or or Mac OS operating systems, they're incredibly complex. It's very rare that a single person can navigate that whole codebase, right? So what do companies do? They divide and conquer, and they assign, you know, subsystems to, to individual teams. And that's, you know, in some ways, the, the funny thing about software development is that what you learn, learn in school, in university is the basics. And 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, 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. And so on mainframes, which is a technology that was, you know, the state of the art in nineteen seventy five. That's still runs, right? And somebody has to maintain that. So 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 the state again, because now you can just, you know, ask Copilot, you know,
where, where in my codebase is the feature implemented? What does this method do? What does that method in COBOL or the struct look, looks like in a more modern language like, like Java or Python? And so you can do these transformations. You have a, an agent, a coding agent that's always available to you. And, you know, this week at our build conference here in Seattle, we announced the coding agent in Copilot, 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. Now, 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 forty five minutes or an hour? And make sure it's right. And, you know, how does a discipline, I said, what used to happen, I guess, in engineering teams was that, you know, you, you might show your commits to your neighbor who's a peer of yours and say, this is how I approached it. They might ask you the questions and maybe once a week, your team manager might sit down with you and, and walk, ask you to walk through some of the things you've done as a, as a measure of, you know, beyond whether you've passed the, the unit tests. But how does that team now work where you fired lots of things off to coding agents to, to go and build? Where do you get the understanding, the assurance from?
It starts with the planning process, you know, the process of describing what you actually want to implement. And the, the key new skill that engineers, product managers, designer, whoever's using, you know, the
Orchestra of Asians that helps us all day. You will you will learn and internalize. What is the right level of description that the agent needs to do actually what I wanted to be? Now, of course, you can, you know, when you try out an agent like this, you can just give it a very abstract task and see what it does. And very quickly we'll find out, and you mentioned earlier image generators. I think image generator is actually the perfect abstraction of that concept, right? Like the first time you use 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 description and then you know 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? You will try it out, you'll see, okay, wrote something, but that's actually not what I wanted or doesn't align with our standards here at GitHub. And so then you go back to your description and adjust your prompt. And as you learn that skill, you're going to get better in on describing exactly the task. That the coding coding agent can take, you know, run forty five minutes, submit a pull request, you review the code and you're like, yeah, 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?
And 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 to change those three lines of code, I just change it myself. So we will switch between the natural language layer and the the the coding layer all the time.
But let me let me ask you about how how this changes as the software changes. You know, you've described that a lot of developers in the world are, you know, they're not working on the next TikTok. They're actually maintaining a customer database for a shoe factory. And they have to go in and do that work. And 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 Replid 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 systems of record, 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. Just 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 know, you mentioned a number of these agents. And so let's say, you know, you and I want to build a webpage where we sell shoes, right? You can just go to any of these agents and have it build the webpage for you and it can even deploy it and you'd never have to look at the code of that webpage, right? Because that's, it used to be called low code or no code. And a lot of these very simple things you can build without ever looking at the code. Now our shoe empire grows and now we have a full e-commerce store and we need a backend and a warehouse. Now, what started simple no longer scales and all of a sudden, you know, a million buyers come and the webpage is down on Black Friday. How do you figure out?
To make that actually work, now you need to go into what is actually the part of engineering, which is not, you know, building this quick webpage, hacking it together, is what we would use to call it. But figuring out how do I make this scale? How do I have the capacity on Black Friday? But, you know, don't waste a lot of money because servers cost money and that ruins the margin of our business when there is no demand. And so we have to build, you know, an abstraction layer in between. For example, for all the school pages to have the same design system, design components. And so when we decide, okay, you know, we're five years into our business and our brand color is no longer purple, but pink, you know, that we can just change all the design at once instead of having the agent go to every single page and modify that again, right?
So we gotta build a stack, an engineering stack, a platform stack that resembles our business. Another example is GitHub, we have a product called GitHub Actions, which is our continuous integration deployment service. And we're looking into how can we get that from 99.9% uptime to 99.99, so-called four nines uptime. That's not something you can just go and ask the agent, right? Like, well, this is an engineering problem that you need to solve. That is very similar, I think, in from a complexity perspective. If you're the mayor of a city and you promise everybody you're making public transport better, right? It sounds simple when you're promising it during the election and it's much harder when you're actually elected. And now you have to figure out, how do I change the city? How do I get the permits?
How do I build? Where's the funding coming from? And I think that is where you always want to have humans, humans that use agents and combine different agents. But you gotta know at which point in your day to day process, in your engineering process, you're using these agents for what purpose?
Okay, so I think what you're saying there, that point is that, you know, it's one thing to write small chunks of code that can do a function or a personal app, but embedded in what is effectively a complex system of enterprise software with thousands of functions and services where they can be quite brittle because one is very sensitive to how quickly it gets a response. And over the years, you've built in queues and other mechanisms to make sure the whole thing works. That is almost a Undocumented implicit knowledge that the senior engineers have of a system. Your contention is it'll take a while for AI systems to get there.
So we're going to see two trends, right? Today, you're buying software, you know, SaaS services, platforms like Substack. Because it's cheaper for you to spend, you know, a small amount of dollars every month on those platforms instead of all building it yourself. If building it yourself with an agent becomes so simple that you can just do that in a couple of minutes, you will stop paying for these SaaS services. You know, we will see a commoditization of software that is so simple that recreating that on the fly will replace those SaaS services. And one such example is Manus, one of the tools that became very popular in recent weeks. And I met with the founders a couple of weeks ago and they showed me how they were looking for an office in Tokyo. And so instead of just going to a real estate page and kind of creating a note sheet of what is interesting.
They had the agent create a map of all the available offices just for them, right? So it's personal software, it only serves that one purpose. Once they're found an office, they can throw that away. And whenever they need to find bigger space and whatnot, they recreate that software, right? So that level of software effectively has has lost most of its value. And it's only because the creation is so cheap. But at the same time, everybody using agents will create so much more complex software. Because they can now, with the same skill, with the same skills and the same capabilities, add features to their platforms like GitHub at an accelerated pace. And so hopefully, you know, you're still finding value in buying these platforms and paying, you know, for the service.
Because the complexity there is increasing as much as the simplicity commoditizes the more simple applications.
Yeah, I mean, it's very true. I have a really personal example. So my physio gave me some a program for a month. And I took the program and I threw it into one of these vibe coding platforms. So these are products you can go to, they've got a prompt, you type in a description. And it generates working code and it generated me a working web app called Build Back Better, which I thought was a great name for a back uh uh program. Uh and it's just for the four weeks that I've been using and tracking and and and doing the work. And I didn't go off and buy something. I didn't find something, you know, that that didn't quite fit fit my needs.
So you you start to see, you start to see things like that emerge quite uh quite quickly. And and you yourself talked about a world of a billion developers, right? So we currently have about fifty million developers and and you said, well, you can envisage this world of a billion. But that feels like a phase change, right? So what are a billion developers doing? They're not they're not debugging SAP, right? Or COBOL or DIBOL or in an IBM three seventy, right? So what what does that actually mean for there to be a billion developers?
We already have um a hundred fifty million accounts on GitHub. Uh now I'm sure there's, you know, some duplicate accounts and some bots and whatnot. But we are on a path, if you look back where GitHub came from seventeen uh uh years ago, when it launched in April twenty twenty two thousand eight. Now we're at a hundred fifty million. So you can just continue that exponential curve um and predict that by, you know, twenty thirty or so, we're going to be at the billion. From my perspective, the most important thing about this number is that we have way more than a billion computer users. In fact, we have more than a billion smartphone users on the different platforms. And a lot of that smartphone usage today is consumption. Um you're downloading an app um or you're just opening a browser or you're you're watching videos and reading reading text.
And that's actually is different to what computers were fifty years ago. When when you when you bought your first, you know, well, PC wasn't around, but like microcomputer and then uh uh. And where you started with creating software, right? You had a basic prompt on a Commodore sixty four and so you had to learn a little bit of coding. And I think we're going back to that, that we are every, every consumer is also being empowered to be a creator. Just like you're using your camera already to create on these phones and, and your email app and, and whatnot. And I think that's crucial, that it's important for us that these devices let us create whatever we want to create. And the programming language is not in the way of that.
I love that, that picture. So let's play around with what that might, might look like. I mean, the tools are pretty good today. I don't think they're quite, quite there for a billion people. You still, you know, the, the agents still make mistakes and you need to know a little bit about CSS styling and other, other types of questions. When you, you know, you look at the preview, but it, it is really, um, you know, enlivening in fact. And I, I wrote my first code, uh, for the first time since two thousand and twelve. I had been banned by my engineering co-team from writing any more, more code back then. Uh, and I had to set up a new GitHub account and this code does one thing for me. And it's a little extension on my browser that allows me to count the number of words I've highlighted.
And there are lots of word count extensions in the Chrome store, but they all have other features I don't want. And this one I've been able to run. I just got Claude to write it for me. I got ChatGPT to check there were no security problems. And, and it's been amazing because I haven't been able to do that for fifteen years. But you know, you work with, you work with developers all the time. That's been your life. So what happens when a billion of us are able to do that, right? How are we interacting with our, with our computers and with each other?
So that's the other side I see is, um, you know, we have a billion, well, we have more than a billion, way more than a billion people that learn math in school. And, uh, they learn reading and writing in school and they have arts and sciences and physics and maths and all that. But most folks then after school, most students after they leave school pursue one career path and just because they had, you know, math in school, that doesn't mean they don't become a mathematician. Now, that might also be because that's something where you don't make a lot of money as a mathematician. But you get the idea, right? We're teaching our kids the fundamental skills of life and I think computer science is part of these skills. So that's number one. Like, we need actually every human on this planet to understand
the basics of these devices that are so dominating our lives and it will only get worse from here. Um, you know, the future-
Or get better perhaps, depending on your perspective.
Well, better. Yes. Sorry. That was you, the optimist, and me, the German realist. But like, worse in the sense of we're going to have software and computers everywhere in our lives. If, you know, self-driving cars and our alarm is a software and our house is controlled by software and travel is controlled by software, all that. And so then there's the intersection of you can do it because you have learned it, or you want to make that your career. You become a professional software developer. And I think that that is a Venn diagram that will never be perfect because not everybody in this world wants to be a software developer. You know, people want to be outside, people want to be in the kitchen, you know, becoming a chef, they want to build houses and whatnot.
But to take your example now, you know, the builder that works on your house to build your new deck or whatever, right, will now probably build software for your project that is between you and him or them and that, you know, the crew. And that software will be there for the part of the project. So you don't have to create an account for some platform, you don't have to accept the terms. And maybe there's still a billing platform and credit card stuff and because that that will always be simpler through something that's standardized. But you're going to have a personalized piece of software and I think we're going to rethink these devices and you see some, you know, folks in the industry already doing that, where a lot of that is more like an agentic interface
that is highly custom for you instead of having a grid of icons.
You know, there was that no code movement some years ago, which the people who aren't developers meant that you could build applications without, just by joining blocks together. And actually, when my house was renovated, I did in fact build an app for it. So when when you take the house over from the builder, you have to go around and find all the snagging, right? Where did the paint not finish? Where's a door not closing properly? So I built a little app using something called Airtable, and you could take photos of it, of the thing, and it would get dropped into this database. And then we printed it out and gave it to the builder. And it was an incredible feeling back then to just produce this thing. It was time limited. It came and it went.
But the thing is, of course, a lot of the hundred million people who are on GitHub and the fifty million former professional software developers make their money by writing software that is built and used by many, many people. And we pay fifty dollars for it or a thousand dollars for it. So in this world of a billion developers, don't you naturally suppress the wages in the coding community? Don't you dampen down the number of formal roles that are there? Because I'm not buying downloading an app on the App Store now because I can just quickly whip up the thing I need.
You're not downloading an app from the App Store, but you're building your personal applications that are connecting to what we call the agentic web, you know, servers, APIs, application programming interfaces, you know, information stores, databases, payment gateways, all these, the models itself, you know, and GPU clusters and around the world to actually enable all this. Right, so there's going to be the infrastructure that enables you to build that app. Of course, you're still going to buy some device. And as a good nerd, you're buying a new device way too often. Way more often than you actually need a new device. And that device runs an operating system and has connectivity that connects to that,
you know, agentic web backend. I think what will go away in the sense that nothing actually ever goes away. But will fade more into the background is this notion that everything has a highly branded webpage. Like, take, you know, an example, like, I'm going to Paris uh uh in a few weeks. And and today, when I booked this trip, I I go, you know, to to a webpage to book my my plane ticket or train ticket and then book a hotel on a different webpage. And uh I book a rental car or driver. And so three times I've entered the same from to date and have accommodated for when I arrive and when I leave. And and looked at my calendar fifteen times. Why can I just not just go into my agent and say, hey, I'm going to Paris?
You know, this is the and describe in natural language what you would actually describe to the human travel agent. And then the maybe it builds even a webpage for the trip. And and so you have all your bookmarks there and all your images, uh highly personalized. But all these pieces, all these features connect to to infrastructure and to to processing, to ultimately whoever is selling you the service. Because it's not like you're having an agent that builds an airplane that that flies to Paris. Uh although that would be kind of cool if that exists. The world that we as humans enjoy is still mostly physical. And it's mostly based on services provided by others. And even if you like, you know, making your own food at home, you still have to buy groceries. Uh because you're not growing all these in the garden.
But even if you grow all these in the garden, then you have to buy, then you you are good customer from depot to to get all the gardening materials and the tools, right? And so the same is true for software. There's always going to be some part of the stack that the professional software developer companies like Microsoft, Google, uh you know, and so on, to provide to you. What is really changing is the way you engage with that stack. And instead of taking off the shelf apps, you're going to have personalized. And I think the misconception is a little bit that we're just replacing existing apps on our home screen with new apps that we built for ourselves. I think it's much more on the fly that you're engaging with your agent. You know, Tony Stark in in Iron Man has Jarvis and effectively engages with Jarvis his computer only through natural language.
But every time he needs something, it it has this hollow image screen in front of him. And and he can see how how how, you know, he can build a plan machine. And so I think this is. How I'm thinking about agents helping us to build software for your house, you know, for my Paris trip, but it's built on top of a stack that's provided by a technology industry. And I think that technology industry will sit on so much more complexity and so much more scale because now a billion people generate software that connects with those APIs. And any, it's almost like we are enabling a world where the humanity constantly runs the distributed network of service, DDoS attack against the whole tech industry, right?
And so the scale that you have to build, and that's why companies like Nvidia, you know, have been thriving so much over recent years, the scale that you have to build is magnitudes larger than what we have today.
Well, and what you're describing there is, you know, a fundamental shift of the web, right? You can't call it a re-architecting because there's no architect. It's going to, you know, come bit by bit, step at a time, where the web has really been built for people. We've had APIs on the web that allow computers to talk directly to particular resources. But essentially, you know, the starting point of the web actually is the mobile view, right? Then it's the web view. And then you think about the API. But those first two things are not really useful for agents at all, right? They don't need to see, and in fact, what you're starting to see emerging from the startup community are many, many tools
that effectively agointify webpages. So they take these beautifully designed webpages for humans, a module runs over them in order to reliably allow an agent to programmatically get information or put information into it. And at some sense, and this may have been Satya who said this, but it was, it may have been somebody else, that essentially, software is a user interface stuck on top of a crud system creates, read, update, delete, you know, database. And in a way, what you're describing is that sort of thing where I might be the person who has the really great data on food composition, and you might be the person who has.
Great data on room availability in in London, in European capital city hotels. And the agents will come in and query that to to then build the experience that the the end user, that the end user has. It's a fundamental shift for the from the web because the web has been largely paid for by human attention on human constructed pages or pages constructed for humans. So just, you know, you're a master of change management because you've worked with the software industry for a long time. So talk us through the steps from this human oriented web funded by human eyeballs to
an agentic web, which is about this intelligence autonomous infrastructure that my agent or agents can interact with to build my experience.
The most crucial thing, especially as my in my my role as CEO of GitHub, is you've got to meet, you know, the customer for us that's software developers, you've got to meet them where they are. You've got to bring the products where they're already doing, you know, their work. It is much harder to convince you, you know, to change everything in your in your in your on your computer or in your life, in your house, because I to convince you of that new future and ultimately sell you that future instead of telling you here, install this into, you know, your existing environment and you get AI features. And, you know, when we launched Copilot in twenty twenty two, we didn't even focus on this, there wasn't generative AI, it wasn't a high. And so we mentioned, we called it the AI pair programmer, but ultimately it was positioned
as something that makes your coding experience a little bit better. And it was very much in the background in the IDE, which is the, you know, the editor. And when you typed it, it gave you a suggestion. The flip side of that is that you've got to, you know, have a vision, we often call this the North Star, of what that future looks like. And the challenge, you know, specific with AI is that there's two camps, there's the one that believes, you know, the artificial superintelligence or general intelligence is coming, and that's just replacing everything as we know it because it's going to be so intelligent that, you know, it does. Doesn't really make sense to even write, you know, have an editor anymore and and C code. And and maybe that future is coming, I don't know, but we certainly don't know how far away that is.
And that's that's tricky if you're running a business today. And the other side of that is that, you know, you gradually get closer to that future. But every step of the way, you're making smaller innovations to what you believe is realistically achievable in the next in the next three to five years. And even that is moving so fast that you're going to be off. And so in in software development, you know, we've been calling this agile development for quite quite a while. Where we are today in technology means you have to be incredibly agile. 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 of a really small boat and that can turn very small circles.
And so I think finding that every single day, finding the energy, finding the motivation, finding the steps that we need to take to have this agility, even though we're running this large ship, that that is what what is required in this world of AI. And let me give you one one last metaphor, because we talked a lot about this is like we we have seen self driving cars. You know, whoever has been to San Francisco has hopefully been in a Vemo to see what that is like. And today, most American houses in in the suburbs have a two car garage. And so, you know, a significant amount of space on our lot is taken by that garage. Now, I could already start building houses without garages in the in the in the aspiration that soon enough,
you know, Vemo and and similar cars will be everywhere. And I don't need a garage anymore. I can have a much bigger Lego room in my house. But reality is we're not at that point yet. And so I can't do that yet. I can have that dream and that vision, but in the meantime, I still have to build garages and then and and work work our way into that future that we're seeing. And I think that's the the fundamental balancing those two, the the vision, you know, the aspiration of where the world is going with where we are today in reality, and then making incremental changes at a very fast pace. That is What allows us to to stay ahead in the world of in the age of AI.
I I'm gonna I'm gonna pick up on that in a second. I want to think about something that you said about your customers. Because you're close to your customers, to the software developers and GitHub hosts millions of pieces of software. Uh, many of which are publicly accessible. And so, you know, what a lot of investors do, I remember doing this myself. You see which repositories are growing really quickly and you get in touch to the the guy who's written the woman, woman who's written them CFL, accept your money. And and I remember a year or so ago, uh, that um, Agent G P T, which was this framework for building agents using G P T four. Was getting all the stars on GitHub, which is like, I guess it's like a Tinder swipe right, right? Lots of those swipes happening on it.
Really, really popular. And it allowed people to say, well, that's where the smartest developers are kind of veering towards. So looking at what you're seeing across GitHub, right? What are the little hotspots that are going to be really exciting? In the next six months and a year, because you're seeing the smartest of your developers star clone fork uh repos.
This weekend is the Formula One race in Monaco and Saturday is qualifying and Sunday is the race. And what you described is you look at what the qualifying result is and you assume that that's also the result of the race. Now, that may be true for some races where you can't overtake, although now they do two mandatory pit stops. We'll see what that's like. Uh, but it scratches a bit off what what, you know, the world that you see is there is a lot of great ideas out there. There's a lot of projects um that have really uh, steep adoption curves. That doesn't necessarily mean that they're winning and vice versa, you know, can have a winner that comes from behind and and was in the shadows for a while.
This goes back to what I said earlier. The crucial piece is that you gotta keep it up. In software, there's no stable state. The world is always changing. What is the, you know, the the new shit today is is going to be outdated tomorrow. And and we see this in AI even faster than we've ever seen it before. And so it means no matter, you know, what project you're looking at, you gotta see, okay, so what are they doing? Next and how often can they keep up with the work? And that is as true in the enterprise and or in the commercial software space where you keep your source code close. Then it is in the open source space. And you know, the best, the best way I can describe this is like they're all playing Minecraft. There is no ultimate win. There's little mini wins that you have, but you're playing an infinite game.
You're playing an infinite game and survival, survival and staying, you know, staying on top of it. That is actually the, that is actually the skill for, for software engineers and the groups, you know, that they're forming to build companies.
I mean, I think Steve Jobs said that the computer is the bicycle for the mind. If the computer is the bicycle for the mind, software, I suppose, are the unending roadways and hills and places that you, you, you can travel. Thank you for your time. One last question for you. I know you talked about Minecraft. You, you love Lego. If we could bring these two things together, Lego and AI, what would be your fantasy agent? What would you want that had to merge those loves of your life?
The magical thing, I think for every Lego enthusiast is that I can give it all my unsorted Legos. And it perfectly sorts them by size and color into the, into the container store bins that I have upstairs. There is an app on smartphones that does that to a smaller degree. But I would love kind of like, like a little machine, you know, maybe it's the size of a dishwasher and you just put all the Legos on top of it. And it sorts them all into the bins. And so you don't have to do that yourself. That's the nature, I think, especially for parents at home. The magic of Lego is that you can take it apart and reassemble it in any, any possible way. But the more, that also means you're creating entropy. The Lego room is always going to have entropy.
And then bringing the entropy back into, into order is the, the, the. And the funny thing is, you know, if you take that into software, that's exactly the same for code, right? Code also has entropy, like code, code bases always get worse. Even if they're stable, then they get worse because the world around the code base is changing. New libraries, new operating systems and so on. So keeping the code, you know, organized and clean and healthy and scalable. That is what, what engineers are looking into with these agents. And so they can then use their time, their creative time to build something amazing.
Thomas, on that chaotic note, I'll also get you a humanoid robot to load your Lego sorting machine at some point. Thank you for all of your time this morning.
Thank you so much for having me.
Page updated November 3, 2026 · transcript and summary are machine-generated