DEV Community: itysu tur

AI-Assisted TDD vs. Pure TDD: I Picked the Iterative Dance

itysu tur — Fri, 05 Jun 2026 11:34:16 +0000

AI-Assisted TDD vs. Pure TDD: I Picked the Iterative Dance

How do you maintain a true test-first discipline when an AI assistant is constantly itching to write the implementation before you've even finished the test? That question gnawed at me for months.

I've been a TDD advocate for years, but the rise of AI coding assistants like GitHub Copilot and Claude Sonnet 4.6 threw a wrench in my process. My usual rhythm of red-green-refactor felt constantly disrupted. I needed a way to leverage the AI without losing the benefits of TDD, especially on a new .NET 9 project I was kicking off. I wanted a true ai tdd dotnet workflow, not just AI generating code around my tests.

My Initial Missteps and the 'Premature Implementation' Trap

Honestly, my first attempts at integrating AI into my TDD cycle were a mess. I'd typically prompt something like, "Write a C# 13 method to reverse a string, then write a unit test for it." And almost every time, the AI—whether it was Copilot's inline suggestion or a full response from Claude Opus 4.7 in Cursor 0.42—would spit out the implementation first, then a test that simply confirmed its own code. It wasn't TDD; it was "implementation-driven development with a side of AI-generated validation."

This felt like cheating, or at best, missing the point. The value of TDD, for me, lies in defining behavior before coding, letting the tests guide the design. When the AI gives you the answer upfront, that crucial design step is skipped. I might be wrong about this, but for me, the magic of TDD is in the constraint, the thinking it forces. The AI's eagerness to complete the thought was a constant hurdle.

Here’s a simplified version of what I kept getting, and what I was actively trying to avoid:

// My initial prompt (mental or explicit): "I need a method to safely parse an int from a string."
// AI's eager response, often before I've even thought of edge cases:
public static class StringParser
{
    public static int ParseIntOrDefault(string input, int defaultValue = 0)
    {
        if (int.TryParse(input, out int result))
        {
            return result;
        }
        return defaultValue;
    }
}

// And then, a test for it, which is useful but didn't guide the *design*:
[TestFixture]
public class StringParserTests
{
    [Test]
    public void ParseIntOrDefault_ValidInput_ReturnsParsedValue()
    {
        Assert.That(StringParser.ParseIntOrDefault("123"), Is.EqualTo(123));
    }

    [Test]
    public void ParseIntOrDefault_InvalidInput_ReturnsDefault()
    {
        Assert.That(StringParser.ParseIntOrDefault("abc"), Is.EqualTo(0));
    }
}

The implementation was often fine, but it bypassed my brain's TDD muscle memory. I was constantly running into this "premature implementation" trap.

The Rhythm I Found: Test-First Prompts

It took me an embarrassing amount of time to figure out: I needed to treat the AI like a highly capable, but literal, junior developer who needed very specific instructions. The key was to constrain the AI to only generate the test, and then, once I'd seen it fail, to ask for the implementation. This became my core tdd ai pair strategy.

What I ended up with was a two-stage prompting approach, primarily using Cursor 0.42's chat for the initial test generation and then Visual Studio 2026 with Copilot for quick completions on the implementation.

First, I'd prompt for the test, often specifying C# 13 and .NET 9 context:

"I'm working in C# 13 with .NET 9. I need a unit test for a new static method `GuidUtils.IsValidGuid(string s)`.
It should handle null, empty, invalid format strings, and a valid GUID. Focus ONLY on the test, no implementation."

Claude Sonnet 4.6 would then give me something wonderfully focused like this, which I'd drop into my test project:

using NUnit.Framework;
using System;

[TestFixture]
public class GuidUtilsTests
{
    [Test]
    public void IsValidGuid_NullString_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid(null), Is.False);
    }

    [Test]
    public void IsValidGuid_EmptyString_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid(""), Is.False);
    }

    [Test]
    public void IsValidGuid_InvalidFormat_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid("not-a-guid"), Is.False);
    }

    [Test]
    public void IsValidGuid_ValidGuid_ReturnsTrue()
    {
        Assert.That(GuidUtils.IsValidGuid(Guid.NewGuid().ToString()), Is.True);
    }
}

I'd run the tests, watch them all fail (red!), and then I'd prompt the AI for the implementation, often feeding it the failing test code as context, or just referencing the method signature:

"Implement the `GuidUtils.IsValidGuid` method in C# 13 to make the above tests pass. Keep it efficient."

And then, the AI would provide the minimal code to get to green:

using System;

public static class GuidUtils
{
    public static bool IsValidGuid(string s)
    {
        return Guid.TryParse(s, out _);
    }
}

This felt like genuine test driven ai. I was still driving the behavior definition, and the AI was an incredible accelerator for getting to the green state.

Where I'm Still Tweaking: Refactoring and Edge Cases

So, where am I now? I'm firmly in the camp of ai tdd pair as a viable, productive workflow. My test suites are growing faster, and I'm catching more edge cases upfront because the AI is so good at suggesting test scenarios. It’s particularly strong for utility methods and well-defined algorithms.

However, the journey isn't over. Refactoring, for instance, is still a tricky area. While I can prompt the AI to "refactor this C# method to improve readability," it often suggests a full rewrite based on patterns rather than an incremental, behavior-preserving refactor that I'd typically do with TDD. I find myself doing more of the refactoring manually, using the AI more for brainstorming ideas for refactorings rather than the actual code changes. Also, for complex domain logic with subtle business rules, I still often write the first few tests myself to truly embed my understanding. Your mileage may vary, but for me, the test generation part remains the biggest win.

The biggest remaining challenge for me is leveraging AI for complex domain modeling during the design phase, before any code or tests are written.

If you've tried to pair TDD with AI in a .NET context, especially for refactoring existing codebases, I'd love to hear what broke or what surprising workflows you discovered.

AI Agents Cut My .NET Debug Time by 30% — But Not How I Expected

itysu tur — Thu, 04 Jun 2026 10:42:20 +0000

AI Agents Cut My .NET Debug Time by 30% — But Not How I Expected

I closed the laptop at 2am after my third failed migration attempt, staring at a NullReferenceException that just shouldn't be there. Debugging legacy .NET 6 code after a .NET 9 upgrade, especially with a few tricky interop layers, has been draining. I'd been hearing about the new wave of ai agents dotnet tools, specifically the multi-step reasoning capabilities, and honestly, I was cynical. My prior attempts with "AI assistants" often felt like glorified search engines. But that particular Tuesday night, something had to give. I needed a different approach to untangle these gnarly dependency issues.

My goal wasn't to replace myself, but to offload the tedious, repetitive "check this, then check that" debugging loops that eat up hours. I wanted an agentic ai 2026 solution that could actually act on code, not just suggest it. The idea of a small, focused agent capable of inspecting project files, running tests, and even modifying code based on a goal, sounded like a pipe dream. Yet, the promise of automating the initial diagnostic steps for complex csharp ai agents interactions kept nagging at me.

The Agentic "Aha!" Moment: Context is King

My initial attempts involved throwing entire solution folders at large language models via the new Copilot for Workspaces in Visual Studio 2026. Predictably, it was a mess. The models got lost, hallucinated file paths, or just gave generic advice. It wasn't until I started thinking like a human debugger – focusing on specific files and immediate context – that things changed. I needed an agent that could reason about its environment, not just consume a massive blob of text.

What finally clicked for me was using a specialized agent running on Claude Opus 4.7, orchestrated via a simple C# 13 console app. This agent's primary tool was a FileInspector which could read specific files and a DotNetRunner that could execute dotnet test or dotnet build commands. The prompt was crucial: I didn't ask it to "fix the bug," but to "investigate the NullReferenceException in LegacyService.cs related to DependencyX after the .NET 9 upgrade." This gave it a concrete starting point.

Here's a simplified version of the tool definition I gave my agent, using the emerging Model Context Protocol (MCP) for C# tools:

// Simplified representation of an agent tool definition
public class FileInspectorTool
{
    [ToolDescription("Reads the content of a specified file.")]
    public string ReadFile(
        [ParameterDescription("The path to the file to read.")]
        string filePath)
    {
        if (File.Exists(filePath))
        {
            return File.ReadAllText(filePath);
        }
        return $"Error: File not found at {filePath}";
    }
}

public class DotNetRunnerTool
{
    [ToolDescription("Executes a dotnet CLI command and returns its output.")]
    public string RunDotNetCommand(
        [ParameterDescription("The dotnet command arguments (e.g., 'test', 'build --no-restore').")]
        string arguments)
    {
        // In a real scenario, this would execute a process and capture stdout/stderr
        return $"Simulated: dotnet {arguments} output...";
    }
}

The agent would then autonomously decide to ReadFile on LegacyService.cs, see the usage of DependencyX, then perhaps RunDotNetCommand("build --no-restore") to check for compilation errors, and so on. This iterative, tool-driven approach was game-changing for narrowing down issues. It wasn't perfect, but it dramatically cut down the initial legwork.

The Overhead and The "Gotcha": Orchestration Complexity

While the concept of ai agents dotnet proved powerful, the journey wasn't without its bumps. My biggest "gotcha" wasn't the AI itself, but the sheer complexity of agent orchestration. Initially, I tried to make a single, monolithic agent that could do everything. This led to decision paralysis for the model and slow, expensive interactions.

The key learning for me was to embrace specialized agents. Instead of one "super-agent," I ended up with a small team:

Issue Triage Agent: (Claude Haiku 4.5) Quick, cheap, and good at scanning logs or error messages, then deciding which specialized agent to hand off to.
Code Analysis Agent: (Claude Sonnet 4.6) Deeper code inspection, understanding design patterns, suggesting refactors.
Test Execution Agent: (Custom C# agent) Focused solely on running specific dotnet test commands and reporting results.

This multi-agent architecture, though more complex to set up, provided far superior results. My local setup, primarily in Visual Studio 2026 and Rider 2026, involves a small C# orchestrator that manages tool registration for each agent and routes requests. The biggest challenge here was ensuring proper context flow between agents – passing relevant file paths, error messages, or previous analysis results without overwhelming the next agent. I also found that giving agents a "scratchpad" (a temporary file they could write notes to) significantly improved their multi-step reasoning, as they could externalize their thoughts. It took me an embarrassing amount of time to figure out that just dumping all prior conversational turns into the next agent's prompt was a recipe for disaster.

For instance, if the Triage Agent spotted a potential EF Core issue, it would hand off to the Code Analysis Agent with a prompt like:

[AGENT_MESSAGE]
Context: A NullReferenceException was found in LegacyService.cs.
Suspected Area: Entity Framework Core query in DataAccessLayer.cs.
Goal: Analyze DataAccessLayer.cs for potential EF Core lazy-loading or include-related issues causing the NRE.

This explicit context passing, rather than relying on a shared history, made all the difference in getting reliable agentic ai 2026 behavior. Your mileage may vary, but for my specific .NET ecosystem, this separation of concerns was crucial.

I'm still figuring out the best ways to integrate these ai agents dotnet workflows into my daily .NET 9 development. The initial setup had a steep learning curve, and the cost of powerful models like Claude Opus 4.7 can add up if you're not careful with prompt engineering. Right now, I'm focusing on refining the orchestration for more complex refactoring tasks.

If you've built specialized C# agents for automated debugging or refactoring, especially in a distributed microservices environment, I'd love to hear what surprising limitations or breakthroughs you've encountered.

How I Stopped Fighting AI on Legacy .NET Code

itysu tur — Wed, 03 Jun 2026 11:32:09 +0000

How I Stopped Fighting AI on Legacy .NET Code

My workflow before modern AI tools felt like a constant cycle of context switching. I’d spend half my day digging through solution explorer, jumping between files to understand dependencies, and manually writing boilerplate. Debugging meant stepping through code line by line, often guessing at the root cause of an issue in a complex .NET Framework 4.8 service that’s been around for over a decade.

Now, with tools like GitHub Copilot for Workspaces and Claude Opus 4.7 integrated into Visual Studio 2026 and Rider 2026, things are different. Boilerplate code, initial test drafts, even explaining obscure C# 13 syntax – AI handles it. The friction of starting a new feature or understanding a small, isolated module has drastically reduced. Yet, this new efficiency introduced a different kind of friction, a subtle battle against a tool that often thinks it knows more than it does about my specific codebase.

AI's Blind Spot for Architectural Nuance

I quickly learned that AI, even the latest models like Claude Sonnet 4.6, struggles significantly with deep architectural context. It's fantastic at localized code generation and refactoring within a single file or a tightly coupled pair. But ask it to understand a cross-cutting concern in a multi-project solution, or to refactor a service layer that has evolved over years, and its suggestions often fall flat. For me, this was particularly evident when dealing with our primary legacy .NET 9 service, which uses a custom event-driven architecture that predates many modern patterns.

Last Tuesday, I was trying to refactor a PaymentProcessor interface and its implementations across three different projects. I fed the entire solution structure and relevant files into Cursor 0.42+, expecting it to grasp the implicit domain knowledge. It generated a clean, modern C# 13 interface and abstract base class, but completely missed the mark on how our custom message bus integrated with the PostProcess method, suggesting a direct dependency injection where a MediatR notification was expected. It was syntactically perfect, but architecturally wrong.

// AI's initial suggestion, trying to refactor PaymentProcessor
// This looks clean, but completely misses our internal message bus integration
public class StripePaymentProcessor : IPaymentProcessor
{
    private readonly ILogger<StripePaymentProcessor> _logger;
    // AI missed that we don't directly inject IMessageBus here, 
    // but rather publish events via a MediatR notification handler.
    // private readonly IMessageBus _messageBus; 

    public StripePaymentProcessor(ILogger<StripePaymentProcessor> logger /*, IMessageBus messageBus */)
    {
        _logger = logger;
        // _messageBus = messageBus;
    }

    public async Task<PaymentResult> ProcessAsync(PaymentRequest request)
    {
        _logger.LogInformation("Processing Stripe payment for {Amount}", request.Amount);
        // ... Stripe API calls ...
        // AI suggested: await _messageBus.Publish(new PaymentProcessedEvent(request.OrderId));
        // What we actually needed was a MediatR notification:
        // await _mediator.Publish(new PaymentProcessedNotification(request.OrderId));
        return new PaymentResult(true, "Stripe payment successful");
    }
}

The issue isn't that AI can't generate code; it's that it lacks the deep, implicit understanding of why certain design decisions were made years ago. It doesn't know the historical context, the trade-offs, or the specific business rules that shaped the architecture. This is where ai csharp limitations truly show. I've found it helps to provide extremely verbose context about architectural patterns and internal conventions, but even then, it's a constant battle of correction.

Debugging the Unseen: Environment-Specific Failures

Another area where I consistently hit ai coding limits is debugging environment-specific issues. AI models, even those with advanced MCP (Model Context Protocol) capabilities, are trained on vast datasets of common code patterns and public documentation. They are fantastic at identifying syntax errors, suggesting common exceptions, or even pinpointing potential race conditions in well-known frameworks. But when a bug manifests only in a specific Kubernetes cluster running .NET 10 Preview, or due to a subtle interaction with a third-party library's native dependency, AI often provides generic, unhelpful advice.

I spent three days chasing a System.Net.Http.HttpRequestException last month that only occurred when our service was deployed to our staging environment. Copilot Edits kept suggesting network connectivity issues or incorrect base URLs. Claude Opus 4.7, when fed the stack trace and relevant code, would hallucinate about proxy configurations that didn't exist in our setup. It took me an embarrassing amount of time to figure out it was a specific TLS 1.3 negotiation issue with an outdated load balancer firmware version in staging – something completely external to the code itself.

# My desperate prompt to Claude Opus 4.7 after 2 days
# Claude's response was a generic list of HTTP client best practices.
# It couldn't 'see' the environment.
You are debugging an ASP.NET Core 9.0 service.
It throws System.Net.Http.HttpRequestException: 'The SSL connection could not be established'
This ONLY happens in our staging Kubernetes cluster, not local dev or UAT.
The target is an external vendor API.
I've verified DNS, firewall rules, and API key.
What are less obvious causes for this specific environment-dependent SSL failure?

# Snippet of the actual error log from K8s, which AI struggled to interpret accurately.
# It often focused on app code, not infrastructure.
---
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
    ---> System.Security.Cryptography.X509Certificates.X509Chain+ChainAix.BuildChain(X509Certificate2 certificate, X509Certificate2Collection extraStore, X509RevocationMode revocationMode, X509RevocationFlag revocationFlag, X509VerificationFlags verificationFlags, DateTime verificationTime, X509ChainStatus[]& chainStatus)
    at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ReadOnlySpan`1 alert)
    at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean is renegotiation, CancellationToken cancellationToken)
    at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
---

This is where ai fails dotnet developers who work on complex, distributed systems. The AI lacks the "eyes" to observe the runtime environment, the network conditions, or the specific configuration of a particular deployment. It can only reason about the code it sees, not the complex interplay of factors outside the repository. Your mileage may vary, but for me, environment-specific debugging remains a deeply human task.

I'm still figuring out the optimal dance between letting AI take the lead and knowing when to trust my own intuition and experience. It's clear that AI is a powerful accelerator for many tasks, but its understanding of architectural intent and unseen environmental factors is still nascent.

If you've encountered similar limitations with AI tools when tackling legacy .NET code or subtle environment-specific bugs, I'd love to hear what strategies you've found effective.

5 Surprises Migrating .NET Framework to .NET 9 with Claude Opus

itysu tur — Tue, 02 Jun 2026 10:25:42 +0000

5 Surprises Migrating .NET Framework to .NET 9 with Claude Opus

My workflow before this little experiment was pretty standard for a .NET Framework to .NET 9 migration: open Visual Studio 2026, create a new SDK-style project, copy over files, then hit a wall of red squiggles. I'd spend hours manually updating csproj files, hunting down modern equivalents for System.Web or ConfigurationManager, and constantly flipping between documentation, Stack Overflow, and my IDE. It was a grind of context switching and often, just plain guessing.

Now, my initial pass looks wildly different. I'm still in Visual Studio 2026 or Rider 2026, but the first step involves feeding the entire legacy project structure and relevant code files into Claude Opus 4.7. I'm prompting it to generate the new csproj, suggest initial code changes, and even outline a migration plan. The red squiggles still appear, but they're a starting point for refinement, not a blank canvas of despair. It’s like having a hyper-competent, slightly over-confident junior dev do the grunt work, and I get to be the architect, reviewing and correcting.

Honestly, I was skeptical. Our team has a decent-sized .NET Framework 4.8 web service – nothing ancient, but definitely showing its age with some custom configuration and a reliance on System.Web for various utility functions. The goal was to bring it to .NET 9 (with C# 13, naturally) to leverage modern performance and features. I figured this was a prime candidate to see if ai migration dotnet could actually deliver, or if it was just hype.

What Claude Opus 4.7 Got Right (and Wrong) About the Initial Lift

My first real test was feeding Claude Opus 4.7 an entire solution structure, including a csproj file and a few core C# files, asking for a net framework to net 9 conversion. What surprised me was how well it handled the basic csproj upgrade. It correctly identified target frameworks, package references, and even most of the ItemGroup changes. Honestly, I expected this to fail completely on the first pass, but the generated SDK-style project file was a solid foundation.

<!-- Initial prompt to Claude Opus 4.7 -->
<prompt>
I have a .NET Framework 4.8 C# project. Please convert this csproj to an SDK-style .NET 9 csproj. 
Also, review the provided C# code files and suggest initial changes for .NET 9 compatibility, focusing on common System.Web and ConfigurationManager replacements.

<csproj_content>
  <Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
    <PropertyGroup>
      <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
      <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
      <ProjectGuid>{ABCDEF-1234-5678-90AB-CDEF12345678}</ProjectGuid>
      <OutputType>Library</OutputType>
      <AppDesignerFolder>Properties</AppDesignerFolder>
      <RootNamespace>MyLegacyService</RootNamespace>
      <AssemblyName>MyLegacyService</AssemblyName>
      <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
      <FileAlignment>512</FileAlignment>
    </PropertyGroup>
    <ItemGroup>
      <Reference Include="System" />
      <Reference Include="System.Configuration" />
      <Reference Include="System.Web" />
      <!-- ... other references ... -->
    </ItemGroup>
    <ItemGroup>
      <Compile Include="MyService.cs" />
      <!-- ... other compiles ... -->
    </ItemGroup>
    <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  </Project>
</csproj_content>

<file_content name="MyService.cs">
  using System.Configuration;
  using System.Web;
  using System.Collections.Generic;

  namespace MyLegacyService
  {
      public class MyService
      {
          public string GetConfigValue()
          {
              return ConfigurationManager.AppSettings["MyKey"];
          }
          public Dictionary<string, string> GetRequestHeaders()
          {
              var headers = new Dictionary<string, string>();
              if (HttpContext.Current != null)
              {
                  foreach (string key in HttpContext.Current.Request.Headers.AllKeys)
                  {
                      headers.Add(key, HttpContext.Current.Request.Headers[key]);
                  }
              }
              return headers;
          }
      }
  }
</file_content>
</prompt>

<!-- Claude's (edited for brevity) initial response for MyService.cs -->

csharp
// Claude's suggested MyService.cs changes
// Note: This is a starting point, manual integration with IConfiguration and DI is needed.
using Microsoft.Extensions.Configuration; // Added
using Microsoft.AspNetCore.Http; // For HttpContext replacement (assuming ASP.NET Core)
using System.Collections.Generic;

namespace MyLegacyService // Namespace retained, assuming project structure
{
public class MyService
{
// Placeholder for IConfiguration injection
private readonly IConfiguration _configuration;
private readonly IHttpContextAccessor _httpContextAccessor; // For HttpContext access

    public MyService(IConfiguration configuration, IHttpContextAccessor httpContextAccessor) // Added constructor
    {
        _configuration = configuration;
        _httpContextAccessor = httpContextAccessor;
    }

    public string GetConfigValue()
    {
        // Replaced ConfigurationManager.AppSettings
        return _configuration["MyKey"]; 
    }

    public Dictionary<string, string> GetRequestHeaders()
    {
        var headers = new Dictionary<string, string>();
        if (_httpContextAccessor.HttpContext != null)
        {
            foreach (var header in _httpContextAccessor.HttpContext.Request.Headers)
            {
                headers.Add(header.Key, header.Value.ToString());
            }
        }
        return headers;
    }
}

}

Where it stumbled, predictably, was on the deeper integration patterns. It correctly identified `ConfigurationManager.AppSettings` needed to go but replaced it with a direct `IConfiguration` access without considering dependency injection or how that `IConfiguration` instance would actually *get* there in a new ASP.NET Core project. Similarly, for `HttpContext.Current`, it pointed to `IHttpContextAccessor`, which is the right path, but again, didn't provide the full DI setup. It was a strong hint, but not a drop-in solution. The **context of *how* an ASP.NET Core app is structured** was missing from its initial understanding, which is fair given I only fed it code, not architecture.

## The Iterative Dance: Prompting for Nuances and Dependencies

This is where the real `claude migration` magic, or rather, the iterative process, began. Instead of asking for a full conversion, I started focusing on specific problem areas. For instance, a common pattern in our legacy code was accessing `ConfigurationManager` in static helper classes. I couldn't just inject `IConfiguration` into a static class. Took me an embarrassing amount of time to figure out the right prompt to get Claude to suggest a factory pattern or a service locator *only for that specific legacy scenario* that I could then refactor later.

prompt
My .NET 9 project uses Dependency Injection. I have a static utility class 'LegacyConfigHelper' that currently accesses ConfigurationManager.AppSettings. How can I refactor this static class to use IConfiguration from DI, or provide a suitable pattern for accessing configuration in a static context without violating DI principles in a modern ASP.NET Core 9 application? Provide a code example.

// Claude's suggested pattern for static configuration access (simplified)
using Microsoft.Extensions.Configuration;
using System;

namespace MyLegacyService
{
    public static class LegacyConfigHelper
    {
        private static IConfiguration _configuration;

        // This method should be called once at application startup (e.g., in Program.cs)
        public static void Initialize(IConfiguration configuration)
        {
            _configuration = configuration ?? throw new ArgumentNullException(nameof(configuration));
        }

        public static string GetLegacySetting(string key)
        {
            if (_configuration == null)
            {
                throw new InvalidOperationException("LegacyConfigHelper has not been initialized. Call Initialize() at startup.");
            }
            return _configuration[key];
        }
    }
}

// In Program.cs (or similar startup file for an ASP.NET Core app):
// var builder = WebApplication.CreateBuilder(args);
// // ... other services ...
// var app = builder.Build();
// LegacyConfigHelper.Initialize(app.Configuration); // Call this after build, before run
// app.Run();

This pattern, while not ideal long-term, gave me a bridge. It allowed me to get the application compiling and running with dotnet build quickly, deferring a full refactor of those static helpers. I found that providing a small, focused code block and a very specific problem description yielded far better results than dumping large files. Your mileage may vary, but for me, this granular approach to ai migration dotnet was key. I also started using Copilot Edits within Visual Studio 2026 for smaller, in-file refactors after Claude had done the heavy lifting.

The Setup I Settled On for Debugging and Refinement

My final setup involved Visual Studio 2026 as the primary IDE for debugging and running tests, especially with the new C# 13 features. For larger refactors or when I needed to give Claude more context than a single file, I'd use Cursor 0.42+. Cursor's ability to "chat with your codebase" by indexing multiple files and providing a larger context window (leveraging MCP, Model Context Protocol, for Claude Opus 4.7) was invaluable. I could ask it to find all usages of a particular System.Web method and suggest replacements across the entire project, which was far more efficient than manual searching.

When I had a chunk of code that Claude had transformed, my process was to paste it into Visual Studio, let Copilot Edits suggest minor syntax fixes, and then immediately run the existing unit tests (which I was also migrating and updating with Claude's help).

# Example of running tests to validate a migration step
# Assuming you've created a test project for your migrated service
cd MyMigratedService.Tests
dotnet test --filter "Category=MigrationTests & Priority=High"

This rapid feedback loop was critical. I screwed this up by initially trusting Claude's output too much without immediate validation. Last Tuesday, I was debugging a seemingly correct IConfiguration access that was always returning null, only to realize Claude had suggested a GetSection call that didn't match my appsettings structure. A quick dotnet test would have caught that immediately if I'd written a test for it (which I then did). I'm still figuring out the best way to leverage Copilot for Workspaces alongside Claude's larger refactors, but the combination of broad strokes from Claude and fine-grained assistance from Copilot is proving powerful.

The service is now mostly running on .NET 9, albeit with a few LegacyConfigHelper instances I'm still planning to eliminate. The biggest remaining challenge is a complex custom serialization library that relies heavily on reflection patterns that changed between .NET Framework and .NET 9.

If you've tried using AI models like Claude or Copilot for Workspaces to migrate a substantial .NET Framework project to .NET 9, I'd love to hear about your biggest gotchas or unexpected wins.

3 Unexpected Ways Copilot Edges CodeWhisperer for .NET 9 Devs

itysu tur — Mon, 01 Jun 2026 10:31:02 +0000

3 Unexpected Ways Copilot Edges CodeWhisperer for .NET 9 Devs

I processed over 2,000 lines of legacy C# last month, untangling years of technical debt in a crucial microservice. It was a grind, and honestly, the thought of doing it without some AI assistance felt like going back to the stone age. My team’s been using GitHub Copilot for Workspaces for a while, and it’s become indispensable for our .NET 9 projects. But with all the buzz around Amazon CodeWhisperer's recent C# model updates and its deep integration into AWS services, I started to wonder if we were missing out. For a couple of weeks, I decided to run both in parallel in Visual Studio 2026 and Rider 2026, specifically looking at their ai code completion csharp capabilities.

My Initial Jitters and Basic Completion

Setting up both was straightforward enough. Copilot for Workspaces was already active, and CodeWhisperer's plugin for Visual Studio 2026 (or Rider 2026) installed without a hitch. My first impression, especially when writing new methods or simple classes, was that Copilot felt more organic. It would often suggest completions that extended naturally from my variable names or comments. CodeWhisperer, on the other hand, sometimes felt a little too eager to complete an entire method or class with boilerplate that wasn't quite what I needed, often requiring more backspacing than actual coding.

For example, when I was creating a simple DTO, Copilot would usually give me property names that made sense in the context of the surrounding code. CodeWhisperer, especially in a fresh file, would sometimes just dump a generic public class MyClass { public int Id { get; set; } ... } which was rarely useful. I found myself hitting Esc more often with CodeWhisperer. It took me an embarrassing amount of time to realize I needed to be much more explicit with my initial code or comments for CodeWhisperer to grasp the intent.

// Scenario: Creating a new DTO for a user profile update request
// Copilot often suggests relevant properties based on common patterns.
public class UserProfileUpdateRequest
{
    public Guid UserId { get; set; }
    public string FirstName { get; set; } // Copilot often suggests LastName, Email right after
    public string LastName { get; set; }
    public string Email { get; set; }
    // ...
}

// CodeWhisperer, without much context, might be more generic or verbose initially.
// It often felt like I had to type more of the structure before it "understood".
// Example of a prompt I'd type, then CodeWhisperer might try to complete:
// public class UserProfileUpdateRequest
// {
//     public string Username { get; set; }
//     public string Password { get; set; } // Less relevant for a *profile update*
//     // ...
// }

Where Contextual Understanding Made the Difference

This is where the copilot vs codewhisperer debate really started to resolve for me. I spend a lot of time in existing, often sprawling, C# applications. Copilot for Workspaces, especially with its expanded context window, felt like it had a much better grasp of the surrounding files and the overall project structure. When I was refactoring a particularly gnarly service class, Copilot would offer suggestions that actually adhered to the existing naming conventions and patterns within that specific codebase, even if they were a bit idiosyncratic.

Last Tuesday, I was debugging a 500-line method (yes, really) that handled complex business logic. My goal was to extract a few helper methods. Copilot consistently suggested method signatures and implementations that fit the existing data flow and object types. CodeWhisperer, powered by its latest C# model, often proposed entirely new approaches or introduced types that weren't present, forcing me to re-type or discard its suggestions. It felt like CodeWhisperer was trying to give me "best practice" code rather than "this project's practice" code. Honestly, I expected CodeWhisperer to be better at this, given Amazon's scale, but for legacy code, it just wasn't as effective for me.

// Original problematic code snippet (simplified for brevity)
public async Task<Result> ProcessOrderAsync(OrderRequest request)
{
    // ... many lines of validation and data fetching ...

    if (request.IsSpecialOrder)
    {
        // Complex logic for special orders, ~100 lines
        // Copilot would suggest: "Extract SpecialOrderValidation(request)"
        // CodeWhisperer often suggested: "Create new SpecialOrderProcessor.Process(request)"
        // which wasn't quite what I was going for.
    }
    else
    {
        // Regular order processing
    }

    // ... more logic ...
}

// Copilot's helpful suggestion for extraction within the existing class:
// (User types 'private bool IsValidSpecialOrder(OrderRequest request)' and Copilot fills)
private bool IsValidSpecialOrder(OrderRequest request)
{
    // Check specific conditions for special orders
    // ...
    return true;
}

The Ecosystem Play and My Final Setup

Beyond raw code completion, the ecosystem integration was a significant factor. As a heavy GitHub user, Copilot for Workspaces integrates seamlessly with my pull requests, code reviews, and even suggests changes based on my team's coding standards pulled from our repositories. I'm still figuring out how to fully leverage Copilot Edits for multi-file changes, but the potential is huge. CodeWhisperer, naturally, shines when you're deeply embedded in the AWS ecosystem. If I were building a new serverless application on AWS Lambda with .NET 9, I could see CodeWhisperer's direct integration with AWS SDKs and services being a massive time-saver. It automatically suggests code for connecting to S3, DynamoDB, and other services, which is incredibly powerful if that's your stack.

For my current work, which involves a mix of legacy on-prem and modern Azure-hosted microservices, Copilot’s broader contextual understanding and integration with GitHub felt more aligned. Your mileage may vary, especially if AWS is your primary cloud provider. What I ended up doing was keeping Copilot for Workspaces as my primary ai code completion csharp tool, mainly because its suggestions required less correction in my daily workflow. I still have CodeWhisperer installed, but I disable it by default and only enable it when I'm specifically working on a new AWS-centric project where I know its specialized knowledge will be an advantage.

# How I toggle CodeWhisperer in Visual Studio 2026 (simplified representation)
# In reality, this is done via Extensions -> Manage Extensions, or a specific CodeWhisperer menu.
# This shell command is illustrative of the intent.
# My preference is to have Copilot active by default.

# Example: Disable CodeWhisperer globally for general .NET development
# (simulated via CLI, actual UI interaction in VS/Rider)
# aws codewhisperer disable-extension --profile my-dev-profile

# Example: Enable CodeWhisperer when starting a new AWS-specific project
# aws codewhisperer enable-extension --profile my-dev-profile

I'm currently running Copilot for Workspaces alongside C# 13 in Visual Studio 2026. While CodeWhisperer has certainly improved, for now, Copilot provides a smoother, more context-aware experience across the diverse C# projects I juggle. I’m still figuring out how to best integrate AI tools for high-level architectural suggestions rather than just code completion.

If you've run both GitHub Copilot and Amazon CodeWhisperer on complex legacy C# codebases, I'd love to hear what specific challenges or triumphs you encountered.

Is AI-Native .NET Development Actually Happening in 2026?

itysu tur — Sun, 31 May 2026 12:48:02 +0000

Is AI-Native .NET Development Actually Happening in 2026?

Honestly, I'd been dipping my toes into AI for coding for a while, mostly with basic Copilot completions, but it felt more like a novelty. Then, last Tuesday, my teammate Mark mentioned how he'd been using Copilot Edits in Visual Studio 2026 to refactor some gnarly .NET Framework 4.8 code into modern .NET 9. I was skeptical. I mean, really? An AI doing proper legacy refactoring? But he insisted it saved him hours on a particularly stubborn module. That's what finally pushed me to dedicate two weeks to really integrating AI into my daily .NET workflow. I wanted to see if this ai dotnet 2026 buzz was just hype or if it was genuinely changing how we build software.

The IDE as a new copiloted workspace

What I quickly learned was that the landscape has shifted dramatically since I last paid close attention. It's no longer just about generating a single line of code. Both Visual Studio 2026 and Rider 2026 have deeply integrated Copilot for Workspaces and Copilot Edits, making the IDE itself feel like a collaborative partner. For me, the biggest win was using Copilot Edits for C# 13 language feature adoption. I'd highlight a block of older code, hit Alt+C, and prompt for "Convert to C# 13 primary constructor and use ArgumentOutOfRangeException.ThrowIfNegativeOrZero." It wasn't perfect every time; sometimes it would miss an edge case or suggest something overly complex, but it got me 80% of the way there, often better than I'd have done manually in the same time.

Here’s a quick example of a common scenario where Copilot Edits helped me out:

// Before Copilot Edits
public class ProductService(ILogger<ProductService> logger)
{
    private readonly IProductRepository _repository = new ProductRepository(); // Bad practice!

    public async Task<Product> GetProductByIdAsync(int id)
    {
        if (id <= 0)
        {
            logger.LogError("Invalid product ID: {Id}", id);
            throw new ArgumentException("Product ID must be positive.", nameof(id));
        }
        return await _repository.GetByIdAsync(id);
    }
}

// After Copilot Edits prompt: "Fix repository instantiation, use C# 13 ThrowIfNegativeOrZero"
public class ProductService(IProductRepository repository, ILogger<ProductService> logger) // Injected repository
{
    public async Task<Product> GetProductByIdAsync(int id)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(id, nameof(id)); // C# 13 helper
        return await repository.GetByIdAsync(id);
    }
}

This wasn't just about syntax; it was about moving towards a more idiomatic future of dotnet codebase, nudging me to fix dependency injection issues I might have overlooked. Your mileage may vary, but I found it incredibly useful for cleaning up debt.

Beyond the IDE: Custom AI agents for .NET 9

Where things got really interesting for me was using external AI models, specifically Claude Sonnet 4.6 (and sometimes Opus 4.7 for more strategic tasks), to generate entire feature prototypes. My team often needs to spin up new minimal API endpoints for .NET 9 services, and the boilerplate can be tedious. I'm still figuring out the best way to prompt, but what I ended up with was a structured approach using a custom agent that understands our existing architectural patterns. It took me an embarrassing amount of time to figure out how to give it enough context without overwhelming it.

My process involved defining our common interfaces and data models, then asking Claude to generate an endpoint. The key was using the Model Context Protocol (MCP) to explicitly define the context schema, so I could feed it IProductRepository and ProductDto definitions directly.

Here’s an example of a prompt I used and a snippet of the response for a new product endpoint:

Prompt for Claude Sonnet 4.6:

"Generate a C# 13 minimal API endpoint using .NET 9.
The endpoint should handle POST requests to '/products'.
It needs to:
1. Accept a `ProductDto` from the request body.
2. Inject `IProductRepository` and `ILogger<ProductEndpoint>` via the primary constructor.
3. Validate `ProductDto.Name` for null/whitespace.
4. Map `ProductDto` to a `Product` entity.
5. Use `IProductRepository` to add the new `Product`.
6. Return a `Results.CreatedAtRoute` response, linking to a hypothetical 'GetProductById' route.
7. Include `.WithName` and `.Produces` for OpenAPI documentation.

Assume the following types are available:
public record ProductDto(string Name, decimal Price);
public class Product { public int Id { get; set; } public string Name { get; set; } public decimal Price { get; set; } }
public interface IProductRepository { Task AddProductAsync(Product product); }
"

// Claude Sonnet 4.6 Response (snippet for app.MapPost)
app.MapPost("/products", async (ProductDto productDto, IProductRepository repo, ILogger<ProductEndpoint> logger) =>
{
    if (string.IsNullOrWhiteSpace(productDto.Name))
    {
        logger.LogWarning("Product creation failed due to empty name.");
        return Results.BadRequest(new { error = "Product name cannot be empty." });
    }

    var product = new Product { Name = productDto.Name, Price = productDto.Price };
    await repo.AddProductAsync(product);
    logger.LogInformation("Created new product with ID: {ProductId}", product.Id);

    return Results.CreatedAtRoute("GetProductById", new { id = product.Id }, product);
})
.WithName("CreateProduct")
.Produces<Product>(StatusCodes.Status201Created)
.Produces(StatusCodes.Status400BadRequest);

This wasn't just about saving typing; it was about ensuring consistency with our existing patterns and quickly generating a fully-fledged, runnable starting point. It's a significant shift in the csharp future workflow.

After these two weeks, I'm genuinely impressed. The future of dotnet development, at least for me, involves a lot more AI collaboration than I anticipated. I'm still trying to figure out how to integrate these custom AI agents into our CI/CD pipeline for automated code generation, but the potential is clear.

If you've managed to integrate AI agents into your CI/CD pipeline for .NET 9, especially for generating and validating code, I'd love to hear about your setup and any roadblocks you hit.

How Fixing My AI Coding Pitfalls Rescued My .NET Development Time

itysu tur — Sat, 30 May 2026 07:26:25 +0000

How Fixing My AI Coding Pitfalls Rescued My .NET Development Time

Everyone talks about AI tools as a productivity superpower, but for me, integrating them into my daily .NET development initially felt like trying to code with one hand tied behind my back. I'd spend more time correcting copilot mistakes and refactoring Claude Opus 4.7's suggestions than I saved writing new code. Honestly, I was pretty close to giving up on the whole idea, convinced these tools just weren't mature enough for serious enterprise .NET work. It took me an embarrassing amount of time to realize the problem wasn't the tools; it was my approach to using them. I was making some fundamental ai coding mistakes that turned every interaction into a time sink.

I had jumped in expecting magic, hoping Visual Studio 2026 and Rider 2026's AI integrations would instantly churn out perfect C# 13 code for my .NET 9 and .NET 10 projects. My goal was to accelerate boilerplate, unit test generation, and refactoring. Instead, I found myself battling irrelevant suggestions and subtly broken code. These dotnet ai pitfalls cost me hours, until I started to reflect on how I was interacting with the AI.

My Blind Spot: Underestimating Context

My biggest initial ai coding mistake was treating AI like a mind-reader. I'd provide vague prompts, assuming the tool, whether Copilot Edits or Claude Opus 4.7, would infer everything it needed from my open files. It turns out, that's a recipe for generic, often incorrect, code. While Copilot for Workspaces and its integration with the Model Context Protocol (MCP) in Visual Studio 2026 does help by providing a wider context, it’s not omniscient. I learned the hard way that explicit context is king.

For example, asking for "a new service" would get me a barebones class. But asking for "a new IOrderService implementation that uses MediatR for domain events, logs with Serilog, and interacts with an IOrderRepository for a .NET 9 application" yielded significantly better results. I found Claude Opus 4.7 especially responsive to this level of detail when I was building out new feature skeletons.

// My initial, naive prompt to Claude Opus 4.7
Please write a service to handle orders.

// What I learned to do for better results
Please generate an implementation for `IOrderService` in a .NET 9 C# 13 project.
It needs to:
1. Be registered as a scoped service.
2. Inject `IOrderRepository` and `ILogger<OrderService>`.
3. Have a `PlaceOrder` method that takes an `OrderDto`, maps it to an `Order` entity, saves it via the repository, and publishes an `OrderPlacedEvent` using `IMediator`.
4. Include basic error handling and logging.

The "Looks Good" Trap: Trusting Too Fast

Another significant pitfall was my tendency to blindly accept suggestions from Copilot Edits or Cursor 0.42+ without thorough review. The code looked right, it compiled, and often passed basic tests. But under the hood, I was accumulating copilot mistakes that introduced subtle bugs, performance regressions, or deviations from our team's established .NET 9 coding standards.

Last Tuesday, I was debugging a strange entity state issue with EF Core when I traced it back to a Copilot Edits suggestion I'd accepted weeks prior. It had "optimized" a LINQ query, but in doing so, created an N+1 problem that only manifested under specific load conditions. It was a perfect example of a dotnet ai pitfall where the AI provided syntactically correct but semantically flawed code. Now, I always run a quick mental check, especially with complex LINQ or async/await patterns. Never hit "Accept" without a glance.

// Original, performant query
public async Task<List<Order>> GetOrdersWithItemsAsync(int customerId)
{
    return await _context.Orders
                         .Where(o => o.CustomerId == customerId)
                         .Include(o => o.OrderItems) // Eager loading
                         .ToListAsync();
}

// Copilot's "optimization" that introduced N+1 if OrderItems were accessed outside the context
// (I accepted this without thinking, assuming it was smarter)
public async Task<List<Order>> GetOrdersWithItemsAsync(int customerId)
{
    var orders = await _context.Orders
                               .Where(o => o.CustomerId == customerId)
                               .ToListAsync(); // Fetches orders
    // Later, if I iterated 'orders' and accessed 'order.OrderItems', it would cause a separate query per order
    return orders;
}

Misaligned Expectations: One AI Tool Does Not Fit All

My final, and perhaps most frustrating, initial mistake was trying to force a general-purpose LLM to do highly specific, domain-heavy .NET tasks. I'd try to get Claude Sonnet 4.6 to generate complex ASP.NET Core middleware configurations or intricate EF Core query projections. While it could give me something, it often required significant correction or entirely missed nuanced .NET 9 idioms or C# 13 features.

I learned that for in-line, localized code completion and suggestions within an existing codebase, Visual Studio 2026's built-in Copilot features are incredibly powerful. For larger architectural patterns, brainstorming, or detailed problem-solving outside the immediate code context, Claude Opus 4.7 is fantastic – but only if I feed it enough of my project's structure and existing code. Trying to use it for a quick, specific dotnet snippet often led to more ai coding mistakes than solutions. Your mileage may vary, but for me, understanding each tool's strength was key.

I'm still figuring out the best ways to integrate these tools, but by being more deliberate about context, critically reviewing output, and using the right AI for the right job, my productivity has genuinely improved. If you've also wrestled with initial dotnet ai pitfalls and found specific strategies to overcome them in production, I'd love to hear what worked for you.

How I Finally Got an MCP Server Running with .NET 9

itysu tur — Fri, 29 May 2026 10:20:28 +0000

How I Finally Got an MCP Server Running with .NET 9

Last Tuesday, a Slack DM from our DevOps lead about "context window exhaustion" got me thinking. We've been hitting the limits with direct API calls to Claude Opus 4.7 for some of our internal workflow automation tools. The sheer volume of domain-specific context we need to feed was becoming unwieldy, and frankly, expensive. That's when I remembered hearing whispers about the Model Context Protocol (MCP) and how it's designed to give you more granular control over context management. I figured, why not try to build a simple mcp server csharp implementation myself?

Honestly, I was skeptical. Another protocol, another layer of abstraction. But the idea of potentially offloading complex context assembly from the model provider's API and managing it locally, closer to our data, was too tempting to ignore. My goal wasn't a production-ready behemoth, but a proof-of-concept for a model context protocol dotnet server that could accept context, make internal tool calls, and then pass a refined request to an actual LLM. I spent the next couple of weeks chipping away at it in Visual Studio 2026 using C# 13 and dotnet 9.

My First Stumble: Deconstructing the Protocol

The initial hurdle was simply understanding the MCP specification itself. It's not overly complex, but translating its concepts into idiomatic C# took a few tries. I kept getting stuck on how tools were supposed to be defined and then invoked. My first attempt at defining the core Message and ToolDefinition structures felt clunky, and I spent an embarrassing amount of time over-engineering the serialization. I envisioned a complex hierarchy, but the protocol is surprisingly flat.

What I ended up with, after several refactors and some help from Claude Sonnet 4.6 (more on that later), were simple record types. The key insight was realizing that ToolDefinition objects are just JSON schemas, and ToolCall objects are essentially method calls with arguments. Keeping it simple was crucial. This pattern holds true across the protocol: everything is a structured message, whether it's user input, assistant output, or a tool invocation.

// Simplified core MCP types I settled on
public record Message(string Role, string Content, ToolCall? ToolCall = null, ToolResult? ToolResult = null);

public record ToolCall(string Name, Dictionary<string, object> Arguments);

public record ToolResult(string ToolCallId, string Content, bool IsError = false);

public record ToolDefinition(string Name, string Description, JsonSchema Parameters); // JsonSchema from a library

The Setup I Settled On: A Minimal .NET 9 Host

After wrestling with the data structures, the server implementation itself was surprisingly straightforward, thanks to ASP.NET Core Minimal APIs in .NET 9. I wanted something lean, without a lot of boilerplate, and Minimal APIs fit the bill perfectly. My Program.cs became the central hub for defining the MCP endpoints.

I decided to encapsulate the core logic for handling invoke requests within a simple IMCPService interface. This allowed me to swap out implementations easily and kept my Program.cs clean. I found it helps to think of the MCP server as a proxy or an orchestrator. It receives a request, potentially performs some local actions (like invoking an internal tool), and then crafts a new request for the actual LLM if needed.

Here’s a snippet of my Program.cs showing how I mapped the primary /mcp/v1/invoke endpoint. I used Rider 2026 for most of this, and its refactoring tools made quick work of moving logic around.

// Program.cs snippet for MCP server
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Anthropic.MCP.Server.Models; // My custom models based on MCP spec
using Anthropic.MCP.Server.Services; // My IMCPService implementation

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddScoped<IMCPService, LocalMCPService>(); // My service for handling MCP logic
builder.Services.AddHttpClient(); // For making calls to actual LLMs

var app = builder.Build();

// Main MCP invoke endpoint
app.MapPost("/mcp/v1/invoke", async (HttpContext context, IMCPService mcpService) =>
{
    // The MCP spec allows for streaming directly over HTTP/1.1 or WebSockets.
    // For simplicity in this PoC, I initially focused on non-streaming, then added SSE.
    // This example shows the initial non-streaming approach.
    var request = await context.Request.ReadFromJsonAsync<InvokeRequest>(); 
    if (request == null) return Results.BadRequest("Invalid MCP InvokeRequest payload.");

    context.Response.Headers.ContentType = "text/event-stream";
    context.Response.Headers.CacheControl = "no-cache";
    context.Response.Headers.Connection = "keep-alive";

    // Use a custom streaming writer for Server-Sent Events (SSE)
    await mcpService.HandleInvokeStreamAsync(request, context.Response.BodyWriter);

    return Results.Empty; // Response written directly to stream
});

app.Run();

Integrating with AI: Where Copilot and Claude Shined (and Failed)

The real power play came in connecting my MCP server to an actual model. My goal was to feed the processed context to Claude Opus 4.7. This meant my LocalMCPService needed to perform two main tasks: interpreting incoming tool calls from the MCP request and then, if necessary, making an API call to Anthropic's API with the refined context.

This is where GitHub Copilot for Workspaces and Cursor 0.42+ became invaluable. Writing the boilerplate for HttpClient calls, JSON serialization, and handling streaming responses from the Anthropic API is tedious. I prompted Copilot with things like "create a method to call the Anthropic messages API with streaming, given a list of Anthropic.MessagesApi.Message objects." It generated surprisingly accurate starting points, saving me hours.

Where I screwed this up initially was with the streaming responses. I tried to buffer everything before sending it back through my MCP server's SSE stream, which completely defeated the purpose. It took me a few frustrating debugging sessions to realize I needed to directly pipe the Anthropic streaming response into my own Response.BodyWriter as Server-Sent Events. My server wasn't just a proxy; it was a re-streamer.

// Simplified snippet from LocalMCPService.cs
public async Task HandleInvokeStreamAsync(InvokeRequest request, PipeWriter writer)
{
    // ... logic to process incoming MCP messages and tool definitions ...

    // Example: If an internal tool call is detected and handled
    if (request.Messages.Any(m => m.ToolCall != null))
    {
        var toolCall = request.Messages.First(m => m.ToolCall != null).ToolCall;
        // Simulate internal tool execution
        var toolResult = await ExecuteInternalTool(toolCall);
        await WriteSseEvent(writer, new InvokeResponse(new Choice("tool_result", toolResult.Content)));
        // Add the tool result to the context for the LLM
        request = request with { Messages = request.Messages.Append(new Message("tool", toolResult.Content, ToolResult: toolResult)).ToList() };
    }

    // Now, forward the refined context to the actual Anthropic API
    var anthropicMessages = request.Messages.Select(MapToAnthropicMessage).ToList(); // Mapping logic

    // Using Anthropic's official .NET client (or a custom HttpClient call)
    await _anthropicClient.StreamMessagesAsync(anthropicMessages, request.ToolDefinitions, writer); // Custom method to pipe stream
}

// ... helper methods like MapToAnthropicMessage, WriteSseEvent, ExecuteInternalTool ...

I'm still figuring out the best way to manage the state between multiple MCP requests for a single conversation, especially when tools are involved. Your mileage may vary, but for me, this initial dive into an anthropic mcp tutorial proved that gaining control over the context pipeline is absolutely worth the effort.

If you've tried building an MCP server in .NET, especially with complex tool orchestration or state management, I'd love to hear what challenges you faced and how you solved them.

How I Stopped Fighting AI Context: JetBrains AI vs. Copilot in Rider

itysu tur — Thu, 28 May 2026 12:13:39 +0000

How I Stopped Fighting AI Context: JetBrains AI vs. Copilot in Rider

Last Tuesday, I was staring at a System.NullReferenceException: Object reference not set to an instance of an object. (Parameter 'serviceProvider') in a new Program.cs file, trying to boot up a .NET 9 API. The kicker? The code came almost entirely from an AI assistant. I'd been trying to leverage JetBrains AI Assistant and GitHub Copilot in Rider 2026 to speed up a legacy .NET 7 service migration, and honestly, the context dance between them was driving me a little nuts.

For a while, I felt like I was spending more time debugging AI output than writing actual code. My goal was simple: use AI to offload boilerplate, understand unfamiliar patterns in a large codebase, and generally accelerate my daily work. What I ended up with initially was a chaotic mix of half-baked suggestions and context-blind refactors. It took some serious trial and error, but I think I've finally settled on a pragmatic approach that works for me.

The Context Conundrum: Where My Assumptions Broke Down

My initial mistake was treating both JetBrains AI Assistant (powered by Claude Sonnet 4.6) and GitHub Copilot (the latest Copilot for Workspaces version) as interchangeable, all-knowing oracles. I'd ask a question in the chat window, or expect an inline completion to magically understand my entire project structure. This almost never worked.

For instance, I'd ask JetBrains AI Assistant to "add a new AuditLogService to this project" and get back a barebones class definition that completely ignored my existing DI setup, appsettings.json conventions, or even the ILogger pattern I was using everywhere else. It was technically correct C#, but utterly useless in my context. Copilot, meanwhile, would often complete a line based purely on syntax and local variables, completely missing the architectural implications. I even got a code block where _dbContext was used before it was injected, leading to that nasty NullReferenceException I mentioned.

Here’s a simplified example of the kind of output I was getting, which compiled but didn't quite fit:

// Asking JetBrains AI Assistant to "Add a new AuditLogService"
public class AuditLogService
{
    public void LogAction(string user, string action)
    {
        Console.WriteLine($"User {user} performed {action}");
    }
}

// And then Copilot suggesting usage without context
public class MyController
{
    private readonly AuditLogService _auditLogService; // No constructor injection

    public MyController() // Missing dependency
    {
        // ...
        _auditLogService.LogAction("current_user", "some_action"); // NRE waiting to happen
    }
}

The issue wasn't the AI's intelligence, but my prompting strategy and expectation of its context awareness. While MCP (Model Context Protocol) support in Rider 2026 does a great job of feeding relevant code snippets, it's not a mind-reader. I learned that explicit context is king.

Finding My Workflow: A Tale of Two Assistants

What I ended up with is a clearer division of labor, treating them less as rivals and more as complementary tools. Your mileage may vary, but this has drastically improved my productivity.

GitHub Copilot in Rider: This is my fast-twitch muscle memory. For quick, inline completions, generating boilerplate, writing unit tests for a specific method, or even just filling out XML documentation comments, Copilot is incredibly efficient. It excels when the context is narrow and immediately visible in the current file or surrounding lines. I use it constantly for things like if (string.IsNullOrWhiteSpace(value)) or generating switch expressions. I've also found Copilot Edits surprisingly useful for quick refactors within a single method, like extracting a local function or simplifying a LINQ query.

// Using Copilot for quick completion and test generation
public interface IOrderService
{
    Task<bool> ProcessOrderAsync(Guid orderId);
}

// After defining IOrderService, Copilot often suggests this:
public class OrderService : IOrderService
{
    public async Task<bool> ProcessOrderAsync(Guid orderId)
    {
        // TODO: Implement order processing logic
        return await Task.FromResult(true); 
    }
}

// If I then navigate to the test project and create a new test file:
[TestFixture]
public class OrderServiceTests
{
    [Test]
    public async Task ProcessOrderAsync_ValidId_ReturnsTrue()
    {
        // Copilot will often suggest this test setup:
        var service = new OrderService();
        var result = await service.ProcessOrderAsync(Guid.NewGuid());
        Assert.That(result, Is.True);
    }
}

JetBrains AI Assistant (with Claude Sonnet 4.6) in Rider: This is where I go for deeper understanding, architectural refactoring, or when I need more nuanced code generation. Its strength lies in its chat interface, allowing for multi-turn conversations and explicit context feeding. When I need to understand a complex legacy class, I'll paste the entire file into the chat, ask "Explain the dependencies and responsibilities of this LegacyOrderProcessor," and then follow up with "Suggest a strategy to refactor this using a CQRS pattern for .NET 9." It takes more effort to craft the prompt, but the quality of the output is significantly higher for complex tasks. I've even used Claude Opus 4.7 via the assistant for particularly thorny problems, though it's slower.

// Prompting JetBrains AI Assistant for a refactor
// (Imagine I've pasted the entire 'LegacyOrderProcessor' class into the chat window first)
"Refactor the provided `LegacyOrderProcessor` class to use an `IOrderStategy` pattern. 
Create a new interface `IOrderProcessingStrategy` and at least two concrete implementations
(`StandardOrderStrategy`, `PremiumOrderStrategy`). Explain the changes step-by-step and 
show how to update the processor to use a strategy factory."

// Partial example of the kind of detailed response I get back:
// (AI Assistant would provide full code, explanations, and factory logic)
public interface IOrderProcessingStrategy
{
    Task<bool> ProcessAsync(Order order);
}

public class StandardOrderStrategy : IOrderProcessingStrategy
{
    public async Task<bool> ProcessAsync(Order order)
    {
        // Standard processing logic here
        return await Task.FromResult(true);
    }
}

This dual-tool approach means Copilot handles the small, localized tasks, while JetBrains AI Assistant tackles the bigger picture, aided by more explicit context from me.

I'm still figuring out the best way to leverage Copilot for Workspaces' broader context features without feeling overwhelmed by its suggestions, especially when dealing with early .NET 10 preview features. If you've managed to integrate both JetBrains AI Assistant and GitHub Copilot effectively in Rider for large-scale .NET refactoring, I'd love to hear your strategies and any pitfalls you've encountered.

From InvalidOperationException to Insight: My AI Debugging Journey with .NET 9

itysu tur — Wed, 27 May 2026 10:26:53 +0000

From InvalidOperationException to Insight: My AI Debugging Journey with .NET 9

Last Tuesday, I hit a familiar wall: System.InvalidOperationException: Collection was modified; enumeration operation may not execute. I was trying to optimize a legacy .NET 9 endpoint, iterating a list of active connections while a background task could add new ones. Classic race condition, but in a sprawling codebase, tracing the exact timing and interplay felt like untangling wet spaghetti. My usual approach of setting breakpoints and stepping through felt like it would take hours.

This particular bug pushed me over the edge. I've been cautiously optimistic about AI's role in dev workflows, but mostly for boilerplate code or documentation. Could it actually help with real, gnarly debugging? For two weeks, I decided to lean heavily into ai debugging dotnet tools, specifically focusing on how Claude Opus 4.7 and Visual Studio 2026's integrated AI features could speed up my ai bug fix cycle.

My First Forays (and Fumbles) with Claude Debugging C

My initial attempts at claude debug csharp were, frankly, a bit clunky. I'd paste the exception, maybe a few lines of code, and get back generic advice like "use ToList() before iterating" or "add locks." Useful, but not always the deep insight I needed for a specific context. My first major screw-up was feeding it too little context. I’d paste a method, but forget to include the calling code or the full stack trace. The AI, understandably, made assumptions that led me down a few rabbit holes.

What I ended up doing was taking a more structured approach. When I hit that InvalidOperationException, I grabbed the full stack trace, the problematic method, and any relevant class definitions. Then, I'd prompt Claude Opus 4.7 directly within Cursor 0.42+, which I’ve been using more lately for its integrated AI chat.

Here’s a simplified version of a prompt that finally got me somewhere:

I'm getting a System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
Here's the stack trace:
   at System.Collections.Concurrent.ConcurrentQueue`1.GetEnumerator()
   at MyNamespace.ConnectionManager.ProcessConnections() in C:\...\ConnectionManager.cs:line 45
   at MyNamespace.BackgroundService.DoWork(CancellationToken cancellationToken) in C:\...\BackgroundService.cs:line 22

Here's the relevant code from ConnectionManager.cs:

public class ConnectionManager
{
    private readonly ConcurrentQueue<Connection> _activeConnections = new ConcurrentQueue<Connection>();

    public void AddConnection(Connection connection)
    {
        _activeConnections.Enqueue(connection);
    }

    public void ProcessConnections()
    {
        foreach (var connection in _activeConnections) // Line 45
        {
            // Process connection
            if (connection.ShouldBeRemoved())
            {
                // This is where the issue might be - trying to remove while iterating.
                // But ConcurrentQueue doesn't have a direct Remove.
            }
        }
    }
}

The issue occurs on line 45. The `AddConnection` method can be called from multiple threads.
How can I safely iterate and potentially remove connections without causing this exception?

Claude’s response was surprisingly insightful, pointing out that even ConcurrentQueue iterators can throw this if the collection is modified during enumeration, and that direct removal isn't supported. It suggested a few patterns, but the one that stuck was using a snapshot or a producer-consumer pattern. This was a lightbulb moment for me, realizing the AI understood the nuances beyond just "use lock."

The Setup I Settled On for Rapid AI Bug Fixes

After a few days of trial and error, I found a workflow that significantly cut down my ai bug fix time. Instead of just pasting code, I now treat the AI as a highly knowledgeable, slightly context-blind colleague.

Replicate (or Isolate): Get a minimal reproducible example or at least the exact failure scenario.
Gather Context: Full stack trace, relevant code (including dependencies or interfaces), and a clear description of what I was trying to do.
Prompt the AI: I've found that Claude Opus 4.7, particularly when given a good "System Prompt" (using MCP in Cursor or Copilot for Workspaces in VS 2026), provides the best results. I ask it to explain the root cause first, then suggest solutions, and finally provide a code example.
Review and Implement: This is crucial. I never just copy-paste. The AI's suggestion is a starting point. I understand why it works, verify it, and then integrate it into my codebase.

For my InvalidOperationException, the AI nudged me towards a simple snapshot approach for processing, acknowledging that ConcurrentQueue isn't designed for mid-iteration removal. What I ended up with was something like this:

public class ConnectionManager
{
    private readonly ConcurrentQueue<Connection> _activeConnections = new ConcurrentQueue<Connection>();

    public void AddConnection(Connection connection)
    {
        _activeConnections.Enqueue(connection);
    }

    public void ProcessConnections()
    {
        // Take a snapshot of the current connections
        var connectionsToProcess = _activeConnections.ToList(); // Safe snapshot

        foreach (var connection in connectionsToProcess)
        {
            // Process connection
            if (connection.ShouldBeRemoved())
            {
                // If removal is needed, re-enqueue only the ones that should remain
                // or use a separate mechanism for removal (e.g., a "dead connections" queue)
                // For this specific bug, simply not re-adding it effectively "removes" it from the next snapshot.
            }
            else
            {
                // If connection is still active and needs to be processed again,
                // re-enqueue it or ensure it's handled by AddConnection if it's new.
                // My actual fix involved moving to a ConcurrentDictionary for easier ID-based removal.
            }
        }

        // For a ConcurrentQueue, if you need to "remove" items, you typically drain and re-populate.
        // A better structure might be ConcurrentDictionary<Guid, Connection> for explicit removal.
        // The AI's core insight was "don't modify the collection you're iterating."
    }
}

This wasn't a direct "copy-paste" fix, but the AI pointed me to the fundamental issue and the common patterns. It saved me hours of stepping through code, letting me focus on the architectural implications of the fix. Your mileage may vary with the specific AI and prompt, but for ai debugging dotnet in a crunch, this worked wonders for me.

I'm still figuring out the best way to integrate AI into every debugging scenario, especially for subtle performance issues or highly domain-specific logic. But for common concurrency bugs or puzzling exceptions, it feels like I've gained a superpower.

If you've tried using Claude Opus 4.7 or similar AI tools for real-world ai debugging dotnet scenarios, especially in legacy C# projects, I'd love to hear what specific challenges you faced and how you overcame them.

Claude Code vs. Legacy .NET: I Picked the Helper, Not the Hero

itysu tur — Tue, 26 May 2026 11:06:02 +0000

Claude Code vs. Legacy .NET: I Picked the Helper, Not the Hero

Last Tuesday, I was staring down a System.InvalidOperationException: 'Sequence contains no elements.' at MyLegacyProject.DataService.GetActiveUsersAsync() stack trace. It wasn't the AI's fault directly, but it was generated from a prompt I'd given Claude Sonnet 4.6 to "fix" a related issue in a particularly ancient .NET Framework 4.8 service. That's when I realized this wasn't going to be a simple copy-paste job.

Our team, like many, has a few critical, undocumented services nobody wants to touch. The idea was to see if Claude Code, specifically the Opus 4.7 model, could accelerate our understanding of this spaghetti code, perhaps even generate some initial fixes or tests, reducing the mental load on our ai coding team dotnet members. Honestly, I didn't expect much from this initially; I figured it would be another glorified search engine. I was wrong, but not in the way I expected.

Unraveling Legacy Code with Claude Opus 4.7

My initial goal was to get Claude to explain a particularly dense, 500-line method in an old DataService class. This method, CalculateComplexBillingAsync, had a dozen nested if statements and some truly creative LINQ queries. I copied the entire method, pasted it into the Claude Opus 4.7 web interface, and asked: "Explain this C# method, identify potential issues, and suggest how it could be refactored for readability and testability, targeting .NET 9 and C# 13 features."

What I got back wasn't just a line-by-line explanation, but a high-level summary of its purpose, a breakdown of its core logic flows, and even a couple of specific edge cases I'd never considered (like a FirstOrDefault() without a null check, which was the root of my Sequence contains no elements error last week). It even proposed using record types for some DTOs and IAsyncEnumerable for streaming results, which was a nice touch for a .NET 9 target. For me, the contextual understanding Claude provided was a game-changer. It helped me mentally model the legacy code far faster than just stepping through it in Visual Studio 2026.

// My prompt (simplified)
// "Explain this C# method, identify potential issues, and suggest refactoring for .NET 9/C# 13."
// (Followed by 500 lines of legacy C# code)

// Claude's (simplified) response snippet:
/*
This method primarily calculates billing based on various user activity logs.
Potential Issue 1: Lack of null checking on `FirstOrDefault()`. If `userActivityLogs` is empty or no matching log is found, this will throw `InvalidOperationException`.
Refactoring Suggestion:
Replace `FirstOrDefault().Property` with:

csharp
var log = userActivityLogs.FirstOrDefault(l => l.UserId == userId);
if (log != null)
{
// ... proceed with log.Property
}
else
{
// Handle case where no log is found, e.g., default value or throw specific exception.
}

*/

Integrating into the AI Coding Team DotNet Workflow (and the Handoff)

The real challenge wasn't getting Claude to generate code or explanations, but integrating it effectively into our existing ai coding team dotnet workflow. My colleagues, mostly Rider 2026 users, were initially skeptical. "Another Copilot?" was the common refrain. My personal workflow evolved: I'd use Claude for the initial understanding or boilerplate generation, then bring that into my IDE for refinement.

One specific "gotcha" I hit repeatedly was Claude's tendency to generate C# 13 preview features or .NET 10 preview APIs when I wasn't explicit enough about our stable .NET 9 target. It took me an embarrassing amount of time to realize the generated code often wouldn't compile without slight modifications or specific using directives, even when I thought I'd given it enough context. This meant that claude code review wasn't about blindly accepting its output; it was about treating Claude's suggestions as a very smart junior developer's first draft. Human oversight remained critical. We started treating Claude's output like any other code submitted by a new team member – it needed thorough review, especially for correctness and adherence to our coding standards.

// Claude generated this (hypothetically, for .NET 10 preview)
// Example of a small issue I'd often fix manually
public static class FeatureToggle
{
    // .NET 10 preview feature (hypothetically)
    public static bool IsEnabled(string featureName) =>
        Environment.GetExperimentalFeature(featureName) == "enabled";
}

// My manual fix for .NET 9:
public static class FeatureToggle
{
    public static bool IsEnabled(string featureName) =>
        Environment.GetEnvironmentVariable($"FEATURE_{featureName.ToUpperInvariant()}") == "enabled";
}

After a month, I'm still figuring out the best way to leverage Claude Code. It's fantastic for understanding complex codebases and generating initial drafts or unit tests, especially when dealing with legacy systems. However, it's not a set-it-and-forget-it solution. The handoff between AI generation and human refinement is where the real work happens, and it requires careful attention to detail, especially regarding target framework and language versions.

If you've managed to integrate AI code generation tools into your team's .NET code review process without major headaches, I'd love to hear what broke for you and how you fixed it.

AI's Promise vs. My Reality: The .NET Dev Stack I Actually Use

itysu tur — Mon, 25 May 2026 08:32:21 +0000

AI's Promise vs. My Reality: The .NET Dev Stack I Actually Use

I'd heard the buzz about AI coding assistants replacing developers, and honestly, for a while, I bought into the hype. But what I’ve found after months of trying to integrate every shiny new AI into my .NET 9 projects is that the real game-changer isn't replacement, but intelligent augmentation. My personal journey has been less about delegating entire features to an LLM and more about finding that sweet spot where a few specific tools amplify my existing skills, especially when wrestling with legacy C# 13 codebases.

The Copilot I Never Expected

My initial foray into the world of dotnet ai tools started, like many, with GitHub Copilot. Honestly, I expected it to be a novelty, good for trivial boilerplate or maybe filling out a switch statement. What I ended up finding was that its real strength, for me, lies in its ability to act as a hyper-aware rubber duck. When I'm in Visual Studio 2026 or Rider 2026 and get stuck on a method signature or a common pattern, Copilot often has the right suggestion before I even finish typing.

Where it truly shines for me is in generating unit tests or simple CRUD operations, especially when there's an existing codebase to learn from. However, I learned the hard way that over-reliance can introduce subtle bugs, particularly with complex async/await patterns or intricate LINQ queries in C# 13. My rule now is: if it's more than a few lines, I treat Copilot's suggestion as a draft, not gospel.

// In a .NET 9 Web API controller, Copilot often nails the boilerplate
[HttpPost("products")]
public async Task<ActionResult<Product>> CreateProduct([FromBody] Product product)
{
    // Copilot frequently suggests this entire block based on existing repository patterns
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }

    await _productRepository.AddAsync(product);
    return CreatedAtAction(nameof(GetProductById), new { id = product.Id }, product);
}

Claude and Cursor: My Pair-Programming Power-Up

For deeper architectural questions, complex refactoring, or simply understanding a gnarly piece of legacy code, my developer ai stack leans heavily on Claude Opus 4.7, accessed primarily through Cursor 0.42+. I'm still figuring out the optimal way to prompt, but what I've found is that Claude excels at explaining why a particular piece of code might be problematic or suggesting more robust patterns.

One specific scenario where this combination saved me an embarrassing amount of time was debugging a tricky ConcurrentDictionary race condition. I'd tried to implement an async cache GetOrAdd pattern myself, only to hit subtle deadlocks. Feeding the problematic C# 13 snippet to Claude via Cursor, leveraging its Model Context Protocol (MCP) awareness, yielded a robust solution. It took a few iterations, but the detailed explanation of Lazy<Task<T>> was a game-changer.

// Prompt to Claude Opus 4.7 via Cursor 0.42+
Explain the potential pitfalls and thread-safety concerns of this .NET 9 C# 13 code snippet, particularly related to the concurrent modification of the `_cache` dictionary with an async factory. Suggest a safer pattern.

csharp
public class MyService
{
private readonly ConcurrentDictionary _cache = new();

public async Task<T> GetOrAddAsync<T>(string key, Func<Task<T>> factory)
{
    if (_cache.TryGetValue(key, out var cachedValue))
    {
        return (T)cachedValue;
    }

    var newValue = await factory(); // Potential for multiple threads to execute factory
    _cache.TryAdd(key, newValue);
    return newValue;
}

}

csharp
// Claude Opus 4.7 Response (abbreviated for brevity)
You've correctly identified a race condition. The primary issue with your proposed GetOrAddAsync is that ConcurrentDictionary.GetOrAdd expects a synchronous factory function. Directly passing an async lambda won't properly cache the result of the Task, only the Task object itself, leading to potential re-execution or incomplete caching.

To properly handle asynchronous factory functions and ensure single execution of the factory across multiple threads, I typically lean on a pattern involving Lazy<Task<T>> or an AsyncLazy<T> implementation. This ensures the asynchronous operation is performed once and its result is safely cached.

public class MyService
{
    // Store Lazy<Task<object>> to ensure the async factory runs only once
    private readonly ConcurrentDictionary<string, Lazy<Task<object>>> _cache = new();

    public async Task<T> GetOrAddAsync<T>(string key, Func<Task<T>> factory)
    {
        var lazyTask = _cache.GetOrAdd(key, k => new Lazy<Task<object>>(async () =>
        {
            // The factory is executed inside the Lazy, ensuring single execution
            var result = await factory();
            return result;
        }, LazyThreadSafetyMode.ExecutionAndPublication)); // Critical for thread safety

        return (T)await lazyTask.Value; // Await the result of the Lazy<Task<object>>
    }
}

Visual Studio + Copilot Edits: The IDE's New Brain

The biggest shift in my daily coding rhythm has been the tight integration of AI directly into my IDE. Visual Studio 2026, with its latest Copilot Edits and Copilot for Workspaces features, has become an indispensable part of my best ai for csharp toolkit. It's not just auto-completion anymore; it's proactive refactoring and code generation right where I need it.

For quick, localized transformations, Copilot Edits is fantastic. I can highlight a for loop and prompt it to "Refactor this to use LINQ," and it usually gets it right on the first try. It handles mundane tasks like extracting methods, renaming variables consistently, or even adding XML documentation comments based on context. I'm still figuring out how to make Copilot for Workspaces truly effective for larger, multi-file refactors across our sprawling monorepo, but for focused, in-file changes, it's a significant time-saver.

// Scenario: Using Copilot Edits in VS 2026
// Original code selected by me:
// var activeUsers = new List<User>();
// foreach (var user in allUsers)
// {
//     if (user.IsActive && user.LastLogin > DateTime.UtcNow.AddDays(-30))
//     {
//         activeUsers.Add(user);
//     }
// }
// return activeUsers.OrderBy(u => u.Username).ToList();

// My prompt to Copilot Edits: "Refactor this to use LINQ for filtering and ordering."

// Copilot Edits output:
return allUsers
    .Where(user => user.IsActive && user.LastLogin > DateTime.UtcNow.AddDays(-30))
    .OrderBy(user => user.Username)
    .ToList();

So, where am I now? My current developer AI stack isn't about replacing me, but about making me a faster, more informed .NET developer. I'm still figuring out how to leverage Copilot for Workspaces effectively for cross-project context, especially with our monorepo setup. It feels like we're just scratching the surface of what's possible.

If you've managed to integrate dotnet ai tools into your daily workflow for complex refactoring or legacy codebase understanding, I'd genuinely love to hear about your specific wins and especially your failures. What broke for you, and how did you fix it?