4 Prompting Mistakes That Make Claude Write the Wrong C#

Here's a story I keep seeing in .NET teams: someone shares a Claude answer that "didn't work." The fix it suggested used DateTime.Now in a codebase that injects TimeProvider everywhere, added a NuGet package we'd banned, and quietly changed the method's exceptions. Claude didn't do anything wrong there. It answered the question it was given, and that question was a pasted method plus "fix this."

After a few months of pairing with Claude on .NET work, I've noticed the bad answers come from four prompt mistakes. Below is each mistake, the pattern I use instead, and a short checklist to run before you hit Enter.

If you want the bigger toolkit, The Claude Playbook has a full library of copy-ready prompts. For complete, tested .NET projects to practice on, there's Tech Skill Builder.

Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10.

Mistake 1: Making Claude guess your project

Claude can't see your .csproj. So it guesses the target framework, whether nullable reference types are on, and which package versions you use. Each guess is a small chance of an answer that compiles in its head and not on your machine.

The fix: start with facts, not code. I paste a short facts block at the top of every new conversation:

Project facts (treat as ground truth):
- net10.0, ASP.NET Core minimal APIs
- <Nullable>enable</Nullable>, warnings are errors in CI
- EF Core 10, FluentValidation 12. Don't add packages without asking.
- House rules: inject TimeProvider (never DateTime.Now), async all the way,
  CancellationToken on every public async method
If something you need is not listed here, ask instead of guessing.

The last line does more than anything else in the block. Typing this by hand gets old, so I generate it from the project file. The shape is small:

public sealed record PackageRef(string Name, string? Version);

public sealed record ProjectFacts(
    string ProjectName, string Sdk, IReadOnlyList<string> TargetFrameworks,
    string? Nullable, IReadOnlyList<PackageRef> Packages, string? HouseRules)
{
    public static ProjectFacts FromCsproj(string csprojPath)
    {
        var root = XDocument.Load(csprojPath).Root!;
        // read TargetFramework(s), Nullable, PackageReference items,
        // then walk up to the nearest AGENTS.md for house rules
        // ...implementation omitted in this post
    }
}

Putting the block in a Claude Project's instructions works too, so every chat in that project starts grounded.

Mistake 2: Asking for code before the decisions are made

"Add soft delete to Customer" sounds like one task. It's really several decisions: global query filter or explicit Where? What happens to unique indexes on email? Can admins see deleted rows? Does DeletedAt use TimeProvider? If you ask for code, Claude makes those calls silently, and you find out in review, or in production.

The fix: questions first, then a plan, then code. In my own words:

Don't write code yet. First ask me up to 4 questions about anything this
task leaves open. After I answer, list the files you'll change and the
tests you'll add. Wait for my OK before writing code.

Task: {{task}}

Reading a six-line plan takes seconds. Untangling 200 lines built on the wrong assumption takes an afternoon.

Mistake 3: Letting it make the error go away instead of fixing it

Paste a build warning and ask for a fix, and the fastest "fix" often makes the message disappear without solving anything. A real one:

warning CS8618: Non-nullable property 'Name' must contain a non-null value
when exiting constructor. Consider adding the 'required' modifier or
declaring the property as nullable.

The lazy answers are = null!;, #pragma warning disable, or turning nullable off. All three hide a real question: can a Customer exist without a name?

The fix: ask for the cause before the fix, and rule out suppression.

Here is the full, unedited build output. Explain the root cause in two
sentences and point to the line. Then give the smallest real fix.
Not allowed: null-forgiving (!), #pragma disables, or changing project
settings. If the right fix depends on a domain rule, ask me.

Paste the real output, including the CSxxxx code and line number, not your summary of it.

Mistake 4: Accepting "done" without proof

Claude writing "this should work" isn't evidence. Neither is code that looks right. Here's one that looks right and isn't:

// Reads "1.5" from a config file or a CSV
var rate = decimal.Parse(input);

On a machine with de-DE culture, decimal.Parse("1.5") returns 15, because . is the thousands separator there. I checked this on .NET 10. No reviewer catches that by eye, but a test that pins the culture does.

The fix: make verification part of the task.

Before calling this done, give me:
1. the exact commands to verify it (dotnet build -warnaserror,
   dotnet test --filter ..., a curl call if it's an endpoint)
2. the output you expect from each
3. a list of what you have NOT verified, including culture/time zone cases

Item 3 is the most useful. A pair programmer who says "I didn't test this under a non-English culture" is worth more than one who just says "done."

The 30-second checklist before you hit Enter

• [ ] Did I paste project facts, or is Claude guessing the framework and packages?
• [ ] Is there exactly one task in this conversation?
• [ ] Did I ask for questions or a plan before code on anything non-trivial?
• [ ] Is the error output pasted in full, with suppression ruled out?
• [ ] Did I ask what was not verified?
• [ ] Will I run dotnet test myself before merging? (Always yes.)

I've shared four patterns here. I keep a longer set for reviews, refactors, architecture rules and TDD in a snippets file, and the habit that ties them together is simple: give facts, ask for decisions, demand proof.

Want the full prompt toolkit?

The Claude Playbook goes much further than this post: 150 copy-ready prompts in a searchable library, 8 before-and-after prompt makeovers that explain why each fix works, a start-to-finish walkthrough of building a tested app with Claude Code, and developer chapters on the API with Python, TypeScript and C# examples. You get an interactive HTML guide plus a 48-page PDF.

And if you'd rather practice on real code than toy examples, Tech Skill Builder gives you complete, working, tested .NET projects with full source code and step-by-step PDF guides, with new ones added regularly. Tech Skill Builder is $5/month for a very limited time only (normally $10). Grab it now before it goes back to $10. 👉 Join Tech Skill Builder

What's the worst "fix" an AI assistant has handed you in C#? I'll start: = null!; on 40 properties.