GitHub CEO Thomas Dohmke on Copilot and the Future of Software Development
Gradient Dissent · 10 Jun 2025
Source: https://wandb.ai/site/resources/podcast
Transcript: https://podcasts.opennash.com/shows/gradient-dissent/github-ceo-thomas-dohmke-on-copilot-and-the-future-of-software-development-ed6f75/ (via OpenNash Podcasts, machine-generated)

You're listening to Gradient Dissent, a show about making machine learning work in the real world, and I'm your host, Lukas Biewald. All right, today I'm talking with Thomas, the CEO of GitHub. I've obviously been looking forward to this interview for quite a while. GitHub is one of those products that I've used nearly every day of my professional career for over a decade, and I have a real attachment to it. I was really excited after Microsoft bought GitHub and their UM innovation accelerated.

And it's interesting timing for me because if you haven't heard, uh, Weights and Biases was recently acquired by CoreWeave, and GitHub was one of the analogies that I used in my head of a successful acquisition. So I talk to them and get advice from them actually on camera about how to make an acquisition successful. But we also get to get into how GitHub Copilot works, um, why it's worked so well, where it's weak today, and how they think about the future of coding.

I hope you enjoyed this one. All right, so Thomas, thanks for for joining us. I guess we were just talking before we started recording about UM acquisitions, and you've been on on both sides. Do you have any advice for, uh, me and my team? Post, um, post acquisition of Weights Biases?

I would say, stay, uh, sane, you know, get some sleep in between, you know, the craziness that is that process. Um, as you mentioned, you know, I've been, you know, both the seller of of a startup. I was the co founder of a company called Hockey app, um, that we sold to Microsoft in late 2014. And and so I know what that was like, um, with my team going through that acquisition, uh, until the last moment, we were just setting, uh, before the pod started that, and then everything was fine.

We were sitting at dinner and it was an emptiness surrounding us. Uh, like, you you feel like you should be more happy than you are in that moment. Um, a, and that it, you know, takes some time to actually process that everything is now changing in your life. Um, I've been, you know, obviously involved in the GitHub deal, uh, in 2018, uh, mostly behind the scenes. Um, um, and then, uh. After we had acquired GitHub, we bought, I think, six or seven, um, small to medium sized companies.

And I remember a number of conversations with the founder CEOs of the company we were acquiring, and um, the emotions that that went through them. And and I could empathize with them and and understand where they're coming from, kind of like relating back to my own experience. So it is, it is something, you know, f for founder, CEO, um, or founder team to sell their company. Um, uh, an experience in life that, uh, is probably, you know, hard to compare to anything else.

Well, I wonder if it was like this for you. But but you know, one thing about this transaction is, you know, I couldn't talk about it with anyone for for quite a long time. And it was also kind of very slow where, you know, kind of it felt done. But then we're kind of working through lots of details, then there's like lots of regulatory approvals, so you know, it feels, um, honestly to me, like very anticlimactic.

And also I'm kind of like, okay, I'd I'd actually been wanting to, like, you know, just kind of like, work on the future stuff, um, you know, for a long time, but but couldn't so. Um, it felt, uh, very unmomentous, I guess, to me. But it probably felt like a much bigger deal to all the people around me who are kind of just learning about it. And yeah, going through the that well, and by change.

and by, you can't, w during that phase where you cannot tell people that this is happening. Uh, then you also have to. You're almost forced into, you know, lying to a certain degree or planning for a future that you know will no longer happen. Where you may commit, you know, to, uh, you know, an offsite or a customer event, or, and then, you know, okay. But by the time that actually, uh, would materialize, there's like a like a the most kiddo about me, uh, by the time that that actually materializes.

Um, uh, the world will look look fundamentally different. Um, and then you tell people, and of course you, you deal with a lot of uncertainty and doubt. And I'm sure you have gotten the question, Lucas, you know what's going to be my role in the future company? what is going to be your role, you know? And people? The tendency is that they they doubt what you're saying is actually the truth. Um, given that, as soon as you know the the these deals are closed, uh, and you, you moved, you know, into the new office, either virtually or in reality.

Um, uh, you realize that the grass isn't always greener on the other side. And there's, you know, as as many problems, often in the in the buyer company than than they ran the seller company. So, yeah, um, I hope everything works works smoothly for for you, for you and your team. And um, uh, next time, maybe we talk about the the life after and uh, what it's now like after everything is fully closed and integrated and so on.

Yeah, no, I I appreciate it. It's a it's a very unfamiliar experience for me, honestly, because I've I've spent, um, you know, most of my career running companies. And I didn't think I was like, attached to the, you know, CEO title particularly. But it's, um, you know, one thing. One big, like, big difference actually is like, you know, I can't like, really guarantee people that I can control, you know what, what happens. Like, it's a very different kind of conversation.

I feel a lot more empathy for the managers that have worked for me, uh, in the past. Now. I actually have another experience where, you know, like, I, you know, I think that's I. I feel like it's. It's really making more sense to me why people want so much clarity from their their leaders. And and, you know, fast decision making and things. I actually think it will make me a better CEO to be on the other side of this.

Uh, you know, for a period of time,

yeah. Naturally, you lost a little bit of control, right? Because one way or another, now you have, uh, a manager above you for sure. Yeah, or or a set of managers, and and and the board and and whatnot. And uh, while people might trust you, um, they haven't got to the point yet where they have seen you. Reacting to instruction, direction, you know, um, command, if you will, from, uh, from your management chain. And and that certainly is a different life.

And I think I, you know, in many ways, that is what is so fundamentally different between being a leader in a medium sized to to a large company. Um, you know, including me as GitHub CEO, because obviously we are part of Microsoft, and, uh, I have a management chain, uh, um, um, uh, within that construct. And and deal, you know, with the Microsoft finance team and HR and and all these kind of things. With us being a founder CEO, where, uh, you live with a different uncertainty, uh, uh, what, what?

What t does tomorrow look like? or what does, uh, you know, the company look like in a year? Uh, but there's other than your board, if you have one, uh, there isn't really anyone, uh, telling you what to do. And I, I, I always felt like, as a startup founder, that is the ultimate freedom. Um, uh, that you can have, even more so if you have a bootstrap startup where there isn't really a board or or venture capitalists or investors or anything like that.

Um, but it's not that, you know, you, you wake up every morning and everything is a happy place, uh, and even more so when you have a product in market. And now you have customers and they have support issues. And they, I'm sure you have seen that that they email you and says, Hey, your team hasn't gotten back to me. And I'm really frustrated and I'm paying you so much money. And then you're like, Oh, okay, I.

I was planning to have a night, nice night with my family, and now I'm dealing with this customer escalation, right? So,

yeah, that is the job. Um, I'm curious, actually, you know, uh, we're immediately going off script. I, I love it, but, you know, I mean, I feel like GitHub, actually, from the outside, feels like one of the most successful acquisitions that I can even, um, think of. I mean, this is such a softball question, I guess. But what do you, what do you think made, uh, made the GitHub acquisition so successful, and was it a success?

Was it all? was it all that you, um, hoped, you know, having, like, kind of thought about it before it happened, and now, um, running it?

yeah, I mean, I would say the if you ask around in in Microsoft leadership, the answer would clearly be yes. This was one of our most successful acquisitions. Um, I think the other two that are always, you know, listed in a similar realm are LinkedIn, uh, which has, you know, very similar integration. Mo model where they have a certain level of independence. Um, Ryan Roslansky is the CEO, you know, they have their own offices, their own brand.

