Forem: itysu tur

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?

My Two Weeks with Claude Sonnet 4.6 for C# Development

itysu tur — Sun, 24 May 2026 11:07:39 +0000

My Two Weeks with Claude Sonnet 4.6 for C# Development

Last month, I spent two weeks trying to integrate Claude Sonnet 4.6 into my daily C# workflow, specifically targeting a gnarly .NET 6 Web API codebase that's slowly being migrated to .NET 9. I wasn't looking for a magic bullet, just some pragmatic help.

Our team's been dabbling with AI tools for a while, mostly Copilot and some GPT-4o for documentation. My personal goal was to see if Claude Sonnet 4.6 could genuinely assist with refactoring and debugging existing C# 10 code, or if it was just another glorified autocomplete. I was looking for a fresh perspective, especially on some tricky LINQ queries and async deadlocks that had been haunting us in Visual Studio 2026.

What surprised me about its C# understanding

Honestly, I expected Sonnet 4.6 to struggle with the nuances of C# 10 and our specific domain, but it often surprised me with its contextual understanding. My initial attempts involved pasting small, isolated functions, which worked okay. The real game-changer came when I started feeding it entire .cs files, or even pairs of related files (like a service and its interface). It felt like the Model Context Protocol (MCP) was really helping it build a richer internal model.

For example, I had a complex LINQ query in a repository method that was a performance bottleneck. I pasted the entire ProductRepository.cs file into Claude with a simple prompt. It didn't just suggest a basic Where clause; it understood the intent and proposed an AsQueryable() followed by multiple Where and Select statements, even suggesting an Include for a related entity that wasn't immediately obvious from the method signature alone. It still took me a few tries to get the exact Select projection right.

// Prompt to Claude Sonnet 4.6
/*
Given the following C# 10 code from `ProductRepository.cs`, refactor the `GetFilteredProductsAsync` method to be more performant and readable, especially for filtering by multiple optional criteria.
Consider using `IQueryable` for building the query dynamically.

csharp
// ProductRepository.cs
public class ProductRepository : IProductRepository
{
private readonly AppDbContext _context;

public ProductRepository(AppDbContext context) => _context = context;

public async Task<IEnumerable<Product>> GetFilteredProductsAsync(
    string? nameFilter, int? categoryId, decimal? minPrice)
{
    var products = await _context.Products
        .Where(p =>
            (string.IsNullOrEmpty(nameFilter) || p.Name.Contains(nameFilter)) &&
            (!categoryId.HasValue || p.CategoryId == categoryId.Value) &&
            (!minPrice.HasValue || p.Price >= minPrice.Value))
        .ToListAsync();
    return products;
}

}

*/

// Claude Sonnet 4.6 Response (excerpt):
/*
Okay, here's a refactored version of `GetFilteredProductsAsync` using `IQueryable` to build the query dynamically, which can be more efficient as the filtering happens at the database level before materialization.

csharp
public async Task> GetFilteredProductsAsync(
string? nameFilter, int? categoryId, decimal? minPrice)
{
IQueryable query = _context.Products;

if (!string.IsNullOrEmpty(nameFilter))
{
    query = query.Where(p => p.Name.Contains(nameFilter));
}

if (categoryId.HasValue)
{
    query = query.Where(p => p.CategoryId == categoryId.Value);
}

if (minPrice.HasValue)
{
    query = query.Where(p => p.Price >= minPrice.Value);
}

// Example of including related data, if needed, for better context awareness
// query = query.Include(p => p.Category);

return await query.ToListAsync();

}

*/

plaintext
This dynamic query building was a definite improvement. The contextual understanding of the existing code was surprisingly robust.

Where it broke and how I learned to prompt better

While its understanding was good, Claude Sonnet 4.6 isn't a mind reader. I screwed up several times by not providing enough explicit detail. For instance, I was debugging a System.Text.Json serialization issue, and Claude initially suggested Newtonsoft.Json attributes or configuration. It took me an embarrassing amount of time to realize I needed to explicitly state our project used System.Text.Json exclusively.

This taught me a critical lesson: even with advanced models like Claude Sonnet 4.6, you still need to be precise. For C# 13 and .NET 9 work, I started adding specific directives to my prompts, like "Using C# 13 and .NET 9, please refactor this..." or "Given this Foo.cs and BarService.cs from our ASP.NET Core 9 project...". This significantly improved the relevance and accuracy of its suggestions.

// My improved prompting style:
"Given the following C# 13 code from `OrderProcessor.cs` and `OrderRepository.cs` in our .NET 9 project, refactor `ProcessOrderAsync` to use a more robust error handling strategy with `IResult` from ASP.NET Core 9, instead of throwing exceptions directly. Assume `OrderRepository.GetByIdAsync` can return null. Also, ensure all database operations are wrapped in a transaction using `_context.Database.BeginTransactionAsync()`."

