270 Audio.mp3: Audio automatically transcribed by Sonix

270 Audio.mp3: this mp3 audio file was automatically transcribed by Sonix with the best speech-to-text algorithms. This transcript may contain errors.

Thomas:

If you use Coding Agent, all you do is write the prompt. The prompt is a longer description, so arguably you're writing natural language to describe the problem you're trying to solve, and then Agent Mode or Coding Agent writes all the code, and so for certain scenarios it's 100% code written by AI, but you still have to write, you know, in English. So arguably, human language is becoming the universal programming language. In the future, the developer will have an orchestra of agents and the role will be to be the manager or the conductor of that orchestra, and I think, ultimately, the biggest skill for developers, other than understanding technology and the craft of engineering, will be to decide am I doing it myself or am I using an agent, and at what point do I have diminishing returns to assign these three lines of code to an agent instead of just doing it myself?

Craig:

Building multi-agent software is hard. Agent-to-agent and agent-to-tool communication is still the wild west. How do you achieve accuracy and consistency in non-deterministic agentic apps? That's where agency comes in. A-g-n-t-c-y. The agency is an open source collective building the Internet of Agents. And what's the Internet of Agents? It's a collaboration layer where AI agents can communicate, discover each other and work across frameworks. For developers, this means standardized agent discovery tools, seamless protocols for interagent communication and modular components to compose and scale multi-agent workflows. Build with other engineers who care about high-quality multi-agent software. Visit agencyorg and add your support. That's A-G-N-T-C-Y. Dot O-R-G.

Thomas:

Hey, I'm Thomas, and I'd like to say I'm not only the GitHub CEO, I also am a developer, and I've started coding more than 30 years ago, in the early 1990s, first on an East German clone of a Z80, and then on a Commodore 64 and later a 386 PC. I've been a developer since my mid teens, I guess, and through different parts of my journey, I ultimately landed first at Microsoft, who acquired my startup in late 2014. And then I was part of the team that acquired GitHub in 2018. Actually, now, today, as we're recording, this is June 4, 2025. So we're exactly seven years after the announcement that Microsoft will acquire GitHub, and through that announcement and the acquisition, I joined GitHub and GitHub's leadership team in October 2018. And then became the CEO three and a half years ago.

Craig:

And so you were living where in East Germany, before the wall came down.

Thomas:

In Berlin. So I grew up in Berlin. You know one of the suburbs that has all the prefab buildings called Marzahn, or Marzahn in German. So I grew up there. You know, I had a, you know was 11 years old in 1989 when the wall, you know, technically fell, quote, unquote. And then, you know, as the Germany got unified in 1990, I finished high school in 97 and started a technical university in Berlin in 98 98 and then moved down to Stuttgart to work for Mercedes. And so ever since I left Berlin in 2002 and haven't been back other than for, you know, a few business trips and to see the family.

Craig:

And you said you began coding on the C-Strom and clone. Was that before the wall came down?

Thomas:

Yeah, I think my history is a little bit muddy on this. To my memory, we discovered in the geography lab these Robotron computers, which were East German-made computers but very similar to Commodore 64. You would start with a basic prompt and then load I think it was cassette tape in school. You would load software with a basic command and so we started coding on that. And then the community center in the suburb had these same computers and we started going to computer club.

Thomas:

I don't know when. I think that was after the wall had fallen. Obviously the suburbs and Berlin itself didn't change as rapidly as it now feels in hindsight, and so a lot of things were still like following the East German system. I think the education system only switched in September 1991, given that the unification day was October, which was after the school 1990, which was after the school had started. So there was another year from 1990 to 1991 where we were still in the East German education system, even though technically the country had already been unified, and then only in 1991 that we switched to the West German system.

Craig:

So GitHub I mean, I think of GitHub still and I'm not a coder as a code repository, but it's become much more than that. Can you give us just a thumbnail history of GitHub's development and then we'll talk about some of the new things that you guys are doing?

Thomas:

I would argue GitHub was always more than just the repository. The repository is the foundation, the primitive, as we would say. That has enabled you know what you might now call modern software developer collaboration. But essentially he invented how developers work with each other. And in October 2007, I think, is when the founders of GitHub, chris PJ and Tom, started working on it. The founders of GitHub, chris PJ and Tom, started working on it a few years ago. We celebrated that by creating a poster that has the first 10 or so commit messages on it and, as you may imagine, a lot of those were kind of funny because obviously the founders at that time didn't realize what they would be building and how important that would become for the world. It officially launched early 2008, depending on whether you count the preview or the actual release, somewhere between February and April.

