GitHub CEO Thomas Dohmke on Building Copilot, and the the Future of Software Development

The human brain is still so much more advanced than the transformer models and the diffusion models and the other types of models that we have to image recognition and whatnot that we have today. And you know, it remains to be seen if we can kind of like add that Sentience piece to it. But today I'm not seeing it and I haven't seen any research that telling me that that's coming anytime.

Hi everyone. Welcome to Training Data. Today we host Thomas Domke, CEO of GitHub. Thomas has an ambitious vision for enabling a world of 1 billion developers and bringing agents through the end to end developer workflow and into adjacent categories like code security. He even hints at the progress he thinks the industry will make on SU bench over the next few years. Some categories he's excited about in AI outside of developer tools and whether he thinks a new architecture will overtake the transformer. Today we're so excited to introduce our special guest, Thomas Domke, CEO of GitHub.

Hey, and thank you so much for having me.

Thomas. We're so excited to dive into the GitHub and Copilot story in particular today. Maybe to kick off, we'd love to learn a little bit about your personal background. You have a very interesting story. Having grown up in East Berlin before the wall fell and then starting your first company that brought you into the United States when Microsoft acquired the company, how did your background and upbringing really shape who you are today?

I think, you know, I'm living a very normal life, not the American dream now with a wife and two kids. I think what shaped really my journey was the passion for software development. Early, you know, when I was an 11 year old or so, it was still East Germany and West Germany was the wall between the two parts of Berlin. And I saw computers for the first time. I couldn't buy one, but I in school we had one in the geography lab and a friend of mine and I, we started, you know, playing with that, learning to code. You had to code to even do anything with a machine, you know, you understand some basic to even load a program. And then as the wall fell, I bought a Commodore 64 and later my first PC, a 386 DX40.

Wow.

And so I, you know, as a teenager I spent most of my time coding and you know, started a company. It wasn't at that time really a startup. We just had insurance software as in the late 90s there wasn't most of insurance agents didn't have software yet. Some were working on mainframes and others just had, you know, paper in front of them. And then I moved to South Germany to work for Mercedes, and then I had, you know, the startup that got acquired by Microsoft. But it's really this passion for doing stuff with software, being creative with software. And I think the fascinating thing back in the 90s, and it's still true today, is that you can start very easily. There's not a lot of capital investment required, and if you make a mistake, you can just start from scratch. And I think that's what makes this so cool, to build software.

And that gave you the love for building and fixing things, even today with robotic lawnmowers in your own home.

Yes, well, and it gives me the laugh as the CEO of GitHub, to build software for software developers. I think that's the really cool thing about being at GitHub. We are building the tools that other developers are using, and we always say we put the developers first. And that, I think, is the dream job for me. I get to speak with a lot of developers, I get to build software for developers, and I get to speak to many developers here in Silicon Valley.

I think what many might not know about you outside of Microsoft is that you played a pivotal role in sponsoring Microsoft's acquisition of GitHub back in 2018. Can you share. Take us back to that moment and share a little bit about what was your vision for GitHub back then?

Yeah, so in 2018, I was a product manager at Microsoft working for Nat Friedman, who at the time was the CVP for mobile developer tools. And Nat had the idea of buying GitHub and making GitHub part of Microsoft. And so he and a few folks in his team were kind of like strategizing of how can we pull that off and pitch it to Satya and the board? And as the deal got announced, we're actually, you know, about six years away from that. At the time of this recording, June 4, 2018, is when we announced the deal. I became the deal Integration manager, which was the role within Microsoft that runs around the whole company making sure all the pieces, you know, from legal to hr finances and product and engineering come together to get that deal through the regulatory approval and ultimately now getting us to a successful Day Zero, which then happened in October 2018. And that's how ultimately came to GitHub.

What did you envision GitHub becoming the potential it had as part of the GitHub universe?

I think at the time we were thinking, there's so much potential for GitHub that's still to be explored and to be realized. GitHub started with the first commit in late 2007, launched in 2008. Very quickly became a new way of developers working together. Social coding was invented by Chris and the other founders and it evolved into two sided product, the home of open source, where many open source developers were collaborating and the place where many startups and ultimately enterprises, they're building their software. And often that two sided equation was that the companies wanted to work exactly like open source developers work, which is boundary less. In the world of open source, you don't really care where your collaborator sits, where they're from, what their education is. They don't sit in an org chart. Often you don't even know their real name. All you know is the handle and the code that they want to contribute back to the project. And I think many companies you have silos and when you get an email you're like, wait, who is this and why are they emailing me and why do you want to be involved in my project? And so companies want to burn down these walled gardens and have a similar collaboration model. And that's what GitHub symbolized in 2018. But there was so much more to do to provide something like GitHub Actions that allows developers not only to manage the source code and plan, but also to build their apps. And now ultimately with Copilot, to take it even a step further and making development a very different experience than it was 20 years or 30 years ago when I started.

Since you mentioned Copilot, yeah, I'm dying to ask you about the behind the scenes view on what is not only the most successful enterprise AI application today, but I believe the first LLM native application that was really built, built and launched like I guess, was it part of the original acquisition thesis at the time that you might be able to build something like Copilot eventually. Whose idea was it to do something like Copilot? And like, was it, did everyone say yes, this is going to work or was it, was it like, this is a crazy idea, this is a moonshot, it's never going to work. Like, take us back to the origin story.

