Lenny's Podcast: Product | Career | Growth - The role of AI in product development | Ryan J. Salva (VP of Product at GitHub, Copilot)

Episode Date: September 4, 2022

Ryan J. Salva is the VP of Product at GitHub, where he led the incubation and launch of Copilot. Copilot uses OpenAI’s ML engine 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.—Find the full transcript here: https://www.lennyspodcast.com/the-role-of-ai-in-new-product-development-ryan-j-salva-vp-of-product-at-github-copilot/#transcript—Where to find Ryan J. Salva:• Twitter: https://twitter.com/ryanjsalva• LinkedIn : https://www.linkedin.com/in/ryanjsalva/• Website: http://www.ryanjsalva.com/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—Thank you to our wonderful sponsors for making this episode possible:• Amplitude: https://amplitude.com/• Athletic Greens: https://athleticgreens.com/lenny• Modern Treasury: https://www.moderntreasury.com/—Referenced:• GitHub Copilot: https://github.com/features/copilot• Make It So: Interaction Design Lessons from Science Fiction: https://www.amazon.com/Make-So-Interaction-Lessons-Science/dp/1933820985• Brief Interviews with Hideous Men: https://www.amazon.com/Brief-Interviews-Hideous-Foster-Wallace/dp/0316925195• The Memory Palace podcast: https://thememorypalace.us/• Arrival: https://www.hulu.com/movie/arrival-6ec67b11-b282-4383-85ac-38c4731b40e4• Oege De Moor’s LinkedIn: https://www.linkedin.com/in/oegedemoor/—In this episode, we cover:[04:39] Ryan’s background and how he became involved in development[10:46] What is GitHub Copilot?[14:44] How GitHub Copilot can be utilized for education[17:46] How GitHub incorporated AI models with computer languages[27:24] Project horizons: delegating tasks based on confidence levels[30:39] How to put together a development team for “moonshots”[35:22] When and how to transition your R&D team smoothly[38:28] Dealing with ethical issues surrounding AI[44:40] The future of AI in development[48:48] Challenges with scaling Copilot[54:23] Allocating your energy as products scale[58:17] Lightning round —Production and marketing: https://penname.co/ This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe

We had actually created a snapshot of GitHub's public code for what we call the Arctic Code Vault. Essentially, this is up in like way in the northlands of Finland. There's a seed vault. And we're like, you know what? Seed vaults 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. But 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 like,

intelligence of kind of like the modern world. And so we had put this snapshot of public repositories on these like silver film that would be preserved for thousands of years in this Arctic Code Bowl. Well, we took that same data snapshot and we brought it to her friends over at OpenAI to see like, okay, what can we do with these large language models built on public code? Well, it turns out we can do some pretty cool things. Ryan Solva is a 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. If you haven't heard of it, it uses OpenAI's machine learning and digital. to auto-complete 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, build momentum, and then launches, especially at a big company like Microsoft, and especially a product like co-pilot that has surprising ethics challenges, scaling challenges, business model questions. 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 Solva. If you're setting up your analytics stack, but you're not using amplitude, what are you doing? Amplitude is the number one most popular analytic 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 self-service product data to 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. This episode is brought to you by Athletic Greens. I've been hearing about AGIWant on basically every podcast that I listen to, like Tim Ferriss and Lex Friedman, and so I finally gave it a shot earlier this year,

and it has quickly become a core part of 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 evolving 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 in 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, and five free travel packs with your first purchase.

All you have to do is visit athletic greens.com slash Lenny. Again, that's athletic greens.com slash Lenny to take ownership over your health and pick up the ultimate daily nutritional insurance. 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.

I'm excited as well. 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 what you studied in school and then briefly just how that led to your career in product management? Wow, you're going to make me remember all the way back to school. Okay.

Yeah, so back in school, I was not a classic software engineering CS major. I studied the kind of esoteric and. answer is philosophy of aesthetics and 20th century critical theory. The easier access answer is philosophy in English. But primarily, it was really about like, how do we as people communicate with each other? How do we express ourselves through creativity? We like, you know, 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 got started in software development and product management because I wanted to be in the business of creativity. And like we're at a really, really unique time in human history where like we actually get to witness the advent of a brand new medium, like software development. like software development in the worlds that it creates wasn't possible, I don't know, maybe 50, 60 years ago now. And, you know, if I'd been born in the 1700s, I probably would have been the guy making, I don't know, new colors of paint and paint brushes. But it 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. Amazing. I didn't know that was a job to make new paint colors for paintbrushes. Is there a color you would come up with? Oh, man. A very, you know, it so happens that like yellow.

