GitHub Copilot advanced features | GH-300 | Episode 5

Hey there, once more, welcome to our video series on GitHub Copilot.

In this fifth and final module, we set the stage to introduce GitHub Copilot's advanced capabilities with a specific focus on how Copilot evolves beyond simple code suggestions. What that means is, rather than viewing Copilot solely as a tool for faster code writing, this module explores how it can support more complex development and DevOps workflows.

My name is Peter Detender. I'm a Lead Technical Trainer here at Microsoft. I'm a huge fan of GitHub Copilot, as you hopefully experienced in the previous modules already. If you missed them, feel free to review them. Or maybe you are already familiar with many GitHub Copilot capabilities, and you just want to see what we mean by advanced features. Either way, I'm glad you're here.

The key message out of this module is perspective. As we progress, you'll start to see Copilot as a more active collaborator. It's becoming an engine that can reason across repositories, across pipelines, and processes, not just looking into files anymore. This framing is necessary because it prepares you to think in terms of outcomes and workflows, no longer prompts and snippets.

This slide clarifies what you'll walk away with by the end of the module. You'll learn how GitHub Copilot Agent Mode works, how to extend it with additional knowledge sources, and how features like AgentMD, pull request reviews, and pipeline troubleshooting all fit into real-world DevOps workflows. Equally important, this slide explains why these topics matter. By combining Agent Mode with organizational context and automation, Copilot helps teams like yours move faster while staying aligned with standards. The main benefit here isn't just productivity. We're now talking about scalable, consistent engineering practices from development as well as operations.

Let's kick it off with the first capability here, Agent Mode. Agent Mode is really that shift from prompt-based assistance to now goal-driven execution. Instead of responding to isolated questions, Copilot can now plan tasks, execute steps, evaluating results, and iterate. Pretty much like a human engineer working through a problem.

The real value comes from how Agent Mode uses that context. By understanding repository state, looking at issues, pull requests, and workflows, Copilot produces more consistent and policy-aware outcomes. Overall, the benefit is clear. Less manual effort, but higher velocity, and way better alignment with how teams are already working today.

You might go, "Okay, cool, but what does that actually mean?" Like when and where is Agent Mode most useful? Out of my own experience, and I use Agent Mode for almost everything now since it became available in preview, it really shines in scenarios that cross boundaries. Looking at multiple files, looking at multiple repositories, checking pipelines, or even configurations, where simple code completion would fall short. Agent Mode is especially effective for debugging as well as CI-CD operations. It can trace failures across workflows, analyzing logs, and looking into YAML files, and then from there, proposing fixes while iteratively validating them. The real benefit is faster resolution of complex issues, as well as reduced cognitive load for engineers like you working in large interconnected systems.

With that, let's again shift the focus from theory to practice. In my next demo here, I'll show you how to switch from Ask Mode into Agent Mode and trigger more autonomous behavior. What's important about this demo is not just the mechanics, but it's the mindset shift. You'll see how prompting changes from asking questions into now assigning goals, and how Copilot takes ownership of the actual execution.

For this demo, I'm actually even more excited than any of all my previous demo. Yes, I know I've done a lot of them, but why am I so excited? I talked about Agent Mode, how powerful it is, how cool it is, how close we are to almost fully autonomous. What that means is I'm going to loop through similar little demo scenario that I used in, I think, module three when we did some DevOps tasks, but now showing you how amazing Agent Mode is.

In short, what it does in my demo environment, remember we used the Ask Mode all the time here and now I'm switching to Agent Mode. Agent Mode again is that little trigger like I trust you, my dear Copilot, to now not only provide me code suggestions, but also actually writing code, running code, and executing steps to really change, manipulate, take actions. That's the main thing.

I'm going to reuse the exact same prompt that I used before. If you were here for demo three when we talked about Developer and DevOps use cases, I'm pretty sure you recognize the prompt because what I'm asking now in Agent Mode is confirming the app is working fine and we need to move this into our DevOps cycle. Step number one, run the container. Step number two, push the container into Azure. Step number three, create the pipeline.

In module three, using the exact same prompt, it provides me all the code snippets, but I still had to go through all those steps creating the files, copying code, where now Agent Mode is going to perform all those steps for me. Again, the power is not in the prompting. You already know out of previous modules that obviously being more specific in the prompts is definitely going to help you, but most important part here is that based on the prompt, it starts analyzing and then from there, it's going to move it into a set of to-do tasks. It's recognizing like this is what you ask me and I'm going to create my own to-do list.