So the original acquisition thesis had like a little paragraph in it about AI, but I think that was more like a moonshot than the proper idea at the time. What really happened in mid-2020 is that transformer models, the paper came out a few years before that, but the first really working transformer models was GPT3 was about to launch, we got early access, we were all locked down June 2020 on a call, and one of our team members, Hugo d', Amore, started typing into things, into the model, and everybody else was just looking what Ugo would be doing. And then so then in the actual question, what can we prompt it to write code and can it write proper code? And I think that was the first kind of aha moment that it was actually able to write the real syntax. And then we tried different languages and we also found flaws in the model. And so we started exploring the deeper outset of that zoom call in a research process doing analysis. We ask some of our staff and principal engineers to submit coding exercises. We looked at Python functions that were in open source repositories on GitHub. And we worked with OpenAI to take GPT3 and fine tune the model to be better at these coding tasks. And ultimately in August, we had a model that was able to solve 92% of these coding exercises. And in fact, of the Python bodies that we extracted from open source projects, it was like 52%. Now, naturally that percentage is lower because you have less specified code than in a coding exercise for an interview loop, right? But that I think gave us this moment of confidence saying we can build a product around this. The second moment I'd say was when we rolled it out to our internal engineers in early 2021 and they came back with saying, this is fantastic. I think the. Net Promoter Score, NPS was somewhere in the 70s and which is, I think, for developer tools, really, really good. Most developers are skeptical. Don't touch my system. Never touch the running system or process. And many folks kind of have created their work setup not only on their physical desks, but also on their virtual desk of how they want to work. And so we were really intrigued by the internal responses. And then we launched the preview and the team came back and saying, it's writing 25% of Python code in those files where it was enabled. And I think we sent them back, say, go and verify the telemetry. That can't be true, right? Because we couldn't believe it initially. And then as we saw this progressing, I think in my first keynote as CEO was in June 2022. So now, two years ago, and I said, it's writing 40% of the code, and I think in five years it's going to write 80% of the code in those files where it's enabled.

So it happened really organically. It wasn't like you were sitting in a room whiteboarding, like Copilot is going to be the next iteration. It was like the model proved to you how great it was. And just seeing the model performance and seeing usage like really like it organically built up.

From going back to the original thesis for GitHub, we wanted to make developers life easier. And as we are company building software, we have our own software developers and Microsoft has 70,000 or so of them. And so we understand how software developers work because we have so many of them and we live the life of many of our customers, which is we have way too many ideas, we are moving way too slow, at least in our feeling. Amazon delivers my picket package faster than we're implementing some features. Also, the expectations have shifted significantly, but the backlog is endless. The amount of ideas that we can brainstorm on virtual whiteboards. GitHub is a remote company, so we don't often meet in front of real physical whiteboards. And then the other side is all the other work that we also have to do. Compliance, security, accessibility, enterprise requirements, privacy regulations, European AI act and Digital Markets act. And all these things also cause developer work. And so everybody's constantly struggling with the length of these backlogs. And so if you will, the intrinsic motivation was let's bring the effort down to write software and make it joyful again.

What do you think made Copilot so good at the time and also going forward today? Obviously GPT3 was great even, you know, back then, but also I think a lot of people might not know all the value that you brought or GitHub brought in both public and proprietary data around code that GitHub owned. Can you share a little bit more about that and also how you think about that going forward?

I think the key ingredient of the original Copilot, which was on the autocompletion, right, like you would type in your editor and it would complete the next line, but it could also complete multiple lines of code. Complex algorithms or simple algorithms. Some of the demos we often chose to implement a sorting algorithm like bubble sort or prime number detection, and it can just write those 10 lines of code by just a simple prompt, which is a comment in the code, or just writing the method declaration. And so getting into the editor, where developers already write code, not changing the way they work, but giving them ideas while they're typing. I think that was the key moment, other than obviously the model being good enough and OpenAI tuning that model on publicly available source code from GitHub. GitHub didn't give special access to OpenAI. OpenAI was just able to access our source code in the same way that many Other startups are now doing that either through direct access through API or through archive programs like the Internet Archive and the Software Heritage. We actually have an established partnership with them to stream our open source code over there so it can be archived until the end of time. And so of course the model got tuned to be good enough, but then the UI and the user experience I think was crucial. It wasn't, you know, AI is now in everybody's mind. But the truth is our cell phones have, you know, some kind of AI built in for a long time. Your keyboard is predicting the next word with some kind of machine learning algorithms. Your photo library. You can just go in there and search for license plate and find all the photos of the cars that you took to remember what the license plate you have. And that's AI, you know, image recognition. But that nobody perceives that as AI. It's just a cool user feature. And so I think that also was the, the core ingredient of Copilot. We're meeting developers where they are and we're making their life better. And then I think the name itself was also a stroke of genius. One of our other developers, Alex, came up with the idea to name this Copilot as NAT is a hobby pilot. And so that's where the name is coming from. So it's like I'm thinking about what could I name this? So, you know, my boss is. The name is resonating with him.

Wow, that's so interesting. I didn't know that if you could go back to 2020, 2021, is there anything that you might do differently?

You know, in hindsight you can always move faster and be, I think, more convicted of those ideas. I think in the beginning we kept the team intentionally small. Small teams can, can move fast.

How big was the team?

I think the original staffers were like three people. But that's obviously a staff researcher. Sorry. Or principal researchers. But I think that's cheating a little bit in the sense that of course there was a team at OpenAI, there was a team or multiple teams in Microsoft, both on the research side and on the inference side, the model inference side. In fact, on the model training side to even enable the model. So of course, in the bigger partnership between Microsoft, OpenAI and GitHub, it was a larger team. But the original paper was written by three researchers. And then 100 people or so are mentioned in the credits. And then we move fast with I think a stub of five. And then I think it increased to 10 teams. And of course today the team is Much smaller. But we still have what we call GitHub Next, an incubation team that now works on Copilot workspace and iterates on new ideas. It's almost like a startup incubator within the company and they're picking up ideas. And the main difference to our mainline engineering teams and product management teams are that they got to have the mindset that most of their ideas will never go into production. Right? It's kind of like this. OKRs won't work because your key result is to throw away most of their ideas and start fresh with another idea. And I think that's where a lot of the innovation speed is coming from.

I want to go back to what you said a minute ago about how you handed over control of the model effectively to OpenAI. Was it scary because the brain of your AI application is actually being built by another company, not, you know, like developers under your payroll, your control? Like, how do you think about, was it an easy decision to kind of out like to partner with a different external model provider? And I'm curious how you think about the value that Microsoft and GitHub provide to end users versus the value that OpenAI provides to end users and where you seek to really bring value to users.

