AI-Assisted Development for .NET Developers

What Is AI-Assisted Development?

AI-assisted development is often described as "using AI to write code." That definition is too thin to be useful. A more accurate one is this: a disciplined loop in which a human developer owns the architecture, the engineering rules, and the requirements, while an AI coding tool performs scoped generation against that specification. The human reviews, builds, and ships the result.

The distinction matters because it changes who is responsible for correctness. When the AI drives the process, nobody owns the design. When the human drives it, the design is explicit and the AI becomes a fast, tireless implementer that fills in the parts a human already decided. For a longer treatment of the end-to-end process, see the practical guide for .NET developers.

This is not vibe coding. Vibe coding asks a model to invent requirements, architecture, naming, and constraints at the same time it writes code. AI-assisted development separates those concerns on purpose: the human resolves ambiguity first, and the AI executes inside a boundary that is already defined.

The Problem With One-Shot Prompting

The tempting shortcut is a single giant prompt: "Build me an inventory management system with orders, customers, and reports." It works for a throwaway demo and collapses on a real project, for reasons that have nothing to do with model quality:

• Ambiguity is hidden, not solved. "Inventory tracking" can mean a dozen schemas. The model picks one silently, and it is rarely the one you wanted.
• Constraints are missing. Nothing in the prompt says how IDs are generated, how records are deleted, how validation is expressed, or how errors are returned.
• There is no reference pattern. Without an existing file to imitate, the model invents a different style for every file, and the codebase becomes a patchwork.
• Long prompts lose their own tail. Instructions near the top of a very long prompt are effectively forgotten by the time generation reaches the end.

The entire failure mode is analysed in depth in Why One-Shot AI Prompts Fail for Software Development. The short version: a one-shot prompt asks the model to do specification and implementation in the same pass, and it is bad at both simultaneously.

Human Directs, AI Executes

The responsibility split is the whole discipline. It is worth stating explicitly, because most failed AI projects blur it.

• The human owns architecture. Project layout, boundaries, folder conventions, and which patterns are allowed.
• The human owns the specification. Data model, relationships, lifecycle rules, and feature scope.
• The human owns acceptance. Reading every diff, running the build, and testing at runtime.
• The AI owns generation. Turning a settled specification into files that conform to the rules and the reference implementation.

This is the difference between human-directed and AI-directed development. In the human-directed model the AI is powerful precisely because its scope is narrow: it does not have to guess, so it does not have to be lucky.

The Six Steps of the Workflow

Every article in this series elaborates one of these steps. Read together, they form a complete, repeatable pipeline from an idea to reviewed code.

1. Software Engineering Skill / Rules

Before any generation, you write down the rules the AI must obey: how files are named, how many files one entity produces, how numbers are generated, how deletion works, how cancellation is handled, and where validation lives. These rules become an authoritative document the AI reads on every task. See Software Engineering Rules for AI Coding Agents.

2. Data Dictionary

The data dictionary is the single input file a developer is expected to fill in. It records the application name and short name, the personas, and every feature with a group/subgroup taxonomy and a stage enum. It is deliberately plain so that a domain expert, not just a developer, can complete it. See Data Dictionary for AI-Assisted Software Development.

3. Feature Requirements

From the dictionary, features are expanded into concrete requirements: what each screen does, which fields it shows, which roles can reach it, and how the stages flow. This is the bridge between a noun and a behaviour. See AI-Assisted Development Workflow: From Requirement to Code.

4. PRD.md

The product requirements document is generated next and becomes the technical blueprint: entities, fields, types, relationships, endpoints, and UI surfaces. It is the document the AI consults while implementing, so it must be precise and internally consistent. See How to Write a PRD for AI-Assisted Development.

5. AI Implementation

Only now does code generation begin, and it begins one feature at a time. Each feature is built against the rules and the reference implementation, then compiled. See AI-Assisted CRUD Development with ASP.NET Core MVC.

6. Human Review