I think I would do like a really like, like vibrant gold sunshine yellow. If I was, you know, in that business. It's very positive, happy. I love it. That could be a new GitHub brand color. So today you're VP of 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 just like a longtime senior 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? 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 a 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.

And when the acquisition happened, it was clear that 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 the community is creating. That's where people are learning. That's where so much of the mindshare 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 to get going where I could work on everything from. I don't know, and AI technology like co-pilot to a cloud-hosted development environments like code spaces, repos, which literally every single developer on the planet is like participating in

some way and GitHub repos in the typical year. And so that was like, that was what I wanted to accomplish. It's just like, how do I get more connected to the community, especially the community outside of what Microsoft could reach on it on its own? And the decision to move as well, I think was really focused not just on what GitHub was and MAB 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 really expanded that portfolio to include so many different parts of the developer lifecycle. Again, I talked there about code spaces and co-pilot, but it's also actions for CICD and advanced security. 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, like that is creation itself, right? To be able to build an entirely new product, get it out to market, test it, iterate on it, and really feed on the energy that's coming back from the community. 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 co-pilot. Which in my, just from my outsider perspective, 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 launched 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? He just kind of briefly described what co-pilot is? Yeah, sure. So 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 what the particular syntax might look like for a method or a function. Copilot is essentially that magnet. by many lines of code. It is multi-lined 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, GPT3. When you are in the editor, it could be VS code, it could be IntelliJ, it could be them. Essentially, as you were typing, copilot will provide suggestions, usually in kind of this like italicized gray text that is really, to your point, 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. Copilot kind of infers what you intend to create and then hopefully does a pretty good job at nailing it by providing 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 products, 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's supposed to do? Or, oh, I've got to create a bunch of, like, 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 typing. Copilot helps developers stay in the flow by bringing all of that information. information into the editor, preventing them from having to go check out documentation or watch a tutorial or go to Stack Overflow and either find an answer or worse have to ask a question and wait for an answer.

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. 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 like 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 touring test of AI writing code is he used co-pilot to center divs.

Yeah, yeah. 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 immediately. And so I can't make these videos as easily. I have to like turn it off so that doesn't just give it away. And so I'm curious, yeah, what have you seen?

I mean, there are so many of those. I mean, I'll just kind of give a couple of recent ones that I've heard. So I was talking to one developer who was, he's actually an educator. And he's teaching kids how to code, usually like kind of high school age, right? So 16, 15, that kind of thing. And his experience matches my own, which is that many of us, we learn to code best by, not by like arbitrary exercises, but by actually building something that's going to be useful, right, solving problems.

And so what he does is he matches small businesses and medium-sized businesses who need to build internal tools with essentially classes of students, like a group of maybe six or eight students, and then gives those students co-pilot and says, here, small business, media besides business, you know, group of students, go build this internal tool for this business. And co-pilot is essentially kind of whispering in the students' ear,

metaphorically speaking, hey, you know, here's how you solve this problem. Here's how you do this. And students build not only the kind of the tool, the software that the business, business needs and then get to put that on their resume and their application for college and university. But they also 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. So that was a pretty cool recent one that I talked to.

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. Yeah, I mean, and that's the thing. Like, co-pilot is particularly 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 waiting 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 waiting into new territory, but maybe you need to fix a bug,

in an app that you don't often touch. Waiting into that codebase is kind of like learning and creating a mental map for that codebase. One of the really magical pieces of co-pilot here is that that AI is collecting context of the application that you're going into, and so it can help you build that mental map and learn the codebase,

even if it's a language that you're already familiar in. 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'd it come from, who had the original vision, how did this idea emerge and build momentum where you put resources into it? Yeah, yeah.

Oh, wow, what a long and, I don't know, depending upon your point of view, sorted or exciting story, that is. So, yeah. So Microsoft and Open AI have been collaborating for quite a while now on large language models, making its way into all different experiments and different parts of both Microsoft's software portfolio, as well as just kind of helping Open AI by providing the compute necessary. It takes massive amounts of compute to train these models. And they were mostly large language models. And so a couple years ago now, it kind of dawned on us that, well, language models aren't just English and Spanish and German and Korean and Japanese, right? But Python and JavaScript and Java and C-sharp and closure, all of these are languages too. In fact, they're kind of nice from an AI perspective because they're relatively kind of,