To me, it wasn't scary at all. I'm sure, you know, there were folks in the team and in the company that thought we should have our own models instead. But in reality, if you look at GitHub as a company that was born in the cloud, of course we have always relied on partners to build our stack. To my memory, we have never built hardware ourselves. And while we have metal in data centers or had metal in data centers for a while, the data center itself wasn't built by us either. Neither was the CPU and the memory and the network infrastructure. And then even if you go higher in that stack, you know, GitHub is built on top of open source and so are the majority of software applications. In fact, we love sharing a statistic that says 90% of the stack of most of most applications, even if the application itself is closed source, is in fact based on the work of the open source community. You know, from the operating system, the Linux operating system is ubiquitous today on servers, to container technology like Docker and Kubernetes, to thousands, sometimes tens of thousands of open source libraries. And so the model just flows naturally in that stack. And we at Microsoft think about this as the copilot stack with different layers, hardware, the model, the kernel, if you will, like the infrastructure response to the AI filtering and whatnot, then you get into the application layer with the AI copilot and then the extensibility on top of that. And so if you look at these layers in the stack, Microsoft has strengths and partners. And in fact, in some form, Microsoft is involved in all parts of that stack. The Copilot PC has a custom chip that Microsoft is developing with partners. We have our own models with phy3 and we have partnership models with OpenAI, but we're also hosting Mistral and Llama on Azure. We of course have a large cloud and we have a lot of expertise in responsible AI. And then we have lots of application we are building ourselves and we're enabling others to build those applications. And so two part questions are always hard for me to forget the second part, but I think that actually describes the relationship very well. It allowed us to move really fast because we could rely on partners like OpenAI not only building GPT3 and then codecs, but also then innovating with GPT 3.5 and ChatGPT GPT4. Now we have GPT 2.4.0. We have Microsoft with a large infrastructure that builds supercomputers for training, but also infrastructure to run inference. And you know, Copilot today runs in multiple data centers spread around the world in different regions. So the developers that sit in France, you now connect to a gpu, to an Azure instance that's much closer to them to enable low latency. Right. And so Microsoft gives us a lot of infrastructure, a lot of expertise and responsible AI and of course a lot of commercial distribution.

Yeah, very complicated layer cake that makes the magic come together.

Would GitHub ever want to build its own models or just use best in class models out there?

You know, obviously there's always the desire of engineers to build their own stuff and I would not deny that we have played with our ideas on models. I think the Almost machine learning team goes back Almost. I think it actually had it before Microsoft acquired GitHub. And then we obviously have fine tuned models ourselves and we have fine tuned models with OpenAI and Azure and we are working with customers on them being able to customize models based on the code that they have in their repositories and never say never, what the future may bring. But today we're really happy with the models that we have and we're constantly looking into the market of what not only OpenAI provides to us, but also what others have.

So Copilot is already one of the most successful generative AI applications in terms of user Scale usage, et cetera. What are some of the latest metrics you can share and what are the metrics that you're most proud of?

I think the one I'm most proud of is the developer happiness scores. And if you look at survey data, both the surveys that we have done, but also the service that now our customers either publishing themselves or bringing back to us, it's clear that software developers, after they have tried Copilot, after they got over the initial adoption hurdle or skepticism, most of them love using Copilot and most of them report that they are more fulfilled, they're more satisfied, more happy, they feel like they're requiring less mental energy to get the job done. They need to do less boilerplate. And I think that alone is really making me happy. And there's lots of numbers that I can throw out, but I think the general gist is no matter what developer I talk to, those that have used Copilot for a while no longer want to work without a Copilot. And then the other side is the productivity metrics of making, you know, developers more productive, which I think matters to the developers too. But it also of course matters to their management chain and their leadership in the sense of, you know, getting more stuff done, delivering more value to their end customers. And so, you know, today, today we are happy to say that we have more than 1.8 million paid subscribers on CoPilot and more than 50,000 organizations. And that really makes us happy, looking at that growth. And you know, we're here at Sequoia's office and it feels like we are like a high growth startup and that's a good place to be in.

It's awesome. Well, we're still on our wall somewhere, actually. We know exactly where. We'll show you.

Me too. The creative minds.

Was there anything that surprised you in terms of Copilot's impact after its launch? And even today, I think, you know.

It'S the 25% certainly surprised us. The quick turnaround from the skepticism after we announced this in June 2021, I think we had a very short blog post and then just a webpage with examples and animations showing how it will work. And I think folks were looking at this and saying this is like a cool tech demo, but it doesn't actually work for me. And I think the skepticism was that people had seen how GPT3 at the time would work and they couldn't understand until trying it that it has the context of whatever you wrote in the file before Copilot suggestion comes and it considers adjacent tabs and things like that. And so it magically picks up your style and it knows about open source libraries that you're using, not because you have opened those libraries, just because you have an import statement at the top and because the model was trained on such a large corpus of data that it can provide the calls into these open source libraries. And so kind of like it feels to you that the Copilot understands more about your project than you thought GPT3 can do. And I think that's where the original magic came from. The other thing is today when I observe people using copilot and obviously ChatGPT changed the whole game and put in chat as a component. We have now Copilot Chat is this natural language component, like using not only code and comments as a trigger, but English and German and Brazilian, Portuguese. And we have demos in India where Karen mv, one of our folks there, is demoing this in Hindi. And you can actually speak into the copilot with voice detection in visual studio code and then gives you the response back, also in Hindi. And, and so it's really cool, you know, for anyone that wants to explore coding, even if they're not fluent in English or in programming language, my kids are using it to find their own bugs in Python. So they're only coming, you know, they're no longer coming to me and it's like, daddy, you have to find my bug. It's kind of like, well, go and find your own bug. And that also obviously helps them to develop their skills. And it's a bit like, you know, I often talk about, you know, natural language will democratize access to software developers, but it doesn't mean that everybody is immediately a senior or principal software developers. In the same way that just because I buy a guitar, I'm not as good as Keith Richards playing with the Rolling Stones, right? And if you look at any professional band that's touring the world, they all still rehearse over and over again. And I think this is like this idea that to be good in a craft, you have to keep doing it. That Copilot does not take that away, it just gives you another tool in your toolbox.

