The Future of Programming with Kyle Daigle, COO at GitHub

Adel Nehme: Hello everyone, I'm Adel, Data Evangelist and Educator at DataCamp, and if you're new here, DataFramed is a weekly podcast in which we explore how individuals and organizations can succeed with data and AI. I mentioned this on my episode with Benn Stencil a few episodes back, but programming and data work have surprisingly been one of the killer apps of generative AI.

At least for me, the moments where I've experienced an aha moment with Generative AI has been mostly when it has helped me analyze data. And one of the companies leading the pack when it comes to AI assisted coding is GitHub Copilot. GitHub Copilot is predominantly used by software engineering teams and provide a suite of AI tools to assist in coding workflows.

Today I'm joined by Kyle Daigle, GitHub's Chief Operating Officer. Kyle joined GitHub in 2013 and built and scaled the ecosystem engineering teams and worked on the acquisition of Semmle, NPM, and others. He now oversees culture, operations, and communications for the business. Throughout the episode, we spoke about the state of AI assisted coding, the strengths and weaknesses of GitHub Copilot, how he sees the programming profession evolve, why he thinks in the future there will be many more programmers than we have today, and a lot more.

If you enjoyed this episode, make sure to let us know in the comments, on social, and more. And now, on to today's episode.

Kyle Daigle, it's great to have you on the show.

Kyle Daigle: It's so great to be here. Thanks for having me.

Adel Nehme: Thank you so much for coming on. So you are the Chief Operating Officer at GitHub. I don't think GitHub needs any introduction at this point. You know, Data teams, developers, hobbyists all around the world use GitHub and, store, maintain their code, collaborate, and more importantly, GitHub has been leading the wave when it comes to AI assisted coding tools for developers, specifically software engineering teams.

So before we get into that, though, I'm interested in hearing your background, actually, you're a chief operating officer, but you joined GitHub 10 years ago as a developer. Walk us through that journey from jumping from a technical role to a leadership role on the business side, specifically in operations, because, that's a lot of different departments probably you have your hands in making sure that the organization runs smoothly.

Yeah. So walk us through that.

Kyle Daigle: Yeah, of course. So I mean, I joined GitHub 10 years ago. Like you said, I started coding lot earlier, right? I mean, I really enjoy Solving problems and seeing how people use what I built. And so when I started, I was 13 years old. I worked in my town's election office. I was building an access database and a very poor PHP website to allow people to look up if they were registered to vote.

And I think through that experience, I kind of quickly realized, the unique role that like devs can play in the world where. I can have an idea or be asked to do something and sit down and just code it and put it out in the world and say, Hey, does this work versus having to spend, weeks, months, years planning and figuring it out and kind of so on and so forth.

So, I went through that track through most of my life. I actually was going to college for lighting design originally and I was paying for that art degree by coding and building rails websites and like selling them on the side. Eventually the math. Stopped working and I wasn't able to make enough money to, pay for school.

And that's when I ended up finding startups. I live in Connecticut. I grew up in Connecticut. I'm in the sort of farm side of Connecticut, not the New York side. And so for me, startups were never really a thing, you know, I've coded. My parents wanted me to go to school for computer science, but for Connecticut folks, that means you go into insurance.

And. That didn't sound super interesting to me. And so, you know, I found my love of startups and again, it really scratched that problem solving itch. And so, fast forward into my time at GitHub. Most of my time as a developer and an engineering leader at GitHub was focused on helping people integrate their tools with GitHub or build businesses on top of GitHub.

So I ran all the ecosystem teams until the acquisition when I wanted a moment to go, okay, I've done engineering leadership. I've done product leadership. I'm a developer. I like solving problems. What else can I do? And I sort of decided to make the leap to the business side. And that's where the shift really began.

And I went from, you know, leading engineering teams to working on mergers and acquisitions and talking to those companies and figuring out, what it would take for them to successfully join GitHub and understanding what they built and what's unique and novel. And so Most of my time these days, a COO has kind of been taking a software development approach to things that are not software, you know, how we communicate, how we talk about our culture, how we ensure every hubber is able to do their best work.

Do they have the tools that they need and so on? And instead of sort of starting from a more, writing an RFP, building out a project plan, all this stuff. I kind of go and say, okay, what's the problem we're trying to solve? Let's make a guess and how we can solve it. Build an MVP. It just so happens that more often than not, this isn't in software.

It's with people. It's talking to people and saying, Hey, our company wide get togethers, we call them, how can we improve those? Well, this time, let's try this one thing and measure it just like any software developer would do. And so now I get this. Really unique role. And I've really enjoyed kind of, chasing problems, that I could potentially solve with my really talented team rather than necessarily worrying about, you know, well, once you're a senior engineer, you become a staff engineer and their principal engineer, and then maybe you go into management.

