Trevor McFedries

The role of AI in new product development | Ryan J. Salva (VP of Product at GitHub)

Ryan J. Salva is the VP of Product at GitHub, where he led the incubation and launch of Copilot, which uses OpenAI to suggest code and entire functions in real time, right from your editor, and is changing the way we build software. Ryan is an experienced developer and product manager, with over a decade of experience working for Microsoft before moving to lead the GitHub product team. In today’s episode, he shares how Copilot got its start, how it moved from prototype to live product, and how he structures R&D teams within larger companies. He also discusses the ethical questions surrounding AI use and how to build a successful product team, and shares the inside story of the development of Copilot.

Published
Published Jun 14, 2023
Uploaded
Uploaded Jun 14, 2026
File type
YouTube
Queried
0

Full transcript

Showing the full transcript for this video.

AI-generated transcript with timestamped sections.

0:00-1:46

[00:00] we had actually created a snapshot [00:03] of GitHub's public code for what we call the Arctic Code Vault. [00:08] Essentially, this is often like way in the north lands of Finland, there's a sea vault. [00:15] And we were like, you know what, like seed vaults are really there to preserve the diversity of the world's flora in seeds in case of some crazy either natural or manmade disaster. But. [00:29] Another really important asset to the world is our code, our open source. This represents actually a lot of the collective, well, certainly software, if not intelligence of the modern world. [00:43] And so... [00:44] We had put... [00:46] this snapshot of public repositories on this silver film that would be preserved for thousands of years in this Arctic code vault. Well, we took that same data snapshot and we brought it to our friends over at OpenAI to see, like, okay, what can we do with these large language models built on public code? [01:06] Well, [01:07] It turns out we can do some pretty cool things. [01:12] Ryan Salva is VP of product at GitHub, where, amongst other projects, he incubated and launched GitHub Copilot, which, in my opinion, is one of the most magical products that you'll come across. [01:24] If you haven't heard of it, it uses OpenAI's machine learning engine to autocomplete code for engineers in real time as they're coding. And I think it's one of the biggest advances in product development and productivity that we've seen in a while. I'm always really curious how a big product like this starts, gets buy-in, builds momentum, and then launches, especially at a big company like Microsoft,

1:54-3:19

[01:54] Also, this came out of a small R&D team that GitHub has, and it's so interesting to hear what Ryan has learned about incubating big bets within a large company and then taking them from prototype to Microsoft scale. Ryan is also just super interesting as a human. He's got a very non-traditional background, and so I am excited for you to hear this conversation. And so with that, I bring you Ryan Salva. [02:24] stack, but you're not using Amplitude, what are you doing? Amplitude is the number one most popular analytics solution in the world, used by both big companies like Shopify, Instacart, and Atlassian, and also most tech startups. Amplitude has everything you need, including a powerful and fully self-service analytics product, an experimentation platform, and even an integrated customer data platform to help you understand your users like never before. Give your team's [02:54] Understand your users, drive conversions, and increase engagement, growth, and revenue. Ditch your vanity metrics, trust your data, work smarter, and grow your business. Try Amplitude for free. Just visit Amplitude.com to get started. [03:10] This episode is brought to you by Athletic Greens. I've been hearing about AG1 on basically every podcast that I listen to, like Tim Ferriss and Lex Friedman.

3:24-5:05

[03:24] my morning routine, especially on days that I need to go deep on writing or record a podcast like this. Here's three things that I love about AG1. One, with a small scoop that dissolved in water, you're absorbing 75 vitamins, minerals, probiotics, and adaptogens. I kind of like to think of it as a little safety net for my nutrition in case I've missed something in my diet. Two, they treat AG1 like a software product. Apparently they're on their 50 second iteration and they're constantly [03:54] involving it based on the latest science, research studies, and internal testing that they do. And three, it's just one easy thing that I can do every single day to take care of myself. Right now, it's time to reclaim your health and arm your immune system with convenient daily nutrition. It's just one scoop and a cup of water every day, and that's it. There's no need for a million different pills and supplements to look out for your health. Make it easy. Athletic Greens is going to give you a free one-year supply of immune-supporting vitamin D, [04:24] free travel packs with your first purchase. All you have to do is visit athleticgreens.com slash Lenny. Again, that's athleticgreens.com slash Lenny. [04:33] to take ownership over your health and pick up the ultimate daily nutritional insurance. [04:40] Ryan, welcome to the podcast. Thank you, my friend. I am genuinely very excited to be here. Lovely to geek out with you for a little while. [04:48] I'm excited as well. [04:49] We were chatting briefly before we started recording and you mentioned a little bit about your background, which is really unique for someone that is leading product at GitHub. And so can you just share like what you studied in school and then briefly just how that led to your career in product management?

5:06-6:50

[05:06] Wow, you're going to make me remember all the way back to school. Okay. Yeah, so back in school, I... [05:14] I was not a classic software engineering CS major. I studied the kind of [05:21] Esoteric answer is philosophy of aesthetics and 20th century critical theory. The easier access answer is philosophy of English. [05:30] But primarily, it was really about like, [05:33] how do we as people communicate with each other? How do we express ourselves through creativity? As [05:42] as humans since the dawn of time have been painting on cave walls and dancing around the fire and writing stories and novels and singing to each other. And I was just really interested in how we kind of convey our experience of the world to others. And so I kind of, I got [06:00] started in software development and product management because I wanted to be in the business of creativity. And we're at a really, really unique time in human history where we actually get to witness the advent of a brand new medium, like software development and the worlds that it creates wasn't possible maybe 50, 60 years ago now. And if I'd been born in the 1700s, I probably [06:30] I don't know, new colors of paint and paintbrushes. But I wasn't. I was born kind of at the turn of the 21st century. And so I work in engineering. That's what I've been doing for the last about a little bit more than 20 years now. Working sometimes in startups, some of them other people, some of them my own. About 10 years at Microsoft and now three years at GitHub.

