The Pragmatic Engineer - The present, past and future of GitHub

Episode Date: June 18, 2025

Supported by Our Partners•⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more.• Graphite — The AI developer productivity platform. • Augment Code — AI coding assistant that pro engineering teams love—GitHub recently turned 17 years old—but how did it start, how has it evolved, and what does the future look like as AI reshapes developer workflows?In this episode of The Pragmatic Engineer, I’m joined by Thomas Dohmke, CEO of GitHub. Thomas has been a GitHub user for 16 years and an employee for 7. We talk about GitHub’s early architecture, its remote-first operating model, and how the company is navigating AI—from Copilot to agents. We also discuss why GitHub hires junior engineers, how the company handled product-market fit early on, and why being a beloved tool can make shipping harder at times.Other topics we discuss include:• How GitHub’s architecture evolved beyond its original Rails monolith• How GitHub runs as a remote-first company—and why they rarely use email • GitHub’s rigorous approach to security• Why GitHub hires junior engineers• GitHub’s acquisition by Microsoft• The launch of Copilot and how it’s reshaping software development• Why GitHub sees AI agents as tools, not a replacement for engineers• And much more!—Timestamps(00:00) Intro(02:25) GitHub’s modern tech stack(08:11) From cloud-first to hybrid: How GitHub handles infrastructure(13:08) How GitHub’s remote-first culture shapes its operations(18:00) Former and current internal tools including Haystack(21:12) GitHub’s approach to security (24:30) The current size of GitHub, including security and engineering teams(25:03) GitHub’s intern program, and why they are hiring junior engineers(28:27) Why AI isn’t a replacement for junior engineers (34:40) A mini-history of GitHub (39:10) Why GitHub hit product market fit so quickly (43:44) The invention of pull requests(44:50) How GitHub enables offline work(46:21) How monetization has changed at GitHub since the acquisition (48:00) 2014 desktop application releases (52:10) The Microsoft acquisition (1:01:57) Behind the scenes of GitHub’s quiet period (1:06:42) The release of Copilot and its impact(1:14:14) Why GitHub decided to open-source Copilot extensions(1:20:01) AI agents and the myth of disappearing engineering jobs(1:26:36) Closing—The Pragmatic Engineer deepdives relevant for this episode:• AI Engineering in the real world• The AI Engineering stack•  How Linux is built with Greg Kroah-Hartman•  Stacked Diffs (and why you should know about them)•  50 Years of Microsoft and developer tools—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Steve will came out 21, yeah. So GPD3 came out right after the build conference in 2020. Kevin Scott and Sam Altman 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 Open AI Microsoft Partnership. And we realized together with Open AI that it was able to write decent code in different programming languages and wouldn't not mix up the syntax between Python, Ruby, and JavaScript. And then Open AI 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 latter scenarios didn't work well enough. But text to code, as in pumping the model within the editor and ultimately building auto-completion, that worked so well that very quickly we saw our internal hubbers adopting the tool, giving it really high scores, saying, this is great, I 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 that 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 we saw more and more folks on social media saying, well, I was skeptical that this could ever work. But it actually is good enough that I don't want to work without it anymore. GitHub recently turned 17 years old.

But how did it start? And how did a platform evolve? I sat down with GitHub CEO Thomas Zemke, who has been a GitHub user for 16 years, has been working at GitHub for seven years, and has been the CEO of the company for the last four years since 2021. In today's episode we discuss, GitHub's remote first and acing first engineering culture, and why the company barely uses email. Why GitHub seemingly stops shipping features between 2015 and 2020, and how they created GitHub co-pilot in 2021.

GitHub's interesting internal tools in the early days, like Haystack, GitHub TV, and Hulp. 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, someone for having me.

It's great to meet a person after exchanging email. and putting a name to the face. And reading your newsletter every week? 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 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 a Ruby on Rails monolith. At some point, it might have been the biggest in the world, and then I think Shopify 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 and Rails applications. The other one that you didn't mention was Twitter. It was in the early days also Ruby. In early days, yeah. I think all three companies in one form or another have somewhat moved a wave on this being the only part of the stacks. We still have a large monolith with about 700 engineers in that within the company

contributing to it at different times of the year. Not all of them are working constantly in the monolith. We actually just passed 2 million Git commits into the monolith and, you know, tens of thousands of pull requests. But we also have moved beyond just that one architecture. So, for example, we're using more and more React on the front end. We have a number of, you know, services that outside the monolith, for example, the copilot API is written and go, given it needs, you know, lots of API calls for inference. The GitHub Actions, this is on a completely different tech stack, kind of actions. I would imagine Rails might not be the best for a very heavy workflow.

And it has actually a history because a large part of the action stack came from what was back then Visual Studio team services and then became added DevOps. And so Azure pipelines. And so there was a lot of dot-net code in that code base. And over time, we are now evolving that into more modern architecture with the goal of, you know, one of your other posts of getting to four nines and beyond. And so our tech stack is very diverse today. Obviously, we're doing also Swift for iPhone app. We have Cortland for Android app. We're using all the clouds beyond also having our own metal in commercial data centers.

And we have like a modern software company with all the complexity and all the challenges that everybody else has as well. And I guess all the not simple tradeoffs, 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 your history of it. And then...

I mean, we can spend a whole hour probably just talking about the benefits of having a mono repo with a monolith versus, you know, hundreds of microservices. You know, when GitHub was in 2007 was founded for, I think, more than a year, it was only the three original founders, Chris, PJ and Tom, plus to Scott, who's now the founder of Git Butler and Scott Charconnell, who's kind of like the first employee that was often seen as the fourth founder. And so, you know, a team of four is way better off of working in a single code base. You can move much faster.

I think that was always important for GitHub to be able to move really fast and ship new features. And it's much easier to, you know, get to learn the code base and try to understand the dependencies as the company scales and the product scales. it makes more sense to move away from that architecture. I'm so glad you're saying this. The other day I was talking with an early Amazon employee, and he was saying the same thing, how early Amazon had made sense. And then as you grow, 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? Statsig. Statsic is a unified platform for flags, analytics, experiments, and more, combining 5 plus products into a single platform with a unified set of data. Here's how it works. First, Statsic helps you ship a feature via feature flag or config.

Then, it measures how it's working, from alerts and errors to replace the people using that feature to measurement of top line impact. Then you get your analytics, user account metrics, and dashboards to track your progress over time, all linked to the stuff you ship. Even better, Statsick is incredibly affordable. with the super generous freets here, a startup 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 statstick.com slash pragmatic. That is sta, tsig.com slash 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 software company on GitHub. Graphite also leverages high signal code-based aware AI to give the believers 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 Vercel 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.d.def, dv slash pragmatic. That is G4 Graphite, T4 Technology.Dev slash pragmatic. Now, you mentioned something really interesting, which I also heard that you run your own data centers or historically have run your own data centers. But I talk with some current GitHub folks and they said that you, in some part, still do so. Why did you do this? How is it changing? And are you, obviously, since you're now part of Microsoft as well, does it make sense to use some parts of Azure and if so what parts

