The present, past and future of GitHub

Steve came out 21, so GPD3 came out right after the build conference in 2027, Scott, in some open session about transformers and Dutch language models, and then after that GPD got into the preview and we got access to that and put open the i Microsoft partnership and we realized together with OpenAI that it was able to write decent code in different programming languages and would not mix up the syntax between ISA and Ruby on Njavaskup, and then OpenAI fine-tuned a model that was called codecs that was specific for these coding scenarios. And so in 2020, in August, we wrote a paper with three ideas we had, a text to code to text as in describing code and conversational codeings are recorded which then today is known as chat. And those two later scenarios didn't work well enough, but text to code as a prompting the model within the editor and automatically building auto-completion that worked so well that very quickly we saw our internal hubbers adopting the tool, giving it really high scores saying this is great, I wanna keep using this, it's not the typical management says you have to use it and you don't want to, but ultimately writing in the early days 25% of the code and those files that was enabled and then shortly after that number got into a 50% range or 46% I think early 2023.

And so that was the early days of 4 pilot in 2021 we went into the public video and within a few months is the goal and two million users and we saw more folks on social media saying, well I was skeptical that this could ever work, but it actually is good enough that I don't wanna work without it anymore. GitHub recently turned 17 years old, but how did it start and how did it platform evolve? I sat down with GitHub CEO Thomas Dumpka, who has been a GitHub user for 16 years, has been working on GitHub for seven years and has been to CEO of the company for the last four years since 2021. In today's episode we discuss, GitHub's remote first and async first engineering culture and why the company barely uses email, why GitHub seemingly stops shipping features between 2015 and 2020 and how they created GitHub code pilot in 2021.

GitHub's interesting internal tools in the early days like haystack, GitHub TV and help. How GitHub sees about 10 billion API requests per day, that's about 120,000 per second. And why Thomas doesn't believe that all Thomas AI tools would solve hard engineering challenges and many more topics. If you're interested in the past, present or future of a high-growth company like GitHub, this episode is for you. If you enjoyed the show, please subscribe to the podcast on any podcast platform and on YouTube.

So Thomas, welcome to the podcast. Thank you so much for having me. It's great to meet a person after exchanging emails and putting a name to the face. And reading your new set of every week. Hi, I appreciate that.

I appreciate that that's where interaction started. Before we jump into the history, I just wanted to go through a couple of like just interesting things that people might or might not know about GitHub. Number one is a tech stack. It is pretty commonly known or it used to be that this was Ruby on Rails Monolith at some point it might have been the biggest in the world. And then I think you'll shopify might might have come.

But today, is it still a Ruby on Rails Monolith or have things changed? It's still Ruby on Rails. And I think it's still one of the largest Ruby on Rails applications. The other one you didn't mention was Twitter. It wasn't the early days also Ruby on Rails.

I think all three companies in one form or another have somewhat moved away from this being the only part of the stack. So we still have a large monolith with about 700 engineers in the company contributing to it at different times of the year. Not all of them are working constantly in the monolith. We actually just passed two million Git commits into the monolith and tens of thousands of full requests. And but we also have moved beyond just that one architecture.

So for example, we're using more and more React on the front end. We have a number of services that outside the monolith, for example, the Copart API is a little bit more given that it needs lots of API calls for inference. The actions system are completely different tech stack kind of actions. I would imagine Rails might not be the best for a very heavy workflow. And it has actually a history because a large part of the action stack came from what's back then versus the team services and then became head and web and so there was a lot of net code in that code base.

And over time we are now evolving that into a more and more architecture with the goal of one of the other posts. And we're getting to four nights and beyond. And so our tech stack is very diverse today. Obviously we're doing also Swift for iPhone app. We have Kotlin for N1 app.

We're using all the clouds beyond also having our own metal in commercial data centers. And we have a modern software company with all the complexity and all the challenges that everybody else has as well. And I guess all the not simple trade-offs, for example, it's easy to point, you know, the community loves to say Rails does not scale or why would you do it. But I mean, you are one example, obviously, there's other companies who mentioned that. It feels like it's less about the technology itself, but what you're building on it and your history of it.

And then maybe you can spend a whole hour probably just talking about the benefits of having a mono-repo, but the monolith and for those, you know, hundreds of microservices. You know, when GitHub was in 2007 was founded for, I think more than a year, it was only the three original founders, Chris P.J. and Tom, plus Scott, who's now the founder of GitBattler and Scott Chacon, who's kind of like the first employee that was often seen as the fourth founder. And so now the team of four is maybe an off of working in a single codebase. You can move from much faster.

I think that was always important for GitHub to be able to move really fast and then ship your features. And it's much easier to get to learn the codebase and try to understand the dependencies. As the company scales and the product scales, it makes more sense to what we're very from the architecture. I'm so glad you're saying this the other day, I was talking with an early Amazon employee and he was saying the same thing how early Amazon it made sense. And then as you grow, you know, you figure out your tradeoffs.

If you want to build a great product, you have to ship quickly. But how do you know what works? More importantly, how do you avoid shipping things that don't work? The answer, Statsig. Statsig is a unified platform for flags, analytics, experiments, and more, combining five plus products into single platform with a unified set of data.

Here's how it works. First, Statsig helps you ship a feature with a feature flag or config. Then it measures how it's working, from alerts and errors to replays a people using that feature to measurement of top line impact. Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsig is incredibly affordable.

With the Super General's Fries here, a startup program with $50,000 of free credits, and custom plans to help you consolidate your existing spend on flags, analytics, or ABA testing tools. To get started, go to Statsig.com.pragmatic. That is statsi.com.pragmatic. Happy building. This episode was brought to you by Graphite, the developer productivity platform that helps developers create, review, and merge smaller code changes, stay unblocked, and ship faster.

Code review is a huge time sink for engineering teams. Most developers spend about a day per week or more review in code or blocked waiting for a review. It doesn't have to be this way. Graphite brings stack pull requests that work for the heart of the best-in-class internal code review tools that companies like Meta and Google to every solve company on GitHub. Graphite also leverages high signal code based aware AI to give developers immediate action on their pull requests, allowing teams to cut down on review cycles.

Tens of thousands of developers at top companies like Asana, Ramp, Tecton, and Versailles rely on Graphite every day. Start stacking with Graphite today for free, and reduce your time to merge from days to hours. Get started at gt.dev slash pragmatic. That is gforgraphyteefertragnology.dev slash pragmatic. Now you mentioned something really interesting, which I also heard that you run your own data centers, or historically have run your own data centers.

But I talked with some current GitHub folks, and they said that you in some parts still do so. Why did you do this? How is it changing? And are you obviously since you're now part of Microsoft as well? Does it make sense to use some parts of Azure and if so, what parts are using?

And you also mentioned other clouds. So like, how are you thinking of only the center, which again, we used to say, oh, it's just moved to the cloud and there's now an opposite thing as well. What's your take on this? Get up. You know, started on the cloud.

Really? Early days it was to my memory, it was Engine Yard as a platformer service provider, and then AWS, you hide the scenes. Oh, OK. You know, it's easy to forget in today's world where lots of startups announced huge funding, own skid app had no funding, until I think five years into its journey. And then back then, on the road of 100 million came from around that by a reason, always.

But until that point in time, GitHub was rushed. And it had very fast adoption. You know, when launched in April 2008, very quickly, the number of users and the number of public and private repositories kept going. You can still find, you know, people talking about that they're begging the founders to introduce a paid tier. So they have the confidence that the company can fly around.

It will be around. And so it was a natural business decision for the founders to say, how can we host this? Or more optimized cost given that we're bootstrapping this and we're having to pay for the service from our own revenue strainer. And they couldn't be burning money because they had, you know, they have no money from a check capitalist. And so I think that was part of our decision.

The other one is storing Git data, what we call today, our Git systems team in File Storage in itself. It's probably not the best use case for the top tomatoes that existed in 2008, 2009, where you had limited access to that layout. And we're, you know, especially the networking part of having multiple nodes communicating with each other. It was much more complex than it is today. And so the decision was made to move to servers in commercial data centers.

So we own the servers, we still own the servers in the access and the storage and all that. The data centers are commercial data centers. We don't own the data centers. It's own in the sense of making accords for this. It's own in the sense of we manage the service in those data centers.

Now, today's GitHub is a lot of that. The core is in these own data centers, but things like it have actions, code spaces, a core pilot run on Azure cloud and levels of scale that you naturally, whether it's CPU's in actions. Or GPU's in core pilot, of course, core pilot given its multi-model choice and has a topic models and open AI models and Gemini models. Not all of these models are on Azure. So naturally, we also have other provides often with both, you know, the first party API, aka the API that open AI or the topic provide and, you know, other clouds that have vertex, bad luck, bad rock and so on.

And we in fact now have GitHub fully boosted on Azure for data. So if you as an enterprise customer, new up won't your data or stored in Europe, you're getting a GitHub organization on a stamp that fully lands on Azure in Netherlands and in Sweden. We have the same for Australia, just announced a US stamp that will be FALAM compliant and we're going to expand into more regions in the US to come. Yeah, I feel these are like really kind of boring things, but they start to become really important when you are at a company that is now starting to care about these things. Well, they're not boring for me.

It was like, well, not boring, but like it's the thing that I think as an outside, you know, it's not the shiny features, but I agree. I had an engineering perspective that actually sounds pretty challenging. The challenge, you know, if you go back to the Google Ads conversation, it's enough you know a bit about Rails and how, and did not only on Rails be also on MySQL and so whenever you change, you know, the schema of a database table, a so called migration as fun. How do you do that if you not only have one stamp in one region, but you actually have five or 10 stamps and we deploy hundreds of times per day. In fact, I think this year we're forecasting 12 million deploys across about a thousand or so I see engineers that we have on the company.

And so how do you do that? How do you deploy, how do you go from one, you know, central stamp on all US data center cloud, if you will, to having, you know, deployment that goes to all these different stamps and the migrations that you need to be able to hold back. So that was a lot of the engineering work that went into that. Let's say, the actual work of moving this to Azure was less work than getting the engineering system to DX the developer experience actually aligned with this now via running in multiple regions. Yeah, one interesting thing that I always surprise people who don't know GitHub all that.

Well, those people think, well, it's now Microsoft, right? So it must work as in with Microsoft. And then, you know, one like fact that shows is all the case, GitHub is still remote first. It started as remote first initially and it was actually one of the few companies that even before COVID truly remote first. And as I understand, even today, it's remote first to tell me about this on a how you managed to keep this, how it's working inside a larger company, which Microsoft is not remote first.

There are, I understand parts of it that are more supportive of it, but generally, you know, people are often in the office. So the founders, they actually met in San Francisco. So you could argue that very, very early place was first time, like, three people in the same place. And that's often how that goes. But yeah, very quickly, GitHub started hiring superfence.

You know, people that were interested in GitHub, promoting GitHub, you know, help to drive in the communities. Those people got hired into GitHub and they were naturally everywhere in the world. And so very quickly, GitHub moved from a culture that was headquartered to a remote first culture. And that gave us an advantage when the pandemic came, because we were already used on being on video calls, on using Slack. In fact, you know, I think GitHub is very different than Microsoft when it comes to how the company communicates.

My joke always is when I wake up in the morning, because I'm obviously both. I'm a Microsoft executive and I'm a GitHub employee. When I wake up in the morning, on the GitHub side, I have lots of Slack messages, DM's channels to look at into. And maybe, you know, a handful of customer emails or emails from you that can help communicate with me in Slack. On the Microsoft side of the other one, I have, like, dozens of emails that I pay attention to, and maybe a few of you teams' messages.

And so I think that shows the async part of our culture that has grown over the last 17 years. And that is so important at GitHub using GitHub for everything. And so all employees across all the functions, not just engineering and product, but HR and COMs, finance, all the functions work on GitHub. And so they have repositories to describe a team. You know, they use pull requests to make changes, for example, to our terms of service.

Every company-wide announcement is a pull request against the repository that we call the Hub that gets published as a pages page that is only internally accessible and that goes to our identity provider. And so even there, we don't do company-wide emails. Almost never. We do an announcement on the Hub. And there's a link that is posted in the Slack channel that everybody can see.

Let me take a conversation there. So yeah, today we are very much remote for us company. But people all around the world in different time zones, almost everything is async. Obviously, there's meetings. And our town hall meeting is called the Git together.

And so that has to be in some time zone. And the challenge there is that if you do it, you know, adjusting it for the folks in the US, North America and Europe, you're missing all those in Australia and India, because it's just impossible to meet. So we try different times of a year to have one that is a pack of plenty of times on and a few that are European-friendly. Often, you know, it's not the way when you do one early in the morning on the West Coast. That's actually bad time for the Europeans, because that's kind of like when you pick up the kids from school and go and have family dinner.

So many of them actually prefer a later point on the day on the West Coast. So it's later in the evening when maybe everybody's watching TV or the kids are already in bed. So yeah, we're trying to really keep that spirit and it enables us to hire talent in different places, in different phases of their life. And I think that helps us as a company to be as agile as possible. Yeah, it is pretty cool to hear because GitHub, I mean, you can use GitHub in many ways, but one popular way to use it is async way, right?

So it's kind of cool that you're using it the same way as a lot of the startups are. I think one of the core pieces there is not only as the startups are, but as the open source ecosystem is using it, right? But the open source ecosystem by design is async. And they're not all in the same place that would never work. If an open source project could only, you know, you could only be contributed if you're in the same place in all the same time zone.

And so given that we're catering to both commercial customers, startups, enterprises, those that are paying us money for GitHub enterprise and cool business, I've also catering serving the open source economy, the open source ecosystem and such as a company, even though the GitHub core itself was never open source and we're operating pretty much like an open source product. One fun fact I've heard is you have some really kind of fun and interesting internal tools, some are still here, some are not. One tool that I understand is no longer there was called haystack, which was an internal exception tracking app. And someone told me it was the best piece of software they've seen. Can you share a little bit about what past fun internal tools you have and what kind of internal tools you still have today, especially for what engineers use?

If you look back into GitHub's history and we don't have the time to cover it all today, I can recommend if I'm allowed to another podcast, a quiet podcast, they had an episode on June 5, 2018, so the day after the acquisition announcement that covers a lot of the history of GitHub in the early days and in general a really good podcast. And they actually mentioned this time in GitHub, you know, when it started, it had a very non-traditional way of operating and managers. Everybody was encouraged to work on their passion projects. And I started to get up for many years and it didn't have a traditional IT infrastructure company. Everybody was built in-house because there was the belief that we can build, we as GitHub can do it better than a tool that we can buy off the shelf.

We maybe come back to this later when we talk about AI. That future might actually come back to some startups. So we had a tool where our own internal video streaming platform, it was called GitHub.tv and so all the townhords and so on. We have a stream on all the platform and of course, that no longer exists. We're using Loon for that.

Haystack already mentioned that was exception tracking. And keep in mind, 15 years ago, there wasn't like established players in that market that you could use, especially not in the Ruby Nailsburg. So Haystack was one of my such tool today. It's a century, a really big thing for that. Another one was HULP, which was our internal support system, where tickets got out for folks to work on.

They didn't have internal control teams. And now this is all in Zendesk and HULP has been retired. But some of these ideas have led to new startups, like Hubbers, so we call GitHub employees. Hubbers have taken the idea and maybe they're able to frustrate that we're shutting down with their internal passion project, have taken that and created that. I think, you know, culturally, we're still encouraging folks pretty much to experiment and to incubate new ideas.

So if you're trying to make those external facing products, and there's a number of examples from GitHub's to really as well there. And that comes to mind, which came out of Adam, which was our editor. Oh, yes. A few weeks later, we should be able to answer. We'll comment on interfaces, open source projects, and so everybody can see what we're doing there and can take the ideas and be mentioned.

Stack Stack earlier, the CI, for example, is with Mango. And so it also gives us a full-ever one-star learn how to build the CI, can you see the CI as an example. One thing that keeps surprising me out with GitHub is every now and then there's a security incident that is in the press that is like a big deal. Not always, but sometimes it starts with like X company, X, had a security issue. And it starts like, oh, they detected it because GitHub alerted for them.

And the very famous one was in 2022, Heroku had a security incident. And it started by not Heroku noticing that something leaked, but GitHub itself noticed some strange patterns. They contacted the Heroku security team, who then confirmed it. And this just struck me a little bit striking. Hold on, how is GitHub having better or very strong security?

I'm not going to say better, but in some ways, in this case, clearly they got earlier. What is your approach to security? And again, this was not even right now. This was years back. It just suggests to me, you probably think about security a little bit differently than maybe some other companies.

Security is part of our culture. We have the saying that security is priority zero for everybody. In fact, our previous CISO Mike Hanley introduced this concept. He came from a dual, the two-factor authentication company. He introduced this concept that when the question is asked, who here is on the security team, every other basis at hand.

And so we internalized that security is part of what we do. And of course, we want to drive innovation and make customers happy, but we cannot be in the market if we lose the trust. And of course, the worst day in my life would be that I got to call and say, I lost the private repositories, we lost the platform. So it's important to compare this to an attacker. And now have to do the damage control.

And so it's really important for us, the CISO, the chief security officer, reports directly to me. And we have a team of about 150 or so in a while, always that take care of security from multiple endos, one of the of course, the private intelligence. Working closely with the Microsoft security team, the so-called Cyber Defense Operations Center, and those folks that look into finding security vulnerabilities, that teaming not only for the traditional software and willing, but also for the AI pieces. And you can imagine, you know, at the scale of GitHub, but even more so at the scale of Microsoft, there's a lot of that intelligence. When you combine all the intelligence, you get a lot of signal.

One such example is a very trivial example is that if you have a person, if you, for example, your user ID access is not only the pragmatic engineer, the positories, but also those of, let's say, BMW and Mercedes, that person is very unlikely to exist in the industry, right? Like even if you're working for a systems integrator, then you typically don't work on a BMW and Mercedes quadratic together. So there's a lot of intelligence that we can collect by having the holistic view, even more so when you combine it with all the other Microsoft systems. And we also have a security lab. We have a team of research that are hunting for security vulnerabilities using our own security products, like CQL, which is query language that you can use to find variations of existing code draws, you know, code vulnerabilities.

That tries to find those in open source projects and then departs them to the open source maintainer in a responsible way, helping them to fix those in the meantime of the disclosure, hopefully the back is already fixed in there. So we're doing a lot of that, we're investing into a lot of that, but of course, nobody is perfect. And so it's really cool for us as a company to have this ingrained into our culture, to not have secrets and software to affect blocking all the pushes and everything. Exactly. I guess open source might help here, that you're a big focus on open source.

But you mentioned 150 people working on security aspects. How many people or engineers are in GitHub roughly these days? So GitHub all up is about 3,000 employees, about half or so in what I would call an engineering product design or EPD. So that's about 10%. If I just look at the security of our program.

Yeah, it's tough to have engineering function and then look at just engineers, I see engineers a little bit under 1,000 that works and then it's of course managers and product managers and technical pull-down managers and sign us and all that. One interesting thing I've heard from a parent gets to employee is you are starting to look into hiring junior developers, developers, less experience, which is a little bit different because most of the industry, we don't hear this. Why are you deciding on this? And like, this is just a really positive thing to hear. I'd love to hear more about your thinking.

We were really excited about working with young people. You saw some of those in the second decade, you know, yesterday as well. And in fact, you know, just on Monday, our intern class for the summer started, we have three groups that start on different days and go for the internship. So those are very early in career folks and that often, oh, no, not often, that still go to college or university. And this is a program that we institutionalized them after the pandemic was over and you could bring people back in person because obviously, half in person, where these have to meet with folks at our services headquarters or here in the present or elsewhere in the world.

And so we have an intern program and often, all these interns get a full time offer at the internship or maybe they come back for a second year. And so it's a lovely to see that, you know, those folks that bring cash ideas, a great amount of energy, you know, the latest learnings from college and university. And often, you know, a different diverse background into the company and, you know, coming in and often, you know, the folks, you know, that are younger in Korea, bring a new perspective to the team and say, here, this is, you know, why don't we try this? Or I want to incubate this idea. And so I excited about having this kind of like both Julia and senior population in the company.

And it's not only for an engineering. You know, it's the same. And if you can into sales or into marketing, obviously the way, you know, marketing works today is very different than it was, you know, five, 10 years ago when the press, you know, traditional media played a much bigger role. Today, you gotta be, you know, in a podcast and you have to be on YouTube and take talking. I'm like, what do they do?

Does that, you know, you see more and more of that happening? And of course, you know, when you hire people earlier in Korea, they give you this idea. They give you that input and, you know what, you talk to a lot of people in companies, there's always a debate, there's always a debate between those that are defending how we've always done it in a 50 year old company like Microsoft that obviously exists and those that come in and say, hey, you know, nobody in my, you know, watches TV anymore and or CNBC or whatever. And they're all watching just, you know, three minute videos on TikTok. And so I think that's really important.

And then we're trying to have, you know, a nice balance between our own career engineers, senior engineers, we have, you know, a number of distinguished engineers and they all come to be back to all that. No, I look, because like when I worked both as an engineering manager or as an engineer, having an intern, it's just like boosted morale. Like we were so much more enthusiastic. I'm not gonna say that we necessarily did more work. I think we might have, but we got fresh ideas.

And it's just so rewarding looking back at those interns, you know, I now see them many, many years later, some are not principal engineers, some are CTOs. But the one question that a lot of people who are maybe less technical than you and have not seen the benefit of the internship, they're thinking like, oh, I'm hearing all these AI things, including Microsoft is saying it's so efficient, you know, they're not talking about AI colleagues on the keynote. Why? And now this is not Microsoft people, but we're hearing people go say like, oh, it's now a level of a junior engineer. And they're thinking, hm, maybe let's hold off on hiring new grads because they're telling us, you know, some of these so called experts that it's now the level of junior engineers.

So maybe we don't need junior engineers. What would you suggest to people who are in this thing, maybe not as informed? Because clearly you've decided it makes sense. And you know, this thing doesn't apply. But they're thinking it's real.

I think that's backwards in many ways. I think actually folks that, you know, go to high school now or to college, or even, you know, kids earlier in the education, they get to use AI in a faster. And they get it because they are, you know, taking this with an open mind. They don't have to, this is how we always done it. They don't touch, never touch that running system.

They haven't been in an experience where some change that was applied, you know, from upper management or from the engineers themselves has led to, you know, a big outage and things like that. So they're more open minded. You know, you kind of see that when you look at media as we already talked about, like kids are much more open to just scoring full shots and consuming the content they'd like to consume while, you know, when you're not going to have a child heading into the interview and you got to watch, you're not living in the room to be but your mom and dad decided it's on tonight, right? And so they have much more freedom. And I think this will lead to ultimately junior engineers coming into the companies and then in like, prompting skills, you know, like experience with different models.

Like, you know, intern doesn't mean I haven't worked for another company before. It might be my second or third internship or I've already been coding with, you know, a group of students on my own project on my own app. So you get a lot of good new ideas and outside perspective that is ultimately crucial to compete in the market. I think vice versa, you know, these interns then go back into college and they have worked on something new deal. If I'm a mind-to-mind university, I always have the feeling I gotta get out in the industry and learn how it's actually done because while, you know, there's new learning coding in university, but you don't really have an engineering system.

You're not having tech debt. You're not working on a legacy code, but it's engineering. The company means you're working on somebody else's code off now, you know, you know, 17 years old code and you have to follow up on decisions other people made. And that's not how you learn coding in university. So I think it's both for us important to have those specialities within the company but also for us important to give back to those that in a future become get-up customers.

I love it and I feel it's also just a very, it's the cheapest way to do it. Just like, you know, you're not gonna have the highest salary for the new people. This is a silly way to think about it. I talked with the product manager recently and I just like how the user went when you said it, this product manager was saying, she was saying, this is while we were doing the Gen Z research about the latest generation. She said, I love Gen Z.

She's like, for years as a product manager, I'm sitting in front of engineers telling them, oh, you know, product thinking, think about the customer and they're like, just tell us, you know, what we need to do. And she's like, the huge generation comes in and they have opinions, they're like, I think our customers would like this. I have tested a competitor, here's what they're doing. She's like, I love it. So I wonder if by hiring these people and actually just ignoring, as you say, the back, we're thinking, you might get the next generation of software engineers.

Gen Z is already to order, I think. Gen Z starts 1980 or something like that, and then it's like, Gen Alpha, right? Like 60 is all coding today. And so that's Gen Alpha or, you know, sooner, whatever, Gen B, I guess is the next one. And so, but you're right, you know, you're getting folks that didn't learn to code on a Commodore 64 or on a PC that, you know, have a lot of low level thinking, but also, you know, in a different environment that cool up with smartphones, that cool up with being always connected.

They just have just from an expectation perspective, they're looking at this systems problem they're trying to solve with a different perspective. Yeah, I wonder just like, a silly thing, would you rather hire an engineer with the same years of experience of like someone who has, you know, like, has traditional coding and learned in university or the same years old, you learn to university on this university projects or this engineer or this, this fresh graph, who did the university, but they actually have before that five years of building programs and Roblox, and they actually built this like hundred person thing. It's like the skills that that person brings and the mindset, you know, the way they think about things. As a third group, and there's lots of folks, you know, at Microsoft and GitHub that don't have a fall. Yeah, it was a big question.

And I don't know about event, but that goes back to the earlier discussion about being a remote first company. You hire people, because they're passionate about the product, you hire people because they have a green contribution graph on their GitHub profile, because they have shown they contributed back to the Google Analytics codebase, to the Git, you know, open source codebase, where, you know, GitHub, we traditionally have employed folks that are spending a lot of time on maintaining Git together with open source community. So I think a lot, you know, what actually plays a world to us is that folks have shown the right mindset to join GitHub. If you don't have a green contribution graph on your GitHub profile, that I think matters more to us than whether you have five years at one company and five at one company. Of course, we, you know, take people to an interview loop, and I think increasingly we're thinking about how do we leverage AI within the interview loop.

There's nothing wrong about that from my perspective. In fact, I would say if you want to, you know, get a job in a tech company very soon, you want to be asked to show your pumping skills, your propited skills, if you will, and how you use something in agent mode or the coding agent that we introduced this week to get the exercise done, you know, to basically, because the goal of the future engineers no longer divided off from scratch, and the goal is to combine their pumping skills and agent open source libraries into getting that problem solved much faster than they could have done two years ago. So with that, these were some of the, like, a bunch of interesting facts. I wanted to talk about the past, and then later the president and the future of GitHub starting with the past. So Git, I did a podcast episode with Linux currently, Daniel Gekkke, KH, and he told a story about how Git was created in 2005.

In fact, recently there was a podcast with GitHub, a staff engineer at GitHub, and Jabid Linner Store Worlds. In 2005, Linner Store was, got frustrated with source control for Linux projects specifically. There were some commercial things, we had to set it down in 10 days, he wrote Git, which was obviously open source. It was meant for Linux only, but they released it and it turned out it's pretty good. GitHub was founded in, I believe, 2008.

Can you tell me about these early days? What happened then? What's your understanding from talking with the early founders? The first commit was October 2007, so it was about two years after Linux had done Git, right? And then October 2007, to I believe February 2008, is when they started beta testing it with folks in the Ruby or we on this community.

And then April is when the public version of GitHub launched, so it's really fast as well. October to April, it's half six months. If you go back to the history books, it's Chris and Tom, Tom, and Chris and Bonner and Chris once read meeting in a bar, as I remember, and having seen Git and figuring out that there isn't a place where you can host your open source repositories and your private repositories together. There were some other things like source watch, the most popular open source platform back then, but also painful to use. I think that's fair to say.

Those that I had a couple of projects on source as well, they were kind of designed for a different era of the web and didn't make the jump in that mode, ultimately became known as web to the low or not native. And so I think the idea was, Git is here, Git is amazing, but I want to host it without setting up a server and installing the backend and managing SSH access and so they started building a home around that idea. What always made GitHub is that they put the developers first. Like if you go on the VVAC machine and look at the first Git up homepage, it isn't very fancy. It looks like a commit lock.

It's very short announcement of, hey, we should listen to feature, try it out and let us know what you think. The story about our logo, what is now known as the Octocad, is a funny one and I learned that actually from the acquired podcast because they learned from the Twitter founders how they get their logo when they bought it on some stock graphic page from a British designer, I believe. And so they looked for other graphics that the same designer had done and bought this hyper-lit of an octopus and a cat and made that the logo. Right, so there was a lot of, as a booster startup that's scrappy, it has a cool technology that might become the future of version control.

And then the ability is now known as CloudNative, and CloudNative Company. And it grew fast and back in the day, probably the fastest product market fit. Nowadays, there's other companies that have similar, but it's a different time. It's a different time now. And I think it was unheard of how quickly it's spread like that.

If I was in 2008, I was still working in the automotive industry. I was at Bosch, so I didn't use GitHub in the first year. And then I quit Bosch at the end of 2008, not because of GitHub, but because of the iPhone SDK. And it became an IZV building apps for German companies. And so I created, I think, my GitHub account in early 2009.

We can look at that, I think March or April 2009. And then I was at Rails Conference in last week, I was in 2009 and saw Chris once Thanksgiving a talk about GitHub and what they were up to. And that's I would say when I became a GitHub fan and then I started using GitHub in my products. But until that point, you would use some help for the tool and solve it on some boot server or maybe you already had the cloud and then maintain all that yourself. And ever since people just, you know, long and must get up and then create people.

Yeah, when I looked through the history of just the things that I could find, what struck me as like, so like as the first coming from 2007 and 2008, the service was launched. I think you said March or something like that. April, sorry. And already in 2008, Reddit, Yahoo, Twitter, and Facebook already onboarded. Facebook was surprising to me because I knew they used Mercurial, but apparently they used it for their open source things.

And these were very hip and very trending companies at the time. And obviously from there on, as you said in 2009, this was the obvious place to find. Why do you think it was so popular? Like what was the reason? Was it open source?

Was it? Because Git wasn't even like back by talking 2009. Like now we know Git is great and it works, but back then this was not clear. There was everyone's using SVN. I remember at the time and Microsoft had their own really heavily invested it.

TFS, team validation server. Why do you think this product market fit just hit so bad? And Devs were like, yeah, GitHub is the place to be. Solve the pain point that you have with all these other version control systems. You know, subversion, TFS, you know, had its own version control until much data when they added Git support.

They're painful to use. And they're painful to use, especially when you had multiple teams working together within the same codebase, Git bought this concept of you have the full repository on your machines. You can switch from one lunch to another, even without having an internet connection. And you always have everything on your computer. So you could make changes to multiple branches and then push upstream or shared with the core workers.

And in some ways, GitHub, I think, is the irony of self-development tools. Because you have a decentralized system like Git and then you have a central hub where that world depends on today and where everybody pushes to. So this notion of decentralized systems is still something that sounds great when developers are chatting about technology. But I think humans are longing for home. And today at GitHub, we have the same way the home of software developers, where they collaborate human to human and human to agent.

I think that played a big role. You had a new vertical process in that people were intrinsically motivated to try out because they were frustrated with using some versions of it. Or even CVS, you know, and something like that. And just wanted something new to solve that problem. And then it was just easy to shoot an account and try it out.

And even user interfaces, like, pausing the repo, clicking the file tree, GitHub innovated a lot in that compared to what was there before and making that age-ex request would load really fast. And you wouldn't make it full of full-plate. GitHub invented the pull request, you know, this notion of that you can fork people, make your modifications. If you'd like to keep your fork, you can just do that. That's totally cool.

Or you can send a pull request back. So we're asking the other maintainer to merge your changes before that. The file's the best change. This episode was brought to you by Augment Code. Your professional software engineer vibes will not cut it.

Augment Code is the AI assistant built for real engineering teams. It ingests your entire repo, millions of lines, tens of thousands of files. So every suggestion lands in context and keeps you in flow. With Augment's new remote agent, give a parallel task like buck fixes, features, and refactors, close your laptop, and return to ready for review pull requests. Where other tools stall, Augment Code sprints.

Augment Code never trains or sells your code, so your team's intellectual property stays yours. And you don't have to switch tooling, keep using VS Code, Jeff Raines, Android Studio, or even Vim. Don't hire an AI for vibes, get the agent that knows you and your code base best. Start your 14 day free trial at augmentcode.com slash pragmatic. Well, I think this is one of the biggest things that people miss as I understood, like understanding.

So like, Linux or was designed Git, and a lot of GitHub or the Git functionality comes from there. But the Linux workflow was email based. So actually in Git there is a command. I don't remember the exact command where I think it's something email where you send an email with your changes bundled, which your Git changes bundled. And that's how Linux works.

They just do email. And GitHub does not do this. Indeed, GitHub invented the pull request, which is a big difference between even today how Linux uses Git and GitHub does. And yeah, it was a smash. What was the pull request invented?

Was it early on? I'm getting the date form. I think it was a year or so in to get us. It wasn't there on day one. It came sometime later.

And we can look it up and it's shown on. But it was a new thing at the time. And I think it's ultimately liberating for software developers. And where you send a pull request, and if the maintainer doesn't like it, they can just close the pull request or leave it open. Others can see it.

And they want to pick it up. And they can just jump over to your fork and keep using it there. And so you see a lot of that also happening, that people just keep their forks independent because they want to have the obligation to engage with the main project. I have a bunch of forks where I made some modification for my own hobby project. I don't see a big reason that that needs to go back into the main branch.

Some of that might be just a bit packy as well. And so it makes it much easier for developers that want to collaborate, to collaborate with each other. And for the others, it democratizes how they engage with open source, how they don't from it, how they mix and match and so on. So what I have a gathering of my putting it together. Open source was clearly one thing.

This new collaborative workflow, especially with open source, but also one. I think one thing you didn't mention, but I wonder if it is a part is how even if you use GitHub, you can always move to your own Git server. It's very easy to migrate. It also works offline. So even if GitHub is offline, yes, it's a central hub.

But if there's a GitHub outage, I mean, we're not happy about it. And people complain these days. And there's not many of them to be fair. But even when that happens, I mean, oh, I guess I can keep working locally. Like I can keep pushing.

So you might not, if it's just, again, if it's just like a 30 second outage or a one minute one, again, not advocating for it. But you might not even notice because you're just doing your local thing. So I think as a developer, I think we appreciate when we know we are not locked into a mobile by the way, it's free, a lot of the, sorry, not per se, but for open source, it was always free, right? It was always for open source. And you might say GitHub invented a version of the freemium model that is not at base.

By traditionally, freemium is at base. The fee users get something for free with advertisement. And then the pages get a little bit of advertisement and get more features. GitHub originally had the separation between everything you do in public as free because it helps the community. Obviously, it helps the social network quote unquote, or GitHub going.

And then when you wanted private repositories, you had to pay for them. Shortly after that, acquisition in early 2019, we changed that. And instead of paying for private repositories, we actually made private repositories free as well. Because we had a lot of individual developers giving us feedback, especially when you'll travel around the world for an American four dollars a month, might not be a lot. But for somebody, a different country that is much more money relative to their income.

And so we had a private repository and today we charge for what you could call enterprise features, like single sign-on or branch protection, things that a student or hobbyist probably doesn't need. If I'm honest, when I work on my hobby projects, I really write any tests. I certainly don't have a pull request. In order to review my own code, I just push into main branch and that's cool. And so, but GitHub innovated in the business model space as well.

And you mentioned that the scenarios where it's helpful to use GitHub or Git on your local machine. In 2007, 2008, flights didn't have Wi-Fi. At least normally, Wi-Fi wasn't that. And I don't think Wi-Fi has had Wi-Fi as far as item. And I don't know if Star Wars made me Star Wars already had it.

But there was much more places where you would work or smoke on your machine for quite a while. And being able to commit into the repository, there wasn't a separation that didn't have a push. You would always commit into the upstream, change planches, rollback, all these operations that are now a natural bit. They're very natural in 2007, 2008. So GitHub started off.

It started to get real big traction in 2008, 2009, 2010. The next big kind of mouse and ironman from developers' perspective is, until then, to use GitHub, you could use the web version and use the local command line interface. You just learned all the commands. It looks about the easy ones are easy on them. Like, cherry picking and all that.

I was always confused by that. And then in around 2014 was the first time that GitHub actually released desktop applications. But not only did it release desktop applications, it actually released the Atom text editor, which I love. I use it for so long. It was a lightweight editor.

It released the electron framework, which powered the atom. And then GitHub, in 2014, 2015. Why do you think GitHub waited that long to have these desktop applications? What was the goal with Atom? And how did this help?

Did it actually help get more people who just liked a nice user interface and were not the command types? I don't know the history of all these apps. My suspicion is that you say, wait it this long. I make the counter argument. How long is long for startup to run a core product?

Having multiple other products that may not become a distraction. I think each of those solve specific problems that the team saw. Adam came out, I think, a year or so before VS Code launched. It's created the time was for a new generation of IE's. Both of them were open source.

For the app position, they both ended in the same company. And then it would be made the decision to continue all journey on VS Code and entire atom. But it goes back to this developer first culture. It goes back to GitHub's origins where you would join as an employee. And you wouldn't have a manager.

You wouldn't have a backlog. You would have the... So back when there were no managers. There was obviously a CEO in a little bit, but that was very flat. And people on boarding was always at headquarters.

So even though I was a remote first company, you would spend a week or so in our headquarters in San Francisco. And you would go to make an espresso. And that was literally one of the onboarding videos. And they kind of have some future, whimsical future. And you got told, pick something that you're interested in.

And that natural leads to developers picking things that they want to solve for their jobs. And so Adam was actually a response threat to the CEO at the time. And then for most of the get up's journey until the acquisition was one of the core maintainers of the island project. And so I think... You don't hear that all about the CEO being a board maintainer.

A lot of that is about the passion of the people working there. I don't know exactly the story of desktop, but my assumption, that would be that they saw a need to expand the people that can use GitHub without knowing all the intricacies of Git. In many ways, the GitHub user interface on GitHub.com Also served their purpose. If you think, for example, about blame, use them on GitHub.com is just picking about the C who modified the file. I have the line on the file.

If you do get blame on the comment line, it's much, much harder to figure out what to watch. Especially if you don't know a lot about software development. So it's all about going to user base and expanding the people that get utility. I'll say that I use GitHub desktop a lot. I mean, there is a different...

And I know how to use command line, but I just like that. I don't have to think about it again. So I appreciate it when it came out. I barely use it, but I use GitHub integration and VSCode a lot for the same purpose. And so I think even that, you know, Git as a protocol, with SSH access and HTTP access, which was also by the way, wasn't something that was very prevalent in the early days of GitHub.

And it's now much more use because it's easier to access through HTTP and then then through SSH. I think all of these pieces, you know, are ultimately helping, you know, to create the developer experience that we now consider normal, but by no means was normal 20 years ago. So then we're getting to the Microsoft acquisition. So we've now passed 2015 as now 2016, or so. You were in the inside of Microsoft.

You were already working there. How did this come about? What was Microsoft thinking? Why was even Microsoft interested in GitHub? And then how did the purchase go from your perspective?

It was 2018, early 2018, that back then that frequent my boss within Microsoft CP in the developer division doing mobile developers tools. Nat came from Zamarin, so I had joined Microsoft himself when I joined, I had joined the hockey app acquisition. So we ran like a bit of an outside in team within Microsoft with lots of people coming from my companies, lots of, you know, cloud native experience, a non-traditional stack for Microsoft. But at the same time, also Microsoft had changed. It was now about four years since Satinadar had come to CEO, Satya had very early on and braced open source, you know, then VS Code was launched, and that became open source.

So a number of steps that happened where Microsoft changed. It's fundamentally positioned on how it views open source, how it views, you know, the stack and where the future is going. You may remember this part of the strategy back then was called first mobile first. And, you know, in many ways that is still true today. We're not saying no longer saying those two things.

You know, if you think about how you interact with Microsoft products today, they are, you know, on every device, regardless of who makes the device more happens. This was not obvious, because it was still Windows first. They're still feeling that Microsoft is only Windows. And yeah, I heard this was set everywhere. And I think outside of Microsoft we were skeptical, honestly.

But, you know, obviously the cloud stack, the compute stack that Microsoft offers today, not only to its own products, but to any company in the industry really. One thing I learned early in my journey at Microsoft is that when you're a small startup, you consider, you know, other companies in the space competitors and they, you know, quote, unquote the enemy. And Microsoft competitors are at the same time also customers and often partners. And we're providing, you know, if you take, for example, Azure, Azure, our inference stack for language models, they're providing those not only to our own co-piders, they're providing those to many other companies that may directly or indirectly compete with GitHub or with other Microsoft products. Right? So, in 2018, the world view in Microsoft had changed.

I think the reputation started to change. We at Microsoft started to believe that we could pull off an acquisition, like GitHub, you know, make GitHub part of Microsoft and not lose all the open source maintainers, because they, like Microsoft, you know, is not going to be able to do it off GitHub. And we said very early on, clear principles of what that looks like. And 2018 was about two years after the LinkedIn acquisition. It was longer since the micro-act acquisition.

So we had kind of like two examples of acquisitions where we kept the brand and the platform independent, even today, when you go to a LinkedIn homepage, you don't see a lot of Microsoft there. Seven years after the GitHub acquisition, there's no Microsoft on the GitHub homepage unless you're using an entire ID, you know, as a single sign-on provider, or of course we have blog posts where we talk about, you know, co-pilot and Microsoft, a fine model and then things like that. And Minecraft, you know, many kids, I think, realize much later, you know, in their childhood that one of their favorite games is actually the same company that also produces the operating system and the professional network and GitHub, right? But part of, you know, when you look at those two acquisitions and then you'll see GitHub, it feels like a natural consequence, like the natural next step for Microsoft to go down the path.

Microsoft always has been a developer first company, you know, but first product was basic for the Altair and, you know, here at the conference center, I don't know if it has a 1975 experience where you work on a fake Altair and pass some coding tests. You know, that was basic for the Apple II and obviously Visual Studio in the 1990s. I think my first version of Visual Studio was C1.0, came with a book and then had Visual J, which was like Microsoft's Java, and then bought like a full-scale Visual Studio 7 for way too much money back then. At least, you know, for where I was as a high school student, right? Obviously in today's world, selling the IE at a one-time price would be something that has no Has the market fit anymore.

You know, Microsoft lacked access to the open source ecosystem. It didn't have, you know, the same attraction to cloud native developers. It was a big being not trending at all. Yeah, and it was important from a business perspective to have that ecosystem. It was important for us, you know, to put developers first again.

And so that was actually the first principle of three principles. And we believe we can be accelerated because GitHub in 2018 had a bit of the deputation of not being able to innovate anymore for various reasons. And we can talk about that as more in detail. But it was really important to think about acquisition, not a Microsoft gets a lot out of GitHub, but Microsoft is willing to invest into GitHub, you know, GitHub in 2018 at the time to start the conversation to them was about 700 employees all up. And I mentioned earlier, it's now over 3000 employees.

So that investment surely has happened. And we have leveraged in a lot of the Microsoft stack and Co-Pilot comes to mind that we're using, as I found the end of the relationship with OpenAI, you know, to build our core generation product. And then the last one was of course, also Microsoft wanted something back. And so GitHub accelerated Microsoft and the easy answer there is how did we achieve that by growing it? And I mean, we announced last July.

So about a year ago now that I was going to over 2 billion annual recurring in Avenue Run rate, and that keeps going and very happy with these businesses, you know, contributing back to Microsoft's earnings. But in that order, right, developers from making developer products, accelerate, and then eventually get up, you know, accelerating Microsoft and giving back both on the product side with Co-Pilot on the revenue side with the other ones. But I think this is this last thing is just worth emphasizing in the sense that I think as a developer, I really like that I like using products where I know they'll be around. So you're saying that, you know, GitHub's revenue has been consistently going up more, enterprises, more companies, more teams paying for professional use cases, right, to help their work. The memory correctly 2017 was the last official revenue announcement that you have made before the acquisition on the very about 200 million on rate.

And they announced that that time that they're looking for new CEOs across the world, was ready to step down and then ultimately, you know, resulted in the acquisition then in June 2018, full acquisition and new CEO and that treatment. But like 2017, you know, 200 million to 2024 in seven years, revenue went up factor 10. Yeah, well, this is which is also kind of reassuring to hear that, because there's always a risk like we know Microsoft is a for-profit company. You know, like such a net-level report to shareholders is good to know that those things are going well as well. Well, and I think, you know, the full-long time developer tools were not seen as an revenue drive-off in the industry.

And I think, you know, there were a few examples like companies and Jack Brains comes to mind, or Jay Fork, there's a bunch of companies that, you know, we're focusing on developer tools, but I think, you know, if you try to back five years or before that, because it's like seven and a half years, and we talk with such a capitalist about an idea that we have, you know, I about a developer tool started going to tell you, you need something else beyond just developer tools, because that's where the big money is. And that's where obviously has dramatically changed. Absolutely. But as I was talking with Scott Booth, the interesting thing was that the last company that was able to make developers pay for, the developers tools, a lot of money, we're talking thousands of dollars, was Microsoft into two thousands, where this was pre-when internet was small, and developers didn't just pay for developer tools, but they paid for MSE and documentation for actors to the latest software.

And, you know, that time has passed, and we were talking about some of the learnings, but it's interesting how Microsoft figured that out. And I feel Microsoft is very good at figuring out this great mix where, again, back then, and I worked at a Hungarian company, we paid about $1,000 per developer in Hungary, because it made us so much more productive. So, we'll go today, I part on this one. But you mentioned something interesting, which I also noticed. So, I was looking back, and I remember back in 2020, when GitHub desk golf came out, it was great, I think I started to use GitHub more.

But then, from 2015, nothing really happened. Microsoft got GitHub great, and I remember on online forums as well, people were saying GitHub is not doing anything. And then the next thing, I looked at a change log, and the only notable thing I've seen shipped, it started in 2021. Then GitHub sponsors came out, the package registry, co-pilot, code spaces. But what happened there from 2015 to 2020?

It almost felt like from, I'm sure people were working, but from the outside, it just looked like nothing, like bare in land, and more people being tired, and you alluded to this. What was going on behind the scenes? I mean, obviously, the time before Microsoft, you know, 2015 to 2018, I only have PSA and a little bit of insight. I think the big problem that GitHub had, especially before the Microsoft acquisition, and for some time after that, was that the platform had gone so much. And so many people were relying on it, being available and not broken.

Plus, many developers did the big ban and still are very much involved with the brand. Like the OctoCAD, you know, internal because of Mona, Mona Lisa, Mona. It's something that is recognized to get asked about it on the street, or in a coffee shop, or in the Lego store, because obviously the employees there are often lots of college students and I mean, I've been, you know, I had an airplane, the cool member asking me, how do you know GitHub? He was like, well, you know, use that in college. And for some, you know, computer science course that I took.

And I think if you have something that is so beloved by the space, that also means that applications are really high. Like it's often that, you know, the disappointment is even bigger if you actually care about something. But if you don't give a damn about this thing, then whether it's up or down or that's broken, it doesn't really matter to you because you hate it anyway. And so I think those two things combined led to, you know, people really being worried about shipping stuff, because you would change something into the action from developers when you change something, whether it's in the user interface or things work or hate limits and things like that, is often there's, you know, a loud minority yelling on the internet. And there's a silent majority that actually fine with the change, but don't say anything and a small change might lead to an outage.

And then you're the one that may three lenses have changed in your first week and you won't get it done. That's obviously not encouraging in your journey. So I think that, you know, created an organization that actually still shipped a lot of things in what we call stashes, what Microsoft calls dot foodings, so features that landed within the organization that Hubbers would see when they use, you know, one funny thing is we have, even today, as we using GitHub every day, I often actually don't know if that feature is available to you, because I only see GitHub, how it would see it. And that's a way to disable all these features, but how do you apply? Well, I can hide the staff bar and then disable the features that you don't see, but how often do you really do that and remember that in a conversation that you're getting, it doesn't have the feature, but I have it.

And I thought it already shipped, but it's actually stated for next week. So I think that that pretty, you know, a culture of various things where internally shipped, but never made, you know, too public, because everybody's worried is that good enough to ship it. You know, see, oh, change was in flight, there were a number of cultural issues. And then as we closed the deal and we came in, we made private people's public relatively fast. That was a fast one.

Yeah, sorry. That's true. At that universe, and in 2018, the first version of GitHub actions was announced. That was even for the deal close, but it was, you know, hopefully the folks building and forgive me was built of a hack built on top of containers in Google Cloud. And we quickly saw from the data that the product wasn't actually needing the requirements from developers.

Many developers wanted full CICD, but GitHub actions are actually designed to be offline automation. And we kept that for automation part, but evolved it into what it is now in the course of 2019. 2020 sponsors was announced in mid-2019 at the last ever satellite conference in Berlin. And then COVID came in that wound to kind of like the pads that we had as we came back from it. You know, we were very careful with being back universe in a smaller scale and given that there was still lots of travel restrictions.

But it took us a while, you know, to get the organization back into a state where we could both innovate really fast and, you know, keep the fundamentals in place. Keep security, availability, you know, other things, accessibility, things that you might not actually see have changed, because, you know, everything is working. You don't notice it, but, you know, create a lot of investment behind the scenes. So we are feeling good about the pace of innovation that we have today, but yeah, it took us a while to turn the ship around, you know, even in a team of seven people that takes a while and certainly about 3,000 people, that it is something that, you know, requires a lot of energy and focus. I think it's just a good reminder from the outside, a company that is doing great.

Because GitHub, I think all developers can agree from the outside it looked like is doing really good. Like, yeah, you can have some things that you need to work through, right? Like, and growing too fast is amazing. I think the best problem for any team to have, but it's still a problem, right? That you need to solve and you get through it.

Now, co-pilot was the biggest flash that I can remember from the past few years, clearly, especially because when it came out, it just felt so early. Was it, did the beta come out in 2022? 21? 21, yes. Did it come out in 2021?

Beta came out in 2021 because it was built on an earlier model before Chad GPT launch. It was on, was it on GPT 2? No, it was, GPT 3 was the, so GPT 3 came out at the, right after the book conference in 2020, which was obviously given, given the pandemic, fully remote. But Kevin Scott and some augmented session about transformers and Dutch language models. And then after that, GPT 3 got into the preview and we got access to that and put the OpenAI Microsoft partnership and we realized together with OpenAI that it was able to, to like, decent code in different programming languages and would not mix up the syntax between Python, Ruby and JavaScript, which somebody asked me that earlier this week was my biggest surprise that it can do that, even though it doesn't have a compiler built in, right?

Like, it's not able to validate the code it generates and it doesn't have the syntax that just knows it from the, the training set. And then OpenAI fine-tuned a model that was called codecs that was specific for these coding scenarios. And in 2020, in August, we wrote a paper with three ideas we had, a text to code, code to text, and describing code. And conversational coding is what we call it, which then, you know, today is known as chat. And those two layers of scenarios didn't work well enough.

We had a describe code and sometimes it worked and oftentimes it was wrong, you know, how it is. And even if I see that, that description is not actually what the code does, you quickly, you know, detract and you get a little, a little, a little, a little bit more score or whatever, you're measuring satisfaction. But, but text to code as a, you know, pumping the model within the editor and ultimately building all the completion that worked so well that very quickly we saw our internal, you know, how about adopting the tool, giving it really high scores saying, you know, this is great. I want to keep using this. It's not the typical management says you have to use it and you don't want to, but ultimately writing, you know, in the early days, 25% of the code in those files, it wasn't able to then shortly after that number got into the 50% range or 46%, I think early 2020.

And so that was the early days of Copilot in 2021. We went into the public preview and within, you know, a few months, at the beta, second, I told my users, we saw more and more folks on social media saying, well, I was skeptical that this could ever work, but it actually is good enough that I don't want to work without it anymore. Yeah, because the surprising thing for me is every, most of us remember the launch of chat GPT in November 2022 and everything exploded from there. It was the product that made people go, wow, inside tech, outside tech, a lot of AI startups start up and a lot of actually coding startups started after that. So like in early 2020, however, by that time, get, get off Copilot was already.

Yeah, I think I think it was beat on 2021 right there, but it's 2022. I think it became public. So it was GA already? It was generally available. Yeah.

Generally available in June 2022, which I was charging for, for individuals in August 2022 and then chat GPT actually had two moments, but one of them was not noticed by many so opening eyes showed at Microsoft Ignite conference, which is the fall event showed actually chat GPT in the keynote. It wasn't called, they showed like a similar scenario that is what you see now, the agent doing where you ask it to the Wacom code and make modifications like code and then it launched in late November. And the world changed for us dramatically. For once, because we had a product and market that was really good for developers. And so our customer conversations shifted from us having to convince customers that AI is actually something that should look into to customers asking us to come talk about how we build Copilot, how it can help developers, the first user studies come in, the first one, the first company comparing a group without Copilot with a group with Copilot.

And the 5% number is obviously both well known and often used today as a productivity improvement, which was never intended to be. It was a case study in that month scenario. It made the developers 35% faster. That's the other things that developers do day in and day out, where you don't get the Copilot to make you that much faster. But it was a very exciting time.

And then in 2023, we launched GPT4, bought it into the CLI, voice came out, right? It's a lot of these things feel like they happen forever, but it's only been a little bit over two years. It's only been a little bit, and then 2023 on a post from GitHub, and I should say it was you, so I don't want to miss out. But it was written that just as GitHub was found on Git today, we are re- Sorry, so it was you writing it that just as GitHub was found on Git today, we are re-founded on Copilot. This was in 2023 and Copilot was clearly very strong.

What has this changed meant since then, and that was in two years. This was at GitHub universe at 2023, so in that year, the conference was in early November. It is our biggest event of the year, and it was one of the lines in the keynote, and I think in the press release of Black Post. And we talked a lot about the early days of GitHub, right? The GitHub founders did not invent Git, Linux, it's a tall out state.

But they realized there's a new technology that changes how developers work, not only to version the code, but how they collaborate. GitHub, if you think about GitHub, is designed for asynchronous collaboration of developers. That is what GitHub is really all about. And with Copilot, it repeated history because we didn't invent transformers, we didn't invent language models, we didn't train GPD two or three or Kubernetes, but we saw something that changes how developers work. And if you're honest, we saw an opportunity for ourselves to accelerate.

My back-top is endless. There's lots of GitHub issues in repositories that were filed, whether the issue was filed in 2014 with customer feedback and every enterprise seller since then, we took a closer time to run it. I have the same problem and it's not like we don't want to get to that issue, but it's like there's also a thousand other things that are also high priority. And you mentioned security issues and availability and all these things are also high priority. When we saw GPD and then code X, we saw an opportunity to bring the effort down for all the developers and of course every developer on the planet to get more done.

Not that they actually get to an anti-backload because I don't believe that because Java's paradox means more ideas will get stuck. In fact, now we have all the AI ideas. If you will now GitHub and Microsoft are closer together from the sense that Microsoft's developer division has for over 25 years, produce IDEs and Copilot started as an IDE feature. And my GitHub was the developer platform. Now, those are the Venn diagram of GitHub and VS Code and NVS is much more well-lapping and we see that here at the conference and we see that in order to get an action between GitHub and Dev Dev.

And just on build, two big announcements related to GitHub. One is open sourcing with Copilot extension. Why did you decide to do that? And also, what's the idea here? Because we have seen open sourcing with VS Code.

In fact, open source and VS Code gave way to some of the competing editors that are also adopted in Windsor, of cursor. I think there's a smaller one as well. What is your hope with this move? And why? It feels counterintuitive because Copilot has been an edge for Microsoft, right?

Isn't it funny that it's counterintuitive? Now, Microsoft is embracing open source and is open sourcing it's part while startups are taking open source for P&L and making a closed source. This is like if you had told me that. Interesting. Yes, you have it backwards.

It's just a really close or not open source. That's not, you know, and look, you know, that's the VE published VS Code in 2015 under the M.I.C. license. So the license allows it and of course people can do with VS Code code base what they want. That's their game.

So stepping into our footsteps, into our own footsteps, footsteps of years code over the last 10 years and we felt the time is right to bring the Copilot extension into the main editor code base and that means it needs to be open source because we made a promise to the community when we published VS Code that we will keep it open source. You mentioned Copilot in 2021, 2021, 2021, too. It didn't take long until people reverse engineered VS Code extension at the end of the JavaScript. We're writing in the TypeScript but it's delivered as a JavaScript. And so you can find those blog posts of how we compose the prompt along the prompt.

You know, this is not that we're using adjacent tabs. All that information is already out there but you couldn't take that information and contribute back or, you know, look at the code base, learn from it or take, you know, Copilot and its APIs and the system prompt and put that into, let's say, code.org or, you know, the interview tool you're building because you want your applicants to use a Copilot and maybe even show how they can sign in with GitHub at the same time and not give them the full experience you want that, you know, scope experience for an interview. So I think from our perspective it follows exactly the idea of open source which you can learn from it. You can contribute to it. You can do whatever you want with it.

It ultimately helps the developer community to have that piece of kind code available. And you know, now you're going to ask, or I'm going to ask myself the question, so we ask the value generated and aren't we losing all the revenue. And we believe that the ultimate value generation for these AI tools is in the platform. Whether it's the computer inference layer, whether it's the security or control layer or enterprise is one control of what model is enabled, who can use AI, you know, in which project you might use AI given that you might have signed, you know, legal terms with whoever polite to source put that you aren't using technology and inference layer, the security layer and the collaboration layer where people collaborate and you see that with human to human collaboration.

And we were going to see that with human to Asian collaboration with our new coding agent, bringing that agent into the platform and beginning at certain permissions and protecting the agent from doing things that you might, you know, allowed for human but you wouldn't control what that agent does it. I do like looking back at history of Microsoft. I do appreciate that Microsoft has been open always to the idea of being a platform, but a good platform. So for example, JetBrains, you know, they might disagree with this. But I remember the first time I bought JetBrains project for $200 a year was this extension called Resharper.

Yeah. So Microsoft opened up their ID to allow extension points and JetBrains honestly were way better autocomplete than Microsoft themselves have. And they made a bunch of money off of it. And I think this helped us to spend all these things. But when I look at, let's say, Apple's Xcode, the reason I don't like it and I'm very vocal about it, there is no extensions.

I'm stuck with what it is. I would sometimes pay money for someone I cannot. So I just really like how Microsoft seems to be keeping this idea of like sometimes opening up the business so other skin succeeds, startups can do it. It's better for everyone, especially as developers. And as you mentioned, we actually have a co-pilot extension for Xcode.

It's a bit of, you know, a hacker. Given the limitations. But it does have all the completion of the test chat and just the speakers we ship agent mode as a preview into the Xcode extension. We have it in the JetBrains extension as well. It costs them all the different different settings at ease.

We even bring it to Eclipse and then that is something you know, including agent mode. Because if you look into, you know, larger companies, they have developers on all of these. And probably, you know, none of that other developers prefer one where the company doesn't want to prescribe which I need to use. But it is important for companies to standardize their engine system stack and to have certain proof tools, maybe it's just maybe it's multiple of those. Obviously, if you think about it, for example, Artifactory or JFARC often companies have that in the stack together with GitHub or HashiCorp Terraform and of course, you have a cloud and a key secret store and a key value store and all that.

But it is important to have a couple of available costs all these IEs. And our export extension is already open source. What's open source before this week? Because an open source maintainer avoided. And then we did a commercial agreement with that open source maintainer.

Of course. To take it over, right? So we, you know, the maintainer benefit from it, we benefit from it. But so that means the system from the APIs or that you can already find an export extension. And so now we're continuing the journey with your code and others.

The last question I wanted to touch on. This is agent, agent mode or GitHub agents was also an announcement that the agents are getting more and more autonomous now. As developers, there is a bit of this fear. There's some not necessarily Microsoft, but there's this vision of in the future, the software engineer, you will manage all these agents and you'll be more of a manager than a software engineer. And there's two things.

They're a fear of like, are they taking away the parts of the work that I like? Even if not my job, I'll have a job, but it just seems like a boring job to be manager. And then the other thing is what could happen with software engineering job? And then you said earlier that you believe this will increase actually just recently in public. So what is your view on agents and what advice would you give to software engineers who want to say software engineers, but obviously want to up level?

Like how should we look at this thing? Because it feels like a frigging change. Because I think autonomous at least in minus, that means the thing figures out itself, what it should work on. That's not how these things work. They have a level of autonomy.

Then you assign a task to them or how they're putting the task. Or even that autonomy is restricted by the MCP service, a model context protocol, that you can figure out for it or the tools you allow it to use or the repository you give it access to, because obviously it's an engineer. It's a human engineer. I can look beyond the one in the repository, found only and see what has been happening in other repositories, but the agent needs to get permission to do that. Right?

So it's definitely far away from full-service driving. If you take cars as a metaphor here, we're certainly getting into more drive assistance systems. As developers, we have always automated what we can automate. A compiler is a tool that helps me to not buy the assembler, so I can write a much nicer language. I'm sure when compilers and languages like basic and others, they're also skeptics saying, I'm losing control over the instructions that I can do in my app is much faster.

I certainly remember my Commodore 64 days when there was a very active demo scene and you couldn't really have a successful demo, especially as this was limited. But then, for physical limitations, today it's artificial. You're limiting it because it could only win those demo challenges if you knew how to do assembler and you couldn't win that. So agents will work as one of the tools that developers have available. It's just like we have compilers, linkers, linters and whatnot.

They will pick up tasks that I don't want to do, like writing test cases. I don't know many developers that want to buy test cases. And certainly not more than they already would. Like testing is always a how many do I write until I can get away with it when I go into code with you. Because there isn't a right answer, it doesn't end up good.

It's like how many you need is actually very subjective thing. And those have tried to holistically test all the edge cases that are shipping actual valuable software, finding documentation, fixing security vulnerabilities, finding security vulnerabilities. I didn't see them because I had a long day and I have obviously always my own bias that, you know, the code that I'm writing, that's exactly what I wanted to be until you have even something simple, like a pull request description, right? Like you have the AI, just why the work that you have done and all of a sudden it shows, Thomas spoke to behavior, it won't say like that, but like you know, you get the idea, Thomas changed the behavior of the checkout flow. And I didn't touch the checkout flow by it, but it's no change, right?

Because the benefit describes the code changes. It does have the confirmation bias that you self-have and you would like your own description. So I think we're heading into that world. And now we have these, let's say I start for agents roles. I think that's what Jessica did in the keynote.

And well, but also we have all this code generated by all these agents. I'm the one now having to validate that what the agent is actually the thing that I'm willing to merge into my codebase. And we all know that this gets harder the more open pull requests you have in different branches that might have merged conflicts by the time you're merging those things. So you've got to understand all that code. You've got to understand all the systems designed.

You need to know what the agent did to be, have the level of confidence. Trust, we talked about security, ability, all these things earlier. Sale. At the end of the day, most companies are for-profit organizations, even those that are on-profit, operating on the budget. And so you need the agent to write code that solves the business problem and still makes you a healthy margin.

It sounds like keeping an open mind and experiment and see how they can help you, right? The other thing that is super important to this is that we're already seeing this paradox because now we have all the AI requirements that come on top of a full-second engineers. Right? So long as it's back in the database infrastructure and front end and how they're coming to the backend and GitHub to give you one last data point is we are seeing 120,000 APIs. So we're seeing 120,000 APIs per second on an average day.

Oh, wow. That's 7 per minute. That's 430 million per hour or 10 billion per day. Right? That's API requests.

And now that doesn't say is it a cheap API, like, you know, listing the first 10 leaders that you have or is it a GraphQL API that can take, you know, lots of complex queries to actually another result, right? And so if you just take that example, like you've got to have engineering skills, you've got to have developed the craft. You need senior people that know how to build large-scale systems. You need people that take large complex problems, take them down to small-powers. Maybe they use AI along the way and say, what's a good, you know, no secure database, what's a good data that doesn't see how to do a good GTBR.

That job is going to be to break it down to the layer. But then now, no, now I can sign into the agent that will provide high quality code without me having to repel them 15 times and then I can move to the next task. That's what engineering is all about. The coding skill will be part of that engineering skill set, but ultimately engineering means I can build a really large complex system and then evolve it and need to even larger system, you know, next week and today's report. A lot of the stickway of abstractions and being able to take on more complexity.

This is a really good conversation. Yeah, awesome. Really great to meet you, Greg and Preston and looking forward to saying that. Thanks very much, Thomas, for this conversation. The thing that's struggling most is how despite GitHub building AI tools like Copilot, Thomas, it's very strong and believes that there's a lot of value in hiring junior engineers.

And he thinks that the future of software engineering will not be about autonomous AI agents, but software engineers directing AI agents on what kind of work to do and staying in charge of this work. For more practical reading and listening to AI engineering, check out DeepDive's Traumatic Engineer, linked in the show notes below. If you enjoyed the show, it would be a lot if you loved the reading on the show on your podcast player.