AI-Assisted Development with ASP.NET Core

ASP.NET Core has spent years accumulating conventions: controllers, Razor views, dependency injection, EF Core, model binding, and a build CLI that either succeeds silently or tells you exactly what broke. Those conventions are what make the framework an unusually good host for AI-assisted development. A coding agent does not have to be insightful when the framework already dictates where files live and how they are shaped — it only needs an explicit rules file and one reference implementation to copy.

This article explains why ASP.NET Core fits the workflow, what an agent can produce from a single entity class, which conventions it can lean on, and how dotnet build becomes the gate that keeps every generated feature honest. For the wider, human-directed process behind it, start with the pillar guide to AI-assisted development.

Why ASP.NET Core Fits AI-Assisted Development

AI models generate reliable code when the target is predictable, and ASP.NET Core is predictable in exactly the ways that matter:

• There is one obvious place for everything. Controllers, views, and endpoints have conventional homes, and the dependency injection container is configured in one pipeline. An agent learns the map once and reuses it for every feature.
• The compiler verifies the agent's work. C# is strongly typed, so a missing cancellation token, a mismatched DTO, or a forgotten namespace fails at build time rather than in production.
• The tooling gives a real feedback loop. dotnet build returns a machine-readable verdict in seconds, which means the agent can check its own output without a human interpreting logs.
• The patterns are copyable. Minimal API endpoints, CQRS handlers, FluentValidation validators, and Razor views all share a canonical shape. Show the agent one, and it can generate twenty.

What the framework does not supply is a written contract for the conventions you require. Without one, the model invents a plausible but inconsistent style for every file. With one, it produces slices that look like they were written by the same developer on the same day.

One Entity, a Full Feature

The central promise of this workflow is small to state and large in effect: one entity class becomes one complete feature. From a single entity — say Asset — the agent generates the controller, the CQRS handlers, the validators, the Minimal API endpoints, the Razor views, and the collocated JavaScript that binds them.

For an entity named Asset, the generated slice contains:

• A Controller that serves the Razor pages and delegates work to handlers.
• GetAssetListHandler and GetAssetByIdHandler for reads.
• CreateAssetHandler and UpdateAssetHandler, each paired with a FluentValidation validator.
• DeleteAssetHandler, which performs a soft delete rather than removing the row.
• A GetAsset{Lookup}LookupHandler whenever the entity feeds a dropdown.
• Endpoints/AssetEndpoint.cs, mapping the Minimal API routes for the slice.
• Razor views Index.cshtml, Create.cshtml, Edit.cshtml, and Detail.cshtml, plus a collocated .cshtml.js file for each page.

That is eighteen or more files from one input. The value is not raw speed; it is consistency. Every file is derived from the same reference implementation and the same rules, so the slice reads as a single coherent feature instead of a pile of independently invented pages.

Conventions the AI Can Rely On

Four framework conventions carry most of the weight. Each one removes a decision the agent would otherwise make by guessing.

Feature folders and Areas

MVC Areas give each business domain a home: Areas/{Area}/{Entity} holds the controller and views for one entity. Within that folder, a Cqrs folder holds the handlers and validators, and an Endpoints folder holds the Minimal API mapping. Because everything for a feature is colocated, the agent never has to search the solution to understand a slice — and neither does a new developer. The same reasoning is why an AI-ready project structure matters more than it first appears.

CQRS and Minimal API endpoints

Each operation is a request with a dedicated handler. Commands mutate state; queries read it. Handlers are dispatched by MediatR, and Minimal API endpoints expose them over HTTP. Two rules make this predictable: the last segment of a route names the entity, so a lookup for a related table is /api/{entitylower}/{lookupentitylower}-lookup, and every handler and endpoint accepts a CancellationToken. The token on a Minimal API lambda is bound to HttpContext.RequestAborted, which keeps long queries cancellable.

EF Core and the DbContext

Handlers talk to a single DbContext and use EF Core directly, with no repository abstraction wrapped around it. The context owns the global query filters for soft deletes and the configuration that turns an entity property into an AutoNumber column. Because there is one context and one configuration style, the agent can add an entity and its EF configuration without inventing new infrastructure.

FluentValidation

FluentValidation is the single source of truth for validation. The database stays open: no data annotations on entities, no duplicated rules hiding in attributes. A CreateAssetValidator and an UpdateAssetValidator sit next to their handlers, so the agent learns validation once and applies it everywhere. This separation is what lets one model serve both the web forms and the API without rule drift.

A Rules File for ASP.NET Core

Conventions cover structure; a rules file covers the decisions those conventions leave open. The rules file is authoritative, and the agent reads it before writing anything. In this workflow it is a single document, commonly named SKILL-SOFTWARE-ENGINEERING.md, that states the non-negotiables:

• Naming. Handlers are named for the entity and the operation (GetAssetListHandler, CreateAssetHandler), and routes take the entity's name.
• Soft delete only. Records are never physically removed. The context applies a global query filter, handlers set an IsDeleted flag, and code never writes !x.IsDeleted or calls .Remove().
• CancellationToken everywhere. Every CQRS handler and every endpoint accepts and forwards a cancellation token.
• AutoNumber is mandatory. Every entity implements IHasAutoNumber and gets a business reference in the format {ToShortNameConsonant(3)}/{Year}/{4-digit}, for example ASS/2026/0001. It is never a form field; it is always a DataTable column and an Audit Trail value.
• The build gate. After every feature, dotnet build must report zero errors before the next one begins.

The rules reserve particular care for file generation, because an entity's type determines its shape. A Pure Master has no foreign key and no child collection. A Master with Lookup carries a string {X}Id plus a {X}? {X} navigation. A Master-Detail declares ICollection<T>? Items. The agent detects the type from the entity and then follows the matching reference.

// The token is mandatory, and so is the entity-named route segment.
app.MapGet("/api/asset/{id}", async (int id, IMediator mediator, CancellationToken ct) =>
{
    var result = await mediator.Send(new GetAssetByIdQuery(id), ct);
    return result.IsSuccess ? Results.Ok(result.Value) : Results.NotFound(result.Errors);
});

The rules also encode a read-first protocol: before writing a single file, the agent reads the canonical reference for the entity type in full. Country is the Pure Master example, Currency is the Master with Lookup example, and Todo is the Master-Detail example. Read first, then generate.

Buildable Output Is the Gate

The workflow has a deliberately low ceiling for automated verification: dotnet build with zero errors. That is not the whole definition of correct software, and the rules say so openly. After every feature is generated, the agent builds. If the build fails, it fixes the errors and builds again before moving on. A feature that does not compile is not "mostly done"; it is not done.

Two honest caveats keep the gate meaningful. First, the agent never runs the application — a human tests at runtime. Compilation proves the code is well-formed, not that a form posts the right value or that a lifecycle transition is allowed. Second, JavaScript is not compiled by dotnet build, so a collocated .cshtml.js file can still be broken. The rules close that gap by requiring a brace-balance check or node --check on every generated script.

A Worked Example: the Asset Feature

The reference application used to demonstrate this workflow is an ASP.NET Core asset management system. Its entities include Branch, Department, Manufacture, Vendor, Depreciation, AssetModelGroup, AssetModelSubGroup, AssetModel, Asset, and Employee. It is a real example application, not the Indotalent webstore, and it was chosen because its relationships exercise every entity type the rules describe.

Building the Asset feature follows the workflow directly. The entity is a Master with a lookup to AssetModel, so the agent produces the entity-named controller, the read and write handlers, the validators, the lookup handler, the endpoint file, and the four Razor pages with their collocated scripts. AutoNumber gives each asset a reference like ASS/2026/0001; the asset model gets its own AST/2026/0001. The lifecycle is modeled as the AssetStage enum — ReadyToAssigned, Assigned, Repair, Quarantine, Missing — which the agent turns into a typed status field with a DataTable column and an Audit Trail value.

Attachments, such as asset photos or handover documents, follow the same pattern: a child collection on the entity, generated from the Master-Detail reference. After each addition the agent runs the build, fixes any errors, and only then continues. The result is a feature that compiles cleanly, follows the house conventions, and is ready for a human to exercise in the browser.

Key Takeaways

• ASP.NET Core's strong conventions make it a natural host for AI-assisted development — the agent needs a rules file and a reference implementation, not inspiration.
• One entity class drives a full slice of eighteen or more files: controller, CQRS handlers, validators, endpoints, Razor views, and collocated JavaScript.
• Feature folders, CQRS with entity-named routes, one EF Core context, and FluentValidation are the conventions the agent can rely on.
• The rules file makes naming, soft delete, cancellation tokens, and AutoNumber non-negotiable.
• dotnet build with zero errors is the gate after every feature; a human still tests the running application.