I’m using the GitHub Copilot CLI on a day to day basis but I have been away for a few weeks and a lot has changed, in order to keep up to date with all of the changes I created a very simple web app that tracks the latest realses to the GitHub Copilot CLI.

You can find the repository on GitHub https://github.com/gsuttie/GitHubCoPilotReleaseNotes

I am using the GitHub Copilot CLI to build useful apps for my day-to-day use, and it helps me keep track of the most recent changes.

If you’ve ever had to jump between multiple Azure subscriptions in the portal just to check on the health of your applications, you’ll know how frustrating it can be. The Azure portal is powerful, but it isn’t always the fastest way to get a quick read on what’s happening across your Application Insights instances. That’s the problem I set out to solve with AppInsights Analyser.

What Is It?

AppInsights Analyser is a .NET 10 Blazor Server application that connects directly to your Azure Application Insights resources and presents all the key telemetry data in a clean, fast dashboard — without you ever having to leave the app. You pick your subscription, select an Application Insights instance, and immediately get access to ten different analytics views:

• Requests
• Dependencies
• Exceptions
• Page Views
• Page Speed,
• Availability
• Traces
• Top Failures
• Performance
• Overview summary.

Everything is driven by KQL (Kusto Query Language) queries running against the Azure Monitor Logs API, so the data is always live and accurate.

How I Built It

The tech stack is deliberately straightforward. I used .NET 10 Blazor Server for the application framework — Blazor Server made sense here because all the Azure SDK calls happen server-side anyway, and there’s no need to expose credentials to the browser. For the UI I reached for MudBlazor, which gave me a polished Material Design component library including drawers, tables, chips, and dialogs with minimal effort.

For charts I used Blazor-ApexCharts, which made it easy to render grouped bar charts for the Page Speed comparison feature — showing today’s page load times versus yesterday’s side by side, with percentage change calculated automatically.

Authentication was one of the more interesting design decisions. Rather than storing connection strings or API keys anywhere, the app uses
ChainedTokenCredential from the Azure.Identity SDK. It tries your active az login session first, then falls back to DefaultAzureCredential for environments like Managed Identity or Visual Studio. This means you can run it locally with a quick az login –tenant and it just works.

The Azure resource discovery uses the Azure Resource Manager SDK to enumerate subscriptions and Application Insights instances dynamically — so there’s nothing to configure. If you have access to it in Azure, it shows up in the app.

Features

A few things came together particularly well. The drilldown panels let you click a failed request count and instantly see the individual failed
requests inline — no navigation away from the page. The same pattern works for exception details, top failure occurrences, and performance
percentile breakdowns (P50 through P99).

The left-hand sidebar navigation keeps all ten sections just one click away, with the active section highlighted and the main content area updating without a full page reload.

All tables are fully sortable — click any column header and the data reorders instantly client-side.

Try It Yourself

The project is open source and available on GitHub. All you need is the .NET 10 SDK, the Azure CLI, and read access to an Azure subscription.
Clone the repo, run az login –tenant , then dotnet run — and you’re in.

https://github.com/gsuttie/AppInsightsAnalyser

When you’re part of an agile team, sometimes it feels like you’re orchestrating a heist. You’ve got a tight deadline, a complex
target, and a crew of specialists, each with their own quirks and talents. That’s exactly how it felt when I set out to
build a live .NET 10 Blazor Server sprint review dashboard for the team I work in at Intercept. But this time, my crew wasn’t just
my colleague; it was a team of AI agents assembled using GitHub Copilot’s Squad system, and each one had a name straight
out of Ocean’s Eleven.

Let me set the scene: Squad is a GitHub project that lets you assemble a named team of AI agents, each with a
persistent identity. For this job, I picked Ocean’s Eleven as my universe. The coordinator, Squad itself, was my Rusty
Ryan, keeping everyone in sync. My main developer agent? Livingston is named after Livingston Dell, the tech wizard who hacks
into the casino’s systems. The parallel was intentional and, honestly, delightful. Just like Danny Ocean briefs his crew for
a big job, I was Danny, briefing Livingston and the rest of the Squad for our sprint review dashboard caper.

Features I added include

• Main Dashboard as shown above
• Issues – show you a list of issues, sortable, filterbale and searchable for the previous, current and next sprint.
• Team Workload looks at how much work each team member has and shows you the % of open and closed tasks.
• Risks – this will highlight potential risks with the current workload / issue status’
• Members – shows you a view of each team memberm theire issues in previous, current and next sprint.
• Sprint Health – highlights serial carryover in issues, carried-over issues with no updates, and anything added mid-sprint.

The target: Project #134 for Team 503. The plan? Pull real data from the GitHub Projects API across three sprints, previous
(2026-4), current (2026-5), and next (2026-6). We needed an Issues page with a sortable, searchable table, complete with
GitHub issue links that open in a new tab. The Risks page would serve as our risk register, with linked issue-number badges.
The Team Workload page would show who’s carrying what, and the Members page would break down stats for each of our team
members, and the Sprint Health page would flag serial carry-overs (red), no-update carry-overs (yellow), and mid-sprint
additions (teal) so we could spot problems before they snowballed.

Here’s where the magic happened. Instead of slogging through days of solo development, I described the “job” to Livingston.
Features that would normally take hours, sometimes days, were done in minutes. Livingston even caught a subtle Blazor
gotcha with @rendermode InteractiveServer, making sure all filtering and searching was truly interactive. The Squad
coordinator orchestrated the operation, keeping everything on track.

But the real joy was in the pair programming experience. Instead of talking to a generic “AI assistant,” I was briefing my
crew. Livingston wasn’t just a bot, he was the tech guy, always ready to hack the next piece of the dashboard into
existence. The agent names made the whole process feel collaborative and fun, like we were all in on the heist together.

Looking back, this is how dev teams should work. Assemble your crew, brief them on the job, and let each specialist shine.
With Copilot Squad, the line between human and AI collaboration blurs in the best way. If you want to pull off your own
perfect sprint review heist, don’t just hire an assistant. Build a crew.

If you are interested this is how I went about it – I used https://bradygaster.github.io/squad and I cannot tell you just how impressive this is to use.

This application was built from scratch in a little over 30 minutes.

This article is my entry into this year’s Azure Spring Clean 2026 event. Huge thanks to the organisers!

A customer asked me how to interpret Azure Application Insights and whether it would be possible to build a web app to help them understand what Application Insights was reporting about app performance.

The prompt I used was as follows:-

To run this, I went into GitHub Copilot CLI and then used/plan and then type the prompt

I need a website to look at my production application insights and help me figure out the good and the bad within it – the resource is called appinsights-customername-prod, in the resource group called rg-app-insights-prod within the subscription <redacted> – do this using the latest version of C #.

That’s it, the full prompt, start small, build onto itas you go. As you may guess, this is quite a vague prompt, but enough to get started with.

The plan it comes back looked like so:-

Plan: Application Insights Health Dashboard (Blazor Server, .NET 9)

A Blazor Server web application that queries the production Application Insights resource using the Azure Monitor Query SDK and DefaultAzureCredential, presenting a real-time dashboard split into “green” (healthy signals) and “red” (problems) sections with a user-selectable time range.

Project Layout

All files created inside a new c:\personal\code\phillip\AppInsightsDashboard\ folder:

Steps

1. Create the project — dotnet new blazorserver targeting net9.0 at c:\personal\code\gregor\AppInsightsDashboard
2. Add NuGet packages to the .csproj:
   • Azure.Monitor.Query — logs (KQL) and metrics queries
   • Azure.Identity — DefaultAzureCredential for auth (uses az login locally)
3. Configure appsettings.json — store only the non-secret App Insights resource ID:
   • Resource ID: /subscriptions/<redacted>/resourceGroups/rg-app-insights-prod /providers/microsoft.insights/components/appinsights-customername-prod
   • No connection strings or secrets in config
4. Program.cs — register LogsQueryClient and MetricsQueryClient as singletons using DefaultAzureCredential, register AppInsightsQueryService as scoped
5. AppInsightsQueryService.cs — wraps LogsQueryClient.QueryResourceAsync(resourceId, kql, timeRange) and exposes typed async methods for each dashboard section:
   • GetSummaryAsync(TimeRange) → total requests, success %, avg duration, exception count
   • GetSlowestEndpointsAsync(TimeRange) → p50/p95/p99 by operation name
   • GetExceptionSummaryAsync(TimeRange) → exception type, count, last seen
   • GetDependencyHealthAsync(TimeRange) → name, success rate, avg duration
   • GetFailedRequestsAsync(TimeRange) → recent failed requests with details
   • GetRecentExceptionsAsync(TimeRange) → raw exception feed
