AI-Assisted Development: A Practical Guide for .NET Developers

What "AI-Assisted" Really Means

The word that matters is "assisted." An assistant does not set direction. It does not decide the data model, choose the folder layout, or accept its own work. In a healthy AI-assisted workflow, the developer is the architect and the reviewer, and the AI is the generator. The moment that relationship inverts — when the model is allowed to decide what to build and whether it is correct — you are no longer assisted, you are guessing.

This distinction is what separates AI-assisted development from a demo. A demo only has to run once in front of an audience. A production system has to survive migrations, new features, code review, and the next developer who reads the code. The assistant model protects all of that; the autopilot model quietly erodes it.

The Toolchain

Most .NET teams already have every tool they need. The categories below are not competitors so much as different scopes of the same idea: a model receives context, produces a completion, and the human decides whether to keep it.

In-IDE completion (GitHub Copilot)

Copilot lives inside the editor and completes as you type. Its strength is proximity: it sees the current file, nearby files, and the shape of what you just wrote. That makes it excellent at finishing a pattern you have already established and poor at inventing architecture. Give it a consistent codebase and it is fast; give it an inconsistent one and it amplifies the inconsistency.

Chat-style assistants (ChatGPT, Claude)

Chat assistants are best for reasoning and explanation: drafting a PRD, reviewing a design, or explaining an error. They are only as good as the context you paste in, which is why a self-contained, well-organised project is a prerequisite rather than a nice-to-have. They shine when you hand them one complete feature folder and ask a specific question about it.

Agentic coding agents (Cursor and similar)

Agents can read multiple files, run commands, and edit the codebase across several steps. That power multiplies both the value and the risk. An agent given explicit engineering rules and a reference implementation is genuinely productive; an agent turned loose on an undocumented solution will confidently produce a large diff that touches everything and satisfies nothing. Agents are the strongest argument for writing the rules down first.

What the tools have in common — they all live inside a context window

Regardless of interface, every one of these tools operates within a finite context window. The quality of what it produces is bounded by the quality and completeness of what fits inside that window. This single fact should drive your architecture and your project layout far more than any feature comparison. If a task requires six files to understand, you will pay for it on every prompt.

There is a second, quieter consequence. Because the window is finite, every irrelevant file you include is space taken from a relevant one. The goal is not to give the model more context; it is to give it the right context and nothing else. A feature folder that contains exactly the endpoint, the handler, the validator, the view, and the collocated script is not just tidy — it is the difference between a prompt that fits and a prompt that forgets.

The Workflow End to End

The workflow is a pipeline with a single input file and a clear owner at each stage:

1. Rules. Write down how the codebase is allowed to be built.
2. Data dictionary. Record the app, the personas, and the features with their taxonomy and stages.
3. FEATURE.md. Expand the dictionary into business requirements.
4. PRD.md. Turn requirements into a technical blueprint of entities, endpoints, and screens.
5. Implementation. Generate the application one feature at a time.
6. Review. Read the diff, run the build, and test at runtime.

Each stage consumes the output of the previous one, so a gap early on propagates all the way to the code. The full sequence, with the reasoning behind each step, is in AI-Assisted Development Workflow: From Requirement to Code.

What a Good AI Task Looks Like

A good AI task is small, scoped, and anchored to something that already exists. It names one entity or one behaviour, references the file that defines the pattern, and states the acceptance condition. Compare these two requests:

The strong task is not longer because it is polite; it is longer because it transfers knowledge the model would otherwise have to guess. That knowledge is the difference between a diff you can review in five minutes and a diff you have to rewrite.

Notice also what the strong task leaves out. It does not restate the architecture, because the rules file already does. It does not paste the reference implementation, because the model is expected to read it as part of the protocol. A task that repeats everything the project already documents is a sign that the documentation is not being used, and that is a workflow problem rather than a prompt-writing problem. Keep tasks focused on what is genuinely new: the entity, its fields, its stages, and the one behaviour that distinguishes it.

Keeping a Human in Control

Control is not a feeling; it is a set of concrete ownership boundaries. Four of them matter most.

A human owns the architecture

The human decides that one entity produces a controller, CQRS handlers, Minimal API endpoints, and Razor views with collocated .cshtml.js — not the AI. The human decides that folders are feature-first and that the reference implementations are Country for a pure master, Currency for a master with lookup, and Todo for a master-detail. Architecture chosen by a model changes between prompts; architecture chosen by a person stays stable.

A human owns the specification

The data dictionary is a human artefact. Personas, features, taxonomy, and stages are business decisions. When the specification is complete, the AI's job is mechanical translation; when it is incomplete, the AI fills the gap with plausible fiction.

A human reviews every diff

Generated code is a draft, not a commit. Reading the diff is where you catch the subtle failure — a query missing the soft-delete filter, a handler without a CancellationToken, a validator that disagrees with the PRD. The build will not catch these; only a person will.

The build gate — dotnet build with 0 errors

dotnet build

The build is the workflow's verification ceiling. After every feature, the AI runs dotnet build and fixes all errors until the count is zero. Note what this does and does not prove: it proves the code compiles and the references resolve, but it proves nothing about runtime behaviour. That is intentional — a human tests at runtime, and automation that pretends to replace that test is worse than no automation at all.

Common Mistakes

• Vague prompts. Asking for a "module" instead of a defined entity forces the model to invent the data model.
• No reference file. Without a canonical example, every generated file invents its own conventions.
• Accepting code you did not read. A clean build is not a review. Unread code is debt with extra steps.
• Skipping the build. Letting errors accumulate across features makes each subsequent fix harder and hides which change broke what.
• Letting the agent decide scope. Broad agent runs produce broad diffs; scope is a human decision.

Key Takeaways

• AI-assisted means the developer keeps architecture, specification, and review; the AI generates.
• Every tool — Copilot, chat, or agent — is bounded by its context window, so cohesion is a requirement, not a preference.
• The workflow runs rules → data dictionary → FEATURE.md → PRD.md → implementation → review.
• Good tasks are small, scoped, and backed by a reference implementation.
• dotnet build with 0 errors is the ceiling of automation; a human still tests at runtime.
• For the theory behind this practice, read the pillar guide to AI-assisted development.