As you can see, it already starts creating the different files. I'll make it a little bit bigger. It created four to-dos, reading my existing code, reading the package file, and then from there interacting and it's already running the Docker creation. There's a couple of different steps where now you can follow along. You could try and read through the chat conversation, but then you could also follow along here. We're currently at step one out of the four identified to-do tasks. From here, it's basically just waiting and see what's going to happen.

While it's still processing and running, we can follow along a little bit. So it flagged like I created the Dockerfile and Dockerignore. So what that means is obviously here in the code view, I can now look into the Dockerfile. And again, if you remember the scenario from module three, it came up with about the same code file. It has the Dockerignore, but now I didn't need to create those files anymore. So it's again, shifting a bit away from that more like reactive scenario where it's suggesting code, but you still need to decide. But now it's sort of like giving you more comfort, maybe trusting, Copilot even more than you already did before and giving it the permission to actually create all those files for us.

I'm using this in my DevOps example, but obviously I can do the same for just code rewriting. Like the example I used before transforming code from Python to .NET. Again, creating all those files manual, the program CS file, the W root folder, moving all the files in there, it's now performing all those steps for us. In meantime, I was just talking through it and we still have something running in the terminal. And it's also creating the GitHub actions pipelines, which now means that we also have this GitHub folder. We have the workflow folder and it's nicely coming up with all the different possible pipelines where one pipeline is connected to Azure, creating copilot, preparing first introduction like doing the Docker work, all in preparation. So it's a lot more than I think a lot of us are doing, typically combining everything in a single pipeline and it's now using the multi-stage approach.

You can see that it's somehow flagged a little problem in my code file. And that's just me confirming that I'm okay with all those changes. Now I'm sort of intrigued what the problems still could be in my CI CD pipeline, GitHub actions code file. So let's have a look where here it's pointing at the production where apparently this value is not valid. And you might remember from previous demos, we can use that Copilot quick fix out of the inline chat. It's gonna look into this scenario and hopefully pretty confident coming up with a solution for the problem. And now everything looks fine. Only thing I have to do now is go to my source control, committing the changes, because I think we did everything here, but now nicely, almost fully automated, right?

One last little Copilot integration is when we want to commit our code updates into our branch that we created earlier, one of the annoying things I would say, but super important is the commit message. There's this little icon up here and that's actually another integration with GitHub Copilot where it provides a commit message. So what it means is again, a little step in the automation process, the optimization process, where now I don't need to think back anymore about what were all the changes that happened in my branch and then coming up with a useful enough commit message. It's gonna help me in creating that message. So I'm gonna commit all my changes and then eventually publishing the branch. And I think that just wraps up everything we can do with this project at least using our agent integration. Wasn't that mind blowing? I'm personally still amazed by what it can do and how my use of Copilot has dramatically changed thanks to Agent Mode.

But we're not done yet. Remember that Generative AI's knowledge is derived from large language models. In a previous module, we highlighted the importance of adding more specific context, using prompting techniques or assigning files, assigning folders or bringing in other information. But there might be an even better way. And that's what Model Context Protocol or MCP is now bringing to agents. MCP is the mechanism that allows tools and data to be safely exposed to AI models. MCP standardizes how applications provide structured context to large language models.

The main benefit of MCP is interoperability and control. By using that standard protocol, organizations can connect Copilot to trusted systems. For example, documentation, using APIs without hard coding logic. This enables a richer reasoning while keeping integration manageable and secure. The MCP protocol was initially developed by Black Forest Company, better known out of the Entropic models, but now available as an open source project. So all AI platforms can now benefit from, as well as integrate with one another. I found a LinkedIn post a few months ago that also described MCP as the USB-C of Generative AI.

Now briefly, let me break down MCP into practical roles. We have clients and servers. MCP servers expose tools, resources, and prompts. While on the other side, MCP clients dynamically discover and use them. This separation matters because it clearly defines who controls what. Tools are really important to MCP. Who controls what? Tools are really model controlled, resources are application controlled, and the prompts are user controlled. The benefit is flexibility. Copilot can act autonomously while organizations still decide which data and actions are permitted.