I really like that analogy.

Still believe in teaching your kids to code? Because that's like a debate on the Internet now.

Oh, absolutely. First of all, the human language is not deterministic. You mean different things. You can mean different things by saying the same sentence. And even that's very German. Even the. Yet. Well, now we can get into off topic debates about Yeses and nos. When you're answering a question with a negative in it, right? Like you have not been to the grocery store, do we answer that with yes or with no? Right. And Americans expect a no, even though you mean actually yes to that question. But like, look, you know, it's. Human language is not deterministic. And so code is. With code you can very precise describe what the machine does. Code is an abstraction layer on top of assembly language, on top of the instruction set of the CPU or GPU that the processor manufacturer like intel or Nvidia has created. So it's just another abstraction layer. Human language is something completely different. It's creative and that's the power. But it also means that there will be code involved one way or another. And we are moving up the abstraction layer, but we're also spreading the meaning and that's truly powerful. But it also means that there will be some conversion to code somewhere because the chip itself, at least today, is requiring a deterministic instruction set.

Yeah, I love that. I'd love to talk about the future of Copilot. You've been announcing new products in rapid fire succession, I think. Copilot X, Copilot Enterprise, something on code security, I believe, and then workspaces most recently. Can you tell us maybe about what each of those things does and how you see them all fitting together in the grander vision for what you hope Copilot becomes?

You know, what you described with all these product names is one of. Part of our mindset is that momentum is our energy in this age of AI moving fast and iterating fast is crucial. And so we are having developed Copilot from this original idea of auto completion. By adding chat, we were developing auto completion and then chat. And then with chat we also announced something, what we call Copilot X, which the idea was we are bringing AI features into every part of the developer lifecycle. We're bringing Copilot wherever developers are. So while we added chat to the editor, we also added a little Copilot icon into the input field where you write your commit message. And that might be trivial, everybody can write a commit message. But it also means I reduce my mental workload and I reduce the bias that I have for the work that created myself. Right. Like for me everything is obvious that I just did for the last hour, but for you, when you want to review my commit or my pull request, it's not as obvious. And so having an AI describe that in a neutral form, kind of like in our describing what I just did is incredibly useful and it just keeps me in my flow. And we added it to the debugger, we added it to many different parts of the lifecycle already. And with Copilot Enterprise, we bundled it into a higher price product that allows enterprises to customize Copilot based on their institutional knowledge. And enterprise here means really any company that has gone for more than a few weeks because they all immediately build institutional knowledge. Right? How we work as a team, how our coding practices, these are the libraries and languages that we use. And so unless you're a student in university that gets to have the free range of technologies available, at least when they, when the professor allows that every time you join a company or join a different project, you have to ramp up again on how they are doing things. And so Cobalt Enterprise lets companies customize the copilots to their institutional knowledge. And it makes it really easy for me to join that company because I can now ask dumb questions without you judging me. Like, imagine I would join here my first day with like, why is Thomas asking all these questions? Shouldn't he already know all of the FTCs? You know, been in professional life for a long time. That's the challenge that we have when we join companies. And we have the anxiety in our head that we can't ask too many questions before Steph says what the hell. Right. And so that's I think the power of Copilot Enterprise. That's the power of bringing Copilot into every part of the developer lifecycle and ultimately into every part of the of our lives.

You've also mentioned that agents are one of the most important next things for GitHub. Maybe just to set the stage, how would you describe an agent versus a copilot? And can you give us a teaser for what types of agentic capabilities we should expect come into Copilot soon?

Yeah, I would say Copilot and agents is kind of like the same thing. An agent is using a model to get a task done effectively. It's looping with a model to solve something for you. And a copilot is an agent of agents. And it has multiple features available to it. If you think about auto completion, well, it's an agent that takes every keystroke you did and the context that you have in your editor sends it to model inference that gets a response back. It might pick the best prediction and then it shows it to you. And so we are going to see more of these agents that take over more of our tasks. And one of them that I'm most Excited about is autofix. And the way it works is you submit a pull request and traditionally some security scanning feature that you have integrated into your pipeline finds security vulnerabilities, let's say SQL injection or cross site scripting. Well, that's great, except now I cost more work for myself. It's kind of like you have a Roomba, but instead of vacuum your house, it just shows you where the dirt is and then you have to go and vacuum yourself on that position. So now with autofix, we're actually not only showing you the security vulnerability, we're also giving you the fix. And that uses the AI model together with the vulnerability and the description and the code to basically solve that vulnerability for you. And the initial results are really impressive. With some customers, we see that we can burn through like 75, 80% of their open alerts, because everybody has those alerts. And if you don't have any alerts right now, I bet you you have them by Monday. Right? That's the challenge in this world of software security is everything is around us moving so fast. There's always a new version of a open source library, there's a new version of Linux or, you know, a new Windows patch, there's a new device coming along the way or new Nvidia gpu. And so we constantly are behind just keeping our applications up to date, you know, to the, to the standard that is expected by our customers. And at the same time we have to build all that innovation and all that super interesting, cool stuff. Yeah.

What else do you think is missing in the product roadmap? Like if you could wave a magic wand, like, what else is there to build that you're really excited about?

