15 October 2026 · A practical fortnightly briefing on .NET, Azure and AI-assisted engineering.
The useful developments this fortnight have a common theme: better engineering tools matter, but the biggest gains come when teams can control how work is executed, verified and recovered. There is plenty of AI noise around; here are the changes I think are actually worth an engineering team’s attention.
.NET 11 RC2 is here — but don’t neglect the versions you’re running
Microsoft shipped .NET 11 Release Candidate 2 on 13 October, with go-live support and improvements across the SDK, MSBuild, ASP.NET Core, NuGet and WinForms. The practical ones to watch include faster MSBuild wildcard evaluation, a NuGet CLI option for minimum package publication age, and new WinForms layout and accessibility work. For teams maintaining desktop-heavy estates, it is worth looking beyond the headline runtime changes.
Just as important, the October servicing releases bring security and reliability fixes for supported .NET and .NET Framework installations. For a business running a mixture of modern .NET and older systems, a reliable patch inventory is more valuable than a rushed framework upgrade. Practical step: verify deployed runtime versions, container base images and your .NET Framework patch process before experimenting with RC2.
C# Dev Kit gets noticeably more useful for large solutions
The C# Dev Kit 11.0 rearchitecture is one of the more tangible developer-productivity stories. In Microsoft’s tests, active-file readiness on large solutions fell from tens of seconds to well under one second, while the extension’s server memory use dropped by roughly 80–85%. Results will vary by solution, but faster project loading and incremental builds should help humans and coding agents alike — particularly when spinning up new worktrees.
Practical step: benchmark your own largest solution on the updated VS Code extension rather than assuming those improvements transfer directly. For a legacy .NET estate, check compatibility before changing the standard development setup.
AI agents need reliable workflows, not endless tool loops
Microsoft’s Azure Functions Hosted Skills Dynamic Workflows preview (8 October) separates agent planning from execution. An LLM produces a constrained task graph; Durable Functions executes it with retries, progress visibility and recovery. The current preview is Python-based, so this is not a new C# feature — but it is an important architectural pattern for .NET teams building Azure systems.
Microsoft also published a useful 12 October guide to Durable Task using approval flows, provisioning, payments, webhooks and incident investigation. Its strongest point: durable orchestration does not make external side effects exactly-once. Your application still owns idempotency, authorization and reconciliation. Practical step: identify workflows that require human approval or survive process restarts; put durable coordination around them, but keep business decisions in deterministic code.
Coding agents are becoming managed engineering systems
GitHub’s dynamic workflows preview lets teams define repeatable, code-driven agent processes with checkpoints and structured hand-offs. Separately, local sandboxing is now generally available across supported Copilot experiences, and the Copilot CLI can discover models from a local Ollama instance. The ability to constrain file, network and credential access matters much more than yet another autonomous demo.
Practical step: choose one repeatable job — perhaps investigating a failed pipeline or preparing a dependency-upgrade PR — and define inputs, permissions, tests and a human review point. Measure accepted changes and review time, not simply how much code an agent produces.
Two concrete security improvements worth acting on
On 14 October, GitHub previewed workflow dependency lockfiles for supported GitHub Enterprise Cloud environments. These lock action references to reviewed commits instead of trusting a mutable tag. And from 13 October, GitHub secret scanning detects additional Anthropic key formats and includes them in push protection by default wherever the feature is enabled.
Practical step: audit third-party CI dependencies and how your team stores AI provider keys. Lockfiles are a defence against changed dependencies, not a guarantee that a dependency was safe in the first place.
A small but important shift: test the agent, not just its output
Microsoft’s Agent Experience Practitioner Playbook (9 October) tackles a common problem: an AI coding agent produces compiling code with the wrong SDK version, deprecated security practices or unsuitable architecture. Its advice is to run realistic evaluations and improve the documentation, tooling and instructions agents consume. This is especially relevant when introducing agents to older applications that have undocumented constraints.
Practical step: create three repository-specific checks for any AI-written change: correct framework and package versions, preserved authorization boundaries, and passing build/tests. A green compile alone is not an acceptance criterion.
From the site
Two longer reads on modernisation remain relevant: Should You Maintain or Rewrite a Legacy .NET Application? and What to Do When the Developer Who Built Your Software Leaves. Both are about reducing delivery risk before choosing the shiny technical answer.
If you’re dealing with an ageing .NET application, an AI-assisted workflow you don’t quite trust, or a repetitive process worth automating, I work with businesses on pragmatic modernisation and software automation. More at peterfrench.dev.
— Peter