Thomas:

A lot of the early users of GitHub were in the Ruby on Rails community, given that the GitHub founders were coming out of the community in San Francisco. Founders were coming out of the community in San Francisco and it started really as repositories. The pull request wasn't actually there in the beginning, but it came very, very quickly, but it already had. Like you know, it's hard to think about this now as something revolutionary, but in 2008, being able to see a repository in a browser interface, clicking on it, it was actually fast. It had a nice, modern user interface. That alone, I think, created a lot of attraction for folks to say I host my repo on GitHub, it's easy to set it up, it's easy to push my code and then I can just go there and click through the file tree and see the history of the files and the commit messages and so on. So repositories was that first building block.

Thomas:

Collaboration with pull requests that GitHub ultimately invented was another one. Before the pull request, open source maintainers would send diffs you know files with changes around and then apply those changes locally to merge them back into the main repository. And later came issues and wikis and all these things that developers need to collaborate. And today I think what defines really GitHub is that whether you're an open source developer or a commercial developer, whether you're working on a startup or a hobby project, all that software development process is very similar to each other. While we think about these as different worlds, they're actually not that different and oftentimes, you know, the four things I described are all the same person and just in different times of the week. You know they're doing open source, they're doing doing hobby projects, they're working maybe on a big idea, and then they they also have a job where they're using github yeah, it's always fun to look at people's profiles and all the the different things they're working on.

Craig:

What just for for the kids out there? Uh, what, what? Where did people put their code before GitHub?

Thomas:

That's a. You know, there's many ways to answer that question and the funniest, I think, is that you would just put it in a folder on your computer and then you have a V1, v2, or you know date and time stamp, and then you would realize three days later that you didn't actually do that, and then you lost a lot of the changes or you can't hold back to what you wanted to do. I actually think this is, even today, still pretty prevalent that people just do that if they're early in career or if they're working on just some of their first steps in software development. A lot of the code is just stored locally.

Thomas:

The origins of version control systems is probably like a history podcast in itself. There was something called CVS, which was the most used version control system, and I started coding and during university. And then Subversion came out and that was very popular and SourceForge was kind of like the place where you put your Subversion repository to share with the world. And then Git was developed by the Linux kernel team, linux Torvalds and others, and Mercurial was the competitor at the time and clearly Git has won that race. But in 2008, when GitHub launched, that was still a question Is it Git or is it Mercurial? But a lot of the early GitHub users came from SourceForge and from Subversion and even today we're still migrating customers of their old Subversion repositories into Git and GitHub.

Craig:

Yeah, yeah. And again for listeners that aren't coders, describe what a Git is and what GitHub did for Gits.

Thomas:

In its most simplest form.

Thomas:

I think the way to look at Git is that it stores changes to the text files that you're writing, and developers, obviously, as they're writing programming language, they're writing files, plain text files with code in it, and Git stores the changes that you make to that file at the time when you commit into the repository, and so it's version control.

Thomas:

It's the history of all the changes, and nowadays you know Invert and Google Docs and elsewhere you can also go through the version history.

Thomas:

But that wasn't always the case, and the significant change of Git, compared to other version control systems that came before it, is that you have all the repository on your local machine and it's a decentralized technology, so you can have a copy of the whole repository with all the, with all the branches and all the changes.

Thomas:

I can have my own local copy, and github offers us a place where we can bring those together and, where I can, I can push my changes and you can pull my changes, and we can both collaborate on the same repository with each other. And so GitHub, as the name implies, offered the central place for all these decentralized repos so we can share them with each other, because, as much as we like decentralized technology and like to talk about this decentralized world, the reality is, you still need a place, a home, if you will, to go to and we're calling GitHub the home of all developers because we believe that that's our aspiration if you will, to build the home where every developer goes and likes to collaborate with others and meet with them and exchange code.

Craig:

So let's talk about some of the new features that you've developed. Particularly, you've been very active this year. What is top of the list for you?

Thomas:

AI clearly is top of the list Otherwise I wouldn't be on this podcast, I think. And it's interesting because we talked about Git and GitHub. And Git is a technology that wasn't invented by the GitHub founders. It was invented by the Linux kernel team and then the founders took that a few years I think two years before GitHub and then the founders took that technology and built GitHub. And the same happened to us again with Copilot, where a technology was invented by Google you know the transformer model and then taken by OpenAI to build back in 2020, gpe3 and a version of that model fine-tuned, called Codex, fine-tuned on open source code, and we at GitHub at the time got access to this model through the partnership between Microsoft and OpenAI and started playing with it and asked questions how to write a method that detects prime numbers or sort an array Typical kind of like lower entry level coding questions for students in university and it was able to write these code examples in proper programming language and in fact, it could do that in different languages and would not mix things up between you know some languages like have parentheses, other have curly braces, some have commas, other have, you know, colons and whatnot have curly braces, some have commas, others have colons and whatnot, and that led us to the idea of building a product around this, which then became Copilot, and in its earliest form it was really simple. It was just auto-completion in the editor. So where developers write their code and where they're using Git, you know, to create the version history of that code, they would now get a suggestion from this Codex model or, in general, the large language model, and the suggestions wasn't just like the next word or the next few words, it was multiple lines of code.

Thomas:

You know a lot of developers. A lot of what developers do is writing test cases and writing what we call boilerplate code things that you repeat over and over again. You know making rounded corners so your user interface looks nice and so on, and so it could predict that code and, as such, it kept developers in the flow. Right, your editor and the browser, or the editor and documentation, or the editor and asking you know somebody in your office or, in 2020, I guess you know on Slack or Teams?

Thomas:

Copilot gave you enough of an idea of what you could do next, even with hallucinations and all that, that you could just keep staying in the flow, and often this flow state feels really magical for software developers. It's kind of like I have this idea and now all I need to do quote unquote is just to take this idea and write down all the code to build what I have in my head. And so, five years later, we're still working on that and there's still a lot of innovation happening in this code completion space of predicting what's the next change after the current change, what's the next change in adjacent tabs or just making the model better. But ultimately, where we're heading into is agents and building agents that developers can use to write code we call that the coding agent to review code, we call that the code review agent or to fix their security vulnerabilities, and we call that the autofix agent.

Craig:

Are all of these under the GitHub coding agent umbrella, or is the GitHub coding agent referred to one of those?

Thomas:

It's all under the GitHub Copilot umbrella. So you know, the way to think about Copilot is it has all these capabilities and we're adding more. So, just like a human developer, you know, the Copilot as a developer learns more skills and gets better in each of them, and so Copilot has a coding agent, a code review agent, an autofix agent. It has auto completions. It still has chat, which is often quite useful. I have two sons. They're both coding in Python and so they're using Copilot, you know, to fix their own bugs instead of, you know, coming into my office and asking me, and often chat is the better way for them to learn than just having the agent do it, because they understand. Then you know from the description and the code example of how to make the change instead of just magic happening to them.

Craig:

Yeah, actually, how old are your sons, and did you teach them to code, or have they learned on their own or at school?

Thomas:

They are 13 and 10. And it's a mix of all these things that you said, so we encouraged them to learn, especially during the pandemic. I think typing was the tool they used to learn 10-finger typing. I think they can do it better than I, actually, because I never properly learned it and so it's more like eight-finger typing or seven-finger typing, and they use Scratch from MIT and Lego Mindstorms, which has a very similar interface as Scratch, like you know logic blocks and whatnot.

Thomas:

They learned Python in school, although the eldest learned Python in middle school and then the rest, you know. They taught themselves very similar to how I taught it myself in the 1990s, except, you know, I only had books and magazines and they have the whole range of the internet and that's incredibly powerful. You know, even without AI, just go on to you have a problem. You know. You're trying to figure out how to do.

Thomas:

I don't know animated sprites in Python and Pygame and you can just find a YouTube video for that.

Thomas:

In fact, you know, my kids also taught themselves. You know, to solve the Rubik's Cube by just watching YouTube videos, right, and of course there's a lot of trial and error. But that is very similar to how many of us learn coding. And then Copilot gives you this, you know, extra step where it can look at your code, explain it to you not only in English, but actually also in German and other languages which my kids speak both languages, given that we immigrated in the United States more than 10 years ago. But even that I think is incredibly democratizing that as a seven, eight-year-old, if you want to learn coding, you can just ask it in your mother tongue and it will explain to you. Okay, this is you need to open a file, and then this is where you put the Python code and this is how you run it, and now you have a snake game, and I think kids are in many ways, actually better at this than adults, because they are. It's so natural to them to just keep trying right.