constrained in terms of their semantics, right? 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. And so we started to see what it would be like to actually bring 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. 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. And we noticed one day that we were getting 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 we're going to respond to this, what's going to happen? And we figured out pretty quickly that it was actually open AI. They were cloning all of our

repositories to harvest kind of the data out of GitHub. I mean, like, it's totally legit practice, but like, you know, it does have a real consequence. And we were able to step in and mitigate it very quickly. There was not a reliability, kind of an uptime incident there. But we're like, hey, y'all, like, cool, love this thing. Let's see if we can get that data to you. a more responsible way, in a way this packaged a little bit more to meet your needs. And so what we did is just like the year before that, we had actually created a snapshot of GitHub's public code for what we call the Arctic Code Vault. Essentially, this is up in like way in the Nordlands of Finland. There's a seed vault. And we're 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 man-made disaster. But another really important asset to the world is our code, our open source. Like this represents actually a lot of the collective, well, certainly software, if not like intelligence of kind of like the modern world. And so we had put this SNAPS, of public repositories on these like silver film that would be preserved for thousands of years and this Arctic Code Bowl. Well, we took that same data snapshot and we brought it to her friends over at OpenAI to see like, okay, what can we do with these large language models built on public code? Well, 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-sharp. And 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. And we started experimenting with different user experiences, right? Do we want it so that you, 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? That was nice because it would give you like whole functions, but it's kind of 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, they're like, hey, there's not really an extensibility yet in your editor for this multi-line auto-complete. But we've got an idea for how this might work, you know, played around with kind of of the actual presentation of it. What should the keystrokes be? What should the presentation layer be? The gray italicized text seemed to be a good way of indicating that it was ephemeral, as it were.

And pretty early on, we landed on this user experience that is co-pilot as most developers experience it today. That was now, I want to say, that was at least 16 months ago, 14, 14. 16 months ago. 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. Is that right? That is exactly right. Wow. That's exactly right. Yeah. So it's about a year and a half ago. That's insane.

What was that period between Open AI almost taking down GitHub to, I guess, that point? So the period in between kind of Open AI, almost taking down to the hub, and then us really arriving at the user experience. 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 dataset,

tossing back to us a model that we might play with and think around with. And these models have literally thousands of parameters that you can pass to them. So when you're really thinking about kind of GPT3 and codex and then the transition from that to something like copilot, 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 a great example of this is performance, right? When you're in a code editor, you don't necessarily want to type, type,

type, type, and then have to wait one second, two seconds, three seconds to get a suggestion back when your entire goal is to stay in the flow. And so we would run experiments to see like how many milliseconds are the right amount such that a developer doesn't feel like they're being interrupted by copilot and a suggestion. What's the answer to that? It seems. like right now it's around 200 milliseconds. 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.

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. So going back to the way this started, it sounds like basically it was kind of this fortunate accident where open AI just did some that you didn't expect. And then somebody within this 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 was amazingly good, like a step level change in actual like intelligence.

right? And then marrying that up against a really good use case that actually changes developers fundamental experience of the creation process, the creative process. Was there kind of a point at which it was clear to you or leadership in general? Like we should double down on this thing and 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 co-pilot at GitHub was the team, it's a team that we called GitHub Next. 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 work in the next one or two years, but might three, five years down in line actually turn into something meaningful. Is there a concrete definition of Horizon 2 and 3? Is it like number of years out, like Amazon style?

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 a measure of ambiguity and confidence level more than calendar dates. This episode is brought to you by Modern Treasury. Modern Treasury is a next generation operating system for moving and tracking money. They're modernizing the developer tools and financial processes for companies managing complex payment flows. Think digital wallets, fiat crypto on ramps, right, sharing market, marketplaces, instant lending, and more. They work with high-growth companies like Gusto, Pipe, Class Pass, and Marquetta. Modern Treasury's robust APIs allow engineering to build payment flows right into your product, while finance can monitor and approve 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, having raised funding from top firms like benchmark, Altimeter, SVB Capital, Salesforce Ventures, and Y Combinator. Check them out at modern treasury.com. 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 in a certain percentage of resources or bet on different horizons? Yeah, it is, I would say it is not necessarily a Microsoft thing, but is definitely at GitHub, how we have. really contextualize it. Not to say that there aren't teams at Microsoft who might also kind of use that methodology, but 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 from, you know, EPD, EPD here being engineering, product, and design, the folks who are working on building, you know, productized operational, like, products that we bring to market and we either give away or monetize in some way. 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 moon shots within a larger company. Yeah. I mean, I think like the first step is to invest in it. Like the first step is really like hire really smart people, attract smart people and give them the opportunity to be creative. Don't expect any anything out of them that is going to turn into a moneymaker or something that is going to be beholden to fundamentals around security. privacy, uptime, you know, accessibility, all that groupy kind of stuff up front.