6:51-8:31

[06:51] Amazing. I didn't know that was a job to make new paint colors for paint brushes. Is there a color you would come up with? [06:58] Oh, man. A very, you know. [07:02] It so happens that like yellow, I think I would do a really vibrant gold sunshine yellow if I was in that business. Very positive, happy, I love it. That could be a new GitHub brand color. So today you're VP of product at GitHub. And before that you were a super senior product leader at Microsoft. And I'm always curious how that transition happens when you move from [07:28] just like a longtime senior [07:30] product leader at a larger company to taking on something like this that was an acquisition. And so I'm curious, what made you decide to kind of take this leap? And then just, is there anything interesting about the machination that went into just making that transition and figuring that out? [07:45] Yeah, yeah, it's a good question. You know, so like I said, I was working on development tools and developer services when I was there at Microsoft. Specifically, I was leading product for what they call one engineering system. It's essentially like the shared developer infrastructure for all Microsoft products like Windows and Office and Azure and things like that, as well as a kind of Microsoft's DevOps solution called Azure DevOps. [08:14] And when the acquisition happened, it was clear that [08:20] so much of the energy, so much of the focus and the innovation that was going to be happening around developer tools and services was going to be happening around GitHub. I mean, that's where...

8:31-10:06

[08:31] That's where the community is creating. That's where people are learning. That's where... [08:36] so much of the mind share of just the development community is focused. And like I said, I'm motivated. What I care about is helping people create. And it was very clear to me that there was no place that I could have a larger impact than working at GitHub. And so I really took that opportunity to make the transition out of a little bit more kind of enterprise focused internal role at Microsoft [09:06] Going where I could work on everything from, I don't know, an AI technology like Copilot to a cloud hosted development environments like Codespaces, repos, which literally every single developer on the planet is like participating in some way and get have repos in the typical year. [09:36] could reach on its own. [09:38] And [09:39] The decision to move as well, I think, was [09:44] was really focused not just on what GitHub was and maybe is at the time, but what GitHub also can be. I mean, GitHub has more than a decade, nearly a decade and a half of history of bringing developers together to collaborate on code through repositories. But in the last few years, we've, you know,

10:06-11:49

[10:06] really expanded that portfolio to include so many different parts of the developer lifecycle. Again, I talked there about Codespaces and Copilot, but it's also actions for CICD and advanced security. [10:21] And as developers, we are so much more than just where we put our code. There's a whole part of the tool chain there. And to get to an opportunity to work on so many V1 products, that is creation itself, right? To be able to build an entirely new product. [10:38] get it out to market, test it, iterate on it, and really feed on the energy that's coming back from the community. [10:46] Awesome. There's definitely a lot of energy coming out of GitHub. And what I want to spend most of our time chatting about is a product that your team helped launch Incubate, which is GitHub Copilot, which in my... [10:59] Just from my outsider perspective, it feels like one of the biggest advances in software development in, I don't know, a decade, maybe more. And it's definitely one of the most magical products out there. And your team and you kind of led the incubation and launch of the Copilot. And so I'd love to spend most of our time chatting through that. And the first question. Okay, cool. So my first question, just for folks that don't know a lot about Copilot, is just like, what is it? Can you just kind of briefly describe what Copilot is? [11:26] Yeah, sure. So, [11:29] Developers for the last 20 years or more have had essentially simple IntelliSense autocomplete. You hit the period and you get the next variable that might come up. It's helpful for moving a little bit faster through your code, helpful sometimes for remembering...

11:49-13:37

[11:49] what the particular syntax might look like for a method or a function. Copilot is essentially that magnified by many lines of code. [12:01] It is multi-line autocomplete that is fundamentally powered by an AI model called Codex, which is a derivative of another kind of one that you might be familiar with, GPT-3. [12:14] Now, when you are in the editor, it could be, [12:18] VS Code, it could be IntelliJ, it could be Vim. Essentially, as you are typing, Copilot will provide suggestions, usually in this italicized gray text that is really, to your point, [12:33] kind of magical what it's able to infer based upon the variables around it, the class names, the method names around it, your comments. [12:42] Co-pilot kind of infers what you intend to create, [12:47] and then hopefully does a pretty good job at nailing it by providing... [12:51] scaffolding code template that you can then riff on. What we tend to find is that developers love it. They really enjoy it. They kind of find themselves getting a little addicted to it because it helps them stay in the flow. As developers, we love to be in that place. I love to be in that place where I'm creating things, where I'm focusing on some [13:16] some product, some piece of software that I'm going to give to my customers, my users. The labor of remembering, you know, what's the order of parameters that need to come into a particular API? Or, hey, what's the particular syntax of this thing that I'm supposed to do? Or, oh, I've got to create a bunch of like,

13:37-15:14

[13:37] dummy data that is days of the week or months in the year. Like that's just labor. It's not creating. It's just, [13:45] typing. [13:46] co-pilot, [13:48] helps developers stay in the flow by bringing all of that information into the editor, preventing them from having to go check out documentation or watch a tutorial or go to Stack Overflow and, you know, either find an answer or worse, have to ask a question and wait for an answer. [14:06] It just brings all of that into the editor and gives the developer often multiple suggestions that they can choose from and just kind of pick and choose what is the right solution to solve the problem for the thing they're trying to create. [14:21] Awesome. What I'm most curious about, and we're going to spend time on this, is just how a product like this comes to be at a larger company. But before we get into that, what's the craziest story of someone using Copilot to write code? And I'll share one real quick. I was watching some YouTube videos to prepare for this chat, and one guy, maybe this is the Turing test of AI writing code, is he... [14:41] used Copilot to center divs. Yeah, yeah. Well, he's like, wow, this did it right. And then another guy, he's like an instructor of code on he makes YouTube videos teaching people how to code. And he's like, Copilot just gives you the answer. And so I can't make these videos as easily. I have to like turn it off. So it doesn't just give it away. And so I'm curious. Yeah, what have you seen? [15:02] There are so many of those. I mean, I'll just kind of [15:06] give a couple of recent ones that I've heard. So I was talking to one developer who was, he's actually an educator,

