Developer Experience | The .NET Blog

Reviewing Pull Requests Inside Visual Studio Is Exactly the Kind of Friction Reduction I Like

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

The browser has been stealing too much of the code review workflow for too long.

So I am very happy to see Visual Studio pushing further into end-to-end pull request review inside the IDE.

This is one of those features that may not generate huge headlines, but it can absolutely improve everyday development.

The main value is simple: less context switching

When your review loop lives partly in the IDE and partly in the browser, the friction adds up:

open the PR elsewhere
inspect changes in one tool
jump back to the solution for deeper investigation
switch again to comment or approve

It is not catastrophic. It is just inefficient.

If Visual Studio can let you open, inspect, comment, approve, and merge from the same working environment, that is a real productivity win.

The “review without checkout” option is especially nice

One part I particularly like is the ability to review without checking out the PR branch.

That sounds small, but it is perfect for:

quick review passes
interrupt-driven feedback requests
keeping your current branch and local state intact

That is exactly the kind of flexibility good code review tooling needs.

My take

This is not a revolutionary feature.

It is something better: a practical one.

For teams spending most of their day in Visual Studio, tighter PR review support means fewer workflow breaks and a smoother path from inspection to action.

That is a worthwhile improvement in my book.

Original post: Review pull requests without leaving Visual Studio

Agent Harnesses Matter Because Prompts Are Not Enough

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

One of the easiest mistakes in agent development is thinking the prompt is the product.

It is not.

The new agent harness and claw walkthrough from the Microsoft Agent Framework team is valuable because it keeps the focus on the part that really determines whether an agent feels usable: the runtime shell around the model.

That includes:

tools
planning
session state
memory
execution modes
a usable console or interface for iteration

That is where agents stop being clever demos and start feeling like software.

The harness pattern is a practical one

What I like here is how approachable the idea is.

You start with a chat client.

Then you wrap it into a harness with instructions and tools.

Then you run it through a shell that supports planning, todos, sessions, and streaming interaction.

That is a healthy pattern because it separates concerns clearly:

the model handles reasoning
the harness handles runtime behavior
the app decides which tools and experiences matter

This fits very well with how .NET developers build systems

The harness idea also maps nicely to the .NET mindset.

We usually do better when runtime behavior is explicit and composable. Middleware, pipelines, options, providers, and adapters all feel natural in this world.

That is why I think Agent Framework has a good chance of landing with .NET developers. It is not forcing everyone into one magical abstraction. It is giving you structured runtime pieces you can wire together.

My take

The most useful part of this post is the reminder that agents need more than a good model and a clever instruction string.

They need a runtime shell that gives them structure, memory, tool access, planning, and a workable developer loop.

That is what the harness gives you.

And honestly, that is why this pattern is worth paying attention to.

Original post: Meet your agent harness and claw

Aspire in VS Code 13.4 Tightens the Developer Loop in All the Right Ways

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

The best tooling updates are the ones you feel after a few days, not the ones that only look good in release notes.

That is how Aspire in VS Code 13.4 reads to me.

This update is all about tightening the inner loop: creating projects faster, debugging mixed-language resources more naturally, surfacing health and commands directly in the editor, and keeping the dashboard close without making it the only place you can work.

That is a very good direction.

The big win is less context switching

If you use Aspire seriously, you are usually moving across several surfaces:

AppHost code
terminal
dashboard
logs
debug sessions
service endpoints

What 13.4 does well is reduce the friction between those surfaces.

The new VS Code experience makes more of the app state visible exactly where you are already working:

resource health in the editor
commands next to resource declarations
easier dashboard access
log access from the AppHost context
a panel that remains useful even before full debugging starts

That sounds small until you do it every day.

Debugging mixed stacks matters more than people think

One of the strongest parts of this update is the more natural story for debugging C#, TypeScript, Python, Go, browser apps, and Azure Functions in one Aspire-driven flow.

That reflects the real shape of modern apps much better than pretending everything lives in a single runtime.

For .NET developers especially, that is valuable because many of us are now building systems that mix API projects, frontends, workers, and AI-adjacent services in different languages.

The fact that Aspire is making this feel more unified inside VS Code is a very practical improvement.

TypeScript AppHost support reaching GA is also meaningful

I would not ignore the TypeScript AppHost side of this release.

Aspire becoming more natural for both C# and TypeScript broadens who can work in the same system model without weird second-class workflows. That matters for teams where platform code, frontend code, and service orchestration all live close together.

My take

Aspire 13.4 in VS Code is not about one killer feature. It is about smoothing the rough edges in the daily loop:

start faster
see more state where you code
debug more naturally
jump to logs and the dashboard only when needed

That is exactly how good tooling should evolve.

If you are already using Aspire, this update looks worth installing. If you are still wondering whether VS Code is a serious home for Aspire-based development, the answer is becoming more and more obvious.

Original post: Aspire in VS Code: the 13.4 developer loop

The New Plan Agent in Visual Studio Fixes a Very Real AI Workflow Problem

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

One of the more frustrating AI coding workflows is when the implementation starts too fast.

The code may even be technically fine, but it is solving the wrong version of the problem you had in mind.

You wanted a refactor. It started a rewrite. You wanted a scoped improvement. It touched half the project. You wanted to talk through options. It jumped straight into file changes.

That is why the new Plan agent in Visual Studio is such a useful addition.

This fixes a real workflow problem, not a cosmetic one

The source post describes a very familiar situation: “The code isn’t wrong… it just isn’t what you were going for.”

That line is perfect.

Because the weak point in a lot of AI-assisted development is not whether the model can produce code. It is whether the workflow creates enough space to agree on the intended shape of the work before implementation begins.

That matters most for:

larger features
unfamiliar codebases
non-trivial refactors
architecture-sensitive changes
work that needs team review before edits start

In those situations, jumping straight into implementation is often the wrong move.

Planning is not overhead when the task is real

I think teams sometimes underestimate how much time they lose by starting implementation too early.

If the agent:

touches the wrong files
chooses the wrong approach
misses a key constraint
ignores a required edge case

then the “fast” start becomes a slower overall workflow.

That is why I like this feature.

It makes room for:

clarifying questions
plan drafting
editing the plan directly
sharing the plan before code changes happen

That is not bureaucracy. That is often just good engineering.

The markdown plan file is a smart choice

One detail I especially like is that every plan is saved to .copilot/plans/plan-{title}.md.

That makes the planning step tangible.

It means the plan is not trapped inside a chat transcript. It becomes something you can:

review
edit
version mentally
discuss with teammates
hand off into implementation more deliberately

That makes the feature feel much more serious than a temporary preamble before code generation.

This is where AI workflows start respecting team process

I think this is one of the stronger signs that these tools are maturing.

The best AI developer workflows are not the ones that remove all intermediate steps. They are the ones that improve the right intermediate steps.

Planning is one of those steps.

If the plan is strong, implementation gets easier. If the plan is weak, implementation gets noisy.

This feature acknowledges that directly.

My take

This is not just an AI nicety.

It is a workflow improvement.

And for real features and refactors, it is exactly the kind of improvement that can save a lot of unnecessary churn, review noise, and “this is not what I meant” rework.

I think more agent experiences will eventually need something like this.

Visual Studio just got there sooner in a way that feels useful.

Original post: Plan Before You Build: Introducing the Plan agent in Visual Studio

Your Dev Loop Is Full of Tribal Knowledge — and Aspire Has the Right Response

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

This might be one of the most important Aspire posts for understanding why the product matters.

Not because it announces a huge new feature.

Because it names a problem that almost every engineering team has felt and not every team has described well:

the dev loop is full of tribal knowledge.

That phrase lands because it is true.

The problem is not lack of tools

The core argument of the source article is excellent: teams often do not lack infrastructure, scripts, dashboards, or commands.

What they lack is a coherent model that turns all the hidden operational knowledge around the application into something visible and repeatable.

The real architecture of many apps lives in:

shell history
scattered scripts
README fragments
Slack threads
the one senior engineer who knows the order of operations

That is not a sustainable dev loop for humans.

And it is definitely not one for agents.

The quote I think captures the whole post

There is one sentence in the source article that I think captures the broader point really well:

“Applications already exist as systems. Aspire makes those systems explicit, because explicit systems scale better than tribal knowledge.”

That is the entire case in one line.

And honestly, it is one of the strongest one-line explanations of Aspire I have seen so far.

Why this matters more now than a year ago

I think this post lands especially well in the current moment because AI-assisted development changes the cost of ambiguity.

Humans can compensate for incomplete systems surprisingly well.

We remember:

which script to run first
which environment variable is secretly required
which terminal usually shows the useful logs
which service needs to be restarted twice for reasons nobody documented

Agents are much worse at that sort of hidden operational folklore.

So if we want agents to become meaningfully useful in real repositories, we need the system to become more explicit, not less.

That is why I think this Aspire framing matters.

Aspire’s real value is not just orchestration

One mistake people make with Aspire is thinking of it only as a distributed app launcher or local orchestration helper.

That is too small a frame.

The stronger value proposition is that Aspire gives the application:

a model
a shape
named resources
explicit dependencies
health and operations surfaces
commands that humans and automation can both understand

That changes the development loop more than people sometimes realize.

Because once the app stops being a pile of implicit conventions and starts being a system with a real model, several things get easier at once:

onboarding
debugging
repeatable setup
CI consistency
AI-assisted workflows

That is a lot of leverage from one design choice.

I especially like the “commands as first-class operations” angle

Another point from the source post that I think deserves more attention is the move from README instructions to resource-attached commands.

That is a deceptively big shift.

Instead of saying:

run this script, then that one, then maybe this other one if the first thing fails

you can model operations directly in the app context.

That means humans can discover them more easily.

And it means agents do not have to guess intent from prose.

That is the sort of thing that turns an application from “operable if you already know it” into “operable by design.”

What I would take from this as a team lead

If I were looking at my own team’s dev loop through this lens, I would ask a few blunt questions:

how much of our setup depends on memory?
how many critical dev actions only exist in docs or chat threads?
how often do new contributors get blocked on invisible system behavior?
could an automation tool or coding agent understand our app topology from the repo itself?

If the answer to that last question is “not even close,” then this post should hit a nerve in a useful way.

My take

This is a very strong framing of Aspire’s real value.

It is not just orchestration.

It is about making the app model explicit enough that the system becomes easier to operate, understand, and automate.

That matters for humans. It matters for teams. And it matters even more now that so much of modern development is moving toward agent-assisted workflows.

This is exactly the kind of article that helps explain why Aspire feels increasingly relevant beyond just the .NET marketing label.

Original post: Your dev loop is full of tribal knowledge

Hermetic Aspire End-to-End Tests Are the Kind of Pattern More Teams Should Steal

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Flaky end-to-end tests are expensive in a way that does not always show up on a dashboard.

They do not just fail. They slowly train the team to stop trusting the feedback loop.

That is why this Azure Chaos Studio + Aspire write-up hit me immediately. It is not a flashy product announcement. It is a grounded engineering story about how to make end-to-end testing stop feeling like a negotiation with luck.

And honestly? I think more teams should copy this pattern.

The core idea is simple, but the payoff is huge

The key move is giving each test its own hermetic, ephemeral environment with real services, real dependencies, and explicit health-based startup.

That sounds obvious when you read it in one sentence. It is much harder in real systems, especially when cloud dependencies, shared environments, and distributed services enter the picture.

The source article puts the problem very clearly: shared test environments bring “cross-talk, the flake, and the ‘who broke staging’ group chat messages as the cost of doing business.”

That line is funny because it is painfully real.

Too many teams accept that tradeoff as normal. I do not think they should.

Why this pattern matters beyond testing

What I like most here is that the article is not just saying, “we made tests more reliable.”

It is really saying something bigger:

if your distributed system is hard to reproduce, hard to isolate, and hard to verify, your whole engineering loop slows down.

That affects more than CI.

It affects:

how confidently developers refactor
how quickly regressions are diagnosed
how safely larger architectural changes can be attempted
how much trust the team puts in automated validation

And in 2026, it also affects how useful AI-assisted development can become.

The most important quote in the post

There is one line in the article that I think deserves to be repeated:

“Agents don’t have to be perfect. They have to be checkable.”

That is such a good framing.

People spend a lot of time asking whether AI coding agents are reliable enough to help with non-trivial work. I think the better question is whether our systems are testable enough to judge that work correctly.

If an agent proposes a meaningful refactor and your only safety signal is a pile of brittle, semi-random end-to-end checks running against a shared environment, then the problem is not just the agent.

The problem is your validation model.

This Aspire pattern improves that dramatically.

What makes this implementation especially good

Several parts of the source story make this more than a vague “we improved our tests” post.

1. Real service graph, not fake theater

The tests are not built around a pile of disconnected mocks pretending to be end-to-end validation.

They run the real binaries, wire up emulators where possible, and use the same application model used for local development.

That matters.

Because once end-to-end tests become mock-against-mock theater, they stop telling you anything trustworthy about real composition.

2. Readiness-based startup instead of magical sleeps

This part is bigger than it looks.

The article explicitly calls out that tests wait for real health with WaitForResourceHealthyAsync, rather than relying on arbitrary timing guesses.

That is a huge difference.

A test suite that says “sleep 30 seconds and hope” is basically documenting uncertainty. A suite that waits for real readiness is documenting system intent.

3. The same model drives local dev and tests

I really like this because it aligns with the strongest Aspire stories overall.

The same app model drives:

local development
service wiring
emulated dependencies
health checks
hermetic test orchestration

That reduces drift, and drift is one of the hidden killers of trust.

This is the kind of devex investment people underestimate

One reason I wanted this post to be longer than a quick reaction is that I think these kinds of engineering improvements are often undervalued.

They are not shiny.

They do not demo like a new AI feature.

They do not always produce a single slide that executives get excited about.

But they create something much more valuable over time: a team that can move faster without lying to itself about quality.

That is a big deal.

The article says they now run roughly 90 hermetic tests, including scenarios like zone outages, DNS failure, and geo-replication failure. That is not just better test hygiene. That is a much stronger confidence model for a distributed platform.

What I would take from this if I were running a distributed .NET system

If you are working with distributed services, Aspire, and CI pipelines today, here is what I would pull from this immediately:

stop normalizing shared-environment flakiness
move to health-based startup gates wherever possible
treat the AppHost as real production-grade orchestration code
build end-to-end checks that validate service composition, not just individual service correctness
if you are adopting AI-assisted development, invest in checkability before you chase automation breadth

That last point is the one I think more teams need to hear.

My take

This is one of the strongest Aspire posts in this batch because it solves a deeply practical problem.

It is not trying to impress you with abstraction. It is showing how to make end-to-end tests more deterministic, more useful, and more trustworthy in a real distributed system.

And once you see the connection to agent-assisted development, the pattern becomes even more compelling.

If your end-to-end test story still depends on shared environments, hidden setup knowledge, and a little bit of prayer, this is absolutely worth studying.

Original post: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests