{"slug": "how-to-make-ai-write-high-quality-code-in-net", "title": "How to Make AI Write High-Quality Code in .NET", "summary": "A .NET developer describes how to make AI coding agents produce high-quality C# code by encoding standards in build-time enforcement rather than prompts. The approach centers on a Directory.Build.props file with settings such as TreatWarningsAsErrors, AnalysisMode All, and EnforceCodeStyleInBuild, so that an agent's dotnet build output surfaces violations as errors it must fix before a human reviews the diff. The developer argues prompt-based rules degrade as session context fills, while build-enforced rules are followed every time.", "body_md": "AI writes .NET code faster than anyone on your team.\n\nIt can also write code that looks good but can fall apart during careful review.\n\nI have spent years improving the quality of code I write, long before the AI was around.\n\nI learned to write code that is easy to read and maintain, and I have been refining my skills ever since.\n\nNow I'm doing the same by teaching AI agents to write code with the same quality I do.\n\nBut most developers fail to get AI to write high-quality, clean code.\n\nThe reason is simple. The AI followed the rules it could see, and it never saw yours.\n\nMost developers try to fix this by putting the rules in the prompt.\n\nI tried that for many months.\n\nThe rules work for a few files, maybe a few iterations in a session.\n\nBut as the session goes on, the context gets loaded with information, and your rules start to be ignored.\n\nSo only two things actually work reliably that I want to show you today:\n\nIn this post, we will explore:\n\nLet's dive in.\n\nš **Read original article on my newsletter:** [https://antondevtips.com/blog/how-to-make-ai-write-high-quality-code-in-dotnet](https://antondevtips.com/blog/how-to-make-ai-write-high-quality-code-in-dotnet)\n\nEvery .NET solution should start with a `Directory.Build.props` file. This file defines project-wide settings that apply to all projects in your solution.\n\nWithout this file, you end up duplicating the same configuration across multiple `.csproj` files.\n\nWhen you want to change a setting, you have to update every project file by hand. This leads to inconsistencies and wasted time.\n\n`Directory.Build.props` solves this problem by centralizing configuration in a single file.\n\nYou create this file in the same directory as your `.sln` file, and MSBuild applies it to all projects in the solution.\n\nHere is the configuration I use for every new project:\n\n```\n\n \n enable\n enable\n latest\n All\n true\n true\n true\n \n\n```\n\n**Here is what each setting does:**\n\n**Nullable:** Enables nullable reference types, which help prevent null reference exceptions. The compiler warns you when you might be using a null value incorrectly.\n\n**ImplicitUsings:** Adds common namespace imports to every file. You don't need to write `using System;` or `using System.Linq;` anymore.\n\n**AnalysisLevel:** Sets the code analysis level to the latest version. You get the most recent code quality checks from Microsoft.\n\n**AnalysisMode:** Turns on all code analysis rules. This gives you the most feedback on code quality.\n\n**TreatWarningsAsErrors:** Stops compilation if there are any warnings. This forces you to fix issues right away instead of letting them pile up.\n\n**CodeAnalysisTreatWarningsAsErrors:** Applies the same strict treatment to code analysis warnings.\n\n**EnforceCodeStyleInBuild:** Runs code style checks during build, not just in the IDE. Your CI/CD pipeline will catch style violations.\n\nNow here is why this file matters more than ever.\n\nAn AI agent doesn't read your standards. It runs `dotnet build`, and it reads the output.\n\n`TreatWarningsAsErrors` turns every analyzer rule into a build error. The agent detects the error, fixes it, and rebuilds. That loop runs before you ever open the diff.\n\nWithout this one line, the same rules become warnings. Warnings can get ignored by agents.\n\nThat is the pattern behind everything below. A rule the build enforces gets followed every time, and a rule that only lives in a document gets skipped as soon as the agent has busy context.\n\nCode quality is something you need to care about from day 1.\n\nIt's easier to follow the best coding practices than to fix them later.\n\nFor this, we can use static code analysis.\n\nStatic code analyzers examine your code without running it.\n\nThey catch common mistakes, enforce coding standards, and find potential bugs before they reach production.\n\nSome of the analyzers can even catch code quality issues.\n\nThey can detect:\n\nThe analyzers run during compilation, so you get feedback right away in your IDE and in your CI/CD pipeline.\n\nAdd these analyzer packages to your `Directory.Build.props` file:\n\n```\n\n \n enable\n enable\n latest\n All\n true\n true\n true\n \n\n \n \n runtime; build; native; contentfiles; analyzers; buildtransitive\n \n \n runtime; build; native; contentfiles; analyzers; buildtransitive\n \n \n runtime; build; native; contentfiles; analyzers; buildtransitive\n \n \n runtime; build; native; contentfiles; analyzers; buildtransitive\n \n \n\n```\n\n**Here is what each analyzer provides:**\n\n**SonarAnalyzer.CSharp:** Focuses on code quality, security holes, and code smells. It finds complex methods, duplicated code, and potential bugs.\n\n**Meziantou.Analyzer:** Catches performance issues, security holes, and incorrect API usage. It has hundreds of rules covering async/await patterns, LINQ usage, string handling, and more.\n\n**Roslynator.Analyzers:** Provides code analysis and refactoring suggestions. It helps you write cleaner, more idiomatic C# code.\n\n**xunit.analyzers:** Makes sure you write tests correctly. It catches common testing mistakes, such as missing assertions or wrong test attributes.\n\nThe `IncludeAssets` configuration makes sure that these analyzers run during compilation but don't get included in your published application.\n\nWith `TreatWarningsAsErrors` enabled, your build will fail if any analyzer finds an issue. This might seem strict, but it stops technical debt from piling up.\n\nYou should always aim for zero warnings in your project. Many developers ignore warnings, but warnings often point at real problems that will cause bugs later.\n\nThese four packages carry thousands of rules between them. That's thousands of rules an AI agent has to satisfy, and none of them cost you a single line in a prompt.\n\nFor more information about code quality best practices, check out this [article](https://antondevtips.com/blog/best-practices-for-increasing-code-quality-in-dotnet-projects).", "url": "https://wpnews.pro/news/how-to-make-ai-write-high-quality-code-in-net", "canonical_source": "https://dev.to/antonmartyniuk/how-to-make-ai-write-high-quality-code-in-net-2d4l", "published_at": "2026-10-06 11:10:00+00:00", "updated_at": "2026-10-06 11:18:00.201478+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": [".NET", "MSBuild", "Directory.Build.props", "Microsoft"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-make-ai-write-high-quality-code-in-net", "markdown": "https://wpnews.pro/news/how-to-make-ai-write-high-quality-code-in-net.md", "text": "https://wpnews.pro/news/how-to-make-ai-write-high-quality-code-in-net.txt", "jsonld": "https://wpnews.pro/news/how-to-make-ai-write-high-quality-code-in-net.jsonld"}}