15:15-16:47

[15:15] And he's teaching kids how to code, usually like kind of high school age, right? So 16, 15, that kind of thing. And, you know, his... [15:27] experience matches my own, which is that many of us, we learn to code best by, not by arbitrary exercises, but by actually [15:37] building something that's going to be useful, solving problems. And so what he does [15:42] is he matches small businesses and medium-sized businesses who need to build internal tools [15:49] with essentially classes of students, like a group of maybe six or eight students, and then gives those students co-pilots. [15:58] and says here, [15:59] small business, medium-sized business, group of students. [16:04] Go build this internal tool for this business. [16:07] And Copilot is essentially kind of whispering in the student's ear, metaphorically speaking, hey, you know, here's how you solve this problem. Here's how you do this. And students... [16:17] build not only the kind of the tool, the software that the business needs, and then get to put that on their resume and their application for college and university. [16:28] But they also... [16:30] get to learn by kind of using the tools that likely are going to be part of the core DNA of the developer tool chain two, three, four years from now, as AI starts to permeate our entire stack. [16:44] So that was a pretty cool recent one that I talked to.

16:47-18:41

[16:47] That is very cool. I didn't think about just education lever here, just like making it so much easier to learn to code, not even just building code. [16:54] Yeah, I mean, and that's the thing, like, Copilot is particularly... [16:59] good not just at taking away some of the effort, but often, you know, there's learning a new language. And then there's also just wading into a code base that you're not necessarily familiar with, right? Like, I mean, heck, sometimes I don't recognize some of the code that I wrote six months ago or a year ago, it feels like I'm wading into new territory, but maybe [17:19] Maybe you need to fix a bug in an app that you don't often touch. [17:25] wading into that codebase is kind of like learning and creating a mental map for that codebase. [17:30] One of the really magical pieces of Copilot here is that AI is collecting context of the application you're going into. [17:39] And so it can help you build that mental map and learn the code base, even if it's a language that you're already familiar in. [17:46] Awesome. Okay, so going back to the beginning of Copilot and how it started, I'm always curious how a project that ends up being a huge deal to a larger company begins, and especially how it builds momentum, how it gets buy-in, and then just kind of gets out the door. And so you talk about just the original seed of this idea, like who did it come from, who had the original vision, how did it come from? [18:06] How did this idea emerge and build momentum where you put resources into it? [18:11] Yeah, yeah. Oh, wow. What a long and, I don't know, depending upon your point of view, a sordid or exciting story that is. So, yeah. So, Microsoft and OpenAI have been collaborating for quite a while now on large language models, making its way into kind of all different experiments and different parts of both Microsoft's software portfolio, as well as just kind of helping OpenAI by providing, you know, the compute necessary.

18:41-20:19

[18:41] It takes massive amounts of compute to train these models. And they were mostly large language models. And so a couple of years ago now, it kind of dawned on us that, well, language models aren't just English and Spanish and German and Korean and English. [19:00] Japanese, right? But [19:02] Python and JavaScript and Java and C# and Clojure. All of these are languages too. In fact, [19:09] they're kind of nice from an AI perspective because they're relatively constrained in terms of their semantics. The number of words, and I put that in scare quotes as it were, that can be expressed in Python, for example, is much smaller than the English language, which has all sorts of different grammar rules and nouns, verbs, adjectives, adverbs. [19:37] We started to see what it would be like to actually bring [19:43] code to these large language models. And the way that I actually got introduced to it is kind of funny. Microsoft and OpenAI had this idea, [19:53] And at the time, one of the teams that I was responsible for was GitHub's infrastructure team, the team responsible for our data centers, our reliability, our uptime. [20:04] We noticed one day that we were getting... [20:06] hammered, I mean absolutely hammered with a tremendous amount of clone requests. And we're like, "Oh my gosh, is this like a denial of service attack? How are we going to respond to this? What's going to happen?"

20:19-22:03

[20:19] We figured out pretty quickly that it was actually OpenAI. They were cloning all of our repositories to harvest the data out of GitHub. It's totally legit practice, but it does have a real consequence. And we were able to step in and mitigate it very quickly. There was not a reliability, an uptime incident there. But we're like, hey, y'all, cool, love this thing. Let's see if we can get that data to you in a more responsible way, in a way that's packaged a little bit more to me. [20:49] your needs. And so what we did is just like the year before that, we had actually created a snapshot [20:59] of GitHub's public code for what we call the Arctic Code Vault. [21:05] Essentially, this is up in like way in the northlands of Finland. There's a seed vault. [21:12] We were like, "You know what? Seed balts are really there to preserve the diversity of the world's flora in seeds in case of some crazy, either natural or man-made disaster." [21:25] Another really important asset to the world is our code, our open source. This represents actually a lot of the collective, well, certainly software, if not intelligence of the modern world. [21:41] We had put this snapshot of public repositories on this silver film that would be preserved for thousands of years in this Arctic code bulb. Well, we took that same data snapshot and we brought it to our friends over at OpenAI to see what can we do with these large language models built on public code.

22:03-23:29

