Sound Code - Mark Heath's Blog

The Future of Tech Blogging in the Age of AI

test@example.com — Wed, 01 Apr 2026 00:00:00 GMT

I've been blogging on this site for almost 20 years now, and the majority of my posts are simple coding tutorials, where I share what I've learned as I explore various new technologies (my journey on this blog has taken me through Silverlight, WPF, IronPython, Mercurial, LINQ, F#, Azure, and much more).

My process has always been quite simple. First, I work through a technical challenge and eventually get something working. And then, I write some instructions for how to do it.

Benefits of tech blogging

There are many benefits to sharing your progress like this:

The process of putting it into writing helps solidify what you learned
Despite this I still often forget how I achieved something, so my blog functions as a journal I can refer back to later
You're supporting the wider developer community by sharing proven ways to get something working
Thanks to "Cunningham's Law" ("the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."), your post may lead you to discover a better way to achieve the same goal, or a fatal flaw in your approach
And gradually it builds your personal reputation and credibility, as eventually you'll build up visitors (although you may find that your most popular post of all time is on the one topic that you most certainly aren't an expert on!)

Are LLMs going to ruin it all?

But recently I've been wondering - are LLM's going to put an end to coding tutorial blogs like mine? Do they render it all pointless?

For starters, GitHub Copilot and Claude Code have already dramatically changed the way I go about exploring a new technique or technology. Instead of slogging through Bicep documentation, and endlessly debugging why my template didn't work, I now just ask the AI model to create one for me.

Refreshingly, I notice that it gets it wrong just as frequently as I do, but it doesn't get frustrated - it just keeps battling away until eventually it gets something working.

But now it feels like a hollow victory. Is there even any point writing a tutorial about it? If you can simply ask an agent to solve the problem, why would anyone need to read my tutorial? Are developers even going to bother visiting blogs like mine in the future?

And then there's the question of who writes the tutorial? Not only is the agent much quicker than me at solving the technical challenge, it's also significantly faster at writing the tutorial, and undeniably a better writer than me too. So maybe I should just let it write the article for me? But the internet is already full of AI-generated slop...

Should you let AI write your blog posts?

This is a deeply polarizing question. There's a number of possible options:

Level 1: Human only

You could insist on hand-writing everything yourself, with strictly no AI assistance. That's what you're reading right now (if you can't already tell from the decidedly mediocre writing style!)

This mirrors a big debate going on in the world of music production at the moment. If AI tools like Suno can generate an entire song from a single prompt, that sounds far more polished than anything I've ever managed to produce, then does that spell the end of real humans writing and recording songs? And should we fight against it or just embrace it as the future?

I think tech tutorials do fall into a different category to music though. If I want to learn how to achieve X with technology Y, I just want clear, concise and correct instructions - and I'm not overly bothered whether it came 100% from a human mind or not.

Having said that, we've already identified a key benefit of writing your own tutorials: it helps solidify what you've learned. Doing your own writing will also improve your own powers of communication. For those reasons alone I have no intention of delegating all my blog writing to LLMs.

Level 2: Human writes, AI refines

On the other hand, it seems churlish to refuse to take advantage of the benefits of LLM for proof reading, fact checking, and stylistic improvements. When I posted recently about does code quality still matter this is exactly what I did. I wrote the post myself, and then asked Claude Code to help me refine it, by critiquing my thoughts and providing counter-arguments.

To be honest, I ignored most of the feedback, but undoubtedly it improved the final article. This is the approach I've been taking with my Pluralsight course scripts - I first write the whole thing myself, and then ask an LLM to take me to task and tell me all the things I got wrong. (Although they're still ridiculously sycophantic and tell me it's the greatest thing they've ever read on the topic of lazy loading!)

Level 3: AI writes, human refines

But of course, my time is at a premium. A blog tutorial often takes me well over two hours to write. That's a big time investment for something that will likely barely be read by anyone.

And if all I'm producing is a tutorial, perhaps it would be better for me to get the LLM to do the leg-work of creating the structure and initial draft, and then I can edit afterwards, adapting the language to sound a bit more in my voice, and deleting some of the most egregious AI-speak.

That's exactly what I tried with a recent post on private endpoints. Claude Code not only created the Bicep and test application, but once it was done I got it to write up the instructions and even create a GitHub repo of sample code. The end result was far more thorough than I would have managed myself, and although I read the whole thing carefully and edited it a bit, I have to admit that most of the time I couldn't think of better ways to phrase each sentence, so a lot of it ended up unchanged.

That left a bad taste in my mouth to be honest. If I do that too often will I lose credibility and scare away readers? And yet I do feel like it was a genuinely valuable article that shows how to solve a problem that I'd been wanting to blog about for a long time.

Level 4: AI only

Of course, there is a level further, and now we are getting to the dark side. Could I ask Claude or ChatGPT to write me a blog post and just publish it without even reading it myself? I could instruct it to mimic my writing style, and it might even do a good enough job to go unnoticed? Maybe at some time in the future, Claude can dethrone my most popular article with one it wrote entirely itself.

To be honest, I have no interest in doing that at all - it undermines the purpose of this blog which is a way for me to share the things that I have learned. So I can assure you I have no intention of filling this site up with "slop" articles where the LLM has come up with the idea, written and tested the code, and published the article all without me having to be involved at all.

But interestingly, this approach might make sense for back-filling the documentation for my open-source project NAudio. Over the years I've written close to one hundred tutorials but there are still major gaps in the documentation.

I'm thinking of experimenting with asking Claude Code to write a short tutorial for every public class in the NAudio repo, and to then check its work by following the tutorial and making sure it really works.

I expect we're going to see an explosion of this approach to, and it could be a genuine positive for the open source community, where documentation is often lacking and outdated. If LLMs are to make a positive contribution to the world of coding tutorials, this is probably one of the best ways they can be utilized.

Why tech blogging still matters

If you're still with me at this point, well done - I know I've gone on too long. Even humans can be as long-winded as LLMs sometimes. But the process of writing down my thoughts on this issue has helped me gain some clarity, and made me realise that it doesn't necessarily matter whether or not I take an AI-free, AI-assisted or even a AI-first approach to my posts.

The value of sharing these coding tutorials is that the problems I'm solving are real-world problems. They are tasks that I genuinely needed to accomplish, and came with unique constraints and requirements that are specific to my circumstances. That gives them an authenticity that an AI can't fake. At best it can guess at what humans might want to achieve, and create a tutorials about that.

So when I'm reading your tech blog (which I hope you'll share a link to), I won't really care whether or not you used ChatGPT to create the sample code, or make you sound like a Pulitzer prize winner. I'll be interested because you're sharing your experience of how you solved a problem using the tools at your disposal.