are you using? And you also mentioned other clouds. So like, how are you thinking of own data center, which again, we used to say, oh, it's just moved to the cloud and there's the sound opposite I'm thinking as well. What's your take on this? Get up, you know, started on the cloud. Really? Early days, it was, to my memory, it was engineered as a platform as a service provider and then AWS behind the scenes. Oh, okay. You know, it's easy to forget in today's world where lots of startups announce huge funding around.

GitHub had no funding until, I think, five years into its journey. Oh, okay. Back then unheard of 100 million came from around led by Andreessen Horowitz, but until that point in time, GitHub was bootstruck. And it had very fast adoption, you know, when it launched in April 2008, very quickly the number of users, a number of both public and private depositories kept going. You can still find, you know, people talking about that they're begging the founders to introduce a paid tier.

So they have the confidence that the company can survive. We'll be around. Yes. And so it was a natural business decision for the founders to say, how can we host this, the more optimized cost, given that we're bootstrapping this and we're having to pay for the service from our own revenue stream. And they couldn't be burning money because they had no money from venture capitalists. And so I think that was part of starting the decision.

The other one is storing Git data, what we call today our Git systems team in file storage in itself is probably not the best use case for the cloud formatives that existed in 2009, where you had limited access to that layout and where, you know, especially the networking part of having multiple, you know, nodes 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 centers. So we own the servers. We still own the servers in the racks 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. It's own in the sense of we managed the servers in those data centers. Now, today's GitHub is a lot of that. The core is in these own data centers. But things like GitHub actions, GitHub Quartz spaces, get up co-paces. get up copilot run on Azure in the cloud and leverage the scale that you naturally lead, whether it's CPUs and actions or GPUs in co-pilot. Of course, copilot given it's multi-model choice and has orthopic models and OpenAI models

and Gemini models. Not all of these models are on Azure. So naturally, we also work with other providers often with both, you know, the first-party API, aka the API that OpenAI or Anthropic provide and, you know, other clouds that have vertex bedrock and so on. And we in fact now have GitHub fully hosted on Azure for data residences. If you as an enterprise

customer in Europe want your data all stored in Europe, you're getting a GitHub organization on a stamp that fully runs on Azure in Netherlands and in Sweden. We have the same for Australia we just announced a US stamp that will be Fedrem compliant

and we're going to expand into more regions in the years to come. Yeah, I feel these are the like really kind of boring things, but they start to become really important when you are at a company that is now starting to care about these things. Well, they're not boring from an interesting perspective. Well, not boring, but it's the thing that I think as a from outside, you know, it's not the shiny features, but I agree.

An engineering perspective, that actually sounds pretty challenging. The challenge, you know, if you go back to the Ruby on Rails conversation is, and if you know a little bit about Rails and how, and we do not only run on Rails, we also run on my sequel. And so whenever you change, you know, the schema of a database table, a so-called migration is run. How do you do that if you not only have one stamp in one region, but you actually have, you know, five or 10 stamps? And we deploy, you know, hundreds of times per day. In fact, I think this year we're forecasting 12 million deploys across about a thousand or so I see engineers that we have in the company. And so how do you do that?

How do you deploy, how do you go from one, you know, a central stamp on our U.S. data center? cloud, if you will, to having deployment that goes to all these different stamps and fund the migrations. And then if you need to able to hold back. So that was a lot of the engineering work that went into that. Less so I'd say the actual work of moving this to Azure was less work than getting the engineering system, the DX, the developer experience, actually aligned with this now we are running in multiple regions.

Yeah. One interesting thing that I always surprise people who don't know GitHub all that. Well, as people think, well, it's now Microsoft. right? So it must work the same way as Microsoft. And then, you know, one, like, fact that shows this is all the case. GitHub is still remote first. It started as remote first initially. And it was actually one of the few companies that even before COVID truly remote first. And as I understand, even today, it's remote first. Tell me about this on how you manage 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 off. in the office. So the pre-founders, they actually met in San Francisco. So you could argue that very, very early place was kind of three people in a same place. And that's often how that goes. But yeah, very quickly, GitHub started hiring super fans, you know, people that were interested in GitHub, promoting GitHub, you know, helped drive in the communities. Those people got hired into GitHub,

and they were naturally everywhere in the world. And so very quickly, GitHub moved from a culture that was headquarter-centric to a remote first culture. And that gave us an advantage when the COVID pandemic came, COVID, because we were already used on being on video calls, on using Slack. In fact, I think GitHub is very different than Microsoft when it comes to how the company communicates. My joke always is when I wake up in the morning, because I'm obviously both, I'm a Microsoft executive and I'm a GitHub employee.

When I wake up in the morning, on the GitHub side, I have lots of Slack messages, the DMs, channels to look into, and maybe, you know, a handful of customer emails or emails from you that can not communicate with me in Slack. On the Microsoft side, it's the other way known. I have like dozens of emails to pay attention to and maybe, you know, a few teams messages. And so I think that shows the async part of our culture that has grown over the last 17 years and that is so important. At GitHub, we are using GitHub for everything. And so all employees across all the functions, not just engineering. in product, but HR and comms 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 make changes, for example, to our terms of service. You know, every company-wide announcement is a pull request against the repository that we call the hub that gets published as a GitHub Pages page that is not only internally accessible and that goes throughout identity provider. And so even there, we don't do company-wide emails, almost never. we do an announcement on the hub. There's a link that is posted in the Slack channel,

but then everybody can see and then we take the conversation there. So yeah, today we are a very much remote first company with people all around the world in different time zones. Almost everything is async. Obviously there's meetings and our town hall meetings called the Git together. That has to be in some time zone. And challenge there is that if you do it, you know, adjusting it for the folks in the US, North America and Europe, you're missing out those in Australia and India because that's just

impossible to meet. So we try, you know, different times over here to have one that is in the APEC-friendly time zone, 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 and have family dinner. So many of them actually prefer a later point on the day on the West Coast. So it is later in the evening when maybe everybody's watching TV or the kids are already in bad.

So we're trying to really keep that spirit and it enables us to hire talent, you know, in different places, in different phases of their life. And I think that helps us as a company, you know, to be as agile as possible. Yeah, it is pretty cool to hear because GitHub, I mean, you can use GitHub in many ways, but like one popular way to use it 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. And they're not all in the same place that would never work if an open source project

could only, you know, you could only be 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, those that are paying us money for GitHub Enterprise and copied business, but we're also catering, serving those. open source 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 heard is you have some really kind of fun and interesting internal tools. Some are still here, some are not. One tool that I understand is no longer there was called Haystack, which was an internal exception tracking app. And someone told me it was the best piece of software they've seen. Can you share a little bit about like what past. fun internal tools you have and what kind of internal tools do you still have today, especially for like what engineers use.

If you look back into GitHub's history and we don't have the time to cover it all today, I can recommend if I'm allowed to another podcast, the Acquired podcast. 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 in general, a really good podcast. And they actually mentioned this that in the GitHub, you know, when it started, it 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 infrastructure company. Okay. 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. maybe we come back to this later when we talk about AI. That future might actually come back to some startup. So we had a tool with our own internal video streaming platform.

It was called GitHub.com. And so all the townhorts. Wow. We have, you know, streamed on our own platform. And of course, that no longer exists. I'm using Loon for that. Haystack, you already mentioned, that was exception tracking. And now, keep in mind 15 years ago, there wasn't like established players