Craig:

Yeah.

Thomas: They just keep trying, they just keep asking. As a parent, you quickly run out of patience or daytime, but kids will just keep asking Copilot or ChatGPT or any other AI tool, and they will not sit there and say this is bad or I could do that way better without the model, no, no, they will take the feedback and work with whatever co-pilot gave them to make that thing work.

Craig:

Building multi-agent software is hard. Agent-to-agent and agent-to-tool communication is still the Wild West. How do you achieve accuracy and consistency in non-deterministic agentic apps? That's where agency comes in. A-g-n-t-c-y. The agency is an open source collective building the internet of agents. And what's the internet of agents? It's a collaboration layer where AI agents can communicate, discover each other and work across frameworks. For developers, this means standardized agent discovery tools, seamless protocols for interagent communication and modular components to compose and scale multi-agent workflows. Build with other engineers who care about high-quality multi-agent software. Visit agencyorg and add your support. That's A-G-N-T-C-Y dot O-R-G.

Craig:

Yeah, a couple of questions about the Copilot coding agent. I mean, it's a tool built for coders, but for non-coders coming into this world, is it reliable enough that a non-coder could open up the Copilot coding agent, ask it to begin coding something with chat and because, as I said, I'm not a coder myself? When I when, what was it called back then? You know, ancient history is like three years ago the first of these that came out. I can't even remember what they were called, but you know, you ask it to code something. You then copy it into you know Visual Studio or whatever ID you have. You run it, you get an error, you cop the error back and you go back and you just end up going down a wormhole and never get it resolved. So is I mean, where are we now with these agents? Is it to the point that a non-coder could start using them?

Thomas:

Yeah, I mean there wasn't even Visual Studio when I started. You had basic or on the PC it was Turbo Pascal, and Turbo Pascal that actually ran in DOS, not in Windows, and then to run the application you would move Turbo Pascal or on Unix back then it was VI. You would move that into the background, type the comment line command to run the thing or compile the thing. Then you run it and you get an error message and you have to figure out okay, so how do I bring back the editor? And you wouldn't even see the error message and the editor. Side by side.

Thomas:

Those things were on separate planes, if you will, although there wasn't Windows, right, like it was all you know Today. I think the state of the art is and the answer to your question is both. So, as a non somebody who doesn't understand programming language, you can use tools like Copilot and I you know. Maybe I should explain what the coding agent is, but you can use Copilot and there's a bunch of others out there, like Rocelle has V0 and Lovable Bolt.

Thomas:

Some of those do similar things, which is they can write and actually OpenAI has Codex now can write a prompt and then it creates all the code for you, and especially in web development, like create a quick web page or a small web application, even a little game, as long as it runs in the browser, you can easily create with these things and you can keep going with more prompts.

Thomas:

In the same way that you can keep going when you want to render an image in ChatGPT and you don't like the first version of that image. You keep going writing more prompts and eventually you either get there or you're like okay. So I got so far off what I had in my head that it's easier to start from scratch, and I think that's between an image model or an image you know generator and a code generator. It's very similar Like or an image generator and a code generator it's very similar. You can get a long way. But if you don't have knowledge of the programming language and how this all works behind the scenes, you're going to get into a place where at some point a prompt doesn't get you where you need to go.

Craig:

Right.

Thomas:

And certainly when we think about scaling this then to millions or hundreds of millions of users, at some point you certainly have to go and become a professional developer or hire those. The other piece is that and often this is called vibe coding right, you're vibing by creating this, but you're always, I think, going to reach the point where now you have to learn what actually was generated by Cop this. But you're always, I think, going to reach the point where now you have to learn what actually was generated by Copilot and to understand whether that code is actually doing what you described you wanted it to do. And that's even more true in professional environments. When you join a company that builds software, in 99% of the cases you're taking over somebody else's code. Yeah, and you're working, or you're working on a project with you know that had dozens, if not hundreds, of developers already on it, and so working on an existing code base. And that's where the coding agent comes in.

Thomas:

The idea of the coding agent is that you describe the changes that you want to make to the existing code base and you assign Copilot to it, and then Copilot in the background, aka in the cloud, spins up a virtual machine that checks out the code, it installs all the dependencies and all the tools it needs and then it tries to figure out, with the help of the model, how it implements the issue or the task that you described.