Securing Back-end App Service Web Apps with Private Endpoints

test@example.com — Tue, 31 Mar 2026 00:00:00 GMT

Back in 2019, I wrote about securing back-end App Service web apps using VNets and Service Endpoints. That approach worked well at the time, but Azure has moved on significantly since then. In this post, I'll show the modern way to achieve the same thing using Private Endpoints — which is now Microsoft's recommended approach.

The Problem

The scenario is the same as before. You have a front-end web app and a back-end API, both hosted on Azure App Service. End users need to reach the front-end, but the back-end should only be callable from the front-end. No one on the public internet should be able to reach it directly.

flowchart LR
    User([Internet User]) -->|✅ allowed| FE[Frontend Web App]
    FE -->|✅ allowed| BE[Backend API]
    User -->|❌ blocked| BE

This is a standard multi-tier architecture. With VMs or containers in a VNet, you'd simply not expose a public endpoint for the back-end. But App Service web apps have always had public endpoints by default — and until recently, locking them down was either fiddly (Service Endpoints) or expensive (App Service Environments).

What Changed Since 2019?

My 2019 approach used three features together:

VNet Integration — route the front-end's outbound traffic through a VNet
Service Endpoints — set up routing so App Service traffic flows through the VNet
Access Restrictions — whitelist the VNet subnet on the back-end

This worked, but had some limitations. Service Endpoints don't prevent data exfiltration (traffic is scoped to the entire App Service, not your specific app), and the Access Restrictions approach required some tricky Azure CLI commands to set up.

Private Endpoints are now the recommended replacement. Microsoft's documentation is explicit about this:

"Microsoft recommends using Azure Private Link. Private Link offers better capabilities for privately accessing PaaS from on-premises, provides built-in data-exfiltration protection, and maps services to private IPs in your own network."

Here's what makes Private Endpoints better:

	Service Endpoints (2019)	Private Endpoints (2026)
Scope	Entire App Service	Your specific app only
Data exfiltration protection	No	Yes
Public access	Still reachable (blocked by rules)	Blocked (access restrictions + Private Endpoint)
On-premises access	No	Yes (via VPN/ExpressRoute)
Setup complexity	Moderate (fiddly CLI commands)	Straightforward (Bicep)
Cost	Free	~$8/month

The small cost is well worth it for the significantly stronger security posture.

Architecture Overview

Here's what we're going to build:

flowchart TB
    subgraph Internet
        User([Internet User])
    end

    subgraph Azure
        subgraph VNet ["Virtual Network (10.0.0.0/16)"]
            subgraph IntSub ["integration-subnet (10.0.0.0/24)"]
            end
            subgraph PeSub ["pe-subnet (10.0.1.0/24)"]
                PE[Private Endpoint<br/>10.0.1.4]
            end
        end

        FE[Frontend Web App<br/>public access]
        BE[Backend API<br/>main site blocked]
        DNS[Private DNS Zone<br/>privatelink.azurewebsites.net]
    end

    User -->|HTTPS| FE
    FE -.->|VNet Integration| IntSub
    IntSub -->|private network| PE
    PE -->|Private Link| BE
    DNS -.->|resolves backend<br/>to 10.0.1.4| VNet
    User -.->|❌ 403 Forbidden| BE

    style BE fill:#f96,stroke:#333
    style FE fill:#6f9,stroke:#333
    style PE fill:#69f,stroke:#333

The key components:

VNet with two subnets: one for VNet Integration (delegated to App Service), one for the Private Endpoint
Frontend Web App — publicly accessible, with VNet Integration so its outbound traffic goes through the VNet
Backend API — main site blocked by access restrictions, reachable only via Private Endpoint
Private DNS Zone — resolves backend-xxx.azurewebsites.net to the private IP within the VNet

When the front-end calls the back-end, DNS resolution within the VNet returns the private IP (e.g. 10.0.1.4), and traffic flows through the Microsoft backbone via Private Link. Anyone on the public internet trying to reach the back-end gets a 403 Forbidden.

The Sample Apps

I used Claude Code to help me create two minimal ASP.NET Core (.NET 10) apps to demonstrate this. The back-end is a simple API:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/api/greeting", () => new
{
    message = "Hello from the secure backend!",
    timestamp = DateTime.UtcNow
});

app.MapGet("/health", () => Results.Ok("Healthy"));

app.Run();

The front-end is a Razor Pages app that calls the back-end. The key part is the HttpClient setup in Program.cs:

builder.Services.AddHttpClient("BackendApi", client =>
{
    var baseUrl = builder.Configuration["BackendApi:BaseUrl"]
        ?? "http://localhost:5100";
    client.BaseAddress = new Uri(baseUrl);
});

And the page model that calls it:

public async Task OnGetAsync()
{
    try
    {
        var client = _httpClientFactory.CreateClient("BackendApi");
        var response = await client.GetAsync("/api/greeting");
        response.EnsureSuccessStatusCode();

        var json = await response.Content.ReadFromJsonAsync<JsonElement>();
        GreetingMessage = json.GetProperty("message").GetString();
        GreetingTimestamp = json.GetProperty("timestamp").GetString();
    }
    catch (Exception ex)
    {
        ErrorMessage = $"Failed to reach backend: {ex.Message}";
    }
}

All pretty straightforward. The backend security is all handled by the infrastructure.

The Bicep Template

This is where the interesting stuff happens. Lets look at the key resources.

Virtual Network

We need a VNet with two subnets. The integration subnet is delegated to Microsoft.Web/serverFarms (required for VNet Integration). The private endpoint subnet has privateEndpointNetworkPolicies set to Disabled (required for Private Endpoints).

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'integration-subnet'
        properties: {
          addressPrefix: '10.0.0.0/24'
          delegations: [{
            name: 'delegation'
            properties: {
              serviceName: 'Microsoft.Web/serverFarms'
            }
          }]
        }
      }
      {
        name: 'pe-subnet'
        properties: {
          addressPrefix: '10.0.1.0/24'
          privateEndpointNetworkPolicies: 'Disabled'
        }
      }
    ]
  }
}

App Service Plan and Web Apps

Both apps share a single Linux B1 App Service Plan. The front-end has virtualNetworkSubnetId set to the integration subnet, which routes its outbound traffic through the VNet.

