Why your AI assistant writes JavaScript-flavored C# (and 8 rules that fix it)

Recs Ventures — Sat, 12 Sep 2026 15:38:56 +0000

I use Cursor and Claude Code every day on ASP.NET Core work, and I kept noticing the same thing: the C# they hand me on the first try reads like it was written by someone whose main language is JavaScript. It compiles. It looks reasonable in review. And it's full of the exact mistakes a senior .NET dev would never ship.

After correcting the same handful of defects for the hundredth time, I stopped blaming the model and started writing the corrections down as rules. Here's why this happens, the three failures I hit most, and how I get the assistant to write senior-grade .NET on the first draft instead of the third.

Why the average is JavaScript

An LLM predicts the most likely next token given everything it has seen. The training data is enormous and heavily weighted toward web and JavaScript code. So when you ask for "an endpoint that saves a user," the model reaches for the shape that's most common across all that data. It returns the object you just loaded, fire off calls without much thought to threading, don't worry too much about how the query hits the database.

None of that is wrong in a Node handler. It's quietly wrong in C#. The language has strong opinions about async, and EF Core has sharp edges that don't exist in an ORM you drive from JavaScript. The model doesn't know your project cares about those things unless you tell it. Left alone, it regresses to the mean, and the mean is JavaScript-flavored.

The fix isn't a better prompt each time. It's giving the assistant a standing set of rules so the defaults change. Below are the three defects I see most, with real before/after, and the rule behind each fix.

1. Blocking on async

This is the one I catch most. The model writes an async call and then immediately blocks on it with .Result or .Wait().

Before:

[HttpGet("{id}")]
public ActionResult<OrderDto> GetOrder(int id)
{
    // .Result blocks the request thread until the DB call finishes
    var order = _dbContext.Orders.FirstOrDefault(o => o.Id == id);
    var total = _pricingService.CalculateTotalAsync(order).Result;
    return Ok(new OrderDto(order.Id, total));
}

.Result looks harmless. It isn't. It parks the request thread while the async operation runs, so instead of releasing that thread back to the pool to serve other requests, you hold it hostage. Do that under load and you get thread-pool starvation: requests queue up waiting for threads that are all blocked waiting for I/O. In some synchronization contexts you can also deadlock outright.

After:

[HttpGet("{id}")]
public async Task<ActionResult<OrderDto>> GetOrderAsync(
    int id,
    CancellationToken cancellationToken)
{
    var order = await _dbContext.Orders
        .FirstOrDefaultAsync(o => o.Id == id, cancellationToken);

    if (order is null)
        return NotFound();

    var total = await _pricingService.CalculateTotalAsync(order, cancellationToken);
    return Ok(new OrderDto(order.Id, total));
}

The method is async all the way. It returns Task<ActionResult<T>>, awaits instead of blocking, and threads a CancellationToken through so a client that hangs up doesn't leave the server doing work nobody's waiting for.

A few things the model gets wrong even when it does use await:

It reaches for Task.Run to wrap synchronous I/O and call it "async." That doesn't make it async, it just moves the blocking to a different thread.
It writes async void. Unless it's a real event handler, don't. You can't await it and its exceptions escape where you can't catch them.
It thinks ConfigureAwait(false) fixes sync-over-async. It doesn't. It doesn't release a thread that's already blocked on .Result.

The rule I give the assistant, in plain terms: async I/O returns Task/Task<T> with an Async suffix; never .Result/.Wait()/.GetAwaiter().GetResult() in app code; flow a CancellationToken as the last parameter through the whole chain; no async void outside event handlers. After a refactor, search the touched call chain for those three blocking patterns again, because they hide one level up from where you started.

2. The EF entity that escapes the controller

Second most common: the model loads an entity and returns it straight out of the controller.

Before:

[HttpPost]
public async Task<ActionResult<User>> Create(User user)
{
    _dbContext.Users.Add(user);
    await _dbContext.SaveChangesAsync();
    return Ok(user); // the whole entity goes out the door
}

Two problems, and they're both about trust boundaries. On the way in, binding directly to the User entity means a caller can set fields you never intended to expose. Send {"email": "...", "isAdmin": true} and if IsAdmin is a property on the entity, you just got mass-assignment (overposting). On the way out, you're serializing the entire entity, including navigation properties and internal fields that were never meant to be part of your API contract.

After:

public record CreateUserRequest(string Email, string DisplayName);
public record UserResponse(int Id, string Email, string DisplayName);

[HttpPost]
public async Task<ActionResult<UserResponse>> CreateAsync(
    CreateUserRequest request,
    CancellationToken cancellationToken)
{
    var user = new User
    {
        Email = request.Email,
        DisplayName = request.DisplayName,
        // IsAdmin is NOT settable from the request; it's set by policy elsewhere
    };

    _dbContext.Users.Add(user);
    await _dbContext.SaveChangesAsync(cancellationToken);

    var response = new UserResponse(user.Id, user.Email, user.DisplayName);
    return CreatedAtAction(nameof(GetByIdAsync), new { id = user.Id }, response);
}

Bind to a purpose-built request DTO that only contains the fields you accept. Map to a response DTO that only contains the fields you expose. And return 201 Created with a location, not 200 OK with a raw entity. The DTOs are your API contract; the entity is your persistence model, and keeping them separate is what stops the two concerns from leaking into each other.

The rule: controllers are thin. Bind, dispatch, map. No business logic and no raw entities crossing the HTTP boundary in either direction.

3. The N+1 query you don't see until production

This one is invisible in a demo with three rows and brutal with thirty thousand.

Before:

var orders = await _dbContext.Orders
    .Where(o => o.CustomerId == customerId)
    .ToListAsync(cancellationToken);

var summaries = new List<OrderSummary>();
foreach (var order in orders)
{
    // each access to order.Items triggers a separate query
    var itemCount = order.Items.Count;
    summaries.Add(new OrderSummary(order.Id, itemCount));
}

If lazy loading is on, order.Items fires a fresh query for every single order. One query to get the orders, then N more to count items. That's the N+1. It runs fine locally and falls over the moment a customer has a real order history.

After:

var summaries = await _dbContext.Orders
    .AsNoTracking()
    .Where(o => o.CustomerId == customerId)
    .Select(o => new OrderSummary(o.Id, o.Items.Count))
    .ToListAsync(cancellationToken);

Project straight to the shape you need with Select. EF translates o.Items.Count into the SQL: one set-based query, item counts computed in the database, only the two columns you actually use coming back over the wire. AsNoTracking() because this is read-only, so there's no reason to pay for change tracking.

The rules behind it: use AsNoTracking for read-only queries; prevent N+1 by eager-loading with Include or projecting with Select (projection is usually the better call for read models); don't enable lazy-loading proxies in web apps, because they hide exactly this; paginate anything unbounded; and use AnyAsync for existence checks instead of CountAsync() > 0. One more that trips people up: don't put an Include on top of a Select projection. The projection already pulls what it needs, so the Include is ignored.

The pattern behind all three

None of these are exotic. They're the boring, load-bearing rules a senior .NET dev already carries in muscle memory. The model doesn't have them, because its defaults were shaped by a different corpus. The reliable fix is to encode those standards where the assistant reads them (Cursor project rules, a Claude Code CLAUDE.md, a Copilot instructions file) so the first draft already assumes them instead of you re-typing the correction on every prompt.

I count eight areas worth pinning down this way, from what I keep correcting: core C# and async, Clean Architecture boundaries, EF Core, ASP.NET Core Web API shape, testing, security, performance, and Azure. Async, DTOs, and EF queries are the three that bite first and hardest, which is why they're the examples here.

If you want the rules

I pulled two of these into a small, MIT-licensed repo (the async correctness rule, the EF read-query rule, and a prompt for fixing a slow query) so you can drop them into .cursor/rules/ and try them on your own code. No signup.

github.com/recsventures-ops/dotnet-ai-coding-rules

Take them, change them, ignore the rest.

If they earn their keep, I also sell a fuller pack that covers all eight areas across Cursor, Claude Code, and Copilot with a commercial license. It's linked from the repo. But the two rules above are genuinely free and useful on their own, and honestly that's the point. If the free ones don't change how your assistant writes C#, the paid ones won't either.

Either way: if your AI keeps writing JavaScript-flavored C#, write the correction down once as a rule instead of re-typing it forever. That habit alone is most of the win.

DEV Community: Recs Ventures

Why your AI assistant writes JavaScript-flavored C# (and 8 rules that fix it)

Why the average is JavaScript

1. Blocking on async

2. The EF entity that escapes the controller

3. The N+1 query you don't see until production

The pattern behind all three

If you want the rules