If you go to LinkedIn. com, there isn't much Microsoft in in terms of branding or anything like that. Um, and it's very much perceived as as an independent platform, um, within the Microsoft ecosystem, the other one, um, is Minecraft, um, which was a very different acquisition, um, also how it started and and how it went, went through, um, but similarly, right, the brand is is very independent. Um, uh, most kids playing Minecraft, that's probably their 1st touchpoint, uh, with the Microsoft ecosystem, unless they're playing Minecraft on on a PC.

But if you know if they have it on their iPhone or Android phone, um, or on a tablet that they're getting handed from their parents, it's it's not even that. Um, and so you have these three brands and GitHub kind of sits in the middle. Um, uh, it is, it is more of an enterprise brand. Um, right, that's where, uh, you know, we make most of our revenue. Um, but at the same time, it has this recog recognition from from consumers.

Like my, my favorite example is, um, when I go to the Lego store, uh, uh, I in the Pacific Northwest, um, nat. Naturally, a lot of the employees there are students, uh, and so they know what GitHub is, um, and so they they are as much a fan of, you know, the company that I'm running as I am an a Lego fan. Um, and um, and and you don't get that. M with many other enterprise companies, um.

And and part of that is obviously that GitHub is, you know, uh, both, you know, an open source company, uh, hosting all these open source projects, um, and a company that sells, uh, uh, enterprise products. Um, to many of the companies that wanna work like an open source project, wanna emulate a lot of these practices. Or they're sitting, you know, somewhere in the middle that they are both providing open source. Uh, like, like your, your company a and and have, you know, um, a a part of the stack that is that is open source.

Um, so yeah, we are very happy about, um, the acquisition, you know, revenue grow has grown. We announced, um, uh, in July of uh, 2024, uh, over 2 billion run rate, um, and you can look up yourself what the rumors were back in 2018. I don't think there's an officially published number, but it's, you know, significantly up. Um, acquisitions often have scorecards, so the scorecard, um, on on the revenue side, is, uh, more than green, uh, the scorecard on the on the growth side is more than green.

And um, uh, with Copilot, you know, post acquisition, um, and um, uh, with the open ai investment, uh, in 2019, uh, you know, we. We kind of materialized the best of Microsoft with its cloud and experience in responsible AI, and and all these kind of pieces, the best of GitHub with with our developer first approach and the open ai partnership. That gave us access to, uh, first GPT 3 and then the Codex model, uh, to to build, you know, uh, like the original copilot, GitHub copilot.

Okay, but so why is it so green? is it? is it the open AI? Um, connection? Cause? I feel like even before that, like, one thing that I noticed from the outside is that, um, it seemed like the development actually accelerated post acquisition like that. That was my impression. Um, as a user, I don't know if it felt like that on the inside, but it. But yeah, like, what, what happened there?

As part of the deal, um, you know, we actually defined, uh, the three, um, acquisition principles, or integration principles, um, and the 1st one was. And I think that's really part of our success is that, uh, above everything, we put the developer 1st. Um, and in many ways, you could argue GitHub has always done that, uh, since it was founded, it was founded, you know, by, uh, hackers, um, that, you know, had discovered that git is, you know, cool.

And and Thomas, did you know, Chris,

actually did I tell you, you know, they, God, they work for me, so I'm actually, I'm actually like, user well, number seven of GitHub or something. I don't know if I ever mentioned that. Um,

I don't think you did. yeah, yeah, yeah, it's Yeah,

funny. I I was like there when they when they started. It was on my my co founder's couch, actually, that they were, they were hatching so yeah, Chris the idea. Tom, uh, PJ, Yeah, and then, uh, Scott, yeah, yeah,

um, as as kind of like the 4th, uh, late founder, right? Like they were. It's, uh, really, actually fun to go to the Wayback machine and and look at, uh, what GitHub. com looked like in the very early days. Um, I think many folks have a much more evolved picture in their head of what the UI looked like and and what the front page looked like. But the reality was that it was almost like a commit log, with like, single line updates from from Chris.

I think, mostly saying, Yep, we have this new feature, check it out. That was all that was there on the front page, and the UI, you know, looked, looked, uh, much more, you know, uh uh, basic, uh, than it is today. And um, I think many people kinda like, have this 20, I would say 2015, 2016 evolution, uh, in their head, as as as that was what GitHub was always like. Uh, but obviously in the early days, uh, of, uh, of this cloud native, you know, uh, web 2.0, or whatever you wanna call that, that, um, wave of of startups, um, uh, look, look much more, much more simple, um, than today.

And so we put developers 1st, right? And so, you know, whether we write blog posts, whether we build products, we have all internal processes. Everybody at GitHub, across every roles, you know, HR, finance, legal, um, product management, they're all using GitHub every single day. Um, I think the only other tool that we're using as much as GitHub is Slack. Um, that's the two tools as a remote first company, uh, that that we're using very intensely, uh, assively, and um, but that helps us, you know, to, uh, to evolve the product.

The 2nd principle was, and that, I think, is the mistake in many acquisitions. Um, um, we thought about how is Microsoft accelerating GitHub, right? But I think in many ex acquisitions, it's the other way around. You think about how the you find synergies between the company that you bought and the the company that's buying, uh, you, and you're looking at how is the the startup accelerating the big company. And we thought about how is Microsoft accelerating GitHub.

And I think that's where you see things like GitHub Actions, which was, you know, um, uh, an effort where we took, uh, an existing technology, um, out of Azure DevOps, um, uh, called Azure pipelines, um, uh, and and brought that into into GitHub. And it looks like GitHub, and you know, it has a different format of defining these workflows. Um, uh, but the underlying technology and part of the team, uh, came came over in in early 2019 to to to build what is today GitHub Actions.

And so you can kinda like track that progress. Um, in part of, you know, the success, uh, was that we very quickly figured out how can we do joint sales with the Microsoft sales team around the world. Uh, which gave us coverage that, uh, in GitHub, you know, at the time of the acquisition, was about 800 employees could could never have, um, uh, and that helped us to accelerate. But really, Microsoft invested into GitHub to let it grow, and I think that is crucial.

And in many ways, you know, it's almost like a D round or E round or whatever, series E, uh, uh, uh, of of an investment. Um, and then last, the last principle, so the 3rd one was, how does GitHub accelerate Microsoft? And we always said that comes later, uh, and we will think about that when we have figured out the other two pieces. And Copilot, I would say, was was probably the 1st one. Where we were intentional about taking our learnings, partnering with Azure.

Um, you know, building on top of a joint stack between, uh, the GitHub Copilot and all the other copilots that that Microsoft now has leveraging, uh, the responsible AI, um, pieces that Microsoft offered us. But also, you know, contributing back to that. And so that, I think, is what what describes the success, um, of of GitHub now, almost, yeah, seven years, um, seven years after we announced the acquisition in 2018.

Hm, and so, I mean, you know, Copilot is this really incredible product. I think it was for a lot of people, you know, the 1st time really seeing, you know, the power of LLMs. Like, I, I remember, you know, when I 1st, um, you know, when I 1st kinda started to use it, just just like this. Oh my god, you know, feeling of like, kind of seeing, like, how amazing, you know, this could be, I guess.

Um, you know, I I wonder with that, with that product, like, I feel like there's so much momentum in Silicon Valley about like, you hear, like, kind of like, you know, codeium, and you hear about like, kind of cursor and it. It doesn't feel like Copilot has the same, I don't know, like purchase inside the brains of at least like Silicon Valley companies. Like, how do you think about that? Like, do you feel like, you know, you're behind in some ways and you're you're planning to catch up?