This level of detail made a huge difference. Without it, I found myself getting generic C# 8 or .NET 6 suggestions that required more manual tweaking than the initial problem warranted. Specificity is key, even for advanced models.

The setup I settled on (for now)

For this personal review, I mostly stuck with the official Claude web interface for Sonnet 4.6, pasting code directly into the chat. I did experiment briefly with a custom VS Code extension that leverages the Claude Opus 4.7 API for larger, multi-file refactors, but for the focused task of evaluating Sonnet 4.6, the web UI was sufficient. My reasoning was simple: minimize integration complexity to isolate the model's performance.

I found myself using Sonnet 4.6 for quick code reviews, suggesting minor refactors, or generating boilerplate for new interfaces based on existing classes. For anything involving significant architectural changes or complex interactions across many files, I still leaned on my own architectural understanding and, if available, the more powerful Claude Opus 4.7. It's not a replacement for Rider 2026 or Visual Studio 2026's deep refactoring tools, but it's a solid complement.

My workflow often looked like this: identify a problematic C# file, paste it into Sonnet 4.6 with a clear prompt, review the suggestions, and then manually apply and refine them in my IDE. I might be wrong about this, but I think this "human-in-the-loop" approach is currently the most effective way to leverage models like Claude Sonnet 4.6 for C# development.

So, after two weeks, Claude Sonnet 4.6 earned a spot in my toolkit, mostly for its ability to quickly parse context and suggest alternative approaches. I'm still figuring out the best way to leverage it for complex, multi-file refactors without turning into a prompt engineer, but it's a solid contender for C# code help. Your mileage may vary, of course.

If you've spent time with Claude Sonnet 4.6 or another model on a particularly tricky C# 13 codebase, I'd genuinely love to hear about your wins and frustrations in the comments.

My Two-Week Sprint: Claude Sonnet 4.6 and C# Productivity

itysu tur — Sun, 24 May 2026 11:07:33 +0000

My Two-Week Sprint: Claude Sonnet 4.6 and C# Productivity

Last month, I almost gave up on really integrating AI into my daily C# development workflow. Every attempt felt like more overhead than help, until I tried a focused two-week experiment with Claude Sonnet 4.6.

Like many of us, I've dabbled with AI coding assistants – mostly Copilot for boilerplate, maybe a quick Stack Overflow search with ChatGPT. But the promise of a true claude code productivity boost always felt just out of reach. My goal was simple: track my actual time spent coding on a specific feature, first without, then with, Claude Sonnet 4.6 as my primary AI assistant for C# 13 and .NET 9 projects.

The Initial Hump and the 'Aha!' Moment

Honestly, I was skeptical at first. My first few days with Claude Sonnet 4.6 felt like a clumsy dance. I'd paste a chunk of C# code, ask for a refactor, and get back something that was technically correct but missed the nuance of our domain-driven design. I learned the hard way that just dumping code isn't enough; Claude, like any junior dev, needs proper context window and clear intent.

The 'aha!' moment came when I started feeding it architectural constraints, specific patterns we use, and even links to our internal wiki documentation via the Model Context Protocol (MCP) in Visual Studio 2026. Last Tuesday, I was refactoring an old IQueryable extension method for a new .NET 9 API, and it was taking forever. I gave Claude the existing method, our PaginationRequest DTO, and a description of the desired new filtering logic. What I got back wasn't just working code, but code that felt like it belonged in our codebase.

// My initial prompt (simplified in blog, but I provided full method and DTOs):
// "I need to update this IQueryable extension to support dynamic filtering based on a list of FilterCriteria.
// Each criteria has a PropertyName, Operator (e.g., "eq", "gt"), and Value.
// The existing method only handles basic pagination and sorting.
// Use System.Linq.Dynamic.Core for dynamic expression building."

// Claude's suggested addition (excerpt, after several refinements):
// It understood the need for dynamic LINQ and handled various operators.
public static IQueryable<T> ApplyFiltering<T>(
    this IQueryable<T> query, IEnumerable<FilterCriteria> filters)
{
    var config = new ParsingConfig { AllowNewToEvaluateExpressions = true }; // From System.Linq.Dynamic.Core
    foreach (var filter in filters)
    {
        var propertyType = typeof(T).GetProperty(filter.PropertyName, BindingFlags.IgnoreCase | BindingFlags.Public | BindingFlags.Instance)?.PropertyType;
        if (propertyType == null) continue;

        var value = Convert.ChangeType(filter.Value, propertyType);

        string dynamicLinqQuery = filter.Operator.ToLowerInvariant() switch
        {
            "eq" => $"{filter.PropertyName} == @0",
            "gt" => $"{filter.PropertyName} > @0",
            "lt" => $"{filter.PropertyName} < @0",
            "contains" => $"{filter.PropertyName}.Contains(@0)",
            _ => throw new ArgumentException($"Unsupported operator: {filter.Operator}")
        };
        query = query.Where(config, dynamicLinqQuery, value);
    }
    return query;
}

