Development-Workflow | The .NET Blog

Making Agents Practical for Real-World Development

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

Making Agents Practical for Real-World Development

Original source: Making agents practical for real-world development

The gap between an impressive agent demo and a useful Thursday afternoon is mostly operational. Real repositories have large outputs, accumulated conventions, interruptions, failed commands, and decisions that need to survive more than one chat turn.

VS Code’s recent agent work is aimed at that gap. The useful story is not one spectacular capability. It is the collection of small controls that make an agent easier to supervise across a real development loop.

Scale the Output Without Flooding the Session

Large terminal output and generated files can overwhelm a context window. VS Code now streams large outputs to temporary files and makes terminal output collapsible, so the conversation can remain focused on the decision rather than displaying every line.

That is relevant to .NET projects with verbose restores, test runs, generated migrations, and build logs. The agent can work with the result without turning the conversation into a wall of output.

Streaming does not solve architectural discovery. An agent still needs the relevant project structure, domain rules, and design constraints. If a migration touches a large model, point the agent to the schema and tests that define the intended behavior. Output management helps the context window; it does not create missing context.

A good practice is to keep large artifacts inspectable and named. Ask the agent to summarize the result, identify the file containing the full output, and state which lines or failures drove its next action.

Memory Needs Human Direction

Agent memory can carry useful lessons across sessions, but the developer still needs to decide what matters. Manual context compaction lets you preserve specific decisions instead of trusting an automatic summary to retain every important detail.

For a long-running .NET feature, write instructions such as preserving the authentication flow decision or the database transaction boundary when compacting. Then verify the next response against the actual code. Memory should reduce repetition, not become an invisible source of truth.

The same principle applies to the repository. If a convention is important, encode it in tests, documentation, or project instructions. A chat memory can help today; source control is what the whole team can inspect tomorrow.

Redirect Without Throwing Away the Work

An agent that takes the wrong direction creates an awkward choice: wait for it to finish, cancel it, or start over. Steering and message queueing make that choice less costly. You can redirect the next step while allowing the current operation to finish when it is safe, or queue a follow-up when the plan is still sound.

Forking a chat session is useful when an architectural question has multiple plausible answers. Explore one dependency injection or data-access approach in a fork, keep the original available, and compare the resulting plans before changing the repository.

These controls do not make generated decisions correct. They make supervision cheaper, which is a more durable improvement.

Hooks Encode Team Standards

Hooks run at lifecycle points such as session start, before edits, or after tool calls. They turn a repeated reminder into a repository-level guardrail. A hook can request formatting, block a sensitive file change, or trigger a validation action.

For a .NET team, use hooks carefully. A formatting check may be a good default. Blocking edits to a deployment file may also be sensible. A hook that runs a long integration suite before every small edit will frustrate developers and encourage them to disable the whole system.

Keep the policy close to the risk. Make the hook’s failure message actionable, and ensure the command works in the same environment as the agent. Hooks are automation, so they deserve the same review as build scripts.

Browser Tools Verify the Running Result

Browser agent tools can navigate, interact with, and capture screenshots of a running web application. For ASP.NET Core and Blazor developers, that provides a path from generated UI code to an observable result inside the editor.

Use it for bounded checks: does the route load, does the component display the expected test data, does a form show the validation state? Keep authentication, real customer data, and destructive actions outside the experiment. A browser screenshot is evidence of one state, not a replacement for automated tests or accessibility review.

Skills Make Good Workflows Repeatable

Reusable skills package procedures that teams otherwise restate in every session. A .NET team might define one for preparing an Entity Framework migration, another for adding OpenAPI documentation, and another for reviewing asynchronous code.

The best skill has a narrow trigger, known inputs, and a validation command. Start with a procedure that is repetitive but not ambiguous. A skill should make team knowledge easier to apply, not hide a complicated decision behind a slash command.

The Practical Recommendation

Adopt these capabilities in layers. First make large outputs and session steering comfortable. Then add one hook and one project-specific skill. Finally, try browser verification for a local web workflow.

Measure the result by review effort and recovery time, not by how autonomous the agent appears. Practical agents are the ones a team can understand, redirect, and validate when the happy path ends.