[22:03] It turns out we can do some pretty cool things. Just like a translation tool that goes from English to Spanish, Spanish to German, you can also go from English to Python, or Python to C#. [22:18] We're like, "Okay, this is cool. We can start to get not only translation, but a little bit of predictive text here as well." And we're all, I think, fairly already familiar with predictive text already in our code editors as IntelliSense. But in, I don't know, you go to your favorite word processor and chances are that you've got some kind of predictive text happening there as well. [22:41] and we started experimenting with different user experiences, right? [22:47] Do we want it so that you... [22:50] I don't know, right click and get a little side panel that comes up with a bunch of different options for things that you might want here. [22:58] That was nice because it would give you whole functions. [23:01] But it's kind of out of the... [23:03] And it was out of the cursor, right? And you had to really, even if you weren't switching over to a different window, you still had to switch over to a different panel, which itself was a little bit distracting. And we eventually came to this idea of inline autocomplete. We were able to, with the kind of partnership of some of our friends over on the Microsoft side of things, partner with our friends in Visual Studio Code.

23:33-25:15

[23:33] you're, [23:34] for this multi-line autocomplete but we've got an idea for how this might work you know [23:40] played around with the actual presentation of it. What should the keystrokes be? What should the [23:47] Presentation layer being the gray italicized text seemed to be a good way of indicating that it was ephemeral, as it were. [23:55] and [23:57] Pretty early on, we landed on this user experience that is... [24:02] co-pilot as most developers experience it today that was now i want to say that was at least [24:09] 16 months ago, 14, 16 months ago. [24:13] Since then, we brought it to developers. Just to double click on that. So you're saying just like less than a year and a half ago, this kind of really started as a project and now it's out to the world. That is exactly right. That's exactly right. Yeah. So it's about a year and a half ago. That's insane. What was that period between OpenAI almost taking down GitHub to, I guess, that point? [24:43] and then us really arriving at the user experience. [24:49] Part of that was, frankly, a lot of really smart researchers at OpenAI experimenting and doing what only world-class AI researchers can do. It was a lot of them experimenting, occasionally asking for updates to the data set, tossing back to us a model that we might play with and tinker around with. These models have literally thousands of parameters that you can pass to them.

25:19-27:02

[25:19] and Codex and then the transition from that to something like Copilot. [25:24] It was not just like the model, creating the model is one thing, but then figuring out how to use the model in terms of what parameters do you want to kind of like adjust for, what do you want to optimize for in terms of like... [25:38] A great example of this is performance, right? [25:42] When you're in a code editor... [25:44] You don't necessarily want to type, type, type, and then have to wait one second. [25:49] two seconds, three seconds. [25:51] to get a suggestion back when your entire goal is to stay in the flow. And so we would run experiments to see how many milliseconds are the right amount, [26:01] such that a developer doesn't feel like they're being interrupted by co-pilot and a suggestion. What's the answer to that? It seems like right now it's around 200 milliseconds. [26:11] So depending upon where you're in the world, your latency can go up or down a little bit from there. But it seems like the sweet spot is somewhere around 200 milliseconds. Good to know. And we also experimented quite a bit. So it's not just about the model, but it's also about what you feed the model. How do you prompt the model to return back a useful response? And so this kind of began a journey of experimentation for what we call prompt crafting. [26:41] the way this started, it sounds like basically it was kind of this fortunate accident where OpenAI just did something that you didn't expect. [26:47] And then somebody within this like PhD group that you described is like, oh, wow, maybe we could do something really good with this. Is that kind of how it began? That's fairly accurate. Yeah. I mean, you know, we had a model that really like.

27:02-28:38

[27:02] was amazingly good, like a step-level change in actual intelligence, right? And then marrying that up against a really good use case that actually changes... [27:18] developer's fundamental experience of the creation process, the creative process. [27:24] was there kind of a... [27:27] point at which it was clear to you or leadership in general, like we should double down on this thing, go big, where this smaller team was working on this idea. And then they're like, oh, wow, this is going to work. Or is it always like we will bet on this thing. This is such a big and great idea. We're going to invest resources for sure from the beginning. Yeah. Yeah. So the original team that was working on Copilot at GitHub was, you know, [27:57] And essentially, their job is to work on second and third horizon projects, what some folks might call moonshots, right? Things that we never really expect to work in the next one or two years, but might three, five years down the line actually turn into something meaningful. Is there a concrete definition of horizon two and three? Is it like number of years out, like Amazon style? [28:22] Not necessarily a concrete definition. For me, I usually ballpark it as first horizon is the next year, second horizon the next three years, third horizon next five years, but we generally think of it more as...

28:38-30:11

[28:38] like [28:39] a measure of ambiguity and confidence level more than calendar dates. [29:09] Gusto, Pipe, ClassPass, and Marketa. Modern Treasury's robust APIs allow engineering to build payment flows right into your product, while finance can monitor and improve everything through a sleek and modern web dashboard. Enabling real-time payments, automatic reconciliation, continuous accounting, and compliance solutions, Modern Treasury's platform is used to reconcile over $3 billion per month. They're one of the hottest young fintech startups on the market today, [29:39] I'd love to spend a little bit more time on this. So interesting. Is this like a Microsoft thing? Just having these three horizons and a certain percentage of resources are bet. [29:55] on different horizons? Yeah, I would say it is not necessarily a Microsoft thing, but it's definitely at GitHub, how we have really contextualized it. Not to say that there aren't teams at Microsoft who might also use that methodology, but

30:11-31:42

[30:11] Where we've been really maybe explicit or intentional about it is at GitHub, where we've actually ring-fenced a team to think about that Horizon 2 and Horizon 3 work and kept them separate. [30:24] from you know EPD uh EPD here being engineering product and design the folks who are working on building you know productized operational like [30:34] products that we bring to market and we either give away or monetize in some way. [30:39] This is so interesting. There's a lot of companies that have these sorts of R&D groups, New Product Experience team at Facebook, and Google has one. I'm not sure how many successes have come out of these teams from what I've seen. And I'm curious, what have you, and clearly you had a huge success as far as I can tell so far. Is there anything you've learned about how to do this where you invest in these big moonshots within a larger company? Yeah. I mean, I think [31:09] they hire really smart people, attract smart people, and... [31:14] Give them the opportunity to be creative. Don't expect anything out of them that is going to turn into a moneymaker or something that is going to be beholden to people. [31:27] fundamentals around security, privacy, uptime, accessibility, all that groovy kind of stuff up front. They need space to create an experiment. And also, [31:38] When you do get to a place where...