I find it way more interesting just to chase, what I'm most passionate about. And as long as I'm solving hard problems And there's no shortage of them in software development, even with AI I've really enjoyed the role since I took it earlier this year or last year, rather.

Adel Nehme: That's really great. I love that story. And I love how you mentioned kind of, the software development mindset, but approaching it to, you know, the chief operating officer role, maybe expand on that a bit more. What were kind of those transferable skills from, being an individual contributor or software engineer, but also software engineering leader to, being a chief operating officer at a company at the scale of GitHub at this point?

Kyle Daigle: Yeah. You know, we're a bit over 3000 employees and we're looking across, communications and it and our events and corporate marketing and so on and so forth. And so when I sort of joined that group and brought them all together, The first thing I really focused on was, can we be a lot clearer about the problem we're trying to solve?

And that sounds so simple and straightforward and sort of like, uh, leadership, uh, uh, mumbo jumbo. But I really think when you seriously sit down and you think about that, It can be a lot harder than you think, because with software, that's where most of things skew. It's when you're building the wrong thing.

It's not necessarily building it the wrong way. Yes, sometimes that happens too, but it's usually building the wrong thing. And so, the same way we had the sort of ship to learn mentality at GitHub for our product, I tried to bring that across operations where When risk is low, or we can revert a decision, let's just make the decision right now.

Let's make the decision and focus on whether we made the right decision or the wrong decision. What can we learn from how it went? And so we just had our annual conference, GitHub Universe. We did a a premortem before that event where we talked about what may not work. We made some decisions. We changed them before the event.

We went through the event. We did a retrospective on that event, and now we're doing a premortem for next year's event, and that's all a marketing activity in the in the purest sense of things, but at the same time, I just don't think we have to go. Okay. Well, how iterate on product can't be applied to how we build and iterate on a communication strategy or how we build and iterate on culture.

Those things also have risk, just like building bad software that leaks your code or leaks customer data has risk. You measure that risk, and I think we focus more on the iteration and the speed to learning inside those operational practices just as much. It was a huge shift, you know, and I think we're still kind of working through it because the natural inclination is everything should be 100 percent buttoned up before we take that next step.

And that's true for super high risk stuff. But I think, when we're talking about most of what we all think about day to day at work, like, what tools are we going to use to communicate with and how do I know when I can take time off, all that sort of stuff, we can improve the lives of our hubbers, our employees, simply by trying and trying and trying and learning like our engineers and product managers do.

Adel Nehme: That's incredible. And, I want to double down on what you said on, exactly focusing on what problems are we trying to solve? Because, when you manage different teams, different departments, creating that shared alignment around that one's objective, one metric that we're optimizing for is actually very hard, especially at companies that are, maybe remote first silo distributed, right?

that's a very big challenge. And taking that software development approach to this problem is very interesting. for your time. So, I could talk to you about, leadership best practices and how you approach leadership at GitHub for hours, but I would love to really focus on GitHub Copilot and, this new wave of AI assisted coding, right?

You mentioned you know, the Conference that you guys focused on last year, that's when you announced kind of the refounding of GitHub around AI, and specifically GitHub Copilot, Walk us through what it means for GitHub to be re founded on Copilot, and how important is this AI moment for GitHub?

Kyle Daigle: Yeah, yeah, of course, it's it's funny, the sharing that message with the world definitely, struck a chord and it's been a lot of conversation that I've had. I think, I think it's easy to forget that, when GitHub came out, did drive an enormous change for the industry. And at first it was, you were going from Subversion or, CVS or you Whatever older tool you were using it to get, but get up didn't even start with pull requests, right?

Pull requests came years after and so the real collaboration workflows that we think of today as just Normal pull requests, forking open source repositories, contributing back to open source, working in issues, didn't happen at first. And so, now when we're fast forwarding to this moment, I think saying, GitHub being refounded on Copilot is really just denoting that we're about to experience a major change in software development.

It doesn't mean like GitHub is giving up on open source or not caring about collaboration. All of that is fundamental. We just need to build on top of that and help the world come along with how AI and Copilot are helping devs write code 55 percent faster. They're more productive. One of our customers, Accenture, said that 88 percent of their code that was written by Copilot is being kept verbatim.

That's a huge change, right? From writing code five or 10 years ago. And so, I think when we are looking towards the future in this AI moment, forget up. I really think, well, we're a key driver of that moment. It's not an AI moment for get up. It's an AI moment for software. It's an AI moment for technology and for the world.

We Our mission at GitHub is to accelerate human progress through developer collaboration. We really believe that every developer can, sit down and build a small project, build an open source project, be a part of a fortune 500 and make a huge difference. And that's changing significantly with generative AI coming into code.

And so for now, co pilot for the last, maybe year and a half or two years has broadly been about, Making it easier for you to write code. And I think we're just starting to see the shifts into, well, now that it's easier to write code, what happens to the rest of your software development life cycle or the rest of your systems, or now that it's easier to write code, can more people write code day to day as part of their job we're really barely at the beginning of the starting line of this, but it's a moment, it's a moment that we're about to live through.