Specifically on this slide, we explain how tools become available to Copilot through dynamic discovery. Instead of hard coding integrations, Copilot can discover tools exposed by MCP servers using decorators. The key advantage is scalability. New systems like GitHub, Azure documentation, or even third-party platforms outside of Microsoft can be added without rewriting logic. This makes Agent Mode adaptable as tools and ecosystems are evolving. And yes, you guessed it right. Peter has yet another demo up his sleeve to showcase how MCP actually works. You'll see how adding Azure or Microsoft Learn documentation as MCP servers dramatically enhances Copilot's reasoning. And the benefit is immediate. Copilot can answer questions and make decisions using authoritative up-to-date knowledge rather than generic training data from the large language model. This makes Agent Mode far more helpful in enterprise scenarios.

But first of all, I hope that you're a little bit mind-blown about the power of Agent Mode, again, meaning that everything is pretty becoming pretty autonomous and just running all the tasks for us. But it's not the only thing, right? I talk about MCP and to me it's like really bringing in that real-time knowledge into your already trained large language model. Because remember from the introduction, a large language model is always running behind a little bit. Typically 12 to 18 months, it's using public internet data. And maybe we don't always want to rely on that too much. Or out of the fact that it's like sometimes more than a year old, it means like in one of my other demos I emphasized, although I prompted for give me the latest .NET framework, it was using .NET 9, which at least at this moment in time is no longer the latest version. That's the reason why we bring in MCP servers.

So how do you do that? Out of the VS Code environment, but it's about the same in Visual Studio and other development environments, you can pull up a list of MCP servers. So how to do that? I'm gonna use the command palette and there is a list of actions you can take to bring in MCP servers like adding a server, I'll show you that, browsing existing servers, and then maybe even resetting connections and anything like that. So it's a little plugin you could say that's running pretty autonomous. So I can start with browsing MCP servers where it's gonna allow you to look into the MCP server marketplace. This might take a while because like a lot of software companies, software vendors are exposing their data APIs using the MCP protocol. Another option is using a repo that I personally like quite a lot. And that's going to github.com/model-context-protocol, and there's a list of servers. Now in here, we can scroll down, there's a pretty long list, but for example, I'm gonna bring in the Microsoft Learn docs. There's GitHub, there's Jira, there's again so many, I think there's like two, 300 different vendors listed in meantime. So let's look at the Microsoft Learn docs where it's gonna provide a description what is the purpose of MCP server. In meantime, you already know that. And then obviously most relevant is how can I configure this? How can I bring this in? In the presentation, I talked about MCP server, MCP client. So MCP server in this case is the Microsoft Learn backend. The MCP client is my VS Code. So what you need is copying this little snippet of code. You move back to VS Code and you're gonna move it into your MCP JSON, which is now part of your user profile. So that means whenever you're switching to a different environment, you can migrate all your MCP servers and basically take them with you.

When I go back to my view and I look into more MCPs, I can list all the servers that I currently have in my environment. And as you can see, as long as you're not using them or not calling them out, they're not running. So it's not even consuming any compute power. Knowing that I'm a technical trainer, typically doing quite a lot with Azure, using Bicep for templates, using Copilot and using the Learn Docs, I'm gonna show you another little example. How now Agent Mode, that's also important. You only have agents, MCP when using agents. You can call it out using tools. From the presentation that one slide with server, client and tools, the tool is really bringing in that intelligence. What is the intelligence? It are the different steps, the actions that your MCP server provides you with. Like the Learn Docs as an easy example, it allows you to consume the learn information, but I cannot rewrite them. I cannot make any updates to them.

If you select the tools option next to the Agent Mode, it's gonna show you the built-in tools and already used some of these, but not out of agents. I did a demo earlier on integrating source control as the context providing the GitHub Copilot instructions was another one, but now we also have our tools listed up here. And you can always decide, do you want a full library of tools? Do you want a subset? What that means is if I open up the Azure MCP, it's gonna show me information about all possible Azure Live services. Every now and then, you might go like, "Well, I'm never using Cosmos database." "I'm not using monitoring because we might have" "another monitoring tool within the organization." "So why would I bring in that information" "to maybe confuse Copilot even more?" And that's where you can decide which of those libraries you want to use, or maybe you don't want to use anymore. So that's one part to allow them or use them or not even using them.

Another example is just running prompts like you've been doing before. We're now out of the keywords in the prompt. It's gonna trigger a connection to the MCP servers. So what that means is if I go back to my code view and I'm gonna run a prompt for this project, can you help me creating the necessary Azure Bicep template to deploy the app into Azure? So I'm using Azure multiple times. In this prompt, I'm calling out Azure Bicep, and since all my MCP tools are enabled, I don't need to specify explicitly which ones I wanna use. What it's gonna do here in the references is like always analyzing what needs to happen. And then at some point, and I noticed that it's not always emphasizing too much, but luckily it's doing it here. It's now asking me like, "Hey, I recognize you're calling out the Azure. I recognize an Azure MCP server in your list of tools, like the toolbox," you could say, "Do you want me to use that? Yes or no?" I don't see a reason why you would not use this because again, it's gonna bring in real-time information, making sure that your templates are recognizing the up-to-date API, sometimes even preview APIs. But I can imagine that there might be a good reason, like because of compliance, because of standardization, that if you've been using certain versions of like Azure Bicep APIs, that maybe you don't wanna bring in the latest and greatest versions, and that's where you might decide to not allow it. I also have the Azure best practices, as again part of the Azure MCP, and that's where it's again asking confirmation, like, "Do you want me to also bring in that additional knowledge?" And again, the real power here is that it's no longer just relying on the large language model. It still uses the large language model to analyze your prompt, to understand, recognize natural language, but now to create code, to update code, to bring in the template, in this example at least, it's now relying on the real-time information coming in from the Learn Docs, coming in from Azure MCP, from GitHub, from Jira, from AWS, obviously depending on your scenario.

Next to that, since it's still Agent Mode, it already started rewriting all my code files, at least for my templates. So it's looking in the packaging, it's creating a deployment markdown, and it highlights all the different template files. It creates an Azure folder inside the deployment folder, so little bash script on how to run all this. It created an infra folder, where I have my, let me close this view here, it created my Azure bicep, and then also the parameter file. Basically everything that I need, where obviously this assumes that, you know a little bit more about Azure, where it's gonna use pretty up-to-date APIs. So that's pretty much what I wanted to show you, as the power of MCP servers. So with that, let's switch back to the presentation.

Now we discussed Agent Mode, and GitHub recently announced Copilot Coding Agent on top of that. Where the editor-based Copilot helps within files, the Coding Agent operates at the repository level, through issues and pull requests. The benefit in this case is autonomy at scale. The Coding Agent can create project structures, coordinate multiple files, and deliver end-to-end solutions. Once more, moving from reactive suggestions, now into proactive problem solving.

This diagram here, based on the companion exercise in the Coding Agent Learn module on the Learn platform, illustrates how the Coding Agent fits into a real workflow. Starting from issue creation through pull requests, and then performing review, Copilot participates as a contributor, rather than that passive assistant. The key takeaway is now collaboration. Copilot integrates naturally into your existing processes, helping your team move faster without changing how they work. This makes adoption smoother and the impact even more immediate.

This slide here is really aiming to reinforce the core concepts of that Coding Agent. Describing the purpose, what are the benefits, what are the characteristics, by bringing them together. By revisiting these points, I hope this helps you leave with a clear mental model. Agent Mode and now Coding Agent enable autonomous, context aware, iterative execution, delivering consistent, scalable outcomes across development, as well as DevOps tasks.

And you know what? It doesn't even stop here. What if you could provide instructions to an agent or even establish an orchestrated multi-agent scenario without even using prompting? You think it's too good to be true? Well, not anymore, thanks to the AgentMD concept. AgentMD provides persistent guidance to Copilot. Instead of relying on repeated prompts, teams like yours can encode rules, standards, and expectations directly in the repository, using nothing more than a set of markdown files. The benefit here is predictability. AgentMD turns your Copilot into a policy aware collaborator, allowing your team to scale automation in a safe way, while maintaining consistency across contributors and time.

This brings me to my final set of demos in this module, showing issue handling and application development using the Coding Agent. I'll also show you how the Coding Agent is integrated into creating a new repo and how it enables code generation straight from the start. What matters here is realism. By seeing Copilot work through real tasks, I want you to understand exactly how Agent Mode fits into everyday engineering workflows, not just for demos, not just for prototyping.

So that let me switch to my last demo, and it's all about Coding Agent, where I like to show you two different possible tasks for now. One is how to use it out of your GitHub repos issues, but then using it to actually perform issue handling, like becoming again that virtual assistant, helping you in really fixing problems. And then second one is, I think even more mind blowing, showing you how easy it becomes to create a new repo, provide instructions like storytelling almost. This is the kind of app I want you to build, and it's just going to perform all those steps for us.

So I'm using the public repo, the reference repo, that I used for most of my demos throughout all the videos here, and that's that skills getting started with GitHub. So that's the school web application that we use, and as you can see, I do have a few issues. Now, the first one I would say was one for me to try out, like just going prepping my demos. The second one I'm going to use a little bit to show you once the process kicks off, because it takes a little bit of time, like about 10, 15 minutes for even not the greatest or the longest complex task, but it's so detailed, it's so thorough, going through all those steps, where I'm going to kick off the next issue handling, and then once it's running, I'm going to switch back to my previous example, because again, I want to show you live as much as possible, but I also don't want you to sit and wait for like 10, 15 minutes to just see it in action. Next to that, since it's a public repo, if you do have a GitHub account, feel free to go to the repo, I'll keep it live, and you can just look in the issue and literally going through each and every step in your own time.

So I'm going to use the top issue here where, remember we had that school web application, students can sign in and selecting activities to sign up for, but now I want to extend my web application and adding a new theme, and next to that, I also want to allow my school staff to actually sign in and use their user profile to maybe keep track of some activities as well, or identifying anything else that they're doing within our schooling environment. So I'm providing a description of my issue, just like you could expect from any other issue. I want you to change the color theme, because it recently changed out of like some marketing update to dark red. We need to apply the changes and just go for it, right? Next to that, at the same time, and maybe you could debate like, "Hey Peter, you should better create a second issue for this." Well, too bad it happened, right? Pretty sure it's the same on your end, where you start creating an issue and then once you start explaining it, you detect a few more changes. So that's literally what I tried to replicate here. Well, now I want to allow employees to log in, checking their profile, and then identifying the employee category, what kind of professor is it, are they staff, are they administrative workers, anything like that, and then also keeping their first and last name. And as a good developer, I also want to make sure that all these changes are happening in a dedicated branch.

So where is our Coding Agent coming in? So we're going to assign this task where maybe in the past or still current, right, we have an issue and we assign it to someone. Like you get ownership, responsibility to look into the issue, fix the problem, submitting code, that's going to trigger a pull request, and from there someone else is going to review code and then merging into the main branch. I'm going to assign it to Copilot. This is where the coding assistant or coding agent kicks in and it starts looping through. All this behind the scenes is triggered using actions, and every now and then I just need to refresh and see what's going on. So it created a work in progress that's now linked to my issue. The number five here might be a little bit confusing because it's not the same as my issue number three. So the number five here reflects to how many tasks did you already hand over to the coding agent. From here you can select the task and it's going to loop through the details. So it's going to help me identifying like what are all the steps, what are the prompts that I used so we can always go back. And then it's also providing the fix, where now this fix is linked to my original issue. So we can always go back and forth, go back and forth, and see what's happening.

Now from here, as you can see it's starting to loop through different tasks. Copilot started the work. And this is where it's now, again, first of all, relying on its own GitHub MCP server. That's where it brings in the real-time up-to-date information, like what are all the steps that me being GitHub Copilot can actually perform out of this prompt. And then next it also relies on our Microsoft Playwright framework. And that's our automated integration into browser handling, where it's going to create screen captures. So we're asking it to create code, rewrite code, and then at some point it's actually going to validate, trying to run the app, showing the webpage, and confirming that the changes are actually successful.

Now from here, my demo would be a little bit boring if I keep talking or maybe be coming silent for like 10, 15 minutes. So what I'm going to do is switching back to a previous issue and showing you a bit more in detail how powerful it actually handles it. And again, remember the repo is public, so if you have that account, feel free to go through it a little bit more in your own time. So what I did here is about the same scenario. Didn't want to make it more complex, but I asked to switch my original Marine Blue into Magenta, applying the changes, and then what I did in the live session kicking off the employee profile, I asked for the same using the student profile. So from here it kicked off the task, and I'll make it a little bit bigger. So it starts recognizing parts of the prompt, so I injected one longer description in the issue, and now it's analyzing like what are all the potential tasks I detect out of that prompt. It started migrating the color theme from the blue into Magenta, and then doing the same for the lighter version, started creating the student profile components, specifically with the name, email, and category, as I asked for little snippets because I allowed it to come up with mockup data, and then that's the integration with the Microsoft Playwright, integrating screenshots. So as you can see, it's the exact same website that I've used for all previous demos, but now all blue color got nicely changed into Magenta. Out of that Coding Agent, it recognizes the web app, it's using Playwright, it's going to validate like this, all looks good, and then we also have our profile icon, as I asked for, and then when you move over, you hover into that icon, it's going to show you your profile details. So I think this is just amazingly cool, and then next it also provides the full explanation. These are the files that I updated, the same files that we used throughout most of the demos. It still shows us the original prompt, so we still have that reference, and then going back to the pull request and allowing us to bring in those changes. This is a process that ran for about 10, 15 minutes, and again, it's looping through all the different stages and then real time, if you want, you can go back and view each and every step.

Next to that, each and every action it takes is now also linked to individual commit messages. So it's not just becoming a code writer, it's not just becoming an automation agent, but it's still respecting the traditional way of creating software, following best practices, create a branch, although I explicitly asked for it right, but then each and every step is now becoming an individual commit. And then obviously all the way at the end, we're still committing to our DevOps process where it's asking for a review. So if you have an existing repo, you have your pull request policies, your branch rule sets, as we call them now in GitHub, none of that is changing. So we're just bringing in the power of the Coding Agent, and it's just becoming that peer developer, as we called it from the start of the sessions. I hope this is convincing enough, this is more than powerful enough to show you how it works, but I got one last example where I'm going to try and create a little game just to close off the whole series. I like playing games, although I don't have a lot of time anymore, but it brings me back to the early 80s. Yes, I'm dating myself here. And what if we could start from a fresh new repo and providing instructions, and then from there again, relying on the same task.

I go into my GitHub profile, and I'm going to create a new repo. I'm going to call this the GH300 game. A live demo for GH300. I'll make it public, so after watching the video, you can actually go back and then maybe cloning it, forking it, contributing to it. I'm going to use Git ignore for Python. Let's do Python, why not? I'm going to add open source MIT license, and this is where the Coding Agent comes in. I need to describe what I want Copilot to build. So I got a little description on the side, so I'm going to grab it. And it's not working. Why not? Because I was already too detailed. I need to limit myself to 500 characters. So I'm sharing some details. As a kid, I played arcade games. Well, that's cool, but in the end, it's not going to influence the coding agent experience. So I'm going to remove some of those characters. I want to build, well, that's being nice, but let's say we provide instructions so we can remove a few characters, build a Python app which tests me on my shooting reflexes. That's like explaining the purpose of the game. Help me develop, we don't need to ask, because that's the real purpose. And let's do the game does the following. I need to find three more characters. Step one, ask the player for input. Step two, at the bottom in the middle of the game screen shows the shooter. Anywhere random, it needs to show up a target. Using the spacebar, because I don't want to use like a, I don't know, fancy Xbox or like, or any other game controller. Using the good ultimate 80s keyboard, some arrows and spacebar to shoot, and then it needs to test my reflexes. And I'm going to fix this, and I guess I got a space somewhere. There we go. What I'm doing here is obviously emphasizing how amazing it is to build a game with just a description that's 500 characters long.

So I'm going to kick it off, and as you can see here, it's pulling up the same Coding Agent view with all the different tasks that I've been using linked to my GitHub account. It's becoming a work in progress. And I think for this one, since we're close to the end of the videos, I guess it's totally fine to just keep it running for probably five to ten minutes. If you don't want to see all the detailed steps in action, then I would say just fast forward the video and then seeing me playing the game.

After roughly 10 minutes, as I predicted, because I've been running this test obviously multiple times, it gave me this exciting cool message that the game is ready to use. Obviously I want to walk you through the steps to actually show you the game in action, but before I'm going to do that, assuming that not all of you are watching the video running for about 10 minutes, right? Let me quickly repeat what actually happened here. So we started from that super high level prompt. Remember it's only 500 characters providing instructions like this is what the gameplay should be about. It started creating the Python coding file, adding the necessary package file using the requirements, already creating the readme file. And I think it's just following the good GitHub repo best practices, installing Pygame. So it's looking into what would be the best way to not only create the code, but also allowing you to actually play the game and not just like a console terminal based version, but like a full blown Windows application in my case. It's going to look into the Python syntax and for each and every of those, as you can imagine, it also shows you the actual output of the code level. Once the code got created looking into Git, because remember we asked to keep source control into account as well, more progress editing some files, because that's where it started validating code and detecting like, oh, I discovered a few issues. It needed to rewrite code and it's just doing all those steps automatically. All the way at the end, more reviewing, more update of code, checking syntax. And then the other thing, which I think is also pretty mind blowing, it started integrating CodeQL like the GitHub advanced security code scanning to make sure that any packages that we're using do not have any vulnerabilities. And then all the way down after making all these changes, committing the history to then again end up with a nice summary description of all the implemented features, which files got created and providing the security overview.

So from here, I had to do one last step and that's reviewing the pull request. I did the reviewing, I merged my code and everything is now ready. Now ultimately, obviously we do not only want to use this to create code, but we actually want to see it in action, which means I'm going to grab code, I'm going to clone it to my local machine. I'm going to run a git clone and obviously I could use GitHub Copilot here to help me with that. We're going to call this the gh 300 game. I'm going to open it in VS Code, although I could probably run it straight from the terminal. All the files are here just like any other repo. If you want again, it's a public repo, so feel free to look into the actual code, clone it, fork it, and then have some fun with it while playing the game. Just going to accept a few Python debugging options, so it allows me to actually run the game. Debugging started and look at that. It looks and feels like a full blown again Windows application and I didn't specify a lot of the graphical requirements, but it's a full blown app and it brings me back to the good old days where Peter was a lot younger. It's going to ask me my name and we can start playing the game. And I'm too slow. I was not fast enough. So now I need to play it multiple times to make sure that I'm becoming faster. Still too slow, spacebar, and I won the game. There's no other way for me to show you how amazing this technology is because remember I provided a pretty high level description about 500 characters running a process for about 10 minutes where it's respecting all the requirements technically functionally, but also respecting the GitHub way of developing software, creating a branch, moving it into a pull request where someone from my development team needs to review it, go through the merge operation, cloning the repo and then testing it out.

For this last scenario, I would like to introduce you to the AgentMD concept that we just talked about in the presentation earlier, but to make it even a bit more challenging, I'm not just talking about one single agent, but I'm going to use some sort of a workflow, actually one that I already use out of my own experience as a trainer where if you remember a bit from the introductions, what I do is providing a lot of Azure training and I guess it's pretty clear by now, I like doing demos. So what that means before Copilot and even before Agent Mode, I needed to create my Azure demos, which typically means I need to come up with an Azure demo scenario. I need to create the Azure templates to actually deploy the scenario, preferably integrating some sort of a web application, a database, maybe a virtual machine, depending on the demo scenario. And then also a few demo steps because I'm probably repeating the same demo for multiple classes. How do you move all this into that AgentMD concept? Well, you basically think about what is the process that I've been using for so long in a manual approach and you just write it down. And that's a bit what I have here. Now, to not make it too complex, too text file oriented, let me quickly draw out a little diagram so you got some idea what's happening. So my process starts with what I call the ideation. So that's where I want Copilot to help me. I provide a prompt that's going to be the input and I want that prompt to be transformed into an actual demo scenario. What's the business case? What's the relevance? And what do we need to actually make that work? Making it work, we want to make sure that it's following Azure best practices and validating like, okay, it's a cool design. It's a cool idea, but can it actually run in Azure? So that's where I'm going to bring in a second agent that I'm going to call the Azure architect. Once we have the business idea and the Azure architect is validating it, we're going to hand it over to our DevOps team where the DevOps team is now responsible for creating the application if we need one, the VM, the database, again, depending on the scenario, and then also creating the Azure building blocks like bicep templates in my case. And then last, we have the trainer where I'm providing instructions to look at the Azure architecture, look at the diagram, look at the template files, and provide me step-by-step instructions that I could use to demo that sample application.

So how does this relate to my setup? I have four different files in two different sections. One section is the agents and the other section is the prompts. I'm going to remove the diagram. I hope it makes sense. Four different steps for agents with the clarification, what is the purpose of the agent, and then providing some sample prompts for each and every agent step. I start from a blank repo. There's nothing in here apart from the .github folder. Inside you create an agents folder and a prompt folder. Inside you provide that markdown-based descriptive approach. And I have to be honest, this is not even super detailed. But I provide the YAML headline here, and that's just recognizing that it's some sort of an agent instruction file, right, where I'm defining the description where, hey, you're the Azure demo ideation agent, you share and describe an Azure demo scenario. From there, and this can be as long as detailed, as high level, but not always that functional, I would say here try to be as detailed, as specific as possible. So just giving you a quick idea, like how does this actually work? So as the ideation agent, I want you as a role to be inspirational, descriptive, capture cloud solution scenarios using Azure as the platform. A couple of instructions propose detailed scenarios that could be mapped with an Azure demo. For each scenario, provide me a description, an intended audience, and which Azure services that could be involved. Next to that, be creative to just make demos a bit more entertaining, and then also make sure that it follows Azure cloud capabilities. From there, we're going to hand it over to the cloud architect, and it's basically the same setup. We define the name, the description, the purpose, the intent. This is what you can do. In my case, I'm defining here, I want you to use the Azure Well-Architected Framework. I want you to look into potential risks and maybe security and anything else that you could come up with. From there, I hand it over to the DevOps agent, where now the purpose is, I want you to create modular bicep templates, and I want you to follow any of the other instructions that I have. And then last, for the trainer, validate the demo scenario. From here, this gets translated to a few prompts where you can be more specific. And again, this is pretty high level just for the sake of the demo, because there's no need in going through all the scenarios, because most probably, you're not going to build an Azure demo builder. You provide some instructions, so more specific.

Now what you can see here as well is that each and every of those steps already come with a trigger. What is the trigger? Well, if I move to my agent, where before I used "add workspace", I could now also use the forward slash, and it's going to pull up a list of tools that we talked about in that MCP topic earlier, where now I'm actually creating my sort of local MCP server, providing instructions where you can see here, it's still recognizing my Azure level. It's still recognizing the built-in GitHub Copilot tools. And now it also shows me my demo instructions, my generate-azd, my scenario, and my validation. Getting back to the architect, the ideation, the DevOps agent, and the trainer doing the actual demo. Last to see this in action, we trigger our scenario, and we need to describe what Azure demo do we want. I'm going to keep this pretty high level, because otherwise it might start running again for another 10 minutes, and that's not the goal of the demo. So create me a demo. I don't need to ask, because it knows that it needs to create a demo showing Azure Network subnet peering, preferably across two regions. Again, this can be a lot more detailed. You can see that it already pulls in MCP out of my Azure toolbox, and it starts analyzing. So now it comes back with a useful Azure demo scenario. It's going to map it with a business case, like why does a business need multiple Azure regions? Why does the business need multiple peering connections? Next to that, thanks to the Azure MCP integration, it knows that we do provide Azure training. You can get certified. So now you can actually turn your agent not only into "develop me something," but also using it to maybe come up with your own testing cases in preparation for practical experience, in preparation for your exam. Based on the high level prompt, it also identifies the architecture, like we're going to use Azure VNets, we're going to do peering, we need Bastion, which all integrates like Azure security to protect connectivity to the virtual machines. It comes back with a high level Azure architecture, and it comes back with a demo flow, like this going to take 15 minutes to set up, 10 minutes give or take to actually do the demo, some success criteria, and then all the way at the end, after the ideation is done, it's now asking like, well, I can see that you do have multiple agents. And most logically, we had the architect validating it already. And now the next step is, well, do you like the scenario? Are you okay with the business case? And can you approve it that it's fine for me to hand it over to the DevOps agent and actually creating everything that we need? Or do you want to skip that step and then maybe going through the demo deploy guide first? You can create a full automated process, semi-automated, fully autonomous, by using nothing more than descriptions and then triggering the flow of an individual agent, creating a cascade of different agents. And that's in short, the power of AgentMD. So with that, let's go back to the presentation.

In this module, you learn to use more advanced GitHub Copilot features, primarily Agent Mode. You learned how to integrate additional knowledge into the agent using the MCP protocol and concept. Next to that, I share details on several other GitHub Copilot DevOps use cases, primarily pull request reviewing and actions pipeline troubleshooting.

Thank you so much for participating in this GitHub Copilot video series, which remember aligns with the GH300 material we have on Microsoft Learn platform. I hope you enjoyed learning about all aspects of GitHub Copilot as much as I enjoyed presenting the concepts, but then also walking you through numerous live demos. While it's all video based, trust me, none of the demos were edited or even faked to make them more mind blowing. Everything you saw is working and it's 100% reality today.

Now that said, keep in mind that Generative AI and therefore GitHub Copilot continuously evolve. I encourage you to stay curious and continue exploring new capabilities with the platform. That's also how teams continue unlocking value. Now remember, there are many ways to continue your learning journey. I encourage you to watch other videos in this course if you missed any of the previous ones, or search for your next favorite topic on Microsoft Learn using aka.ms/learn.

The second thing to remember, once you have gained sufficient practical experience, why not considering enrolling in that GitHub Copilot certification? It might not give you an immediate pay raise or a promotion, but at least your code will be solid and you might even have more time on your hands because you managed to create your own little bundle of agents doing most of the work for you now. But then also don't forget, these are just tools that don't function without humans. Till next time friends, take care for now.