I mean, I think there's still a lot of work to do on these agents. I think there's a lot of agents you can think about. We talked a little bit or you mentioned workspace before. What Copilot Workspace does, it provides different agents to get you from idea to your pull request. So get you from idea to the code. And the first one is the spec agent. And what that actually does, it helps you with your thought process. So you write down an idea, implement some features, and it looks at your existing code base and it basically helps you then to reframe that idea. Now that's not only useful for a developer, it's actually useful for a product manager. Right. Because it might tell you, well, Thomas, this idea is no way you can describe that with a single sentence. And a developer cannot implement that in just a Single ticket, it needs to be an EPIC or multiple different user stories. Right? And then the next step is the plan agent that helps to figure out where to make the changes in the code base. And again, you can kind of see here there's a lot of other benefits you get from that because it helps you to understand the code base. Because most code bases that are older than a few days have hundreds, if not thousands of files. And as developers, we have to navigate all those files. And even if you have been in a code base for a long time, you still might miss out that one file that you haven't touched for a while. And you have to add a config statement there. So it helps you understanding the code base. And then the implement agent helps you implementing the code change. And every step in that way, you're still in charge. You can, with natural language, modify the bullet points of each of these agents and then obviously you can modify the code at the end. And so if you look at just these three agents, you can easily start thinking about other agents that you might have along the way. Right. For example, the one that estimates the size of a ticket, the story pointing agent, as one example or another one, is that once you have implemented the file well, now you want to build, run and debug the file. And maybe you have an agent in the future that will just automatically fix any bugs that were introduced by the previous agents. And so I think we are going to have more of these building blocks, Lego blocks, if you will, available to us. In fact, if you look at Lego, they have way more types of pieces today than they used to have. Trust, the models are much more complex. And then, you know, you can buy, you know, NASA rockets and whatnot, and they need different pieces for that. And I think that's kind of like the same way we should think about copilots. They will have more of these building blocks that enable us, in addition, you know, to more powerful models and a mix of models. These building blocks will enable us to.

Do more increasing modularity. Interesting. Where does your ambition for GitHub take you, or maybe even with GitHub Copilot specifically take you as you think about what you alluded to from the perspective of deepening, where you can go with just the software engineer, to also expanding into potentially different Personas. PMs, you mentioned maybe an SRE, maybe a security engineer. Where does that, you know, that breath also take you?

Yeah, I mean, first of all, I think all those roles today are already collaborating on GitHub. In fact, GitHub had always that mantra that we are building GitHub on GitHub and that sometimes we have pushed it a bit too far. But Today most of GitHub employees, we call them Hubbers, Hubbers are engaging on GitHub and GitHub discussions and GitHub pull requests. Our legal documentation is all on GitHub, which if you think about is actually much better than managing red lines in Word because you have a version history and you can see who made what change. And in fact you can see soon in the future where maybe your legal document is explained by a copilot in human language, in the actual understandable human language, not the lawyer language. Right. And so we're using GitHub to run our company. But yeah, it's where all the developers and all the supporting functions collaborate on a project. So that's, I think number one, number two is we want to democratize access to software development. And I recently gave a TED talk and I talked about that. I think our goal is to get to 1 billion software developers on the world. Now, it doesn't mean 1 billion professional software developers, although that might not be a bad thing necessarily given the demand is still very high and it's sometimes hard to find qualified software developers. But it's really about democratizing access to writing software on these devices that are with us. Our mobile phones are a really important part of our lives today. You can't really imagine life, urban life for sure, without a mobile phone. And so then also being able to write little applications or little scripts or just using natural language to control the phone, I think is incredibly empowering. And so bringing that into 10% of the world's population by 2030 or so, assuming that then there are 10 billion inhabitants on this planet, I think is going to create a better world and it's going to unlock creativity everywhere. And hopefully we see cool venture backed startups in India and in Brazil and maybe the next big tech company is coming from one of those countries instead of the US West Coast.

We hope so. Maybe zooming out of GitHub Copilot to broader GitHub itself. GitHub Copilot itself is driving so much innovation within GitHub. But what are some of the other key initiatives that you're leading across GitHub overall as well?

Yeah, we already talked a little bit about Autofix and security and I think security securing the software supply chain is dear near to our hearts. There is no future of human progress with software if you're not also able to secure the supply chain today there's this XKCD comic of the Internet's infrastructure and there's this one building block that says the guy in Nebraska, maintaining this one library alone, that actually is as funny as that is. That is a reflection of the software world today. So we have to make it sustainable for those maintainers to build that software and keep it joyful. And then also we have to make sure that all these building blocks that are in our stacks that have become system critical and to be secure. And so we're investing a lot in platform security and application security and of course, in our security products. And I think that's going to be crucial combined with Copilot and AI, to not only create all these work items, but to also enable developers to burn them down to fix all these issues.

Yeah, I want to Zoom out from GitHub for a second and just talk about how you see the future of AI and coding overall. Like you mentioned, there's a billion casual developers around the world. What will it look like? Will everybody be kind of coding applications for themselves to use? Will there be some number of professional developers who are super developers? Like, how do you imagine the world looks when you so kind of democratize the craft of coding?

I mean, I think it's an incredibly creative world in a world where you're not dependent on, when you're a kid, on your parents having technical knowledge or your school having a teacher that knows how to do these things. So we are going to have much more access to those that are interested in learning about this. You know, it's easy today to take a sheet of paper and paint something. And every restaurant, at least in this country, gives you crayons if you come with kids and a coloring sheet.

Lifesaver.

Lifesaver. Or you have your mobile phone and they use your mobile phone. You know, it's easy to learn, easy in the sense of accessible to learn a musical instrument. And I think it should be easy to learn coding. And so first of all, I think that should be something we are excited about and not concerned that we are inflating the number of developers. Because just because kids learn, it doesn't mean they want to become a developer. I think there's still a world where people want to do something else than software. But then if you think about many other professions, physicists, for example, they use a lot of software. The first image of a black hole was rendered by the help of open source project. The Mars helicopter ran on open source. And so yeah, it's space engineering, but they're Using software and they're building software. And so the profession itself is everywhere. Every company is a software company. Banks are software companies, energy providers are software companies. Farmers are software companies predicting what seed to plant this year, what the weather is going to be like, what's the soil quality from last year, and things like that. But of course that the hobby scenario is also important, like tax season is over here in the United States. But that doesn't mean that I couldn't think about next year to automate a lot of that. If I only had an AI agent that does all that work for me and downloads all the PDFs and extracts all the numbers. And I don't think we are too far away from that. And I'm now in Software for almost 30 years. Almost 30 years. And as a professional software developer. And I don't have a lot of time to code. I have a company to run my podcasts to give and things. But the problem today is you find an hour on a weekend and you have a project and the first 20 minutes you're spending with updating everything to whatever you missed. And the burden is actually the fun is gone to a certain degree because the burden of maintaining software is so high. So having something available to you that gets you quickly into the hobby and out of the hobby or out of that task, I think is incredibly empowering and brings the fun back. And that's where the LEGO comparison is so useful, because LEGO is just incredibly accessible. And even if you the best LEGO is the one where you don't have instructions, you just have a table full with LEGO bricks, even in random colors, and then have this excitement of play. And even professional workers at their off sites or workshops often have little gadgets or bricks on the table. So you have your fingers do things while you're thinking. So I think that's where that world is leading us. And we will have more access to the technology. We have more people that can build software. That doesn't mean that they're taking jobs away from professional software developers.

