## Intro [00:00] TV came out 21. Yeah. So, GPD3 came out right after the build conference in 2020. Kevin Scott and Sam Alman did a session about transformers and Dutch language models. And then after that, GP3 got into the preview and we got access to that and through the OpenAI Microsoft partnership and we realized together with OpenAI that it was able to write decent code in different programming languages and wouldn't not mix up the syntax between Python, OB and JavaScript. And then OpenAI fine-tuned a model that was called Codex that was specific for these coding scenarios. And so in 2020 in August we wrote a paper with three ideas. We had text to code code to text as in describing code and conversational coding is what we called it which then today is known as chat. And those two letter scenarios didn't work well enough. But text to code as it prompting the model within the editor and ultimately building autocomp 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 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 in the early days 25% of the code in those files it was enabled and then shortly thereafter that number got into the 50% range or 46% I think early 2023 and so that was the early days of copilot and then June 2021 we went into the public preview and within a few months this had grown to a million users and you 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. GitHub recently turned 17 years old, but how did it start and how did the platform evolve? I sat down with GitHub CEO Thomas Dunca, who has been a GitHub user for 16 years, has been working at GitHub for 7 years, and has been the CEO of the company for the last 4 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 stopped shipping features between 2015 and 2020 and how they created GitHub copilot in 2021. GitHub's interesting internal tools in the early days like hastack, GitHub TV, and Hul. How GitHub sees about 10 billion API requests per day. That's about 120,000 per second. and why Thomas doesn't believe that autonomous 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 enjoy 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 in person after ## GitHub’s modern tech stack [02:25] exchanging emails and putting a name to the face and reading your newsletter every week. Yeah, twice a week, I guess. 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 know 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 was in the early days also Ruby. 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 um with about um 700 uh engineers in the within the company contributing to it, you know, at different times of of the year. Not all of them are working constantly in the monolith. um we actually just passed um two million git commits into the monolith and you know tens of thousands of of pull requests and um but we also have moved um uh beyond just just that one architecture. Um so for example we're using more and more react uh on the front end. Uh we have a number of you know services that outside the monolith. Um for example the copilot API is written in go given it needs you know lots of API calls for inference. The G actions uh sits on a completely different tech stack. um kind of actions. Um I I would imagine Rails might not be the best for a very heavy workflow. And it has a it has actually a um history um because uh a large part of the action stack um came from what was back then Visual Studio Team Services and then became Azure DevOps and so Azure pipelines um and so there was a lot of net code uh in that code base and and over time we are now evolving that into into a more more modern architecture with the goal of you know one of your other posts of getting to 49s and beyond and so our text is is very diverse today obviously we're doing also swift um for iPhone app we have cotlin for Android app um we using you know all the clouds um u beyond um also having our own uh metal in uh commercial data centers and we like a modern um modern software company with all the complexity and all the challenges that 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 we mentioned that it feels like it's less about the technology itself but what you're building on it and you know your history of it and then I mean we can spend a whole hour probably just talking about the benefits of having a mono monor repo with a monolith versus you know hundreds of microservices. Um you know when GitHub was uh in 2007 was founded for I think more than a year it was only the three original founders um Chris PJ and and Tom plus the Scott um who's now the uh founder of Git Butler and um Scott Sha who's kind of like the first employee but was often seen as as the fourth founder and so you know a team of four is way better off of working in a single codebase. Uh you can move much faster. I think that was always um uh important for GitHub to be able to move really fast and and ship new features and it's much easier to you know get to learn the codebase and and try to understand the dependencies. Uh as as the company scales and the product scales uh it it makes more sense to move away from that architecture. I I'm I'm so glad you're 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 trade-offs. 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, Statig. Static is a unified platform for flags, analytics, experiments, and more. Combining five plus products into a single platform with a unified set of data. Here's how it works. First, Static helps you ship a feature with a feature flag or config. Then it measures how it's working from alerts and errors to replays of people using that feature to measurement of topline 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, Static is incredibly affordable with a super generous free tier, a starter program with $50,000 of free credits, and custom plans to help you consolidate your existing spend on flags, analytics, or AB testing tools. To get started, go to stats.com/pragmatic. That is satsig.com/pragmatic. Happy building. This episode is 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 sync for engineering teams. Most developers spend about a day per week or more reviewing code or blocked waiting for a review. It doesn't have to be this way. Graphite brings stack pull requests, the workflow at the heart of the best-in-class internal code review tools at companies like Meta and Google to every solver company on GitHub. Graphite also leverages high signal codebased aware AI to give developers immediate actionable feedback on their poll requests, allowing teams to cut down on review cycles. Tens of thousands of developers at top companies like Asana, Ramp, Tecton, and Verscell 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/pragmatic. That is g for graphite t for techchnology.dev/pragmatic. Now you mentioned something really interesting which I also heard that you run your own data centers or ## From cloud-first to hybrid: How GitHub handles infrastructure [08:11] historically have run your own data centers but I talked with some current GitHub folks and they said that you in in some parts still do. So why did you do this? uh how is it changing and and are you obviously since you're now part of Microsoft as well does it make sense to use some parts of Azure and and if so what parts are using and you also mentioned other cloud so like how are you thinking of own data center which again we used to say oh it's just move to the cloud and there's there's own opposite thinking as well what's your take on this get up you know started on uh on the on the cloud um really early days it was um to my memory uh it was engineered uh as a platform as a service provider and then AWS Yes. Um behind the scenes and okay, you know it's it's easy to forget in today's world where lots of startups announce huge funding rounds, GitHub had no funding until um I think 5 years into its journey um when the back then unheard of 100 million uh came came from around led by Andre Howitz. But until that point in time, GitHub was bootstrapped and it had very fast adoption. you know when um when it launched in April 2008 very quickly uh the number of users number of both public and private repositories uh kept kept growing you can still find you know people um talking about that they're begging the founders to introduce a paid tier so they have the confidence that the company can be will be around and and so it was a natural business decision um for the founders to say how can we host this with more optimized cost um given that we are bootstrapping this and we're having to pay for the service uh from our own uh revenue stream and we they couldn't be burning money because they had you know they had no money um from from venture capitalists and so I think that was part of daring the decision. The other one is you know storing git data um what we call today our git systems uh team uh uh in file storage in itself is probably not like the best use case for cloud cloudives that existed you know in 2008 2009 uh where you had limited access um to to that layer and where you know especially the networking part of having multiple you know nodes um communicating with each other was much more complex than it is today and so the decision was made to move to servers in commercial data center. So we own the servers. We still own you know the servers and the racks and and the storage and all that. But the data center is a commercial data center. So we don't own the data center. So it's own in the sense of I'm making air quotes for listeners is own in the sense of we managed you know the servers in those data centers. Now today's GitHub still is a lot of that. the core is in in these uh own data centers but things like GitHub actions, GitHub code spaces, GitHub copilot uh uh run on on Azure in the cloud and leverage the scale that you naturally need whether it's you know CPUs and actions um or GPUs uh in copilot of course copilot given it's multimodel choice and has anic models and openi models and gemini models not all of these models are on Azure so naturally we're also working um often with both you know the first party API um aka API that OpenAI or Anthropic provide and you know other clouds that um that have Vertex Bedrock and so on and we in fact now have GitHub um fully hosted on Azure for data residencies. If you as an enterprise uh customer in Europe want your data all stored in Europe, you're getting a big deal. You're getting a GitHub organization on a stamp that fully runs on Azure in the Netherlands and in Sweden. Uh I mean we have the same for Australia have just announced a US stem that will be fed compliant and we're going to expand into into more regions in in the years to come. Yeah. I feel these are the like really kind of boring things but they're they start to become really important when you are at a company that you know is now starting to care about these things. Well and they're not boring from an perspective. Well, not not not boring, but like it's it's the thing that I think as a from outside, you know, it's it's not the shiny features, but I agree an engineering perspective that actually sounds pretty challenging. The the challenge, you know, if you go back to the rub on rails conversation is and if you know a little bit about rails and how um and we not only run on rails, we also run on my SQL and so whenever you change, you know, the schema of a database table, a so-called migration is run. Um how do you do that? that if you not only have one stamp uh in one region, but you actually have you know five or 10 stamps and you deploy um you know hundreds of times per day in fact um I think this year we're forecasting 12 million deploys um across the about a thousand or so IC engineers that that we have in the company and so how do you do that how do you deploy how do you go from one you know central stamp uh on our US uh data center cloud if you will to having you know deployment that goes to all these different stamps and run the migrations and if you need to are able to hold back. So that was a lot of the engineering work that went into that. Um less so I'd say um the actual work of moving this to Azure was was less work than getting the engineering system the DX the developer experience actually aligned with this now we are running in multiple in multiple regions. Yeah. One interesting thing that I always surprise people who don't know ## How GitHub’s remote-first culture shapes its operations [13:08] GitHub all that well is people think well it's now Microsoft right? So it it must work the same way as Microsoft and then you know one like fact that shows this is not 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 co truly remote first and as I understand even today it's remote first. Tell me about this on a h how you managed to keep this how it's working inside a larger company which you know 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 pre prefounders they actually met in San Francisco. So you could argue that very very early phase was was kind of like three people in a in a same place and that's often I guess that helps how that how that goes. Um but yeah very quickly GitHub started hiring uh super fans you know people that were interested in GitHub promoting GitHub you know helped to drive in the community those people got hired uh into GitHub and they were naturally everywhere in the world and so very quickly GitHub moved from a culture that was headquarterentric to a remote first culture and um that you know gave us an advantage when uh the pandemic came uh because we were already used on uh on being on video calls on using Slack Um, 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 uh employee. When I wake up in the morning, on the GitHub side, I have lots of Slack messages, DMs, channels to to look at into maybe, you know, a handful of of customer emails or or emails from you that cannot communicate with me in Slack. On the Microsoft side, it's the other way around. have like dozens of of emails to pay attention to and maybe you know a few a few teams messages and so I think that shows the async part of our culture that has grown over the last um uh 17 years and that is so important. At GitHub uh we are using GitHub for everything and so all employees across all the functions not just engineering and product but HR and coms and finance all the functions work on GitHub and so they have repositories to describe their team. You know they're using pull requests to to make changes for example to our terms of service. Um you know every company write announcement is a pull request against the repository that we call the hub that gets published as a GitHub pages page. uh that is only internally accessible and that goes through our identity provider and so even there we don't do um companywide emails um almost never uh we do an announcement on the hub and there's a link that is posted in a slack channel but then we can everybody can see and then we take the conversation there so yeah today we are uh a very much remote first company um with people all around the world in different time zones um almost everything is async um obviously there's you know meetings and our town hall meeting is called the git together and So that has to be in some you know time zone and challenge there is that if you do it you know uh adjusting it for the folks in the US, North America and uh and Europe you you're missing out those in Australia and India because that's just impossible to meet. So we try, you know, different times of a year to have one that is in the apac friendly time zone and you know a few that are European friendly often, you know, it's not the way when you do like 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 your kids from school and go go and have family dinner. So many of them actually prefer a later point on the day on the West Coast. So is 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 um you know in different places um in different uh phases of their life and and I think that helps us as a company you know to be um as agile as possible. Yeah, it is pretty cool to hear because GitHub I mean you can use GitHub in many ways but like one one popular way to use it at this 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 async and they're not all in the same place that would never work if an open source project could only you know uh you could only be a contributor if you're in the same place and all the same time zone and so given that we're catering to both you know commercial customers startups enterprises uh those that are paying us money for GitHub enterprise and copile business but we're also catering serving ing the open source um economy, the open source ecosystem and as such as a company even though you know the GitHub core itself was never open source and we're operating pretty much like an open source project. One fun fact I've I've heard is you have some really kind of fun and interesting internal tools. Some some are still here, some are not. One tool that I understand is no longer there was called Haststack, which was an internal exception tracking app and ## Former and current internal tools including Haystack [18:00] someone told me it was the best piece of software they've seen. Can can you share a little bit about like what past fun in internal tools you have and what kind of internal tools you still have today especially for like what engineers use? If you look back into GitHub's history and um we don't have the time to cover it all today. I can I can recommend if I if I'm allowed to another podcast the acquired podcast um they had an episode on June 5th 2018. So the day after the acquisition announcement that covers a lot of the history of GitHub in the early days and uh in general a really good podcast um and and and they actually mentioned this that in GitHub you know when it started had a very you know non-traditional way of operating there were no managers everybody was encouraged to work on their passion projects and as such GitHub you know for many years didn't have a traditional IT uh uh infrastructure in the company and so everybody was built in house because there was the belief you know we can build we as GitHub can do it better than a tool that we can buy off the shelf. We maybe we come back to this later when we talk about AI that future might actually come back to to some startups. So we had a tool uh we had our own internal video streaming platform it was called githuba.tv TV and so all the you know town halls um and so on you know streamed on our own platform and of course that no longer exists and we're using Loom using Loom for that haste you already mentioned that was exception tracking and know keep in mind 15 years ago there wasn't like established players in that market that you could use especially not in the in the Ruby Railsburg so haste one was one such tool today it's sentry that we're using for that another one was Help Halp which was our internal support system where tickets got routed um uh for folks to work on the ticket have internal comput teams and yeah and now this is all in zenesk and and help has been retired but you know some of these ideas have led to new startups right where hubbas have hubbas is what we call employees where hubbas have taken the idea and maybe they were a bit frustrated that we're shutting down the their internal passion project have taken that and and and creat um I think you know culturally we are still encouraging folks pretty much to experiment and to incubate new ideas but we're trying to make those external facing products and there's a number of examples from GitHub history as well there electron comes to mind which came out of Adam which was was our editor um oh yes um you know our desktop app or comment line interface those are all open source projects and so everybody can see what we're doing there and can take the ideas and you know we mentioned stack text earlier the CLI for example is with mang go um and so it's also gives a you know whoever wants to learn how to build a CLI can use the GitHub 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 it for them. And a very famous one was in 2022. Heroku had a security incident and it started by not Heroku noticing that something leaked but the but GitHub itself noticed some strange patterns. ## GitHub’s approach to security [21:12] They contacted the Heroku security team who then confirmed it. And this just struck me a little bit striking like hold on like uh how is GitHub having better or very strong security? I'm not going to say better but in in in some ways in this case clearly they got earlier. What is your approach to security? And and this was again this was not even right now. This was years back. It it it just suggests to me like you probably think about security a little bit differently than maybe some other companies. Security is part of our culture. We have this saying security as priority zebo for for everybody. And in fact our previous uh siso Mike Handley introduced this concept um he came from Duo uh the two-factor authentication company. he introduced this concept that when the question is asked who here is on the security team every hub raises their hand and so we institutionalized that security is is part of what we do of course we want to drive innovation I'm going to make customers happy but we cannot win in the market if we lose the trust and of course the worst day you know uh in my life would be that I get a call and say I lost you know the private repositories we lost you know as a platform so it's so important to companies your code to an attacker and um and now have to do the damage control and so it's really important for us the CSO and the chief security officer reports directly to me and we have a team of about 150 or so boys that take care of security from from multiple angles. one is of of cost threat intelligence um working closely with the Microsoft security team uh the so-called cyber defense operations center uh and those folks that look into uh you know finding security vulnerabilities um that teaming uh not only for you know the traditional software they're building but also for 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 threat intelligence when you combine all that intelligence you get a lot of signal and one such example is a very trivial example is that if you have a person if you for example you know you your user ID accesses not only the pragmatic engineer repositories but also those of let's say BMW and Mercedes that person is very unlikely to exist in in the industry right like even if if you're working for like a systems integrator then you typically don't work on a BMW and a Mercedes project together so there's a lot of intelligence that we can collect by having the holistic view even more so when when you combine it with all the other Microsoft systems. And we also have a security lab um where we have a team of research that's uh that are hunting for security vulnerabilities using our own security products uh like CodeQL which is query language um that you can use to find variances um like variations of existing code flaws you know code vulnerabilities tries to find those in open source projects and then reports them to the open source maintainer in a responsible way helping them to fix those in the time of thelo disclosure hopefully uh you know the bug is already fixed And so we doing a lot of that. We're investing into a lot of that. But of course, you know, nobody is perfect. And so it's really crucial for us as a company to have this ingrained into our culture to not have secrets and source code. In fact, you're blocking all the pushes and Exactly. I guess I guess open source might help here. Your your big focus on open source, but you mentioned 150 people working on on security as context. How how many people are ## The current size of GitHub, including security and engineering teams [24:30] engineers are in GitHub roughly these days? Yeah. So GitHub all up is about 3,000 uh uh employees. um about half or so are in what I would call engineering product design or EPD. Um so that's that's about 10%. If I just look at the security roughly engineering function and then you look at just um engineers IC engineers it's a little bit under a thousand um that work and build software and then it's of course managers and product managers and technical program managers, designers and all that. One interesting thing I've heard from a current get employee is you are starting ## GitHub’s intern program, and why they are hiring junior engineers [25:03] to look into hiring junior developers developers with less experienced which is a little bit different because most of the industry does we don't hear this. Yeah. Why are you deciding on this and like you know this is just a really positive thing to hear. I'd love to hear more about your thinking. We're really excited about working with young people. You saw some of those um uh on the in the second day keynote yesterday as well. And in fact you know just on Monday um our intern class for this for the summer started. We have three groups that start on different days and go through the internship. So those are the very early in career folks um that often oh not not often that still go to to college or university and um this is a program that we um institutionalized um after after the pandemic was over and you could bring people back in person because obviously or to half in person where they at least have you know a way you know to to meet with folks um um at our San Francisco headquarters or here in the Pacific Northwest or or elsewhere in the world and so we have an intern program and often uh you know these interns get a full-time offer at the end of the internship or maybe they come back for a second year. Uh and so it's a lovely to see uh that you know those folks that bring fresh ideas um a great amount of energy you know the the latest learnings uh from coalition university um and often you know a different uh you know diverse background uh into into the company and and and you know come in and and often you know the the folks you know that are younger in in Korea uh bring bring a new perspective to the team and say hey this is you know why why don't we try this or I want to incubate this idea Yeah. Um, and so we are very excited about having this kind of like both junior and and senior population in the company. And it's not only true in engineering, you know, it's the same in if you look in into sales or into marketing. Obviously, the way, you know, marketing works today, uh, is very different, um, than it was, you know, 5 10 years ago when the press, you know, traditional media played a much bigger role. uh today uh you got to be you know in a podcast and and you have to be on on YouTube and Tik Tok and just like today just like today but yeah you you know that that you see more and more of that happening and of course you know the when you when you hire people earlier in Korea they give you those ideas they give you that input and you know how it is you you talk to a lot people in companies there's always a debate um there's always a debate between those um that are defending how we've always done it uh in a 50-year-old company like Microsoft that obviously exists and and those that come in and say, "Hey, you know, nobody in my peer group, you know, watches TV anymore and or CNBC or whatever." Uh, and they're all watching just, you know, 3 minute videos on on TikTok. Um, and so I think that's really important and and we're trying to have, you know, a nice balance between early career engineers, senior engineers. We have, you know, a number of distinguished engineers and they all contribute back to to our platform. No, I I I love it cuz like when when I when I worked both as an engineering manager or as an engineer, having an intern, it just like boosted morale. Like we were so much more enthusiastic. I'm not going to say that we necessarily did more work. I think we 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 now principal engineers, some are CTO's. But the one question that a lot of people who are maybe less technical than you and have not seen the benefit of internships, they're thinking like, "Oh, I'm hearing all these AI things, including Microsoft, is saying ## Why AI isn’t a replacement for junior engineers [28:27] it's so efficient, you know, now they're now talking about AI colleagues on on the keynote. Why?" And and and now this is non-Microsoft people, but we're hearing people at Google say like, "Oh, it's now at a level of a junior engineer." uh 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 at the level of junior engineers, so maybe we don't need junior engineers. What would you suggest to people who are in this thinking and may maybe not as informed because clearly you you've decided it makes sense and you know this this thing doesn't apply, but their thinking is 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 or even you know kids earlier in in their education they get to use AI much faster and they they get it because they are you know taking this with an open mind. They they don't have to this is how we always done it. This you know don't touch never touch a running system. They haven't been in an experience where some change that was applied you know from from upper management or or from the engineers themselves has led to you know a big outage and things like that. So they're more open-minded. you you know you kind of see that when you look at media as as we already talked about like kids are much more uh open to just scrolling through shorts um and and and consuming the content they'd like to consume while you know when you and I were a child we had linear TV and you got to watch on the living room TV what your mom and dad decided is is on on tonight right and so they have much more freedom and I think this will lead to to ultimately um junior engineers coming or or interns coming into the companies and bringing 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 third my second or third internship or might have already been coding with you know a group of students on on my own project on my own app so you get a lot of good new ideas and outside perspective that is ultimately crucial uh to compete in the market and I think vice versa you know these interns then go back into college and they have worked on something real I I remember my time at university I always had the feeling I got to get out into industry and learn how it's actually done because while you know there's you learn 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 codebase becoming an engineer in a company means you're working on somebody else's code um often now you know GitHub 17 years old code uh and you have to follow up on decisions other other people made and that's not how you learn coding in in a university and so I think it's both for us important to have those fresh ideas within the company, but also for us important to to give back uh to to those that in the future become GitHub customers. I I love it and I feel it's also just a very it's the cheapest way to do it just like it, you know, you're not going to have the highest salary for the the new people. This is a silly way to think about it, but I talked with the product manager recently and I I just like had a deja vu when when you said it, this product manager was saying she 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, she's like, for years as a product manager, I'm sitting in front of engineers telling them, oh, you know, get 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 new 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. Here's And she's like, I love it. Like they So, I I I want I wonder if like by hiring these people and actually just ignoring, as you say, the backward thinking, you might get the next generation of of software engineers. Gen Z is already too old I think to some degree because Gen Z I think starts 1980 or something like that the millennials Gen Alpha right like the 60 years old are coding today and so that's Gen Alpha or you know soon the whatever the gen beta I guess is the next one and so but you're right you know you're you're getting folks that didn't learn to code on a on a on a Commodore 64 on a PC that you know have have a lot of low-level thinking but also you know learned in in a different in a different environment than those you know that cool with with smartphones that grew up with being always connected. They just have just from an expectation perspective, they they're looking at this often systems problem they're trying to solve with a different with a different perspective. Yeah. I I wonder just like 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 same years old? you learned in university and did some university projects or this engineer or this this this fresh grad who did a university but they actually have before that five years of building programs and roadblocks and they actually built this like 100 person thing is like the skills that that person brings and the the mindset you know the way they think about things and there's a third group and and there's lots of folks you know at Microsoft and GitHub that don't have a formal uh university education and either dropped out or another event right that's that goes back to the earlier discussion about um being an an 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 uh because they have shown they contributed back to the Ruby on Rails codebase to the to the Git, you know, open source codebase where you know at GitHub we traditionally have employed folks that are spending a lot of time on maintaining git together with the open source community. So I think a lot you know uh what actually plays a role to us is that folks have shown the right mindset uh to join GitHub they if they if you don't have a green contribution graph on your GitHub profile um that I think matters more to us than whether you have five years at one company and five other 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 um there's nothing wrong about that from my perspective in fact I would say if you want to you know get a up in a tech company. Very soon, you're going to be asked to show your your prompting skills, your your co-pilot skills, if you will, and how you use uh something like agent mode or the coding agent that we introduced this week to to get the exercise done, you know, to basically because the the the goal of the future engineer is no longer to write it all from scratch and the goal is to, you know, combine their prompting skills and agent open source libraries into getting that problem solved much faster than they could have done two three years ago. So with with that these were some of the like a bunch of ## A mini-history of GitHub [34:40] interesting facts. I wanted to talk about the the the past and then later the present and the future of GitHub starting with the past. So git uh we we I did a podcast episode with Linux kernel maintainer Greg KH and he he told a story about how git was created in in 2005. In fact recently there's a podcast with GitHub a staff engineer at GitHub interviewed Linos in 2005. Lin store words got frustrated with uh the source control for the Linux project specifically. There was some commercial things we can see history sat down in 10 days he wrote git which was obviously open source it was meant for Linux only but they released it and turns out it's pretty good. GitHub was founded in I believe 2008. Can can you tell me about these early days? What what what happened then? What you understand from talking with the early founders? The first commit was October 2007. So it was about 2 years after Lenos had done git, right? And then October 2007 to I believe February 2008 is when uh they started beta testing it with with folks in the Ruby Ruby Rails community. And then um April is when the public version of of GitHub launched. So it's really fast as well. um you know October to to April Fier six months you know if you go back you know to to the history books um it's Chris and Tom uh Tom Tom Creston Bourne and Chris Wstrad meeting in a bar as as I remember it and uh having seen Git and and and and figuring out that there isn't um a place um where you can host your your open source repositories and your private repositories together. There was obviously things like um Source Forge um which was the most popular open source platform back then but also you know painful to use um I think that's fair to say like those that I had a couple projects on saucer as well. It was kind of designed for a different era of the web and and didn't and didn't make the jump in that mode ultimately you know became known as as web uh as web web 2.0 or or cloud native. And so I think the the idea was okay, git is here. Git is amazing uh but I want to host it um without you know setting up a server and installing you know the back end and managing you know SSH access. And so they started building around around that idea. What always made GitHub GitHub is that they put the developers first. Like if you go on the Vback machine and look at the first you know GitHub homepage it isn't very fancy. It looks like a commit lock. this very short announcement of hey you know we shipped this new feature try it out and let us know what you think right the story about our logo uh what is now known as the octoad you know is is is a funny one and I learned that actually from the acquired podcast because they um they learned from the Twitter founders how they got their logo and they bought it on some uh stock graphic uh page um from a British designer I believe and so they looked you know for other graphics that that the same designer had done and and bought you know this this hybrid rid of an octopus and a and a cat uh and and and made that the logo. Um right. So there was a lot of you know as a bootstrap startup that's scrappy that has a cool technology that might you know become the next the future of of of version control and then they built what is now known as cloud native but a cloud native company and um and then yeah it grew fast and uh back in the day probably the product with the fastest product market fit. Uh nowadays you know there's there other companies that have it similar but it's a different time. It's a different time now and I think it was unheard of um how quickly it spread like wildfire. I was in 2008 still working in the automotive industry. I was at Bosch. Uh 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 I became you know an an ISV building apps for for German companies. And so I created I think my GitHub account in in in early 2009. We can look it up I think March or April 2009. And then I was at Rails conf uh the Ruby Rails conference in Las Vegas in 2009 and saw Chris uh Wrath giving a talk about GitHub and and what they up to and that's I would say when I became a GitHub fan and and when I started using GitHub in in my projects um but until that point you would use some some help self was a tool you know install it on some wood server or maybe you already had the cloud and and and maintain all that yourself and ever since people just you know log in with GitHub and and create a repo. Yeah, when I looked through the history just the things that I could find what struck me as like so like as the first company was it 2007 in ## Why GitHub hit product market fit so quickly [39:10] 2008 the service was launched I think you said March or something like that April sorry and already in 2008 the Reddit, Yahoo, Twitter and Facebook already onboarded. Facebook was surprising to me cuz I knew they use Mercurial but apparently they use it for their open source things. And these are these were very hip and very trendy companies at the time. And obviously from there on as you said in 2009 this was the obvious place to to find. Why do you think it was so popular? Like what what what was the reason? Was it open source? Was it because git wasn't even like back we're talking 2008 2009 like now we know git is great and it works but back then this was not clear. There was s everyone was using svn. I remember at the time and Microsoft had their own really heavily invested TFS team foundation server. Why do you think this product market fit just hit so so bad and devs were like yeah GitHub is the place to be? get you know solve the pain point that we you have with all these other uh dist version control systems you know subversion TFS you know had its own uh version control until much later when they added git support uh they're painful to use um and they were 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 machine so you can switch from one branch to another even without having the connection and you had always everything on your computer. So, you know, you could make changes to multiple branches and then then pushed upstream or or shared with your co-workers. And in some ways, you know, GitHub, I think, is the irony of um of of software development tools um because you have a decentralized system like Git and then you have a central hub uh where that the world depends on today and where everybody pushes to. So this notion of of decentralized systems is still something that sounds great and when developers are chatting about technology uh but I think humans are are longing for home and you know today at GitHub we have the saying we're the home of software developers um where they collaborate um human to human and and soon human to agent. So I think that played a big role. um you had you have had a new version control system that people were intrinsically motivated to try out because they were frustrated with using or even CBS, you know, and um and something like that and and just wanted something new to solve that problem and then it was just easy to to to shoot an account and um and and try it out and and uh you know even user interfaces like browsing the repo, clicking through the file tree, GitHub, you know, innovated a lot in that compared to what was there before and making that Ajax requests. So they would load really fast and you wouldn't wait to full full pry load. GitHub invented the pull request. You know this notion of that you can fork a repo 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 asking the other maintainer uh to to merge in your changes before that diff files were exchanged. This episode is brought to you by Augment Code. You're a 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, cue a parallel task like bug fixes, features, and refactors. Close your laptop and return to ready for review poll 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, Jet Brains, Android Studio, or even Vim. Don't hire an AI for Vibes. Get the agent that knows you and your code base. Start your 14-day free trial at augmentode.com/pragmatic. Well, I think this is one of the biggest thing that people miss as as I understood like understanding. So like Lin store 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 with your git changes bundled and that's how Linux works. They just use email and GitHub does not do this indeed. GitHub invented the the pull request which is a big difference between even today how Linux uses get and and GitHub does and yeah it was a smash. When was the pull request invented? Do you know was it early on? I'm getting the date form. I think it was a year or so in into it wasn't definitely wasn't there on day one. uh it it came sometime later. Um we can you know look it up and add to show notes but um it was a new thing at the ## The invention of pull requests [43:44] time and I think it it's ultimately liberating for for software developers where you send a pull request and you know if the maintainer doesn't like it they can just close the pull request or leave it open but others can see it you know and and if they want to pick it up they can just jump over to your fork and keep using it there. So you see, you know, um see a lot of that also happening that people just keep their forks independent uh because they want to they don't want to have the obligation to to engage with the main project. Like I have a bunch of forks where I made some small modification for my own, you know, hobby project. Um I don't see, you know, um I don't see a big reason that that needs to go back into the main branch. Some of that might be just with hackery as well, right? And so you it makes it much easier for developers that want to collaborate to collaborate with each other. And for for the others it democratizes how they engage with open source, how they learn from it, how they mix and match and and so on. So what one kind of gathering if I putting it together like open source was clearly one thing this new collaborative workflow especially with open source but also and I think one ## How GitHub enables offline work [44:50] thing you didn't mention but I I wonder if you're if it is a 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, like 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 if it's just again if it's just like a 30-cond outage or a 1 minute one. Again, not advocating for it, but you might not even notice because you're you're just like doing your local thing. I I I I I think as developer like I think we appreciate when we know we are not locked into well by the way it's free like a lot of the the sorry not not GitHub per se but for open source it was always free right it was always free for open source um and in you you might say GitHub invented a version of the fremium model that is not adbased right traditionally fremium is adbased the free users get it uh get something for free with advertisement and then the paid users get get rid of the advertisement and get more features GitHub originally had the separation between everything you do in public as free because it helps the community obviously helps the social network quote unquote yes or GitHub growing and then when you wanted private repositories um you had to pay for them. Um a shortly after the acquisition early 2019 we changed that and instead of paying uh for private repositories we actually made private repositories free as well because we had a lot of uh uh individual ## How monetization has changed at GitHub since the acquisition [46:21] developers giving us feedback. Um especially you know when you travel around the world um for an American $4 a month might not be a lot. Um but for somebody in a different country that that is a much more money uh relative to their income. And so we were private repository free. And today we charge for what you could call enterprise features like single sign on or branch protection things that a student or hobbyist you know probably doesn't need. If I'm honest when I work on my hobby projects I barely write any tests. I certainly don't send myself a pull request you know to review my own code. I just merge push into main blanch and that's cool. And so but yeah GitHub innovated in this in the business model space as well. And you know you mentioned uh that the the scenarios where it's helpful to use GitHub or Git on on your local machine. Um in 2007 2008 flights didn't have Wi-Fi at least in my memory. Wi-Fi wasn't like have Wi-Fi as far as I remember. I don't know if Starbucks maybe Starbucks already had it but like there was much more places where you would work just local on your machine uh for for quite a while and and and being able to commit into the repository. There wasn't, you know, subversion didn't have a push. It had uh you would always commit into the into the upstream uh change planes you know roll back all these operations that are now natural um with git that weren't natural in in 2007208. So, so it gets GitHub started off it started to get real big traction 2008, 2009, 2010. The next big kind of milestone I remember from developers perspective is until then to use GitHub you you could use the web version and ## 2014 desktop application releases [48:00] you use the local command line interface. You just learned all the commands you know there books about like the easy ones are easy and then like cherrypicking and all that. I was always confused by that. Uh 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 loved. I used it for so long. It was a lightweight editor. It it released the Electron framework which powered Atom and then and then GitHub desktop in 2014 2015. Why why do you think GitHub waited that long to have these desktop applications? What what what was the goal with atom and and how how did this help? Did it actually help like get more people who just liked a nice user interface and were not the command types? I don't know the history of of all these apps. My my suspicion is that um you know when you say waited this long, I'd make the counter argument how long is long for a startup to move from one core product to having multiple other products that may or may not become a distraction. I I think each of those solved a specific problems that that the team saw. Um Adam um came out you know I think a year or so before VS code launched and security the time was VIP you know for a new generation of idees of both of them were open source you know for the acquisition they they both ended in the same company and then OB made the decision uh to continue our journey on VS code and and retire 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. He would have the so so back then really there were no managers. There were no well there was obviously a CEO and like a little bit but that was very flat and and people when they when they onboarding was always at headquarters. So even though as a remote first company you would spend a week or so in our headquarters in San Francisco and you learned how to make an an espresso. Uh and that was literally one of the onboarding videos and you know they got to have some some whimsical future. Yeah. Whimsical culture. um and um you got told you know pick pick something that you're interested in and and that naturally leads you know to developers uh picking things that they want to solve for themselves that they care about and so Adam um was actually you know Chris Wrat uh the CEO at the time and then for most of GitHub's journey until the acquisition um was one of the you know core maintainers of the Alen project and um and so I think about CEO being a core maintainer a lot of that was about the passion of of the people working there. I don't know exactly the history of desktop but my assumption there would be that uh they saw a need to expand the people that can use GitHub uh without knowing all the intricacies of of git. Um in many ways you know the GitHub user interface on github.com also serve that purpose. If you think for example about blame uh views um blame on g.com is just clicking a button see who modified which file which line in the file. while if you do get blame on the comment line, it's um much much harder to to figure out what's what. Uh especially if you don't know a lot about software development. So, it's all about um growing the user base uh and expanding the people that um get get, you know, utility um out of I'll say that I I I use GitHub desktop a lot. I mean, every is different and I know how to use command line, but I just like that I don't have to think about it again. So, like I I I appreciate it when when it came out. I barely use it but uh I use you know the Git integration GitHub integration in VS code a lot um for the same purpose and so there's and I think even that you know git um as a protocol um with SSH access and HTTP access which also by the way wasn't something that was very prevalent in the early days of GitHub um and is now much more used um because it's easier to access through HTTP than than through SSH um I think all of these pieces you know they're ultimately helping you know, to create the developer experience that we now consider normal, but by no means was normal uh 20 years ago. So then we're getting to the Microsoft acquisition. So we've now passed 2015, it's now 2016 or or so. You were in the ## The Microsoft acquisition [52:10] 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, you know, how did the the purchase go from from your perspective? It was 2018, early 2018. um that um back then N freeri my boss within Microsoft um CDP in a developer division doing mobile developer tools Nat came uh from from Zamarin so had joined uh Microsoft himself when acquisition I had joined for the hockey app acquisition so we were like a bit of a you know outside in team within Microsoft with lots of people coming from companies lots of um you know cloud native experience um a non-traditional stack for Microsoft but at the same time also Microsoft had changed. Um it was now about four years uh since Satya Nadella had become the CEO. Satya had very early on embraced open source. You know then then VS code uh was launched umn net became um open source. So a number of steps had happened where Microsoft changed um its fundamental position on how it views open source how it views you know uh the stack and and where the future is going. Uh you may remember this part of the strategy back then was cloud first, mobile first. Um and um you know in many ways that is still true today. We're not no longer saying um those those two things. You know if you think about how you interact with Microsoft products today, you know on every device um regardless of who makes the device, what operating system, this was not obvious then because it was still Windows first. There was still a feeling that Microsoft is only Windows and yeah and and I heard this was said everywhere and I think outside of we were skeptical honestly but you know then obviously the cloud stack the compute stack that 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 you consider you know other companies in the space competitors and they're you know quote unquote the enemy um At Microsoft competitors are at the same time also customers and often partners. We are providing you know if you take for example Azure IA foundry our inference stack for large language models we're providing those not only to our own uh co-pilots we're providing those to many other companies that may uh directly or indirectly compete uh uh uh with GitHub or with with other Microsoft products. Right? So and so 2018 the world view in Microsoft had changed. I think the reputation started to change. Um we at Microsoft started to believe that we could pull off an acquisition like GitHub where you you know make GitHub part of Microsoft and and and not lose all the open source maintainers because they like Microsoft you know is not going to be good steward um of GitHub and we set very early on clear principles of what that looks like and 2018 was about two years after the LinkedIn acquisition a bit longer since the Minecraft acquisition so we had kind of like two examples of acquisitions where kept the brand and the platform uh independent. Um even even today when you go to to the LinkedIn homepage, you don't see a lot of Microsoft there. Um 7 years after the GitHub acquisition, uh there's there's no Microsoft on the GitHub homepage. um unless you're using uh Entra ID um you know as your as your single sign on provider or of course we have blog posts where we talk about um you know copilot and and the Microsoft model and and things like that and Minecraft is you know many kids I think realize much later you know in their childhood that one of their favorite games is actually the same uh company that also produces the operating system and the professional network and and GitHub right but part of when you know when you look at those two acquisitions and then you see GitHub it it feels like a natural consequence like the natural next step for Microsoft to go down that path. Microsoft always has been a developer first company you know first product was basic for the alter and and you know here at the conference center I don't know if you 1975 experience where you work on a fake alter and uh and pass some coding tests um you know then that was basic for the Apple 2 and and and obviously Visual Studio in in 1990s uh I think my first version of Visual Studio was Visual C 1.0 zero came with a book uh and then had Visual J which was like Microsoft's Java clone and then then I bought like a full scale Visual Studio 7 for way too much money uh back then uh at least you know for where I was as a as a high school student right obviously uh in today's world uh selling an IDE at a onetime price would be something that that is has no has no market fit anymore you know Microsoft lacked access to the open source uh ecosystem it it it didn't have, you know, the same attraction to cloud native developers. It was just being not trending at all. Yeah. And and and it was important from a business perspective to to have that ecosystem. It was important for us, you know, to put developers first again. And so that was actually the first principle um of of three principles. And we believed we can reacelerate GitHub because GitHub in 2018 had a bit of the reputation of not being able to innovate anymore for for various reasons and we can we can talk about that as more in detail but it was really important to think about this 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 you started the conversations with them was about 700 employees all up and you mentioned earlier it's now over 3,000 employees. So that investment surely has happened and we have leveraged you know a lot of the Microsoft stack and copilot comes to mind where we're using Azure AI foundry and the relationship with open AI you know to to to build our our AI code generation product and then the last one was of course also Microsoft wanted something back and so GitHub accelerate Microsoft and the easy answer there is how did we achieve that by growing revenue um and um you know we announced last July um so about a year ago now that revenue has grown to over 2 billion annual recurring revenue run rate. uh and that you know keeps going and we're very happy with these business result you know contributing back to to Microsoft's earnings right but in that order right like developers first making great developer products accelerate GitHub and then eventually GitHub you know accelerating Microsoft and and giving back both on the product side with copilot or on the revenue side with with our results but I I think this is this last thing is just worth emphasizing in the sense that I think as a developer I I really like that I 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 more more companies, more more teams paying for sort of professional use cases, right, to help their work. If I remember correctly, 2017 uh was the last official revenue announcement that GitHub made before the acquisition and they were at about 200 million run rate and they announced at that time that they're looking for a new CEO. So Chris was was ready to step down and then that ultimately you know resulted in the acquisition then in June 2018 through an acquisition and a new CEO net net freman. Uh but like 2017 you know 200 million to 2024 in seven years um revenue went up factor 10. Yeah. Well this is which is also it's kind of reassuring to hear that because there's always a risk like we know Microsoft is a for-profit company. It you know like such an adult report to shareholders. It's good to know that those those things are are going well as well. Well, and and I think you know the for a long time developer tools were not seen as a as a as a revenue driver in the in the industry. I think you know there were a few examples like companies in Jet Brains comes to mind or JROG there's a bunch of companies that you know we're focusing on developer tools but I think you know if you if you try time travel back five years uh or before that give let's say seven and a half years and we talk with venture capitalists about an idea that we have you and I about a developer tool startup they're going to tell you you need something else beyond just developer tools because that's where the big money is and today this world obviously has dramatically changed absolutely but as I was talking with Scott Guthrie. The interesting thing was that the last company that was able to make develop developers pay for developer tools a lot of money. We're talking thousands of dollars was Microsoft in the 2000s where this was pre when internet was small and developers didn't just pay for developer tools but they pay for MSD and documentation for access to the latest software and you know that time has passed and we were talking about Scott on on some of the learnings but it's interesting how Microsoft figured that out. I feel Microsoft is very good at figuring out this great mix where again back then and I 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 we'll get today I part on on this one but you mentioned something interesting which I also noticed. So I looking back and I remember back it's when GitHub when GitHub desk came out it was great. I think I started to use GitHub more but then from like 2015 nothing really happened. Microsoft bought GitHub. Great. And I remember on online forums as well, people were saying like GitHub is not doing anything. And then the next thing I looked at the change log and the only notable thing I've seen shipped it started in 2021. Then the GitHub sponsors came out, the package registry, C-pilot, code spaces. But what happened there from 2015 to 2020? It almost felt like from I'm I'm sure people were working, but from the outside it just looked like nothing, like bare land and more people being hired. 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 hearsay and a little bit of insight. I think a big problem that GitHub had um especially before the Microsoft acquisition and you know, for some time after that was that um the ## Behind the scenes of GitHub’s quiet period [01:01:57] platform had grown so much um and so many people were relying on it being available and and not broken. Uh plus you know many developers did the big ben and still are very much in love with the brand like the the octoat you know internally we call it Mona how do you call it Mona like Mona Lisa you know Mona um is is something that is recognized you get you get asked about it on the street or like in a coffee shop or in the Lego store because obviously the employees there are often also college students and and have been in I mean I've been you know I had a you know on on an airplane the crew member asking about GitHub and I'm like how do you know GitHub and she's she was like well I you know used that it was that in college for for some you know computer science course that I took and and I think if you have something that is so beloved by the by the space that also means the expectations are really high like it's often that you know the disappointment is even bigger if you actually care about something while if you don't you know give a damn about this thing then whether it's up or down or whether it's broken doesn't really matter to you because you hate it anyway right and so I think those two things combined and led to, you know, people really being worried about shipping uh stuff because you would change something and the reaction from developers when you change something, whether it's the user interface or things work or hate limits and things like that is is often there's, you know, a loud minority yelling on the internet and and there's a silent majority that are actually fine with the change but don't say anything. And a small change might lead, you know, to an outage and then you're the one that made three languages of change in your first week and and you brought GitHub down. that's obviously not encouraging in your journey. So I think that you know created um an organization that um actually you still shipped a lot of things and what we call staff ship um what Microsoft called stock fooding. features that landed uh within the GitHub organization that that hubbers would see when they use you know one funny thing is um we have even today uh 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 a haba would see it and there's a way to disable all these features but how often well know I can hide the staff bar and then uh it disables the features that that you don't see but how often do you really do that and do you then remember that in a conversation that Ger doesn't have the feature but I have it and I I thought it already shipped but it is actually slated for next week. So I think that that created you know a culture whereas things were internally shipped um but but never made it uh you know to to public uh because everybody's worried is that is that good enough to to ship it you know CEO change uh uh was in flight there were a number of cultural issues and then uh as as we closed the deal and we came in u we made private repos uh uh public relatively fast. That that was a fast one. actually at that universe in in 2018 the first version of GitHub actions was announced. Uh that was even before the deal closed but it was you know hopefully the folks building it forgive me it was bit of a hack uh built on on top of containers in in uh in in Google cloud um and um we quickly saw from the data that the the product wasn't actually meeting the the requirements from developers many developers wanted full CI/CD while Git actions originally was designed was workflow automation and we kept that workflow automation part but evolved it into what it is now and over the course of 2019 19 at 2020. Sponsors was announced uh in mid 2019 at the last ever satellite conference in Berlin and then co came and that ruined kind of like the the plans that we had uh as we came back from it. You know, we were very careful with bringing back universe in a smaller scale. Um 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 um where we could both innovate really fast and you know, keep uh the fundamentals in place. um keep security um availability um uh you know other things accessibility things that you might not actually see have changed um because you know if everything is working you don't notice it um but it you know created a lot of investment behind the scenes so we are we are feeling good about the pace of innovation that that we have today but yeah it to it took us a while to turn turn the ship around and you know even in a team of 700 people that takes a while and certainly with 3,000 people that uh it is something that you know requires a lot of energy and and um 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 like and growing too fast is is amazing I think the best problem for any team to have but it's still a problem right that that you need to solve and you get through it now co-pilot was the biggest ## The release of Copilot and its impact [01:06:42] flash that I can remember from the past few years clearly especially because when it came out it just felt so early was it was did the beta come out in 2022 21 21 yes people came out 21 yeah beta came out in 2021 because it was built on an earlier model before Chad GPT launched it was on uh was it on GPT2 no it was um GP3 was the so GPD3 came out at the right after the build conference in 2020 which was obviously given given the pandemic uh fully remote uh but Kevin Scott uh and some ament did a session about transformers and Dutch language models and then after that GP3 uh got into into the preview and and we got access to that and through the OpenAI Microsoft partnership and and we realized uh together with OpenAI that it was able to to write decent code um in different programming languages and and wouldn't not mix up the syntax between you know Python, Ruby and JavaScript which uh 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 it's not able to validate the code it generates um it doesn't have the syntax that just knows it from the the training set and then openAI fine-tuned a model that uh uh was called codeex. Yes, that was spec specific for these coding scenarios and uh in so in 2020 in August we wrote a paper with three ideas we had text to code to text as in describing code and conversational coding is what we called it which then you know today is known as chat and those two letter scenarios didn't work well enough uh we you know we had a describe code and sometimes it worked and often times it was wrong and you know how it is uh when developers see that that the description is not actually what the code does you quickly you know detract and you get a little uh net promoter score or whatever you're you're measuring satisfaction with. But but uh text to code as in you know prompting the model uh within the editor and and ultimately building auto completion that worked so well that very quickly we saw our internal you know uh uh hubbers adopting the tool giving it really high scores um saying you know this is great I want to keep using this I it's not the typical management says you have to use it and you don't want to but ultimately writing uh you know in the early days 25% of the code in those files it was enabled and then shortly there after that number got got into the 50% range or 46% I think early 2023 and so that was the early days of co-pilot then June 2021 we went into the public preview h and within you know a few months uh the debate this had grown to a million users you 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 cuz the surprising thing for me is every most of us remember the launch of Chad at GPC in November 2022 and everything exploded from there. It it was the product that that made people go wow inside tech outside tech and a lot of AI startups start up and a lot of actually coding startups started after that. So like in early 2023 however by that time get GitHub copilot was already I think I think it was beta in 2021 right but in 2022 I think it was it became public so it was GA already available was generally available in June 2022 and it started charging for us for it for individuals in August 2022 and then chat GPT actually had two moments but one of them was um uh not noticed by many um so um OpenAI showed at Microsoft Ignite conference which is fall event showed actually CHPT in the keynote. Um it it wasn't called CHP but they called like they showed like a similar scenario uh that is what what you see now the agent doing where you we ask it to to to write some code and make modifications to our code and then it launched uh in in late November and the world changed for us dramatically. um uh for once because we had a product on market uh that was really good for developers and so our customer conversations shifted from us having to convince customers that AI is actually something they should look into to customers asking us to come and talk about how we build copilot how it can help their developers the first you know user studies come in we were um the first money the first company comparing a group without copilot with a group with copilot and and 5% number is obviously you both well known and and and often used today as a productivity improvement which was never intended to be. It's a case study in that one scenario. It made the developers 55% faster, right? There's lots of other things that developers do day in day out where you don't get the copilot make you that much faster. But it was a very exciting time and then in 2023 we launched chat uh GPD4 bought it into the CLI voice came out right. is a lot of these things feel like they have been around forever, but it's only been a little bit over two years. Totally been. And in 2023, uh on on a on a post from GitHub, uh I'm not sure if it was you, so I don't want to misog you, but but it was written that that just as GitHub was founded on Git, today we are sorry. So it was you writing it that just as GitHub was founded on Git, today we are refounded on Copilot. This was in 2023 and copilot was clearly very strong. What what has this change meant since then? And now it's been two years. This was at GitHub Universe 2023. So I think in that year the conference was in early November. Um uh 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 or blog post and we talked a lot about the early days of GitHub, right? The GitHub founders did not invent Git. Um Linos to did but they realized there's a new technology that changes how developers work. not only to version their call their code but how they collaborate right GitHub if if you think about it GitHub is designed for asynchronous collaboration of developers that what GitHub is really all about and with copilot repeated history because we didn't invent transformers we didn't invent large language models we didn't train GP2 or three or codecs but um we saw something that changes how developers work and you know if you're honest um we saw an opportunity for ourselves to accelerate. Uh is you know my backlog is endless. Um there's lots of GitHub issues in repositories that were filed where the issue is issue was filed in 2014 with customer feedback and you know every enterprise seller since then you know posted on 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 and you mentioned security issues and availability and all these things are also high priority. when we saw uh GP3 and then codeex we saw an opportunity to bring the effort down for all for own developers and of course every developer on the planet to to get more done not that you know they actually get to an empty backlog because I don't believe that because Javon's paradox means more ideas will get stacked in fact now we have all the AI ideas you know if you will now GitHub and Microsoft are closer together from the sense that Microsoft's developer division uh you know has for over 25 years produced idees and and copilot started as an IDE feature and while GitHub was the developed platform now those are you know the ven diagram of GitHub and VS code and NVS is is much more overlapping and we see that here at the conference and we see that in our day-to-day interaction between GitHub and and DevD and just on build you know like two big announcements related to to GitHub one is open sourcing co-pilot extension why did you decide to to do that and and also like what's the what's ## Why GitHub decided to open-source Copilot extensions [01:14:14] the idea here because we we have seen open sourcing with with VS Code. In fact, open sourcing VS Code gave way to some of the the competing editors that are are also adopted you know Windinserve cursor I think there there's there's some smaller ones as well. What what is your hope with this move and and and why? You know, it it feels counterintuitive because copilot has has kind of been an edge for Microsoft, right? Isn't it isn't it funny that it's it's counterintuitive? We live in a world now where Microsoft is embracing open source and is open sourcing its part while startups are taking open source, forking it, and making it closed source. Like this is like if you had told me that 10 years ago, you would have said you'll have it backwards, buddy. This is true, right? Curves on not open source. is that's not you know um and look you know that's we we published VS Code in in in 2015 under the MIT license um so the license allows it and of course people uh can do with a VS codebase what they want that's that's fair game and so we're stepping into our footsteps into our own footsteps footsteps uh of of VS Code over the last 10 years and we felt the time is right um to bring the the copilot extension into the main uh editor uh codebase and that means it needs to be open source Um because we we made a promise to the community when we published VS Code that we will keep it open source. You mentioned we um co-piloted in 2021 2022. It didn't take long until people reverse engineered the VS code extension. It's at the end of the day JavaScript. Uh we write in Typescript but it's delivered as offiscated JavaScript. And so there's you still can find those those blog posts of how we compose the prompt, how long the prompt context window is, you know that we're using adjacent tabs. All that information is already out there, but you couldn't take that information and contribute back um or, you know, look at the codebase, learn from it, or take, you know, copilot and its APIs and its 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 VS code experience. You want that you know scope experience for an interview loop. So I think from our perspective it follows exactly the idea of open source which is you can learn from it, you can contribute to it, you can fork it, you can do whatever you want with it. Um it it ultimately helps the the developer community to have that piece of client code available. And you know now you're going to ask uh or I'm going to ask myself the question so where's the value generated and and aren't we losing uh all the revenue and we believe that the ultimate value generation for these AI tools is in the platform whether it's the the compute or inference layer um whether it's the security or control layer right enterprises want control what what model is enabled who can use uh AI you know in which project you might use AI given that you might have signed you know legal terms with with whoever provided your source code that you aren't using certain technology and um uh inference layer, the the security layer and at the collaboration layer where where people collaborate and you see that uh with with humanto human collaboration uh and we were going to see that with human to agent collaboration with our new coding agent. We're bringing that agent into the G platform and and we're giving it certain permissions and we are uh protecting the agent from doing things that you might you know allowed for a human but you want control over that when when the agent does it. I I do like looking back at the 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, Jet Brains, you know, they they might disagree with this, but I remember the first time I bought a JetBrains project for $200 a year was this extension called ReSharper. So, Microsoft opened up their IDE to allow extension points and JetBrains honestly wrote a way better autocomplete than Microsoft themselves had and they made a bunch of money off of it and I think this helped them spin out 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 I I just really like like how Microsoft seems to be keeping this idea of like sometimes opening up the business so others can succeed, startups can do it. It it's better for everyone especially as for developers just want better tools. As you mentioned Xcode, we actually have a co-pilot extension for Xcode. It's a bit of you know hackery given the extensions given the limitations. It's not as but it does have auto completion. last chat and just uh this week also we ship agent mode as a preview into the Xcode extension. We have it in the jet planes uh uh extension as well across all the different jet planes IDE. Uh we even bring it to Eclipse um uh and and that is in preview now including agent mode because if you look into you know larger companies uh they have developers on all of these um and and probably you know another dozen of other editors that developers prefer and where the company doesn't want to prescribe which IDE to use. But it is important for companies to standardize their engineering system stack and to have certain approved tools. Maybe it's just those maybe it's multiple of those. Obviously if you think about for example artifactory or j um often companies have that in the stack together with github or or hashi cop terraform and of course you have a cloud and a key key store secret store and then key value store and whatnot. But it is uh important to have uh copite available across all these IES and our export codec extension is already open source um was open source before this week uh because an open source maintainer voted uh and then we did a commercial agreement with that open source maintainer course to take it over right so we you know the maintainer benefited from it we benefited from it but so that means the system prompt the APIs all that you can already find in Xcode extension and so now we're we're continuing that journey uh with VS Code and others well the the last question I I wanted to touch on this is agent a ## AI agents and the myth of disappearing engineering jobs [01:20:01] agent mode or or gif agents was also an announcement and the agents are 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 like vision of in the future as a software engineer you will manage all these agents and you'll be more of a manager than a software engineer and there's you know two things here a 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'll just seems like a boring job to be a manager and then the the other thing is what will happen with what could happen with uh with software engineering job and then you said earlier that you believe this will increase actually just just recently and in public. So what what is your view on on Asians and what advice would you give to software engineers who are you know want to say software engineers but obviously want to up level like how should we look at this thing because it feels like a freaking big change. I don't like the term autonomous because I think autonomous at least in my understanding means the thing figures out itself what it should work on. That's not how these things work. they have a level of autonomy when you assign a task to them of how they're implementing the task or but even that autonomy is restricted by uh the MCP service model context protocol that you configure for it or the tools you allow it to use or you know the repository you give it access to because obviously as an engineer as a human engineer uh I can look beyond the one repository boundary and see what has been happen in other repositories uh while the agent needs to get permission to do Right. So it's we're definitely far away from full self-driving. Uh if you take cars as a metaphor here, we're certainly getting into more driver assistance systems. And as developers, we have always automated whatever we can automate, right? A compiler is is a tool that helps me to not write assembler. Instead, I can write a much nicer language. Thank god. And but you know like I'm sure you know when compilers and then languages like basic and others were introduced there were also skeptics saying you know I'm losing control over the instruction set uh and the optimizations that I can do and my my app is so much faster and I certainly remember you know my my Commodore 64 days when there was a very active demo scene and you couldn't really have a a successful demo especially as and I think even nowadays it exists where the size was limited back then through physical limitations today it's artificial right? Like you're limiting it because it do you want to create a challenge but you could only win those demo challenges if you knew how to do assembler and and and and you couldn't you couldn't win that in basic so agents will you know work as one of the tools that have developers have available um just like we have compilers linkers llinters 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 write test cases and certainly not more than they have already written right like test unit testing is always a how How many do I write until I can get away with it when I go into cotal view that because there isn't like a right answer. It's like not a dozen and you're good. It's like how many you need is actually very is a very subjective thing. And those that try to holistically test all the edge cases um they they're never shipping actual valuable software. writing documentation, uh fixing security vulnerabilities, finding these security vulnerabilities when I didn't see them because I had a long day and I I you know I have obviously always my own uh bias that you know the code that I'm writing it does exactly what I want it to be until you have even something simple like a pull request description right like have the AI describe the work that you have done and all of a sudden it shows well Thomas broke the behavior it won't say it like that but like you know you get the idea Thomas changed the behavior of of of the checkout flow program like wait a second I didn't touch the checkout flow why why is this no change right because when it describes the code changes it doesn't have the confirmation bias that you yourself had when you would write your own description so I think we're heading into that world and now you have these let's say I start four agent flows I think that's what uh Jessica Dean did in the day two keynote um well but also you have all this code generated by all these agents I'm the one now having to validate that what the agent did 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 merge conflicts by the time you're merging those things. So you got to understand all that code. You got to understand how the system is designed. You need to know what the agent did to be have the level of confidence, trust, you know, we talked about security, availability, all these things earlier. Scale. Um at the end of the day, most companies are for-profit organizations and even those that are nonprofit operating under budget. And so you need the agent to write code that solves a business problem and still makes you a healthy margin. It sounds like keep an open mind and experiment and see how they can help you. Right? The other thing that you know is I think super important to this is that we already seeing this paradox because now we have all the AI requirements that come on top of what a full sec engineer does, right? like no longer just back end and database and infrastructure and front end and how the front end communicates with the back end and you know at GitHub to give you give you one last data point is we are seeing 120,000 API requests per second on an average day. Oh wow. That's seven per minute. That's uh 430 million per hour or 10 billion per day, right? And that's API requests. And now that doesn't say is it a cheap API like you know listing the first 10 repos that you have or is it a GraphQL API that can take you know lots of complex queries to actually render the result right and so if you just take that example like you got to have engineering skills you got to have developed craft. You need senior people that know how to build large scale systems. You need people that take large complex problems, take break them down into smaller problems. Maybe they use AI along the way and say what's, you know, a good, you know, no SQL database, what's a good infrastructure, how do I do data residency, how do I do GDPR? That their job is going to be break it down to the to this to the layer where they now know now I can sign it to the agent that will provide high quality code without me having to reprompt it 15 times. And then I can merge that into my codebase and move to the next task. That's that's what engineering is all about. The 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 that and into even larger larger system you know next week in today's world. Love this takeaway abstractions and and being able to take on more complexity. This was a really good conversation. Yeah. Awesome. Really great to meet you Greg in person and looking forward to stay in touch. Thanks very much to ## Closing [01:26:36] Thomas for this conversation. The thing that struck with me most is how despite GitHub building AI tools like Copilot, Thomas very strongly 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 on AI engineering, check out deep dives from the pragmatic engineer linked in the show notes below. If you enjoy the show, it would mean a lot if you left the rating on the show on your podcast player. This helps more people discover the show. Thanks and see you in the next one.