AI-assisted development has moved well past autocomplete. A modern .NET workflow can include inline completions while you type, a chat pane that edits several files at once, an agent that works a GitHub issue into a pull request without you watching, and IDE-connected tools that let the model query your APIs, databases or ticket tracker through the Model Context Protocol. This guide is a practical map of that landscape for .NET developers in 2026: how GitHub Copilot's different modes work in Visual Studio and VS Code, how to steer them with custom instructions, how the Copilot coding agent and third-party agents such as Claude Code and OpenAI Codex fit into a GitHub workflow, where AI-assisted modernization tooling stands, and how to keep review, security and licensing discipline intact while using all of it.
What Counts as AI-Assisted .NET Development Today#
It helps to think of AI assistance as a spectrum rather than one feature. At one end, inline completions suggest the next few tokens as you type, and you stay in full control of every keystroke. Further along, chat lets you ask questions or request a change in natural language, and you review a proposed diff before accepting it. Agent mode goes further still: the model plans a multi-step change, edits multiple files, runs your build and tests, and iterates on failures with limited supervision. At the far end, coding agents work asynchronously on a GitHub issue or a natural-language task and open a pull request for you to review later, closer to delegating work to a teammate than to using a tool. All four levels are useful; the skill is picking the right one for the task and never skipping the review step just because the lower levels trained you to trust fast suggestions.
How Copilot's Modes Work in Visual Studio and VS Code#
GitHub Copilot ships the same underlying modes in both IDEs, with some UI differences:
| Mode | What it does | Typical scope |
|---|---|---|
| Completions | Suggests the rest of the current line or block as "ghost text" while you type | One edit location |
| Next edit suggestions | Predicts and highlights the next place you are likely to edit, based on the change you just made, not just the cursor position | A few nearby edit locations |
| Chat (ask) | Answers questions about the open code or a selection, with no file changes | Read-only, current context |
| Edit mode | Applies a requested change across one or more selected files as a reviewable diff | A few named files |
| Agent mode | Plans and executes a multi-step change: edits files, runs terminal commands, and iterates against build or test failures | A whole workspace, until the goal is met or you stop it |
Next edit suggestions matter for larger refactors: renaming a method or changing a signature often requires several correlated edits, and this mode chains you from one to the next instead of leaving you to search for the remaining call sites yourself. Agent mode is the mode to reach for when a task is well specified but mechanical across many files, such as adding a parameter to a widely used method and updating every caller; it is not a substitute for design decisions you have not made yet.
Getting Started: Agent Mode and MCP Servers in Your IDE#
Agent mode becomes far more useful once it can call tools beyond editing files, and the Model Context Protocol (MCP) is how you give it that access. In VS Code, MCP servers are configured per workspace in a .vscode/mcp.json file, or globally in user settings:
{
"inputs": [
{ "type": "promptString" }
],
"servers": {
"fetch": {
"command": "uvx",
"args": ["mcp-server-fetch"]
}
}
}Save the file, click the Start action that appears above the server entry, and the tools that server exposes become available to Copilot Chat once you switch the chat mode to Agent. VS Code also ships a curated MCP registry, reachable by searching @mcp in the Extensions view, for one-click installs of common servers instead of hand-writing configuration. Visual Studio (17.14 and later) configures MCP servers from the Copilot Chat tools picker instead of a JSON file directly, supporting both local, command-launched servers and remote, URL-and-credential servers such as an internally hosted one; either way, the servers themselves, and the tools they expose, are the same MCP servers regardless of which .NET IDE connects to them. Point Copilot at your own internal services, a database, or a work-item tracker through MCP rather than pasting that context into chat by hand, and its tool calls show up as reviewable steps in the conversation rather than opaque guesses.
Custom Instructions: Teaching Copilot Your .NET Conventions#
Left to its defaults, Copilot has no idea your team uses file-scoped namespaces, requires tests for public methods, or has banned a particular package. Custom instruction files fix that, and .NET tooling recognizes three kinds:
# .github/copilot-instructions.md — applies to every request in this repository
This is a .NET 10 solution using C# 14, minimal APIs and EF Core.
- Use file-scoped namespaces and nullable reference types everywhere.
- Prefer `IOptions<T>` for configuration; never read `IConfiguration` directly in a service.
- All public async methods must accept and propagate a `CancellationToken`.
- Do not add a new NuGet package without calling it out in the PR description.# .github/instructions/tests.instructions.md — applies only to files matching the pattern
---
applyTo: "**/*Tests.cs"
---
Use xUnit and `Assert.Equal(expected, actual)` ordering. One assertion focus per test.
Name tests `MethodName_Scenario_ExpectedResult`. Do not mock types you do not own.# AGENTS.md — repository root, read by Copilot's agent mode and by other coding agents
## Build and validate
- Build: `dotnet build`
- Test: `dotnet test`
- Before finishing a task, both commands must succeed with zero warnings.
## Conventions
- Follow the patterns in .github/copilot-instructions.md.
- Do not modify files under `/generated`; they are produced by a source generator.Repository-wide instructions in .github/copilot-instructions.md apply to every request; path-specific instructions in .github/instructions/*.instructions.md apply only to matching files and combine with the repository-wide file when both match; AGENTS.md is a cross-tool convention, read by Copilot's agent mode as well as by other agents, and is the right place for build, test and validation commands an autonomous agent needs before it can self-check its own work. Treat all three the way you treat prompt templates: reviewed, versioned, and specific rather than vague, since a one-line ambiguous instruction produces inconsistent results just as an ambiguous prompt does.
The Copilot Coding Agent: From Issue to Pull Request#
Assign an existing GitHub issue to Copilot, or start a task directly from the Agents view, and the coding agent works asynchronously in its own environment: it plans the change, edits the code, runs available checks, and opens a draft pull request when it believes the task is done. You review that PR like any other, and leaving a comment asking for a change sends the agent back to iterate, rather than requiring you to make the fix yourself. Before the PR is finalized, GitHub automatically scans agent-authored changes with CodeQL code scanning, secret scanning, and a dependency advisory check for newly introduced packages, which catches a meaningful class of mistakes, such as an accidentally hardcoded key or a dependency with a known critical vulnerability, before a human ever looks at the diff. Usage is metered separately from ordinary completions: each agent session consumes GitHub Actions minutes for the run itself plus AI credits based on the model and token volume, so a large, long-running task costs more than a short one, and it is worth scoping issues narrowly for both quality and cost reasons.
Other Coding Agents: Claude Code, OpenAI Codex and Choosing Between Them#
GitHub also supports third-party coding agents, currently Anthropic's Claude and OpenAI's Codex, alongside its own, and they can be assigned to the same issues, mentioned in the same pull request comments, and are subject to the same security scanning as the built-in agent. Enabling them is an account or organization policy decision, separate from enabling Copilot's own agent, and each one installs as its own GitHub App. Claude Code and Codex are also full standalone tools in their own right, run from a terminal or their own cloud environment against any repository, independent of GitHub's UI, which matters for workflows that live outside issues and pull requests, such as an interactive refactor session or a scripted batch task.
| Where you work | GitHub-native option | What it is best at |
|---|---|---|
| A GitHub issue or PR comment | Copilot coding agent, or Claude/Codex as third-party agents | Delegating a scoped, well-described task and reviewing the result later |
| Visual Studio or VS Code, interactively | Copilot chat and agent mode | Fast iteration with a human watching every step |
| A terminal, against any repository | Claude Code, OpenAI Codex CLI, or the GitHub CLI's gh copilot extension | Scripted or exploratory work outside the IDE, and CI-adjacent automation |
# The GitHub CLI's Copilot extension answers questions and suggests commands
# without leaving the terminal; useful for quick "how do I" moments mid-task.
gh copilot suggest "find every .cs file that still references the obsolete WebClient type"
gh copilot explain "dotnet ef migrations add InitialCreate"Which one wins for a given team usually comes down to where the work already happens and which model the task needs, not a fundamental capability gap; running the same well-scoped task through more than one agent occasionally is a reasonable way to build your own intuition instead of relying on marketing claims from any single vendor.
AI-Assisted Modernization for .NET#
Upgrading a large .NET Framework codebase to modern .NET is exactly the kind of mechanical-but-tedious work agents are well suited to: find every obsolete API, apply the same well-understood transformation, and verify the build still passes. Microsoft's tooling in this space has moved quickly and changed names more than once, so verify the current tool before you commit to it in a runbook: the original dotnet upgrade-assistant CLI is deprecated, its GitHub Copilot-based successor is also now deprecated, and current tooling ships as an agent distributed as a Copilot plugin, invoked from the Copilot app, the Copilot CLI, or as a cloud agent against a pull request, which assesses an application, proposes an upgrade plan, applies the changes, and validates the result. Whatever the tool is called by the time you read this, the shape of the work looks like a series of small, verifiable diffs rather than one giant rewrite:
// Before: synchronous WebClient, deprecated since .NET Core 2.1 and unsupported for new code.
public string DownloadReport(string url)
{
using var client = new WebClient();
return client.DownloadString(url);
}// After: async HttpClient from IHttpClientFactory, with cancellation support.
public sealed class ReportDownloader(IHttpClientFactory httpClientFactory)
{
public async Task<string> DownloadReportAsync(string url, CancellationToken cancellationToken)
{
using HttpClient client = httpClientFactory.CreateClient(nameof(ReportDownloader));
return await client.GetStringAsync(url, cancellationToken);
}
}An agent can propose this kind of change across hundreds of call sites quickly, but it cannot decide your target framework, your dependency-injection lifetime rules, or which callers should now propagate a CancellationToken all the way to an HTTP endpoint; those are architectural decisions that still need a person. For the broader migration strategy beyond individual API swaps, see Modernizing .NET Framework Applications to Modern .NET.
Review Discipline: Treat AI Output Like Any Other Contributor's Code#
The review bar for AI-generated code should not be lower than for a human contributor's, and in practice it often needs to be higher, because the code can look confident and idiomatic while resting on a subtly wrong assumption, such as a misunderstood null-handling convention or an invented configuration key. Practical habits that hold up:
- Require the same tests, static analysis and CI gates for AI-authored and agent-authored changes as for anything else; never merge on the strength of "the agent said it built and tests passed" without your own read of the diff.
- Use Copilot's own code review feature as a fast first pass that catches obvious issues, not as a replacement for a human reviewer's judgment on design and correctness.
- Read generated tests as carefully as generated production code. A test that always passes, or that asserts against the code's own (wrong) output, is worse than no test.
- For a large agent-driven change, review it in the same small, logically grouped commits you would ask a human to produce, rather than one enormous diff.
Security and Licensing Considerations#
Two risks are specific to AI-assisted coding rather than coding in general. The first is leakage: anything you paste into a chat prompt, or that an agent reads while working, can leave your network if it is sent to a hosted model, so keep secrets out of prompts and out of repositories an agent has access to, and prefer the same approaches covered in Secrets Management in .NET over hardcoding credentials an assistant might later read or reproduce. The second is provenance: a suggestion can closely resemble code the model was trained on, which is why Copilot for Business and Enterprise offer an optional filter that blocks suggestions matching public code above a configurable length, and why security scanning on agent PRs, covered above, checks newly introduced dependencies rather than trusting them by default. Apply the same tool-permission thinking from Responsible AI and LLM Security for .NET Applications to a coding agent as you would to any other autonomous tool: scope its repository and credential access to what the task needs, and require approval before it can merge or deploy anything itself.
What the Evidence Says About Productivity#
Be skeptical of any single headline number here, in either direction. Vendor-sponsored studies tend to measure narrow, well-scoped tasks, such as writing a unit test or a boilerplate function, where assistants reliably do well and speed gains are large and easy to demonstrate. Independent research paints a more mixed picture once the task is a complex change in a large, unfamiliar-to-the-model codebase: some studies of experienced developers working in their own mature repositories have found AI assistance producing no clear speedup, or even a slowdown, once the time spent prompting, reviewing and correcting the output is counted. The honest summary is that the effect is highly task-dependent: strongest for greenfield code, boilerplate, tests and familiar patterns, weakest for large, tightly coupled, poorly documented legacy systems where understanding the existing code is the actual bottleneck, not typing speed. Rather than trust a general percentage, measure your own team on signals you already track, such as cycle time, PR review time and change failure or revert rate, before and after adopting a given tool or workflow, and treat that as the number that matters for your codebase.
Best Practices#
- Match the mode to the task. Use completions and chat for small, supervised changes; reserve agent mode and coding agents for well-scoped, mechanical or clearly specified work.
- Write instructions files early and keep them current. A
copilot-instructions.mdandAGENTS.mdthat describe your real conventions pay for themselves across every future suggestion and agent run. - Connect tools through MCP instead of pasting context by hand, so the model queries live data and its tool calls stay visible and auditable.
- Scope coding agent tasks narrowly. Small, well-described issues produce reviewable pull requests; vague, sprawling ones produce vague, sprawling diffs.
- Never relax your review or CI bar for AI-authored or agent-authored code. Automated security scanning on agent PRs is a floor, not a substitute for a human reviewer.
- Measure your own team's outcomes instead of relying on a vendor's or a blog post's productivity claim.
Common Pitfalls#
- Accepting agent-mode changes without reading the diff, because the build passed and the agent sounded confident.
- Pasting proprietary code or secrets into chat to give the model context, instead of connecting it to the actual system through MCP or a scoped instructions file.
- Writing instructions files once and never updating them, so they drift from the codebase's real conventions and start producing worse suggestions than no instructions at all.
- Treating a coding agent like a full replacement for a teammate on tasks that need architectural judgment, not just mechanical edits.
- Assuming a modernization tool's name and behavior from an old blog post. This space has renamed and re-released its core tooling more than once; check what currently ships before you plan around it.
- Quoting a single productivity study as settled fact, in either direction, instead of validating impact against your own team's metrics.
Frequently Asked Questions#
Is GitHub Copilot's agent mode the same thing as the Copilot coding agent?#
No. Agent mode runs locally in your IDE, with you present and able to interrupt it at any point. The Copilot coding agent runs asynchronously in its own cloud environment against an assigned issue or task and opens a pull request when it is done, without needing you to watch it work.
Do I need an MCP server to use Copilot effectively?#
No, MCP is optional. Completions, chat and agent mode all work without any MCP server configured. MCP becomes valuable once you want the model to pull live, structured context from your own systems, such as an internal API or issue tracker, instead of relying only on what is open in the editor.
Can I use Claude Code or OpenAI Codex instead of GitHub Copilot for a .NET project?#
Yes. Both work against any repository from their own terminal or cloud environment, independent of GitHub's Copilot product, and both can also be enabled as third-party coding agents inside GitHub's own issue and pull request workflow. Choice usually comes down to model preference, existing licensing and where your team already works.
Should AGENTS.md replace .github/copilot-instructions.md?#
Not necessarily; they serve overlapping but distinct purposes. copilot-instructions.md is Copilot-specific and read for every request; AGENTS.md is a cross-tool convention aimed at autonomous agents and is a natural place for build and validation commands. Many repositories keep both, with AGENTS.md referencing the Copilot-specific file for style rules.
Is AI-generated .NET code safe to ship without extra review?#
No. Treat it like any other contributor's code: run your full test suite and static analysis, and have a human review the diff. Automated scanning on coding-agent pull requests catches some classes of problems, such as hardcoded secrets or clearly vulnerable dependencies, but it does not verify business logic or architectural fit.
Summary#
- AI assistance spans a spectrum from inline completions to fully asynchronous coding agents; match the mode to how well-specified and mechanical the task is.
- MCP servers give agent mode access to live tools and data instead of pasted-in context, configured per IDE but based on the same open protocol.
.github/copilot-instructions.md, path-specific*.instructions.mdfiles andAGENTS.mdeach teach different scopes of convention to Copilot and other agents.- The Copilot coding agent and third-party agents such as Claude Code and Codex can work a GitHub issue into a reviewable pull request, with automated security scanning as a floor, not a substitute for review.
- .NET modernization tooling in this space changes names quickly; verify the current tool rather than trusting an older reference.
- Treat AI-authored code, and any productivity claim about the tools that wrote it, with the same scrutiny you would apply to any other unverified source.