Developer Experience | The .NET Blog

Revisar pull requests dentro do Visual Studio é exatamente o tipo de redução de atrito que eu gosto

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

Este artigo foi traduzido automaticamente. Leia o original aqui.

O navegador roubou por tempo demais uma parte grande demais do workflow de code review.

Por isso fico muito feliz em ver o Visual Studio avançando mais rumo à revisão end-to-end de pull requests dentro do IDE.

Este é um daqueles recursos que talvez não gere manchetes enormes, mas que pode melhorar de forma real o desenvolvimento diário.

O valor principal é simples: menos context switching

Quando o seu loop de review vive em parte no IDE e em parte no navegador, o atrito se acumula:

abra o PR em outro lugar
inspecione as mudanças em uma ferramenta
volte para a solution para investigar melhor
troque outra vez para comentar ou aprovar

Isso não é catastrófico. É só ineficiente.

Se o Visual Studio permitir abrir, inspecionar, comentar, aprovar e fazer merge no mesmo ambiente de trabalho, isso é um ganho real de produtividade.

A opção de “review sem checkout” é especialmente boa

Uma parte que eu particularmente gosto é a possibilidade de revisar sem fazer checkout do branch do PR.

Isso pode parecer pequeno, mas é perfeito para:

passadas rápidas de review
pedidos de feedback interrompidos
manter seu branch atual e o estado local intactos

Esse é exatamente o tipo de flexibilidade que boas ferramentas de code review precisam.

Minha opinião

Isso não é um recurso revolucionário.

É algo melhor: algo prático.

Para equipes que passam a maior parte do dia no Visual Studio, um suporte mais forte a PR review significa menos interrupções no workflow e um caminho mais suave da inspeção à ação.

Na minha visão, essa é uma melhoria que vale a pena.

Publicação original: Revise pull requests sem sair do Visual Studio

Harnesses de Agentes Importam Porque Prompts Não São Suficientes

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

Um dos erros mais fáceis de cometer no desenvolvimento de agentes é achar que o prompt é o produto.

Não é.

O novo passo a passo de agent harness e claw da equipe do Microsoft Agent Framework é valioso porque mantém o foco na parte que realmente determina se um agente parece utilizável: a camada de runtime ao redor do modelo.

Isso inclui:

ferramentas
planejamento
estado de sessão
memória
modos de execução
um console ou interface utilizável para iteração

É aí que os agentes deixam de ser demos inteligentes e passam a parecer software de verdade.

O padrão de harness é prático

O que eu gosto aqui é o quão acessível a ideia é.

Você começa com um chat client.

Depois envolve isso em um harness com instruções e ferramentas.

Depois roda tudo através de um shell que suporta planejamento, todos, sessões e interação em streaming.

Esse é um padrão saudável porque separa claramente as responsabilidades:

o modelo cuida do raciocínio
o harness cuida do comportamento em tempo de execução
a aplicação decide quais ferramentas e experiências importam

Isso combina muito bem com a forma como desenvolvedores .NET constroem sistemas

A ideia do harness também mapeia bem para a mentalidade .NET.

Geralmente nos saímos melhor quando o comportamento em runtime é explícito e composável. Middleware, pipelines, options, providers e adapters são todos naturais nesse mundo.

É por isso que acho que o Agent Framework tem uma boa chance de agradar aos desenvolvedores .NET. Ele não força todo mundo em uma única abstração mágica. Ele te dá peças estruturadas de runtime que você pode conectar entre si.

Minha opinião

A parte mais útil deste post é o lembrete de que agentes precisam de mais do que um bom modelo e uma string de instrução inteligente.

Eles precisam de uma camada de runtime que dê a eles estrutura, memória, acesso a ferramentas, planejamento e um loop de desenvolvimento viável.

É isso que o harness te dá.

E, honestamente, é por isso que esse padrão vale a pena acompanhar.

Post original: Meet your agent harness and claw

Aspire no VS Code 13.4 Aperta o Ciclo de Desenvolvimento nos Lugares Certos

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

As melhores atualizações de ferramentas são aquelas que você sente depois de alguns dias, não as que só parecem boas nas notas de lançamento.

É assim que Aspire no VS Code 13.4 me parece.