31:42-33:13

[31:42] That team... [31:43] has an idea that is clearly connected to a representative set of customers. [31:50] who have a genuine problem. [31:52] And there is signal with at least medium confidence that this solution, whatever it is, solves it in a novel way. That's the time to start thinking about. [32:04] Okay. [32:05] like let's actually put a little bit of, I'm going to call this market testing. It's nothing so formal as market testing. It's really like, let's start to actually, [32:15] bring prototypes of this in front of more and more customers to kind of test it out and see, hey, is this [32:21] Is this actually solving a problem for you? Is this something that you would use? And this is where the transition between Next and EPD at GitHub really, you know, really... [32:34] started. And this is actually where my role in the product lifecycle kind of really started to increase. You know, I had kind of been in [32:44] tight connection and kind of been monitoring the work and consulting a little bit with the next team prior to that. But it was that moment when we identified that, okay, this is actually something real, [32:56] Customers are saying, developers are saying, [33:00] this is magical, this does something extraordinary that I could not do on my own, that we started to think about, okay, how do we transition this over? [33:09] And so from there, [33:11] What we really did was like, "Okay,

33:13-34:52

[33:13] We think we've got a hit here. We think we've got something that we can actually bring to developers. And so we made an intentional decision to take some of the researchers who were in the next team and for a finite period of time, move them over to create a new EPD squad. We want them to be researchers, but we need to do knowledge transfer. [33:43] a team that could eventually operationalize and productize. And that kind of began the technical preview where we started to invite people [33:51] tens of thousands, then hundreds of thousands to the technical preview. And in that technical preview, when we started to see crazy, mind blown emoji tweets and threads on Hacker News about people getting really, really excited about it, that's how we knew it was time to start scaling. [34:12] And it was time to really start thinking about how do we do hiring so that we can build in some insulation around these researchers so that they can eventually go back to. [34:23] GitHub Next to do what they do best, which is... [34:27] Be innovative and creative and think about the next moonshot. That process, that took... [34:33] Well, we're actually still kind of at the tail end of it now. Here we are, you know, like I said, roughly a year and a half after kind of the initial kind of creation of the product, having gone through technical preview, have achieved general availability. We've now hired in a team around them.

34:52-36:27

[34:52] and the researchers starting actually as early as last month have started to gradually move back over to GitHub Next. And multiple EPD squads actually are now taking the product forward. [35:07] and starting to respond to customer feedback to think about, okay, how do we now as a product team carry this roadmap forward? [35:16] from an idea that originated [35:19] and, [35:21] Get up next. [35:22] I love that insight of bringing the people along and not just kind of like, cool, we'll take it from here. If you were to build a team like this again somewhere, let's kind of R&D. [35:32] Horizon 3 or 2 team. Is there anything else you would... [35:36] do differently? Any lessons you take away from this experience for maybe founders that are, or PMs working at larger companies that are like, "Hey, we should have something like this." [35:45] Is there anything else that you find is important for making something like this successful? [35:49] The criteria for moving [35:51] researchers back into their R&D team, whatever that happens to be for your organization. That can't be based on a calendar. [36:02] It needs to be based on [36:04] a replacement of, [36:06] End seat. [36:07] who's actually doing the job and has picked up all of the skills necessary. [36:13] And only then can the researcher move back. [36:16] So make sure that you've got continuity of expertise and skill sets and domain familiarity before you move over. I feel like we've managed that pretty well today.

36:27-38:08

[36:27] As well, it's critical that the... [36:31] team who is taking over from the R&D shop feels like they have control over their own future. You can't [36:39] really delegate roadmap to an R&D team, the team who's responsible for maintaining the product, for building the product, who has the closest feedback loop with the end customer, they're the ones who really need to own and feel like they control the roadmap. And so making sure that you're not outsourcing innovation exclusively to an R&D team, but that is happening within the [37:09] over the idea and over the use case and the customer. [37:13] Last I would say here is really that engineering fundamentals, [37:19] in a lot of ways are the contracts that differentiate an R&D team from an operational product team. And bringing that fundamentals process into it is going to feel [37:34] candidly a little bit unnatural to the researchers and [37:39] That takes, therefore, a little bit of cultural change management for everyone to just kind of like adapt their way of working and understand that we're graduating from an experiment and a research project to an operational product. And often because those researchers are, you know, they're the first wave that come over, they're the seed of the project. It's going to feel a little bit unnatural to them, and they probably won't have all the right skill sets in order to make that transition.

38:09-39:46

[38:09] You've got a good mix of engineers who are comfortable maintaining a service as well as [38:16] you know, [38:17] engineers and researchers who are really thinking about what is the idea that we've created? What is the new thing that we brought to market and can bring that vision to it? [38:27] Yeah, I can totally see the challenge that comes from [38:31] This was my thing. I've been working on this. What are you guys doing to this project? Where is this going? I'm not sure. And then there's all these new asks that are coming at you. Like, oh my God, this was so much fun. And now I have to scale this freaking thing. [38:45] Well, and I mean, this is the best problem in the world to have. Talk about kind of customer ask. [38:51] For Copilot in particular, the amount of chatter, the amount of customer feedback that was coming in, especially for us with AI. I mean, the world is still figuring out AI, candidly. I mean, we're getting a lot, lot better at it, especially in the last couple of years with things like DALI and Copilot. [39:13] But, [39:14] It brings with it not only... [39:16] engineering challenges, but also, frankly, ethical challenges, right? Like, you know, and legal challenges, like making sense of how we actually, what our expectations are of AI. And if AI produces something that is [39:32] offensive, [39:34] Who was at fault? [39:35] you know, [39:36] Our stance on it, what we ended up coming to is actually the framing of Copilot as an AI pair programmer.