Adel Nehme: It's definitely a moment. So I'm a data scientist by training, but I haven't coded in a while, but AI has really brought back my love for coding in a lot of ways. I really, it's a much bigger part of my daily workflow now that it's, much more on hand because I know what to tell the AI.

But my syntax skills have been, you know, not the sharpest, let's say. and you mentioned Accenture's 88%. You mentioned that, 88 percent of the code has been kept verbatim. You mentioned the 55 percent improvement in productivity. GitHub Copilot has been live for about a couple years now.

You know, I think it started in beta. Yeah. Walk us through, you know, what you've seen, you know, in a bit more detail. The type of productivity increases. And the type of results you've seen from, developer teams using GitHub Copilot, love to learn a bit more.

Kyle Daigle: yeah, for sure. So, I mean, like you mentioned, GitHub Copilot's been around for a little over two years now. And at this point, Copilot's just like really widely adopted across the across the world with over 249 different countries and regions, a million paid users. And I already mentioned that it makes it faster.

I think that's the stat that everyone in this space talks about, right? You get to produce more code, and that's quite obvious. I think the thing that I've always been really interested in with Copilot is. Then what? I'm a dev to similar to your story. I like to code on the weekends, but I can't keep up with all of the new versions of ruby and rails.

And so I don't always know what the cool current thing is. And so I can ask copilot to help me out. And I think, when we're doing studies and talking to customers that also comes through, we hear that, devs are hurt. 85 percent more confident when they use co pilot in their code quality.

They're 88 percent less frustrated and focused. They're 90 percent more fulfilled in their jobs. That's like a hard thing to measure. But when we ask a dev, like, are you more likely to be happy day to day with this tool? And the answer being yes, there's all kinds of downstream impacts economically for that, for your businesses, You're more likely to stay in a job, presumably if you're using co pilot but I think, the thing that we've heard from customers since we started was this concern that like 55 percent faster.

Does that mean 55 percent more? And now we're going to have all this code. And what do we do with all this code? And I think, what we've really the the Scene, which to be honest, I don't think I expected is that, code that has gone through co pilot or written with co pilot is actually making its way through the rest of CI and CD and code review faster.

So code review is 67% faster if that code has been written by copilot or with copilot rather, you know what I mean? It's made lots of our customers notice that the next downstream steps require less time and less effort and are less confusing. More CI builds are green on the first attempt instead of having to pay for One or two failures and maybe two might even be not enough right before you get that green build.

It ends up being a lot faster and one of the things that I think, we always talk about as devs is like, how long does it take me to go from like, I have an idea to a commit or to a pull request and it's a bank. South America, they were able to achieve what they've measured as a 93 percent reduction between the time to commit code.

So being able to use copilot with actions and get up advanced security, being able to go a lot faster. So it's not only that, folks are able to produce more code. Go bring their ideas out faster. It's actually that they're able to go through the entire loop and get to production a lot faster. So we're kind of actually testing out DevOps if it's actually real and worked, because now you have to be able to test if your system can accept all this problem solutions that your customers are looking for and let them actually touch it a lot faster.

Thanks to the help of, co pilot making code. That is easier to review, easier to deploy, and so forth.

Adel Nehme: Interesting. And you touch upon here, you know, something you mentioned is that, some of these results have been a bit unexpected, right? Especially when it comes to, the relatively non obvious results. I think we all expected that, with AI assisted coding, that we'll be able to produce more code, that we'll be able to code faster, right?

But what's interesting that you're touching upon here is that, Development teams have also become more collaborative. their work, their operations have become easier. Maybe walks through a bit more detail, from what you've seen. Maybe take a few examples from GitHub Copilot customers.

help teams become more collaborative and help their operations become smoother?

Kyle Daigle: Yeah, yeah. So, it's probably not in the way that you think when we started this, we kind of did a couple of research studies and one of them we asked engineers that work in a, company climate, what's the number of engineers that work with you on a given project?

And we found that on average. 21 engineers work on a single project at any given time. And so that's a lot of people that you either want to get reviewed from or have to get reviewed from before you can actually deploy something. And so what we started to kind of realize is that when you're Getting so much of the sort of, syntax and semantics figured out for you, have way more time to focus on the problem in the architecture and starting at the beginning and saying, okay, well, how should we structure this versus needing to kind of Paint your way to that.

You can start with a framework and that's a moment to collaborate. That wasn't always there before, because in a lot of times, if you're a senior dev or a staff engineer, you might be like, all right, go start with this library in this class, get going and I'll review it. Well, if copilot can do the get going for you, then it's actually more important that you're clear up front and you have to talk through that creative step way more, and I think on the pull request side, why we see pull requests being so much faster is that there's less review on the the small syntactical things that, come up like this, this variable is not well named or have you considered using this method or not?