On what time frame do you think we'll have coding agents that are as good as maybe the average professional software developer? And. And there's the legend of the 10x software engineer. At what point do you think AI will be as good as the 10x software engineer in capability?

The trick in that question is the. As good as. And what does that mean? So I think is a model today able to write better code than the average developer if it is prompted in the right way or given the right context? I'D say we are already there on average. Because often the model just knows more about that whole space than I as a human do. And you see that with students, if they have to implement a conversion from binary to decimal or something like that, and they might write 100 lines of code, and then they go and ask Copilot how to do that, and they get probably an open source library and one line of code, and then you can kind of say, well, I'm not allowed to use open source. And then you will probably still get a better code than they would. And I think the same is true for the professional software developer, because, look, we are not perfect, we are human. And I think that's part of our nature, that's part of creativity. Now, that's the key thing, though, that the model is not creative. And the model cannot. Today, the model cannot make decisions for us. Or if it doesn't make decision, it doesn't actually take all the constraints into account. Like, if you think about software development other than writing code, which is, I think, the fun part, it often means, you know, I take a very complex problem and you break it, decompose the problem into small building blocks, you know, and the block size is increasing over time. You know, it used to be auto completion, used to be just the next word, and then it was maybe, you know, a full command, and now it's multiple lines of code and maybe it's whole files in the future. But along that decomposition process, you still have to make a lot of technical decisions. What database am I using? And you probably know better how many database startups Sequoia has invested in and how many infrastructure startups and how many serverless startups. And obviously there's all the incumbents in all those spaces. So there's thousand, if not 10,000 decisions to be made, and the engineer is the systems thinker that is making those decisions, or the team of engineers and companies. I think we have been building houses as humans for thousands of years, and if you have ever built a house, it's still not a solved problem.

But at what point do you think that creativity and that systems thinking gets built into Copilot, or do you think it never does?

I mean, it's a bit of predicting the future. I don't know if I would say never, never say that's a dangerous thing. On a podcast, you invite me back in three years and say, well, Thomas, last time we asked you about, clearly it has happened since. No, I think we'll see where the research goes and where the technology goes. In kind of critical thinking and systems thinking and those kind of questions also learning. You mentioned your 2 year old. Your 2 year old and my kids, they learn as they mimic the humans around them. They are so good at learning language and especially in young age they can learn multiple languages. Mine speak English and German because we speak German at home and they don't have an accent in English. Well, they have an American accent, but they don't have the German accent. Right. And they don't have an accent in German either. And I think this shows that the human brain is still so much more advanced than the transformer models and the diffusion models and the other types of models that we have to image recognition and whatnot that we have today. And it remains to be seen if we can kind of add that Sentience piece to it. But today I'm not seeing it and I haven't seen any research that telling me that that's coming anytime soon.

That's a really clear delineation.

Switching gears a little bit. And we'd love to hear your thoughts on the overall ecosystem of startups. Right now AI CodeGen is the hottest category with a lot of ambitious founders and there are so many different attempts that they're taking, whether it's folks who are trying to build a better model, folks who are trying to build a better idea, folks who are trying to build kind of an all in full stack engineer as an agent and you know, but the big elephant in the room is GitHub, Copilot and all the adjacent products that you have around it with Copilot Workspace, with Copilot Enterprise, with Autofix and owning VS Code as well, amongst many other things. How do you think about what white space there is for existing. Sorry for new founders. And if you were a founder yourself trying to build mustpace, what would you do?

I mean, I love developer tools so I probably still do developer tools. And I'm not sure I would worry too much about what's white space with what's taken by incumbents, because that can change quickly. You know, when GitHub started, Sourceforge was the big elephant in the room. And Sourceforge had all the open source projects and then came Git and Git recepted that space and then the founders of GitHub took Git and built GitHub and all of a sudden that elephant in the room was no longer the elephant. And I think it is often fun to compete in the same space and we love competition because it pushes us forward. It's boring to Do a race or a game if you don't have an opponent and if you don't have other teams in the league who would watch the super bowl if there's only one winning team every year. So I think a. I don't think competition should hold you back as a founder from going into that space. And I think the software development space is wide open and there's lots of problems to solve. There's lots of problems in different industries and categories to solve. We haven't really solved modernization of source code. You know, COBOL runs still on mainframes and you can use a copilot. And we are heavily looking into that. And because it's such a pain point for many financial services institutions, you know, your credit cards, your bank account, Wall street, all that runs the COBOL on. I haven't met a single bank that doesn't. Doesn't run some COBOL on some mainframe. And what would you do with copilot and COBOL so well, today you can explain that, which is, you know, often helpful because the code was written 60 years ago and so the people that wrote that code are retired.

Yeah, yeah, exactly. Would you rewrite all the code with.

You can ask it to write unit tests. Because nobody wrote unit tests in the 60s and 70s either, let alone that there were testing frameworks for those languages. Like, keep in mind the 60s, that was before hard drives, before we had personal computers. It was a very different world back then. And of course those companies have done work to modernize to a certain degree, but it's far behind Azure software development. So you can support that transformation process today. But we are not at that point where you can just click a button and you have a transform. The same is true for many more modern languages. There's large PHP code bases, there's lots of Java out there, and there's lots of optimization that we can take to just make our existing stacks more efficient where agents can help. There's lots of things to improve in every part of the software development life cycle and in this ecosystem around us. GitHub. I like to think about GitHub as one planet in this universe of software development tools. And there's smaller planets around us and equally or almost equal sized planets in our space and we consider them partners and we are happy that they're there.