Thomas:

And as it does this, it submits code into a pull request, just like a human developer would, and it describes how it made these changes and how it went through its plan. But then you need to come in and say, okay, this is actually what I wanted and this fits into the coding practices of my team, and it uses the right database and the right cloud provider and it doesn't introduce any new security vulnerabilities. And that's where a professional software developer will always have to understand the code that the agent generates within the project they're working in. So you're sitting on the spectrum of if you want to do something without coding, just to spin up you know your wedding webpage or, like a quick e-commerce shop connected to Shopify, you know to sell something on Black Friday, that definitely will work. But there is a on that spectrum. There is a point where you have to then also understand the concepts of computer science, computer engineering, to ultimately be a professional software developer, and that profession isn't going anywhere.

Craig:

Yeah.

Thomas:

It will continue to exist. And it's going up, it's not going away, is, I guess, what I'm trying to say?

Craig:

Yeah, yeah. And what you describe a software developer coming into work on an existing code base. Does Copilot Coding Agent how much of the code base does it review before it starts making suggestions? Or operating in a virtual machine in the cloud, because you know there's so many you change something, it could have implications that you don't see in the amount of code on your screen. Yeah, so does it review the entire code base? See in the amount of code on your screen? Yeah, so does it review the entire code base, or do you choose how much for it to see? Or how does that work?

Thomas:

That's actually fascinating. You know to observe for different types of issues assigned to the coding agent. So it works. You know in many ways like a human developer would work in the code base. So it checks out the coding agent. So it works. You know in many ways like a human developer would work in the code base. So it checks out the code base, you know it reads, you know the description of what it needs to do and then it feeds that into the model to generate the chain of thought.

Thomas:

And as it does that, the model is allowed to call tools and these tools can be things like using code search to find code within files, to identify the files it needs to modify. It can be tools that it runs on the command line to install something or to update a package or maybe even add a package. And what it does that comes out of the chain of thought that comes out of the model as it describes how it would solve that problem. But the key here is that it then looks at the output of these tool calls and trying to compile the thing. Or it can use the technology called MCP model context protocol that was invented by Anthropic. That lets it effectively connect to every other system that already has an MCP server. There's one for GitHub and one for Figma, which is a design tool, and there's even one for, you know, can have it connect to your Apple notes or whatnot on your local machine, and so it effectively works like a human developer tries to figure out within the code base how to do the task, and then it iterates on that with the help of reasoning and the chain of thought and until it ultimately gets to the point where what it has generated compiles and fulfills the test cases it created. And then it submits that for code review.

Thomas:

But obviously you know that's never going to be perfect, right? There's always going to be. Either it thinks it has succeeded and you look at it and you're like what is this? And then you can give feedback. So we believe there's always going to be a feedback loop between the human developer that assigned the task to the coding agent and the agent itself, and that feedback loop at GitHub lives in the pull request, just like the human collaboration between two developers lives also in the pull request. So if you go back in 2008, github was human to human collaboration in software projects. Now, in 2025, github is still human-to-human collaboration, but we are extending it to human-to-agent collaboration.

Craig:

Yeah, and these models are getting more and more powerful. The underlying model for GitHub CodePilot coding agent are the OpenAI models. Is that right?

Thomas:

For the coding agent today it is the Cloud Sonnet 4 model that just came out For CodePilot itself, the CodePilot that you use in your IDE.

Thomas:

It is a range of models, code completions or autocomplete is on an OpenAI model that's based on the 4.0 mini.

Thomas:

We also have, you know, for chat, we have 4.1 and 4.5 and Cloud and Google models, and then for agent mode it's it's those models that uh, support, you know, have reasoning capabilities and can call tools.

Thomas:

Um, you know, at the end of the day, whether it's the open source projects you're picking on github or whether it's the models we believe in, developer choice. It, like a developer tool is not going to be successful if it doesn't offer developers the choice between the different options that are available in the market and let them pick which is the best model for their scenario and what best means and I'm making air quotes for those that are listening audio. What that means is highly dependent on the developer themselves. Right, they might have previous experience, they might have a team that says we're only using this model or this open source library. They might have certain beliefs and all these things play a role and we are not the ones judging that, we are the ones offering that choice. And that goes back to what I said earlier we want to be the home of all developers around the world and, as such, we believe in that choice.