Because while you're working, co pilot can use your company's sort of standards to do that. Or you can ask a question to get a copilot chat, right? And say, Hey, is there a better method than G sub here? Yes, you can use split, for example. And so when you're actually reviewing the code, you're reviewing The architecture, the implementation, the intention behind the change in our most senior and staff folks are helping teach and imbue that into the code base and other engineers instead of, spending 50 percent of things for 50 percent of time on things that the linters, didn't catch.

I really think as we move forward with AI code, we're going to see more and more and more of the focus on. What should the system look like? How should it operate and do a little bit less of, you know, I'm gonna find my way there. And then when I get there, I'll plant a flag in the ground and say, here I am and actually start way more up front with that process because that's what we all know with AI, whether we use chat GPT or some other tool, the question you ask, the problem you pose is currently the most important thing.

With GitHub Copilot or CodeGen, it's, it's kind of no different. We, you have to know where you want to go and how you want to get there to be most efficient. And those are the conversations that I think devs speaking for myself, I love to have anyway. I'd rather talk about, what we're trying to do and what trade offs we want to make way more than, hey, should we be using CamelCase here or this nested class syntax doesn't make any sense.

That's something I'd rather, the tool just to help me do automatically.

Adel Nehme: That's very interesting. And, what you're alluding to here is that, I think a lot of professions are probably headed to that direction of, decision making by humans will become at a higher level abstraction, right, than what it used to be, especially when you have AI assisted tooling here in the specific use case of development, if the tool is producing a lot of the code, a lot of the boilerplate code for you, your time will be freed up to focus on higher level abstraction and making sure that the system is is architected. Well, do you think that at one point in time we'll have also AI assistance to help us with the higher level abstraction?

You know, We had Ben Stansel was the CTO of mode who was talking about, He wouldn't be surprised that if in a few years, here we're talking about data science, right, that you will have an AI assistant that will help you problem solve your data, not just write the code for you.

So how do you view that as well? and the upcoming wave of AI tools?

Kyle Daigle: Yeah, I mean, it's funny, I was just talking to the founder of a company called ritual where he's trying to build a tool that helps you define a problem and then work through, the various questions you would want to answer to come up to a solution, right? I use a tool called Rosebud, it's actually like a kind of therapy slash journaling tool where you go in and it's does the normal questions, how was your day, what are you grateful for, et cetera, and then it.

can read it and ask you to refine your answers. Oh, your favorite part of the day was being able to sit down and read a book with your kid. What book was it? And what made that so special? I'm going, okay, like this is all stuff I could think myself, but being prompted to work through this makes total sense.

And so when we look to, co generation and AI tools, I don't think it's. Much different, you know, I think as the models continue to improve and we're able to give more information in a way that the models can actually like absorb practically and use well, we're able to sort of start with a question, which is, given this repository, what is it?

And it's not just going to summarize a readme, right? It needs to understand what the code is attempting to do, add that all up and get together. And so as GitHub Copilot has been able to take on more and more code, we're getting closer and closer to the places where you can say, hey, given this old repo, why did Kyle build it this way in 2015 because nobody uses this repo anymore.

It runs great, but like now it's time to upgrade. And that's where I think a I along with all the various processes on top to build various algorithms to do fine tuning to build the dag necessary kind of so on and so forth to help answer those questions that, gets us to that next stage of a I where it's not just, helping us churn butter faster, it's not just taking away the toil of the work.

It's helping us come up with recipes and ideas and ways to make new things. We see glimpses of that. I think we all kind of have a story where, a tool and AI tool kind of did that. It's just not normal yet, but I don't think we're probably more than a year away from that being done. Normal for many tools, and I think code has a special chance because we're really, code, data, any sort of structured language is has a little bit more of a special chance of making that happen than pure natural language because it has very clear documented, syntactic and semantic rules based on it.

So hopefully, the next time I come on or next year around this time, we're able to kind of like touch and feel and talk about some of the work that we're doing to make it so that. You can just start with a, well, I think I want to build a mobile app that is a viewer for Hacker News. And it just goes, all right, well, what color do you want the headlines to be?

You know, That sort of thing versus digging into, do you want it to be react native or swift as the first question?

Adel Nehme: yeah, definitely. We're going to have that conversation next year. So, uh, it's very interesting. We're definitely going to unpack, how the skill set of the modern programming is going to evolve. But what I want to first talk to you about is the democratization of coding. something we really think about.

At Datacamp, our mission is to, educate everyone on data and AI skills, right? The big part of that is coding skills. And we're talking about how developers are becoming more productive. But when you see tools like Chachapiti Code Interpreter, GitHub Copilot, you know, we have Datacamp Workspace, which is an AI assisted coding data notebook.