Yeah, so interesting. Agents are just pulling that thread a little bit. It's also an area of excitement for us and I think you have a lot of the benefit of owning so much of the data and everything you can do on the post training side, OpenAI itself is also getting better and better with each new model class, as are every other model company out there. Would you ever want to kind of invest into building your own agents, maybe from scratch by building your own gentic models or just to partner with some of the others out there?

Me as GitHub CEO?

Yes.

Or me as agent investor?

You as GitHub CEO?

Yeah.

I think we are probably doing both in a way. We always have done Both things as GitHub, we have invested into our own things, the thing that we consider as core part of our platform and of our offering, part of our primitives. And we have partnered with companies. Just earlier this week we announced the partnership with JFrog which covers binary artifacts, scanning of containers and those kind of things. And they obviously very naturally in our space we have the source code. And what do you do with source code? Well, you either compile it into binaries or you combine it with binaries before you deploy it into the cloud. And so there's a natural value chain there where we have things where we invested ourselves, things like releases that you see on GitHub and packages. We own NPM, the largest package registry in the world for the JavaScript ecosystem and NuGet through our partners at Microsoft, the largest. Net registry in the world. But that doesn't mean that we cannot also partner with the JFrog to ultimately enable that secure software supply chain that I mentioned earlier and that I think is crucial. And that Figma, Vercell, like so many other companies in our space, that will play a part in the life cycle. And I don't see a world where somebody covers all of that and can convince every developer that using all these tools is better than picking, you know, what, what analysts might call best of breed, like the tool that I consider the best best is all subjective anyway, right? Like it's all this. Does it meet the expectations of the developer in their environment?

Yeah, makes sense.

That's great advice for startup founders and I think really encouraging. What about for incumbents? I think you, you are such a beacon of hope for incumbent companies. Like I think Satya said in the last earnings call that GitHub is now growing 40% year over year thanks to the copilot acceleration. And so like, and to your point earlier, like you feel like you're a young startup again, like walking into the Sequoia offices, like, what advice do you have for. There's so many incumbents that are trying to reinvent themselves around AI. What, what advice would you give Those.

Folks, Saja actually said 45%. So we're really excited about that. All up on our, on our revenue record. 45%. You know, I got an email from somebody last week who was like, looking at GitHub, I'm losing the belief that large companies cannot move as fast as a startup can. And I think the key ingredient on this is radical focus and basically focusing on a few small things. Just because you have 1,000 engineers or 50,000 engineers doesn't mean you can do it all. That's just a false assumption. And I think it's in a way misleading. As you manage larger teams, you're losing kind of like the unit of team size that shows you how much you can actually get done and how much friction you have in the system. If all these teams work on different things, I think focus lots of no's on all the ideas that people have around you and customers, that's, I think, the key piece to move really fast. And then obviously taking in some strategic bets and strategy means you're thinking about it as, how do I differentiate from others? You know, what makes me specific, makes me special in this market, what lets me charge the prices I want to charge and not fight, you know, a race to the bottom. And I think that's this kind of like thinking about, okay, you know, in software, we like to think about, well, if I had just three more features, then I'm going to win the space until you realize, well, everybody else can also add those three features right there. There's almost nothing in GitHub itself as a platform that you couldn't rebuild with significant investment and time. But I think it's really hard to mimic our culture. It's really hard to mimic our experience, our obsession about developers and ultimately our focus and the way we're approaching these.

Things, I guess, very tactically, do you recommend staffing a tiger team to get to product market fit on AI, do you recommend, you know, pulling half your engineers off whatever they're working on and like, hey, you guys are the AI team now. We, we got to go bigger, go home. Like, tactically, how do you recommend companies?

Well, as an incumbent, you always have the challenge that you have to sustain whatever the business is you're in. And so you can't just pull everybody into a new topic unless you're willing, you know, to disappoint all the existing customers, you know. No, no. Enterprise business has not made promises to enterprise customers of what's coming next on their roadmap. Lots of conferences, including our own, is Stuff they are shipping right now and stuff we're announcing for the next six months. And if you're not delivering on this announcement, your customer base is not going to be happy. And so you can't really make that drastic move right away. And so we love this idea of a tiger team or an incubation team. We call it GitHub Next. And when we set that team up, we actually thought they're going to work on projects that are like five years out or in that Horizon three space. And then it turned out, well, it was more like six months ahead of the curve. The future comes really fast on us. And so as that future then comes fast, you really also need to move fast in handing things from the incubation team over to your mainline engineering team. And then it's all about, okay, so we are funding AI because we are seeing the traction there. And that means we're leaving some of our previous bets in keep the lights on mode ktlo, or saying goodbye to these ideas and shut them down. I think that's the hard part of the strategic pivot, and that's easier for a startup. At least it often looks easier from the outside when a startup pivots. There's lots of startups on the wall downstairs that have gone through that as well. But obviously internally is also very hard. Emotionally, you're tight to ideas. You remember the workshop under Sequoia Trees where you had those ideas and then six months later you're realizing, we never got to product market fit and the time is now to move to something else. So that is the same for large companies as for small companies, except that small companies have more of a forcing function to give up and move to something else.

The innovation and success that you've created around GitHub Next is amazing. How does a kernel of an idea start within GitHub Next? How do you then resource and invest into it? And then how do you. At what point? And what's the process in which you decide whether or not something should be continued to invest in or shut down entirely?