For the back-end, you might think we'd just set publicNetworkAccess: 'Disabled'. That does work for blocking internet traffic, but it also blocks the SCM/Kudu deployment endpoint — meaning you can't deploy your code with az webapp deploy any more. Instead, we use access restrictions: ipSecurityRestrictionsDefaultAction: 'Deny' blocks all public traffic to the main site, while scmIpSecurityRestrictionsUseMain: false with scmIpSecurityRestrictionsDefaultAction: 'Allow' keeps the deployment endpoint accessible. The Private Endpoint ensures the front-end can still reach the back-end over the private network.

resource appServicePlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: appServicePlanName
  location: location
  kind: 'linux'
  sku: { name: 'B1' }
  properties: { reserved: true }
}

resource backendApp 'Microsoft.Web/sites@2024-04-01' = {
  name: backendAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    publicNetworkAccess: 'Enabled'
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|10.0'
      ipSecurityRestrictionsDefaultAction: 'Deny'
      scmIpSecurityRestrictionsUseMain: false
      scmIpSecurityRestrictionsDefaultAction: 'Allow'
    }
  }
}

resource frontendApp 'Microsoft.Web/sites@2024-04-01' = {
  name: frontendAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    virtualNetworkSubnetId: vnet.properties.subnets[0].id
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|10.0'
      appSettings: [{
        name: 'BackendApi__BaseUrl'
        value: 'https://${backendAppName}.azurewebsites.net'
      }]
    }
  }
}

Note that our approach leaves the SCM/Kudu deployment endpoint publicly accessible (it's authenticated, so the risk is low). If you want to eliminate that surface area entirely, you could set publicNetworkAccess: 'Disabled' and use an alternative deployment method that bypasses Kudu — for example, run-from-package with WEBSITE_RUN_FROM_PACKAGE pointing at a blob storage URL, or containerizing your app and pulling from ACR. Both approaches mean the backend never needs a public endpoint at all, though you may need to add VNet integration to the backend for outbound access to the storage account or registry if those are private too.

Private Endpoint and DNS

The Private Endpoint creates a network interface in the PE subnet that's connected to the back-end app. The Private DNS Zone ensures that backend-xxx.azurewebsites.net resolves to the private IP when queried from within the VNet.

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2024-05-01' = {
  name: 'pe-${backendAppName}'
  location: location
  properties: {
    subnet: { id: vnet.properties.subnets[1].id }
    privateLinkServiceConnections: [{
      name: 'pe-${backendAppName}'
      properties: {
        privateLinkServiceId: backendApp.id
        groupIds: ['sites']
      }
    }]
  }
}

resource privateDnsZone 'Microsoft.Network/privateDnsZones@2024-06-01' = {
  name: 'privatelink.azurewebsites.net'
  location: 'global'
}

resource dnsZoneLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2024-06-01' = {
  parent: privateDnsZone
  name: '${vnetName}-link'
  location: 'global'
  properties: {
    virtualNetwork: { id: vnet.id }
    registrationEnabled: false
  }
}

resource dnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2024-05-01' = {
  parent: privateEndpoint
  name: 'default'
  properties: {
    privateDnsZoneConfigs: [{
      name: 'privatelink-azurewebsites-net'
      properties: { privateDnsZoneId: privateDnsZone.id }
    }]
  }
}

Deploying

I've created a PowerShell deployment script that uses the Azure CLI. Here are the key steps:

# Create the resource group
az group create -n SecureBackendDemo -l uksouth

# Deploy the Bicep template
az deployment group create `
    -g SecureBackendDemo `
    --template-file ./infra/main.bicep

The Bicep deployment creates all the networking and App Service resources. After that, we publish and deploy both .NET apps:

# Build and publish
dotnet publish src/Backend/Backend.csproj -c Release -o publish/backend
dotnet publish src/Frontend/Frontend.csproj -c Release -o publish/frontend

# Package as zip
Compress-Archive -Path "publish/backend/*" -DestinationPath publish/backend.zip
Compress-Archive -Path "publish/frontend/*" -DestinationPath publish/frontend.zip

# Deploy to App Service
az webapp deploy -g SecureBackendDemo -n $backendAppName --src-path publish/backend.zip --type zip
az webapp deploy -g SecureBackendDemo -n $frontendAppName --src-path publish/frontend.zip --type zip

The full deployment script is in the repository — just run .\deploy\deploy.ps1 and it handles everything.

Testing

Once deployed, we can verify the security is working:

Test 1: Frontend is accessible and shows the backend greeting

$response = Invoke-WebRequest -Uri $frontendUrl -UseBasicParsing
# Should return 200 with "Hello from the secure backend!" in the HTML

Test 2: Backend is NOT accessible from the internet

Invoke-WebRequest -Uri "$backendUrl/api/greeting" -UseBasicParsing
# Should return 403 Forbidden

The test script (deploy/test.ps1) automates both checks.

Cost Breakdown

Here's what this setup costs beyond the App Service Plan itself:

Resource	Monthly Cost
Virtual Network	Free
VNet Integration	Free
Private Endpoint	~$7.30
Private DNS Zone	~$0.50
DNS queries	~$0.40 per million
Total networking overhead	~$8/month

Compare that to alternatives like Application Gateway (_{$200/month), APIM (}$300/month), or an App Service Environment (~$1,000/month). For simple back-end lockdown scenarios, Private Endpoints are by far the most cost-effective option.

Cleaning Up

Since everything is in a single resource group, cleanup is one command:

az group delete -n SecureBackendDemo --yes --no-wait

Summary

Private Endpoints have replaced Service Endpoints as the recommended way to secure back-end App Services. The setup is more straightforward (especially with Bicep), the security is stronger (true private IP, data exfiltration protection), and the cost is minimal (~$8/month). If you're still using the Service Endpoints approach from my 2019 post, it's worth upgrading.

The complete source code for this demo — including the .NET apps, Bicep template, and deployment scripts — is available on GitHub.

Does Code Quality Still Matter in the Age of AI-Assisted Coding?

test@example.com — Mon, 30 Mar 2026 00:00:00 GMT

I'm increasingly hearing the sentiment that now AI models can write code for us, we no longer need to concern ourselves with concepts like "clean code", eliminating code smells, following SOLID principles etc. All of these concerns, it's argued, are purely an attempt to make the codebase more comprehensible for humans. But if humans are no longer reading the code, what does it matter? The only thing we should care about is whether the code works correctly or not.

I can partially understand this perspective. One great strength of AI agents is that they never tire. You can ask them to work on a "big ball of mud" and they won't complain. They don't mind if it's a giant convoluted monolith or an over-engineered set of microservices spread across multiple repos. They will just keep searching around in the code until they eventually find the bit they need to change.