It's incredible how much it lowers the barrier for non coders, right? So, what do you think that means for the future of what it means to be a programmer? Like, because that's a very interesting question for me. Thank you. Mm

Kyle Daigle: Yeah, yeah, for sure. I mean, it's super practical for me. I have two boys, they're nine and six and the nine year old about, I think it was four months ago. We stuck him in a coding school. So every Wednesday he goes to a coding class. And I think, the first question people kind of ask is like, the end state there, which is, well, why would you do that?

Adel Nehme: hmm.

Kyle Daigle: you know, AI is able to do all this. And I think the reality is that, while all of these tools are extremely helpful you still have to start with something currently, you have to know the first question to ask. You have to find a trail head. to go down. And if you can't find the trailhead, you're not going to get very far on the journey.

I have a friend that is a nurse and he's looking to, make a career change. And he's thinking, Hey, coding sounds great. You know, Why don't I get started? And so, of course, I was like, Oh, well, why don't you try GitHub Copilot? And he was able to get sort of that interest and hunger, but similar to like data camp, He then went on to an online learn to code tool that then got him enough of that sort of, Oh, I can go down this road and co pilot can help me there that now he's interested in looking to pursue that as like a career choice because you kind of have to know the questions to ask.

And so for the future of being a programmer, not to reiterate exactly what I was saying before, but, It's more so about problem solving and understanding what the technology can do, and then, building on top of that, okay, well, you're going to use sequel for this and not this other thing.

You're going to use no sequel for this, not this other thing. You're going to run this by Asian tree on top of it or whatever, whatever. Eventually, you'll learn those things, but you have to start and make sure you know kind of how to ask the question in order to be productive. So I don't think like learning to code is going to go away for a fair bit of time because I don't think the abstractions will be so clear.

But I do think that someone that's technological or someone like me that's like not coding day to day for my job, I could probably write out, like a specification. And let a tool build that for me, essentially because I'll know enough as to where those limitations may or may not be

Adel Nehme: Yeah, that conceptual knowledge of how to architect a system, you know, taking the data parallel of like understanding, exactly how to think about your data, right, for example, is going to be very important, even if the tools coding for you, right? And I think this kind of segues into my next point.

We want to talk to you about how you've seen teams adopt, is AI assisted coding, right? I've seen you discuss heavily how, Successful teams using generative AI coding tools like GitHub Copilots are the ones who integrate it into existing workflows, There's kind blend of the chief operating officer in software development comes in this next phrase when you say teams need to use tools that do not require net new behavior.

And I find that very brilliant. So walk us through that concept in a bit more detail, how you've seen that play out with Copilot and what you mean by no behavior.

Kyle Daigle: as co pilot was rolling out. I had the pleasure of helping lead the GitHub next team. And that's the team that, built and delivered co pilot. It's kind of our research team, our next horizon team. And as I moved into the operations role as COO, wanted to think back and go, okay, like what made co pilot so great?

Cause I don't believe it was because. We were one of the first, there's a ton of tools that do this thing now, but folks are still choosing copilot and it sort of dawned on me in talking to the team that, like you said, I think the reason why it was so straightforward was devs are just typing.

That's what they do. They're writing their ideas. We've always had autocomplete. What Copilot did so magically was create the idea of ghost text where it could put in multiple levels of hierarchy of code in a single response. And that was actually The kind of breakthrough that took the model from something that was really powerful to something that was really useful for the average dev.

And so when I realized that, and I'm talking to customers who are implementing their own generative AI pieces, right? They're putting it into their own apps, or for me, when I'm looking to bring other AI tools into GitHub to help us, the ones that stick are the ones that are being used in a way that People are already using the tool.

So let me give you an example. At GitHub, we use Slack and we Do everything in Slack, probably too much in Slack, but one of the rooms is this room called the IT help desk where you can go in and say, Hey, can access my email, whatever. And the team kind of realized that, well, we could put a AI powered bot in there.

That can answer these questions with context of who's asking them and everything else and not have to say, Oh, go use our help desk tool or have you searched the docks or anything like that? And so by going, okay, what can we do to help these people without doing anything new or saying, please go somewhere else?

And sure enough, by doing that, we were able to reduce the amount of time our I. T. Support team spent down 30%. And so I've also tried other tools where we go, okay, please go sign up and use their interface and click this AI chat window. And I can tell you without a doubt, those tools are so much harder to adopt and use and get value from because.

I have to enable you. I have to go tell you, please go over here. Here's how you use the tool. Watch this video and how many of us want to do that every single day over and over again as all these tools come to market into our companies. And so what I think Copilot did well was the no net net new behavior.

And as we continue to bring a I, powered features and functionality into the rest of the GitHub platform like we're also trying to make it so that it's. Looks just like a, you know, a colleague gave you a code suggestion, except it was from copilot versus go review the A. I. Powered code suggestions over here because that's not what we actually do every day.