The loop closes with a human reading the generated code, running the build, and testing behaviour at runtime. Generation without review is just a faster way to accumulate debt. See Human-Directed vs AI-Directed Software Development.

Why Architecture Matters for AI

AI tools operate inside a context window. They can reliably see the file being edited plus a limited amount of surrounding context. The practical consequence is that architecture is no longer only a human concern — it is a context-management strategy. An AI-ready .NET project structure keeps everything a feature needs in one place, so the model does not have to reconstruct relationships across scattered projects.

This is where most teams waste tokens. They paste five files into a chat to explain a single change, or they let an agent search the whole solution on every request. The fix is not a bigger context window; it is cohesion. When one feature is one folder, the context is small, complete, and cheap. The techniques are covered in How to Give AI Enough Context Without Wasting Tokens.

Why Vertical Slice Architecture Works With AI Context

Vertical Slice Architecture takes cohesion to its logical end: a feature owns its endpoint, its handler, its validation, its queries, and its views, all in one folder. For an AI, that means a single file or folder is often enough to understand an entire capability. There is no hopping between a domain project, an application project, and a persistence project to answer a question about one field.

The full argument, with concrete before-and-after examples, is in Why Vertical Slice Architecture is the Best Architecture for AI-Assisted Development. The short version: what makes code easy for a human to reason about is exactly what makes it easy for a model to complete correctly.

A Real ASP.NET Core Example

The workflow is easier to trust once you see it run. A real ASP.NET Core sample application, Asset Manager, demonstrates the whole pipeline. It manages branches, departments, manufacturers, vendors, depreciation, asset model groups and subgroups, asset models, assets with image and file attachments, and employees that extend the identity user. Its lifecycle is modelled by an AssetStage enum that moves from ReadyToAssigned to Assigned, Repair, Quarantine, and Missing.

The developer fills exactly one file, .ai-assisted/DATA-DICTIONARY.md, with the application name and short name, the personas (Admin, Member, Guest), and the main features, each with a group/subgroup taxonomy and a stage enum. Then the developer gives the AI a single instruction:

start the development

ORCHESTRATOR.md drives everything from there. Gate 0 checks AppSettings:Name in appsettings.json. If the value is Indotalent, the workflow proceeds; otherwise it stops, because the application has been customized and the developer is now in maintenance mode. From there the orchestrator reviews the data dictionary, Phase 0 generates FEATURE.md as the business source of truth, Phase 1 runs PROMPT.md to produce PRD.md as the technical blueprint, and Phase 2 builds the application feature by feature — running dotnet build and fixing every error after each feature until there are zero errors.

What the AI produces per entity is not a single class. A dedicated skill, SKILL-SOFTWARE-ENGINEERING.md, dictates that one entity class yields eighteen or more files: a controller, CQRS handlers, Minimal API endpoints, Razor views with collocated .cshtml.js, and the supporting wiring. The skill also enforces the details that keep generated code consistent — the READ-FIRST protocol, where the AI reads a canonical reference implementation in full before writing anything (Country as Pure Master, Currency as Master with Lookup, Todo as Master-Detail); mandatory AutoNumber via IHasAutoNumber in the format {ToShortNameConsonant(3)}/{Year}/{4-digit}, producing values like PRD/2026/0001 or ASS/2026/0001; soft delete only, enforced by a global query filter, so the AI never writes !x.IsDeleted and never calls .Remove(); and a mandatory CancellationToken on every CQRS handler and every Minimal API endpoint. The build itself is the verification ceiling — never run the app, because a human tests it at runtime. The ASP.NET Core specifics are covered in AI-Assisted Development with ASP.NET Core.

Start With the AI-Ready .NET Starter

The fastest way to adopt this workflow is to start from a solution that already implements it. The MVC EDevKit ASP.NET Core MVC AI-Ready starter ships with the rules, the orchestrator, the skills, and the reference implementations in place. You fill in one data dictionary, tell the AI to start, and review the result — instead of building the guardrails from scratch on your first project.