// Simplified FilterCriteria DTO (provided in prompt context)
public class FilterCriteria
{
    public string PropertyName { get; set; }
    public string Operator { get; set; } // e.g., "eq", "gt", "contains"
    public string Value { get; set; }
}

The Numbers: Where I Saw Real Gains

I tracked my time using a simple stopwatch app on my phone. For a specific set of new features and refactoring tasks on an existing microservice, I spent 5 days working without heavy AI assistance (only standard Copilot completions) and 5 days with Claude Sonnet 4.6 as my primary assistant in Rider 2026. The results were genuinely surprising. My average task completion time dropped by about 35% during the Claude-assisted week. This wasn't 10x for everything, but for the right kinds of tasks, it felt like it.

Where did I see the biggest gains? Not in writing greenfield code from scratch, surprisingly. That still requires deep architectural thought from me. The real ai csharp workflow accelerator was in understanding existing, unfamiliar codebases and generating robust unit tests. When I had to dive into a service written by a former colleague, Claude Sonnet 4.6 was invaluable for explaining complex LINQ queries or obscure async patterns, then helping me quickly scaffold tests for them. I might be wrong about this, but it felt like its larger context window (compared to what I typically use with Copilot) made it much better at digesting an entire file or even a small project.

// My prompt to Claude (simplified, but I provided the full method):
// "Explain what this method does and suggest a unit test scenario for its edge cases.
// Consider the 'status' enum and potential null/empty inputs."

// Example method for context (from my codebase)
public async Task<Order> ProcessOrderAsync(OrderRequest request)
{
    if (request == null || string.IsNullOrWhiteSpace(request.CustomerId))
    {
        throw new ArgumentException("Invalid order request.");
    }

    var customer = await _customerRepository.GetByIdAsync(request.CustomerId);
    if (customer == null)
    {
        throw new CustomerNotFoundException(request.CustomerId);
    }

    var order = _mapper.Map<Order>(request);
    order.Status = OrderStatus.Pending;
    order.OrderDate = _dateTimeProvider.UtcNow;

    await _orderRepository.AddAsync(order);
    await _unitOfWork.CommitAsync();

    _eventPublisher.Publish(new OrderCreatedEvent(order.Id));

    return order;
}

// Claude's suggested test (excerpt):
// It identified the null/empty checks and the customer not found scenario effectively.
[Fact]
public async Task ProcessOrderAsync_ShouldThrowArgumentException_WhenRequestIsNull()
{
    // Arrange
    OrderRequest nullRequest = null;
    var service = new OrderService(null, null, null, null, null); // Mocks omitted for brevity

    // Act & Assert
    await Assert.ThrowsAsync<ArgumentException>(() => service.ProcessOrderAsync(nullRequest));
}

[Fact]
public async Task ProcessOrderAsync_ShouldThrowCustomerNotFoundException_WhenCustomerDoesNotExist()
{
    // Arrange
    var request = new OrderRequest { CustomerId = "nonExistent", Items = new List<OrderItemRequest>() };
    var mockCustomerRepo = new Mock<ICustomerRepository>();
    mockCustomerRepo.Setup(r => r.GetByIdAsync(request.CustomerId)).ReturnsAsync((Customer)null);
    var service = new OrderService(mockCustomerRepo.Object, null, null, null, null);

    // Act & Assert
    await Assert.ThrowsAsync<CustomerNotFoundException>(() => service.ProcessOrderAsync(request));
}

My Current Setup and What's Still Fuzzy

What I ended up with for my developer productivity ai setup involves Claude Sonnet 4.6 (sometimes Opus 4.7 for really thorny problems) via the Cursor 0.42+ IDE extension, which supports the Model Context Protocol. This allows me to selectively feed entire files, or even directories, into the prompt without a ton of copy-pasting. For quick, localized completions, Copilot is still fantastic, but for anything requiring broader context or complex transformations, Claude became my go-to.

One thing I'm still figuring out is the optimal way to manage long-running conversations. It's easy to get lost in a massive chat history, and sometimes the AI starts 'hallucinating' based on old, irrelevant context. Your mileage may vary, but for me, starting fresh or explicitly clearing context for a new task often yields better results. I'm also not sure if this scales to truly massive enterprise codebases without hitting context limits or just becoming too slow. The integration is good, but not perfect yet.

So, while I didn't literally 10x every aspect of my C# productivity, I found a significant, measurable uplift in specific, often time-consuming tasks. My ai csharp workflow is definitely evolving, and I'm spending less time wrestling with existing code and more on design. It feels like having a really smart, well-read rubber duck.

If you've integrated Claude Sonnet 4.6 or Opus 4.7 into your C# 13 development, especially for legacy refactoring, I'd love to hear about your concrete wins or the specific challenges you ran into.