And so if like the end of 2024 we stop putting a I buttons on things, we stop adding chat windows where we don't need them. I will be an extremely happy guy because I think the hype window for what We all are willing to accept as our user experience is going away. And then again, that sort of understanding the problem, understanding what you're trying to do.

And humans will come up with unique user experiences that are actually valuable and in flow, just like we want all software to be. That's, I think, how you win by adding AI to your products or your workflow. Every day,

Adel Nehme: So that was exactly my, the next question that I was about to ask, because, you guys have, nailed relatively well the, experience of AI assisted coding, So maybe walk us through meta lessons that you guys learned, right, that are applicable to other type of experiences, That you guys learned when developing Copilot that you think apply as general rules when developing these AI experiences. You know, You mentioned here the new behavior, but are there things that you guys learned when developing Copilot and refining the user experience there that you would be sharing, would be willing to share with others here?

Kyle Daigle: aside from the net new behavior piece, I think a big piece of it is start with the on label use case, but don't finish with the on label use case. And so what I mean by that is that. 4 Turbo, you pick them. Everyone knows the on label use case. Ask a question, get an answer. Ask a question, still has the context, get an answer.

And so, when you integrate that into whatever you're building, that's the on label use case. It's a chatbot, you know? and so, obviously, OpenAI and other companies have created, GPT stores and so on and so forth. I think once you've done the first step, Then you have to seriously sit down and look at that and go, Okay, what is the off label use of this?

What is the thing that I'm actually getting the most value out of this tool? And does it need to be a chat experience? So an example of a chat bot that I love that I'd love for someone to make into an actual experience is I like to cook for my family every night. I hate menu planning. We've all seen the parlor trick of going into chat GPT and saying, Hey, I have chicken breast and broccoli.

What can I make for dinner tonight? There's absolutely no reason any one of the number of shopping services or an app could just do that for me automatically. I do not want to ask a bot what I should cook. It should just tell me when I'm opening up my app. Hey, tonight would be a great night for chicken and broccoli because I know you have that stuff.

And that's the difference between on label and off label is that the fact of you're actually providing value without having to ask for it. We're still in the like, turn the lights on moment when you enter a room with AI and it's magical that electricity works, and the lights go on. turn on, but we're not even at like motion sensing where the lights just turn on because we know you're there yet.

I think that is a huge part of where AI is successful or not. And so for co pilot, most of the time we're putting it in places that's automatic, that just works for you. You're not going to have to ask it to do things. We have a couple of light switch places, summarize this PR for example, you know, and we see that folks don't.

Really respond to that. it doesn't mean folks don't use it, but they're not dying to do that. But there are places with like security auto fix where we use AI to automatically generate a vulnerability fix for you. Everyone loves that because they know exactly what to do. It's already there. I read it.

I know I'm vulnerable. Boom. I can just click this button and move on. And so I think that is another thing. The last thing I'll point out is again, kind of a reiteration of what we learned at the very beginning of co pilot. When we started with copilot and we got access to the model, I think everyone thought that it was going to be a code documentation generation tool.

It's going to read code and spit out docs. Right. And I think what we very quickly realized is, sure it can do that. But what really made the world of difference was. Focusing on the user experience and so figuring out ghost text. And so as new models have come out and we've gotten new increases in technology there, we've been able to take advantage of that because we figured out the user experience.

And so I think too many folks are waiting for the next model to come and save us. Like the new model will not save us. We haven't even figured out how to really use the old models yet. We're just repeating what everyone else has done. And so my last kind of piece of advice in this is. Make sure you're focusing on that experience side.

And if you're doing the same thing, everyone else is dealing with that model, at least from a user experience side, not a problem solving side, but a user experience side. It's important to question, is this really the best way for someone to engage with your tool or with AI? And if you can iterate on that and improve that step more, that is, I think when we're going to start to see these bigger breakthroughs of these bigger leaps, it's not going to be.

Suddenly, there's a new model and everything's fixed, or we're all just sitting around waiting for AGI to come and save it all. I don't think that's as important as putting in the hard work and trying to come up with a new user experience paradigm similar to when we had to do the same thing when the web went from, Raw HTML to, the JavaScript Ajax revolution that changed how we all used the modern browser.

Adel Nehme: Yeah, that's incredible. I couldn't agree more. I think the the user experience aspect of AI is still largely unsolved. And I think we're probably going to see a massive wave of subpar AI products in the foreseeable future till that is relatively resolved. You know, I'm I'm kind of harping on the cooking example, even you can go be a step beyond further.

I'd love this in my fridge. I'd love this with a small camera and a kind of release, a small, large language model that can tell me in my fridge. Here's what I think you could cook. Right. And that would completely abstract away the digital interface in a lot of ways from needing to do this.

It becomes physical in the world. And solving that will be a big industry problem, not necessarily improving the model. So cool. We're talking about the user experience here and we've talked about the net new behavior aspect when it comes to, integrating AI assisted coding in your workflow for development teams.

And we've seen the incredible results that you've seen, from different teams. Do you see any risks emerging from using a lot of generative AI assisted coding? Sorry, this productivity incre increases and increases in code generated per person put strain on organizational processes? Or does it require a change in how we think about development teams?

Kyle Daigle: So when we talk to customers about this, I kind of mentioned that I think a lot of us expected to see just the throughput to go up so high that It was going to break a lot of the systems and in the most part that hasn't really been the case. I think the risk of bringing in AI assisted coding is that it will magnify all the sort of soft problems you've been ignoring with your team.

So engineering culture, practices and principles, what you accept and what you don't accept. AI. isn't solving that for us right now, and so where we see teams struggle is, maybe you're a company that's multinational and you've been around for 35 years. Well, now AI is coming in and saying, well, modern devs look like this because it's being trained right on the code available now and a lot of old code, it's been around forever, isn't, Available for that type of training.

And so now you have to help your devs go, okay, well, we have to go to kind of the next stage here. We can't just stay where we were. We have to go into the future. I think when we talk about, code review, et cetera, we have to help devs think, okay, We're not just looking for the kind of quick fixes or the quick comments.

We're looking for the big changes, which take more time to digest. And you probably need, more assistance there to be helpful. And think those are the biggest ones, at the moment I think there's, always been kind of concerns and discussions around like, Whoa, is this, more secure or less secure?

Humans are inherently insecure when they code. Like, it's all about how you can use these tools to catch those vulnerabilities. And so, of course, get up as advanced, get up advanced security to do that and help you do that. That's an easy way to catch some of the problems. But it's really, I think about, bringing those teams To now tends to be the problem or the thing that starts to break and shift versus, teams that are already living in this sort of, digital native future.

They're already all completely on the cloud. They're just doing the things that we're all doing every day. When we're starting a new greenfield project using open source software, those teams have been able to sort of take this on and start using it right out of the gate without Too much problems and friction because they already have an end to end workflow.

They already have CICD. They're already measuring, they're already deploying to production dozens or some cases hundreds of times a day. If you're not quite there yet, this will show you that it's time to join, the rest of us and get there.

Adel Nehme: Yeah, I couldn't agree more. So, we still have a few minutes left in our chat Kyle, what I want to focus on, you know, we talked about the future of the programming profession, right? And how important problem solving is going to be. I think a lot of people are looking at, you know, you know, you mentioned how you send your kid to a coding school every Wednesday and people ask you, like, why are you doing that?

Like, isn't the future not so bright for the coding profession? I think we're both in agreement that the, Hallmarks of a future successful developer is going to be someone with excellent problem solving skills who has the higher level abstraction and can architect great systems, right? But do you anticipate that the economics of the profession will change as a result of the maturation of AI assisted coding?

Think compensation, job demand, the, supply and demand for coding professions. Walk us through your thinking here.

Kyle Daigle: Yeah, I think I think this is one of those things where when you take a view of writing software as a very, Silicon Valley or Silicon Valley, connected view, you go, Oh, my goodness, like, there's only so many jobs and, things aren't always looking up, et cetera. But when you look at it at a global scale and you think about, the demand for software developers, demand has always outpaced supply in the recent history.

That's always been true because the reality is we're never going to be building less software. What this allows us to do is Bill, some of those holes where we don't have enough developers to do it. I think job demand will continue to be high in part because I don't think we're talking about this part of it enough is that when we talk about, is AI going to take away jobs from developers to be more blunt?

I guess, we view it as though. The amount of software or technology being created is zero sum like we've that we've quantified the amount that needs to be built and I actually think what's most interesting to me about the economics of AI supported software development is what suddenly becomes economical that was previously completely uneconomical.

You starting a business at home and building an app that would take you far too long to get to market, but now it's going to shrink it maybe by half and suddenly you can get your app out to market. I think about open source projects that aren't economical, like meaning they just take too much of people's time to build them to solve really pointed problems.

Like in my community, you know, I live in Eastern Connecticut. It's pretty rural. It's hard to get. Get around, particularly for health care. I'm lucky to live in a state where, health care is available, generally speaking, but you can't always get where you want to go if you don't have easy access to a car because it's rural.

There's no buses, etc. And so there was a hackathon recently where The discussion was, well, how can we help people come and get connected so that way we can bring those folks to those healthcare appointments because access to that was the problem. And sure enough, the reason that I got pinged and went to this was because they only had a small handful of developers to work on this, right?

I mean, I'm not in a tech, capital of the world over here, but co pilot and AI helps make that be something that's like, I think we could do this versus, well, we'll let the big city solve this and we'll be fine over here. And that's the part that I think we're not really talking about is the expanse of what AI can help us do because it's suddenly possible and we can fill in the holes both.

from a job perspective, from a compensation perspective, but also from an opportunity perspective to really, change the world with software. Once using AI makes that, even possible versus just thinking, Oh, all the social networks will suddenly be coded 55 percent faster. Cool.

Whatever. There's much bigger problems for us to solve. In co pilot can help us do that.

Adel Nehme: That's so exciting. And even being able to solve more problems internally within your organization, right? Like I saw you in another appearance, I think it was on the GitHub podcast itself, like on GitHub Universe, the batch system, right? That you guys developed a solution just for that using GitHub Copilot because you were able to get to market for it much faster.

And, here we're talking about, a relatively simple, thing like a conference badge, right? But if you extrapolate it to so many different industries, healthcare, transportation, logistics, etc. Very exciting stuff of what it means for many people to be able to code more. Now, Kyle, before we wrap up this episode, I'd love to to get your intuition or take on what's next for GitHub Copilot.

I don't want you to reveal the roadmap fully, right? But what can we expect this year from GitHub?

Kyle Daigle: Yeah, so we talked about one of those things, and I think it kind of ties together a lot of what we talked about, which at Universe, we shared like vision for something we're calling Co Pilot Workspace, and the idea here is, similar to us talking about Defining a problem and talking about architecture being one of the most important steps and solving a solution or creating a solution.

Rather, with copilot workspace. What if you just had a GitHub issue that described what you're trying to build or the bug you're trying to fix? And then instead of having to go start coding it or just getting a code suggestion, what if copilot could take that up? It could show you the code that will be generated instead of editing the code, you can edit the code, of course, but instead of editing the code, you edit the issue to make the change, and then it runs it, builds it, puts it into a environment that you can click around and touch if it's a web app and then ultimately can immediately deploy it.

And so instead of having to go, okay, here's this issue, I'm going to read it, or here's this idea from my coworker, or here's my idea, and then go right to code. What if you've already written down what you want to do? Why can't copilot just do those next steps for you? So it's still a little bit of early days, but I think that's the thing I'm most excited about with copilot right now is that, of course, we're gonna bring, AI to the entirety of the GitHub platform in ways that makes sense and keep you in flow.

The security auto fix example I already shared as one of those ways, but there's way more to come. I think though being able to go from idea to running app in. Like two minutes. like at the speed of the cloud, without being cliche, I think, is super, super interesting.

The other thing that we kind of went to, which isn't necessarily GitHub based, but is still just so compelling to me, we were talking about the, grocery store example. You mentioned the refrigerator. I really hope 2024 is when we create more solutions to the idea of like ambient ai, IE. It's just, it knows what I've been saying.

It knows what I care about. It's privacy conscious, but it can just do the next step for me. And so instead of, like you said, having to even open the app, like, why doesn't your fridge just know, you know, assuming you want this, that you have this and you can cook. Or, why do I have to before a meeting, go and say, when's the last time I talked to this person?

And go through and just, It should just tell me because it knows I'm going into a meeting. There's some interesting companies that do this or are attempting to do this. Like rewind AI I think folks should check out. It's a great Mac app that does this idea for you and your Mac. But my hope is that.

Both for all of us, we kind of make this breakthrough because again, it brings some of that magic of what has made co pilots so powerful, which is just the second you need it, it just appears. I think I want that in basically every tool that I'm using that could be improved with a little splash of AI.

Adel Nehme: Yeah, and you can also, on a philosophical level, you can even argue that brings us back to the physical world in a lot more meaningful ways than just having to look at your phone all the time. And that's the future that I am much more excited for. Now, Kyle, before we wrap up today's episode, any final notes as we close our discussion?

Kyle Daigle: No, I mean, I'll say, of course, if you haven't tried co pilot, now's the time to go give it a go. What the thing I find so interesting is, folks come in and they love co pilot and they use it right out of the gate. People are detractors and they're like, I'm never going to use anything AI based.

And then they get it in their hands and they just start to try it out. And sure enough, they sort of love it. I love when folks use co pilot and they tell us like what they're building with it. Because, that is, I feel like the true power that AI is providing us is it's actually helping all of us, all of humanity, tap into our creativity that I think, through phones and through digital and through our day to day jobs and honestly, just the toil in so many of our jobs, we've kind of like lost and we're all human beings are inherently creative and I truly believe that Copilot is one way for us software devs, we can truly unlock that.

And so if you use it, if you try it, be sure to reach out to us on Twitter or reach out to me on Twitter or X or LinkedIn or wherever these days. Right. And let me know because I love hearing those stories of creativity through software.

Adel Nehme: We'll definitely include your details in the show notes, Kyle. Thank you so much for coming on DataFrame. I really enjoyed this chat.

Kyle Daigle: It was great to be here. Thank you so much for having me.