Chris Benson (6:10)

I'm curious, I mean, it's a great point you're making there and about the changing developer experience and changing so incredibly rapidly. I mean, month by month there are changes in what it means to be a developer now. And so I know, you know, and I'm sure I'm speaking for a lot of people I like. I keep reinventing kind of parts of my own workflow as I'm doing stuff because new tools become available and what I am doing or not doing is changing constantly. It's kind of a. It's both amazingly wonderful, you know, given where we've been over the years, but it's also quite tumultuous. And when we start and if I stop and kind of lean back a little bit and have a cup of coffee and think about it, I'm kind of going maybe a little bit scary in the future about how good it's getting and where that's going. What are your thoughts on, you know, since you've talked about the developer experience explicitly and the user experience of code assistants and that they are going, they are rapidly going so far ahead. What kind of thoughts? And don't even go out a long way. I'm just talking about in the next few months, in the short term, like where. How can we be thinking about adjusting ourselves to an ever evolving state right now, as we're, as we're trying to think about that even before we get into the specifics of the tools themselves.

Kyle Daigle (7:28)

Yeah, yeah. I mean, you know, I think what we've seen at GitHub by rolling out these tools is like, we'll talk to customers or I'll just talk to devs or open source maintainers, et cetera. And they can kind of fall on this continuum, right? This continuum of I absolutely love every AI tool I'm going to use, every single one, and I'm going to try every single one and then you have the folks who are like, I'm never touching these things ever, they're terrible and they're going to destroy software. And then there's all the folks in the middle. And so I think the thing that I tend to tell folks is like, you know, just like in our careers we've all had a moment where a new piece of technology comes in and I feel like for some reason it's in at least 50% developers minds of like, oh well that's just a silly thing or that's just a toy or whatever. So I'll just say for myself personally, Rubyist by nature, JavaScript took over and I'm like JavaScript, well, Ruby's, you know, blah blah, blah. And so like over time you grow and you realize, oh well, I should really understand that and try it out. And it may not become my new go to tool, but it would not help me or honestly like the industry or my peers for me just to be like, I'm never going to touch JavaScript. So I think that experimentation that you were talking about, Chris, is the important thing. I see a lot of devs like try out a new tool or try out a new feature or a new library or a new model and then drop back to whatever their floor is, whatever the thing they're most comfortable with, the model they know, et cetera, et cetera. And I think that is the minimum because the change is going to happen just like it's always happened between serverless languages, databases. You pick it, right? And if you just don't experiment, my fear personally would be that you do kind of start to get left behind because you don't know how to reach out to the new tool that is actually excellent and actually helpful. And you're, you know, kind of stuck behind the eight ball learning something that you could have been learning as you go. I will say like, you know, in the next few months even not even just kind of like now, I do expect way more kind of AI functionality to come outside the editor. Because if you're developing software as part of a team or as part of a company, not as a solo dev or a smaller startup, but a bigger group, we all know writing code is an important part of the job, but it's not all of your day. You're reviewing code, you're building out decision records or architecture diagrams, or you're debating how to roll this out, you're operating a live site, so on and so forth. I think as AI comes into those spaces to fill in the gaps More and more. Again, like you're going to want to have those skills from, you know, figuring out the right way to word things when the AI can't just figure it out, or the LLM can't just figure it out on its own. Or again, like every developer, know how the system is working inherently so you can best, best benefit from it. So as long as you're kind of trying these things out, even if you drop back to your baseline, I think you get set up for more productivity and I think just kind of like more joy when the AI can take more of those mundane tasks away from you. Again, like, I think over the next couple of months, not even the next.

Daniel Whitenack (10:49)

Year, what do you think are the. For those devs? You know, some that have jumped right in, they figured out their workflow. Maybe there's devs out there that are experimenting with the tools. What do you think are those new kind of, you know, everyone's kind of got their muscle memory of how they, how they develop, you know, the things that they like to use. What are, what are kind of the new, the new muscles that need to be developed for kind of AI assisted coding, like the most important ones that you've seen over very many use cases.

Kyle Daigle (11:23)

Yeah, I mean, I think there's kind of two major ones. Every developer has, like you said, come up with the kind of practices and principles for you personally, we've all worked in systems that have Linters and CI and everything that stops you from making mistakes. But there's just also a bunch of things that I like to work in this order. It helps my brain process what's going on, you know what I mean? I think on a tactical level, stating those rules, those prompt instructions, whatever, depending on which tool you're using for this, there's a different name for it. But I do think that that's something. Just the act of sitting down and writing out, well, how do I work on this project? Even if you work as a part of a company, you know, how do I care about it? I always wanted to find a schema for the backend API before I implement the front end and then I go back to the back end or whatever the thing is for you writing that down and then letting the tool use that, I think is a dual benefit. Which kind of gets me to my second point. The big skill that everyone is, I think, trying to work out is it used to be called like prompt engineering. And I honestly think it's just describing a problem. We use so much shorthand and sort of we skip over the details. Like the hilarious meme of, you know, what the product manager said or what the engineer did, what the designer did. But that is exactly what we have to do with these tools. Every day we go build an app that XYZs and suddenly it comes back and it' makes no sense and you go, oh, this stupid thing doesn't work. You know, and yes, sometimes it just doesn't work. But realistically, sitting down and saying, well, what are the must dos of this app? You know, how do I want it to work, what do I want the flow to be? Whatever those things are. Being able to clearly communicate, particularly in a written form, is like crucial in this new era. And I think it's been a skill that in some ways we've kind of let fall down. Like, you know, when I think back to the era in which I was a much more active dev, I think there was just so much written communication, whether that be blog posts or GitHub's always been remote. And so for us it was usually like a GitHub issue or campfire back in the good old days. Slack these days, just writing down what you mean, that's a skill to bring to saying what I want this app to do. And I think that's why when you're on Twitter or X or wherever and you're looking at what, wow, how did this example get one shot? It's like ask for the instruction. That instruction was certainly not build a multiplayer game that allows me to fly airplanes. Like that was not it. You know, it was much more. But with all the practice that came from describing problems socially, describing problems for your LLM, being able to do that regularly. And I really think it's mainly describing problems as the models have gotten so much better. There's a little less like how do I make it work for each model than there used to be. That's a skill that's going to serve you both in those tools and with your colleagues, with your manager, with your open source friends and maintainers, just cohesively if you can do it really well.

Chris Benson (14:37)

I'm curious to that. Do you think just as a two second follow up that for developers kind of that describing a problem skill that you've been addressing along with kind of the communication skills that support that, should we think of that as developer skills now and maybe that is a muscle that we have that we should start exercising as well?

Kyle Daigle (14:59)

Yeah, I think it's something that we like the best teams, the best companies have considered that and I think we've kind of Let a little bit of the like 10x developer meme take over and make communication not be as big of a deal. There's no major application site or app that serves hundreds of millions of people or tens of millions of people where being able to communicate what's happening or what the problems are isn't core to the job of being a developer. And if we just play out over time, if AI and LLMs are going to continue to write more and more and more and more of the code, even if it never hits, you know, all of the code, whatever that ultimately means, all that's left is collaboration. All that's left is collaborating with your peers, with LLMs, with agents, with designers, with your boss, with your client, whatever that is. And so suddenly the fact that you can write an app incredibly well, succinctly, well factored and tested, whatever, that's great. That's a, that's a, that's a great skill too. But the human factor will be I can look at you in the eye, I can read what you're writing, intuit what you're saying, what you're looking for and describe that in such a way that I can, you know, benefit from all of these tools. It's going to be incredibly necessary as those, you know, more rote or highly automated tasks can be done by, you know, AI tools. Foreign.

Podcast Host / Announcer (16:42)

Today's ever changing AI landscape means your data demands more than the narrow applications and single model solutions that most companies offer. Domos AI and data products platform is a more robust all in one solution for your data is not just ambitious, it's practical and adaptable so your business can meet those new challenges with ease. With Domo, you and your team can channel AI and data into innovative uses that deliver measurable impact. And their all in one platform brings you trustworthy AI results without having to overhaul your entire data infrastructure. Secure AI agents that connect, prepare and automate your workflows, helping you and your team to gain insights, receive alerts and act with ease through guided apps tailored to your role and the flexibility to choose which AI models you want to use. Domo goes beyond productivity. It's designed to transform your processes, helping you make smarter and faster decisions that drive real growth. All powered by Domo's trust, flexibility and their years of expertise in data and AI innovation. Data is hard. Domo is easy. Make smarter decisions and unlock your data's full potential with Domo. Learn more today@AI.domo.com Again, that's AI.domo.com.

Kyle Daigle (18:15)

Well.

Daniel Whitenack (18:15)

Kyle, one of the Things that I was thinking about the other day was there's a sort of generation of developers that are growing up sort of not having any other experience than having this sort of AI assisted experience, both on the kind of like educational debugging, IDE side, but also, of course, using, you know, interesting tools, whether it be kind of Vibe coding tools or other things. I was listening to the A16Z podcast and they did like a. I think it was them. I forget where it was. Like somewhere they mentioned a survey of the latest cohort of Y Combinator, that cohort of companies, and they were saying like 95% of the code is AI generated. What kind of impacts are on your mind in terms of this generation of coders that are really. This is what coding is to them. What does that mean for both organizations that are hiring kind of developers out of that environment, but also new opportunities that maybe like people that wouldn't have maybe broken into developing cool projects or that sort of thing now have opportunity for.

Kyle Daigle (19:36)

Yeah, I mean, I look back on how I personally got started coding and it was because I wanted to build a video game. And I feel like that's not very unique, but it's one of those things where, like, I enjoyed playing video games, but it's still cool. Exactly. And I wanted to go build a video game. So back in the day I went to probably Barnes and Noble and bought, you know, the red C book because you had to learn C if you wanted to write a video game. And that thing was, I don't know, 650 pages probably. You know, that was an enormous book. And so that is a huge immediate barrier to entry to like learning. Because you're like, the reason I came here was to solve a problem. And if I just do 650 pages of how C works, I'll eventually get to build a text based video game, probably. You know what I mean? And at GitHub with like our teams in GitHub education, I get to work with them and the team there on. Well, how do we approach learning in this era in a way where like, we can bring that problem up front, which is essentially what Vibe coding is. Right. I want something in the world, I want to go build it. I think the piece that is necessary to continue to learn is that problem solving piece. And I just want to make it accessible to you so you can bring a problem, something you want to go learn. But in the process of getting you to your destination, we can just expose you to the ideas around why this application works this way or why there's two files, one for the front end and one for the back end or whatever. So you're kind of learning as you go, but still focused on ultimately, you know, solving that problem that you're going after. So I don't think it's a bad thing that, you know, these startups or folks online or even me on the weekend, I'm writing an app that is just for me. It's going to have a user of one in perpetuity. I just want it to get written, you know, I want it to just work. But if we can help folks learn as they go, I think we'll actually create more, you know, craftspeople in a way similar to, like I always describe, you know, changing out a light switch in my house. Like, if you own a home, we've all probably replaced a plug or a switch, but there's no way we're going to go into the circuit breakers on our own. We'll probably fry ourselves. So we call in an electrician to come do that. But I'm not an electrician. I just know how to go change the light switches and that's what I need in order to solve my problems. That's what I think learning coding and the air is going to be, is that you can continue to start from this place of, well, I just want something and that's fine. I think that's great and it makes the idea more accessible. I want to be able to get you to that, you know, journey person stage of oh, okay, I know how this works. I understand variables, new technology came out, oh, I want to try to play with that, etc. But it's possible that at some scale and speed, we're still going to rely on, you know, professional software developers in perpetuity, running these apps, building these apps, kind of, etc. The real thing that's interesting to me about that stat I was talking to some teammates about is I really think there's a huge opportunity in operating the apps. And I'm a little dumbfounded that that hasn't been something that's been tackled yet. I mean, at GitHub, we kind of focus on like, you got to production and like, okay, great. And then you use Century and Planetscale and whatever, Azure and so on and so forth to run it. But I really think that in all of our probable life experiences as developers, the thing that bothers you is you get paged, you get an email, there's an error thing, and you're like, crap, what is this thing? That is another Place that I feel like as vibe coding continues, once you run an app and you have thousands or tens of thousands or hundreds of thousands of users, I'm not on team, like, oh, well, that's when you got to bring in the serious people. They'll rewrite it the right way. I really think there's still space to just, okay, well, an error came in. The AI saw what it was, it resolved it, it wrote a test, the test passed. It deployed it to Canary or to a small version, and you just get a text message that's like, we fixed it. That I feel like, is the next step of this, you know, era of writing, learning how to code writing and deploying these apps versus deploying them and going, oh, now I need a real, you know, a pro to come in and help me out.

Chris Benson (24:09)

That makes so much sense. And are you actually seeing anyone out there kind of early people doing some of this? Is this in the wild? More than just because we tend to think of AI in terms of writing the code, operating the app. Makes perfect sense. Who's doing it?

Kyle Daigle (24:25)

I think the issue here is it will require us all to work together. When I joined GitHub nearly 12 years ago now, I joined to work in the ecosystem on APIs and webhooks and how you connect app everything with GitHub. And I really, that's where my passion lies. It's in, you know, the hub part, you know, of like, how do we get everything connected? And so as I look at, you know, how quickly the industry's gotten so excited about MCP and being able to connect tools together, I'm really hoping this hype wave drives into something valuable, which will be if I can bring the context of my error tracker, my database, my two cloud services, my email provider, et cetera, et cetera, all together, then I believe it becomes possible for tools to work together to solve these problems. Unfortunately, right now, each tool is attempting to solve the problem that it can see, and I do not think that's terribly valuable. Right. As an end consumer, I don't want to use three AI tools to solve an error in production. I want one. You know, I want one tool to do that, or I at least want them in some future magical state where agents all actually work together and blah, blah, blah, then, you know, eventually that could also happen. But I have yet to see a tool that is kind of tackling this. I think because of the, like, interdependency problem that a tool like that would have in this current, you know, very quick moving AI tooling state.

Daniel Whitenack (26:08)

Yeah, yeah, I think it's, it's somewhat connected to like my concern around the ease at which all of this can get built is great. The burden on the debugging side, right, is, is potentially, potentially kind of growing and sort of you have all this stuff and then I guess it's more around, yeah, more around decision support in terms of, of like making good decisions based on like these overwhelming pieces of, of information. Because you built just so much stuff and you might not have kind of visibility and intuition around that. What is your thought kind of. Because as more code is AI generated, there's potentially not a good intuition even on how things are interconnected or like, oh, this function exists, right? I didn't know that this function existed, right. I've never heard this function name. I have no context there. So what's needed from a tool standpoint to really get the proper context around that kind of decision support or whatever you want to call it, for the developers in the tools that they're working in?

Kyle Daigle (27:23)

I think for most of modern history of software development, I feel like most folks are working in a relatively high level language, a lot of abstraction ultimately, and most of us aren't working in C or even lower than that. I think that in order to help us understand our code bases or our multiple code bases and multiple systems, right? Like at GitHub, there's no world in which as a developer who works on, you know, webhooks, I'm going to understand how git systems is ultimately going to work for me. And so for me, I think the piece that I'm trying to figure out is how can we get more that higher level abstraction of how the code base is working available to me. And it probably needs to be in a way that as a human I can understand how that works more so than this class, this file, this whatever. I don't really need to understand that. I need to know that the webhook system is having an issue or this other piece isn't working, or there's a bug over here where we process images and then I can kind of click down and dive in, and dive in a little bit more. Because usually when you have a bug, even if you do understand the system, your goal is to figure out what to ignore. You know, like you're like, okay, well it's not any of this stuff, it's gotta be over here. Uh, and I do think that similar to, you know, humans being good at describing a problem, ultimately to the LLM, I think the LLM has to Help us abstract up to a level where I would draw on a whiteboard, you know, and then let me double click in and understand more deeply what's ultimately going on.

Daniel Whitenack (29:15)

Yeah, yeah, that. That's a, that's a great point. It reminds me of like the sort of peak microservices days and, you know, everything. Everything expanded into, you know, we're. I was at a small company at the time, and I don't know how many microservices we had. And, you know, we had alerting set up, right. But then the alert would go off and, you know, everything was dependent on everything else. So all the alerts would go off. It's either none of the alerts go off or all the alerts go off. And then you're like, well, I give up. Like, where do I even hop in here? Yeah, it seems like a. Seems like a big, big opportunity, I guess, in terms of the, you know, and I want to talk about Copilot specifically here in a second. But just in terms of the IDE specifically and at a more general level, how do you see kind of the, the ide, you know, obviously people are trying various things with what. Both what Copilot's doing and Cursor and Windsurf and all of these things. All hands and all of that. How do you see that interface morphing over time? Do you see that kind of still kind of being recognizable in a year and a half or two years, or being something kind of completely foreign maybe to certain people?

Kyle Daigle (30:39)

I'm hoping that in the next, honestly, six months that a startup, just because of the nature of how these things move, can kind of show us a future state that is in some ways backwards compatible. So what I mean by that is GitHub has had workspace, we kind of demoed Spark. All of these are kind of. The code is stepping into the background to show me the prompts, the thinking, and a pretty preview of what ultimately is being built. But right now, in IDEs, all the ones you've mentioned, and generally all of them that aren't the sort of like, idea to app tools like lovable, bolt, V0, et cetera, they all are still staying code forward. And I think it's necessary, you know, in order to attract an audience right now. Otherwise it kind of. You get pushed aside as like a. It's a fun toy. It's not really a tool that I'm going to use as a. A professional dev. I do think in the future, though, I'm working with the app or the web app. The actual iOS app or whatever. Every time I'm writing code, like I'm writing code, I'm writing a test, and then I'm going to go and touch the app. That last step is usually where I figure out if I'm right or not. And when something's wrong, why do I have to keep bouncing back and forth between the result, the thing I'm trying to actually build in code? And so there's a couple of tools out there now, right, that are kind of showing me the preview and as I adapt that, like, the code is changing and it gets to the most, like, maybe not the most, but one of the most interesting problems to me in this AI era, which is like the magic mirror problem. How do I continuously change a representation and have the code or the text or the readme or the speaker spec match what I'm doing in the representation? So, yes, moving pixels is pretty easy, right? I'm going to go, oh, I changed this position or whatever. But what if I ask it to do something completely different, right? How do I make sure that the code always matches that? And I think there's a couple of really interesting attempts at that. But if and when models, tech specs, et cetera, get better there, then I think ides will broadly be the prompts, the preview, the thinking, so I can kind of correct and adapt. And then probably some way for me to, you know, click on a part of the app and not go make it blue, which is the demo where that we all see. But instead be. Well, no, no, no. I want this to be like a dynamic view that shows me this whole other, you know, basically another controller, another view, another app or whatever, and it'll code it right there and show it to me, me. Then I think we'll be even faster than we think we are. Kind of like right now, because instead we're going and manipulating by a prompting, you know, this turn. Okay, well, now I'm going to convince you AI to go do this thing. But it feels like we're still a couple clicks away because there's some actual hard problems to, to solve to let you go back and forth very, very easily, because most companies are still, like, working in code ultimately by a CI, build, systems, deploy, et cetera. So we want to make sure that everything matches up in the code base, not just in the app or the visual representation of what we're trying to build.

Chris Benson (34:00)

So as we've been talking about code assistance and where things are going and stuff, I want to get more specific for a moment because we got you here. Talk a bit about GitHub Copilot specifically and kind of maybe as a starting point on this, kind of talk a little bit about, you know, what the current state of GitHub copilot is, kind of how, how the user experience is now and as a starting toward what tomorrow and the day after is going to look like and how you see that affecting, you know, IDE's adoption of the technology, the whole thing going forward and kind of start a path into the future from here on that, on that particular item.

Kyle Daigle (34:46)

Yeah, yeah, for sure. I mean, you know, I feel like most folks are familiar with Copilot 1.0, we'll call it, right? Like everyone's like, okay, so it does code completions and cool. And you know, in the last six months or so we went from the. Yeah, it does code completions to, you know, now you can choose to use a variety of models, usually within a day, if not the same, same day of them coming out. There's chat, the ability to ask these questions. Now there's agent mode available in Vs Code Insiders, which allows you to have that experience of describing a problem, watching it do the work, asking it to do something else, working across multiple files, the context of your entire repository, not just the file that's open, and make these much broader changes to your application in the ide. Still, as part of sort of the overall Copilot family, we continue to do these explorations like Workspace and Spark, where we're sort of going like we were just talking about, what does it mean for me to plan out what I want to build and then let Copilot as an agent go and figure out all the steps that need to be taken across multiple files, multiple repos, to ultimately kind of build that app. So the goal, instead of just saying give me some lines of code or give me a whole, you know, method is now starting with, well, what problem are you trying to solve? You know, most of our devs are working in, you know, major open source projects or big companies, or they're starting to learn, etc. And so we want to be able to let folks come from a problem that could be a prompt in chat, that could be a GitHub issue, that could be a pull request that's already open and you think that there's a piece of it that's missing, missing. We want you to be able to just state what you're looking for and then let Copilot take it from there. So we kind of shared a little bit of A preview of that path forward where we've all gotten bugs and we put them in our issue tracker and it's not interesting. It's going to take a fair bit of time to solve or to resolve and reposing the question, why not just assign, assign that to copilot and let them work just like a dev would work, you know, trying it out, running the test, the test failed, commenting, what they think they got wrong, continuing to go and then asking for a human review. That's something that, you know, again, we're trying to model it after that experience of anyone on your team versus treating it like this magical tool that's, you know, always going to get something perfectly right. Instead, just like you would, you know, explain with another dev friend, you can go in and help copilot understand or just go, yep, that's totally right. Just change these two things and copilot will do it and ultimately deploy. So when we're sort of looking at the code creation process, which generally happens in IDEs, I think that's a big part of it. The part that's in some ways like more exciting for me as a dev is all the other pieces of being a dev, like I kind of said, you know, like when I'm writing a re or when I'm reviewing, reviewing code, I'm a human being. And so I may not remember the exact method signature of something, but this doesn't seem like the best way. And so to be able to work with copilot in those moments or to let copilot kind of just tell me, yo, Kyle, this isn't quite right based on how I know you work. And so it can show it to me and just let me accept the change or in actions in CI, why not let it fix the failures that come through or let me define my actions workflow just by talk, talking to AI versus having to go and build it myself. And so the real kind of magic I think of copilot over the next year is how can we find moments both in creating code, but also in reviewing it, building it, testing it, deploying it, and let copilot, probably in a much more agent fashion, having a multitude of copilot agents that can work together and use the context, not just of your code, all the code in your organization, but also the tools that you also use. If copilot can reach out and get the information from them using MCP or a copilot extension, then suddenly it can take over the tasks that you probably didn't want to do in the first place. To be honest, less so. Those sort of interesting novel. I'm building my business around this tasks. It'll help you do all those things, but at the very least, let's let it take away the kind of rote pain work that I think, you know, every dev kind of has in their backlog. But it's been sitting there for the last two years, three years or however long. It's artisanal now. And so Copilot's, you know, really, really trying to allow you to just go from problem to app or you know, problem to fix via these new experiences in the IDE and VS code in particular, but also now in more IDEs like we announced, you know, XCODE now has chat. A bunch of other editors also continue to have chat. So if you're in those environments, you can still use the power of Copilot. And then in GitHub.com, you'll see all those new experiences coming in like code review, being able to use an agent to build an actual solution for you from an issue and kind of fix the other 80% almost of dev time inside the SDLC process that they're working in versus versus only focusing on that editor workflow.

Daniel Whitenack (40:22)

How do you think? I realize this is probably a complex question, but I get it posed to me a lot. So I figure you're probably the best one to answer or at least have an opinion. But oftentimes I get a lot of questions around this side of. I mean, even in what you just described kind of, here's an issue. Generate a fix agents that can do this, especially around like the open source community and code generation. How, how does this kind of influence, you know, licensing and kind of the ecosystem of open source over time from, from your perspective?

Kyle Daigle (41:02)

Yeah, I mean, you know, with Copilot and what it's doing, ultimately that code that is being generated, whether that be generated for, you know, your business or for an open source project. We have tools in Copilot that you can basically say, hey, if this matches any public code, don't give me a match. And then it won't. It's not going to match anything from the public code base that it has access to. And so in general, for folks that are most worried about, well, where is this code coming from? Is it using code and generating code that looks like other public repos that I don't want to match on? It can do that just by setting a setting. And for some of our sort of SKUs of copilot, we require that to be on. You have to have that on in order to protect yourself if there's any concern around, yeah, where is this code coming from, what's the license, et cetera? I think as we continue to move forward more and more, and as we're looking at all the tools out in the market as developers, I think we, we can all kind of intuit that there's only so many novel ways to write the same exact thing. And so you'll sometimes hear, or I should say I'll sometimes hear, particularly from open source devs, going like, oh, well, Copilot won't write this for me. It's not going to. Why won't it give me the answer? And the answer is because that loop that you're trying to build is complex enough that it triggers us to look for a match. And because we have that blocking on, because, you know, you've turned it on or the business has, it won't give you a return. And so it really depends on the business's personal preference or the user's personal preference on whether they want that public matching to come back to you. But in general, especially as we get into agent mode and we get into, you know, the ability to kind of create close to an entire app, you know, or at least a very complex set of files, you know, Copilot is going to iterate and iterate and give you something that again, doesn't match that public set if you have it turned off. But ultimately, you know, try to solve that problem for you. Every other tool has a different set of, you know, obligations like this, or whether it's going to use the suggestions, etc. But I think at the end of the day now, our goal is really to make sure that everyone's empowered to use this tool. They can choose, you know, how they want to use it and what kind of responses and suggestions they want back. And that's why we give Copilot, you know, for free to students and maintainers of very popular open source projects. And we're trying to find more ways. Just let make sure everyone can have the tool if they want to use it. Now Copilot free. Basically everyone can use at least a portion of Copilot and then kind of let them decide for themselves what they're most comfortable with. As we keep going down this AI future of coding, as we start to.

Chris Benson (44:04)

Wind up here, we often will ask guests kind of what we refer to as the future question kind of going forward now. But we have covered so much ground. I'm going to ask you that and I will Say that as you look. Look into the future and you're kind of, you know, we've covered. We've covered everything from AI in the. In terms of productivity with code, to the developer experience, to just the GitHub copilot product itself and a bunch of tangential stuff. You go wherever you want to go. Where do you think as you are kind of finishing up for the day and you get through the crush and you have a glass of wine or maybe you're getting in bed for the night and your brain's kind of spinning in open mode, you know, where you're being creative, where does your brain go and where all this is going to go for us, and what kinds of things might be next that we haven't already talked about. What would you like to see aspirationally coming down the pike? Take us into your brain for this last question?

Kyle Daigle (45:02)

Yeah, for sure. So if I were a good corporate citizen, I'd be pitching you on something from GitHub, but that's not the honest answer. And we're all developers in some way, and so the people on your side understand, I think true ambient AI that understands me and has access to my information and what I choose is the thing I'm most interested in coming right now. You know, I think we've seen the power of the LLM and I don't think we've honestly tapped into the vast majority of it. We're still, broadly speaking, in chat models, and that's incredibly boring to me. You know, I get it and why it's that way. But, like, I really think the next step is going to be more about if you have all of my emails, my calendar, all the things that I'm currently sharing, that could be my purchases on Amazon, that could be, you know, access to sort of my doorbell camera, and you see what I'm wearing on the way out, et cetera. There's all these experiences where we go to Google and we go, what's the weather today? Or we ask our assistant, like, you know, a tool at the house or whatever, or more complex, you know, like, when's the last time I. What was the last episode I listened to of Practical AI and what was it about? Because I'm going into a podcast recording and I want to remind them that Matt Collier is a friend of mine and he did a great job with Sidekick and kind of so on and so forth. That ambient AI or that ambient intelligence where we're not like, invoking an assistant, it's just telling me what I need to know. When I need to know it, because it has all that data about me is I want it. I desperately, desperately want it. And I think there's a couple of like really interesting attempts at this. Like there was Rewind AI that was a Mac app and they kind of pivoted into this limitless tool which is like a wearable. Plus all the apps that has the same idea, there's been a couple of, I won't like name them, but a memed versions of this thing. And that's not really kind of what I mean. I really mean the ability to finish my thought because you have all the context that I need. And I didn't have to set up 55 integrations or IFTT or Zapier to move all my data into a single place. So that way GPT 4 or 5 can answer it or whatever, you know what I mean? And I don't think we're that far off. I think that I find it incredibly interesting that like iOS and Apple intelligence have been attempting to come up with what they're next up on. But I actually have some hope that they may solve this because they haven't shipped their solutions, you know, and they kind of publicly are talking about how it may take longer than they thought. The biggest gap to this isn't LLMs, it isn't connecting all the data, it's privacy. I don't want all of this data sitting in an arbitrary startup's cloud or wherever, you know, to do this. For as powerful as all of our laptops are, there's still limits, you know, about how much it can do and how much data it has and what the models it can run, et cetera. I think someone that can take all the information, do it in a way that I'm personally comfortable with from a privacy perspective, both for me and for anyone that is inherently, you know, like getting data sent from them into this tool. You know, like if I was recording my screen right now, for example, to be able to have all that in actually help my day to day life in a real way, you know, and reminding me of what's coming up and helping me do those things without the personification of a hey Siri or hey Alexa situation, just text. That's what I sit up thinking about at night and how to crack the privacy nut. Because I think that'll be required for us to do this in a way that is both really powerful, but also I think morally correct and safe for all of us to benefit from versus accidentally slipping into a even worse dystopia. By letting all this information get out into the wild in a way that we don't want.

Daniel Whitenack (48:56)

That's a great way to end it, Kyle. I also have hopes for similar things and we end on the same wavelength again. Really appreciate you joining. Thank you so much.

Kyle Daigle (49:08)

Thank you so much for having me.

Podcast Host / Announcer (49:16)

All right, that is our show for this week. If you haven't checked out our Changelog newsletter, head to changelog.com/news. There you'll find 29 reasons, yes, 29 reasons why you should subscribe. I'll tell you reason number 17, you might actually start looking forward to Mondays.

Kyle Daigle (49:37)

Sounds like somebody's got a case of the Mondays.

Podcast Host / Announcer (49:40)

28 more reasons are waiting for you@changelog.com news. Thanks again to our partners at fly IO to break master Cylinder for the Beats and to you for listening. That is all for now, but we'll talk to you again next time.