39:46-41:39

[39:46] I think is a useful one. You know, [39:48] Paraprogrammer, I suspect most of your listeners will know, but like a paraprogrammer is usually two developers sitting side by side, working on a problem together. One's at the keyboard, the other one's kind of like, you know, helping them talk through it, talk through the ideas and, you know, make corrections, that kind of thing. [40:04] Well, [40:05] If Copilot is your AI pair programmer and [40:09] They're whispering crazy stuff into your ear and then bringing politics into it or gender identity into it or I don't know, whatever other... [40:18] you know, they're spouting off slang and slander and all that kind of stuff. You're probably not going to be able to focus on your work, right? It's going to be really distracting. And so really kind of coming down to some principles about what is the use case we're trying to solve, what is appropriate, I put this in scare quotes, behavior of the AI kind of bot sitting side by side with you, helped us kind of create some principles or some guidelines. [40:48] for the developer experience that we wanted to create. I love that just kind of keep creating like a persona of the thing to help you inform how to how the behavior of the thing should work. How do you work through these challenges? Is it like discussions with you and the legal team? And I don't know, like these ethical things are really tricky. I imagine. How do you approach something like that as a product team? Yeah. [41:09] It is conversations with a very, very wide cast of characters. This product in particular, I probably spent more time with legal than any other product that I've ever been responsible for. All wonderful, creative people. But it's not just legal. It is also privacy and security champions. It is, frankly, developers, the people who are using it, listening to them. Hey, what works here? What doesn't work for you here?

41:39-43:12

[41:39] this offensive? Why is it not offensive? When we started out, [41:44] I'll continue on the example of the crazy pair programmer whispering crazy things into your ear. When we first started out, we didn't really have any filter on Copilot whatsoever in the very, very, very early days. [41:58] And then eventually we're like, okay, [42:01] It needs to be... [42:02] slightly more controlled experience. We need to edit out some of the most egregious stuff. And so we introduced a simple block list of words. And these block lists are always fraught with peril, which words are okay, which words are not okay. All of a sudden we become editors of language, and that's kind of a scary place to be. I'm not comfortable with it at least, but at a certain [42:32] Yeah. And so, you know, often we would get feedback from developers of like, hey, you know, [42:40] This particular word was blocked and that it was blocked either was offensive to me or prevented me from being able to get good value out of the product. Oh, man. And so... [42:52] always kind of like dancing the dance of like editorial content. We're actually at a place now where we're able to partner with the Azure Department of Responsible AI. And they've created some really extraordinary models that help detect data.

43:13-45:08

[43:13] I'll call it sentiment, for lack of a better word, but basically when there is something that is patently offensive. Because there are some words that in some contexts may be offensive and in some contexts may be totally reasonable, right? Especially when you get into software for medical kind of scenarios, right? [43:43] also do a better job than we could with crude or simple block lists is maybe another proof point both of how AI as a solution for common development problems, [43:57] is getting way better at solving more parts of our stack or filling in for more parts of our stack. And how, at least in our case, we were pretty fortunate to be able to deliver on or depend on a parent company's contributions. [44:11] to solve a real acute problem that GitHub probably could not have solved on our own. I never thought that a copilot would be like, you would have to worry about it saying things that are crazy. So that is wild that you guys have to deal with that. And wasn't it a Microsoft that had that bot that got turned really negative and shut down? It was. I don't know if it's named Talia or something like that. Yeah, something like that. Yeah, something like that. Yeah, we don't want another one of those incidences. Yeah, wow. [44:41] me think about is your your team is kind of at the forefront of ai in this applied way and i'm curious what your thinking is on just like where this goes for developers especially like i saw a stat that maybe 40 of people's code is now written by copilot i don't know if that's right but like is the vision in the future becomes something like 90 where do you see this all going yeah yeah and so just to put a fine point on that stat yeah it is uh 40 is specifically for python developers

45:11-47:00

[45:11] language. [45:12] Because as you might imagine, some languages have better representation in kind of the public domain than others. And usually both the volume and the diversity of training data correlates with the quality of suggestions, which is then represented by either the number of lines written or the acceptance rate or any one of a number of other metrics. Awesome. In aggregate. Yeah, totally. We see it range anywhere from the upper 20s to the 40s across all the different languages. [45:42] Thank you. [45:42] Just to throw this out there, as a not great engineer, I used to be an engineer for about 10 years, I welcome our AI overlords writing all my code. [45:51] And so I'm excited for this to do more and more. And yes, I'm curious where you think this goes. [45:57] It does. It enables even mediocre developers like myself to be able to do some pretty amazing things. All right. But where is it going? Like... [46:07] So first, I think [46:10] I hope it's obvious to most developers that AI is... [46:16] going to infuse pretty much our entire development stack together. [46:20] in the not so distant future. Copilot is really just kind of the very tip of the spear for a lot of innovations and you know better managing maybe our build queues or [46:36] helping to [46:37] Here's a great one. [46:39] I don't know about you, but often the comments that I get with commit messages and PRs aren't super great. It kind of, you know, it puts a lot of effort onto the code reviewer to go figure out what the developer was actually trying to do. What if AI could summarize all of your changes with your pull request?

47:00-48:39

[47:00] And you just have to, as the contributing developer, just review it to make sure it's accurate, send it on its way, and you don't have to put an extra effort for that. There are lots and lots of different opportunities for AI to essentially be able to take some of the drudgery out of our work so that we can focus on creative acts. [47:30] What are the design patterns I'm trying to create? [47:33] What is the... [47:34] end-user experience or the outcomes that I'm trying to drive with my code, and that I can kind of rely on Copilot to scaffold out a lot of that, [47:45] so that I can focus on more creative work. And that is really what I hope for our industry. [47:53] five, [47:54] 10 years from now. [47:56] is that not only will we be inviting more developers or more people to become developers, right, by essentially providing a layer of abstraction a little bit or at least a little bit of a kind of a hand in development, but that also the... [48:13] really experienced developers are focusing on much larger problems and focusing on outcomes and creativity rather than really kind of low level kind of difficult rote memorization of things like syntax or ordering of parameters and the like. Great. Yeah. And like, if nothing else, it'll keep people from just having a tab up stack overflow, copy and pasting every function that

