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.
Top comments (0)