Or is it like, like, I guess, what, what is like, cursor doing? Even? That's like, different than what, like, Copilot offers.

Yeah, I mean, I th I think, you know, we, we were very early, um, um, when we started with Copilot in, uh, middle of 2020, even there was n almost no AI hype whatsoever. Um, um, GPT-3 was, you know, available to some nerds, um, and uh, data scientists and and people that understood what, like large language model do. And and oftentimes, you know, uh, you had to explain what a transformer is 1st, uh, to a customer before we get to the point of why this might be changing the world.

And um, June 2021 is when we launched the preview of Copilot, and um, you know, you may say we created that whole market, um, uh, with that one announcement, and um was a very short blog post and and a site that really, uh, landing page that showed how how code completion worked for different languages and different examples. And um, if you, if you travel back in time on on Hacker News and other pages, there was equal amount of skepticism, uh, uh, than excitement.

And um, we started giving people, you know, access to the to the private preview, and um, um, uh, you know, some were, you know, skeptical. And then turned around. And you kind of saw saw that evolution happening of saying, oh, you know, after using it for a while, I actually see the the significant impact. And um, and there were, you know, legal challenges and and discussions around, you know, um, uh, fair use, uh on the training side and replicating, uh, code and and licenses.

And so a lot of the investment in the early days was just scaling out, um, uh, copilot, um, I think we had a million users on the waitlist, um, uh, uh, within less than a year, um. And and then in the private preview, also waitlist, and then, you know, going through the waitlist into the private preview, um. And so we had to also scale out the architecture in that 1st year, and that was the the public launch.

Um, what we call GA, general availability, was was June 2022. So even that was before ChatGPT, right? Like that, it, it's it, this, this whole time horizon is so compressed with so many things that have happened since then. That it's easy to forget that a a Copilot was not only in preview, it was a GA product before before ChatGPT came out. And I was actually on a trip, um, uh, uh, right after the chat, Chatgpt launch.

And I could see it in every customer conversation I had, whether it was in Tokyo, Singapore and Sydney, uh, that the world had dramatically changed. Um, uh, it went from AI is kind of this cool technology, but we're far away from that future. And it it actually being useful. F to Thomas, tell me more how you build Copilot, how we can adopt Copilot. Uh, we had the 1st case studies where we showed that developers are 55 faster.

But ultimately, you know, the the play for for GitHub, um, is that we have the platform. And so when you, when you buy GitHub Copilot, you not only get it in VS code, uh, and in JetBrains and in Xcode and, uh, Android studio and whatnot. Uh, you're also getting it in in GitHub and you're getting a a code review agent, um, to look at your pull requests. And and so just in earnings, um, Microsoft earnings, uh, last week, um, uh, we we published that, uh, Copilot has now 15 million, uh uh users, uh, and the Copilot code review agent, uh, just as an example of that platform play, has, um, reviewed, um, over 8 million pull requests.

And I think that's where we are. We are seeing the future as this holistic, um uh, workflow, where you have copilot, uh, for auto completion, you have chat, um, you have agent mode, um, you have mcp integration, uh, and then it continues, you know, in your pull request, um, uh, to review code, to fix security vulnerabilities. And uh, with project Padawan, uh, which we announced earlier this year, as you know, one of the um, early, um, uh, oh, how do you say this?

Uh? As one of the projects we're working on to implement a um software engineering agent or SV agent, um, uh, you v. You have a flow where you can go from issue to pull request, um, just with the help of of an agent.

Hm, and do you have like a sense? I mean, I think you've thrown out different numbers. A lot of people kind of talk about, you know, productivity gains. I I myself wonder how you even possibly really measure that. But do do do you have any sense on, like, what, like, what the speed up is, or like, like, I guess, what are you even like? Kind of shooting for with this, with these projects?

We are ultimately shooting for at making every software engineering team, starting with ourselves, um, you know, able to deal with the ever growing, uh, number of lines of code, uh, and the complexity that comes with that. The problem with, you know, when you compare productivity gains between, uh, uh, you know, uh, without Copilot and with Copilot, um, the challenge you have is you're never working on the same thing twice. Um, you can do case studies, and that's where the 55 came from, where, um, uh, you know, we gave 50 developers, uh, a task, um, to do it without Copilot and 50 with Copilot, and the team with Copilot, um, and everybody did the same thing, right?

And the team with Copilot was 55 faster. Uh, but that obviously is a, you know, clinical study, if you will. Uh, it isn't reflective of the real world. I would never have 100 developers in in in my team do exactly the same thing. Uh, and even the one that works on the same topic, right on the same subsystem or micro micro, um, uh uh, system or whatever. Um, they're not doing the same thing day on, day on.

In fact, they're adding more stuff to the existing service, um, and um. And so the complexity is always rising. And so when you look at productivity gains, you gotta ask, what's the baseline, what's your comparing against? And ultimately, the AI, the AI, um, uh uh, making AI part of the developer workflow had two impacts. One is that we actually increased the complexity for the developers building this system. Because full stack now means backend and database and all that infrastructure and front end.

And now you also have AI, uh, which means you have to integrate models and eval them and fine tune, or, you know, post train them and operate them. And then you have, uh, things like, um, what? OpenAI recently saw that they, you know, have a new version of the model. And they tuned it too too far in in the one direction. And they have to roll that back. But even to, if you don't wanna wait for customer feedback on that, you have to have really good, uh, eval, uh, test suites and a and a really solid, um, um, you know, monitoring process.

Which is, you know, not fundamentally different to monitoring your uptime and your exceptions in Sentry and and all these kind of things. But. But it adds another complexity layer, uh, to our development teams. So what AI has done to almost all software engineering companies, because the expectation is now that you're integrating AI into your stack, is that you increase the complexity. And on the other side, um, uh, it has made coding much easier. I think auto completion is all about flow and and staying in flow state.

Um, when you're typing a code, uh, in VS code yourself, um, uh, uh, and it predicts the next ten lines of code, um, it, uh. It removes you from the obligation to go, um, into your browser. And, you know, search for the how you use a keyboard or how you do this algorithm. Or, I mean, even simple things. When you work in a Ruby on Rails app and you have a have a model, um, with a couple of, you know, columns and you know, go into the controller and you wanna instantiate the model.

Just having it, you know, pre tell you what are the uh, uh, different, um, um, um, attributes, um, of that model, um, and and some of that, you know, already. OB obviously work with IntelliSense, uh, or Intelli code, just more classic auto completion. But it really keeps you in that flow state. And oftentimes, developers, you know, just can accept code. And then it's it's close enough to what you're trying to achieve to. Then go, you know, and modify the pieces that are broken.

Uh, have syntax errors and whatnot. Uh, and and let's face it, that was also true when we copied start, uh, code off of Stack Overflow, off GitHub repos or or from blog posts, right? That code was never actually perfect. You had to take it, you had to, you had to paste it, um, uh, I into into your code, and then you had to make it work. And so that's where I think auto completion has really, um, improved the flow state.

And now, with, you know, next edit suggestions, you can just tap, tap, tap, um, you know, from one suggestion to another. Um, uh, the latest VS code, um, uh, has actually, you know, the auto completions also with syntax highlighting, uh, so you can even parse that a bit more than the original ghost tech. And, you know, this brings us back to the the early days, this UI concept of ghost text of basically showing you ten lines of code within the editor that you can auto complete into.

That didn't exist like we built that in partnership with the VS Code team for the original Copilot. Before that, auto completion was a drop down. Um, uh, where you could, you know, uh, uh, scroll through the different option, uh, from from the documentation. Or, in text mate, I think it captured what else it had in that file and and created kind of like a, uh, a DSL out of that, um, uh, not a DSL, um, but like a a menu of options.

And um. And so now, if you go into agent mode and and SV agents and um, or things like, um, bold, uh, dot, new or lovable, uh, you know, Vercel's, uh, v zero, right? In many ways, um, if you know how to prompt it, you can actually have it write all the code, right, like, uh, uh, like v zero. As an example, like you, you give it a prompt and it renders you the whole web page.

And behind the scenes, it it obviously uses Next. JS. And then you click a single button and it deploys it to Vercel. And and um. So it was never easier to to s spin up a quick web page for your, for your wedding, or for your birthday invitation, or or even to sell. Like, you know, uh, like a pop up store, like, sell a product real quick. And then you can use prompts to redefine that code.

But I think where we are, and so that's super efficient, right? Because you often don't even need to hire a developer anymore. And you see a a bunch of examples, uh, out there where the users of these tools are not actually folks with with a software engineering background. They're just heard about this, uh, on on your podcast, or elsewhere, uh, that this is cool, and then they're trying it out. And similar to how they've used, um, chatgpt, uh, to render an image, and and when the image isn't exactly what you want, you redefine it with with more prompts.

Uh, they're doing that with these webpages. Where I think the biggest challenge lies is that the majority of actual, you know, big scale software projects like VS Code is one, GitHub is one, you know, weights and biases and and others. Is that there's the complexity of these projects is so high that today the agents cannot actually tackle those, much in the same way that, you know, there isn't still a. So far, we haven't, you know, gotten a a car into the market that you can buy that has no steering wheel.

Um, the closest is, you know, Waymo in San Francisco and a bunch of other cities. But it's ring fenced to to that problem space and it has a bunch of extra sensors. I think the that comparison applies to agents as well. There are certain scenarios where that works well, but there's a whole co big complexity out there where it, where it doesn't work well. And where the agent, uh, or agent mode in VS code, um, uh, takes a file and adds the two lines you wanted, and it removes five zero lines or, uh, screws them up in in some form.

And I think that's where it's becoming crucial that developers a still need known how to code, and b can make a very educated decision whether they want to use the agent. Or just go into the file themselves and and make that one line change, where they know exactly how to do it, where to do it. Like, it's, it's, it's almost like a waste, um, of energy and time. If you're trying to write a prompt for something that you can much ra write much faster in in code yourself.

And so having this continuum from having AI infused into the editor with code completion to asking coding questions, explain the code inline chat and those kind of things, all the way to agent mode and and autonomous agent. I think those two things all belong together. And as developers, we want to move, you know, in both direction, up and down, up and down that spectrum. And if you see a pull request that was created by SV agent, and um, and uh, you see a bug in there, what you wanna do is go into the command line.

Say, you know, use the GitHub CLI to check out that pull request and then just keep working in in in VS code or or any of your other favorite IDEs.

Do you think, um, do you think that's gonna be true three or four years from now? Like when I, you know, yeah, like, what, what? How do you know that, right? Cause you could? I mean, it seems pretty clear, like you could look at the situation and be like, well, it's like getting better and better. Like every every month, it seems to be, um, you know, better. Why? why aren't there? s why? why won't it get better?

Kind of going into, like, you know, specific parts of the code and changing it, which I totally acknowledge. You definitely have to do today, especially on like a larger code base. But so many smart people are working on it. Why? why isn't that get fixed?

it's getting better. Um, certainly the models are getting better, but um, I, in some ways, you could argue now 2025. We are still fighting some of the same problems we were fighting back in 2020 with GPT-3 and and Codex. Um, and um, where the model just writes code that is a little broken, or, you know, mis mis types. An import statement in Python. And then now with agent mode, it can use tools and it, you know, can fix itself by looking at the at the error message.

Um, but I think fundamentally, the part, the role of a software engineer, uh, is not just to create new code and new files, it's actually to design, uh, an application, uh, that is unique. Um, you know, for the mission, um, uh, you know, the the OKRs, whatever you're describing, you, and um, part of that is that you wanna build a successful business, um, that, um, grows revenue and and returns, uh, uh, profit, um, to the to the owners, or, you know, the S the shareholders.

And um, I think, you know, that systems thinking, how design, how to design the application, you know how to decide between MySQL and Postgres, um, or between React and um, JQuery. Or I don't know that. Maybe that maybe is an easy decision, uh, go go and use React, Little bit of you know what a tangent I'm saying, right?

there, I know. Like, there's, there's, there's Yeah,

a there's, uh, 10,000 choices, um, to make when you, when you're building, uh, uh, you know, um, an application with indecent complexity. Um, just like you're when you're building a house, um, and n. Almost no house looks exactly the same as another house, and almost no application looks exactly the same. And if that were true, um, you know, if it can just create code with a, um, with a, you know, a few prompts, um, that startup has no value, uh, because then everybody else could also build that, right?

And so the complexity will just significantly grow as these agents become more powerful. I think the flip side of that is that while we're here in 2025, and many, if not all of the financial services institutions, banks and insurances, have still some kind of mainframe. COBOL, you know, legacy code. Um, unless, you know, if the bank was founded in the in the last ten years and didn't do any acquisition. But um, and and so, and that that journey of le managing old code that somebody else has written, um, and um, figuring out what the developer was intending.

How can I refactor this? Are there actually unit tests? um, and if there are unit tests, do they cover enough of that? Um, uh, that is actually the bigger part of software engineering, right? Like, if I switch sides and and join your company as an engineer today, uh, my biggest challenge is to understand how this all works. Um, and while I could use an agent to achieve my goal here, how do I validate that what the agent has written is actually correct and doesn't introduce a new security vulnerability?

And or doesn't make the thing so much, so much slower that you need, you know, ten times, uh, the compute to now run that platform. I think that back and forth between the agent and its output and the developer is going to stay crucial, uh, for many years to come. Let alone that. Obviously, there's also a lot of security risks of accepting code into the code base without understanding what the code actually does, right? This it calls it zero trust principle.

Um, today, um, most companies don't allow, uh, any developer to push into the main branch. Um, they force a pull request review with a different reviewer, uh, branch protection, all those kind of things, uh, run CI CD, and only if all these things are green, um, then you, you can merge it back and deploy it, right? That we're doing that because we are worried about, uh, attacks, we are worried about, you know, the model, we are going to be worried about the model.

Writing code that, uh, injects, you know, a security vulnerability. Whether that came from an attacker or whether that came from a, you know, built in vulnerability into the model, I is, uh, is effectively irrelevant. Um, we d have to deal with that risk, and that risk is mitigated by human reviewing that code. And maybe they're using AI for that as well, and I can see that happening. But I think ultimately, we gotta have humans understanding code, you gotta have humans designing systems.

And, uh, making decisions of when to use an agent. Um, burn, you know, through GPU cycles, uh, to to write code that actually generates value, uh, f for the companies we work for.

I guess, you know, you've written about sort of like this long arc of kind of like level leveling up to higher levels of abstraction in the world of software development. I, I mean, I totally agree, right? Like, I think, you know, like, you know, I've. I sort of felt bad when I was in college for not like going deeper on like C. Cause that sort of felt like an essential software, you know, skill. But maybe, unless you're in certain domains, like less and less, you know, important, you know, over over time.

But I guess you're you're also talking here about like, sort of going in and being able to like there. There's sort of an architectural level of kind of almost like a manager, like software architect, um, you know, mindset of like, you know, like, what database should I use here? and how should I kind of like, lay out my application? But you're, you're also talking about sort of like going in and actually kind of modifying some of the um code, or at least like understanding it for, you know, security reasons or reliability reasons.

But it also seems like, wh, why wouldn't the software be better than a human at kind of like writing tests and doing like security reviews? Like, why, why doesn't that get automated away?

it will get, it will get automated, I think, to to a high degree. Um, if you, if you look at, you know, having AI writing documentation or or unit test cases, um, it already works to a significant degree. Um, although we also gotta be real, um, uh, you know, the most, uh, popular benchmark right now is, uh, Swee Bench, um, SWE Bench, um, which is two zero pairs of issues and pull requests from a dozen Python repos.

And the best, uh, agent in SWE Bench is like at sixty two, sixty three. I think think,

Well, you know, my, we were at the top of it until recently. for a while, But I will, I will but it's sixty, tell you that.

five. But sixty five of Python, dozen Python repos is like returning with sixty five. From a math school in in high school, uh, from from a math test in high school, that's not a great result, right? Ninety, I would, I would, uh, say, we're getting there, um, uh, but even that is like a ten gap of uncertainty in a business. Um, and just, um, just, uh, uh, you know, this week, um, uh. The founders of Swee Bench built out, uh, the multilingual version, and they also, uh, announced, um, um, an agent that can generate new test data for those agents.

And with this multilingual, um, I think the numbers go significantly down. Uh, into the into the 20s to 30 range. So we are, we are far away from this agent to actually be, uh, you know, at 100. Will. Will that point happen? Of course, in the same way that we are going to see fully self driving cars, um, but we don't know when we get to that point. Because it's not an easy problem to solve, and it's not one that hasn't been solved before.

But I wanted to come back to, you know, the fundamental part of your question, which is the you know, the machine that we are all ultimately ultimately building software for. Still runs on a processor that has, you know, a built in instruction set that, um, is abstracted all the way to the programming language, but not higher than that. The programming language is the last n deterministic abstraction layer that basically maps directly into the instructions that the CPU or GPU executes.

Natural language is inherently non deterministic, uh, because you can, you can both say the same sentence or describe the same user interface. And then build a completely different, uh, uh, uh, website with, you know, different, uh, design and and a different functionality, different databases and so on. And so having that, that, I think, is going to be the craft of a software engineer. Is being able to jump between those two abstraction layers and making decisions of when can I just describe it in natural language?

Because because that's ultimately how we're thinking in our brains, and and how we're thinking. You know, when we wake up in the morning and we have an idea about something we wanna build, we're thinking that in, uh, English or German, or whatever language, you know, you, you, you have in your head. Um, and then the challenge in the past was, how do I convert that now into programming language? And that's often more frustrating than most folks wanna admit.

Um, uh, because it takes way longer than you thought it might take. And then it's easy enough, you know, to pull in an open source library. Uh, until you realize, okay, so this actually created a whole new problem in my application. Maybe now you, you now have an a dependency that requires you to upgrade to a newer version of Rails, or or what have you? And so I think, you know, that conversion of being able to take my idea, describe it in a few bullets, or even use, um, Claude 3.7 Sonnet is super powerful in in kind.

This reason with the model what my specification looks like. And then you create, you know, a a a markdown file in in your project, and then you, and and then you're feeding that into Copilot agent mode to have it, then, you know, actually implement that. Um, I think that's the new way of working, but it still requires an engineer, right? Like to to kinda like, do that thought process, um, you know, figure out the user interface flow, build, building an amazing product, um, and then jumping down into the coding layer to find, you know, the one line that that's broken, and um, uh, that you need to fix, um, to to compile the application.

Do you find with, um, uh, you know, suddenly all these people using automated systems that your kind of user metrics are changing a lot, like in the last year? Like I, I? I would think that, you know, automated code generation would, you know, potentially make like a massive increase in the amount of, you know, code getting sent to to to GitHub. I would think that, like, you know, you might get kind of more branching because, like, you know, models are like, more comfortable, like, just, you know, generating pub the pull requests.

Are. Are you seeing effects like that in your own data?

I mean, I think the biggest one we are seeing is that adoption, um, has significantly increased, um, and Adoption it's adoption

of, oh, of the code, of AI, AI, yeah, yeah, yeah, AI is yeah,

now, you know, part of the lifecycle. Um, um, and um. It's no more a question whether software developers, uh, should use, uh, AI as part of their of their day to day workflow. Whether that's in the inner loop, you know, when when writing on on my computer and um, uh, code completion, chat agent mode, everything that's kind of like, uh, uh, synchronous, uh, with me and my machine. Or whether it's, you know, in the outer loop.

And and pull request reviews, you know, summarizing the pull request, um, having, uh, uh, you know, the SV agent, um, build the pull request itself, um. And so I think it's accepted, you know, p best practice now, uh, to to use AI, uh, in your workflow. Um, that doesn't mean everybody has adopted it, but I think we are way, way past the the chasm, uh, and we are now talking about the late majority. Uh, if, if not, you know, the the laggards, um, that, that are even later, um, and um, and that's where you see, you know, this in in very intense competition in the developer tool space.

I, I would, you know, argue, I've never seen anything like that in, uh, in my 30 years, you know, since I started coding on a Commodore 64. In terms of, um, uh, you know, uh, you mentioned a a few startups earlier, but it's not only the startups, it's also, you know, all all the hyperscalers that have AI coding tools. Um, uh, IBM has one, and, you know, uh, everybody is playing in that space. And and the extended version of that, um, uh, from from training models to fine tuning models, to having an AI stack, all the way to to coding tools.

Um, if you will, you know, the B. The biggest use case for AI today is software development. Um, and maybe that gets us to the point where then AI, you know, becomes AGI, when, you know, the AI can write its own code and improve its own code. Um, and so adoption is one thing. I I think it's accepted now that AI is part of the developer workflow. How much code it's writing, uh, is, uh, constantly increasing, the models are getting better.

Um, you know, we are, we are now, uh, shipping a new code completion model, uh, uh, every month. Um, we have an ongoing, um, uh, mid and post training process, um, to improve, you know, the code completion model. Uh, uh, with, you know, uh, online testing, uh, offline and online testing, uh, and um, you know, seeing in those experiments how much the uh, accepted and retained characters. That's the one of the met key metrics that we are looking at is like, when you get a completion, how many of those accept uh characters do you accept?

and then how do you retain them? And so there's a window where we are looking in the editor, what you are doing, and if you are modifying those characters. So that's the metric we are tracking, and based on that metric from offline and online testing, we then decide is that model flight good enough to become the what is it now? May the May model? Um, uh, uh, which is the code completion model that Copilot is using.

And I think that's where, you know, even though code completion, you could argue, is somewhat commoditized now and and everybody considers it a standard feature. There's still a lot of improvement happening based on metrics and making the models more efficient, you know, improving, improving the margins, um, or just the number of GPUs you need for it, and and ultimately improving the user experience. And and having them get more accurate code, um, with lower latency. And latency, by the way, is, I think, you know, latency in many ways is the core metric for every developer tool.

Like, if it isn't fast, um, uh, you're always going to have, uh, an audience, uh, of software developers that are going to, uh, be not happy. And and um, even with with these agents, and I think that's going to be a big problem, uh, both for the synchronous agent on your machine and the asynchronous agent that that runs in the cloud. Is like, I mean, I don't wanna watch, I don't wanna watch an agent, uh, uh, do its work for 15 min.

What I do is I start it, if it doesn't have any question, it goes running, and then I go and do something else. And, uh, and um, we. But we all know context switching is hard. So how many of those agents can you really start and then go to another branch on your computer? Uh, before? Be this becomes more annoying and destroying your flow than than actually helping you. So even, you know that, um, how do you keep the developer in the flow state?

um, and how do you keep the agents fast enough that it feels fun? I think that's going to be, uh, you know, described that, that's going to just be describing a lot of innovation that's, uh, going to happen in the next year. And that's why you, you know, hear, uh, uh. Many of the folks in industry saying that with agents, uh, what the software development looks like will fundamentally change. Um, over the next six, twelve, you know, maybe 24 months.

yeah, it's funny, I guess. From where I sit, it kind of feels like it's already changed. Like, I like, I mean, this is my own personal workflow, I guess. But I find myself using a lot more like agentic code generation than tabs these days, which I would just. I think it's a lot less fun actually. Like, I, I kind of like that you're talking about the like fun of coding, cause the context switching is like, horrible, right?

It goes from like coding, taking me into a flow state to coding, you know, meaning I have to, like, fight my brain to stay focused while I like, you know, frustratingly, like, wait for the the thing to finish. But I think it's more efficient, uh, for me, like, are you? So? I mean, you obviously you have to support, um, both users, like, do you look at how many, how much people are doing in those two different ways of of engaging?

And and d, am I the unusual one here that I've kind of moved to more of the longer pauses? Are most people just tab completing?

um, I mean, I, yes, I mean, most people are still mostly tab completing. I think, if that, that's just the nature of things, right? Like, you're not changing, um, how the majority of developers work overnight. And that there's certainly within the developer and and AI code gen space, a a whole different S curve of, you know, early adopters of agent mode. I think that's still a smaller population than the large majority that has adopted code completion, and let's face it, code completion.

You, that was one of the magic of the original Copilot. You didn't have to adopt anything, um, and and we could have probably announced this and not even mentioned AI, uh, and just say, here's cooler code completion, and it's there. And if you don't like it, just ignore the ghost text. Or, you know, command shift P. Disabled Copilot is is always fair game if if you're annoyed by it as well. Um, especially when you're working in a file where you might not even want, you know, uh, the content of that file.

Go to to model inference. And so we see an adoption spectrum, um, uh, between, you know, code completion, which has the my highest adoption, chat and inline chat, uh, all the way to agent mode. And agent mode, you know, I think, to some degree, is still something that developers have to learn. And where there are scenarios where it makes sense to now start vibe coding with the agent versus just, you know, doing it yourself. Um, and, uh, Toby Lutke, the Shopify CEO, recently had this, you know, memo for the whole company saying AI is now, you know, baseline expectation at Shopify.

And um, I think the the most fun, uh, bullet in in in that memo was, um, if you want more headcount, you first have to show, uh, that you can do it, uh, uh, with, uh, with AI, and uh, and and, you know, and increase the productivity of the company. And I I think that shows you where the thought process is. But the the thing, you know, with agent mode, is that if if it takes too long.

As a developer, you're always going to have the question in your head, is, could I have done that faster myself? And so I think that's a culture change and a mindset change that will will, you know, go, keep going. As the models get faster and more efficient. And and kind of user behavior shows at what point you want to take over and say, Okay, this is good enough, I can do it. Um, we are going to s, you know, see a behavioral change across the population.

I actually think, you know, a lot of the IVN coding is is is fun. In the sense that, look, you know, my hobby projects. I don't run any unit tests because, and I don't put a pull request against myself either, right? Because what I really want is I have this idea. I wanna write some code, I wanna see it light up as an app in my dock or as a web page, and then I wanna feel good about this, right?

And I was like, Look, look, what amazing thing I just created with just a bunch of lines of code and a computer. And that was always, um, the magic for me in software development, right? Like you didn't have to build a factory first and and and tools and all that, uh, you could get any computer, um, the ear, the earliest, you know, PCs, or, um, you know, the Apple II. And they had they, they had a programming language that was the operating system was basic, um, even even on the Altair, uh, even though that didn't even have a keyboard and a uh, uh, and a monitor, um, and um.

And so that I think that dream is still there for many developers. I have an idea and I wanna implement something. So now if you can do that and then spin off an agent in the backend, um, to to write you the unit tests. And you don't even have to watch that because you can just write the next method. And in the meantime, it has built you, you know, the 15 unit tests for that one method.

And then I mean, I mean, it runs it and fixes it itself, and that happens in the background. And you have to watch that, you can just focus on the next method in in your class. That, I think, is keeping you in the flow state. Uh, because you're not going from the thing that is fun, which is really building features and and and functionality, to the thing that is usually not fun for software developers, which is writing unit tests.

And then running them and you wait, and then, you know, the last one fails. And now you're, okay, what, what did I do wrong here? And and why is this one not, you know, uh, meeting the assertion? And I think that's that's where we're going to see, uh, a lot of user interface innovation, um, over the coming, over the coming month. Um, um, spinning off these agents, um, uh, and keeping the developer in the flow state and and letting them really do, uh, uh, what they want to do.

I is that like a core guiding principle for you to to like, make it fun. Cause I would think like a lot of CEOs would be like, don't really care if my devs are having fun, I want them to, you know, be productive here.

It's certainly, uh, it's, uh, it's. Developer happiness is is certainly one of our principles. Um, and we, we d. We definitely believe that, um, if developers are not happy, they're not productive, and if they're not productive, they're not building, uh, amazing products. I think those are very strongly correlated to each other, um, and it goes both ways, right? Like, if your tool chain is bad, that means your NSAT or your NPS is going down, and your developers, uh, get grumpy about the tool chain.

And they have to wait forever. And we know that, um, you know, even at the s, at the scale of Microsoft, um, before I became the GitHub CEO, uh, for some time, I I ran Microsoft Engineering system team called One ES. Uh, and one of their biggest projects was bring down the build time for the office suite, uh, from days, um, down to. I think 8 h is where we ultimately ended. And and Wow, it's even that 8 h to build seems, but

the office suite.

we, yeah, yeah, I mean, 8 h sounds like a lot. But if you're coming down from like three days, you realize that 8 h is actually good. Because it means you can, you know, start a build and then take off for the night. And then the next morning, you, you have a fresh build, right? Whether it's if it, if it took days. And so parallelizing,

wait. So what happens if somebody breaks the build in some cross functional way? Is it just like down for like a month, while people like, figure out what went wrong, or at it,

well, I, I don't know what the answer to that is because I was in the team. But I I mean, the the, I mean, obviously, um, you know, at the scale of of an office suite or Windows, um, you have many, many builds, uh, running every night, and so one broken build, um, is not slowing everybody down, it's just slowing down that team on that branch, or or that, um, uh, feature, um, uh, workflow, um. And then they had to probably spend the day.

Yeah, but yeah, I mean, if the turn, that's the that's the latency problem at at a really large scale, right? Like if your turnaround time is 8 h, um, uh, and and you, you're, um. And we have that actually, you know, in model training now, right? Like model training runs, um, for these really large, uh, uh, uh, um, frontier models, uh uh. Takes so long that if if, uh, you make a mistake or there's a power outage, uh, and that interrupts the training run, uh, you, you have wasted a lot of, uh, ultimately, you know, uh, money, uh, in form of energy, uh, and resources, uh, that that is now wasted, uh, time.

So keeping these, uh, you know, uh, supercomputers or clusters, uh, up and running, uh, to do the model training in itself is, I think, a crucial, uh, a crucial part of of training, uh, uh, frontier models. Um, but yeah, so coming back to, you know, this office example, right? So the goal there was just bring build down the build time, which means you had to parallelize the builds over multiple machines. Which then raises the question, okay, so how do you do that with dependencies?

And and where do the object files goes go? And and what artifact storage do you have? That's fast enough. So the storing the f, uploading the file into an artifact store and then downloading it on another machine. For, you know, that next object file compilation isn't actually slowing down the the build process, right? And I think it's these these kind of like optimization problems that we are going to see, uh, uh, in in a new form, in in AI, um, in in in this AI native workflow.

Um, yeah, the I think the funny thing is actually AI native, uh, is is is a misnomer, right? Like, because it's AI first, um, um, um, uh, or AI infused, um, but nobody is actually AI native yet. Um, we all learned coding, uh, without AI, right? So we, we might be cloud native, we grew up with the cloud, although I didn't, um, I I think you didn't either. Um, uh, uh, but but certainly it became a whole, and then you can become a cloud native startup.

Um, uh, the 1st really AI native startups, I think, are yet to come, where it's like, truly, truly AI native. Um, um, and what we, you know, when we in ten years look back, say, yeah, this is when and things fundamentally changed, and and and now companies were just built in a a whole different way.

D You know, a a conversation that I have all the time, I have a feeling, you know, you might have this too. Is like talking to executives that wanna like, push their team to use more of these, like, you know, kind of use more code automation. It always seems really, um, baffling to me, like, I, I sort of feel like, you know, if it's obviously more productive, like, wouldn't, you know, people adopt it? Like, I'm? I'm not gonna tell my engineers, you know what tools to use, but I am gonna be frustrated if they're like, not as productive as they as they could be.

I mean, do you come across this? Like, I, it's, it's. I just scratch my head with. Like, if an engineer wouldn't adopt a tool that would make them like 50 more CR productive, it just seems really, um, like, ridiculous to me. But but I'm curious, what, what are your experiences of this? Do do you like push like using tools internally to to try to get your team to be more, um, AI native?

So we adopted, um, or adapted, uh, the Shopify memo, um, uh, in some form within Git, uh, some modified form within GitHub, uh, and made that, you know, similar, or I made similar statements, uh, to GitHub, uh, that the usage of Copilot and AI tools is is part of our culture. And and, you know, mandatory, where where it makes sense. Uh, obviously, you know, we don't want a salesperson, uh, use use Copilot, uh, uh, in the same intensity as an engineer does.

But there's many other AI tools, you know, that they should be using, uh, as part of their workflow. Um, so that's where I think we're past that point where that is actually a question in the same way that, you know, at GitHub, um, it is part of every employee to use Git and GitHub. That's not optional. You cannot say, okay, I store my source code, you know, uh, on Azure blob storage or or Dropbox or anything like that, which, you know, it's like you're laughing, but, like, uh, we also know from telemetry that that still is very prevalent, uh, in software development, especially in hobby projects, student projects, or or companies are just, um, you know, um, doing, you know,

something else in software development as as some somewhat, as you know, a corner case of what they do day in, day out. Um, like, while Git adoption certainly has grown significantly, um, over the lifetime of GitHub, uh, there's also still a market to capture for us just on the platform and and and, you know, moving, uh, companies into Git. So, you know, nobody questions whether employees at GitHub should be using Git. I think we're at the point where that is also true for Copilot and and AI tools in general.

Um, but that doesn't mean, you know, that that needs to be 100% of the day, and I think you still need to think about when it makes sense and and doesn't make sense. Um, that that decision making, um, you know, do you do control space on your Mac to open ChatGPT into Intellipanum? Ask a question or do you Google it? And, um, and I think, you know, that is feels somewhat more natural now, uh, but it is it is not binary.

There there is a gray area we could do both, and and often it's driven by your belief system. And I think, you know, the the question you ask is why do developers not use A I, even though the metrics are clear? I think part of that is belief system and and kind of like this is how I have always worked, and now that I have these auto completions or the agent mode, I'm forced into a way of working that I don't actually like.

And now I have to read more code and understand it than write code. And I have to write prompts, but I don't wanna really write prompts. And it's this culture change and and ultimately the change of how we do things as humanity that we know takes time. And it's it's just not done by forcing people into this new way of working. And in fact, I think what we're going to see is a bit of a shift in the performance curve of, um, the employee population.

Like, you know, when you do, uh, uh, performance rankings or, uh, evaluations and and those kind of things, the employees that were good maybe five years ago in in that way of working may not be at the top of of their of their, you know, uh, uh, whole or or class, um, in in that new way. And and because adopting to that world, um, it's it's, you know, I'm a big, uh, F1 fan and, uh, in Formula one, you know, this way it always works is there's new regulations and then the first two years or so, one team had it figured out early and so they're ahead of everybody else, Red Bull in the current regulations, and then they're getting

close and close to each other, and then you have really, really tight races, and you have a fantastic season like 2021. And then they change the regulations. And now there's new regulations and there's a new way of driving these cars and all of a sudden a different team and a different driver can handle this new, you know, uh, uh, type type of car, um, you know, current era is ground effect, um, uh, what the the Vettel area, uh, Sebastian Vettel area was where the diffuser was connected to the exhaust and and and whatnot, right?

So there's different drivers handling those conditions better, and then they win the championship. And I think same is true for developers in this new world of A I. You've got to be able to adapt, uh, learn and and be willing to kind of, like, you know, evolve your mindset, um, into into what is now the state of the art of software development.

Totally, I I totally agree with that. Do do do you also feel like the skills that someone would need to be a good developer are changing? Like, I I sort of feel like, you know, maybe more product-oriented, um, mindset would probably help in a world where the the actual, like, implementation gets gets easier.

The technical details have gone away, right? Like, in the 90s, you had to know about the C P U and the cache and the memory and the bus, uh, if you even had a hard drive, um, or or cassette tape. And then, uh, you so you had to really be in the intricacies of, um, of the hardware architecture you're building for. And that led to things like, you know, the 386 having a turbo switch. Uh, the, uh, you know, the the turbo switch wasn't to make things faster, it was to slow down the the the software that was so optimized for the architecture that would run way too fast and so you couldn't play the games anymore.

So you slow you slowed things down because everything was so optimized. And so those developers that know exactly how the P C works and the instruction set of the C P U and maybe write an assembler function to run that certain part faster, they are like, um, you know, a minority of the of the whole developer ecosystem. Uh, similar for, you know, developers that can write shaders in in computer games, that there's certainly, you know, a demand for that, but the majority, uh, uh, of of full stack developers don't know that skill.

And and so I think we have always moved up the stack and lost left something behind intentionally because the complexity has has grown so much. And so the skill that I think the future developer needs, if not the current developer already, is systems thinking. Like taking, you know, this problem that you're getting from your product manager or your boss, uh, your engineering manager, and breaking it down into a small enough chunk that now you have enough of a of of a way of taking that abstract problem and converting it into code, right?

That ultimately is what software developers do today. You take a description of a feature and then you're kind of like in your head or on on on with a pen and paper, you're breaking it down into small pieces of work that you can, you know, do during your workday. And I think that that thinking doesn't go away, but it moves at an even higher layer. And today, you know, if you go into Copilot, ChatGPT, Copilot, whatever, and you tell it to build you GitHub, um, well, it gives you probably a page that looks like GitHub, um, maybe you should try that after the podcast.

Yeah, yeah, I Um, but Get it, It certainly doesn't give you, you know, all the features, and and it certainly doesn't give you the scale of hosting, you know, more than 500 million repos, let alone it doesn't give you the git stack or the we call it git systems and all the pieces that are part of that application. And, you know, that goes back to A V in five years at the point where that works with just A I, I doubt it.

Uh, because, like, designing, you know, a system like GitHub or or weights and biases or CoreWeave or whatever, that that is still requires engineering skills, architecture, architecture, or that's why I like it to summarize it as systems thinking. Um, the the other side is is this notion, uh, of a full stack builder where you actually no longer had a P M and a designer and an engineer and testers are already gone from from most companies anyway and and and s r e, uh, you know, has has merged with software development as part of DevOps roles.

But basically, having a single person that can, you know, take an idea and work with, you know, one model or agent to mock out the spec and and the designs and then create, you know, the figmas and probably using some form of design system, the one that we have at GitHub is called Primer, uh, because then the A I can, you know, compose these components into into a page and then taking it into the business logic and application, uh, logic with with an agent, uh, writing all the test cases, you know, writing your actions, deploy script, deploying it to the cloud and have an s r e agent model monitor this all, scaled up and down, you know, look at

exceptions, maybe take those exceptions, file a GitHub issue, and then you take, you know, the s w agent to to implement that fix. I think that full stack builder, um, is, um, if it not already exists, in some small startups, um, or or very innovative companies, uh, is is going to soon, you know, become a role in a company, um, and, uh, you're Well, if you're Going to have

Out there, I wanna work with you. I'll say that. That sounds like an amazing, uh

And you're going, so what you're going to have, what you're going to have is, like, the Venn diagram between what a P M is doing, what an engineer is doing, what a designer is doing, uh, even mark a marketer is is going to have a much higher overlap. And so you can, you know, a a really good P M that can write a really good GitHub issue of what a feature should look like and, um, hit exactly the right abstraction level to then assign it to Copilot and then Copilot, you know, spins up, um, GitHub Actions and and uses tools and M C P and all these kind of pieces to implement that feature, creates a pull request, and then

you review that pull request. And and that's where, you know, the engineer might come in and say, yep, what the P M created here, but you might have the P M basically building the whole code change, the diff in a in the form of a pull request, but they have of an agent. Uh, and so the engineer becomes much more of a, you know, a conductor of an of an orchestra of agent, uh, together with, you know, the coworkers in the company.

But I do think, and and, you know, I'm not the only one predicting that, but I do think we are going to see very small companies that have very high valuations. I mean, you know, in fact, with WhatsApp and and Instagram and others, we have already seen examples of that before A I. But we're certainly going to see that, and I I think that's that's super exciting. Um, you can kind of build a business in your garage all over again, um, at a at a at a much bigger scale.

Yeah, because like, not everything is, I mean, I think, first of all, like, you know, making something a as advanced as GitHub is kind of like on the outer edge of like, you know, what you need to do engineering-wise to make something useful, and these systems are getting better, right? Like, I I don't know about you, I think we're about the same age, like, I remember, like, you know, programming, you know, like, really, like, you know, basic computers and and like, just being excited, I can make, like, I don't know, like, a circle grow in size or something, you know, like, I've like, I, you know.

And and um, it's like funny to watch my daughter at, like, age five, you know, like, we like vibe code together in the same, you know, doing the same, it's like the same mindset I think, like when I was like a little kid doing it with my dad, but like, um, I mean, she can make a real web app, you know, like, and and it's like, and and like, you know, kids have such weird, crazy, like, creative ideas.

Like, I sort of feel like when when these, like, you know, when when teenagers and even younger can start, like, you know, deploying their own, like, really realizing their own ideas, like, into things, I just feel like we're gonna get, like, a real Cambrian explosion of, um, of applications.

Yeah, I mean, absolutely. Um, by the way, I'm born seventy eight, Uh, so, uh

Yeah, so like, yeah.

Um, uh, uh, I learned coding, uh, first in East Germany on on, uh, uh, in the geography lab, uh, in the late 80s, uh, with a Commodore computer, uh, with a Z eighty chip, I think, was in there and a cassette tape and all that. It was, you know, in my head, I I think, you know, it it merges with my early experience on a Commodore sixty four, which I bought, I think, in 1991.

Um, um, um, and, um, that's where I really learned coding because I had that at home connected to T V. Um, and, um, when you say growing a circle, in my head, I'm like, well, drawing a circle, even that, you know, the Commodore sixty four didn't come with a graphical user interface, right? Uh, it was all text-based, and then you had to switch into pixel mode. And, like, I think there was a pretty fine method to draw a circle, and you couldn't just download an open-source library either.

Uh, and so you bought I bought magazines, uh, uh, um, and, uh, and books, um, and then they the listings in the magazines, um, I will not forget that the listings were not actually listings, they were checksums. And so you had to, you had to mail stamps to the publisher to get a disk back with the, uh, k with the program, the app, nobody called it app back then, the program, that decoded those checksums back into the code because you could print the checksums almost like a Q R code in, uh, of the of the nineteen nineties.

You could print them, eh, much, eh, much more dense, uh, than you would would print code, right? So you would type those checksums into the Commodore sixty four, then to decode the checksums into the code. And then you had a library that you could use to to draw a circle, or or do do a side

so cool.

scroller and and those kind of things. And yeah, I know my my kids are, um, um, um, twelve, almost thirteen, and and ten. And so same thing, you know, I actually bought them Copilot, um, before we we had the free tier that we have now. I bought them Copilot because they always would come to my desk, uh, show me their their MacBook, uh, with their Python, mostly Pygame stuff, and say, here, I have a problem here.

Uh, go and fix my bug. And I'm like, well, I'm talking to Lucas right now. Can we do that later? And obviously, for them, the answer is no, you know, this is way more, uh, higher priority. And then you give them something like Copilot, and now they can highlight that code and ask questions or use agent mode. Um, and I think kids are, um, so much faster in adopting that new way of thinking, uh, because it it aligns s so closely to how they discover the world and learn, right?

Like by asking questions and asking questions. And when you have the first time, actually, my kids use A I was, um, I think it was, uh, on their own, was Adobe Firefly, and they had seen that somewhere in school. And they came home and said, Hey, look, we have these puppy images. And I'm like, where did you get these puppy? Oh, we signed up for an Adobe account. And I'm like, what? And I was like, Yeah, you type prompt and you get a puppy image, and you type another prompt and you get a better puppy image.

And so they very quickly learned this, okay, so if I don't like what the answer I got, why ask another question? Because that's exactly how they interact with their with their families and their parents and their teachers. Anyway, right? Like, they keep asking questions, they don't like the answer that you're giving them, they're asking you another questions. And I think that, but you have to combine that with getting, um, coding and computer science into into every school.

And and I've been, and in fact, you know, um, on Monday this week, uh, May fifth, um, uh, in partnership with Code.org, uh, more than 250 C E Os signed an open letter to to bring computer education into more schools. Because again, like, okay, so you have an agent that does powerful things, but if you don't understand what it actually created, if you cannot read the code, if you cannot validate, um, if you cannot, you know, fix bugs, you you're actually giving up, you know, uh, something that that makes us human.

In the same way that we're teaching all the kids physics and chemistry, uh, and obviously art and sciences and and literacy and math, and that doesn't mean you just become a physicist just because you had physics in school, right? Like, there's still you're picking your career path based on your interests and and, uh, you know, economic value and and those kind of things. But I think it's fundamental for everyone on this planet to understand code and computer science as these devices will only have a devices and the agents will only have a higher, uh, play a more stronger and a and and a higher importance role in in our lives than than they already play.

Well, that seems like a nice place to end, Thomas. I I appreciate your time. This is this is a lot of fun. Thank you.

Thank you so much for having me, and I agree it was a super fun and great conversation.

Thanks so much for listening to this episode of Gradient Dissent. Please stay tuned for future episodes.