Agent-Mode | The .NET Blog

Autonomous Development Within VS Code: GitHub Copilot Coding Agent Arrives

Emiliano Montesdeoca — Fri, 14 Aug 2026 00:00:00 +0000

Original source: Command GitHub’s Coding Agent from VS Code

Autonomous Development Within VS Code: GitHub Copilot Coding Agent Arrives

There’s a difference between an AI that suggests code and an AI that completes tasks.

VS Code’s agent mode was the former: chat with an AI, ask it to modify files, and approve tool calls. Powerful, but synchronous. You’re still in the loop, making decisions.

GitHub’s Copilot Coding Agent is different. You assign it an issue. It spins up a temporary development environment. It explores your codebase, makes changes, runs tests, and opens a pull request. Then it waits for your feedback.

And now, you can do all of that—assign, track, review, and iterate—without switching to GitHub.com. It’s all in VS Code.

That’s not just convenience. That’s a different workflow.

How Copilot Coding Agent Works

The flow is simple:

Enable the agent in GitHub settings.
Assign an issue to Copilot Coding Agent.
Let it work in a temporary, isolated development environment.
Review the pull request it opens.
Ask for changes or approve the result.
Let the agent iterate until the issue is resolved.

The key difference from local agent mode is that the agent runs remotely, in a temporary environment isolated from your machine. It can explore your codebase, install dependencies, build, run tests, and make changes without touching your local filesystem.

From the blog: “The agent runs within a temporary isolated dev environment that gets spun up where the agent can explore the codebase, make changes, build the code, run tests, etc. - a complete dev environment just for the agent.”

That isolation is crucial for safety. The agent can be as destructive as it needs to be because the environment is disposable.

VS Code Integration: Track and Control Everything

Copilot Coding Agent lived on GitHub.com. You assigned an issue, then switched to a browser to watch progress.

Now, the pull requests extension brings it into VS Code:

Assign from the sidebar. Select an issue in the pull request view and assign it to Copilot Coding Agent without leaving the editor.

Track progress. A new Copilot on My Behalf query shows agent sessions. Open a session to watch the play-by-play: commands, decisions, and progress.

Terminate when needed. If the agent goes off course, terminate the session from VS Code.

Review and iterate. When the agent opens a pull request, leave comments and request changes. The agent reads the feedback, updates the pull request, and tries again.

The workflow is familiar—review, request changes, iterate—but with an agent as the implementer.

A Pull Request Is Still the Boundary

The example in the source article is useful because it shows where autonomy stops. The agent implements a Trending section, including UI and database changes, and opens a pull request. A reviewer notices that the database migration is not enough and the agent needs access to an external account.

That is the right place to pause. The pull request is the review boundary. Additional access should be granted deliberately through an MCP server, not by quietly adding credentials to the agent’s environment.

For a .NET team, the same pattern might look like this:

Issue: Add a paginated orders endpoint

Acceptance criteria:
- Use the existing application service pattern.
- Return ProblemDetails for validation errors.
- Add integration tests for page boundaries.
- Do not change the public database schema.
- Report the dotnet test command and result in the pull request.

Clear acceptance criteria give the agent a shape it can follow and give the reviewer something concrete to verify.

MCP Expands the Agent’s Reach

VS Code lets you configure MCP servers for the Copilot Coding Agent. That is powerful, but the security trade-off is direct: more tools mean more autonomy and more risk.

A conceptual configuration might look like this:

# Example only: grant a narrowly scoped external capability
github:
 codingAgent:
 mcpServers:
 - supabase
 credentials: ${SUPABASE_API_KEY}

Use the smallest useful permission set. An agent that can inspect a deployment is not the same as one that can change production. Keep credentials scoped, short-lived, and observable.

The Caveat: Agent Behavior Is Still Unpredictable

LLMs are stochastic. Sometimes the agent nails a complex feature. Sometimes it misses context and opens a pull request that needs significant rework.

For critical infrastructure changes, add another review layer. The agent is well suited to bounded work that follows existing patterns. Architectural decisions, security-sensitive changes, and changes that cross several systems deserve human ownership.

Good tests matter too. The agent runs tests and uses their results as feedback. Bad or missing tests mean more back-and-forth and weaker confidence.

My Take: Issue Quality Becomes an Engineering Input

This workflow works best when the issue is clear. “Fix the dashboard” is a conversation starter, not an implementation specification. “Add a dark mode toggle to the settings panel, persist the preference, and cover it with a browser test” gives an agent something verifiable.

Teams adopting coding agents will improve when they invest in:

Clear issue acceptance criteria.
Test coverage that describes expected behavior.
Deliberate MCP access policies.
Review rules for agent-generated changes.
Metrics for rework and successful first passes.

This is not replacing developers. It is moving developer attention toward architecture, design, and review while an agent handles routine implementation.

What To Do Next

Install or update the GitHub Pull Requests extension.
Enable Copilot Coding Agent in GitHub settings.
Create a small test issue with explicit acceptance criteria.
Assign it from VS Code and watch the session.
Review the pull request as carefully as any human-authored change.

For .NET teams, start with a bounded endpoint, a test addition, or a small refactoring that fits existing patterns. The autonomous developer is not here to replace your judgment. It is here to multiply the amount of work your judgment can supervise.

Use it deliberately.

Happy coding.