They need space to create an experiment. And also, when you do get to, you know, a place where, like, that team has an idea that is clearly connected to like a representative set of customers who have a genuine problem. 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, okay, 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 bring prototypes of this in front of more and more customers to kind of test it out and see, hey, 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, really 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 tight connection and kind of been monitoring the work and kind of like 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 really. customers are saying, developers are saying, 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? And so from there, we really do is like, okay, we think we've got to 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, right? We want them to be researchers, but we need to do knowledge transfer, and we needed to actually kind of provide the seed

for a team that could eventually operationalize and productize it. And that kind of began the technical preview where we started to invite 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. 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 GitHub, next to do what they do best, which is be innovative and creative and think about the next moonshot. That process, that took, 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, has achieved general

availability. We've now hired in a team around them. And the research, starting, actually as early as last month, have started to gradually move back over to get up next. And a EPD squad, multiple EPD squads actually, are now taking the product forward and starting to respond to customer feedback to think about, okay, how do we now as a product team carry this roadmap forward from an idea that originated in Get Up Next? 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 earn the Horizon 3 or 2 team. Is there anything else you would do differently?

Any lessons you take away from this experience for maybe founders that are, or PM's working at larger companies that are like, hey, we should have some like this. Is there anything else that you find is important for making something like this successful? The criteria for moving researchers back into their R&D team, whatever that happens to be for your organization, that can't be based on a calendar. It needs to be based on a replacement in-seat who's actually doing the job and has picked up all of the skills necessary. And only then can the researcher move back. 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. As well, it's critical that the team who is taking over from the R&D shop feels like they have control over their own future.

You can't 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 product team as they take ownership over the idea and over kind of the use case and the customer. Last I would say here is really that engineering fundamentals in a lot of ways are the contracts that differentiate an R&D team from a operational product team. And bringing that fundamentals process into it is going to feel candidly a little bit unnatural to the researchers. and 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 in a research project to a 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. And so making sure that you've got a good mix of engineers who are comfortable maintaining a service as well as, you know, 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? Yeah, I can totally see the challenge that comes from.

This was my thing. I've been working on this like, what do you guys do into this project? Where is this going? Where I'm not sure. I'm feeling, and then there's all these new asks that are coming out. You're like, oh, my God, this was so much fun. And now I have to scale this freaking thing. Well, and I mean, this is the best problem in the world to have. Talk about kind of customer asked. 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. Like, I mean, we're getting a lot, lot better at it, especially in the last couple of years, you know, with things like Dolly and co-pilot. But it brings with it not only 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 offensive, who is at fault? know, our stance on it, what we ended up coming to is actually the, the framing of co-pilot as an AI pair programmer, I think is a useful one. You know, pair programmer, I suspect most of your listeners

will know, but like a pair programmer is usually two developers sitting side by side, working on a problem together. One's at the keyboard and 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. Well, if co-pilot is your AI pair programmer and they're whispering crazy stuff in your ear and then bringing politics into it or gender identity into it or I don't know whatever other 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 right it's going to be really distracting and so really kind of coming down to some principles about what is the use of

we're trying to solve. What is appropriate, I put this in scare quotes, behavior of the AI, kind of bought sitting side by side with you, helped us kind of create some principles or some guidelines for the developer experience that we wanted to create. I love that. Just kind of creating like a persona of the thing to help you inform how to how the behavior of the things 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 some like that as a product team?

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 products that I've ever kind of been responsible for, all wonderful, creative people. But it's not just legal. It is also, you know, privacy and security champions. it is frankly developers, like the people who are using it, like listening to them,

like, hey, what works here, what doesn't work for you here? Why is this offensive? Why is it not offensive? When we started out, we'll continue on the example of the crazy pair programmer

whispering crazy things in your ear. When we first started out, we didn't really have any filter on copilot whatsoever, the very, very early days. And then eventually, we're like, okay, it needs to be slightly more controlled experience. We need to edit out, you know, 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, like, you know, which words are okay,

which words are not okay. All of a sudden, we become editors, and that's just of like language, and that's kind of a scary place to be. I'm not comfortable with it at least. But like, at a certain level, it has to be done because otherwise you're going to create a bad developer experience. Yeah. And so, you know, often we would get feedback from developers of like, hey, this particular word was blocked and like that he was blocked either was offensive to me or prevented me from being able to kind of get good value out of the product.

Oh, man. And so 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, 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 context may be totally reasonable, right? Especially when you get into software for medical kind of scenarios, right? And so being able to start to shift a little bit, to shift a little bit to focus or to rely on AI models that can 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 is getting way better. It's 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 apparent company's contributions to solve

a real acute problem that GitHub probably could not have solved on a realm. I never thought that a co-pilot 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, wasn't it, wasn't it Microsoft that had that bot that got turned really negative and let's be shut down? Okay. So there's experience. It's named Talia or something like that. Yeah, something like that. Yeah. Yeah. We don't want another one of those incidences. Yeah. Wow. What that makes me think about is your team is kind of at the forefront of AI in this applied way. And I'm curious what you're 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 co-pilot. I don't know if that's right. But like is it 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, it is 40% is specifically for Python developers. It candidly, it varies depending upon the language. 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, you know, any one of a number of other metrics.

Awesome. In aggregate. Yeah, yeah, totally. We see it range anywhere from the upper 20s to the 40s across all the different languages. Yeah, 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. And so I'm excited for this to do more and more.

And yes, I'm curious where you think this goes. 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? So first, I think, I hope it's obvious to most developers that AI is going to infuse pretty much our entire development stack and the not so distant future. Copilot is really just kind of the very tip of the sphere for a lot of innovations in better managing, maybe our build cues, or helping to, here's a great one. You know, I don't know about you, but often the comments that I get with commit messages and PRs aren't super great.

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 full request 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. What I hear from developers and what I experience myself is that co-pilot kind of forces me to think a little bit more about what are the design patterns I'm trying to create? What is the end user experience or the outcomes that I'm trying to drive with my code?

And that I can kind of rely on co-pilot to scaffold out a lot of that so that I can focus on more creative work. And that is really what I hope for our industry, five, ten years from now, 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 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, OPE stack overflow, copy and pasting every function that they're trying to figure out. Yeah. I want Stackoverflow 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? Yeah. So there's a few dimensions of that. One is a problem that's very much of our time and the world,

namely that supply chains have been disrupted dramatically over the course of the last 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. 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, operationally, another challenge has been,

how do we create a model that the community, really feels like ownership over, right? And the dialogue that's had to happen as we brought an AI tool to market, especially one that is trained on public code, 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 potential customers. Copilot in particular has been a more complicated kind of rollout because we as a kind of 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 that's, and why is that? So it's a couple of different reasons. I mean, one, like I said, we are trained on public code and not all of the community is really sure, like, 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 co-pilot producing buggy suggestions?

Like, there's a lot of doubt. There's a lot of very healthy skepticism. And I actually, I mean that genuinely. I want people to be skeptical of 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. How people keeping us accountable, like how are you preventing things like model poisoning? Right.

Like, is there going to be a new attack vector that we just haven't really thought of yet around AI that might produce negative consequences? We think that. we've done a really good and responsible job of that by making sure that, first, we're very clear that copilot is not a replacement for a developer. It will never be. We do not want copilot auto-generating code where a thinking, reasoning, breathing human being is not on the other side of that keyboard making reason decisions. We do not want co-pilot. We do not want co-pilot. to replace any other part of the stack, whether it is static analysis tools or your unit tests

or whatever kind of measures you're putting in today to make sure that your humans produce good quality code, we want you to keep all of those same systems in place to make sure that humans who are leveraging tools like co-pilot continue to produce that good quality code. But there's a lot of, at the same time, like anxiety of like, where is AI stack? Is AI, you know, eventually going to be, this is back to your question about where will we be five, 10 years from now? Will it be writing

90% of the code? We don't want co-pilot to be that, we don't want it to replace anything. We want it to augment. The idea here is really that AI is an enabler for developers to focus on the creative work, to stay in the flow, to be able to make. move faster, right? And kind of working through those anxieties, working through that healthy skepticism takes conversation. It takes dialogue. And that takes us, you know, on the product side, having kind of that guided conversation with the community. It feels like connects back to your education back in the day philosophy and literature and how convenient is that? It often feels very connect. I mean, like, certainly, um, the education side of things taught me that the importance of

dialogue, the importance of skepticism is, is valuable in so much more than esoteric, uh, armchair ponderings. It's actually applicable to the real world. Maybe a final question before we get to our very exciting lightning round. So just looking back at this whole experience of one, just 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, 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 both a product manager and a portfolio manager. of multiple products, because I'm responsible for multiple product lines at GitHub. The allocation of time, of focus, energy, and resources becomes a really challenging question, the answer to which isn't always the same depending upon the time, kind of 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 some capacity for bold, audacious experimental research projects. You can kind of think of those really uncertain bets as being

5 to 10% of the team's capacity. 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 was that about 60% or so is really on incremental progress for our in-market products. How do we make iterative improvements and continue to actually realize payoff for the larger bets that we made, you know, one, two, three, four years back, right? And from a rough kind of like distribution, that's generally how I run kind of my larger teams. That works when you have larger teams, though.

At startups, you know, 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 proverbial lottery ticket, right? Awesome. Thanks for sharing that. I was going to ask you the percentages that you recognize. recommend. And so thank you for getting to that. So with that, we've gotten to our very exciting lightning round. I'm just going to ask you five questions briefly and just whatever comes to mine, whatever answer you have. Let's do it. Sound good. Okay. What are two or three books that you recommend most to other people? Oh, good question. So one of them 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 often make their way into our everyday products and tools, you know, 20, 30 years down the line. It is a great 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 like, entertainment value. There's a David Foster Wallace book called Brief Interviews with Hidious Men that I love. It's a collection of short stories. And essentially what it is, 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. It's that speech like 10 times over for different 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 got to find that one. You'll have to, you'll have to send it to me. It's like a found one at an old bookstore, like use bookstore. So I don't know where they're around anymore, but we'll, I'll find it.

Okay, second question. What's a favorite other podcast that you like to listen to or recommend if there's any? Oh, God, there's so many. I am, I consume hundreds of hours of podcasts every month. It is crazy. Yeah, I am, so I can choose many. I'll give you just one. So the Memory Palace with Nate DeMayo is an excellent storytelling podcast.

He does about 20-minute vignettes, usually selected from kind of American history. He also was the artist and 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 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?

I don't know how if this counts as recent, but it's it's one that I watched recently, which was arrival. Yeah, that counts. Arrival. So a movie about, ostensibly about alien. but is really about language and memory. And I found that really, really compelling. Have you read Ted 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 story, 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. I've got my weekend cut out for me then. There you go. Just leave work and get to reading. What's a favorite interview question that you like to ask in interviews? Let's see here. So I'll give you a fun one, more than it is a challenging one. This is kind of my icebreaker interview question, particularly for like more early to mid-career

product managers. So I ask them to teach me something new in one minute. And so I'll usually like, I'll pull up my phone and I'll like 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.

So, you know, it's one thing if you teach me how to, I don't know, pat my head and rub my stomach at the same time. It's another thing if you teach me something about 18th century ardent connection to religious trends at the time. And then last is really, is really. let's here. Clarity. Oh, yeah, clarity is the last one. Clarity is like, do I actually understand? I'd 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? By my go-to kind of throwaway answer there about did they teach me something about 18th century art and its connection to religious trends at the time? Someone taught me that. It was, 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? It was an extremely strong yes. She was freaking amazing. I like, yeah, such a, 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. But I think for today, I would probably beat myself up if I didn't say Uga Damore. Uga is the primary researcher who really kind of like is the true innovator for co-pilot. He deserves credit for the initial work and is a brilliant technologist and futurists. I really, really respect him a lot. 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. Thank you for being here. Two last questions. 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, Twitter, GitHub, any, you know, pick your, pick your choice, LinkedIn, Ryan J. Salva. And then how can folks peaceful meet? Like, please, like, there is a 60-day free trial of co-pilot that is, you know, there for everyone to pick up and use.

And go try it out. And when you do, posts either on Twitter or Hacker News or on discussions, GitHub, discussion. 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 I'm pretty confident that developers will be pretty freaking amazed at what it's already capable of. Awesome. Thanks for being right. Yeah, dude. Thank you so much. It's been a lot, a lot of thought. Thank you so much for listening.

If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny's Podcast.com. See you in the next episode.