Esta atualização é toda sobre apertar o loop interno: criar projetos mais rápido, depurar recursos multilíngues de forma mais natural, expor saúde e comandos diretamente no editor, e manter o dashboard por perto sem torná-lo o único lugar onde você pode trabalhar.

Essa é uma direção muito boa.

A grande vitória é menos troca de contexto

Se você usa o Aspire com seriedade, geralmente está transitando entre várias superfícies:

código do AppHost
terminal
dashboard
logs
sessões de depuração
endpoints de serviço

O que o 13.4 faz bem é reduzir o atrito entre essas superfícies.

A nova experiência no VS Code torna mais do estado da aplicação visível exatamente onde você já está trabalhando:

saúde dos recursos no editor
comandos ao lado das declarações de recursos
acesso mais fácil ao dashboard
acesso a logs a partir do contexto do AppHost
um painel que continua útil mesmo antes de iniciar a depuração completa

Isso parece pequeno até você fazer isso todos os dias.

Depurar stacks mistas importa mais do que as pessoas pensam

Uma das partes mais fortes desta atualização é a história mais natural para depurar C#, TypeScript, Python, Go, aplicações de navegador e Azure Functions em um único fluxo orientado pelo Aspire.

Isso reflete a forma real das aplicações modernas muito melhor do que fingir que tudo vive em um único runtime.

Para desenvolvedores .NET especialmente, isso é valioso porque muitos de nós agora estamos construindo sistemas que misturam projetos de API, front-ends, workers e serviços adjacentes a IA em linguagens diferentes.

O fato de o Aspire estar tornando isso mais unificado dentro do VS Code é uma melhoria muito prática.

O suporte ao TypeScript AppHost chegar ao GA também é significativo

Eu não ignoraria o lado do TypeScript AppHost neste lançamento.

O Aspire se tornando mais natural tanto para C# quanto para TypeScript amplia quem pode trabalhar no mesmo modelo de sistema sem fluxos de trabalho estranhos de segunda classe. Isso importa para equipes onde código de plataforma, código de front-end e orquestração de serviços vivem próximos.

Minha opinião

Aspire 13.4 no VS Code não é sobre uma única funcionalidade matadora. É sobre suavizar as arestas do loop diário:

iniciar mais rápido
ver mais estado onde você programa
depurar de forma mais natural
pular para logs e dashboard só quando necessário

É exatamente assim que boas ferramentas deveriam evoluir.

Se você já usa o Aspire, esta atualização parece valer a pena instalar. Se você ainda está se perguntando se o VS Code é um lar sério para desenvolvimento baseado em Aspire, a resposta está ficando cada vez mais óbvia.

Post original: Aspire in VS Code: the 13.4 developer loop

O novo Plan agent no Visual Studio resolve um problema muito real de workflow de IA

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

Este artigo foi traduzido automaticamente. Leia o original aqui.

Um dos workflows de programação com IA mais frustrantes é quando a implementação começa rápido demais.

O código pode até estar tecnicamente certo, mas está resolvendo a versão errada do problema que você tinha em mente.

Você queria uma refatoração. Virou um rewrite. Você queria uma melhoria com escopo definido. Tocou metade do projeto. Você queria discutir opções. Foi direto para mudanças em arquivos.

É por isso que o novo Plan agent no Visual Studio é uma adição tão útil.

Isso resolve um problema real de workflow, não apenas um problema cosmético

A publicação original descreve uma situação muito familiar: “O código não está errado… ele só não é o que você queria.”

Essa frase é perfeita.

Porque o ponto fraco de muito desenvolvimento assistido por IA não é se o modelo consegue produzir código. O problema é se o workflow cria espaço suficiente para combinar a forma pretendida do trabalho antes de começar a implementação.

Isso importa especialmente para:

recursos grandes
codebases desconhecidas
refatorações não triviais
mudanças sensíveis à arquitetura
trabalho que precisa de review do time antes de começar a editar

Nessas situações, pular direto para a implementação costuma ser o movimento errado.

Planejamento não é overhead quando a tarefa é real

Acho que os times às vezes subestimam quanto tempo perdem quando começam a implementar cedo demais.

Se o agent:

tocar nos arquivos errados
escolher a abordagem errada
ignorar uma restrição importante
deixar passar um edge case necessário