48:43-50:36

[48:43] flow to stay in business, but I would mind a little bit less context switching myself. So in the experience of scaling this thing, what would you say has been the biggest challenge, either technologically or even operationally, just kind of scaling it to a real product that people are paying for? [48:59] Yeah, so there's a few dimensions of that. One is a problem that's very much of [49:06] of our time in the world, namely that supply chains have been disrupted dramatically over the course of the last few years. And it turns out that co-pilot for both training and operating the models requires some very rare and unique GPUs that there's not a lot of global supply of. [49:29] And so part of it is just like, can we get enough hardware in order to run these things? We've actually earmarked quite a bit of capacity and we are greedy, greedy, greedy for more capacity globally. As soon as we can produce those chips and get them in data centers, we do it. So that's been one kind of unique challenge. Wow. I would also say here that, you know, [49:56] Operationally, another challenge has been how do we create things [50:03] a model that the community really feels like [50:08] ownership over, right? And like the dialogue that's had to happen as we brought an AI tool to market, especially one that is trained on public code, right, has required a lot of dialogue between us and our community. And every good product manager should be spending as much of their time as possible with their customers, with their, you know, potential customers. Copilot in particular is,

50:36-52:09

[50:36] has been a more complicated kind of rollout because we as an industry, as a society, are still figuring out how to make sense of it. And so the amount of kind of give and take between developers and us as a product team has really required us to scale up more of the product team than it has the engineering team. Interesting. And why is that? [51:04] It's a couple of different reasons. One, like I said, we are trained on public code and not all of the community is really sure when is it okay to train a model on public code? When is it not okay to train a model on public code? Is Copilot producing secure suggestions? Is Copilot producing buggy suggestions? There's a lot of doubts. There's a lot of very healthy skepticism. [51:34] co-pilot. We owe it to ourselves as a community to be skeptical of any AI because just like there's great potential for benefit, there's also great potential for harm. People keeping us accountable, how are you preventing things like model poisoning? Is there going to be a new attack vector that we just haven't really thought of yet around AI that might produce negative [52:04] and responsible job of that by making sure that first,

52:10-53:41

[52:10] We are very clear that Copilot is not a replacement for a developer. It will never be. [52:16] We do not want... [52:18] co-pilot auto-generating code where a thinking, reasoning, breathing human being is not on the other side of that keyboard making reasoned decisions. [52:30] We do not want Copilot to replace any other part of the stack, whether it is static analysis tools or unit tests or whatever kind of measures you're putting in. [52:43] today to make sure that your humans produce good quality code, [52:46] We want you to keep all of those same systems in place to make sure that [52:50] humans who are leveraging tools like Copilot continue to produce that good quality code. [52:56] But, you know, [52:57] There's a lot of, at the same time, anxiety of like, [53:01] Where is AI stack? Is AI eventually going to be? This is back to your question about where will we be 5, 10 years from now? Will it be writing 90% of the code? We don't want Copilot to be that. We don't want it to replace anything. We want it to augment. The idea here is really that AI is. [53:19] is an enabler. [53:22] for developers to focus [53:25] on the creative work, to stay in the flow, to [53:29] be able to move faster, right? And kind of working through those anxieties, working through that healthy skepticism, [53:38] takes conversation. It takes dialogue.

53:41-55:29

[53:41] And that takes us, you know, on the product side, having kind of that guided conversation with the community. It feels like it connects back to your education back in the day, philosophy and literature. And how convenient is that? [54:11] esoteric armchair ponderings. It's actually applicable to the real world. Maybe a final question before we get to our very exciting lightning round. [54:22] So just looking back at this whole experience of one just... [54:26] building, incubating, launching this big, bold bet within a big company. You can go in either direction, either just like any lessons on just like taking a bold bet versus incremental wins and how you think about investing in these two kind of categories. [54:39] Or just within a large company, a lesson of just how to build something like this, like a massive new product from just like a seed of an idea to a large new business line, potentially. Yeah. So as a... [54:52] both a product manager and a portfolio manager of multiple products. I'm responsible for multiple product lines at GitHub. Like the allocation of time, of focus, [55:05] energy and resources becomes a really [55:10] challenging question, the answer to which isn't always the same depending upon the time, world circumstances, organizational circumstances, technology circumstances. As a general rule, as a general principle, I certainly try to make sure that we're always reserving

55:29-57:13

[55:29] some capacity for... [55:31] bold, audacious, experimental research projects. You can kind of think of those really uncertain bets as being [55:42] 5 to 10% of the team's capacity. [55:45] About 25, maybe 30% of the team's capacity should generally be on just operations. Like how do we keep our in-market products meeting customer expectations? And then the remainder of it, what is that about 60% or so, is really on incremental progress for our in-market products. [56:15] realized payoff for the larger bets that we made one, two, three, four years back. [56:24] And from a rough distribution, that's generally how I run my larger teams. That works when you have larger teams though. At startups where we were pretty much only a big bet, obviously your percentages get very different and it becomes a matter of you're all in for that one team. [56:47] proverbial lottery ticket. [56:50] Awesome. Thanks for sharing that. I was going to ask you the percentages that you recommend, and so thank you for getting to that. So with that, we've gone to our very exciting lightning round. I'm just going to ask you five questions briefly, and just whatever comes to mind, whatever answer you have, let's do it. Sound good? Okay. What are two or three books that you recommend most to other people?