6. KQL queries used (all target the App Insights classic tables via QueryResourceAsync):
   • requests | where timestamp > ago(Xh) | summarize ...
   • exceptions | where timestamp > ago(Xh) | summarize count() by type | order by count_ desc
   • dependencies | where timestamp > ago(Xh) | summarize ...
   • Performance percentiles via percentiles(duration, 50, 95, 99)
7. Dashboard.razor — the main page with:
   • Time range selector (dropdown: 1h / 6h / 24h / 7d) that triggers re-query
   • Summary cards row: total requests, success rate (colour-coded), avg duration, exception count
   • “The Good” section: top performing endpoints, successful dependency calls
   • “The Bad” section: failed requests, top exceptions, slow dependencies
   • Loading spinner while queries run; error boundary for query failures
8. Performance.razor — sortable table of all endpoints with p50/p95/p99 duration, request volume, failure rate
9. Exceptions.razor — exception type breakdown bar chart (using inline SVG or a lightweight JS chart interop) + scrollable raw exception feed with stack trace expansion
10. Dependencies.razor — dependency type (SQL, HTTP, etc.) success/failure rates and avg duration, colour-coded rows (red if success rate < 95%)
11. MainLayout.razor — simple nav sidebar linking to the four pages, shows the App Insights resource name in the header

Authentication note

Locally, DefaultAzureCredential picks up az login credentials automatically. The signed-in account needs at least Reader on rg-enogrp-point-prd-workload and Log Analytics Reader on the linked workspace (or Monitoring Reader at the resource group level).

Verification

• dotnet run → opens http://localhost:5000, dashboard loads with real data
• Time range dropdown changes refresh all cards without page reload
• Red/amber/green thresholds visible: success rate < 99% = amber, < 95% = red; avg duration > 500ms = amber
• Navigate to each sub-page and confirm tables populate

Decisions

• QueryResourceAsync used over QueryWorkspaceAsync — no need to look up the linked workspace ID separately; App Insights resource ID is sufficient for all requests/exceptions/dependencies/traces tables
• Blazor Server chosen over WASM — avoids CORS concerns with Azure SDK calls from browser, keeps credentials server-side
• DefaultAzureCredential — zero-config for local az login use, Managed Identity ready if later deployed to Azure

Confirm this plan and I can hand it off to an implementation agent, or let me know if you’d like any adjustments (e.g. add a specific custom event table, change colour thresholds, add charts library, etc.).

I then confirm the plan and this was the end result.

So, from a single prompt, I have a new Blazor website with an overview page, a performance page, an exceptions page, and a dependencies page. Now I can go back, style it, change it, add to it, do whatever I want.

I have no dependencies on other tools, I don’t need to version it, and tell people there is an update available, there is nothing to download and install – I am using AI to do the job for me.

Pro tip: Once you’re happy with changes, ask AI to code review, ask it how I can make it even better, more secure, etc., and then and only then create a PR and check it in after it’s been reviewed.

This is just how easy it is to create a web app that you can use, run locally, and build all sorts of useful tools.

Here are further blog posts on this topic. If you want to see examples of how to look after your Azure Environment, check out the article – https://gregorsuttie.com/2026/02/19/how-i-used-github-copilot-cli-to-build-an-azure-governance-web-app-from-zero-to-maturity-score-in-one-weekend/

I’m a golfer who wanted a better way to track my rounds. So I did what a growing number of people are doing in 2026: I sat down with an AI assistant and built the thing myself.

The result is GolfScorer, a full-featured Blazor Server application that lets me record rounds hole by hole, manage courses, and dig into my performance stats. It has user authentication, a SQL database, Azure cloud deployment, and a dark luxury UI theme inspired by Augusta National.

Why I Built It

There are golf tracking apps out there. Plenty of them. But they all come with compromises, monthly subscriptions, clunky interfaces, features I don’t need, or missing the specific stats I care about. I wanted something tailored to me: a clean dashboard that shows my putting percentages, green-in-regulation trends, a handicap index, and a hole difficulty ranking so I can see exactly where my game falls apart.

More than anything, I wanted to understand how the thing worked. Not just use someone else’s black box, but own every piece of it.

The Process

I started by describing what I wanted in plain English. A golf app. Hole-by-hole scoring. Courses with 18 holes of par data. Statistics that actually tell me something useful. From there, the AI and I went back and forth, shaping the data model, building out the UI, debugging migrations, and refining features.