in that market that you could use, especially not in the Ruby Railsburg. So, Haystack 1 was one such tool today. It's Centri that we're using for that. Another one was Help, H-A-LP, which was our internal support system, where tickets got routed for folks to work on the ticket, have internal communication. To the right teams. Yeah.

And now this is all in Zendesk and HALP has been retired. But, you know, some of these ideas have led to new startups. Hubbers have, what we call GitHub employees, where Hubbers have taken the idea and maybe they're very, frustrated that we're shutting down their internal passion project have taken that and create the business on it. 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's history as well there. Electron comes to mind, which came out of Adam, which was our editor. Oh, yes. Our desktop app or comment line interfaces are all open source projects. and so everybody can see what we're doing there and can take the ideas. And we mentioned tech tech stack earlier. The CDI, for example, is with Mingo. And so it also gives whoever wants to learn how to build a CRI

can use the GEOP CRI as an example. One thing that keeps surprising me on 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 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 GitHub itself noticed some strange patterns.

They contacted the Heroku security team, who then confirmed it. And this just struck me a little bit striking. Like, hold on, like, how is GitHub having better or very strong security? I'm not going to say better, but in some ways in this case, clearly they got earlier. what is your approach to security? And this was, again, this was not even right now, this was years back. 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 the saying security is priority zero for everybody. Okay. And in fact, our previous CISO, Mike Hanley, introduced this concept. He came from Duo, the two-factor authentication company. He introduced this concept that when the question is asked who he has on the security, team, every hubba raises their hand. And so we institutionalize that security is as part of what we do.

Of course, we want to drive innovation and make customers happy, but we cannot bring in the market if we lose the trust. And of course, the worst day 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. It's so important to companies your code. To an attacker 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 in a voice that take care of security from multiple angles. One is of course, private intelligence, working closely with the Microsoft security team,

the so-called Cyber Defense Operations Center, and those folks that look into, you know, finding security vulnerabilities, that teaming, not only for, you know, the traditional software they're willing, but also for the AI pieces. And you can imagine, you know, at the scale of GitHub, but even more so at the scale of Microsoft, there's a lot of flat 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, your user ID access is not only the pragmatic engineer repositories, but also those

of, let's say, BMW at Mercedes, that person is very unlikely to exist in the industry, right? Like even 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 you combine it with all the other Microsoft systems. And we also have a security lab where we have a team of research that are hunting for security vulnerabilities using our own security products like CodeQL, which is query language that you can use to find variances, like variations of existing. code flaws, you know, code vulnerabilities. It tries to find those in open source projects and then we post them to the open source maintainer in a

responsible way, helping them to fix those in the meantime of the disclosure, hopefully the buck is already fixed. So we are doing a lot of that. We are 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 to our culture, to not have secrets and

source code. In fact, you're blocking all the pushes and... Exactly. I guess open source might help here. Your big focus on open source. But you mentioned 150 people working on security as context. How many people or engineers are in GitHub roughly these days? Yeah. So get up all up is about 3,000 employees. About half or so are in what I would call engineering product design or EPD. So that's about 10% if I just look at the security versus engineering. It's roughly a hundred percent of their engineering function. And

then if you look at just engineers, I see engineers it's a little bit under a thousand that work and builds off. And then it's, of course, managers and product managers and technical program managers, designers and all of them. One interesting thing I've heard from a current GIFT employee is you are starting to look into hiring junior developers, developers, a less experience, which is a little bit different because most of the industry,

we don't hear this. Why are you deciding on this? And I'm 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 in the second day keynote. day as well. And in fact, just on Monday, our intern class for the summer started, we have three groups that start on different days and go through their internship. So those are very early

in career folks that often, oh, not often, that still go to college or university. And this is a program that we institutionalized after the pandemic was over and you could bring people back in person. Because obviously, or half in person, where they at least have, you know, a way to meet with folks at our San Francisco headquarters or here in the Pacific Northwest or else in the world. And so we have an interim program and often, you know, these interns get a full-time offer at the end of the internship or maybe they come back for a second year. And so it's, A, lovely to see that, you know, those folks that bring fresh ideas, a great amount of energy, you know, the latest learnings from college and university.

And often, you know, a different, you know, diverse background, into the company and and you know come in and often you know the folks you know that are younger in Korea bring a new perspective to the team and say here this is you know why don't we try this or I want to incubate this idea and so we are excited about having this kind of like both junior and senior population in the company and it's not only twin engineering you know it's the same in if you look into sales or into marketing obviously the way you know marketing works today is very different than it was, you know, five, ten years ago when the press, you know, traditional media played a much bigger role. Today, you've got to be, you know,

in a podcast and you have to be on YouTube and TikTok and everything. Just like today, but, you know, you see more and more of that happening. And of course, you know, the, when you hire people earlier in Korea, they give you those ideas. They give you that input. And you know how it is? you talk to a lot people in companies. There's always a debate. There's always a debate between those that are defending how we've always done it in a 50-year-old company like Microsoft that obviously exists. And those that come in in and say, hey, nobody in my peer group watches TV anymore or CNBC or whatever. And they're all watching just, you know, three-minute videos on TikTok.

And so I think that's really important. And then we're trying to have, you know, a nice balance between, you know, in Korea engineers, senior engineers, we have a number of distinguished engineers and they all contributed back to our planet. No, I love it because like when I, when I worked both as an engineering manager or as an engineer, having an intern, it's just like boosted morale. Like we were so much more enthusiastic. I'm not going to say that we necessarily did more work.

I think we might have, but we got fresh ideas. And it's just so rewarding looking back at those interns. You know, I now see them many, many years later. Some are now principal engineers. some are CTOs. But the one question that a lot of people who are maybe less technical than UN who have not seen the benefit of internships, they're thinking like, oh, I'm hearing all these AI things, including Microsoft is saying it's so efficient, you know, they're now talking

about AI colleagues on the keynote. Why? And now this is not Microsoft people, but we're hearing people at Google say like, oh, it's now at a level of a junior engineer. And they're thinking, hmm, maybe let's hold off on hiring new grabs because they're telling us, 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 maybe not as informed? Because clearly you've decided it makes sense, and this thing doesn't apply, but their thinking is real. I think that's backwards in many ways. I think actually folks that go to high school now or to college or even kids earlier in their education, they get to use AI much faster. And they get it because they are taking, you know,

taking this with an open mind. They don't have to, this is how we always done it. Don't touch, never touch the running system. They haven't been in an experience where some change that was applied, you know, from upper management or from the engineers themselves has led to, you know, a big outage and things like that. So they're more open-minded. You, you know, you kind of see that when you look at media, as we already talked about,

like kids are much more open to just scoring through shorts and consuming the content they'd like to consume while, you know, when you and I were a child. He had linear TV and you got to watch on the living room TV, what your mom and dad decided is on tonight, right? And so they have much more freedom. And I think this will lead to ultimately junior engineers coming or interns coming into the companies and thinking in like prompting skills, you know, 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 my own project, on my own app. So you get a lot of good, new ideas and outside perspective that is ultimately crucial to compete in the market. And I think vice versa, you know, these interns then go back into college and they have worked on something real. I remember mine time at university, I always have the feeling I've got to get out in the industry and learn how it's actually done because while, you know, 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 code base. becoming an engineer company means you're working on somebody else's code, often now, you know, GitHub 17 years old code, and you have to follow up on

decisions about other people made. And that's not how you learn coding 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 give back to those that in the future become GitHub customers. 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 new people. This is a silly way to think about it. I talked with the product manager recently, and I just had a deja vu when you said it. This product manager was saying, she was saying,

this is while we were doing the Gen Z research about the latest generation. She said, I love Gen Z. She's like, for years as a product manager, I'm sitting in front of engineers telling them, oh, you know, good 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, and she's like, I love it. Like they, so 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 software engineers. Gen Z is already too old, I think, to some degree. Because Gen B, I think starts 1980 or something, the millennials, Gen Alpha, right? Like the 60 years old are coding today.

And so that's Gen Alpha or, you know, soon, whatever, the Gen Beta, I guess is the next one. And so, but you're right. You're getting folks that didn't learn to code on a Commodore 64 or a PC that have a lot of low-level thinking, but also learned in a different environment than those that grew up with smartphones that grew up with being always connected. They just have just from an expectation perspective. They're looking at this often systems problem they're trying to solve with a different perspective. Yeah, I wonder just like a silly thing. Would you rather hire an engineer with the same years of experience of like someone who has, you know, like has traditional coding and learned in university or same years old? Yeah.

You learned a university and did some university projects or this engineer or this, this fresh grad who did the university, but they actually have before that five years of building programs and Roblox and they actually built this like 100 person thing. It's like the skills that that person brings and the mindset, you know, the way they think about things. And there's a third group and there's lots of folks in. at Microsoft and GitHub that don't have a formal university education. And either dropped out in a event, that goes back to the earlier discussion about being a remote first company. You hire people because they're passionate of the product. You hire people because they have a green contribution graph on their GitHub profile.

Because they have shown they contributed back to the Ruby and Rails codebase to the Git, you know, open source code base where, you know, at GitHub we traditionally have employee folks that are spending a lot of time on maintaining Git together with the open source community. So I think a lot, you know, what actually plays a word to us is that folks have shown the right mindset to join GitHub. If you don't have a green contribution graph on your GitHub profile, that I think matters more to us than whether you have five years at one company and five. A lot of the company, of course, we take people to an interview loop. And I think increasingly we're thinking about how to we leverage AI within the interview loop. there's nothing wrong about that from my perspective.

In fact, I would say if you want to get a job in a tech company very soon, you're going to be asked to show your prompting skills, your co-pilot skills, if you will, and how you use something like agent mode or the coding agent that we introduced this week to get the exercise done, you know, to basically, because the goal of the future engineers no longer to write it off from scratch. And the goal is to, you know, combine their prompting skills and agent, open source libraries, to getting that problem solve much faster than they could have done twice three years ago.

So with that, these were some of the, like, a bunch of interesting facts. I wanted to talk about the past and then later the present and the future of GitHub starting with the past. So Git, I did a podcast episode with Linux kernel maintainer, Greg K-H, and he told the story about how Git was created in 2005.

In fact, recently there's a podcast with a GitHub, a staff engineer at GitHub interviewed Linus Tor Worlds. In 2005, Linux Torwords got frustrated with source control for the Linux project specifically. There were some commercial things. We can see history. He sat down in 10 days. He wrote GIT, which was obviously open source. It was meant for Linux only, but they released it.

And it turns out it's pretty good. GitHub was founded in, I believe, 2008. Can you tell me about these early days? What happened then? What did you understand from talking with the early founders? The first commit was October 2007. So it was about two years after late. you know, said, done Git, right?

And then, yeah, October 2007 to, I believe, February 2008 is when they started beta testing it with folks in the Ruby O'Reilly community. And then April is when the public version of GitHub launched. So it was really fast as well, you know, October to April, 35, six months. You know, if you go back, you know, to the history books, it's Chris and Tom, Tom Preston Warner and Chris Warnstrad meeting in a bar, as I remembered. and having seen Git and figuring out that there isn't a place where you can roast your open source repositories

and your private repositories together. There was obviously things like SourceForge, which was the most popular open source platform back then, but also, you know, painful to use. I think that's fair to say, like those that I had a couple of projects on SOSTRAD as well. It was kind of designed for a different era of the VAT and didn't make the jump. in that mode ultimately, you know,

became known as Web 2.0 or Cloud Native. And so I think the idea was, okay, Git is here, Git is amazing, but I want to host it without, you know, setting up a server and installing, you know, the backend and managing, you know, SSH access. And so they started building around that idea. What always made GitHub GitHub is that they put the developers first.

Like if you go on the VABEC machine and look at the first, you know, GitHub homepage, page, it isn't very fancy. It looks like a commit log. It's a very short announcement of, hey, you know, we ship this new feature, try it out, let us know what you think. The story about our logo, what is now known as the Octocat, you know, is a funny one. And I learned that actually from the Acquired Podcasts because they learned from the Twitter founders

how they get their logo and they bought it on some stock graphic page from a British designer, I believe. And so they looked, you know, for other graphics that the same designer, had done and bought, you know, this hybrid of an octopus and a cat and made that the logo, right? So there was a lot of, you know, as a bootstraff startup, that's scrappy, that has a cool technology that might, you know, become the next, the future of version control. And then they built what is now known as cloud native, but a cloud native company. And, and yeah, it grew fast.

And back in the day, probably the product was the fastest product market fit. Nowadays, you know, there's other companies that have both similar. It's a different time. It's a different time now. And I think it was unheard of how quickly it spread like wildfire. I was in 2008 still working in the automotive industry. I was at Bosch. So I didn't use GitHub in the first year.

And then I quit Bosch at the end of 2008, not because of GitHub, but because of the iPhone SDK. And it became, you know, it's a... And ISV building apps for German companies. And so I created, I think, my GitHub account in early 2009. We can look it up, I think March or April 2009. And then I was at the Ruby and Rails conference in Las Vegas in 2009. And so Chris was dressed giving a talk about GitHub and what they are up to. And that's I would say when I became a GitHub fan.

And when I started using GitHub in my projects. But until that point, you would use some help self-house a tool, you know, installed it on some root server or maybe you already. had the cloud and maintain all that yourself. And ever since, people just, you know, log in with GitHub and create repo. Yeah, when I look through the history of just the things that I could find, what struck me as like, so like as the first commitment was in 2007 and 2008 the service was launched. I think you said March or something like that, April, sorry.

And already in 2008, Reddit, Yahoo, Twitter, and Facebook already onboarded. Facebook was surprising to me because I knew they used Mercurial, but apparently to use it for their open source. things and 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 find. Why do you think it was so popular? Like, what was the reason? Was it open source? Was it?

Because Git wasn't even like back, we're talking to 2008-2009. Like now we know Git is great and it works. But back then, this was not clear. There was everyone was using SVN. I remember at the time. And Microsoft had their own really heavily invested in TFS, Team Foundation server. Why do you think this product market fit just hits so bad? And devs were like, yeah, GitHub is a place to be.

Git, you know, solve the pain point that we had with all these other version control systems. You know, the version TFS, you know, had his own version control until much data when they added Git support. Yes. We're painful to use. And we're painful to use, especially when you had multiple teams working together within the same code base.

Git bought this concept of you have the full depository. on your machines. You can switch from one branch to another even without having an internet connection. And you did always everything on your computer so you could make changes to multiple branches and then push upstream or shared with the coworkers. And in some ways, GitHub, I think,

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

So I think that played a big role. You have had a new version control system that people were intrinsically motivated to try out because they were frustrated with using some versions. or even CPS, you know, and something like that. And just wanted something new to solve that problem. And then it was just easy to shoot an account and try it out. And, you know, even user interfaces like browsing the repo, clicking 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 for a full-plate-to-load. GitHub invented the pull request, you know, this notion of that you can fork a repo.

make your modifications. If you like to keep your fork, you can just do that. That's totally cool. Or you can send a pull request back, so you're asking the other maintainer to merge in your changes before that diff files, Vex, changed. 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 Augman's new remote agent, queue apparel tasks like buck fixes, features and refactures, 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 VScode JetBrains, Android Studio, or even VIM. Don't hire an AI for vibes. Get the agent that knows you and your code-based best. start your 14-day free trial at Augmentcode.com slash pragmatic. Well, I think this is one of the biggest thing that people miss, as I understood, like understanding. So, like, Linistero or design Git, and a lot of GitHub or the Git functionality comes from there. But the Linux workflow was email-based. So actually, in Git there is a command.

I don't remember the exact command where I think it's something email, where you send an email with your changes bundled, which your Git changes bundled. And that's how Linux works. They just do email. And GitHub does not do this. Indeed, GitHub invented the pull request, which is a big difference between even today how Linux users get 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 to Gitra. Pretty early. It definitely wasn't there on day one. It came sometime later.

We can look it up and add to show notes. But it was a new thing at the time. And I think it's ultimately liberating. for software developers and where you send a pool 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 they want to pick it up they can just jump over to your fork and keep using it there and so you see you know see a lot of that also happening that people just keep their forks independent because they want to they don't want to have the obligation to engage with the main project like I have a bunch of forks

where I made some modification for my own hobby project. I don't see a big reason that that needs to go back into the main branch. Some of that might be just with packery as well. And so it makes it much easier for developers that want to collaborate to collaborate with each other. And for the others, it democratizes how they engage with open source, how they learn from it, how they mix and match and so on. So what kind of a gathering if I put it together, like open source was clearly one thing, this new collaborative workflow,

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

So even if GitHub is offline, 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's just, again, if it's just like a 30 second outage or a one minute one, again, not advocating for it. But you might not even notice because you're just like doing your local things. So I think as a 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, sorry, not GitHub per se, but for open source, it was always free, right? It was always free for open source. And you might say GitHub invented a version of the three new model that is not.

ad base where traditionally freemium is ad base. Yes. The free users get something for free with advertisement and then the paid users 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. GetHup growing and then when you wanted private repositories you had to pay for them.

Shortly after the acquisition early 2019, we changed that and instead of paying for private repositories. We actually made private repositories free as well. Because we had a lot of individual developers giving us feedback, especially when you travel around the world for an American, $4 a month might not be a lot, but for somebody in a different country that is much more money relative to their income.

And so we have private repositories free, and today we charge for what you could call enterprise features, like single sign-on or branch protection, things that a student or a 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 have myself a pull request.

Then I have to review my own code. I just merge, push into main branch, and that's cool. And so, but yeah, GitHub innovated in the business model space as well. And, you know, you mentioned that the scenarios where it's helpful to use GitHub or Git on your local machine. In 2007, 2008, flights didn't have Wi-Fi, at least in my memory. I couldn't Wi-Fi wasn't

That's very recent 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 For quite a while And being able to commit into the repository

There wasn't you know Subversion didn't have a push You would always commit into the upstream Change branches You know roll back All these operations that are now natural With Git there weren't natural in 2007, 2008.

So it gets get up started off. It starts to get real big traction, 2008, 2009, 2010. The next big kind of mouse on, I remember, from a developer's perspective, is until then, to use GitHub, you could use the web version and you use the local command line interface. You just learned all the commands.

You know, it looks about, like, the easy ones are easy, and then, like, cherry picking and all that. I was always confused by that. And then in around 2014, was the first time that GitHub actually released desktop applications, but not only did it release desktop applications, it actually released the Atom text editor,

which I loved. I use it for so long. It was a lightweight editor. It released the electron framework, which powered Atom, and then GitHub desktop in 2014-2015. Why do you think GitHub waited that long to have these desktop applications? What was the goal with Atom? And how did this help? Did it actually help, like, get more people who just liked

a nice user interface and were not the command types. I don't know the history of all these apps. My suspicion is that when you say waited this long, I'd make the counter argument, how long is long for a startup to move from a core product, to having multiple other products that may or may not become a distraction. I think each of those solved a specific problems that the team saw. Adam came out, you know, I think a year or so before VES code launched.

And so clearly the time was vibe, you know, for a new generation of IDEs, of both of them were open source, you know, for the acquisition, they both ended in the same company and then ought to be made the decision to continue our journey on BS code and retire at him. 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 and you wouldn't have a backlog. You would have the... So back then, really, there were no managers.

Well, there was obviously a CEO. and like a little bit, but that was very flat. 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 to learn how to make an espresso. And that was literally one of the onboarding videos. And, you know, they can have some musical future. Yeah.

And you got told, you know, pick something that you're interested in. And that natural leads, you know, to develop. was picking things that they want to solve for themselves, that they care about. And so Adam was actually, you know, Chris Wonstrat, the CEO at the time, and then for most of Ked-Up's journey until the acquisition, was one of the, you know, core maintainers of the Allen project. Wow. And so I think a lot of that was about passion.

CEO being a core maintainer. A lot of that was about the passion of the people working there. I don't know exactly the history of desktop, but my assumption there would be that they saw a need to expand the people that can use GitHub without knowing all the intricacies of Git. In many ways, the GitHub user interface on GitHub.com also serve that purpose. If you think, for example, about blame views,

blame on GitHub.com is just picking a button. See who will modify which file, which line in the file. But if you do get blame on the comment line, it's much harder to figure out what's what, especially if you don't know a lot about software development. So it's all about growing the user base and expanding the people that get utility out of people. I'll say that I use GitHub desktop a lot. I mean, never 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 I appreciate it when it came out. I barely even use it. But I use, you know, the GitHub integration and VAS code a lot for the same purpose. And so there's, and I think even that, you know, Git as a protocol, both SSH access and HTTP access, which also, by the way, wasn't something that was very prevalent in the early days of GitHub and is now much more used because easier to access

through HTTP than through SSH. I think all of these pieces, you know, were ultimately helping, you know, to create the developer experience that we now consider normal, but by no means was normal 20 years ago. So then we're getting to the Microsoft acquisition. So we've now passed 2015. It's now 2016 or so. You were in the inside of Microsoft. You were already working there.

How did this come about? What was Microsoft thinking? Why was even Microsoft interested in GitHub? And then how did the purchase go from your perspective? It was 2018, early 2018, that back then at Friedman, my boss within Microsoft CDP in the developer division during mobile developer tools, Nat came from Zamerin,