AI Meets Remote Development: Context-Aware Agents in Any Environment

Emiliano Montesdeoca — Tue, 11 Aug 2026 00:00:00 +0000

Original source: Enhance productivity with AI + Remote Dev

AI Meets Remote Development: Context-Aware Agents in Any Environment

Remote development was already powerful in VS Code—SSH into a VM, work in a dev container, develop in WSL, tunnel to a remote machine, or use GitHub Codespaces. But those workflows were isolated from AI. You had to switch contexts mentally: AI in the editor, but your actual code living somewhere else.

That split is gone. VS Code’s latest integration brings agent mode, chat, and AI completions to every remote environment. More importantly, it lets agents understand which environment they’re in and tailor their behavior accordingly.

That’s not just convenience. That’s a fundamentally different approach to distributed development.

The Five Remote Flavors, Now AI-Enabled

VS Code’s remote development comes in five flavors:

Remote SSH — Connect to any VM or machine via SSH
Dev Containers — Work inside a containerized environment with preconfigured dependencies
WSL — Linux-powered development on Windows
Remote Tunnels — Access a machine via secure tunnel, no SSH config needed
GitHub Codespaces — Managed cloud environments

Before this update, AI worked in all of them. But now, it works with context. GitHub Copilot automatically installs when you connect remotely. Better: custom instructions and chat participants now understand your remote setup.

Custom Instructions: Teaching AI About Your Environment

Imagine you connect to a dev container for Python development. The container has Python 3, pip, and the Python language extensions installed. But the agent doesn’t know that automatically.

With custom instructions, you can tell it:

This is a dev container that includes `python3` and `pip3` pre-installed
and available on the `PATH`, along with the Python language extensions
for Python development.

That one instruction changes everything. Now when you ask the agent to write Python code, it won’t suggest installation steps you’ve already done. It won’t guess at your project structure. It understands the environment.

Better yet: VS Code’s dev container templates now include custom instructions by default. The Python template, the Node.js template—they all ship with environment context built in. Clone a repo with a dev container, open it in VS Code, and the agent knows exactly what toolchain is available.

From the blog: “We’ve made it so that custom instructions can merge successfully across images and Templates.” That means custom instructions compose. Your base Python image has one set of instructions. Your project adds another. The agent gets the union of both.

Chat Participants: Domain-Specific Helpers

Chat participants are AI helpers specialized in particular domains. Type @ in the chat field and you see the available options—@workspace, @vscode, @terminal. Extensions can add their own.

The Remote SSH extension includes @remote-ssh. Ask it how to troubleshoot SSH connection failures. Ask how to configure key-based authentication. It’s like having someone who knows your remote setup sitting next to you.

If an SSH connection fails, there’s a Diagnose with Copilot button. The agent investigates and surfaces actionable insights right in the editor. No context switching. No searching the web. The agent is already in the right context.

Auto-Approvals: Agent Autonomy, Safely

Agents are powerful because they can run terminal commands and tools—install dependencies, run tests, modify local configuration. But some commands are destructive. You might not want an agent deleting files on your local machine.

VS Code now supports chat.tools.autoApprove. When enabled, the agent doesn’t pause for confirmation on tool calls. It just runs them.

Here’s the key: you can scope this to dev containers or remote machines only. This gives you a security model where:

Local dev machine: tools require explicit approval
Dev container: tools auto-approve (it’s ephemeral, less risk)
Remote VM: depends on your risk tolerance

You get autonomy without exposing your local dev machine to potentially destructive commands.

{
 "chat.tools.autoApprove": true
}

Treat that setting as an environment policy, not a productivity switch. A remote VM with production credentials is not automatically safe just because it is remote.

Practical Pattern: Dev Container + Custom Instructions

Here’s how it comes together:

Create a dev container from the Dev Containers: Add Dev Container Configuration command.
Select Python (or your language of choice).
Reopen the folder in the container.
Open chat and ask the agent to build something.
Check that the agent uses the installed toolchain and your repository instructions.

What used to require manual setup—“I’m working in a container, let me tell the agent about it”—now becomes part of the environment definition.

The Caveat: Context Bleed Risk

Here’s the edge case: the more context an agent has, the more it can hallucinate connections that don’t exist.

An agent in your Python dev container might think there is a database available because a .env file contains a connection string. That database may not be running. The agent tries to use it and fails.

Custom instructions help—you can explicitly say “this container does NOT have access to the production database”—but they’re not foolproof. Agents still need human review for risky operations.

My Perspective: This Unlocks Asynchronous Teamwork

Remote development is already about working asynchronously across machines. AI makes it better because agents now understand the context of where they’re working.

Pair this with GitHub’s Copilot Coding Agent, which runs in the cloud, and you have a powerful model:

Local agents handle quick tasks and understand your local dev container.
Remote agents tackle complex features across your codebase.
Both speak the same language because they can share workspace context and coding standards.

What To Do Next

Add custom instructions to your dev container templates. If you maintain dev containers for your team, include environment-aware guidance.
Test auto-approvals in an ephemeral container. Do not begin with a remote machine that holds production credentials.
Experiment with @remote-ssh. Use it to troubleshoot your own setup, then consider what domain-specific participants would help your team.

Remote development plus AI is no longer AI in a desktop editor. It is a distributed workflow where context follows you everywhere you work.

That’s the future. It’s here.

Happy coding.