So I think the start is always the employee, the hub that has an idea. And we have lots of ideas in the company. We do hack weeks, hackathons, passion projects, whatever you want to call it, you know, 20% time. And then in the next team, specifically, you know, there's lots of demo meetings, demos and not memos. You know, it's much more useful. Just show a working prototype. It's so easy these days, you know, to just use some design system, react components or Figma and stitch something together even easier with Copilot. And then, you know, it's strategic decisions that the leaders of these teams, all the way up to me, need to make. Many ways very similar to any other creative industry, like at Disney or Pixar, they have to decide which movies to produce and which ones are probably not going to gain traction. And part of that is customer research, talking with developers. And that then keeps going as we go through the initial idea and the first prototype and then going into a technical preview. And then the preview is all about that flywheel, that feedback loop with the people using it. And quickly you see, are they trying it out and then they are churning, or are they keeping the energy high and then keeping the ideas flowing? It's great in any project if people are just sending you more ideas and more feedback. And I think that's then the decision whether we are keeping that project and making it a main project or whether we are deciding, okay, the experiment is over. We learned a lot and we're moving to the next one. And of course, there's commercial aspects as well.

Maybe outside of the world of code generation and anything in your current purview, what else are you excited about in the world of AI in the span of one, five or ten years, outside.

Of developers, you cheated a little bit on me. I mean, I think in the context of one year within the space of developers and outside of the space of developers, I'm excited about agents. And we are still very early in this journey. I think we have high expectations of what the agents could be, maybe too high expectations to some degree. And so things will probably take a little bit longer. But I think in the next year or so, we're going to see more of these helpers within the chat interface and outside of the chat interface that will solve tasks for us. I look forward to that travel agent that often gets demoed by big companies to actually materialize. And it can just go into my chat interface and say, you know, I want to have a beach vacation over spring break and then figure out, you know, when spring break actually is, because that's all on the Internet and, you know, who I am, what my name is, and what my family's names are and their birth dates and their passport numbers. And so I don't have to enter that into a cumbersome interface anymore. It showed me the price points. And probably we're going to the same hotel as every year anyway. And so I think that those travel agents and those, you know, kind of agents are going to happen in the next year. Plus, I think five years is my natural language vision and unlocking the world's knowledge, including software developers, to everybody, in any language, any human language, and maybe that's even happening sooner. 10 years is hard. 10 years is so far away. But I think it's the AI of things, the material, like the mechanical world of AI. So many things that we do in life. You need to grab something or you need to push something and go and check into any hotel. There isn't any AI involved once you get your room key. And maybe the elevator has some kind of AI because you push a button, what floor you want to go to and then it tells you to take elevator C and so you no longer push the button within the elevator. That's an optimization problem in itself. But I think there's so many physical things in life and we are still not at really self driving cars. We have a dishwasher, but I still have to put the dishes into the dishwasher and out of the dishwasher. It's better with 912 year olds than with 2 year olds. And there's so many other things in life where I think whether it's a robot or some other form of physical AI is going to take over some of the things that we consider as chores.

We're really excited to hear that and I think we have a very similar view of what will happen 1.5 and 10 years from now.

Who do you admire most in the world of AI?

I think I admire those that are building new stuff with AI and software. Those that have a dream of what they could build. I think those that obsess about a problem and not about the technology. We're talking a lot about AI, but at the end of the day it's what problem are you solving for the world? And you know, there's lots of biotech companies that use AI to try to cure diabetes or cancer. I'm sure there's companies trying to solve climate change with technology. And I think those builders, you know, the founders, those that have, you know, big ideas and that can change the world, you know, those are the ones I admire the most. And often when I meet with them in their offices, you know, on calls, I'm like, this is so cool. And obviously as GitHub, we are enabling a small part of that and so we feel really proud of being part of their journey and we're really excited about building more for them.

I think you're enabling a huge wave of new AI companies, especially those that are born open Source. It's amazing to see. What advice do you have for the founders listening in the audience who are building in AI today?

I mean, Sonja asked earlier, I think focus is everything. It's so easy to get lost in all the ideas that you can put on a whiteboard. And that's the danger of a whiteboard, that it covers so much space where you can put ideas. But focus ultimately is everything. Finding very quick market validation, often in the developer space. That means going product led growth, enterprise growth can come later. But from my experience there's nothing then a few excited developers spreading the word about your product, even though the big revenue number then later comes from big enterprises buying you. But the reverse is often much harder of going enterprise first and you might find excited people there as well. But the feedback loop is just so different. So it's focus, it's trying to find that flywheel, the product market fit. And then I think the other one is to think big. I think it's like it's easy to find small ideas on top of model today that get commoditized tomorrow. And so you have to think forward. And that 10 years is a long period of time, but that's a good period of time for a startup to build something that is actually meaningful in this world. And so you have to think big. You have to create a vision that may be much larger than the mvp. The first thing, the prototype that you're building right now. And I think that's really hard as a founder to draft out that vision and then decompose and go back to that small problem that you can solve right now.

So we'll close with some rapid fire questions. One word answers.

One word answers. One word answer, you change the bullet. Okay.

Say one word answer, one sentence if you need it.

Amount Enzos. Yes. Okay, let's go.

Okay. Will anyone meaningfully disrupt Nvidia and AI chips in the next call it five to ten years.

Yes.

In what year will we pass the 50% threshold for SUI agent?

2025.

And what about 90%?

2028? Will GitHub primarily too pessimistic? That last one?

We can hold you to it. Will GitHub primarily be using open or closed source models in the next five years?

Both.

Where does the majority of value accrue in AI models? Compute infra applications across the whole stack.

That had hyphened in it. So it was one word.

Is systems thinking and creativity going to get baked into the models in the next five years?

Maybe.

And will there be a new consensus architecture beyond the transformer in five years?

Of course. Yes.

Wow.

Why would you think the other way around? That said that it is a much easier bet to think that there will be a new architecture because there was other architectures before transformers and that doesn't mean it replaces transformers. Your cell phone still has a CPU Even though GPUs are the hot commodity right now. So I think yeah there will be new architectures and they be bigger than transformers today.

So interesting. I mean that would bring a lot of new oxygen for the builders in the ecosystem and a lot of things that would have to get reworked, rebuilt and rearchitected.

Yeah.

Amazing. Thomas, thank you so much for joining us today. It's been wonderful digging into the history of GitHub, the birth of GitHub Copilot and the ambition that you have going forward as well. Thank you.

Yeah, thank you so much for having me. It was so fun to talk to you both.

Likewise. Thank you.

Sam.