Craig:

So the developers can switch between models. Presumably you can try it with writing a piece of code with one model and then try it with another model and see which one you like better. But is there an orchestration layer where the co-pilot coding agent makes that decision for you? You know it decides on its own which is the best model to use.

Thomas:

Today the coding agent is only on Sonnet 4. But that's certainly something that we have in our minds, or on the backlog, how we say, in the software development, to have more orchestration on these things. And once you bring in the code review agent, which runs on a different model and reviews the code in the pull request, or the autofix agent that fixes security vulnerabilities, we are already supporting a range of models and in some cases we pick the model, like in code completion in this agent scenario, and in others we give developers the choice. I think the crucial thing is there is no single best model that works for every single developer out there.

Thomas:

There's many programming languages, there's many frameworks. There's many programming languages, there's many frameworks, there's many styles of how software is developed in companies, and we believe developers will figure out what works best for them, and often that is trial and error, just as you do trial and error in other parts of the software development lifecycle. You know we all have figured out at some point that we made a wrong decision on some framework library decision in life, I guess. And the nice thing about software and models is that it's really easy and cheap to switch to another model and then try again. But yeah, this auto-orchestration, I think, will play an increasing role for those that do not care what model they want to use and they just want to have the AI decide for them and offload that decision, and so it's going to be a mix of those two things those that want choice will get choice, and those that want a default will get some form of auto mode.

Craig:

Do you have a sense of how much of today's code is being written on GitHub?

Thomas:

Oh, how much code is written on GitHub? I don't have that number, it's not how much.

Craig:

What percentage of new code in the world is written on GitHub?

Thomas:

I have no idea of lines of codes. I mean, we have 150 million developers. I can look it up. We publish every year what we call the Octoverse on statistics from open source. Obviously, we don't want to talk about, you know, what enterprises do in their private repositories, but if you just look at pull requests, we're talking in the range of hundreds of millions pull requests every year. And so then you know, if you do the math, if each of those pull requests only has, like you know, 10 lines of code, that would be already a billion lines of code.

Thomas:

I'm sure the number is way bigger, especially, as you know, developers change existing code all the time. They either do that intentionally by refactoring something like changing a long method with lots of lines of code into smaller methods, because at that point where they were working in it, they realized the previous developer just got it done and now it's time to clean up, or because they're using something like agent mode and they're asking the agent to make a change, and then the agent decides okay, as part of that change, I'm also changing some other files and make those better. And so, if you look at just AI, it's been over two years ago, I think in early 2023 is when we said Copilot is writing 46% of those lines of code in those files where Copilot is enabled.

Thomas:

I see it was already half of the code through just auto-completion half of the code, more just auto completion half of the code in two, more than two years ago. And today, if you use agent mode in VS code or if you use coding agent, all you do is write the prompt. The prompt is a longer description, so arguably, you're writing natural language to describe the problem you're trying to solve, and then agent mode or coding agent writes all the code, and so for certain scenarios it's 100% code written by AI, but you still have to write. You know, in English or whatnot, what you want the agent to do. So by no longer writing programming language and code, now you're writing a specification, and so, arguably, you know human language is becoming the universal programming language and that's written by the person that has the idea in their head and tries to take that idea and transform it into something real.

Craig:

There are other DevOps platforms or whatever you want to call it. Gitlab is one that comes to mind. I mean, github is the dominant, but how many other platforms are there that you're watching and do you have to? I mean, obviously you have to pay attention to the competition, but there's such a critical mass behind GitHub today that it'll take a long time before anyone challenges your position.

Thomas:

I think it's in our nature to always be worried about, you know, even if that's probably true what you said, that it's going to be a long time before a large platform like GitHub is going to be challenged in its position in terms of losing all its value. There's many other technologies in software and in the personal computer world out there that are old and still exist. You know, I saw over the weekend some YouTube video where they were talking about some industry still hiring Windows 95 developers because they're running such old I think it was air traffic controllers, actually I think it was air traffic controllers. They're still running on super old, you know, versions of Windows in some towers, and so technology never goes away. But I think, as Microsoft, as part of Microsoft and as GitHub, we always have a healthy level of anxiety, I'd say, of what else is happening around us. Are we going to be disrupted?

Thomas:

The innovators dilemma, the Hayden Christensen book, plays a big role, I think, for most companies that have research of a certain size and as such, you know, whether it's in DevOps, whether it's in generative AI for software developers, whether it's in security for software developers. You know, with our partners at Microsoft, we also, you know, own two of the largest IDEs, the largest editors Visual Studio, visual Studio Code. We have the NET ecosystem. We're the owners and stewards of NPM, the Node Package Manager, which is the largest package registry for everything in JavaScript. So what I'm trying to say is GitHub is GitHub, and we are going to keep innovating. We are going to keep focusing on what developers expect from us, while also looking at what's going to be ahead.

Thomas:

Where do we need to innovate? Not only to grow our business, but ultimately to prevent that we're going to be disrupted by others. And I think the great thing about GitHub and being part of GitHub is that everybody at GitHub is using GitHub Not only the engineers and the product managers, but also the leadership team, the human resources department, or the people team and the legal team, and or the people team and the legal team and they have their terms of service are just the GitHub repository Because, at the end of the day, everything is a pull request against some previous version of that same file or adding a few new files to the repository. So I think, as a developer myself, building tools for developers is my dream job, and we're going to keep pushing on the GitHub side.

Craig:

Can you talk a little bit about what's next?

Thomas:

It's agents. We already mentioned the coding agent. If you look into the space of these agents right now, there's a very popular benchmark called SWEbench, S-W-E-bench, and the best models in the SWEbench are somewhere in the 60% range. Maybe it's 70% by the time this comes out, but that's only about 2000 issue pull request pairs out of a dozen Python repositories. And 70% is not a lot, because what's for the remaining 30% and what's with all the other programming languages and the team behind CWedge actually recently expanded into multiple programming languages and then the best models are much, much lower, I think in the 30% range. So there's a lot of work to do to get these coding agents, as exciting as they are and as promising they can be, for developers to offload some of the work they don't want to do, to just assign it to the agent, to a point where we can say you know, mission accomplished and agents can now write all my test cases, write documentation, you know, fix security vulnerabilities all the things that developers have to do in addition to build innovation. There's many other agents that we have in mind. We already mentioned the code review agent, the autofix agent. At Microsoft Build we announced the SIE agent that monitors your servers and then takes action based on findings, whether it's errors that are piling up or server load going high and things like that. And so you can imagine, you know, in the future the developer will have an orchestra of agents and the role will be to be the manager or the conductor of that orchestra.

Thomas:

And I think ultimately, the biggest skill for developers, other than understanding technology and the craft of engineering, will be to decide am I doing it myself or am I using an agent? And at what point do I have diminishing returns to assign these three lines of code to an agent instead of just doing it myself and predicting that? And how good does my description have to be? And how far do I have to break the problem into small chunks so that the agent can pick it up? That's going to be the job of the human, and I think that's actually exciting because, you know, when I have an idea that I want to build something as a software developer myself, the hardest part is not coming up with this idea.

Thomas:

The hardest part is to take this idea and convert it from the language I speak in my head you know English and German into a coding language, and part of that journey is like breaking it into smaller and smaller chunks until you get to the point where I'm like, oh, OK, so a button. I know how to do that, you know. And now put a button on that page and then you go in to look in the documentation. Ok, so now how do I handle that? You click on the button right. That's the level where we were, you know, a few years ago, and we're going to go higher in this abstraction ladder, but we're still going to have this. You know, systems thinking process, the system design process of taking my idea and breaking it down into chunks that I can assign to the agent.

Craig:

Yeah, yeah, it's fascinating. I was asking earlier about percentages. What percentage of the world's developers do you think are on GitHub?

Thomas:

Well, 150 million, I think you know. If you ask some of the analysts out there, they're going to tell you that number is already higher than the number of professional developers that we estimate out there.

Craig:

Yeah.

Thomas:

And the question really is, what counts as a software developer? Is an eight-year-old that in middle school? Well, what is it? How old are you? 11 years old, I guess, a sixth grader in middle school. When they do learn Python or they're working on robots for Robot Fighting League and things like that, are they a developer? Or are they, you know, a student? Uh, learning to code, the same way that they're learning physics and math and all that?

Thomas:

And I think you wouldn't call, you know, a middle schooler a physicist, uh, just because they had, you know, two years of physics in school. Yeah, um, uh, but I would, I would hope you know they're, they're, they're on github, um, if only you know to, to learn from other developers out there. That really, I think, truly is the magic behind open source that the majority of software developers on this planet have decided to share their work Sometimes it's just a short code snippet, right, and what we call a gist on GitHub. They share their work with the world so others can learn from it. Can, you know, take it, fork it, remix it. And we believe, and you know, a part of our vision is that we get from 150 million developers to 1 billion developers. Mostly because 1 billion? Not because 1 billion is a number, but because we believe that everyone on this planet should be able to create software if they'd like to do that, and that means they all have to learn it in school.

Thomas:

I think computer science should be standard, just like math is a standard in school, and they might be white coding it or how you said earlier, they might just build something without understanding a lot of the code, but they should be empowered to build software and not only consume software. And today we are very much in that side of. We're all consumers on our smartphones and I think we should all become builders if we'd like to be a builder.

Craig:

And you have events. Is it GitHub Universe and GitHub Galaxy? Can you tell us what those events are? Are those important for community building? Github Universe is our yearly conference.

Thomas:

It's traditionally in San Francisco sometime in either late October, early November this year it's October 28 29 I think I might be off by a day or so and it's a big gathering of software developers that work with us or have their code on GitHub or want to learn more about Copilot and AI, and it's in Fort Mason in San Francisco and and it's in Fort Mason in San Francisco.

Thomas:

Oftentimes it's this time of the year when San Francisco is actually nice weather it's sunny and blue sky and it's important for us from an announcement perspective. But it's also important because we get to meet many other developers from around the world and it's a gathering, if you will, to share and collaborate. And Galaxy is this year a virtual-only event. I mean it's more on the how to use GitHub, as it's like learning about GitHub in the professional environment. But we're part of many other events where we just at Microsoft Build, which is Microsoft's biggest developer conference, and you find hubbers, how we call our employees. We find hubbers at many events, with or without us having a booth or a session. And, yeah, we often announce that on our social media accounts or follow GitHub on X and other platforms to learn more when things are coming up.

Craig:

I wanted to ask about. One of the things you came out with recently is innovation graph data. Can you talk about that a little bit and where does that in your view? Is that an important tool or offering? It sounded intriguing to me.

Thomas:

It's important because we believe you know, as the home of developers and the home of open source, that it's part of what we do to. You know, give back to the community. And GitHub hosts all this open source code, and that's obviously not only interesting to those working with the code and embedded into their own project. It's also interesting for researchers, policymakers, to better understand how the world innovates on GitHub. It brings us full circle to the conversation that we had at the very beginning of this call, which is GitHub is the place where millions of developers around the world collaborate with each other. You know, we once called it the largest team sport on earth.

Thomas:

There's not many things on this planet where people from any, almost any country, from any background often you don't even know their names. Certainly you're not looking them up. In some you know organizational chart and look up what's the title in there, the background and whatnot. Right, what you look at is okay. Is the code or the issue, or the, the, the, the asset, whatever the person is contributing to my project. Is that useful for me? Is that aligned with where I want to go with my open source project? Maybe I tell them hey, this is cool, but I recommend you fork off, and so it's important for us that people around the world that are outside of technology or that are adjacent to it by researching the social dynamics behind it, that they have a tool like the Innovation Graph and the Archive program and many other things that we did over the last decade, that they have access to that information beyond just the source code.

Craig:

Is there anything I didn't ask that you'd want listeners to hear?

Thomas:

I hope listeners took away from this conversation that A we are really excited about the future of software development and we don't believe that AI will replace developers. We in fact believe AI will empower even more developers on this planet those that just want to do that because they want to automate something on their computer you know, taxes come to mind and all these other chores that you have to do, even though somebody promised to you that once you get a personal computer, everything gets easier. Or those that want to become, you know, the next startup founder, the next professional developer in a big tech company, or you know, the next GitHub employee, the next hubber that works on GitHub and other developer tools to contribute back to the community. So we're really excited about that world and we think AI is going to accelerate the way software is developed.

Sonix is the world’s most advanced automated transcription, translation, and subtitling platform. Fast, accurate, and affordable.

Automatically convert your mp3 files to text (txt file), Microsoft Word (docx file), and SubRip Subtitle (srt file) in minutes.

Sonix has many features that you'd love including automated translation, automatic transcription software, automated subtitles, transcribe multiple languages, and easily transcribe your Zoom meetings. Try Sonix for free today.