VS Code 1.110: Making Agents Practical for Complex Tasks

Emiliano Montesdeoca — Mon, 24 Aug 2026 00:00:00 +0000

VS Code 1.110: Making Agents Practical for Complex Tasks

Original source: February 2026 (version 1.110)

VS Code 1.110 focuses on the part of agent development that demos tend to skip: operating an agent once the task is large, multi-step, and connected to a real codebase. The release adds more visibility into execution, better ways to preserve context, browser tools for verification, and extensibility that can be packaged for reuse.

For .NET developers, that changes the question from “can an agent generate this?” to “can I supervise this workflow without guessing what happened?”

More Visibility Into Agent Execution

The Agent Debug panel replaces the older diagnostics-oriented experience with a view of the session’s activity. It shows which prompt files, skills, hooks, and custom configurations were loaded, along with the order of important events and tool calls.

That is useful even when the agent appears to be behaving correctly. If a custom instruction did not load, a tool received an unexpected parameter, or a hook ran at the wrong point, the debug view gives you evidence instead of a vague failure. For a .NET repository with project instructions, analyzers, and multiple services, that distinction matters.

Use the panel when developing custom agents or skills. Confirm the intended files were loaded, inspect the tool boundary, and keep a record of what the session actually did. It is especially valuable when two agents are running in parallel and their results seem inconsistent.

The permission model is also easier to control from a session. Commands such as /autoApprove and /disableAutoApprove make the autonomy decision explicit in the conversation. That convenience comes with a serious warning: skipping confirmations allows terminal commands and edits to proceed without an approval pause. Enable it only after the task and repository boundary are clear.

Browser Verification Closes a Loop

The release adds agentic browser tools for navigating, interacting with, and taking screenshots of web pages from the editor. An agent can make a change, inspect the running application, and use what it sees to guide the next iteration.

For ASP.NET Core and Blazor work, this can shorten the distance between a generated UI change and a verified result. A developer can ask an agent to implement a component, start the local application, and inspect the rendered page rather than relying only on markup and compiler output.

The feature is experimental, and organization administrators can control it. Browser support also depends on the model and tool configuration. Treat it as a verification aid, not as permission to skip human review. A screenshot can show that a page renders; it does not prove that authorization, accessibility, data validation, or error handling are correct.

Keep browser checks bounded. Use test data, avoid real production sessions, and make the expected state explicit. The more powerful the browser tool becomes, the more important the environment boundary is.

Preserve Context Without Losing Control

Long-running sessions become easier to manage with plan memory, manual /compact control, and chat forking. Instead of relying entirely on automatic compaction, a developer can decide what should survive a context reduction. Forking lets you explore an alternative design without destroying the original conversation.

That is a good fit for multi-day .NET work. Preserve decisions about a database schema or API contract, fork before exploring a different dependency injection approach, and keep the original session available as a reference.

Memory is not a substitute for durable project documentation. If a decision matters after the chat is gone, put it in the repository: an ADR, a design note, a test, or a project instruction. Session memory is useful for continuity; source control remains the durable record.

Plugins and Skills Make Repetition Explicit

Agent plugins package skills, commands, agents, MCP servers, and hooks. The release also supports creating customizations from chat through commands such as /create-prompt, /create-skill, /create-agent, and /create-hook.

For .NET teams, this opens a practical path for repeatable work: a skill for adding an Entity Framework migration, a hook that runs formatting checks, or an agent that reviews an ASP.NET endpoint against local conventions. Start with a workflow you already repeat and make its inputs and outputs explicit.

Do not package a vague instruction and call it automation. A useful skill states what it may inspect, what it may change, and which validation command must pass.

Recommendations for .NET Developers

Use the Agent Debug panel when building custom skills or troubleshooting an unexpected tool call.
Try browser tools against a local ASP.NET or Blazor app with non-sensitive test data.
Use /compact deliberately and record durable architectural decisions in the repository.
Keep auto-approval scoped to trusted, disposable environments and bounded tasks.
Turn repeated .NET workflows into small skills with explicit validation.

VS Code 1.110 is a maturity release. The headline is not that agents can do more; it is that developers can see, interrupt, preserve, and verify more of what agents do.