so I had joined Microsoft himself for an acquisition. I had joined through the Hockey App acquisition. So we were like a bit of a, you know, outside in team within Microsoft. There's lots of people coming from acquired companies, lots of, you know, cloud native experience, a non-traditional stack for Microsoft. At the same time, also Microsoft had changed.

It was now about four years since Satya Naderda had come the CEO. So, Satya had very early on embraced open source, you know, then Visc code was launched. Dotnet became open source. So a number of steps had happened where Microsoft changed its fundamental position on how it views open source, how it views, you know, the stack and where the future is going. You may remember this part of the strategy back then was Cloud First, Mobile First. And, you know, in many ways, that is still true today. not say, no longer saying those two things. You know, if you think about how you interact with Microsoft products today,

they are, you know, on every device, regardless of who makes the device, what upbringing. This was not obvious then because it was still Windows first. It was still a feeling that Microsoft is only Windows. And yeah, and I heard this was said everywhere, and I think outside of Microsoft, we were skeptical, honestly. But, you know, and obviously the cloud stack, the compute stack that Microsoft offers today, not only to its own products, but.

to any company in the industry, really. One thing I learned early in my journey at Microsoft is that when you're a small startup, you consider other companies in the space competitors and they, quote unquote, the enemy. At Microsoft, competitors are at the same time also customers and often partners. We are providing, you know, if you take, for example,

Azure A Foundry, our inference stack for large English models, we're providing those not only to our own co-pilators, we're providing those to many other companies that may directly or indirectly compete with GitHub or with other Microsoft products. And so 2018, the worldview in Microsoft had changed. I think the reputation started to change. We at Microsoft started to believe that we could pull off an acquisition like GitHub where you make GitHub part of Microsoft and not lose all the open source maintainers because Microsoft, you know, is not going to be what's steward of GitHub. And we said 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

acquisitions. We had kind of like two examples of acquisitions where we kept the brand and the platform independent. Even today, when you go to the LinkedIn homepage, you don't see a lot of Microsoft there. Seven years after the GitHub acquisition, there's no Microsoft on the GitHub homepage unless you're using. Entra ID, you know, as your single sign-on provider, or of course, we have blog posts where we talk about, you know, co-pilot and the Microsoft FI model and then things like that. And Minecraft is,

you know, many kids, I think, realized much later, you know, in their childhood that one of their favorite games is actually the same company that also produces the operating system and the professional network and GitHub, right? But part of, you know, when you look at those two acquisitions and then you see GitHub, 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. First product was basic for the Altair. And here at the conference center, I don't know if you had a 1975 experience

where you work on a fake Altair and pass some coding tests. Then that was basic for the Apple 2 and obviously Visual Studio in 1990s. I think my first version of Visual Studio was VisualC1.0 came with a book and then had Visual J, which was like Microsoft's Java clone. And then I bought like a full-scale Visual Studio 7 for way too much money back then. At least, you know, for where I was as a high school student, right? Obviously, in today's world, selling an IDE at a one-time price would be something that has no, has the market fit anymore. You know, Microsoft lacked access to the open source ecosystem. It didn't have, you know, the same attraction to cloud native developers.

It was just being not trendy at all. Yeah. And it was important from a business perspective to have that ecosystem. It was important for us, you know, to put developers first again. And so that was actually the first principle of three principles. And we believe we can re-accelerate GitHub. Because GitHub in 2018 had a bit of the reputation of not being able to innovate anymore for various reasons. And we can talk about that as more in detail.

But it was really important to think about its acquisition, not a Microsoft gets a lot out of GitHub, but Microsoft is willing to invest into GitHub. You know, GitHub in 2018 at the time to start the conversation with them was about 700 employees all up. And we mentioned earlier, it's now over 3,000 employees. So that investment surely has happened. And we have leveraged a lot of the Microsoft stack and copilot comes to mind where we're using Azure AI foundry and the relationship with OpenEI to build our AI cogeneration 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.

And we announced last July. So about a year ago now that revenue is grown to over $2 billion annual recurring revenue run. rate and that keeps growing and we're very happy with these business results and contributing back to Microsoft's earnings. But in that order, right, developers first making great developer products, accelerate GitHub and then eventually GitHub, you know, accelerating Microsoft and giving back both on the product side but co-pilot or on the revenue side with our results. But I think this is last thing is just worth emphasizing in the sense that I think as a developer,

I really like that I like using products where I know they'll be around. So you're saying that GitHub's revenue has been consistently going up more enterprises, more companies, more teams paying for professional use cases, right, to help their work. I remember correctly 2017 was the last official revenue announcement that you have made before the acquisition. And they were at about 200 million run rate. And they announced at that time that they're looking for new CEOs. So Chris was ready to step down. And then that ultimately resulted in the acquisition then in June 2018 through an acquisition. and new CEO, NetFeedman.

But like 2017, you know, 200 million to 2024 in seven years, revenue went up Factor 10. Yeah. Well, this 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. You know, like such an adult report to shareholders. It's good to know that those things are going well as well.

Well, and I think, you know, for a long time developer tools were not seen as a, as a revenue driver in the industry. I think, you know, there were a few examples like companies in JetBrains comes to mind or JFork. There's a bunch of companies that, you know, we're focusing on developer tools. But I think, you know, if we try to turn to back five years or before that, give up, because 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 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 some of the learnings. But it was interesting how Microsoft figured that out. I feel Microsoft is just,

is very good at figuring out this great mix where, again, back then, and I worked at a Hungarian company, we paid about $1,000 per developer in Hungary because it made us so much more productive. So we'll get today I part on this one. But you mentioned something interesting, which I also noticed. So I was looking back, and I remember back when GitHub desktop 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 GitHub sponsors came out, the package registry, co-pilot, code spaces. But what happened there from 2015 to 2020?

It almost felt like from, I'm sure people were working, but from the outside, it just looked like nothing, like barren 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 can have had, especially before the Microsoft acquisition and, you know, for some time after that,

was that the platform had grown so much. And so many people were relying on it being available and not broken. Plus, you know, many developers did that big band and still

are very much involved with the brand. Like the Octocat, you know, in turn of it, we call it Mona. How do you call it? Mona. Mona Lisa, you know, Mona. It is something that is recognized.

You get, you know, 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 happen. I mean, I've been, you know, I had a, you know, on an airplane, the crew member asking about Git happen. I'm like, how do you know GitHub? And she was like, well, I, you know, used that. It was that in college for some, you know, computer science course that I took. And I think if you have something that is so beloved by the space, that also means the expectations are really high.

Like, it's often that, you know, the disappointment is even bigger if you actually care about something. Well, if you don't, you know, give a damn about this thing, then whether it's up or down or whether it's broken, it doesn't really matter to you because you hate it anyway. And so I think those two things combined led to, you know, people really being worried about shipping stuff because you would change something 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 often there's a loud minority yelling on the Internet. And there's a silent majority that are actually fine with the change, but don't say anything. And a small change might lead to an outage. And then you're the one that made three landers of change in your first week and you brought GitHub down.

That's obviously not encouraging in your journey. So I think that created an organization that actually still shipped a lot of things. and what we call staff ship, what Microsoft calls the outputting, so features that landed within the GitHub organization that Hubbers would see when they use. You know, one funny thing is we have even today, as we're using GitHub every day,