The stack we landed on is .NET 10 with Blazor Server, Entity Framework Core, ASP.NET Core Identity for authentication, and SQL Server for persistence. If you’d asked me a year ago to pick a tech stack, I would have stared at you blankly. But through the process of building this, I started to understand why each piece exists and what it does.

Some of the features I’m proudest of came from iterating with the AI. The statistics dashboard, for example, breaks down my scoring into eagles, birdies, pars, bogeys, and worse. It shows per-hole analysis so I can see that I consistently blow up on hole 14 but quietly birdie hole 7 more often than I’d expect. That kind of insight is exactly why I wanted to build this.

The UI went through a major redesign too. We ended up with what I call the “Augusta Dark” theme, deep forest greens, gold accents, elegant serif headings using Playfair Display, and a monospaced font for scores so everything lines up cleanly. It looks and feels like a premium product, which still surprises me every time I open it. The theme came from the aigent skill called frontend-design.

What I Learned

Building with AI isn’t pressing a button and getting a finished app. It’s a collaboration. I had to make decisions constantly; how should the data model work? Should rounds store denormalized totals for performance, or calculate everything on the fly? Do I want fairway tracking on par 3s? (No there’s no fairway to hit.) These are domain decisions that the AI can’t make for you. You bring the knowledge of what matters, and the AI brings the ability to turn that into working code.

I also got AI to write the entire deployment to Azure, I plan the feature and it implemented the Bicep code, PowerShell deployment script and even how to update the app after each release.

The biggest lesson? You don’t need to be a developer to build software anymore, but you do need to be willing to think like one. You need patience, curiosity, and the willingness to read an error message and try to understand it before asking for help.

What’s Next

I’m using GolfScorer for every round now. I have plans to add trend charts, a round comparison feature, and maybe a mobile-friendly layout for entering scores on the course. The codebase has unit tests for the core services, so I can keep building with confidence that I’m not breaking things.

If you’ve been sitting on an idea for a tool that would make your life better, something specific to your hobby, your job, your weird niche interest, I’d encourage you to try building it with AI. You might be surprised by what you’re capable of.

Now if you’ll excuse me, I need to go work on that hole 14 problem.

If your interested in checking out a tiny little side hobby – here you go https://golfscoreapp-app.azurewebsites.net

And yes full source code is available- https://github.com/gsuttie/golfscoreapp

If you told me a year ago that I’d build a fully functioning Azure cost management and governance web application in a single weekend, without leaving my terminal I’d have laughed. But that’s exactly what happened when I sat down with GitHub Copilot CLI and a clear goal: build a web app that gives me a single-pane-of-glass view into Azure Budgets, Cost Management, Tagging, Policies, Advisor Recommendations, Orphaned Resources, Security, Service Retirements, Logging Costs, Right Sizing, and a Maturity Score Report.

Here’s how it went, what I learned, and why I believe Copilot CLI is a game-changer for anyone building cloud tooling.

What Is GitHub Copilot CLI?

For those who haven’t tried it yet, GitHub Copilot CLI is the new agentic coding assistant that lives entirely in your terminal. It replaced the older gh copilot extension (deprecated October 2025) and brings the full power of the Copilot coding agent to your command line. You install it, authenticate with your GitHub account, type copilot, and start building.

What makes it different from other AI coding tools? A few things stood out to me during this project. It defaults to Claude Sonnet 4.5 but lets you swap models mid-session with the /model command. It supports Plan Mode (Shift+Tab), which lets you collaborate on an implementation plan before any code gets written. It has deep GitHub integration issues, PRs, repos all accessible through natural language. And critically for this project, it supports MCP (Model Context Protocol) servers, which meant I could extend it with the Azure MCP Server and have Copilot understand my Azure environment natively.

The Problem: Azure Governance Is Scattered

Anyone managing Azure subscriptions at scale knows the pain. Budgets live in Cost Management. Tagging compliance is a separate report. Advisor recommendations are in their own blade. Orphaned resources require custom queries. Security findings are in Defender for Cloud. Service retirement notices come via email. And tying all of this together into a “how mature is our Azure governance?” score? That’s a spreadsheet exercise most teams dread.

I wanted a single web application that pulls all of this together and gives me an actionable maturity score.

