DEV Community: itysu tur

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.