I often actually don't know if that feature is available to you because I only see GitHub how a hubber would see it. And there's a way to disable all these features, but how you... Feature reflects, probably. Well, no, I can hide the staff bar and then it disabled the features that you don't see. But how often do you really do that?

And do you then remember that in a conversation that Gurgeng, it doesn't have the feature, but I have it. And I thought it already shipped, but it is actually stated for next week. So I think that, that prepped, you know, a culture where things were internally shipped, but never made it, you know, to public because everybody is worried, is that good enough to ship it? You know, CEO change was in flight. There were a number of cultural issues. And then as we closed the deal and we came in, we made private repos, public, relatively. That was the fast one. Actually, at that universe in 2018, the first version of GitHub Actions was announced.

That was even before the deal closed. But it was, you know, hopefully the folks building it, forgive me, was a bit of a hack built on top of containers in Google Cloud. And we quickly saw from the data that the product wasn't actually meeting the requirements from developers. Many developers wanted full CICD while GitHub Actions originally was designed was. Robflow Automation. And we kept that rope for automation part, but evolved it into what it is now. And over the course of 2019, 2020 sponsors was announced in mid-2019 at the last ever satellite conference in Berlin.

And then COVID came in that wound to kind of like the plans that we had as we came back from it. You know, we were very careful with bringing back universe in a smaller scale. And given that there was still lots of travel distractions. But it took us a while, you know, to get the organization back into a state. where we could both innovate really fast and keep the fundamentals in place, keep security, availability, you know, other things like accessibility, things that you might not actually see have changed because, you know, if everything is working, you don't notice it, but it, you know, created a lot of investment behind the

scenes. So we are feeling good about the pace of innovation that we have today. But yeah, it took us a while to turn the ship around. and even in a team of 700 people that takes a while and certainly about 3,000 people that is something that requires a lot of energy and focus.

I think it's just a good reminder from the outside. A company that is doing great because GitHub, I think all developers can agree from the outside it looked like is doing really good. Like, yeah, you can have some things that you need to work through, right?

And growing too fast is amazing. I think the best problem for any team to have, but it's still a problem, right? That you need to solve and you get through it. Now, co-pilot was the biggest flash that I can remember from the past few years clearly, especially because when it came out, it just felt so early. Did the beta come out in 2022? 21.

21, yes. People came out 21, yeah. Beta came out on 2021 because it was built on an earlier model before Chad GPT launch. It was on, was it on GPT2? No, it was, so GPD3 came out right after the build conference in 2020, which was obviously given the pandemic fully remote. But 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 Open AI of Microsoft Partnership. And we realized together with Open AI that it was able to write decent code in different programming languages and wouldn't not mix up the syntax between Python, Ruby, and JavaScript, which somebody asked me that earlier this week, was my biggest surprise that it can do that even though it doesn't have a compiler built in, right? Like it's not able to validate the code it generates. It doesn't have the syntax.

It just knows it from the training set. And then Open AI fine-tuned a model that was called Codex. Yes. That was specific for these coding scenarios. And so in 2020 and 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 call it, which then, you know, today is known as chat. And those two latter scenarios didn't work well enough. You know, we had a describe code and sometimes it worked and oftentimes it was wrong. You know how it is. When developers see that, that the description is not actually what the code does, you quickly, you know, detract and you get a low net promoter score or whatever you're measuring satisfaction with. But text to code, as in, you know, prompting the model within the editor and ultimately building

auto completion that worked so well that very quickly we saw our internal, you know, Hubbers adopting the tool, giving it really high scores, saying, you know, this is great. I want to keep using this. It's not the typical management says you have to use it and you don't want to. But ultimately, riding, you know, in the early days, 25% of the code in those files that 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 co-pilot in June 2021.

We went into the public preview. And within a few months, 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, because the surprising thing for me is most of us remember the launch of Chad GPT in November 2020. And everything exploded from there. It was the product that made people. go wow inside tech outside tech and a lot of AI startup startup and a lot of actually coding

startups started after that so like in early 20203 however by that time get get up co-pilot was already yeah i think i think it was beta in 2021 right but at 2022 i think it was it became public so it was GA already it was generally available yeah it's generally available in june 22 in which is charging for it for individuals in august 22 and then chat chpt actually had two moments but one of them was not noticed by many. So OpenEI showed at Microsoft Ignite Conference, which is the fall event, showed actually chat chagipt in the keynote.

It wasn't called Chachypti, but they showed like a similar scenario that is what you see now the agent doing, where we ask it to write some code and make modifications of code, and then it launched in late November. And the world changed for us dramatically. For once, because we had a product and market

that was really good for developers. And so our customer conversations shifted from us having to convince customers that AI is actually something they should look into to customers asking us to come talk about how we build co-pilot, how it can help their developers. The first user studies come in. We are the first company comparing a group without co-pilot with a group with co-pilot.

And 55% number is obviously both well-known and often use 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 co-pilot to make you that much faster. But it was a very exciting time.

And then in 2023, we launched a chat, GPD4, bought it into the CLI voice came out, right? A lot of these things feel like they have been around forever, but it's only been a little bit over two years. Totally bit. And then 2023 on a post from GitHub, I'm not sure it was you, so I don't want to message you, but it was written that just as GitHub was founded on Git, today we are re-found.

Yeah. Sorry, so it was you writing it, that Justice Getter was founded on Git. Today, we are refounded on Copilot. This was in 2020-2020, and Co-Pilot was clearly very strong. What has this change meant since an announcement two years? This was a GitHub universe at 2020-3. So in that year, the conference was in early November. It is our biggest event of the year, and it was one of the lines in the keynote and I think in the press release of blog post.

And we talked a lot about the early days of GitHub, right? The GitHub founders did not invent Git, Linux, Talval State. But they realized there's a new technology that changes how developers work, not only to a version the code, but how they collaborate, right? GitHub, if we think about it, GitHub is designed for asynchronous collaboration. of developers. That is what GitHub is really all about. And with co-pilot repeated history, because we didn't invent transformers, we didn't invent large language models. We didn't train GPT, two or three or codecs, but we saw something that changes how developers work. And, you know, if you're honest, we saw an opportunity for ourselves to accelerate. You know, my backlog is endless.

There's lots of GitHub issues in repositories that were filed, where the issue was filed in 24, with customer feedback and, you know, every enterprise seller since then, we haven't 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 a high priority. And you mentioned security issues and availability and all these things are also high priority. When we saw GP3 and then Codex, we saw an opportunity to bring the effort down for all the, for own developers and, of course, every developer on the planet to get more done.

Not that, you know, they actually get to an empty backlog because I don't believe that, because Jarvon's paradox means more ideas will get stuck. 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, you know, has for over 25 years produced IDEs and co-pilot started as an IDE feature. And while GitHub was the developer platform, now those are, you know, the Venn diagram of GitHub and VOS code and NBS is much more overlapping.

We see that here at the conference, and we see that in all-day interaction between GitHub and Deb-Div. And just on build, you know, like two big announcements related to GitHub. One, it was open-sourcing, co-pilot extension. Why did you decide to do that? And also, yeah, so like what's the idea here? Because we have seen open-sourcing with VS code. In fact, open-sourcing V-Vscode gave way to some of the competing editors that are also adopted, you know, windsurf, cursor.