então o começo “rápido” vira, no fim, um workflow mais lento no geral.

Por isso eu gosto desse recurso.

Ele cria espaço para:

perguntas de esclarecimento
elaboração do plano
editar o plano diretamente
compartilhar o plano antes de começarem as mudanças de código

Isso não é burocracia. Muitas vezes é apenas boa engenharia.

O arquivo de plano em markdown é uma escolha inteligente

Um detalhe que eu gosto especialmente é que cada plano é salvo em .copilot/plans/plan-{title}.md.

Isso torna a etapa de planejamento tangível.

Quer dizer que o plano não fica preso dentro de um transcript de chat. Ele vira algo que você pode:

revisar
editar
versionar mentalmente
discutir com o time
passar para a implementação de forma mais deliberada

Isso faz o recurso parecer muito mais sério do que um simples preâmbulo temporário antes da geração de código.

É aqui que os workflows de IA começam a respeitar o processo do time

Acho que esse é um dos sinais mais fortes de que essas ferramentas estão amadurecendo.

Os melhores workflows de IA para desenvolvedores não são os que eliminam todas as etapas intermediárias. São os que melhoram as etapas intermediárias certas.

E planejamento é uma dessas etapas.

Se o plano é forte, implementar fica mais fácil. Se o plano é fraco, a implementação fica barulhenta.

Esse recurso reconhece isso diretamente.

Minha opinião

Isso não é só uma gentileza de IA.

É uma melhoria de workflow.

E, para recursos reais e refatorações reais, é exatamente o tipo de melhoria que pode economizar muito churn desnecessário, ruído de review e rework do tipo “isso não é o que eu quis dizer”.

Acho que cada vez mais experiências com agents vão acabar precisando de algo assim.

O Visual Studio chegou lá antes, de um jeito que parece útil.

Publicação original: Planeje antes de construir: apresentando o Plan agent no Visual Studio

O seu dev loop está cheio de conhecimento implícito, e o Aspire tem a resposta certa

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

Este artigo foi traduzido automaticamente. Leia o original aqui.

Este pode ser um dos posts mais importantes sobre Aspire para entender por que o produto importa.

Não porque ele anuncie uma grande funcionalidade nova.

Mas porque nomeia um problema que quase toda equipe de engenharia já sentiu e nem toda equipe conseguiu descrever bem:

o dev loop está cheio de conhecimento implícito.

Essa frase pega porque é verdade.

O problema não é falta de ferramentas

O argumento central do artigo original é excelente: times muitas vezes não carecem de infraestrutura, scripts, dashboards ou comandos.

O que lhes falta é um modelo coerente que transforme todo o conhecimento operacional oculto em torno da aplicação em algo visível e repetível.

A verdadeira arquitetura de muitas apps vive em:

shell history
scripts espalhados
trechos de README
threads do Slack
aquele único senior engineer que sabe a ordem das operações

Isso não é um dev loop sustentável para humanos.

E definitivamente não é para agents.

A citação que, na minha opinião, resume o post inteiro

Há uma frase no artigo original que acho que captura muito bem o ponto geral:

“As aplicações já existem como sistemas. O Aspire torna esses sistemas explícitos, porque sistemas explícitos escalam melhor do que conhecimento implícito.”

Essa é a tese inteira em uma linha.

E, sinceramente, é uma das melhores explicações do Aspire em uma frase que eu já vi até agora.

Por que isso importa mais agora do que há um ano

Acho que este post encaixa especialmente bem no momento atual porque o desenvolvimento assistido por IA muda o custo da ambiguidade.

Os humanos conseguem compensar sistemas incompletos de forma surpreendente.

Lembramos:

qual script executar primeiro
qual variável de ambiente é secretamente necessária
qual terminal geralmente mostra os logs úteis
qual serviço precisa ser reiniciado duas vezes por razões que ninguém documentou

Os agents são muito piores nesse tipo de folclore operacional oculto.

Então, se queremos que agents sejam realmente úteis em repositórios reais, precisamos tornar o sistema mais explícito, não menos.

É por isso que acho esse framing do Aspire importante.

O valor real do Aspire não é só orchestration

Um erro comum com Aspire é pensar nele apenas como um launcher de app distribuído ou um auxiliar de orchestration local.

