Replay: Rubber Duck Thursdays

Hey. Hey. Hey. Heat. Heat. Hello. Hello. Hello. Hi everyone. Okay. Right. Um, hi everyone. Could someone kindly confirm if you can see my face on the screen? For some reason, I'm not able to see my video. I'm not sure that's making it to the feed. Okay, there we go. Um, need to use a different background. Um, all right, there. Hi everyone. Good morning, good afternoon, good evening depending on where you are joining in from. Welcome to today's rubber duck Thursday episode. So good to see you all on the chat. Um yeah, drop a quick hi. Let us know where you are tuning in from. I see a lot of folks streaming in from LinkedIn. So this is streaming. This is live on LinkedIn, on YouTube, on Twitch. Hi Roy. Hi Dark. Hey Jay. Yeah, let us know. How's everyone doing? What are you all working on? What's new? What's exciting this week? Hello. You're good. I'm also good. Uh lovely weather here in Nairobi, Kenya. Um, I I saw the sun for about 2 minutes and then I had to close my blinds cuz the sun will just be um just directly on my face. But yeah, doing good. Doing good. All right. Um Roy, you're asking what are they going to talk about? I'm assuming they in this case is what we'll be covering on this live stream. Well, this can be anything honestly. Uh so my routine is to for for us to go over the change log together. So the GitHub change log just see what's new, what's exciting and what do you care about. So we'll probably start the conversation from the change log and then that can evolve to be whatever you guys want it to be. So if you want us to focus on a specific demo or a specific feature, co-pilot features then happy to to do that. But for now, I just open it up. If you have any questions, if you have um anything that you've been building, you want to share with the community, this is the right space to do that. So, if you have something really cool you've been working on, you can share with us and we'll celebrate together. All right. Um, good. Thank you. Thank you, uh, Budoo for confirming. Yeah, I was having some bit of tech issues setting up the camera. It's a good Thursday. I agree. I'm glad it's good for you. Good evening joining in from Australia. Welcome to the show. Anthony, welcome from Kenya. Zaval, welcome from India. Great, great, great. We have um Pina from Portugal. I hope I'm getting your name right. All right. So, let us know if you also have any questions. Um, the purpose for this live stream is to just connect on a weekly basis and then just talk all things GitHub. So, if you have any questions, I'm happy to gear the conversation towards them. But for now, I'm going to pop my screen on the I'm going to share my screen. So just give me a moment here and then we're going to start the change log. So I'll just pop in screen two. All right. So this is the change log. I'm going to put the link right here. So just go over to github.blog um and you will be able to find the change log. So this week let's see what's new. This is week of 26th May. Uh today should be around 27th. So we have a few announcements. We're just going to go over them. See what's new, what's exciting. I'm going to scroll all the way to right May 26th. This should have been released um this week. So first release here is our code coverage on pull requests is now in public preview. Um, so what this means is that you can now aggregate a percentage of your code that is covered directly in pull requests, giving reviewers a clear signal to help evaluate test completeness before merging. So I think this is really useful for um open-source maintainers. So if you're getting a um large amount of PRs then we have this new improvement or new feature where you can see a percentage of the code that is being impacted by the proposed changes in a given PR. So I think this is a really neat feature um and any open source um maintainers on the live stream today uh could definitely try it out. So it's code coverage as you're reviewing your PR. Then you do get this nice um nice comment here with a percentage an overall percentage of the code that will be covered um that is being covered in that particular pull request. So I think that's that's a pretty cool um and interesting feature. So that's the first release that has been announced this week. what else do we have here? Um, all right. These all look interesting. Oh, there's one here that I think has a really, really big impact. So for those who are in the education space, so perhaps you've been using GitHub classroom, then this is a really important announcement that GitHub classroom um signups are no longer available. So the offering from GitHub is being retired. If you're using GitHub education, GitHub classroom, then this is really something important to take note of. Let's read through it. So starting today, new signups for GitHub classrooms are no longer available as we transition to partner solutions. So for those who have existing GitHub classroom accounts, uh you will continue working business as usual, but this will go on up to the 28th of August, which is when GitHub classroom will fully transition to partner solutions. So again let's look at um what this means. Um so after 28th of August users won't be able to sign into managed to sign into managed classrooms and the GitHub classroom website will be decommissioned. So there's a discussion here. Let me just open it in case you are interested. So you you've been using um GitHub classrooms for some time. There is a discussion here in case you have any follow-up questions that you can join. Of course, they have more details what triggered the change and um looks here that educators want um a lot of reliability when it comes to this platform and GitHub is no longer able to support that. So, um we're going to be transitioning that to a partner solution. So we have two partners Kodio and um and and classroom 50. So we I believe that this particular discussion will have more and more details if in case you have any specific questions on what this means for you, what will be available after August of this year etc. So again this is all accessible from the change log. I see a few comments on the chat so let me try and catch up. Hello. Hi. Welcome from Ethiopia. Good to see you all. Hi, Stefan from South Africa. Fantastic. Right. Okay. Yeah. So, I see folks sharing their portfolios, what it is they do, so you can connect as well. Yeah, I agree. That was a really cool um feature that just got released. Stefan says that that's an interesting feature. It should be built to pre push hooks and fill if the percentage is below the threshold. H I do agree with that comment. That would be even more useful um if uh yeah so I think that would be really really useful. So automatically just run the just run the code and if as you said a particular threshold is not reached then it just um basically either drops the PR or something like that. So I think that's a really good um and neat suggestion. Um not really sure where we can put that but I'm sure that we have um communities where we can share that suggestion. I'm actually just going to note it because I think it would make the feature even more useful. What we have right now will at least give you a first glance. If you receive a new PR, you can just at first glance see the amount of code that is being covered with that particular review. But I do believe that would be a very a very very useful enhancement to the feature. So that's that's really cool. All right. Um Okay. So that's the second thing that went live this week. So again for GitHub education users, GitHub classrooms here will be retired in just a few months. So yeah, um what else? What else? Uh GitHub code quality repository enablement API. So this looks like a new a new release. So you can now programmatically enable and configure GitHub code quality on individual repositories using the new repository enablement API. All right, so looks like now you can programmatically um use these two additional endpoints. So one will allow you to either enable or disable code quality as the default setup for your repo. Pretty neat. And then you can also retrieve the current code quality configuration from your repo directly from your code. And these are the currently supported languages C# Go, Java, Cotlin, JavaScript, TypeScript, Python, and Ruby. So that's I think another good feature for especially for um enterprise accounts. So that's really something worth looking into. And then right so this is another one that looks really interesting. So it's an improvement as of this week um targets copilot models to organizations with model vaults. Now for enterprise owners for business owners I think this will really be interesting for you. So now you have granular control over which GitHub copilot models are available to each organization. So within your enterprise uh there's a screenshot here. So within your enterprise you can define which set of models are available for each of the GitHub organizations. So you can see here with this new user interface you can easily create a new access rule and then tie that to a GitHub organization and then define the models that each of these organizations should access. In this example here, we see that the B2B organization has access to open AI models while these other three organizations here have access to entropic model. So this gives you more granular control in terms of model access across your GitHub organization. So that's really really useful. Um what has al also been improved is that the default model availability experience has a refreshed interface. So from one single page you can choose which default copilot models are available. And you can also set each model's availability to either enabled or optional. So users within these individual organizations can either easily switch between the models that you make available to them or you can just leave them as optional. So I think that for enterprise users that's something worth noting. You now have more granular control over who has access to which set of models. So that's that's pretty cool. And the last one is this very first one at the very top. um copilot memory has more controls for deletion scope and the copilot CLI. So I'm curious how many of us on the chat can let me know how many of us are actually actively using copilot memory and if you're not familiar with the concept also let me know happy to chat about it it's fairly new um so if you're not familiar with the concept of copilot memory I'm happy to just give a quick overview but we have a published improvement in that copilot memory now includes includes improved memory deletion, adds a repository level off switch and brings further memory controls into the copilot CLI. So just to give an example that will help us understand what this means. Yeah. And I see one of our GitHub YouTube viewers says that you're yet to be familiar with the concept of copilot memory. So just to give you an example, um here is a ripple. So this is an example of a repo here. If I go over to the settings tab. So if I go over to the settings tab, I have my copilot settings. I'll expand that. And then at the bottom here, you will see memory and it's in preview. If I click on memory, this will show you copilot memory which is uh which is basically a functionality that allows copilot to create a persistent memory store about your repository. So as you're interacting with copilot either on github.com from the CLI on VS code, it stores facts about your repository. It could be instructions, your preferences. It stores them in uh what we're calling here c-ilot memory and then it makes this memory available across all the contributors of your repository. So that means if in this case if I'm working with an agent from the CLI and then another agent like the cloud agent for instance can also refer to that persistent memory. The code review agent can also refer to that persistent memory. If I have third party agents accessing this repo instead of starting from scratch, they can also make a quick reference to the copilot memory. This also applies in case I have human contributors to this repo and they also using their own individual set of AI agents. We can have this shared memory that all these agents can make reference to. So that is what um copilot memory allows you to do. And what this announcement means is as you can see here right here from github.com on my repo in the settings I have the ability to now either delete or update the memory um the copilot memory logs that I have. So I can easily just delete them from here. And as you can see the source for this memory logs is from the copilot CLI. So if I switch to copilot CLI. So I'm just going to open this project but from my terminal. I'll open the terminal. Get into key mask. Hope this is visible enough for everyone. Yeah. So if I start copilot. So I'm just going to type copilot on the terminal. This will launch the copilot CLI agent and then I can now use the slashmemory I believe. Yeah, it's /memory command. So we've now improved these additional um commands that allow you to either turn memory on for your repository. You can easily switch it off or you can show and this should um yeah this should show the status of your copilot memory and as you've seen from the repo side you can now easily come in delete clear etc. And again to avoid having stale information, I believe this um this information gets dropped every should be about 28 or so days. Uh just so you're having fresh information about your repo available for agents to refer to. Okay, we have a question here. So does the memory get stored separately for cloud and for local? That's a good question. Now if I go back to my repo here, so you see these four memories and the source for these four memories is from GitHub CLI. So these memories were logged when I was working with Copilot from my local session, my local CLI session and they also reflect on the repository. So they are saved on a repo level and what that means is since the cloud agent works in the cloud it's not available locally it can also make reference to the same set of memories. So it's a singular it's a single persistent memory store that is accessible both from your local agents as well as your cloud agents. So you can let me know if that answers your question. But as you see from this UI, these memories were stored from a GitHub CLI session. So yeah, I believe that's that's a good that's a good improvement. So this way you have more control. You can delete this uh memory locations. You can delete this memory stores. You can update them. You can switch them on or off for your repositories as you see fit. Okay, we have another question here. Does the rubber duck agent have access to the copilot memory also? Absolutely. A rubber duck agent is a built-in agent that lives within the copilot CLI. So yes, it will have access to this um copilot memory. So good question there. So the idea is that all the agents that collaborate on your repository since you can set this either on a user level or a repository level that means all the agents that come together to work on that particular repo will definitely have access to this persistent memory. So this way you're not having to keep reexplaining what your project is, what your preferences are. All this can easily be captured in the memory and if you kick off a new session then the agent already has some idea of what it is you're working on. Um okay. So with that I think I'm going to switch over. That's the most recent announcement here. Nothing else has come in. So that's pretty exciting. So what we can do is uh yesterday we had the GitHub copilot devase online version. How many of us were able to join in the live stream yesterday? It was close to 6 hours. Um we had a live event here on YouTube. So just by a show of comments. So just let me know on the chat if you are able to join the live stream yesterday because we had some really good conversations around copilot in GitHub copilot in VS Code as well as from the CLI. So I'm happy to do a quick recap on that and just show a few demos. So for those who are able to catch yesterday's event that was GitHub copilot dev days uh let me know on the chat. If you're not able to that's still fine. I'm happy to just do a quick recap of what it is that we covered. Hey Kajal, welcome to the stream. It's good to have you. Okay. Um Oh, so no more questions. Very insightful GitHub copilot tips. Um I agree. We have quite a lot of new features being rolled out. So this is a really good time to just spend some time and really thoroughly talk about what these features are and what it is you can do. So since I'm not seeing anyone confirming that they were able to tune to to tune in to yesterday's event, I'm going to just do a quick walk through of the demo that I did around the copilot CLI which I think should get you started. If you've not used the CLI before, this can be helpful. If you've used it, I'll share some additional tips. So you can just put your questions on the chat as we proceed. So yesterday we had the GitHub copilot devs event. The recording is available on YouTube. So you can access it right here on YouTube on the GitHub account. You should be able to watch most of those sessions. But what I focused on specifically was Copilot CLI. And the reason why we had this specific focus on the CLI was we we continue to see this uprising of CLI native agents. And the reason we see that is because developers do spend a considerable amount of time in your terminals. So yes, you're you're writing your code on your files. Uh you know, you still do that manually to date, but then a lot of context is logged in the terminal. you are in the terminal either running your tests. You're in the terminal managing git. You're in the terminal um deploying your infrastructure or looking at the logs after your builds and your tests fail. So you do spend a good amount of your time on the terminal and often what happens is that either that context remains uncaptured or is just treated as secondary context. So to address that, we now have copilot CLI. You've most likely interacted with it. It's an agent that lives within the terminal. It has so many built-in capabilities and so many features which we're going to spend some time talking about today. Now in terms of getting started, you can easily get the copilot either from the Microsoft store if you're on Windows or using the common um tools across different platforms. Now what I want to focus more on is the three distinct modes in which you can use the CLI. Using it in its interactive mode is the most popular use case. Right? So this way you have I'll switch back to my terminal. So this way you have this um back and forth style of interaction with the agent. So this is the most popular way of using the CLI, but it's not the only way to use it. So one of the other interaction modes for the copilot is using it in its headless state. So this means that you can invoke the copilot CLI agent as part of an automated workflow. So in this case, you don't care about having back and forth conversations with the agent. You just want as part of your workflow, you have a stage that sends a prompt to the agent. You receive an output and then you take that output and inject it into the next stage of your pipeline. So think of the many use cases you have around automation workflows, your CI/CD pipelines, and then you can now easily just have copilot execute one or more of those stages. And to give you an example, I'll switch back to my terminal, I'm going to exit. So I'll use /exit. I'm going into to get into a different folder. It's called rubber Thursdays. This is the folder that I use to just prepare some demos that we can do live with you on this live stream. And so what I'll do is you'll see I have a script. I have a script right here. RDT. So I'm just going to run that script and I will leave it running in a different tab. Let us let us inspect what we have in this file. Okay. So our script file um is executing the script using bash. We're running it in in strict mode. And then I'm defining here that as output I want a single file. Now to give you some context is every single week we have this live stream and before I show up on this live stream I like to just go through the change log and familiarize myself with what's new. So I do this mostly every morning on Thursdays just to read through the change log what's new and then if I get some demo ideas that we can come and do together I also do that. So what I'm doing here is I'm trying to automate that process so that every single morning this can easily be a notification that I get and as part of my morning setup I just get a notification with the updates or what's new from the change log, what's new from the GitHub blog and then that will give me some starters for the conversations that I have with you all on this live stream. So that's the process that I want to automate a little bit. So I have this script file and I'm telling it as output. I want you to just give me a single file in the format of today's date rdt.md and then I'm passing in a prompt to copilot. So here's the prompt, right? So here's the prompt. I'm using copilot-p or alternatively you can use copilot d-prompt and then in double quotes go in with your prompt. Now, the first thing is if you're using Copilot in its headless state yet, in this case, we're using it as part of a script. You want to be very mindful and careful of how you use your quotes just to avoid any um shell misinterpretation of your special characters. So, in this case, I have my prompt inside double quotes and I'm telling Copilot that you are preparing content for Rubber Duck Thursdays, a weekly um a weekly GitHub developer live stream. Today's date is this fetch and read content from the change log and the GitHub blog platform. And then once you do that, return a markdown document as structured as follows. And then I just give it the breakdown. I want a one paragraph summary of what's new this week. I want a section for the change log. So this should just summarize what's new in the change log for this week. I want to get just three updates. So from the blogs, this should give me an idea of what's happening in the world of GitHub this week. And then at the bottom here, I want Copilot to give me some demo ideas so that I no longer just have access to what's new, but I also have some demo ideas that we can come and try out together. So I pass that as the prompt and then I I I pass in some additional parameters. So I run this silently. This way I don't want copilot to log all the session metadata. I just want it to log the output. In the case where you're using it in this mode where you just have it as part of a workflow, you of course want to care so much about just the output. You don't care so much about what happens behind the scenes. And then I'm passing in the dash dash no ask user. So this way it will not attempt to ask clarifying questions to me again because this will likely run in an environment where I'm not present. So if it's part of an automated GitHub action, most likely it will get triggered when I'm not even close to my computer. So it's just going to execute. And then the other recommended practice is if you're using any agents as part of any automation pipelines, you need to limit the number of tools that it can it can access as well as the number of allowed destinations, URL destinations. So this will just minimize um any undesired um out outcomes from your workflow. So in this case, I'm just strictly restricting it to the GitHub blog website and then I'm writing that into our output file. So I just executed this script and as output we should see a file with today's date. So we're going to open that file. Today's date is 28th. So we'll open that file and we'll see as part of that script uh we sent a prompt to copilot CLI and then we did get back a paragraph. So this is what happened this week from GitHub and then we have the change log and if you were there when we started this live stream we actually went through some of these items in depth. So you get a quick summary of what is new from the change log and I have a link that I can just click and verify and then I get this one sentence description of what's new. So I can use this just to prepare for this particular live stream. So you can see it has surfaced some of the new the new announcements that we've just talked about from the change log. And then yeah and then at the bottom here we have a section for the updates. So these are the new blogs that have the recent blogs that have been published on the said website. So that's good. And then the last thing is I expect for it to give me some demo ideas so I can show up on this live stream with something at the back of my mind that we can do together. So this is one of those modes that you can interact with the CLI. It's not interactive. It's not back and forth, but you can already see the potential for me to stick this in a GitHub action and then every single morning I get I get like a a a message probably on Slack or on Teams and then just have that as part of my morning setup routine. So you can already think of the many use cases and the many um projects that you can automate and then just have CLI part of that workflow. Okay, so we have a comment here from Muhammad says the copilot is not pretty good as a code agent. It doesn't understand anything and algorithms in multiple languages unified together ecosystem. All right. So looks like you're having a frustrating um experience there with copilot. So do you mind sharing a little bit more about your setup? Right. like how have you set up your environment to use copilot? Are you using any custom instructions? Are you using any customizations to get more out of copilot? Um, so I think I would be curious just to hear more about that. If there's anyone else who has either a similar experience working with copilot as a code agent or a different experience, you can also let us know. But my own personal experience is that out of the box you actually um if you're able to figure out how to prepare the right model for the right job and what I mean by that is and if I can give you a very practical example is if I am going straight to a coding task so I know the exact code that needs to be written. I like my go-to model would be GPT 5.5. It's it's a very powerful model when it comes to writing code. But if I have a task that involves designing any form of UI, I do not use GPT 5.5 because I don't get very good results but I just use say um a set model. Sonet 4.6 for example does a fantastic job at simple UI design. So if you crack that just mapping the right task to the right model. The beauty with the copilot CLA and of course with data copilot is that you get access to different models from different families cloud models um GPT models. So you're able to have all these models working together and you can leverage their different strengths and substitute their different weaknesses. So I believe Muham Muhammad I would come back to how have you set up your workflow to work with copilot. So, out of the box, you will get fairly good results. That has been my experience so far. But you can still take it a notch higher. I'm going to switch to my I'm going to switch to my terminal and I'll go to the awesome copilot website. Muhammad just let me know if you are familiar with this site but this website basically contains um some community contributed customizations and personalizations that you can use with GitHub copilot. So I see you follow up your comment with um hallucination results. So probably these are some of the these are some of the frustrating experiences you're having with Copilot so far. So what I would recommend and I'll drop this on the chat for you is before you even start using Copilot just go through this site and see if you can pull in some customizations before you engage your different agents. So what I mean by that is let's say for instance you have your own specific set of coding standards that you want the agent to appear to out of the box then by default it will just try and do the best it can from its training data but then you can come in and add your custom instructions. So if you scroll through this page, you'll see that we have so many instruction files. You don't have to write this from scratch. And an example that I can give you is let's look for security. I believe we should have some instructions on security. Let's open that file. So in addition to just using copilot as you get it out of the box, you can choose to always use this security and OASP um custom instruction. So what this means is as your agent is working, it will always refer to the instructions that are in this markdown file. So you can see that in this case it's providing a comprehensive secure coding standards based on the OAS top 10 2025. this needs to be updated with um with over 55 antiatterns, detection rejects, framework specific fixes, etc. So what you do is from this particular website you just come in if you're doing a very specific task find an instruction or find a custom agent or find a skill or find some hooks or some plugins that will simply just improve the outcome from these agents. So that's something that I'll share with you probably just give it a try. Um it's a really really useful um site where you can just come in here if you want copilot to do one specific task and do it very well. You can define a custom agent. So instead of just using the general purpose copilot agent that you get out of the box, you can come in here, pick a custom agent, give it the specific task. So if you're building your own system, you can have this accessibility expert implement or enforce accessibility policies on your particular application. So you're not restricted to just using copilot as it comes out of the box. You have a very broad spectrum of customizations that you can bring in and then just configure a workflow that reflect how you love to code. So I hope that answers your question. Please do give it a try and uh let us know if you get any luck uh or improve the outcomes that you're getting from copilot. Yes, I see your comment here that you've used it uh in your VS code environment and ruined all code structure. I think this is this is more of a setup of a setup challenge not necessarily from copilot because remember these are still language models. they will follow instructions. If you add copilot into a codebase that does not enforce uh you know the recommended practices, it's going to pick up on those on those practices. So if you've not properly um you're not using meaningful names for your functions, for your variables, such minor things, it's going to just learn from your code. So in as much as you're having these agents do most of the implementation from you, the learning is two-way. So it also tries as much as possible to learn for your from your existing practices. So I think this comes down to how you set up your environment to work with the agents. Ensure you have the right guardrails and instructions in place. Restrict the amount of permissions that you give to these agents. So it shouldn't just be able to delete files, move files anyhow. Just take some time and then structure a framework that you want all these agents to adhere to. So, I'll just again refer you to the awesome Copilot website. This is your one-stop shop for all the customizations that you can bring in to use these agents. All right, Philillip, I see you have a question here. How does GitHub justify this as legitimate? Um, do you mind clarifying what that this is in your statement? What exactly are you asking about? Um, what are you referring to as as um as part of your question? Just clarify that for me. All right. So, there's a question here in GitHub Copilot for VS Code. Is there a way to configure auto mode so that it always selects GPT mini instead of defaulting to codeex models in order to consistently use the lowest cost models? Um, good question and my answer to that will probably not what you're expecting because if you just think about how auto mode works and probably I can pull in the documentation here. GitHub compili auto mode. Okay. So I think it's this first result. Yeah. So if you think about how auto mode works, it's backed by two systems right here. So auto mode works um to intelligently choose the best model for you. And behind the scenes, it's using two systems. So one system will go and look at the models that you have access to. So the models that you can use and then it's going to look at the model health and the model availability. So it's going to eliminate any models that probably are not accessible. They they have some bit of issues. So it's just going to surface out of this list. It's going to um narrow down to the healthy models models that are currently available. And then system number two is now going to focus on your task. So it's going to analyze the complexity of your prompt of the task that you're giving it and then it's going to combine the two to make a model selection for you. So I believe that by virtue of just how auto mode works, it would be difficult to to have like a default landing for auto mode because as you see these factors will always vary. you will you have zero control over model availability over the model health. Again, this depends on the task that you give it. So, it's a bit nondeterministic. But if I think more about your question, if you do want to always default to GPT mini, I believe that's a separate setting that you can use. So, I wouldn't recommend you go with auto mode. If you've already identified that you want to use GPT mini for your use case, you can just directly go on and select that as the default model. I do believe that in VS Code, let me open VS Code here. I do think that that's an that's a setting that you can use. So, let me open up settings. Um, let's look for default model. So right here under chat. So for your agents you can select a default language model to use. This is for the explos agent. I don't know if we have one for the general purpose agent. Yeah. But you can see that you have like different options for you to set like default models you want to work with. This can be for the different sub agents. So build you have very many agents already built in before you even bring in your custom agents. There's uh there's an implement agent, there's an explore agent and so you can define the default models for each of these agents. So I I would recommend just looking through um yeah so looking through your settings and then just because you've already identified that you want to use GPT uh GPT mini as as your default model then you can just easily set that in the settings. Hope that's clear. All right. Um, okay. Uh, Phillip, I'm just trying to follow up on your question. Yeah. So I hope I hope that gives some some bit of clarity uh behind like how auto mode works and how you can just play around with the settings on VS Code for you to define the models that you want to run by default. So yeah uh back to my slides again keep the questions coming. So back to my slides we've looked at using or running Copilot CLI in its headless mode. Uh you've seen how you can use it in its interactive mode. This is like the most popular way of working with copilot um in the agent and you can interact with the agent and the different features through the slash uh through the slash commands. Um so Philip, I'm not ignoring your questions. I'm just having a hard time understanding what the question is. yeah. So, you have your you have your questions like as different comments coming in and I'm getting in comments from YouTube, from LinkedIn. So, maybe just try and have a single comment with the full question. So, this way I won't have to struggle reading through all the comments just to piece everything together. So, Philip, if you could do that, that will really be helpful. And if I have an answer to your question, I will definitely give it to you. Yeah. So, I see you have several comments. Just try and consolidate that for me because I'm trying to manage comments from a variety of sources and yeah, so apologies if that's getting lost in the comments. Okay. Um, so what I'll do here is I'm going to show you some additional built-in agents again that you can use directly from the terminal. Now I'll play, let me just play this because it's pre-recorded just to save us some bit of time. Um, so I'm in a project here. So I'm just going to get into a new project. I'm going to launch the copilot CLI agent. Um, so the first thing is you'll confirm here. I'll confirm here that I don't have any custom agents that I have added. So you can see I don't have any custom agents. So I'm going to use the built-in agents that you get out of the box with Copilot CLI. So the first agent that we'll look at is the code review agent. So this is a built-in agent available in the CLI. It comes out of the box where before you push your changes on GitHub, you can run slash review and this will use a dedicated agent that just do does a thorough code review of your local changes. Useful before you even push your changes on GitHub. I see there's a new feature. It's currently in experimental mode where you can use a security review agent just to focus on the security vulnerabilities aspect of your changes. But for now, we'll just use / review and then this will invoke the code review agent. Now, this is separate from the general CLI agent. And you'll see that it's using the so it's it's now using the code review agent. It's reading through my local changes. It's reading through my files. it will attempt to build and compile the application and then shortly we should see a summary of the code review findings. So this is a builtin coding um a built-in custom agent that just allows you before you even push your code just to have a surface level. It's like just have an extra pair of eyes looking through your code um to surface some obvious bugs, some obvious vulnerabilities, um some approaches that you can substitute just to improve the quality of your code. So you can see it categorizes them as medium or high or low which is which is pretty neat. Now at this point I can choose to either tell the agent to directly address all these issues or I can have the agent log them as GitHub issues and and then work through them one after the other or a third option which is what I'm going to do is I can ask for a second opinion. So I can ask for a second opinion using yet another builtin custom agent which is the rubber duck agent. We had a question earlier about the rubber duck agent. If you don't know about it, then this will probably be helpful. So after the code review agent has finished the review, it has surfaced these issues. I'm going to directly invoke the rubber duck agent using slash rubber duck. So I'm going to invoke it using / rubberduck and I'm going to provide I'm going to provide a prompt here. So this will allow me to get an independent critique of what we've done so far. So I'll ask the rubber duck agent to review the findings above to compare with my codebase and then surface any gaps. And what you'll realize here is that my general agent is running using an anthropic model. This is running using sonet 4.6. six. And so as soon as I go in with my prompt, um, the general model acknowledges that this is a this is a request for the rubber duck agent. So it gathers the context from my workspace and then it will send that to the rubber duck agent. So this is an independent agent that lives in the CLI. And so what you'll see is that shortly the rubber duck agent will pick up the task and you'll realize that this agent is using GPT 5.4. for so what is happening behind the scenes is that rubber duck is designed in a way that it enforces crossmodel family validation so that means if my general model is an anthropic model so I'm working with sonet 4.6 then the rubber duck agent will come from a different model family so the openi model family hence why it's running gpt 5.4 for. So we know that these different model families have their own set of strengths and weaknesses. So with a rubber duck agent, you basically get the best of both worlds. So if anything was missed in that initial review for by by using the set model, then GPT 5.4 is most likely going to pick up on it. And the team behind this feature actually published findings that if you use your general agent plus a rubber duck agent, then you get a performance level that is close to OPAS level. And we know that the problem with OPAS is how expensive the OPAS models are. So what this means is you can use a fairly affordable model, sonet GP5.5, pair that with the rubber duck agent and that will give you a performance level close to what you would get with opas. So you're getting something close to what you would get with opas but at the cost of more affordable model. So that's the whole design pattern behind the rubber duck agent. So if you run your main like if you run the main agent using a GP model then the rubber duck agent is going to spin up using a cloud model and vice versa. So that's an interesting concept. I challenge everyone to just try it out. See if you note any improvement in the outputs and the outcomes that you get from the agent. all right. So, Phillip, now I see your question. Uh, let me just put it on the screen. So, on GitHub, repos are posted as MIT license and educational. They get flagged as malicious by most security platforms. I'm going to go to post more and send in a single H. Yeah. Um interest. So they get flagged as malicious by most security platforms. So I'm I'm not sure. Just let me know if this um answers part of your question because I think the last part of it cut off. But whenever you're using Copilot, there is an explicit setting that you can configure. And what this actually let me just show you right here. So, there's a I don't know if you've heard of the um block suggestions matching public code um setting. So, let me see if I'm going to find it here. Should be in co-pilot settings. yes. So there's this setting right privacy. So suggestions matching public code. So if you have this allowed what this means is as copilot is generating your code for you. So it's generating code to eventually um reveal to you as the user. before it shows you this code. If you have this setting enabled, it's going to look at the generated code and just look um and just compare it against the full index of its training data set. And if it finds code that matches what it has generated, then it won't show you that code, right? So if you have it enabled then out of the box copilot just before showing you the final code snippet that it generates it's going to look at it compare it with a full index of code that was used to train that model and if it finds an exact um code block of code then it's simply not going to show you that particular piece of code. If you do not have this enabled, it's going to show you the code, but it's going to link you to where that particular code um or to where it has seen similar code. And it's also going to give you information about the associated license. And so with all that information, you can now make an informed decision of what to do with the suggested code. So the two options here is you can enable this option. What will happen is before Copilot shows you the final code that it has generated, it's going to look at the look at it against the full index. If it finds similar code, it won't show you. Or if you have it switched off, it will show you the code, but it will be transparent and let you know that, hey, this is where I found some code that matches what I have generated. It will give you a link for you to go and look at the code yourself. And it will also give you information about the associated license. And with that you can make an informed decision on what you want to do, how you want to proceed with a particular code. So that was the case. Uh last time I picked that up was in the VS on on VS Code. I don't really know how that looks like from the CLI, but yes, we do have that specific setting that you have to either enable or disable for your particular copilot usage. So that should address part of your question around licensing, right? Then yeah um I this ps this part I don't really quite understand. They get flagged as malicious by most security platforms. So that's not really really clear for me. in case someone on the chat has a better understanding of that question. Um, happy happy to have you help in the discussion. All right. uh but I think what I'll just share as a general comment here and this is not specific to GitHub copilot is that at the end of the day these are powerful models which can be used for fairly anything. Yes, we'll advocate for people to use these ecoding agents or any AI agents for that matter um use them for good. But again, in the wrong hands, then we do have and we've heard of cases where people exploit systems because they have access to very powerful models. So at the end of the day, it really is within the control of the user. So how you choose to implement and use these coding agents to some extent might not be within the control of the provider but the providers of course do have the responsibility to have built-in guadrals where it becomes extremely difficult to be a bad using this model. So again I will just reiterate on that fact. Yes we will advocate for responsible use of AI but unfortunately that will not always be the case. So you have to also use it very carefully. Exercise a lot of caution. If you're pulling in um customizations, uh let's say you're pulling in custom agents that people are using out there, you do want to take an extra step to validate what it is that you are getting from these models. Okay. Um so I see we're out of time, but I have just one more demo to show. Uh so we've seen how you can use the two built-in agents that is the code review agent to review your local changes before you push your code and then two the rubber duck agent to enforce that cross model family um critique or val validation and then lastly here is um we all know that the relationship between developers and agents continues to evolve. Yeah. So that relationship continues to evolve. It's no longer a onetoone. So it's not just one single developer working with one agent. You do have multi- aentic workflows or systems where you have an agent working with sub agents and out of the box without any additional customizations. Copilot CLI supports a hierarchical framework where you can have one main agent dispatch or distribute tasks to other sub agents, manage them and then just consolidate their output. And so for that, the last part of this demo is using the /fleet command. Right? So I'm going to switch back to GPT 5.5. I'll stick to the default reasoning effort. That's medium and the default context window. So what you'll see here is I'm going to use the /split command. Right? And then I'll go in with a prompt. We now have the identified issues from the code review. Address all the issues in this code. Ensure you have one list to track everything as it's as they are fixed. And then test this project. It's an extension. It's a VS code extension. So test the project before you exit the loop. And so what Flit does is that my main agent here, GPD 5.5, is going to analyze my prompt. It's going to break it down into individual um items. It's going to identify which can run in parallel if we have some form of dependencies and then it's going to dispatch three different sub aents each with their own focus areas. So you have the three sub aents running here and they can use slashtasks to closely monitor or just manage the different sub agents and see them as they work. So what happens behind the scenes here and what makes this a really powerful built-in feature for copilot CLI is that these sub agents run their own individual context windows. So the back and forth, the loop that these three individual sub agents are running do not count into the main context window, but rather they are their own separate context windows. And then this main agent, the orchestrator agent is just going to validate the output from the different models. And you're seeing here we are seeing you're getting a prompt to store this as a memory point. So if you are here at the beginning of the live stream, we talked about copilot memory. So this is how it looks like. This is you being asked by the agent, hey, I've learned something new about your project. Do you want me to store it in the copilot memory? And then this way that copilot memory will be accessible across all the agents that interact with this repository. So now you can see here the main agent is monitoring what these different sub agents are doing. It's tracking the completion of the tasks. It's going to validate um the output. It's going to run the tests and eventually it's going to give me a consolidated report of everything that was completed and achieved by the three different agents running in parallel. So this is useful because you don't want to bloat your main context window. Remember um the more your context window is filled up, the lower the quality of the output. So what happens here is with these distinct sub agents each running their own context windows then that means that my main agents context window remains to be clean and it's only getting this output and factoring in output from the individual sub aents. So yeah, so with that um I hope that demo was useful. Just again sharing some bit of best practices how you can use the CLI even more. How you can have like different agents collaborating with each other. How you can leverage different builtin custom agents. Use the rubber duck agent to improve your performance. use the code review agent to just do a quick um a quick review of your code before you push it. And yeah, so let's see if there's one more thing we can look at before we exit. Yeah, so this this last mode um this last mode is is really interesting, but I believe we do not have enough time for it. So what I'll do is I'm just going to quickly talk about running Copilot CLI in server mode, right? And so if you run copilot CLI in server mode, it exposes a JSON RPC port which your client applications can now um connect to and have copilot CLI as a core AI backend for your systems. And to put this into perspective, if you've not tried out the GitHub Copilot SDK, I believe this should be your um your your homework. If if you will your homework for today's session, just go out and try on and try out the GitHub copilot SDK because this shifts the conversation. It's now not you building with AI. Now you're using copilot CLI to power AI functionalities for your applications. Now I have another project here that I will briefly demonstrate the concept of running and using copilot CLI in server mode. This here is study sync. It's a little solution that I use to manage my schoolwork. So you can add in your different courses. You can add in your different notes, lecture notes, additional reading material. And then I recently added this AI chat feature basic concept to chat on top of your lecture notes. So for students, this can be useful to just um ask the agent, hey, where exactly did we talk about this concept? Which lecture was that? yada yada. So it's just basic chat over document functionality. But the back end behind this system is not foundry, is not langchain, is is basically copilot CLI. And I'm using the SDK behind the scenes to connect to a local instance of copilot CLI, which is what I'm using as the back end for my AI features. So if I switch back to the terminal here and launch copilot CLI and then I will use / resume to see the sessions the local sessions I have with this agent. You'll see that this last conversation that I've just had on my application was actually logged as a CLI session and you'll see the exact prompt that I sent. You'll see the custom tools that the CLI agent used and you'll see basically the whole conversation that I had with this agent via my client application. So this is the third and interesting way of using copilot CLI. So you can build your own PC's if you're putting together a prototype for your organization for AI solutions before you even go off to think and explore agent hosting platforms. If you already have access to GitHub copilot, you can leverage CLI the the CLI and just have it as a back end for your AI features. It's really easy to get started. We have proper documentation on the copilot SDK. It's available across um a variety of of languages. So this is definitely something that you can try out yourself today. So if you're yet to try it out, let me just grab the link for you all. That is GitHub Copilot SDK. Should have the repository here. I'm going to put it on the chat. And this will basically allow you to programmatically connect your applications to use the CLI as the back end for your AI features. So definitely give it a try. Let us know um let us know how the experience is. We have these available SDKs and we do have some additional ones that are supported or maintained by the community. So things like C++ we do have such variations but they are entirely supported and maintained by the community. Okay. Um see any last questions? Next week is build by the way. So looking forward to an amazing time next week. uh for those who will be there in person enjoy build most of us will be joining online so I know we have so many interesting sessions and just before we wrap up the very last thing I promise this will be the very last thing is uh of course I hope that you're all attending building next week but if you're using copilot CLI I don't know if you've all seen this really cool feature where you can use copilot CLI to actually walk you through the session catalog for build. So if next week you plan on joining the conference that is Microsoft build. Let me show you a quick hack that you can use. So this is the build site. It's build.microsoft.com. If you head there, there is this note over here. GitHub copilot cla lets you run build from your terminal. What does this mean? If I click on learn how to do this, it should redirect me to the build CLI repository and I should have instructions here on how to run the build CLI plugin. So, just because we can, I am going to do that. If you need to drop, no worries. I know I'm over time, but this is recorded, so you can always come back and rewatch. So, I'm going to start a new I'm going to start a new uh session. I'm going to open the pilot. Then I'll just copy this command here to install the plugin. So, it's /plugin install Microsoft build CLI. Right. So, we have the plug-in installed successfully and then I need to restart the CLI. So, I'm just going to do that. Restart. And so, the idea here is that I can type a prompt like what build sessions are relevant to my project. So, if you run the CLI agent from within your project, then it's going to analyze your dependencies. It's going to analyze what technologies you're using, what's the nature of your project, and then it's going to use that to recommend some sessions from the build catalog. So, I think that's a pretty interesting use case. So, I can go in with a prompt like, uh, do we have any sessions on GitHub at on GitHub at build? Oops. I'll send that in and I expect to see the CLI agent here use the Microsoft Build plugin. Yeah. So, it's pulling in the skill and it should be able to connect to the build catalog, browse through the sessions, and then come back to me with a list of sessions that are relevant to GitHub. And this can be any topic of choice, any technology of choice. So let's see if we are able to successfully get that. So summarize GitHub sessions at build. It's trying to fill time and go through the catalog, narrow down to GitHub sessions, and I expect to at least get a list of available sessions. And there you have it. Uh we have 36 unique GitHub sessions at build. This will be a busy week. Uh so you see the sessions with their codes and when these session will be these sessions will be happening. Uh you can at least you can go deeper into some of these sessions. So this here looks interesting. Your agent anywhere multiclient multi-device. So I can ask the agent to tell me more about BRK 20 uh that is 206 BRK 206. This way it's able to just pull and have a back and forth with a build catalog and it can give me additional session details. And as I said before um yeah so this is a session it's a breakout session level 300 these are the speakers this is when it's happening this is where it's happening this is a topic and here's an abstract so I can easily just know which projects or which sessions I can attend next week at build and then you can see this call out actually that given your project so I've launched the agent in my kask project now given this project. This session is quite relevant. The copilot SDK um is is going to be highlighted in the session. So, you can already see how you can just work directly from your terminal, have it scan your project, and then recommend sessions that you can attend that are relevant to what you're building. And then after build, of course, you can go in ask for, you know, what should be the next step after this session. You can ask it to scaffold new projects based on a session. So if you attend a session, you want to apply what you'll have learned, you can work with this um skill to scaffold a new project which will just set you up for success as you are implementing what you learned at build. So with that I will call it a day. Uh yes this session is live and the recording will be available at the same link so you can always come back and rewatch um later on. So this session will always be here for you to come back and rewatch. Okay. Uh yeah. So for those attending build again, happy building next week. We will likely connect on Thursday either myself or my colleague. But yeah, with that I will call it a day. Thank you all so much for joining. Do enjoy the rest of your days. Bye-bye.