Welcome to Always Azure broadcast. Today I have Giulio with me in the studio and we'll be talking about GitHub Copilot CLI. We just talked about before starting that, let's see what's going to happen because either of us will actually know what the end result will be. Indeed. And thank you for inviting me. Yeah, welcome to the studio. My pleasure being here and as you just heard, this is live. It's not very scripted. So you'll see what we see in real time and hopefully everything will be right. Something might be wrong and then we will work with it in real time. We'll manage. We'll hopefully manage, right? We're professionals, right? But the plan for today, it's very exciting if I say so myself. And it's just a day in a life of a developer using the GitHub Copilot CLI. We're just going to use the word Copilot from now on. Otherwise, the tongue will... There are no Copilots. It's GitHub Copilot CLI. This is the one, right? The one, yeah. And imagine the situation. It's Monday, last time I checked, meaning that the weekend has just finished and maybe you run a marathon. Maybe you had one too many glasses of wine. Maybe you have a very small child or maybe all of the three, you know? It can happen if you are a good one. Exactly. And you go back to work, sadly or happily, depending on how much you like it, and you have to go back and work. But how do you start? And if we look at how you would do it with the Copilot CLI, this is the screen. And I just launched the GitHub Copilot CLI. I'm on Windows today. If you are on Mac, it would look slightly different, but it's the same concept. Yes. And the first thing we do is use what's called a slash command. In this case, it's called chronicle, as you can see in the screen. And this is kind of a cute little thing that tells you what's happened on your machine and on your sessions all across the CLI. In this case, I do stand up because it's Monday. And it's going to do its thing and is going to try to remind itself and mostly me, however, what has happened or what I should be ready to do today. So all the things you lost over the weekend, right? Correct. So you're bringing that back up. Indeed. And this is like my actual real computer. So, you know, things are what they are. And you can see that those are what I should have done or what I should be prepared for today. And I will take, in fact, not this one because this is only using the last 24 hours. And I know that I have been gone for a very long time. I remember, however, that I was working on an application called Inc. And in this application, it's a low latency Inc. and no taking application. I was doing some work. So I remember that I go here. This was my repository. It's a repository on GitHub, as you can see. And I start my GitHub Copilot instance right now. Again, for the sake of the story, right? We don't need to be on GitHub. We could be everywhere. We could. Right? That is correct. So what I'm demoing today is enhanced by the fact that the code is, in fact, on GitHub because we use what's called a remote index. But if your code was on ADO, GitLab, or on-premise, then it would work the same with maybe a slight speed difference because then some of the indexing is done on your machine if it's not done in GitHub. If your code is in GitHub, as you can see, you have this very interesting option where you can start to see how Copilot CLI is really good for enterprise or team of size more than one because you can actually keep the session, so all the things you do, in sync and share it with your team. Yeah. So in this case, I'm going to do this. So I can actually start working on, if you were going on a paternity leave, right? Yes. I can take over your work and actually know what you've been working on, right? Exactly. That's pretty cool. And we're going to demo that at the very end of the live just so you get to see what happens when you leverage the full platform of GitHub. But now we are just locally saying, and as you can see, I've picked the model Claude Haiku because what I'm going to ask next is something very quick, and I just need to kind of remember a little bit more detail what I did. So I'm just going to ask... Oops. Apropos live demos. What happened in all the branches and all the commits so that I can pick up what needs to be picked up. And it's going to do its thing. And I'm just going to zoom in and zoom out so we can see more of the details. So as you can tell, the demo gods today are a little bit against us because, as you can tell, it says that it's not able to authenticate. So it's actually just using the local Git repository and not the remote. going back to the point that this can run in either mode. Most likely, it's an issue on my computer right now. Because it wants to use the MCP server for GitHub, right? Yeah. And it usually would follow based on what you have. So it picks the remote address and then it determines whether or not it should query GitHub or ADO, for example. But so what's telling me that we've been working quite a lot. Good job. And the current state is that I'm on this feature user story, which I'm supposed to be working on. And then there's two branches that have diverged. One that's about adding documentation and one it's about, well, the master branch that most likely has been remain to main, but we forgot to pull. I think documentation is good, but I find it really boring. But I'm a good, you know, developer citizen. So I need to get that done. So let me quickly do a switch to a more powerful model. In this case, I'm going to pick Opus 4.6 because what I'm going to want to do now is to ask the CLI to write the documentation for me. Yes. And I'm going to cheat a little bit. I'm going to copy paste a prompt because otherwise you're going to see me typing and we don't want that. Cheating is good. That's what we often do in this show. So what I do here is that I'm going to copy paste a prompt. And here again, you chose high. So you could choose different levels on your LLM, right? That is correct. You chose high for high reasoning because you wanted to write the documentation. Exactly. And in this case, I think in all transparency, your mileage may vary. You have to develop your own intuition based on the task at hand, the model at hand, and your experience. The bigger the repository, the more important to pick big models that might be a bit slower so that they can have everything in context and actually dig as much as they can. Yeah. But here we're also talking about there actually is a reason for choosing different models for different type of work, right? Because what I often see is just sticking with one model and just doing the same thing over and over and over, right? Indeed. But you could actually speed up stuff, maybe get a better result of choosing a different model. 100%. Right. And if we get there, you'll see that the CLI also shipped with an interesting feature called Review, which enables you to automatically have models kind of playing devil's advocate with each other because models of the same family have different, say, profiles. So maybe Hikoo is really fast. Opus is really smart. But then GPT 4.5, for example, that is a different thing. So they could have different opinions. Yes. And then you can have them kind of fight, quote unquote, right? And that's always a good strategy. But if we go back to the code, let's see. Oh, I didn't press enter. My bad. But basically what I'm trying to do is an okay good prompt. Not the best prompt there is, but in this kind of task, it's pretty okay to do that. And it's, you know, now trying to read all of the files, as you can see, and, yeah, suggest a documentation. So now you prompted for you want that documentation to be done, right? And I don't think we're going to go that much deep into this detail, but instructions and skills and all of that stuff. So if you want to have that in place and not beat up to the single developer making a proper prompt, right, we would need to put that into skills and instructions. Exactly. The repository structure, maybe I can show it later, where there is some predefined skills and instructions where you should put the stuff you use a lot. But if we go back to the code, I'm actually going to do something a bit wild. I'm just going to control C. So I stop this, and I'm going to do the same now. But life is short, right? Sometimes you don't want to wait. Ideally, you also know how to type. So I'm just going to scroll back all the way to the beginning of the prompt and use a new slash command, it's called. It's called delegate, which it is specific to GitHub only. Delegate. But that means that I'm just going to send this to go on a computer that's not mine. Namely, it's going to use GitHub Actions. And it's going to do the same thing that you would do on a machine. And just... Okay. Actually, the demo keeps on not being nice. So we're not going to do that. But let's just... But the idea here is to having this running... Exactly. ...on some cloud machine up in GitHub. Indeed. So you can continue your... Exactly. ...work. This is the goat, in a way. Very often you have the concept of, like, you know, agentic work, in the sense that you don't want to babysit the agent. You want them to go, right? Yeah. And this is one option that unfortunately didn't work. But I'm going to show you how it would have looked in a moment. So now we go back then to, let's say, more work on our machine. We just leave the command line. And... Oh, we are actually in the right branch, as we saw here. And we remember that there was a user story that we added in our commits. Which maybe I'll just show you like this. That was added quite a long time ago. And we want to kind of pick up from there and see what happens. This is a simulation. Obviously, you might have a user story in Jira. It might be in Azure DevOps. And you would then have your enterprise, you know, give you an NCP tool where you could then connect to it. Yeah. In our case, I think the demo gods are not very kind to us today. So we're just going to read it from the file system. All right. We're going to keep Opus because this is a... Not an easy task, right? To understand a user story. So the first thing we do is we switch to plan mode. If it does that. Plan. Well, it's a bit slow, but there you go. And then we say to, you know, look at the user story. In this case, I'm going to reference the local file. There you go. And I'm basically asking, is it a good enough user story? As a developer, am I ready to get going? And what I want to show you here is that it's actually going to pick up our custom skill that has been loaded. As you can see, it realized that it's, you know, that's what I asked, right? And in this skill, what I've encoded is how we do agile development in our company. And then is, yeah, just going to look at it and tell me what I should be planning next. As this goes, you can see how with an MCP server that is connected to that, this could be very powerful because it could, for example, use other resources. Yes. For example, your calendar, your teams. And usually the way you would do it is by having a, you know, a MCP. And now I'm just going to show you the one I have. Actually, I don't think you can while it's working. So we're going to have to wait. But I think we can just show it in a different tab. So a list of MCP servers. In this case, I have, you know, the famous Microsoft WorkIQ, which enables me to connect to my calendar and my teams. Power BI, because, well, we use a lot of Power BI. And this one, which is an internal tool that we use in our work. and then you can imagine how powerful this gets. If you pick a user story, check that you didn't forget something in a meeting note and then use that to make an actual implementation plan. And this leads me back to saying that we actually had Massimo from Microsoft in the studio talking about MCP servers as well and how you can develop your own MCP servers to bring your own data and your own stuff into the LLMs, right? Indeed. And that's what we really want is to give as much, let's say, secret context, right, to the LLMs that comes from internally, from our organization and our teams. And again, if there isn't an MCP server, we can also just create a skill of working with an API directly. Exactly. So there are other ways to getting about this as well. Indeed. Okay, cool. So now the… Did a plan. The plan is planned. The user story was bad, as it tells us. And guess what? I wrote it. I'm not the best PM in the world in this scenario. But it was missing a lot of information and you should really actually ask the PM. That's what it's recommending me, which is a very good thing. You should always make sure that your skills and your MCPs actually can be critical and not just tell you that you're super good and you're ready to go. You want to make sure that you do ask your PM what to do. In this case, yeah, we're not going to continue because the recommendation is to actually ask the PM. So to do that, we're going to cheat again a little bit. As I told you before, we want to… All right. So we're going to now look at the actual repository. So you can see how this skill was written. And this skill is something you can use across all the platforms. So it works in Visual Studio. It works in the GitHub CLI. It works everywhere. And it sits inside the .gitup folder. And in my case, I… Oh, no. Sorry. This, I actually decided to make it enterprise-wide. So this is saved in my own home folder. And that you can tell by actually asking Copilot to show you all the skills. So in this case, I'm going to list it and it's going to tell me. As you can see, I really have many. Yeah. And my recommendation is to play a lot with skills. They can really change your Copilot experience. And they do not pollute the context, right? So it's not like a custom instruction. They are loaded on demand when it's needed. And you can, of course, use a prompt to suggest the agent to pick the skill. Exactly. The more sabble you are, the less likely that it's going to be picked up unless you have one. Yeah. And we have… And as any other developer company, right? We would have some teams that are very mature in using Copilot and CLI and have built skills. And we have some that don't have. So we have a thing as to how do we share these skills, right? How do we make these skills enterprise? Yes. Broad, right? Because maybe I've created the best skill in the world. And I'm the only one using it. I don't want everybody to use my skills. Yes. So that's a hard question. And I'm glad you asked. Because as of today, there is no really enterprise-ready way to share skills. No. Stay tuned. That's all I can say today. But the best practice as of today is depending on how you structure your organization. You've been teasing me with some news, right? So I'm trying to pull it out, but I can't. But good job. Something is coming. Okay. Yes. But today, what we recommend is mostly based on team topologies. Yeah. It is very rare that you have one person per repo. And in that case, well, it doesn't matter, right? You shouldn't share anything. But usually, if you're collaborating in a repository, that's where we would recommend to anchor your skills. Yes. If you are in GitHub Enterprise, what you can do today is do enterprise-level agents. And you can also use the so-called plugin marketplace of the GitHub CLI. Yeah. Okay. That enables you to get there, but it's still not governed as you would really want in an enterprise. Okay. And now, if we go back. So what we want to do now is just, I just wanted to show you my skills, right? So you can see what they are. In this case, it's right here. Oh, no. Sorry. The user story checker. It is very simple and yet very effective in using a local markdown file to check whether or not a user story was really good. Cool. And now, it's time to implement the good user story. So I'm actually going to pick, you know, I'm now looking at my emails where my PAM has finally given me a good user story. It should have been in GitHub, but it wasn't. So now, let me just copy paste that. And do you see it? There we go. User story. As you can tell, this was a really bad one. So now, the PAM updates the user story. And we just try to do it. There you go. There we go. Effective PM. Yes. The old one we don't care about. And now, you see that this is a proper user story with acceptance criteria and whatnot. Looking good. Fantastic. We save it and move on now. So how do we then go from this user story to something that makes sense? Well, let's focus on the other, the pane on the left now. So we are still in plan mode. That's the plan, the mode you want to use. Yes. There are many plans, as you can see. The standard one, so to speak. Plan and autopilot. Autopilot is the one where you take a plan and you let the agents go wild. Do your thing. But always, that's my recommendation, starts with plan. When you have a user story, it helps you take what a human has said to you and translate it into an actionable implementation plan. We talked about this prior to the show here, right? That I often use the plan mode as well. And then because it's very hard when, if I don't use, I'd never just use the autopilot, the YOLO mode, right? And the third mode is where it just asks you questions on each step. And then I lose total control and oversight of what is actually going on, right? So the plan mode gives me that. Exactly. And then I can reprompting, ah, you fix this and that. Try and, this is the context. Okay, and it tries again. Exactly. And it actually builds a plan in a markdown file on your machine that it'll look into, right? And the importance is also not necessarily just technological, right? But it's also how we used to do software before the agents in a way, right? We also have a lot of context that we have in our heads, right? Yes. And the machine doesn't really know it. So when we try to say, hey, do this for me, they don't know what this is, right? No, exactly. So it's important to make sure that it's critical about what you actually ask for. Yeah, yeah. If you've given enough context. Yeah. So if we go back to the screen, then we can see that I'm in the lower left corner. You see this plan mode. And then I'm just going to actually say, help me plan work for my user story. Improved by the PM. And you should know that it's very hard to type when it's demoing by the PM. And then I once again add context from the file. So that was user story. There you go. If this was a prompt without a backing markdown file, I would recommend to make a much better prompt than please help me. But in this case, you've seen how good the user story was. So what we really want is just to trigger. We use this as well, right? So if you create a very good descriptive feature in user story, we can actually just prompt start the work on and then throwing it the idea of the user story. And that is what we would recommend, right? Yeah, right. Because then you also have a nice kind of backing of this is the institutional plan and this is what we agreed and disagreed about. So the way of working hasn't really changed actually, right? Not really. That's something that we often, I think, see people struggling and we struggle ourselves. This is a revolution in many ways. But some of the practices, especially the good practices, haven't really changed. You will own the code. The feature has to be specified. There is no secret sauce where you just prompt something and you get the best thing ever out of it. And this is now going to make the plan. And as it does, I think it's depending on your preference, right? Some people like to be very active on and steering. Some people want, say, the plan to be done and then to review it. I like to be very hands-on when I'm interested. So I now press Ctrl Y or I think Command Y depending on the machine. And it's just showing me this preliminary plan. and I can read it, agree with it, disagree with it, change it, and then continue. You can also just, you know, let it go and it's going to do its thing. And then at the very end, it's going to save the plan. And then you can, you know, conversationally talk. Instead of going in and changing the Markdown file yourself, trying having that conversation to change the plan. Often, it's really good to, when you are planning an implementation, to keep an eye just because it might be that it's going in places where you don't want to go. Plan mode also uses skill, right? Also uses agents. So that's not something that you should forget. For example, if you want to have, say, a specific way of implementing an architecture or TypeScript, for example, in this case, this repository is written in TypeScript, that's where you should put your custom instructions, right? Yes. So if we go back to the screen, you'll see that in the repository, in my github.com folders, or not, sorry, github.com, dot github folders, I actually add a TypeScript instruction file. this is loaded always as long as the path matches this regex. And in this case, it's going to trigger for everything. And this is also used in plan mode, which is very important because, for example, I know that I want to use this very functional style of writing code. And if I don't have that, the plan can never possibly know, right? No, no, exactly. Of course, if you're in github.com, so if your repository is hosted and you have turned it on, github builds memories now across your repository and your organization. Meaning that if you tell it, oh, this is how we do architecture, then it's going to remember it next time. But if you don't have that, you have to be local, and then that's how it goes. And I think we are almost out of time, so we're not going to... We've still got the full five minutes, though, right? But let me just show you how things look on github.com. Because I think it's interesting to see where we're going, because what we've shown you today is really about personal productivity, right? This is me with my code, my machine, my model, so to speak. And if I want to do something that's more shared, then I have to go to github.com. I'm going to here show you. This is our Microsoft internal demo account, so you're not seeing anything secret. This is made for this. And in this enterprise, we have all the possible features enabled, right? And what you can see here in AI controls, I think it's really interesting, because we can see all the agent session that everyone in our organization has been working on, right? And this is where the delegate command that I showed before that didn't work, right, would have been here. And, I mean, this is just not a view, like a read-only view, right? This is an actual agent chat where you see exactly what they've done, you can look at the pull request, you can interact with it. So this gives you an incredible visibility. That is pretty cool, right? If I think that you said that, I find it really cool in terms of, you know, working with other people, and sometimes if you're also working with yourself. in the same way I mentioned before, right, this notion of custom agents, here you can see that in our organization, which is one only in this enterprise, we have two of them that helps us making sure that whatever we do, it doesn't break compliance. Even if it's a demo environment, always good to be safe about that, right? And then we have another documentation specialist that was actually used when I showed you how to write the documentation. And last but definitely not least, audit logs. It's, you know, agents are becoming part of our, let's say, daily workflow. And we need to be able to see what has happened, what they've done, what they looked. And that's where you see it once you are connected to github.com. The other thing I wanted to show you is very important in this time, so to speak, to be able to pick where your data is sitting and also where your data is processed. Yes. And as late as, what, five days ago, I think, removing the weekends maybe, we have launched GitHub Copilot, fully hosted in Europe and in the US, if that's what you're interested in. But I guess in this time zone, it's more interesting to think about that. Exactly. That gives you full inference, all the models, everything that you want together with your data resident GitHub in Europe. And that could be a game changing for adoption in your organization, but that you have to check for yourself. I think it's really cool to have all of these models that are finally available. So we're seeing more and more the enterprise ready setup in GitHub for these agents, right? So we have a lot of features that are going to build more built into GitHub. and we have some already now that gives you that control, compliance and governance over the agents, right? Indeed. But do not forget that the GitHub Copilot CLI is a local tool. Yes. So you can use it no matter what cloud, no matter what tool. It also is synced with other tools. So for example, if you are what's called Rider or VS Code or even Xcode, right? They are connected. So you can have the best of both based on your preference. So you can really adopt GitHub Copilot CLI in any context, right? Absolutely. And we use it internally in a lot of different contexts. Yes, 100%. But you just, if you then use other GitHub services, if you have your repository in GitHub, your organization enterprise there, you'll get some advantage of trust. That's what we're looking into here as well when it comes to, because a lot of the discussions I have with customers are compliance, compliance, and then compliance again. And what about compliance? when running these agents, right? This is a big topic. And I think that that's also why I allowed myself to veer a little bit away from just the CLI, because it is really important to remember that if it's hosted, you can have a much deeper view on compliance. And again, when we start adopting these tools a lot more, and I'm taking like the enterprise cap on, right? And we have a lot of discussion internally, but it can only do what you can do in your context, because it's running locally in your machine, right? So that's some safety. But do you actually know what you can do? Exactly. So that's the next question you should ask yourself. And then looking into, okay, we need some guardrails around. Our development work, our way of working, we need to look into that so we can really adopt agents and fast forward, right? And if you want to hear more, then you have to convince the host to invite me again. And then in a month or so, I can show you all the cool new things that we're working on. We'll need to do a special broadcast on that, right? Yes, I'm happy to. And we're out of time. And thanks for the demo and presentation, Julio. Anytime. And if you're interested in GitHub Copilot, reach out. You know where to find us. Yes. Take care. Bye. Bye-bye.