I think there's the smaller ones as well. What is your hope with this move? And why? You know, it feels counterintuitive because co-pilot has kind of been an edge for Microsoft, right? Isn't it funny that 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 the closed source. This is like if you had told me that... Interesting. Yeah, yeah. We would have said you'll have it backwards, buddy. This is true. It's a real like cursing ones for not open source. That's not, you know.

And look, you know, we published VES code in 2015 under the MIT license. So the license allows it. And of course, people can do with the VES code base what they want. That's fair game. And so we're stepping into our footsteps into our own footsteps, footsteps of our last 10 years. And we felt the time is right to bring the co-pilot extension into the main. editor code base, and that means it needs to be open source because we made a promise to the community when we published Visc code that we will keep it open source. You mentioned we have

co-pilot in 2021, 20202. It didn't take long until people reverse engineered the DS code extension at the end of the day JavaScript. We write it in TypeScript, but it's delivered as off-fuscated JavaScript. And so you still can find those blog posts of how we composed the prompt, how long the prompt context window is that we're using adjacent tabs. All that information is already out there, but you couldn't take that information and contribute back or look at the code base, 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 of your 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 we want with it. It ultimately helps the developer community to have that piece of client code available. And, you know, now you're going to ask, or I'm going to ask myself the question, so where's the value generated and aren't we losing all the revenue? And we believe that the ultimate value generation for these AI tools is in the platform, whether it's the computer, inference layer, whether it's the security or control layer, right, enterprise is one control,

what model is enabled, who can use AI, you know, in which project you might use AI, given that you might have signed, you know, legal terms with whoever provided your source could that you're not using certain technology and inference layer, the security layer, and at the collaboration layer, where people collaborate and you see that with human-to-human collaboration and we were going to see that with human to agent collaboration with our new coding agent, we're bringing that agent into the gear platform and we're giving it certain permissions and we are protecting the agent from doing things that you might, you know, allowed for a human, but you're going to control over that when the agent does it.

I do like looking back at a history of Microsoft, I do appreciate that Microsoft has been open always to the idea of being a platform, but a good platform. So, for example, JetBrains, you know, they might disagree with this, but I remember the first time I bought a JetBrains project for $200 a year was this extension called ReSharper. So Microsoft opened up their ID to allow extension points. And JetBrains honestly wrote a way better auto-complete that 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 just really like how Microsoft seems to be keeping this idea of like sometimes opening up the business to others can succeed. Startups can do it. It's better for everyone, especially as for developers. We 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 extension. Given the limitation. But it does have auto completion. It has chat and just this week also we ship agent mode as a preview into the Xcode extension. We have it in the JetBrains extension as well, across all the different Jet Plains IDs. We even bring it to Eclipse, and that is simply you know, including Asian mode. Because if you look into, you know, larger companies, they have developers on all of these.

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 multiple of those. Obviously, if you think about, for example, Artifactory or JFB. Often companies have that in the stack together with GitHub or HashiCorpteroform. And of course, you have a cloud and a key store and a key value store and whatnot. But it is important to have copilot available across all these IE's.

And our export extension is already open source, was open source before this week, because an open source maintainer voted. And then we did a commercial agreement with that open source, maintainer 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 an export extension. And so now we're continuing that journey with Visc code and others. The last question I wanted to touch on. This is agent, agent mode or GitHub agents was also an announcement that the agents are getting more and more autonomous now. As developers,

there is a bit of this fear. There's some not necessarily. Microsoft, but there's this vision of in the future of 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 of 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 look seems like a boring job to be a manager. And then the other thing is what will happen with what could happen with, with software engineering a job? And then you said earlier that you believe this will increase actually, just just recently in public. So what, what is your view on on agents 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 frigging 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. Then you assign a task to them of how they're implementing the task. But even that autonomy is restricted by the MCP service model context protocol that you configure for it. or the tools you allow it to use, or the repository you give it access to, because obviously, as an engineer, it's a human engineer, I can look beyond the one repository boundary and see what has been happening in other depositories,

while the agent needs to get permission to do that, right? So we are definitely far away from full self-driving. 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. Like a compiler is a tool that helps me to not write assembler. It's like I can write a much nicer language. Thank God. But, you know, like I'm sure, you know, when compilers and languages like Basic and others were introduced,

there were also skeptics saying, you know, I'm losing control over the instruction set and the optimizations that I can do in my app is so much faster. And I certainly remember, you know, my Commodore 64 days when there was a lot of, a very active demo scene and you couldn't really have a successful demo, especially as, and I think even nowadays it's this where the size was limited. Back then, for physical limitations, today is artificial, like you're limiting it because do you want to create a challenge, but you could only win those demo challenges if you knew how to do the assembler and you couldn't win that in basic.

So agents will work as one of the tools that have developers have available. It's just like we have compilers, linkers, linters and whatnot. they will pick up tasks that I don't want to do, like writing test cases. I don't know many developers that want to write test cases, and certainly not more than they're already written, right? Unit testing is always a, how many do I write until, I can get away with it when I go into court review? 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 a very subjective thing. Those that try to holistically test all the edge cases, they're never shipping action. valuable software, finding documentation, fixing security vulnerabilities, finding these security vulnerabilities when I didn't see them because I had a long day and I, you know, I have obviously always my own bias that, you know, the code that I'm writing, that does exactly what I wanted to be until you have even something simple, like a pull request description, right? Like, you 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 the checkout flow where I'm like, wait a second, I didn't touch the checkout flow by, why is there now change, right? Because when it describes the code changes, it doesn't have the confirmation bias that you self 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 for agent flows. I think that's what Jessica Dean did in the day two keynote. Well, but not so 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 code base. And we all know that this gets harder, the more open-pill requests you have in different branches that might have merge conflicts by the time you're merging those things. So you've got to understand all that code. You've got to understand all the system is designed. You need to know what the agent did to have the level of confidence, trust, you know, we talked about security, availability, all these things earlier.

Scale. At the end of the day, most companies are for-profit organizations, and even those that are non-profit operating under budget. And so you need the agent to, like, 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're already seeing this paradox because now we have all the AI requirements that come on top of a full

tech engineer does, right? Like no longer just back in the database and infrastructure and content and how the content communicates with the backend. 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 7 per minute. That's 430 million per hour or 10 billion per day.

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 get another result, right? And so if you just take that example, like you've got to have engineering skills. You've got to have developed craft. You need senior people that know how to build large scale systems. You need people that take large complex problems, break them down to smaller problems. Maybe they use AI along the way and say, what's the know, a good, you know, new SQL database,

what's the good infrastructure? How do I do data residency? How do I do GDPR? Their job is going to be break it down to the layer where they now know, now I can sign 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 what engineering is all about. The coding skill will be part of that engineering skill set,

but ultimately, engineering means I can build a really large complex system and then evolve that I need to even larger system, you know, next week in today's world. Love this takeaway, abstractions and being able to take on more complexity. This was a really good conversation. Yeah, awesome. Really great to meet you, Gregory, in person, and looking forward to stay in touch. Thanks very much to 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 dyes from the pragmatic engineer linked in the show notes below. If you enjoy the show, it would mean a lot if you love to the rating on the show on your podcast player. This helps more people discover the show.

Thanks and see you in the next one.