However, I think that this is a mistake - even if we grant that we don't need code to be "human readable" any more (which I'm also not convinced of - I still find it very useful to check in on how an agent is going about tackling a particular problem). Let me give just a few quick reasons why following these "traditional" coding guidelines still matters.

Finding the right place

The first thing a coding agent needs to do when fixing a bug or adding a new feature, is to determine where in the codebase that change should be made. This involves searching, and if you look at the model's reasoning steps and tool calls you can see what it searches for (spoiler alert: it's mostly just grepping for words it thinks might be relevant).

This has several implications. First, it means that if our naming is weird or inconsistent, it will require more attempts to find the right place, slowing your agent's progress considerably.

Second, it means that it is quite possible that it will miss some relevant portions of the codebase. The "shotgun surgery" antipattern is where you need to modify many different files to implement a single feature. It's often the result of copy and pasted code, or just poor architectural decisions that don't organize key responsibilities or cross-cutting concerns into a single place. When you have code like this, the chances of your agent successfully finding all the places that need to be modified are greatly diminished.

Then, there's a context window size problem. In an ideal world, the agent reads the entire codebase in one go and can reason about the whole thing as a unified whole. But that's simply not how they work at the moment, partly because the context windows aren't large enough (despite some recent models having a 1M token context window), and partly because the quality of model output tends to degrade, the longer your session grows.

This means, for example, that following the "Single Responsibility Principle" will greatly help the model. Once it's found the single class that is relevant to the task at hand, it can read it all, without polluting the context window with lots of additional code that's irrelevant to the task at hand.

So a well-organized, modular codebase, with well-named functions and classes is going to greatly enhance the effectiveness of an AI agent working on that project, increasing its chances of quickly finding the right place to edit.

The cost aspect of this should not be underestimated. These agents can quickly burn through very large amounts of tokens, and it does seem that many of the subscription models are unsustainably subsidised at the moment.

This means that in the (perhaps very near) future, we'll all be thinking a lot harder about how to make our agents read less code and perform fewer tool calls. The fact that each agent session starts out fresh means that it often has to spend time re-learning things it previously discovered. Already we are seeing many projects designed to address this problem (e.g. I just stumbled across this one today)

It's not just the how but the what and why

Code is instructions to the computer about what it should do. It expresses the "how" but not "what" or "why". That's why good class and method names and code comments are important. They provide valuable additional context to the human reading it so they can understand the intent of the code. This contextual information is just as relevant to agents who need to make connections between the natural language instructions that you provide them, and the concepts found in the codebase.

The best way vs the quickest way

AI agents are very goal-oriented. Ask them to fix a bug or to add a feature and they will find a way to do it. Unless you explicitly instruct them to, they won't push back on the request, or propose alternative better strategies.

When a human developer is fixing a bug, they will often take a step back and ask whether this bug is actually an example of a wider category of problems. So we might actually increase the scope of the task at hand in order to prevent many similar issues in the future.

I'm increasingly seeing the idea that we could set up an automated process whereby every time an issue is raised on your GitHub repo, an agent triages it, attempts to fix it, creates and merges the PR. This is of course incredibly appealing - imagine if 90% of bugs were just automatically fixed within hours of being reported.

But unless this "bigger picture" thinking can also be baked into the fixing process, this approach could result in the classic "technical debt" problem where every issue is resolved in the "quickest way" without regard to the longer-term maintainability implications.

Summary

Code quality still matters for any codebase that you plan to improve and maintain long-term. Even if humans don't have to suffer the pain of reading poorly architected codebases, the effectiveness of AI agents can be significantly hindered by allowing structure to degrade. Investing in code quality (even if its just instructing the agents to do some rounds of cleanup and improvements after each task) will provide a stronger foundation for future development.

Protecting Against Concurrent Updates in Azure Blob Storage with ETags

test@example.com — Mon, 09 Feb 2026 00:00:00 GMT

I recently had to deal with a situation where there was potential for multiple processes to attempt to modify the same Azure blob at the same time.

By default, if two processes read the same Azure blob and then both try to write updated content back, one of them will silently overwrite the other's changes. Fortunately, Azure Blob Storage provides a built-in mechanism to prevent this, called ETags. An ETag is simply a version token that changes every time a blob is modified. By passing the ETag you read back as a condition on your write, you can tell Azure to "only accept this update if nobody else has changed the blob since I last read it." If someone else got there first, Azure returns a 412 Precondition Failed and you can retry with fresh data.

Let's take a look at how to implement an optimistic concurrency pattern using ETags in C#.

Setting Up the Clients

First, let's get connected to the storage account using the convenient DefaultAzureCredential to avoid hard-coding any keys.

var serviceUri = new Uri("https://youraccountname.blob.core.windows.net/");
var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(serviceUri, credential);
var containerClient = blobServiceClient.GetBlobContainerClient("your-container");

You'll need to reference the Azure.Identity and Azure.Storage.Blobs NuGet packages.

Fetching the Blob and Its ETag

The crucial step is to retrieve the ETag alongside the blob content. Here I've made a simple helper called DownloadContentAsync that returns both in one call:

async Task<(string, ETag)> FetchContentsAsync(BlobClient blobClient)
{
    try
    {
        var content = await blobClient.DownloadContentAsync();
        return (content.Value.Content.ToString(), content.Value.Details.ETag);
    }
    catch (RequestFailedException ex) when (ex.Status == 404)
    {
        // Blob doesn't exist yet; return empty content and a default (empty) ETag
        return (string.Empty, default);
    }
}

Writing Back with an ETag Condition

Now that we've retrieved the existing blob contents, let's imagine that we've updated them and now we want to re-upload.

Before uploading, we need set a BlobRequestConditions on the upload options. There are two cases:

Blob didn't exist (etag == default): use IfNoneMatch = new ETag("*") so the upload only succeeds if the blob still doesn't exist.
Blob already exists: use IfMatch = etag so the upload only succeeds if the blob's current ETag still matches the one we read.

If the condition fails, Azure returns 412 Precondition Failed and the SDK throws a RequestFailedException. We catch that and return false to signal a conflict.

Again I've created a simple helper method UpdateContentsAsync to show how we can do this and detect the concurrency issue.

async Task<bool> UpdateContentsAsync(BlobClient blobClient, string contents, ETag etag)
{
    var uploadOptions = new BlobUploadOptions
    {
        Conditions = etag == default
            // Blob didn't exist: only create if still absent
            ? new BlobRequestConditions { IfNoneMatch = new ETag("*") }
            // Blob existed: only overwrite if ETag still matches
            : new BlobRequestConditions { IfMatch = etag }
    };

    try
    {
        await blobClient.UploadAsync(BinaryData.FromString(contents), uploadOptions);
        return true;
    }
    catch (RequestFailedException ex) when (ex.Status == 412 || ex.ErrorCode == BlobErrorCode.ConditionNotMet)
    {
        // Another writer changed the blob between our read and write
        return false;
    }
}