Setting Up Copilot CLI for the Project

Getting started was straightforward. I installed Copilot CLI via winget, authenticated, and navigated to my empty project directory.

terminal

winget install GitHub.Copilot

The first thing Copilot asked was whether I trusted the files in this directory. Since it was empty, I selected “Yes, and remember this folder for future sessions.” From there, I was in an interactive session.

Connecting the Azure MCP Server

This was the key enabler for the entire project. The Azure MCP Server gives Copilot the ability to interact with Azure services, Azure Resource Graph, and perform tasks on your behalf. I configured the Azure MCP Server following Microsoft’s documentation and the azd coding-agent config flow. Once connected, Copilot could query my Azure subscriptions, understand my resource landscape, and generate code that used the correct Azure SDK patterns for my environment.

Using Plan Mode

Before writing a single line of code, I switched to Plan Mode with Shift+Tab and described what I wanted:

“I want to build a web application using React for the frontend and Node.js for the backend that connects to Azure and provides dashboards for: Budget tracking and alerts, Cost analysis and trends, Tag compliance auditing, Azure Policy compliance, Advisor recommendations, Orphaned resource detection, Security posture from Defender, Service retirement tracking, Log Analytics cost monitoring, Right-sizing recommendations, and an overall Maturity Score. Use the Azure SDK for JavaScript and Azure Resource Graph queries where appropriate.”

Copilot asked clarifying questions: Did I want multi-subscription support? (Yes.) Should the maturity score be configurable with weighted categories? (Yes.) Did I want role-based access? (Not yet, keep it simple.) After a few rounds, it produced a structured implementation plan that I reviewed and approved.

Building the App: Module by Module

1. Azure Budgets

I prompted Copilot to scaffold the budget tracking module first. It generated API routes that use the @azure/arm-consumption SDK to pull budget data, current spend versus budget thresholds, and forecast projections. The frontend component rendered a clean dashboard with progress bars showing spend-to-budget ratios and colour-coded alerts for budgets approaching their thresholds.

What impressed me was how Copilot handled the Azure authentication flow. It set up DefaultAzureCredential from @azure/identity and structured the code so the same credential chain worked locally (via Azure CLI auth) and in production (via managed identity).

2. Cost Management

For cost analysis, Copilot generated Azure Resource Graph queries to pull cost data by resource group, service, and tag. It created time-series charts showing daily and monthly cost trends, and added a comparison view that overlays the current month against the previous month. I steered it to include anomaly highlighting any day where spend exceeded the 30-day rolling average by more than 20% gets flagged.

3. Tagging Compliance

This module was where Copilot’s plan mode really shone. I described our tagging policy (required tags: Environment, CostCenter, Owner, Project) and Copilot generated Azure Resource Graph queries that audit every resource across subscriptions, calculate compliance percentages, and produce drill-down views by resource group and resource type. It even generated a remediation helper that outputs Azure CLI commands to apply missing tags.

4. Azure Policy Compliance

Copilot scaffolded an integration with the @azure/arm-policy SDK that pulls policy assignment compliance states. The dashboard shows compliant versus non-compliant resource counts per policy initiative, with the ability to drill into specific non-compliant resources. It used the policy compliance API correctly on the first pass, which saved me significant time versus reading the SDK documentation myself.

5. Advisor Recommendations

The Advisor module pulls recommendations across all five categories (Cost, Security, Reliability, Operational Excellence, Performance) using the @azure/arm-advisor SDK. Copilot organized these into a prioritized list with estimated savings for cost recommendations and severity ratings for the rest. It also generated a “quick wins” view that filters for high-impact, low-effort recommendations.

6. Orphaned Resources

This was one of the trickiest modules. Orphaned resources unattached disks, unused public IPs, empty network security groups, NICs not attached to VMs don’t have a single API. Copilot generated a suite of Azure Resource Graph queries to detect each type, estimated the monthly cost of each orphaned resource, and created a cleanup view with one-click remediation scripts (outputting the az commands, not executing them directly for safety).

7. Security Posture

For security, Copilot integrated with the Microsoft Defender for Cloud APIs to pull the Secure Score, security recommendations, and alerts. The dashboard shows the overall secure score as a gauge, breaks down recommendations by severity, and highlights resources with active security alerts. It used the @azure/arm-security SDK and handled the different API versions gracefully.

8. Service Retirements

Service retirements were interesting because there isn’t a single clean API for them. Copilot generated code that pulls service health advisories from the Azure Service Health API and filters for retirement-type events. It then cross-references your deployed resources against the affected services to produce a personalized retirement risk report showing which of your resources are impacted by upcoming retirements.

9. Logging Costs

Log Analytics can become a significant cost driver if not managed carefully. Copilot built a module that queries the Log Analytics workspace usage API, breaks down ingestion by data type (table), shows daily ingestion trends, and flags tables with unusually high or growing ingestion rates. It also added a “noisy tables” detector that identifies tables contributing disproportionately to costs.

10. Right-Sizing

Right-sizing recommendations came from two sources: Azure Advisor (which Copilot already integrated) and custom analysis using Azure Monitor metrics. Copilot generated code that pulls CPU and memory utilization metrics for VMs over the past 30 days, identifies consistently underutilized resources (average utilization below 20%), and recommends appropriate SKU downgrades with estimated savings.

11. The Maturity Score

This was the capstone. I described the maturity scoring model I wanted: each of the ten areas above gets a score from 0 to 100 based on configurable thresholds, each area has a configurable weight, and the overall maturity score is a weighted average.

Copilot generated the scoring engine with sensible defaults: Budget coverage over 80% of subscriptions scores high. Tag compliance above 90% scores high. Less than 5% non-compliant policy resources scores high. And so on for each category. The frontend renders a radar chart showing scores across all dimensions, plus an overall maturity grade (A through F) with specific recommendations for improving each area.

Features That Made the Difference

MCP Server Integration

The Azure MCP Server was transformative. Instead of me describing Azure APIs in my prompts, Copilot could query my actual Azure environment and generate code tailored to my subscription structure, resource types, and existing configurations. This dramatically reduced the back-and-forth that would have been required otherwise.

Plan Mode

Building a ten-module application in a single weekend would have been chaotic without Plan Mode. Being able to describe the full scope, get a structured plan, and then execute module by module kept the project organized. I used /clear between major modules to reset context and keep responses sharp a tip from the official best practices documentation.

Model Switching

For the straightforward CRUD operations and API integrations, I stuck with Claude Sonnet 4.5 (the default). For the more complex maturity scoring logic and the multi-subscription aggregation patterns, I switched to Opus 4.5 with /model. The ability to choose the right model for the complexity of the task was genuinely useful.

Autopilot Mode

For the repetitive scaffolding tasks setting up API routes, creating React components for each dashboard module I used Autopilot mode (Shift+Tab to cycle to it), which lets the agent keep working until a task is complete. This meant I could describe what I wanted and let Copilot build out entire feature modules while I reviewed the output.

Custom Instructions

I created a .github/copilot-instructions.md file in my repo with project conventions: use TypeScript everywhere, follow a specific project structure, always use DefaultAzureCredential, use Recharts for data visualization, and follow our Azure Resource Graph query patterns. Copilot respected these throughout the entire build, which meant consistent code across all modules.

Lessons Learned

Start with Plan Mode for complex projects. The temptation is to just start prompting, but for anything with more than a couple of modules, the plan-first approach saves enormous time.

Use /clear between unrelated tasks. Context pollution is real. When I moved from the Security module to the Logging module, clearing the context gave me noticeably better results.

The Azure MCP Server is essential for Azure projects. Without it, you’re manually describing your Azure environment in every prompt. With it, Copilot understands your subscriptions, resource groups, and deployed services.

Review everything. Copilot generated excellent Azure Resource Graph queries, but I caught a few edge cases like queries that didn’t handle the pagination token for large result sets. The human review step is non-negotiable.

Iterate with specificity. When Copilot’s first pass wasn’t quite right, specific feedback worked much better than vague feedback. “The cost trend chart should use a stacked area chart instead of a line chart, grouped by service category” worked much better than “make the chart better.”

The Result

In one weekend, I had a working web application with eleven interconnected modules, a configurable maturity scoring engine, multi-subscription support, and dashboards that would have taken weeks to build manually. The codebase was consistent, well-structured, and followed the conventions I specified.

Is it production-ready? Yes, it has validation, authentication and proper error handling. It’s exactly what I needed, built in a fraction of the time.

GitHub Copilot CLI didn’t just help me write code faster. It helped me think through the architecture, plan the implementation, and execute systematically. For anyone building Azure tooling, governance dashboards, or FinOps solutions, I can’t recommend it enough.

Resources

GitHub Copilot CLI: github.com/features/copilot/cli
Copilot CLI Repository: github.com/github/copilot-cli
Azure MCP Server: learn.microsoft.com
Copilot CLI Best Practices: docs.github.com
Awesome Copilot (Custom Agents & Skills): github.com/github/awesome-copilot

This is my entry for this year’s Azure Back To School. Massive shout-out to Dwayne Natwick for organising this every year!

If you’re building on Azure, integrating GitHub Copilot into your workflow can save time, reduce friction, and help with infrastructure, deployment, and debugging, not just writing business logic.

Below is an explanation of how to use it, what works well, and what to be aware of.

What “Copilot + Azure” means today

Here’s how the two worlds overlap currently:

GitHub Copilot for Azure: a VS Code extension that lets you ask about Azure, manage resources, deploy, and diagnose, all from the Copilot chat interface.

Copilot + Azure DevOps / Azure Repos: You can use Copilot with Azure Repos for suggestions, commit messages, and PR descriptions.

Agentic DevOps vision: Copilot is evolving into autonomous “agents” that can perform multi-step tasks, such as refactoring, testing, and fixing bugs. Azure pipelines, boards, and resource operations may tie into that.

Inner sourcing/knowledge reuse via MCP server: You can integrate Azure DevOps/Azure MCP server with Copilot, allowing it to suggest content from your organisation’s own modules or documentation.

Azure Boards integration: you can assign work items from Azure Boards to a Copilot coding agent, and track progress.

So it’s not just “autocomplete in VS Code + Azure SDK”, Copilot is pushing into infrastructure, operations, and agentic automation.

How to get started (practical steps)

• Install Copilot and the Azure extension
  • In VS Code, get the GitHub Copilot for Azure extension.
  • You need a Copilot license (Pro, Business, etc.)
• Use @azure prompts in Copilot Chat
  • Once the extension is active, you can prefix prompts with @azure to query Azure resource info, diagnose, or even do operations.

Examples:

@azure Deploy an Azure Function HTTP trigger with .NET 8
@azure What are the cost tiers for Azure SQL in West Europe?
@azure Diagnose why my webapp is showing 500 errors

• Deploy from within the editor
  • Copilot for Azure can suggest CLI commands, resource templates, or deployment steps without you switching to the Azure Portal.
• Use Copilot in code + infra files
  • When you edit ARM templates, Bicep, Terraform alongside app code, Copilot can help complete resource definitions, parameter scaffolding, and provide relevant snippets.
• Explore agentic features
  • Try Copilot agents for multi-file changes, code refactors, or cloud migration tasks. (Feature availability depends on your subscription and preview access.)
• Enable MCP / context servers
  • For tighter integration (e.g. your organization’s code modules, Azure DevOps context), you can configure MCP (Model Context Protocol) servers so Copilot has richer context

Benefits you’ll see

• Faster iteration: fewer trips to Azure portal or docs.
• Context-aware suggestions: Copilot knows your Azure setup or resource naming.
• Multi-step automation: not just code, but “deploy, test, monitor” flows.
• Consistency: reuse corporate standards or templates via inner sourcing.
• Better dev-ops synergy: bridging code and cloud operations in one interface.

Example scenario
Let’s say you’re building a serverless API on Azure Functions + Cosmos DB.

@azure Create an Azure Function project with HTTP trigger, .NET 8

Copilot responds with scaffold commands, project template.

@azure Provision a Cosmos DB instance with RU/s 400, region North Europe
Next up try

@azure Deploy this function and connect to Cosmos DB

It issues az commands or points you to CI/CD YAML.

If you see any errors after deployment:

@azure Diagnose 500 error in function logs

It helps inspect logs, points you to misconfigurations or missing settings.

Meanwhile, inside code files, Copilot suggests resource names, configuration keys, and helper snippets.

Future direction & what to watch

• More tasks handed over to the coding agent (not just suggestions).
• Better integration into Azure services (monitoring, cost, policies).
• Richer context via MCP so that Copilot is aware of your entire org’s patterns.
• Tighter link between Azure Boards / Pipelines and Copilot agents. (You already can assign work items to Copilot.
• Stronger guardrails: security analysis baked into generated infra code.

Summary

I use this GitHub Copilot on a daily basis and I recommend you at least take a look at it, if not use it daily too!