Esse enquadramento é pequeno demais.

A proposta de valor mais forte é que o Aspire dá à aplicação:

um modelo
uma forma
recursos nomeados
dependências explícitas
superfícies de health e operations
comandos que humanos e automação conseguem entender

Isso muda o dev loop mais do que às vezes se percebe.

Porque, quando a app deixa de ser uma pilha de convenções implícitas e passa a ser um sistema com um modelo real, várias coisas ficam mais fáceis ao mesmo tempo:

onboarding
debugging
setup repetível
consistência de CI
workflows assistidos por IA

Isso é muita alavanca a partir de uma única decisão de design.

Gosto especialmente do ângulo “comandos como operações de primeira classe”

Outro ponto do post original que acho que merece mais atenção é a passagem de instruções em README para comandos ligados a recursos.

É uma mudança enganosamente grande.

Em vez de dizer:

execute este script, depois aquele, e talvez este outro se o primeiro falhar

você pode modelar as operações diretamente no contexto da aplicação.

Isso significa que humanos podem descobri-las mais facilmente.

E significa que agents não precisam adivinhar a intenção a partir de prosa.

É o tipo de coisa que transforma uma aplicação de “operável se você já a conhece” em “operável por design”.

O que eu tiraria disso como team lead

Se eu olhasse o dev loop do meu time por essa lente, faria algumas perguntas diretas:

quanto da nossa configuração depende da memória?
quantas ações críticas de desenvolvimento existem apenas em docs ou threads de chat?
com que frequência novos colaboradores travam em um comportamento invisível do sistema?
uma ferramenta de automação ou um coding agent conseguiria entender a topologia da nossa app apenas pelo repo?

Se a resposta para a última for “nem perto”, então este post deve tocar um ponto sensível de forma útil.

Minha opinião

Este é um framing muito forte do valor real do Aspire.

Não é só orchestration.

É tornar o modelo da aplicação explícito o suficiente para que o sistema fique mais fácil de operar, entender e automatizar.

Isso importa para pessoas. Isso importa para times. E importa ainda mais agora que grande parte do desenvolvimento moderno está se movendo para workflows assistidos por agents.

Este é exatamente o tipo de artigo que ajuda a explicar por que o Aspire parece cada vez mais relevante para além do rótulo de marketing de .NET.

Publicação original: O seu dev loop está cheio de conhecimento implícito

Os testes end-to-end herméticos do Aspire são o tipo de padrão que mais equipes deveriam adotar

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Testes end-to-end instáveis são caros de um jeito que nem sempre aparece em um dashboard.

Eles não apenas falham. Eles treinam lentamente o time a parar de confiar no loop de feedback.

Por isso este artigo sobre Azure Chaos Studio + Aspire me chamou atenção imediatamente. Não é um anúncio de produto chamativo. É uma história de engenharia pé no chão sobre como fazer testes end-to-end pararem de parecer uma negociação com a sorte.

E, sinceramente? Acho que mais equipes deveriam adotar esse padrão.

A ideia central é simples, mas o ganho é enorme

O passo-chave é dar a cada teste seu próprio ambiente hermético e efêmero, com serviços reais, dependências reais e um startup explícito baseado em saúde.

Isso parece óbvio quando você lê em uma frase. Em sistemas reais, é muito mais difícil, principalmente quando dependências de nuvem, ambientes compartilhados e serviços distribuídos entram na jogada.

O artigo original descreve o problema com muita clareza: ambientes de teste compartilhados trazem “cross-talk, flaky behavior e mensagens de grupo do tipo ‘quem quebrou o staging?’” como custo operacional.

Essa frase é engraçada porque dói.

Equipe demais aceita esse acordo como algo normal. Eu não acho que deveria ser assim.

Por que esse padrão importa além dos testes

O que eu mais gosto aqui é que o artigo não diz apenas: “tornamos nossos testes mais confiáveis”.

Ele está dizendo algo maior:

se o seu sistema distribuído é difícil de reproduzir, difícil de isolar e difícil de verificar, todo o seu ciclo de engenharia desacelera.

Isso afeta mais do que CI.

Afeta:

o quanto os desenvolvedores se sentem confiantes para refatorar
a rapidez com que regressões são diagnosticadas
quão seguro é tentar mudanças arquiteturais maiores
o quanto o time confia na validação automatizada