Retrying with Exponential Backoff

A conflict just means someone else updated the blob first, so we don't need to give up. Instead we can just fetch the latest version and try again. To avoid a situation of too many processes all trying to update at the same time, we can back off exponentially and add a small random jitter to each delay.

async Task ModifyBlob(
    BlobContainerClient container,
    string blobName,
    Func<string, Task<string>> transform,
    CancellationToken ct)
{
    ArgumentNullException.ThrowIfNull(transform);

    var maxRetries = 5;
    var attempt = 0;
    var delay = TimeSpan.FromSeconds(2);
    var blobClient = container.GetBlobClient(blobName);

    while (attempt < maxRetries)
    {
        ct.ThrowIfCancellationRequested();
        attempt++;

        var (contents, etag) = await FetchContentsAsync(blobClient);
        var newContents = await transform(contents);

        if (await UpdateContentsAsync(blobClient, newContents, etag))
            return; // success

        // Back off before retrying
        var jitterMs = Random.Shared.Next(0, 100);
        await Task.Delay(delay + TimeSpan.FromMilliseconds(jitterMs), ct);

        // Exponential backoff, capped at 5 seconds
        delay = TimeSpan.FromMilliseconds(Math.Min(delay.TotalMilliseconds * 2, 5_000));
    }

    throw new InvalidOperationException(
        $"Failed to update blob '{blobName}' after {maxRetries} attempts.");
}

The transform delegate receives the current blob content and returns the new content. ModifyBlob handles all the retry logic so callers don't need to think about ETags at all.

Seeing Concurrency Conflicts in Action

To check this actually works we can make a simple modification to simulate two concurrent updaters. The outer transform, before writing its own change, triggers an inner call to modify the blob that successfully commits first. When control returns to the outer call its ETag is now stale, so the first attempt fails and the retry loop kicks in.

bool firstTime = true;

await ModifyBlobTest(containerClient, blobName, async currentContent =>
{
    if (firstTime)
    {
        // While the outer call holds its ETag, the inner call commits a change,
        // invalidating the outer ETag.
        await ModifyBlobTest(
            containerClient, blobName,
            c => Task.FromResult($"{c}\r\nInner update {DateTimeOffset.Now}"),
            CancellationToken.None);
    }
    firstTime = false;
    return $"{currentContent}\r\nOuter conflicting update {DateTimeOffset.Now}";
}, CancellationToken.None);

On the first pass through the outer loop you'll see output like:

Successful update of etag "0x1234..."   ← inner update wins
Concurrency conflict detected. Old ETag: "0x1234..."  ← outer detects stale ETag
Successful update of etag "0x5678..."   ← outer retries and succeeds

Both updates end up in the blob — neither is lost.

Summary

ETags give you a simple optimistic concurrency mechanism for Azure Blob Storage: read the blob and its ETag together, apply your changes, then write back with a condition that fails if the blob has been modified in the meantime. If you wrap that in a retry loop with exponential backoff and jitter, you have a robust pattern that handles any number of concurrent writers without data loss or locks.

Obviously in an ideal world you wouldn't be making lots of concurrent updates to blobs, but if you do, you can use the approach shown in the ModifyBlob helper shown above.

EF Core Lazy Loading Performance Gotcha

test@example.com — Thu, 08 Jan 2026 00:00:00 GMT

I was recently using EF Core's ILazyLoader for lazy loading without proxies, and ran into a performance issue that took me by surprise. When you call DbSet<T>.Add() to add an entity to the context, EF Core immediately injects the lazy loader into your entity even before you've called SaveChangesAsync(). This means if you navigate to a lazy-loaded navigation property before persisting, EF Core will try to query the database for related entities that don't exist yet.

It's an unnecessary performance overhead and the fix is fortunately very simple: don't add entities to the DbContext until right before you're ready to call SaveChangesAsync().

The Model

To understand how it behaves I created a simple example project using a Blog and Post relationship with ILazyLoader injection:

public class Blog
{
    private ICollection<Post>? _posts;
    private ILazyLoader? _lazyLoader;

    public Blog() {}

    public Blog(ILazyLoader lazyLoader)
    {
        _lazyLoader = lazyLoader;
    }

    public int Id { get; set; }
    public required string Name { get; set; }
    
    public virtual ICollection<Post> Posts
    {
        get => _lazyLoader?.Load(this, ref _posts) ?? _posts ?? [];
        set => _posts = value;
    }
}

public class Post
{
    public int Id { get; set; }
    public required string Title { get; set; }
    public required string Content { get; set; }
    public virtual Blog? Blog { get; set; }
}

Reproducing The Problem

Now let's look at what happens when you add a blog with posts, but navigate into the Posts collection before persisting to the database:

using (var context = new BloggingContext())
{
    await context.Database.EnsureCreatedAsync();

    // Create a new Blog with two Posts
    var blog = new Blog
    {
        Name = "Test Blog",
        Posts =
        [
            new Post { Title = "First Post", Content = "Hello from EF Core 10!" },
            new Post { Title = "Second Post", Content = "Another post for testing." }
        ]
    };

    // This causes EF Core to inject the lazy loader using reflection
    context.Blogs.Add(blog);

    // Accessing blog.Posts triggers the lazy loader to query the database
    // even though this blog hasn't been saved yet!
    Console.WriteLine("Number of posts: " + blog.Posts.Count);

    await context.SaveChangesAsync();
}

When you call context.Blogs.Add(blog), EF Core uses reflection to inject an ILazyLoader instance into the Blog object. From that point on, any access to blog.Posts will trigger the lazy loading mechanism. Since the blog doesn't exist in the database yet (no Id has been assigned), EF Core will execute a query that looks something like:

SELECT [p].[Id], [p].[BlogId], [p].[Content], [p].[Title]
FROM [Posts] AS [p]
WHERE [p].[BlogId] = 0

This is completely pointless - the blog hasn't been persisted, so there can't possibly be any related posts in the database.

The Solution

The fix is straightforward: only add the entity to the context right before you call SaveChangesAsync():

using (var context = new BloggingContext())
{
    await context.Database.EnsureCreatedAsync();

    var blog = new Blog
    {
        Name = "Test Blog",
        Posts =
        [
            new Post { Title = "First Post", Content = "Hello from EF Core 10!" },
            new Post { Title = "Second Post", Content = "Another post for testing." }
        ]
    };

    // Do all your work with the blog object first
    Console.WriteLine("Number of posts: " + blog.Posts.Count);

    // Only add to context when you're ready to save
    context.Blogs.Add(blog);
    await context.SaveChangesAsync();
}

Now when you access blog.Posts, there's no lazy loader injected yet, so it just returns the collection you assigned, with no database query needed.

Summary

If you're using ILazyLoader injection in EF Core, be mindful of when you add entities to the DbContext. The lazy loader gets injected as soon as you call Add(), not when you call SaveChangesAsync(). So if you need to work with navigation properties before persisting, keep the entity disconnected from the context until you're ready to save. This avoids unnecessary database queries.

2025 Year in Review

test@example.com — Wed, 31 Dec 2025 00:00:00 GMT

Happy Christmas and happy new year! I know it's been a while since I last posted anything here, but thought I'd revive my tradition of writing another year in review post.

Pluralsight

Part of the reason for me not having as much time for blogging is that I created three new Pluralsight courses this year, bringing my total to 29.

First up was a course about refactoring and optimizing code with GitHub Copilot. Obviously 2025 has been the year where AI as firmly established itself as a day-to-day part of the developer experience, and it's an extremely fast-moving space. AI-assisted coding can be both incredibly impressive and incredibly frustrating. Impressive as it can often write in a few seconds what it would have taken hours or even days to write manually, but frustrating as it can often miss the point of what you're asking or make critical mistakes that cost you almost as much time as you saved. In my course I tried to focus on the basics of how to prompt the AI assistant well, to enable you to get as much benefit out of it as possible, without falling into the pitfall of losing control of your codebase and ending up with a vibe-coded mess.

Next up was two courses about microservices, which essentially replace and update my earlier Pluralsight courses on the same topic. Despite some recent pushback against microservices in the industry, it remains a valuable and important architectural approach, and the core principles of microservices are relevant whenever you're building a distributed application (which for a lot of us, is all the time).

The first microservice course was Microservices: Architectural Strategies and Techniques, which covers some of the key principles for designing scalable and modular microservice architectures and explores the value of service meshes and continuous delivery pipelines. And the second was Microservices: Building and Testing which focuses in more detail on topics like implementing the domain logic, as well as how to test and deploy microservices.

Carpal Tunnel Surgery

Another reason for my reduced blogging output this year was some health issues. I've been battling back pain for a few years, although this year a strict regime of daily stretches and exercises and much more use of a standing desk seems to have helped a lot, and I'm a lot better than I was. For any younger developers reading this, make sure you look after your back - it's frustratingly slow to recover once you've injured it!

I've also been having a lot of issues with hand numbness and finally had carpal tunnel surgery on my left hand (which was my worst) midway through the year. I was quite apprehensive about whether it would impact or even eliminate my ability to play guitar but I'm pleased to report that my strength and flexibility returned enough after a couple of months to continue playing as before. Thankfully my right hand isn't as bad, so I'm not in a rush to get that one done yet.

Music and Audio

As you may know, one of my favourite hobbies is playing and recording music, and this year even with a break for carpal tunnel surgery I managed to play guitar or piano live at 32 events, as well as participated in recording a live album which was a first for me.

I also continued my tradition of composing and writing one instrumental song a month (which I occasionally batch up into albums that you can find here on Spotify or Bandcamp or just listen to them as they come out on YouTube).

This Christmas I upgraded my long-serving Yamaha MODX 7 keyboard to the newer Yamaha MODX M7 which is a very nice upgrade with the new ANX audio engine, better AWM polyphony and an improved user interface. It's also interesting to me that we are seeing an increasing number of hardware synthesizers providing fully software versions of their sounds, meaning that you can much more easily transition between studio and live playing using the same sounds (Arturia's Astrolab series also does this).

In terms of guitar tech, I'm still very happy with my Line 6 Helix LT and IK Multimedia TONEX, which between them give me access to a very wide variety of tones and effects. Again it's a very fast-moving space, with many exciting new software and hardware products being released and we're also seeing machine learning take a much more prominent role in music production (a trend I expect to increase in 2026).

AI, .NET and Azure

My day job continues to revolve mostly around .NET and Azure, as well as increasingly incorporating various AI technologies (both in the development process and to power new functionality).

My work with Azure this year has been a lot less on learning about new services, and more on how to deliver excellent resilience, scalability, and performance. I hope to feed a lot of the lessons I've learned into upcoming Pluralsight courses and talks.

I'm also hoping to find more time this year to go deeper with Azure Container Apps and Dapr which both have a lot to offer to simplify the process of building and deploying microservices and distributed applications.

It's great to see that each new version of .NET manages to squeeze out more performance improvements, and this has meant I have never regretted choosing .NET as my main development platform. (Still hoping for discriminated unions in C# though!)

Of course, there was also a lot of AI this year. I am both an AI enthusiast and an AI skeptic - it has potential to be very helpful but also very harmful. A key skill for all developers is knowing when and how to use it effectively.

I did attempt the Advent of Code challenges again this year, forcing myself to do them without the help of AI. Sadly didn't manage to complete all the challenges due to time constraints, so I'd like to cycle back to the two I missed if I get a chance later in the year.

What's next?

As for what's in store for next year, there's a good chance that I'll be creating one or two additional Pluralsight courses, although that's not been confirmed yet.

I took a break from speaking at conferences when my back was at its worst, and haven't currently got any new talks planned, but maybe if things continue to go well this year I might consider taking that up again.

And I think this might be my final year as Microsoft MVP as I have not been able to contribute as much as I have in previous years. It's been a great privilege to be part of the MVP program for nearly 10 years now, so I'll take the opportunity to say a big thank you to the MVP organizers and the other MVPs for all they do to ensure that .NET developers get access to great learning resources.

Once again, a big thank you to everyone who has read this blog or watched my Pluralsight courses. I hope you've found them helpful and thanks for all the encouraging feedback.

Are Microservices Becoming Easier?

test@example.com — Thu, 10 Jul 2025 00:00:00 GMT

I've been a bit quiet on this blog recently mainly because I've been busy working on a new Pluralsight course Microservices: Architectural Strategies and Techniques, which essentially replaces my previous Microservices Fundamentals course, although they cover slightly different topics. In this course, I wanted to make sure I addressed some of the "pushback" against microservices, as it's fair to say that there has been some legitimate questions asked about whether microservices are being applied to problems where they don't actually help.

However despite their challenges, I do think there are situations in which microservices can make a lot of sense. And that's because when a software product becomes large enough, with many teams of developers, and many user-facing websites or applications, and many APIs, then it's inevitable that it becomes a distributed system.

In some ways you can think of microservices as simply a more disciplined approach to distributed systems, where you take care to ensure that each service is independently deployable. This helps you avoid the pitfall of building a "distributed monolith" - an architecture famous for combining the worst aspects of both monoliths and distributed systems.

In fact, the majority of the tools, techniques and strategies I discuss in the course are not strictly specific to microservices. That's because most of the key concerns about observability, security, scalability, testability, automated deployment are things that you'll need in a distributed system regardless of whether you are explicitly trying to create "microservices".

Are Microservices Becoming Easier?

One of the hopes in the early days of microservices was that over time, we'd develop tooling that helped us overcome many of the challenges of building, testing, and deploying distributed systems.

In some ways that is true. For example, Kubernetes is incredibly powerful and flexible and has established itself as the de-facto standard for hosting microservices. However, I certainly wouldn't describe it as simple to learn and manage. But we are seeing the emergence of simplified microservices hosting platforms, such as Azure Container Apps which is built on top of Kubernetes, but takes away a lot of the complexity and streamlines the process of hosting your microservices.

Another favourite toolkit of mine for building microservices is Dapr, which offers a set of "building blocks", to enable you to build secure and reliable microservices. I've actually created a Dapr Fundamentals Pluralsight course. The way Dapr delivers these capabilities is by exposing APIs from a sidecar container. This approach has the benefit of making Dapr programming language agnostic, and cloud-agnostic as the building blocks each offer a variety of backing services to implement the capability, giving you a lot of freedom to use the languages and services you are familiar with.

In the .NET world, .NET Aspire aims to improve the experience of building microservices by providing various tools, templates and packages that especially enhance the local development experience. So it does feel like things are moving in the right direction towards simplifying the overall microservices experience.

And in my Pluralsight course I also wanted to include a brief section exploring the ways in which AI is able to streamline the experience of building, deploying and managing microservice applications. A lot of the pain points of microservices revolve around the complexities of managing a system made up of so many interconnected parts. It's still early days for AI, but I am hopeful that it could make a big difference especially in the area of monitoring and troubleshooting distributed systems.

Summary

Microservices remain an valuable architectural pattern, despite the potential troubles you can run into with them. Generally, my architectural preference is to keep things as simple as possible, and only reach for more advanced patterns and tools when you have proved that you really need them. So most of the tools and techniques I show in the course are not so much a prescription of what you should do, as suggestions for things you might reach for if you're experiencing the problems they're designed to solve. If you're a Pluralsight subscriber, why not check out my Microservices: Architectural Strategies and Techniques course, and as always I'm very interested in learning from other people's experiences so do feel free to get in touch via the comments.

Calling MCP Servers in C# with Microsoft.Extensions.AI

test@example.com — Mon, 14 Apr 2025 00:00:00 GMT

I posted recently about how to allow LLMs to call tools using the Microsoft.Extensions.AI NuGet package in C#.

Obviously, a common usage scenario would be to expose MCP servers as tools for your LLM to call. Thankfully, the new ModelContextProtocol NuGet package makes this straightforward.

Note: This package is still in pre-release (as is Microsoft.Extensions.AI), so do check the release notes for any breaking changes to the API.

I've updated my demo application to support calling MCP tools, following the techniques demonstrated in Microsoft's Chat With Tools sample.

The first step is simply to reference the ModelContextProtocol NuGet package. I had to also update the Microsoft.Extensions.AI versions as well. Here's the versions I used for my test:

<PackageReference Include="Microsoft.Extensions.AI" Version="9.4.0-preview.1.25207.5" />
<PackageReference Include="Microsoft.Extensions.AI.OpenAI" Version="9.4.0-preview.1.25207.5" />
<PackageReference Include="ModelContextProtocol" Version="0.1.0-preview.8" />

The next step is simply to connect to an MCP server. You can do this with the McpClientFactory. Here, we're using npx (which comes with Node) to run a simple example MCP server called the "Everything" server as it demonstrates the range of capabilities of an MCP server.

var mcpClient = await McpClientFactory.CreateAsync(
    new StdioClientTransport(new()
    {
        Command = "npx",
        Arguments = ["-y", "--verbose", "@modelcontextprotocol/server-everything"],
        Name = "Everything",
    }));

We can then use the MCP client to list the available tools:

var tools = await mcpClient.ListToolsAsync();
Console.WriteLine("Available tools:");
foreach (var tool in tools)
{
    Console.WriteLine($"  {tool.Name}: {tool.Description}");
}

These tools are instances of McpClientTool, which inherits from AIFunction, meaning that we can pass them directly in as tools to an instance of ChatOptions:

var chatOptions = new ChatOptions
{
    Tools = [..tools]
};

And then using the tools is simply a case of passing those options into the call to GetStreamingResponseAsync.

 await foreach (var item in chatClient.GetStreamingResponseAsync(
        chatHistory, chatOptions))

Although it's early days for the MCP protocol, it's very pleasing to see how easy it is to get your LLM calling tools provided by an MCP server. For the full code sample, showing how to get this working with Azure OpenAI service, check my demo repo here.

Using an MCP Server in GitHub Copilot

test@example.com — Thu, 10 Apr 2025 00:00:00 GMT

GitHub Copilot is continuing to evolve very rapidly, with the recent launch of "agent mode", and the ability to connect to "Model Context Protocol" servers which gives you access to a vast array of tools, essentially allowing your agent to access any data, and perform any actions you like.

In this post, I'll walk you through the steps to configure Visual Studio Code to connect to an MCP Server and make use of it in agent mode.

For our demo scenario, we'll use the Playwright MCP server which exposes the capabilities of the Playwright end-to-end browser automation testing tool. This essentially gives your "agent" the ability to open a web browser and perform actions in there, which obviously opens up a lot of possibilities.

Configure the MCP Server in VS Code

First of all, we do need to have node installed as we need the npx tool to run the Playwright server.

Next, we need to configure Visual Studio Code to access the Playwright MCP Server. The README docs provide several ways to do this, the easiest being to just click on the "Install Server" button.

Installing it will change your settings.json file to add something like this. Note that I needed to add the --browser msedge args as I don't have Chrome installed on my PC, which is the default browser for Playwright.

"mcp": {
    "servers": {
        "playwright": {
            "command": "npx",
            "args": [
                "-y",
                "@playwright/mcp@latest",
                "--browser",
                "msedge"
            ]
        }
    }
},

You also do need to ensure that the the MCP server starts correctly. In theory VS Code should do this automatically, but you can use the "MCP: List Servers" command in VS Code to pick your server and explicitly start, stop or restart it.

Selecting agent mode and enabling tools

To try it out, you simply open the GitHub Copilot Chat window, and in the drop-down in the prompt box, select "Agent" mode. The prompt box will now include a button to let you select the tools that you want to allow the agent to use.

The Playwright MCP server actually offers multiple tool actions such as navigating, clicking, typing, etc. So if you want to, you can restrict the agent to only be allowed to call specific tools.

Trying it out

Next, we simply need to ask the agent to do something that requires the use of the tool. For example, I prompted it with "visit the hacker news home page and find all articles relating to audio or music"

If the AI model decides it wants to run a tool, it will pause, asking you for permission. This is good from a security perspective, although I can imagine people quickly getting tired of granting permission at a granular level, and just enabling their agents to do whatever they think is best.

In this example, it's likely to ask to run the browser_navigate command to go to the Hacker News homepage. In my case, it found two articles and decided to run browser_navigate again on both of them so it could read these articles and summarise them.

Of course, the agent might not do exactly what you wanted. I found that with this particular prompt, sometimes it assumed I wanted it to create an application that fetched the Hacker News homepage and printed out the titles of the articles about audio.

So don't forget the retry button at the bottom of each response. You can always ask the model to try again (or try again with a different model) if you're not happy with the initial response.

What else can I do with MCP?

The great thing about MCP is that it is extremely flexible. Already, hundreds of servers have been created (you can find a good list here). An obvious use-case would be to give the LLM access to data stored in various locations - such as your company's internal documentation.

And you can also use them to trigger actions in other systems, whether that's posting an update onto a Slack channel, or by calling your own internal API to perform a custom business process.

Already it seems like MCP has been accepted as the defacto standard to grant AI agents access to a wide variety of tools, and the ease with which an MCP server can be built means that just about any kind of integration you can think of is achievable.

I suspect the next challenges in this area will be ensuring that the LLM is good at picking the right tool for the job (especially if you have many dozens of MCP servers, each with multiple commands), and providing adequate security mechanisms so that these tools (whether deliberately or not) don't cause significant damage (e.g. leaking sensitive data, spending all your money in the cloud, deleting all your stuff, etc).

Refactoring and Optimizing Code with GitHub Copilot

test@example.com — Tue, 01 Apr 2025 00:00:00 GMT

I'm pleased to announce my latest Pluralsight course, Refactor and Optimize Code with GitHub Copilot, has just gone live. It will be part of a series of courses covering various aspects of using GitHub Copilot, and my course focuses specifically on using Copilot to refactor, modernize and optimize code.

This is an important topic as many of us are spending a lot of time working on existing legacy codebases, and learning to use GenAI effectively with these projects is a great investment of your time.

Of course, it’s a somewhat daunting topic to teach on because things are changing so rapidly, and best practices are still emerging. However, as I tried out different challenges, I was impressed with the breadth of scenarios in which LLMs can be of assistance in the coding environment.

Let me quickly share a few of the key lessons I learned while preparing for this course and that I tried to teach during it.

Context matters

LLMs know a lot of stuff - they've read pretty much the entire internet. But they don't know about your application, and your goals unless you tell they. So make use of the ability to drag in additional files to the context window, or use @workspace or #codebase. And you can give it more than code - make use of custom instructions or drag in additional documentation that's relevant.

Try to think of Copilot like a new starter at your company. Even if they are very intelligent, they will need a lot of guidance to understand exactly how you want them to work, the big picture of what the application does, and the reasons behind the tasks you are giving them.

Review and verify!

Of course I hope it goes without saying that you should review and verify the changes that Copilot makes. It can be tempting to get lazy especially if Copilot is on a roll, getting things right more often than not. But remember it is your code, and Copilot is your assistant, not your replacement, so take responsibility for what you commit and ship.

Copilot can and does make mistakes, so checkpoint your code frequently so you can roll back, and ensure that you have great unit test coverage (which of course Copilot can help you generate).

Experiment with prompts and models

I love the fact that GitHub Copilot gives you access to a variety of models from Open AI, Anthropic and Google. They are unfortunately confusingly named, making it hard to know which one you're "supposed" to use, but I'd recommend simply experimenting. Switch between models frequently and see which ones give you the best results.

Also, if you're not getting the results you want, consider whether it might be your prompt that is the problem. Don't simply give up after the first attempt. Instead look for ways to be clearer about what you want, and provide additional context to guide it better.

Using Copilot for code review

You can (and should) ask Copilot to review your code, and it will really help if you are explicit about the kinds of thing you are looking for. Do you want suggestions for modernizing, or improving performance? Do you want it to suggest architectural patterns? Not every suggestion it comes back with will be worth acting on, but in my experience it can often come up with some really good ideas.

Using Copilot for planning

If your application uses a legacy technology and you want to modernize it, you might be tempted to see if Copilot can do the whole thing in one shot. But often you'll find that is too ambitious (although maybe that will change with agents).

A better approach is to ask Copilot to come up with a plan. This will give you step by step instructions, and can often include things that you might have overlooked. You can then use Copilot again to help you implement each step of the plan. I was quite impressed with the detail of some of the migration plans it came up with while I was preparing for the course.

Using LLMs for characterization tests

The goal of refactoring is of course to improve the structure of the code, without modifying its functionality. Refactoring is risky because it can introduce bugs, so having thorough unit test coverage is really valuable.

One great thing about Copilot is its willingness to generate tests. A "characterization test" is a test that simply discovers how the code currently behaves, and puts tests in place to ensure that it doesn't change. Copilot can generate these tests, and this gives you a very quick and easy way to roll back or fix a refactoring that introduces regressions.

Using LLMs for performance improvements

One of the topics I covered in the course was using GitHub Copilot for performance enhancements. You can of course just ask it to review your code and ask for performance-related suggestions, and sometimes it will come up with good ideas. But remember that it needs context - it won't automatically know which are the methods in your codebase that get called the most frequently, so supplying that information can help a lot.

In one of my test scenarios, I wanted to validate the performance improvement by using BenchmarkDotNet. Copilot was very quickly able to generate me a new project for performance profiling, and even copied the old implementation into that project so I could get a side-by-side comparison of the improvement with minimal effort.

Summary

Although lots of GitHub Copilot demos focus on the amazing speed with which it can help you bootstrap a new application, that doesn't mean it can't help you on existing legacy codebases (which let's be honest, forms a large part of many of our daily jobs). If you're willing to put in a bit of time to learn how to use these AI tools effectively, you may just find that working on technical debt filled codebases isn't quite as painful as it used to be!