AI Code Review for C# and .NET

Why .NET legacy codebases are hard to audit

Enterprise .NET projects carry a unique form of technical debt: framework migration debt. A codebase that started on .NET Framework 4.5 and migrated through .NET Core 3.1 to .NET 8 often contains layers of each era. You find System.Web references alongside minimal API endpoints, .csproj files mixing SDK-style and legacy formats, and NuGet packages pinned to versions that no longer receive security patches.

Dependency injection compounds the problem. Early modules might use a static service locator or manual instantiation, while newer code relies on constructor injection through the built-in DI container. Some classes register services as singletons that hold mutable state. Others resolve scoped services from a root provider, causing subtle lifetime bugs that only surface under load. The inconsistency makes it difficult to reason about object lifetimes without reading every registration and every constructor across the solution.

Async/await misuse is pervasive in codebases that predate C#'s mature async patterns. Calling .Result or .Wait() on tasks blocks threads and risks deadlocks in ASP.NET contexts. Fire-and-forget Task.Run calls discard exceptions silently. Missing ConfigureAwait(false) in library code ties operations to the synchronisation context unnecessarily. These issues are scattered across hundreds of files and invisible to a quick code search.

What Roslyn analyzers and ReSharper miss

Roslyn analyzers, ReSharper, and SonarQube for .NET are effective at catching local code smells – unused variables, redundant casts, naming convention violations. But they operate file-by-file with limited cross-project awareness.

Consider an Entity Framework DbContext registered as scoped in one project, but injected into a singleton service in another project within the same solution. The analyzer sees valid code in each file. The architectural mismatch – a scoped dependency captured by a singleton – only becomes visible when you trace the DI registration graph across project boundaries. That trace requires reading multiple Startup.cs or Program.cs files and correlating them with constructor signatures in service classes.

Entity Framework N+1 queries are another blind spot. A LINQ query that looks clean in isolation can trigger hundreds of database round-trips when navigation properties are accessed in a loop downstream. Finding these patterns requires understanding how query results flow through service layers and into view models or API responses – context that spans multiple files and assemblies.

Enterprise .NET solutions also accumulate dead abstractions: interfaces with a single implementation, repository wrappers around Entity Framework that add no value, and layers of indirection from a 2015-era architecture initiative that nobody followed through on. Static analysis does not flag these because each class is syntactically valid. Identifying them requires understanding intent, not just syntax.

How VibeRails reviews C# and .NET projects

VibeRails performs a full-codebase scan using frontier large language models. Every .cs, .csproj, .sln, configuration, and migration file is analysed – not just recent diffs, but the entire solution including test projects, build scripts, and deployment configurations.

For C# and .NET code specifically, the AI reasons about:

• Framework migration debt – mixed project formats, dead System.Web references, packages targeting deprecated .NET Standard versions, stale web.config files alongside appsettings.json
• Dependency injection issues – lifetime mismatches between registrations and consumers, service locator anti-patterns, singletons capturing scoped dependencies, ambiguous registrations
• Async/await misuse – synchronous blocking on async calls, fire-and-forget tasks, missing cancellation token propagation, unnecessary async methods that return completed tasks
• Entity Framework patterns – N+1 query paths, mixed raw SQL and LINQ, inconsistent DbContext lifetimes, missing AsNoTracking on read-only queries
• Dead abstractions – interfaces with single implementations, unused repository layers, over-engineered mediator patterns, empty base classes
• Security – SQL injection through string concatenation, insecure deserialization, missing authorization attributes on controllers, hardcoded connection strings

Each finding includes the file path, line range, severity level, category, and a description with suggested remediation. The structured output turns a sprawling .NET solution into an organised inventory of improvements prioritised by risk.

Dual-model verification for .NET

Enterprise .NET codebases contain patterns that are genuinely ambiguous. Is that service locator usage a deliberate design choice for a plugin system, or leftover code from before the team adopted DI? Is the synchronous .Result call in a console app actually fine, or is it a copy-paste from ASP.NET code where it would deadlock?

VibeRails supports running reviews with two different AI backends – Claude Code and Codex CLI – in sequence. The first pass discovers issues, the second verifies them using a different model architecture. When both models flag the same DI lifetime mismatch or async anti-pattern, confidence is high. Disagreements highlight areas that warrant closer human review during triage.

From findings to fixes

After triaging findings, VibeRails can dispatch AI agents to implement fixes directly in your local repository. For .NET projects, this typically means replacing service locator calls with constructor injection, adding ConfigureAwait(false) to library async methods, converting synchronous blocking to proper await chains, removing dead interfaces, and adding AsNoTracking to read-only EF queries.

Each fix is generated as a local code change you can inspect, test, and commit or discard. The AI works within the conventions of the existing codebase, matching the solution's namespace structure, coding style, and framework version.

VibeRails runs as a desktop app with a BYOK model – it orchestrates Claude Code or Codex CLI installations you already have. No code is uploaded to VibeRails servers. AI analysis is sent directly to the provider you configured, billed to your existing subscription. The lifetime license is $299 per developer for the lifetime option (or $19/mo monthly). The free tier includes 5 issues per session to evaluate the workflow.