Name: Copilot 201: Engineering Workflows with CLI, Agents, and MCP
Uploaded: 2026-09-23T17:01:23.763Z
Duration: 45 min 20 s
Description: Copilot 201: Engineering Workflows with CLI, Agents, and MCP

Transcript for "Copilot 201: Engineering Workflows with CLI, Agents, and MCP": Hey, everybody. Thank you so much for joining us this morning. It's great to see so many of you here. I'll begin to share my screen so we can get started. Awesome. I'm really excited to spend the next forty five minutes, exploring what's possible with the GitHub Copilot CLI. And before we get into the session, I just wanted to quickly, introduce myself. My name is Marcos, and I am a senior solutions engineer, here at GitHub. And I'm joining you from, Austin, Texas where it is still incredibly hot outside, despite the calendar insisting that summer is supposed to be over. And I've been with GitHub for close to four years now, and time does really seem to fly when cruise ships are happening, every week, which is actually very relevant to what we are talking about today. During the time I've been here, I've had the opportunity to work with a lot of different engineering teams as they explore how GitHub and Copilot can, fit into their everyday workflows. And that is part of what makes today's session so exciting for me because the CLI itself has significantly changed in a relatively short amount of time. Today, we're going to be moving beyond the basics and be looking at how the CLI can support real engineering workflows from understanding unfamiliar systems to working with issues, writing tests, implementing features, and reviewing changes. Before we get started, though, you should see a poll on your screen, and I'd love to get your feedback. Essentially, we want to know how often do you use, the CLI. Please take a moment to respond. It's really nice when everyone participates, and it really helps to frame the conversation that we are, having today. You should also see a button at the top of your screen that links to a Copilot CLI quick start and additional resources. If it's the first time that you're using the CLI, the quick start will give you what you need to essentially get started and get familiarized. And if you are already using it, there's also some additional materials there as well as in the docs page that could be useful as you continue to explore, what's possible. So with that, let's take a look at the agenda for today. We'll work through six different, sections today. First, I want to look at the trajectory of the CLI itself. Like I said in the beginning, a lot has changed since it was first announced. And that context is important because the product that many people may have remembered, from, a few years ago is very different from where the, product is, today. From there, we'll take a look at how MCP servers can be used within the CLI. Then we'll walk through a practical engineering scenario, which could be familiar to some of you, which is essentially around, joining an unfamiliar codebase, getting oriented quickly, and, essentially making meaningful contributions as, you are making your way through and, you know, writing tests. We'll also look at how code review can happen directly in a CLI before anything is pushed. And finally, I wanna close with a very important topic, which is, essentially permissions and boundaries. Essentially, how to think about what the CLI can do, where it operates, and how you can maintain control, at the end of the day. My goal here today is to not only show you individual capabilities, but essentially to connect them into an engineering workflow that helps you move from understanding a problem to making a contribution with, more confidence there. Oops. I like to start with the trajectory of the CLI and Copilot more broadly because it is really easy for us to use these tools on a day to day without really noticing just how much they have, changed. The CLI itself was first announced in 2024 as a tool that could simply suggest and explain CLI commands. At the time, it was bundled already with the, GitHub CLI, so you simply installed it as, an extension. And that was really useful back then when it first came out, but it's very, very different, a very different starting point from where we are today. And if you fast forward a little over a year, the experience had been completely revamped. September '25 was when the CLI was first shipped as a standalone terminal tool, in its preview stages. And a month later, the ability to deploy custom agents was introduced, and that again completely changed, the experience. Earlier this year, the CLI became generally available. And throughout the year, a number of very important updates have continued to ship, including last month, the plug in marketplace as well as a few other things. I think the key point here is that the CLI itself is no longer simply the g h explain or g h suggest experience that some people may remember. So I think that's why it's really cool for us to have this Agenstic session so we can see the surface, where you can interact with context, tools, agents, and workflows while staying close to the environment where the engineering work happens. The change in the overall timeline here is really what makes the rest of today's discussion, possible. So with that context in mind, let's move from, you know, the story of the product here to how it can, show up in real workflows. So let's head over into github.com. I have a couple of different repositories we're gonna be working with today. This one here has quite a bit of issues as well as a few PRs open, and it is a fully functional application that is already running. If we look here in the readme file, it is a marketplace for cat supplies. So very, very interesting, very cool product. If we go here to the issues, we can see that it has, issues ranging from features to tasks to bugs. We have some epics as well and some labels within these issues. One that specifically caught my eye is the performance optimizations issue. And if we look at what the issue says, it says we need to calculate loading times and optimizations we can make to improve the performance of this application. So it's not necessarily about changing the code just yet. It's just, you know, calculating things, loading things, and it is a perfect candidate for us to run-in the CLI and have it run-in the background. So what I want to do here is open up my CLI, and I have the, repo cloned, and I have opened the CLI right here. To open the CLI, it's very simple. You can simply just navigate to the repository itself. If you wanna do work in that repo, type in Copilot, and you are good to go. If you have any questions about how to install it, again, we have a button up top here that you can click, and you will be able to have a quick start guide that will take you right through the steps. But going back here into this repo, I have also done a couple of things that we will be talking about in more detail, but the prompt that I want to give it is essentially this. I want you to pull this issue using the GitHub MCP server, and I'm putting the issue URL there just for reference, Perform the tasks it requests and comment the findings back in the issue itself using the GHCLI under my account. And this is interesting, and the reason why I'm doing this is, again, there's no really code changes happening in here. I simply want to save some time, and instead of opening, you know, the application, trying to calculate things, and maybe even getting it incorrectly, I am asking it to run it for me, post those results back. And the cool thing is that once those results are back, we could potentially even create sub issues or just different issues altogether to actually implement those optimizations. So let's go ahead and give it a go. And while this is running, you may notice that I have the CLI in autopilot mode. Autopilot allows Copilot to continue working through a multistep task, without coming back to me after every step. It can investigate. It can use tools. And as we can see here, it's using the MCP server. It can make changes, validate its work, and continue until it believes that a task is either complete, it hits a blocker, or reaches a continuation limit. That additional autonomy makes the execution boundary a bit more important, and it is something that I wanted to talk about as well. The CLI gives us two sandboxing options for controlling where work happens. There is a local sandbox where it keeps the session on my machine, but it restricts what Copilot initiated commands can access across, different things like the file system, network, credentials, and system capabilities. And there's also a cloud sandbox, which moves the entire session into a fully isolated, ephemeral Linux environment hosted by GitHub. That can also be useful when I want something like, stronger isolation or I need to offload some local compute maybe or just want to run multiple tasks without consuming my machine's resources at the same time. I am not using a sandbox for this particular demo because this is essentially a controlled environment created specifically for, the session. In a day to day workflow, though, especially when granting broader permissions or running unfamiliar code, sandboxing is something I would strongly, strongly consider. The other piece of work that we have in here is the MCP server. So if we, scroll up, we can see here that it's using that to grab, issue details. It comes built in the Copilot CLI, so there was nothing additional for me to install or to configure. I can essentially just give it access to my GitHub context and let the task move between the local repo and the issue and be good to go. And one of the cool things here is that even though I am running autopilot, it will also run-in a mode that if it thinks that it needs my permission for something very specific, it will. So as you can see here, it's saying, hey. This action may read or write the following path outside of paths currently allowed for this session. Do you want to allow this? Yes. I do. And I want you to remember that. So, again, the autopilot session can continue its work. And speaking of the the MCP server, I think having it as a default matters because GitHub is usually where the surrounding engineering context already lives. So having to manually cop copy information between, you know, that issue and, you know, between the browser and the terminal, I can simply just let Copilot follow the task across those surfaces, you know, that it needs. And the GitHub MCP itself is the built in starting point, but it's not really the limit of what we can connect. And I wanted to bring in another thing here for us to take a quick look at, which is the, GitHub MCP registry. This is a place where we can browse servers for other tools and services. If a workflow depends on a system beyond GitHub, the registry gives us a place to look for an existing integration instead of starting maybe something from scratch. So here we have a couple of them by Microsoft, by Chrome Dev Tools, as well as a few others. And, you know, if you are curious about a task or a platform, you can essentially paste it in here, and most likely, there would be an MCP server already, for it. The Copilot CLI can search and install servers from a configured registry like this one, and organizations can also use, registry and allow list policies to control what is available for developers as well. So I think the takeaway that I want you to have with this here is, pretty simple. You know, GitHub connectivity is available immediately. It comes bundled in with the CLI. You do not have to worry about anything else. And if there is anything else that you may need, you can go to the registry and start looking, and it will most likely, have something that you need. Cool. So let's close this, and let's go back here into the terminal. It seems like the task is complete, and one thing that I wanted to specifically call out after it's done so we can see that the Frontier models are not always necessary in here is that for this task, I used auto mode, and it only consumed 53 AICs. So very, very cheap to do a piece of work that would have taken me at least probably half a day if I want to do it accurately, if I want to measure everything, if I want to have some redundancy, calculate these things, and then, you know, decide what needs to be done. And if we click here into the issue comment itself, let's go back here. We can see that everything has been posted, for us. We have the, measurements in here, the estimated loading times, the root causes, and the recommended optimizations. And the cool thing again is that you could point Copilot to this issue and say, okay. Now perform these optimizations right here or create, you know, sub issues, you know, or just, you know, be creative and bundle this in every other way. The point being here is that it took us a few minutes to complete a task that would be very time consuming, and it was very, very cheap to do so. Cool. Another scenario that I want to run us through belongs in another repository. This scenario could be maybe a familiar one with, you know, some folks here around the call, which is essentially joining an unfamiliar, repository. So what I wanna do is I wanna go back to the CLI. We're going to, switch into this other repo in here, and I want it to give a very specific prompt. I want to ask for something like this. I wanna say, hey. I just joined this team, and I have never seen this repo. Give me a quick overview here of what it does and anything that I should know before I touch it. Use the GHCLI if the trail leads outside of this repo. Keep it brief. I don't want any specific plans. I don't want, any, CI logs. I just want a very simple definition of what the repo does. And, I always like having diagrams, so if you can, you know, draw draw a draw IO diagram of how it all fits together. And as we can see here, something very interesting already started to happen. It called the skill draw. Io diagram generator, which is essentially a skill that I, added into this repo myself. There are a ton of skills that you can browse through. We do have a repository called, Awesome Copilot, which is this one right here, that will contain a ton of skills, a ton of different custom agents that you can play around with, plugins, like we just talked about in the new release, instructions, as well as a few other things. If you haven't used skills, you can think of skills as you giving specific capabilities to the model, and you don't have to necessarily say, hey. Use this specific skill. You can just reference something, and it can interfere, if that skill would be beneficial for it. So, really cool to see it in practice in here. And what I like about this prompt is that I'm not telling, again, which files to inspect or where the important pieces, really live. I'm giving it the, you know, same outcome I would want as a new engineer. You know, tell me what this repo does, and tell me what I need to know before I touch it. I have also explicitly allowed it to use the GHCLI, as we saw, if the trail leads outside of the repository. And this is important. It wasn't there just, you know, randomly. I like doing this because a repository does not always tell us the whole story, and if I contain myself only to that repo, I may not get as much of an answer that I was, hoping for. So if it depends on another service, a shared package, or a separate source of truth, I would not discover that by only looking at the local files. And, again, rather than turning all that into a complete vault text, again, we are leveraging that skill to have what it finds be turned, into the diagram. Awesome. Cool. Right here now, it is essentially, finalizing things. We can leave it running for a little bit. And one thing that I wanted to do is, do another task here, into this repository. So if we go back here into the checkout service repo that we are just learning about, we can see that there are two issues already created here. There is a task and there is a feature. If we look at this task here, it is saying that the test coverage is 12.76%, but the CI gate expects, 80%. So it's giving us a problem, what we need to do, notes for, you know, whoever picks up, maybe Copilot, as well as, a bit of acceptance criteria in here. So this is another issue that I could work with the CLI and have it deliver something, for me. And if we look into this other feature one in here, it's saying that, we're supposed to reject cards above a maximum order value before authorizing payment. Again, context, what we need, acceptance criteria, and notes. This is a template that my team likes to follow, so that whenever we are picking up issue ourselves, assigning to Copilot, or, you know, doing some cocreation with it. We have everything we need in a single place. Before we start working on these, let's see right here, what this task is looking like. Cool. So it seems like the task is complete. It's giving us a quick overview in here. It's saying that the checkout service is a Node 20, TypeScript express service for this, you know, checkout in our org. You know, it does this. It does that. It gives us all of the, moving pieces as well as some, callouts before touching that repo. And it's also cool that it built that diagram for us. So let's go ahead and say open diagram in finder and see what it generates. So I'm excited to see, you know, what it came up with. So what I'm going to do here is open up, Drial, live here into the repository just to blank Canvas, and what I wanna do is drag this in. Cool. Nice. So from not knowing where the repo, what the repo was, what it did, now we have a better understanding of it. And now we have a diagram that we can study before touching anything so that if something isn't clear, we can go ahead and analyze this. We can make any changes. We can ask questions about it now that GitHub Copilot has that context. So very, very cool. Really nice to, get a good understanding of it. Cool. So now let's tackle both of these issues here in, the remainder minutes that we have. So I want to clear this session, and we're gonna do something, interesting in here. Again, the session was cleared, but one cool thing that I'm not sure if a lot of folks realized, that took about five AIC. So 5¢ to get a good understanding, get a diagram, that is a pretty, pretty good deal. Auto mode came to the rescue again. So to work on these two issues, we're gonna be doing a couple of things. So, I want to, first of all, issue my prompt. And, what I am doing here is that there there's a few important details in this prompt. First, I am not asking Copilot to blindly implement what the issue says. Issues can become stale, so I'm asking it to, first of all, verify that the current coverage numbers, are, you know, what it says it is, and establish its own baseline before making a change. Second, I'm giving it a priority that is essentially, based on risk rather than a vanity metric. This service writes to a fine finance ledger. So a task that protects the path where money is being calculated or recorded is more valuable to me than adding coverage to an easy line just to increase that percentage. So we are being, a bit more, careful here to not say, you know, increase the coverage up, but increase the coverage in the right places. I'm also, asking it to investigate where the domain types and tax rules, are coming from. And finally, I think this is cool because this is an end to end engineering task. Right? Copilot needs to, first of all, investigate the issue, understand the surrounding code, add meaningful tasks, run them, work on a branch, and open a pull request. It can do the work, but the final merge remains still, my decision. So we will, be the one sort of, approving that. This task still has some work to do as we can see here, but I do not need to wait for it to finish before we move on. There is another open issue like we saw in here in the same repo, so I am going to work on that issue in parallel. The challenge is that I do not want two autonomous sessions, you know, editing the same working directory or trying to use the same branch. To separate them, I am going to use something called a work tree. So let's go back here into this other, window. I'm going to type in work tree, and I am going to issue my prompt so we can start, working on that. Cool. So a, git work tree, essentially gives me another working directory connected to the same repository with its own checked out branch and its own files as well as everything that it needs. Scenario one from issue one, like we saw, can continue running there, and scenario two is going to be working here now with an isolated, checkout. And this is nice because it prevents the local changes from colliding, and it means that I do not have to stop the first task, stash its work, and switch to the original repository back and forth, you know, between branches. But another thing too to keep in mind is about the boundary. The workspaces themselves are isolated, but every shared system is not isolated. The two branches can still use the same CI capacity, external services, or test environments, and the resulting changes may still overlap logically. But at at the repository level and working directory level, each task has a clean place to, operate. So we can see that by running that, Copilot has created a separated work tree for the second task, and it will begin its work. Another cool thing too is that for this scenario specifically, I am using, down below here, project HydraFusion. HydraFusion is a research preview focused on model orchestration. So there is a nice, blog post that we, essentially did about it. Instead of asking us to choose one model and hope that it is the right fit for every part of the task, HydraFusion essentially, decides, how the work should be handled, at runtime. Depending on the request itself, it can use one of the three patterns that we see here, on the screen. It may choose a single model to complete the task, directly. It may use a cascade where an efficient model gets the first attempt, and work can be then escalated if it does not clear a quality gate. Or it may use a critique pattern where one model drafts. Just wanted to confirm if folks can still hear me. I did see a message here that audio cut out. So I just wanted to validate that. Okay. Works for for other people. So I will continue, but we are recording this. So, if something is going on connection wise, you would be able to to watch it again. Cool. So going back here, it may, also do the critique pattern where one model drafts the results, an independent model reviews it, and the original model gets an opportunity to revise. And I think the cool and important part here is that complexity stays behind the scenes. You know, I select HydraFusion as a model like we saw. I give it a substantial well scoped task, and it chooses a workflow intended to balance quality, cost, and latency. That makes this feature a good example, that we just asked for. It requires implementation. It requires, you know, tests here on both sides of the boundary. It also, requires, you know, validation, judgment about whether a repo change is sufficient for production. We're just essentially not asking for code. We're essentially asking for the system to reason about completeness and do whatever it takes to get there. And I think this is cool, and let's see the progress in here. As we can see, it shows the cascade mode. Nice. So if we go back here into, the, blog post, cascade mode, is this one right here, in the model, bigger here. Cool. Awesome. So, and I think while this is running, it's cool to also speak how HydraFusion also reflects a broader shift in how we think about models. The conversation is very often framed as which single model is the best. But in practice, developers already use different models for different jobs. We may prefer one for speed, another one for deeper reasoning, and another one for maybe a a second set of eyes. Before this was released, I myself was using Frontier models to draft plans and lightweight models to, you know, execute them. And HydraFusion really turns something developers already do manually into a workflow that the system can manage for us. So it just really, really helps with a ton of the cognitive load, and the management that you would be doing behind the scenes. I know we have a few minutes left before we, start q and a. And while this is running, I wanted to bring something up that, I think is very important and has been present in every demo, which are permissions and trust boundaries. As we give Copilot more autonomy, we also need to be deliberate about the authority that we give it. Those are two different things if we think about it. Autopilot, like we saw earlier, controls how independently Copilot can continue working through a task, and permissions control what it is actually allowed to do while it does work on that task. I can let Copilot reason autonomously without automatically giving it access to every tool that I have, every directory, and every network destination. The goal here is to give the agent enough authority to complete the task, but not more authority than the task itself requires. In the CLI, like we're seeing here, that boundary exists across several layers. There is one which is the file system boundary, which will let it know which directories and files it can access. There's the tool boundary, which commands, MCP tools, and other capabilities it is allowed to use. There's a network boundary as well, which is which external URLs and services it can reach, and there is also the credential boundary, which identities and credentials are available to those tools. MCP servers, like we saw, are part of this trust model as well. Adding an MCP server does not simply give Copilot more context. It may also give it additional actions that it can perform in another system. In our case here, it was GitHub. It could be, Atlassian, like someone asked here in the chat, as well as, a few other, systems. And that's why I want to understand which tools a server exposes, whether those tools are read only or can make changes, and what identity the server will use before I add it to a specific workflow. The same principle applies to skills, custom agents, plugins, and repository instructions. These are useful because they shape how Copilot behaves, but that also means that they become part of the trusted configuration for the session that I am working with. So if I am bringing something from the community, I should review it very carefully just like I would review any other dependency that I am using, in my repos. And sandboxing, like we saw, gives us another boundary around execution. A local sandbox restricts which, Copilot initiated commands can reach on my machine, while a cloud sandbox move the session into an isolated environment hosted by GitHub. And I think another one to keep in mind as well, which a ton of folks may not realize the power, but it can be extremely, beneficial in your day to day are work trees, which we, you know, used earlier. They solve a a different problem. They isolate working directories and branches, so this way, parallel tasks do not overwrite one another. They're excellent for workflow isolation, but they're not a security boundary. So it's really, really important to keep that, in mind. Both tasks may still share, you know, credentials, CI systems, as well as, a few other things. Cool. Awesome. Nice. So we have this running right here. As we can see, it is using, the cascade, functionality here. It did a main pass in five minutes, and it completed. And then now it is asking for a review of the second model. And now it's taking, close to three minutes to complete. So it's really cool how we can see both models here and the system picking what it wants to do. And as we can see, it only consumed 33 AICs as of now to complete a pretty complicated task. 37, just jumped, as we were speaking. And we can leave this running. We do have about, you know, fourteen minutes back, for q and a. I did want to give you this time. If we have time before the end, I want to pull this back so we can see the work that it generated. But as you can see, it is very similar to the work that we're doing before. It's just changing at the model level. We will also be sharing, a few links again in the resources tab. So if you haven't clicked yet, there's a ton of cool stuff for you guys to see. Same with the, call to action button there up top. It's really a nice quick start guide, that you can, get familiarized with. But with that, I want to move into q and a, and I wanted to thank you so much for your time. It's very exciting, and and as you can see, time does really fly here whenever we are working with Copilot having some fun together. But I will stop sharing now, and I want to go ahead and, look at q and a, right here. Cool. Let's see. My colleague was able to answer a few of them. Let me see. Let me pick up a few ones right here. I just need to read more. Okay. Cool. So the first one, I think, is is very nice, which is what is the pro what is the benefit of using this CLI mode compared to using GitHub co pilot and Versus Code? That's a really excellent question because, I think there's no right or wrong answer, on which surface you're using. It's just whatever makes the most sense to you and the task that you're trying to complete. So let's take that initial, optimizations one as an example. I could very well run that on Versus Code, on the Copilot app, within github.com itself, but I think having that close to me, but at the same time be in the background running in a CLI session is what made sense. So that's why I opted for the CLI. I think the cool thing is that your subscription gives you access to all of the different surfaces that you can pick and choose. You can maybe test one. You can run the same task maybe through another surface to see if you like it better. But, again, to answer your question, there isn't really a right or wrong. For me here, it's just whatever makes the most, sense to optimize and and save you time and add to your, experience. Cool. And then Mario here asked a similar question. You know, using the CLI in the terminal of Versus Code, isn't that the same thing? It could be similar, and in my opinion, it would add, additional layers to it because in the Versus Code terminal, you would start the Copilot CLI, and it would have that CLI running inside of the IDE. So sometimes to me, that can be, a little bit noisy. So that's why I like to leverage work trees and sometimes some different CLI sessions running, on another monitor while I am doing some more focused work on Versus code and my main monitor. So I think the point being here is that, like we saw in that repo, there were, I believe, 16, you know, different issues. And I pick, maybe four or five issues to work at, the same time. Right? Maybe four of them that I'm going to be uploading to Copilot into a variety of different services, and maybe one of them that is higher priority, higher sensitivity that I'm going to be coding myself, maybe even with autocomplete if I want to, and the chat, so I have some synchronous feedback there. So lots of good surf surfaces, and lots of different options that you can, pick in here. And I did see another question of Flash in here, which, I think it's a good one to pick up. Let's see. Cool. Yeah. I I think it it went away, but I'm gonna be reading a few other ones that, I see here on the screen. So, another question that I think speaks now to a broader, maybe ask, maybe an epic, right, which is, can Copilot CLI analyze an entire dot net solution and suggest improvements across multiple projects? The answer in my head would be yes, but it would very, very well depend on how you are structuring that. If I were to tell you, yes. Just, you know, put a prompt and ask it to do that and say make no mistakes, you know, that wouldn't work. We would need to essentially maybe do even some sort of spec driven development in there where we essentially create the spec for what we're trying to do. We create a very, very robust plan. Maybe we have a few different skills in there that are accustomed to our, repositories, and then we work with Copilot and maybe some sub agents to, perform those improvements. So possible, but definitely something that I myself would take a ton of time prepping. So this way, execution can be, very, very smooth. Cool. Good question. Another one here is any good plug in or skills to generate a good architecture flow diagram for a heavy code base just like skill two, generator. So there are a few of them. I want to maybe explain a little bit, about what I'm doing and share some other skills, and that would give you guys maybe some ideas. So in this example, we use the draw.io, skill, and that generated a diagram that I just, you know, drag and drop, into draw.io, and, you know, that diagram was sufficient for me. If you want to browse other skills, a really nice website is skills.sh by Vercel. There is a ton of different skills in there. It's kind of similar concept to the MCP registry by GitHub that I showed. I like that website because it tells me a ton of popular skills as well as some security information about them, if they're passing security, findings, and and tests. So I myself tend to go in there and type what I'm trying to do. So that draw IO skill, I found it there. It comes from the awesome Copilot, repo, but it's published in there. So I just typed in draw IO. It showed me one that, was really popular and it was safe. So I decided to give that one a go. That is one example. Another thing that I have been enjoying to do as well is use other skills that may not seem like they're meant for that purpose to try and, create some new use cases. So for example, a front end design skill. This front end design skill is made to create, you know, the front end of web apps, websites, you know, using, popular frameworks like React, some HTML behind the scenes, and I'm actually using that skill to create my diagrams now. So I like it to have it create those HTML diagrams. And the reason why I ask it to do that is because I think they look very nice. I think the creative and design freedom that it brings to the table is really, really, interesting. So instead of building a web page, I build a HTML page with my, diagram itself, and then I convert that into PNG, and then I'm able to attach it to a read me or maybe, you know, send it to a colleague. So, skills are very interesting because they they can surprise you. So, good question there. Cool. Let me scroll up and pick some other random questions here that we haven't, talked about. Cool. Yeah. And I think this one here, is really nice, because it touches on a topic we haven't talked about yet, which is when working with a completely new repo, how does the CLI handle AI mistakes or incorrect assumptions, especially since generative AI isn't 100% reliable? And this is true. Right? Because we're dealing here with nondeterministic, agents. So one thing that I like to do, like we saw in those examples, is to be very specific that I do not want you to simply come up with something. I want you to come up with that and then run the deterministic checks in my repo, so the npm run test, to make sure that you're not only saying that you're bringing coverage up, but you're actually running that test, confirming it, and showing it to me, maybe even printing an output that that coverage report, has gone up. So I think it's a mixture here of, you know, being able to steer it in your prompts as well as maybe have some deterministic checks in the repo itself through either CI or maybe some, follow-up questions that you may wanna have. Even the review, forward slash command that allows you to review things before they get pushed, is a nice, I would say habit to to start doing. So, it's just really, you know, comes to mixing, you know, counterbalancing maybe the nondeterminism with a bit of determinism to bring us, some guarantees. And, of course, having a human in the loop, reviewing everything, making sure that you understand what you're generating and not simply just accepting and pushing those things, is the most, important, step. And I see another question here that maybe other folks are going through, and I think it's important to call out as well, which is I somehow do not see HydraFusion as, an option under the models. I wonder if this HydraFusion is already released to the public model. Also, can we use HydraFusion, only in CLI mode? Good good question. So, HydraFusion is essentially an experimental feature. So first of all, as you will see there in that page that I, shared, you will need to first of all update and make sure that you are in the latest version, and then you need to turn on experimental mode, which is forward slash experimental, and that will, essentially, give you those research preview options. And then if you go into the model section, HydroFusion should be in there. So update it, ton experimental, and HydroFusion, should pop up. As of right now, it is, a CLI thing, but, I am also seeing, some of it being migrated to IDEs. So stay tuned for some updates there. Cool. Another question here about MCP server integrations. Can we connect an MCP server with Visual Studio? Also, what is the difference between Visual Studio and Visual Studio Code when it comes to MCP server integration and usage? Really great point. The answer is yes. You can't, you can, integrate with, those two IDEs, and it would behave very similarly to how we saw in the CLI. It would essentially give the model access to those external tools. In terms of, usage, it's very similar. In terms of integration, it would just depend on the IDE. So I know that Visual Studio has, a few different, settings and and many options, same with Visual Studio Code itself, as well as a few other, IDEs from the the JetBrings family. So usage should be very similar integration. We have it documented for you guys, so it is something that, you may find, in the documentation piece, of GitHub. Nice. So many good questions. Thank you so much for bringing those up. And I see here we have about three minutes left, so maybe we'll pick a few additional ones here. Thank you for my colleagues to, answer some of them while I was presenting. I am trying to, see some other ones here. Let's see. Alright. So, there is a really good one here in terms of the marketplace. So and can I use a private, let's say I think it's a follow-up, question? Yeah. That that that first one was answered. So the other one is and can I use a private company repo for the marketplace in the CLI? How about security? I don't want to add, public repos. That is completely fine, and that's a really valid point. Thomas, thank you for bringing that up. Essentially, the way I would do about this is I would create my own marketplace in my org, which is something that you can do. You can create a marketplace that will include all of your skills, MCP servers, agents, instructions, as well as a few other things, and keep it private to you and have your developers pull from that. So it would be pretty much your private registry that you can use internally. So definitely possible and something, we have documented. Cool. I think we have time for one final question. Let's pick this one here that just came in a few minutes ago. A lot of my users who ask questions come in from a business background. I was wondering if it could also help explain the solution, not as a technical solution flow, but also, as something which they can understand, for their value add. Excellent. Excellent question. And the answer is yes. And if I were you, if that is happening frequently, I would create a custom agent, which is essentially an agent responsible for breaking down technical terms into nontechnical terms. So this way, other folks, who are maybe not in engineering could understand. And in that agent, you can maybe specify specific things that you want to, it to say, to reference, the language that it wants to use, the audience that it's, you know, typically speaking to. So definitely possible out of the box, but if you want to customize it even further, and it is repeating something, you know, very frequently there, I would definitely use a custom agent. Great question. And we are coming up on time here, guys. I just wanted to thank you all so much for your time. There are a ton of nice questions, and, the documentation should include a ton of additional resources, for you guys to explore. I hope you have fun with GitHub Copilot, and I hope you have a very, very nice day.