57:13-58:54

[57:13] Oh, good question. So one of them [57:16] is a book on user experience called Make It So. It's a reference back to Star Trek. And the idea here is essentially that user experiences that are presented to us in sci-fi, [57:32] often make their way into... [57:35] our everyday products and tools 20-30 years down the line. It is a great [57:42] eye-opening, illuminating, and just really fun book. So that's one. And then completely different take. I'll go outside of tech and I'll just do entertainment value. There's a David Foster Wallace book called Brief Interviews with Hideous Men that I love. It's a collection of short stories. And [58:06] is it is like if you're watching a movie and like the villain gets their opportunity to like have their big speech, which kind of explains why they are who they are. Right. And makes them maybe a little bit vulnerable in that moment. [58:21] It's that speech like 10 times over for different people. [58:25] hideous people terrible terrible people so interesting read i recommend it i love that reminds me of this book that is the interior design of dictators and they show you their like homes of like saddam hussein hitler and all these guys dude oh my gosh that's awesome i gotta find that one you'll have to uh you'll have to send it to me it's like a found one at an old bookstore like used bookstore so i don't know if they're around anymore but well i'll find

58:55-1:00:41

[58:55] Okay, second question. What's a favorite other podcast that you like to listen to or recommend if there's any? [59:02] Oh, God, there's so many. I consume hundreds of hours of podcasts every month. It is crazy. [59:11] Yeah, I am. So I can choose many. I'll give you just one. So the Memory Palace with Nate Mayo is an excellent storytelling podcast. He does about 20 minutes vignettes. [59:26] usually selected from American history. [59:30] He also was the artist in residence at one of the museums in Washington, D.C. And if you're ever at I think it's the American History Museum or something like that. If you're ever there, you can go to like different rooms in the museum and he'll tell you stories about the kind of the objects or the rooms that you see there. It's a magical experience recommended to anyone. Wow. I love those. What's a recent movie or TV show that you've really enjoyed? [1:00:00] I don't know how this counts as recent, but it's one that I watched recently, which was Arrival. Yeah, that counts. Arrival. So a movie about ostensibly about aliens, but is really about language and memory. And I found that really interesting. [1:00:18] Really compelling. [1:00:19] Have you read Te Ching's books and short stories? I have not. I have not. Oh, wow. Oh, you would love it. It's like that rival is from one of his stories, I believe, is one of his stories. And there's a whole book of many more short stories by the same guy. And they're amazing. Brilliant. Okay. Yeah. I've got my weekend cut out for me then. There you go. Just leave work and get to reading.

1:00:43-1:02:20

[1:00:43] What's a favorite interview question that you like to ask in interviews? Let's see here. [1:00:49] challenging one. This is kind of my icebreaker interview question, particularly for like, [1:00:54] more early to mid-career product managers. [1:00:57] So I ask them to teach me something new in one minute. [1:01:02] And so usually I'll pull up my phone and I'll start the timer. I'll give them a second to think about it and start the timer. And they're graded on three different criteria. So one is completeness. Do they actually finish the lesson inside of one minute? Two is complexity. [1:01:20] So, you know, it's one thing if you teach me how to, I don't know, pat my head and [1:01:26] rub my stomach at the same time. [1:01:28] That's another thing if you teach me something about 18th century art and its connection to religious trends at the time. And then last is really serious. [1:01:39] Clarity, oh yeah, clarity is the last one. Clarity is like, [1:01:43] Do I actually understand? Did I learn something by the end of the lesson? Did they convey the idea fully and wholly? I have to ask, what's the most interesting thing somebody has taught you in this question? [1:01:56] My go-to throwaway answer there about, did they teach me something about 18th century art and its connection to religious trends at the time? [1:02:04] Someone taught me that. It was... [1:02:08] astounding. It was actually a university candidate, so someone who was still in university, and she was from Vanderbilt University. And was that a strong yes hire?

1:02:20-1:03:54

[1:02:20] It was an extremely strong answer. She was freaking amazing. I like, yeah, such a smart person. Amazing. Final question. Who else in the industry would you say you most respect as a thought leader or just influence person? There are many... [1:02:38] But I think... [1:02:39] for today i would probably i'd probably [1:02:44] beat myself up if I didn't say Uga D'Amour. Uga is the primary researcher. [1:02:50] who really kind of like is the true innovator for Copilot. He deserves... [1:02:56] Credit for the initial work and is a brilliant technologist and futurist. I really, really respect him a lot. [1:03:05] Amazing. Cool call out. Ryan, this has been so fascinating. You guys are at the forefront of so much interesting work. I honestly can't wait for a co-pilot for my newsletter so that I can do less work. Maybe that'll come someday. But in any case, I'm excited to see where this whole thing goes. [1:03:23] Thank you for being here. Two last questions. [1:03:25] Where can folks find you online if they're curious to learn more, reach out? And then is there a way that listeners can be useful to you? Yeah. So easy one. How can folks find me? I am Ryan J. Salva everywhere. [1:03:38] Twitter... [1:03:40] GitHub, any, you know, pick your choice. LinkedIn, Ryan J. Salva. And then how can folks peaceful meet? Like, [1:03:48] Please, like there is a 60 day free trial of Copilot that is, you know,

1:03:54-1:04:34

[1:03:54] there for everyone to pick up and use and go try it out and when you do [1:03:59] posts either on Twitter or Hacker News or on discussions, GitHub discussions, your experience. Give us the good feedback, give us the bad feedback. I am so hungry to see how people are using it in novel ways and where they're running up against kind of the rough edges, too. Like I said, there's lots of room for us to grow and improve from here, but [1:04:24] I'm pretty confident that developers will be pretty freaking amazed at what it's already capable of. [1:04:29] Awesome. Thanks for being here, Ryan. Yeah, dude. Thank you so much. It's been a lot, a lot of fun.

Want to learn more?