E, em 2026, também afeta o quão útil o desenvolvimento assistido por IA pode se tornar.

A citação mais importante do post

Há uma linha no artigo que acho que vale repetir:

“Agents não precisam ser perfeitos. Eles precisam ser verificáveis.”

Esse é um framing excelente.

As pessoas passam muito tempo perguntando se os agents de código com IA são confiáveis o suficiente para ajudar em trabalho não trivial. Acho que a pergunta melhor é se nossos sistemas são testáveis o suficiente para julgar esse trabalho corretamente.

Se um agent propõe um refactor relevante e o seu único sinal de segurança é uma pilha de checks end-to-end frágeis e semi-aleatórios rodando em um ambiente compartilhado, então o problema não está só no agent.

O problema está no seu modelo de validação.

Esse padrão Aspire melhora isso drasticamente.

O que torna essa implementação especialmente boa

Vários elementos da história original fazem disso muito mais do que um post vago de “melhoramos nossos testes”.

1. Grafo de serviços real, não teatro de mocks falsos

Os testes não são construídos em cima de um monte de mocks desconectados fingindo ser validação end-to-end.

Eles executam os binários reais, conectam emuladores onde possível e usam o mesmo application model usado no desenvolvimento local.

Isso importa.

Porque, no momento em que os testes end-to-end viram teatro de mock contra mock, eles deixam de dizer algo confiável sobre a composição real.

2. Startup baseado em health em vez de sleeps mágicos

Essa parte é maior do que parece.

O artigo deixa claro que os testes esperam health real com WaitForResourceHealthyAsync, em vez de depender de palpites arbitrários de tempo.

Isso faz uma diferença enorme.

Uma suite que diz “durma 30 segundos e torça pelo melhor” está, na prática, documentando incerteza. Uma suite que espera readiness real está documentando a intenção do sistema.

3. O mesmo modelo impulsiona desenvolvimento local e testes

Eu gosto muito disso porque encaixa bem nas histórias mais fortes do Aspire em geral.

O mesmo application model impulsiona:

desenvolvimento local
wiring de serviços
dependências emuladas
health checks
orquestração de testes herméticos

Isso reduz drift, e drift é um dos assassinos silenciosos da confiança.

Esse tipo de investimento em devex costuma ser subestimado

Um dos motivos pelos quais eu queria que este post fosse mais longo do que uma reação rápida é que acho que esse tipo de melhoria de engenharia costuma ser subestimado.

Não é chamativo.

Não demo como uma nova funcionalidade de IA.

E nem sempre vira um slide que empolga executivos.

Mas, com o tempo, cria algo muito mais valioso: um time que consegue se mover mais rápido sem mentir para si mesmo sobre qualidade.

Isso é grande.

O artigo diz que eles agora executam cerca de 90 testes herméticos, incluindo cenários como queda de zona, falha de DNS e falha de replicação geográfica. Isso não é só uma higiene de testes melhor. É um modelo de confiança muito mais forte para uma plataforma distribuída.

O que eu tiraria disso se estivesse operando um sistema .NET distribuído

Se você trabalha hoje com serviços distribuídos, Aspire e pipelines de CI/CD, eu tiraria isso imediatamente:

pare de normalizar flakiness em ambientes compartilhados
migre para gates de startup baseados em health sempre que possível
trate o AppHost como código real de orquestração de nível production
construa checks end-to-end que validem a composição de serviços, e não apenas a correção de cada serviço isoladamente
se você estiver adotando desenvolvimento assistido por IA, invista primeiro em checkability antes de correr atrás de mais amplitude de automação

Esse último ponto é o que mais equipes precisam ouvir.

Minha opinião

Este é um dos posts mais fortes sobre Aspire deste lote porque resolve um problema muito prático.

Ele não tenta impressionar com abstração. Mostra como deixar testes end-to-end mais determinísticos, mais úteis e mais confiáveis em um sistema distribuído real.

E, assim que você enxerga a conexão com desenvolvimento assistido por agents, o padrão fica ainda mais convincente.

Se a sua história de testes end-to-end ainda depende de ambientes compartilhados, conhecimento escondido de setup e um pouco de oração, vale muito a pena estudar isso.

Post original: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests