GitHub Copilot | The .NET Blog

Atualização de Abril do Azure DevOps MCP Server: Consultas WIQL, Auth PAT e MCP Apps Experimental

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

Esta postagem foi traduzida automaticamente. Para a versão original, clique aqui.

O Azure DevOps MCP Server continua melhorando. A atualização de abril cobre ambos os servidores.

Suporte a Consultas WIQL

A nova ferramenta wit_query_by_wiql permite executar consultas Work Item Query Language diretamente do seu cliente MCP.

Personal Access Tokens

Autenticação PAT no servidor local — importante para cenários de integração sem autenticação interativa.

Anotações MCP

Tags de metadados para ferramentas somente leitura, destrutivas e open-world — fundamentais para a confiabilidade dos agentes.

Consolidação das Ferramentas Wiki

5 ferramentas wiki separadas → 2 ferramentas mais capazes. Menos ferramentas = melhor desempenho do LLM.

Experimental: MCP Apps

Fluxos de trabalho empacotados no ambiente do servidor MCP. A direção está certa.

Post original de Dan Hellem: Azure DevOps MCP Server April Update.

VS Code 1.118: Copilot CLI Ganha Nomes de Sessão, Badges de Modelo e TypeScript 7.0 Nightly

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Visual Studio Code 1.118 é um release menor e focado — principalmente refinamentos do Copilot CLI — mas há algumas coisas que merecem atenção.

Copilot CLI: sessões têm nomes reais

As APIs de título de sessão do SDK do Copilot CLI agora são a fonte da verdade para nomes de sessão. Sessões mostram o nome real do SDK em vez de etiquetas geradas automaticamente.

Troque de sessão mais rápido

O app Agents agora tem Ctrl+1, Ctrl+2, etc. para trocar rapidamente entre sessões.

Badges de modelo no chat

Respostas do Copilot CLI no painel de chat agora mostram um badge de modelo — você pode ver de relance qual modelo tratou cada requisição.

Seleção automática de modelo no Copilot CLI

A seleção automática de modelo agora funciona também no agente Copilot CLI.

Opt-in para TypeScript 7.0 Nightly

Você pode agora optar por testar os nightlies do TypeScript 7.0 diretamente nas configurações do VS Code. TypeScript 7.0 é um release importante (a beta foi lançada há alguns dias).

Veja as notas de release completas.

68 Minutos por Dia Re-Explicando Código? Existe uma Solução

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta postagem foi traduzida automaticamente. Para a versão original, clique aqui.

Você conhece aquele momento quando sua sessão do Copilot chega no /compact e o agente esquece completamente o que você estava fazendo? Você passa os próximos cinco minutos re-explicando a estrutura de arquivos, o teste falhando, as três abordagens que já tentou. Então acontece de novo.

Desi Villanueva mediu: 68 minutos por dia — só em re-orientação. Não escrevendo código. Não revisando PRs. Só atualizando a IA sobre coisas que ela já sabia.

Acontece que há uma razão concreta para isso — e uma solução concreta.

A Mentira da Janela de Contexto

Seu agente vem com um número grande na caixa. 200K tokens. Parece massivo. Na prática é um teto, não uma garantia.

Aqui está a matemática real:

200K de contexto total
Menos ~65K para ferramentas MCP carregadas no início (~33%)
Menos ~10K para arquivos de instruções como AGENTS.md

Isso deixa você com aproximadamente 125K antes de digitar uma palavra. E piora — LLMs não degradam gradualmente. Eles batem em uma parede em torno de 60% de capacidade.

Limite efetivo: 45K tokens antes que a qualidade degrade.

O Imposto de Compactação

Cada /compact custa seu estado de flow. A parte cruel: a memória já existe. O Copilot CLI escreve cada sessão em um banco de dados SQLite local em ~/.copilot/session-store.db. O agente simplesmente não consegue lê-lo.

auto-memory: Uma Camada de Recall, Não um Sistema de Memória

pip install auto-memory

~1.900 linhas de Python. Zero dependências. Instalado em 30 segundos.

Em vez de inundar o contexto com resultados grep, você dá ao agente acesso cirúrgico ao que realmente importa — 50 tokens em vez de 10.000.

Conclusão

Context rot é uma restrição arquitetural real. auto-memory contorna isso dando ao seu agente um mecanismo de recall barato e preciso.

Confira: auto-memory no GitHub. Post original de Desi Villanueva: I Wasted 68 Minutes a Day.

azd + GitHub Copilot: Configuração de projeto com IA e resolução inteligente de erros

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Este artigo foi traduzido automaticamente. Para ver a versão original em inglês, clique aqui.

Você conhece aquele momento em que quer fazer o deploy de uma app existente no Azure e se vê olhando para um azure.yaml em branco, tentando lembrar se sua API Express deveria usar Container Apps ou App Service? Esse momento acabou de ficar muito mais curto.

O Azure Developer CLI (azd) agora se integra com o GitHub Copilot de duas formas concretas: scaffolding assistido por IA durante o azd init, e resolução inteligente de erros quando os deploys falham. Ambas as funcionalidades ficam completamente no terminal — exatamente onde eu quero que estejam.

Configuração com Copilot durante azd init

Quando você executa azd init, agora aparece a opção “Set up with GitHub Copilot (Preview)”. Selecione-a e o Copilot analisa sua base de código para gerar o azure.yaml, os templates de infraestrutura e os módulos Bicep — com base no seu código real.

azd init
# Selecione: "Set up with GitHub Copilot (Preview)"

Pré-requisitos:

azd 1.23.11 ou superior — verifique com azd version ou atualize com azd update
Assinatura ativa do GitHub Copilot (Individual, Business ou Enterprise)
GitHub CLI (gh) — o azd pedirá login se necessário

O que acho genuinamente útil: funciona nos dois sentidos. Construindo do zero? O Copilot ajuda a configurar os serviços Azure certos desde o início. Tem uma app existente que você queria fazer deploy faz tempo? Aponte o Copilot para ela e ele gera a configuração sem você precisar reestruturar nada.

O que ele faz de verdade

Digamos que você tem uma API Express em Node.js com dependência do PostgreSQL. Em vez de decidir manualmente entre Container Apps e App Service, e depois escrever Bicep do zero, o Copilot detecta sua stack e gera:

Um azure.yaml com as configurações corretas de language, host e build
Um módulo Bicep para Azure Container Apps
Um módulo Bicep para Azure Database for PostgreSQL

E ele faz verificações prévias antes de tocar em qualquer coisa — verifica se seu diretório git está limpo, pede consentimento para as ferramentas do servidor MCP. Nada acontece sem que você saiba exatamente o que vai mudar.

Resolução de erros com Copilot

Erros de deploy são inevitáveis. Parâmetros faltando, problemas de permissão, disponibilidade de SKUs — e a mensagem de erro raramente diz a única coisa que você realmente precisa saber: como resolver.

Sem Copilot, o ciclo é: copiar o erro → pesquisar na documentação → ler três respostas irrelevantes do Stack Overflow → executar alguns comandos az CLI → tentar de novo e torcer. Com o Copilot integrado ao azd, esse ciclo colapsa. Quando qualquer comando azd falha, ele imediatamente oferece quatro opções:

Explain — descrição em linguagem natural do que deu errado
Guidance — instruções passo a passo para corrigir
Diagnose and Guide — análise completa + Copilot aplica a correção (com sua aprovação) + nova tentativa opcional
Skip — resolver você mesmo

O ponto crucial: o Copilot já tem contexto sobre seu projeto, o comando que falhou e a saída do erro. Suas sugestões são específicas para sua situação, não documentação genérica.

Configurar comportamento padrão

Se você sempre escolhe a mesma opção, pule o prompt interativo:

azd config set copilot.errorHandling.category troubleshoot

Valores: explain, guidance, troubleshoot, fix, skip. Você também pode habilitar auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Voltar ao modo interativo a qualquer momento:

azd config unset copilot.errorHandling.category

Conclusão

Esta é exatamente o tipo de integração do Copilot que agrega valor real. Experimente executando azd update para obter a versão mais recente e use azd init no seu próximo projeto.

Leia o anúncio original aqui.

VS Code 1.117: Os Agentes Estão Ganhando Suas Próprias Branches Git e Eu Tô Adorando

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

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

A linha entre “assistente de IA” e “colega de equipe de IA” continua ficando mais fina. O VS Code 1.117 acabou de sair e as notas de versão completas estão recheadas, mas a história é clara: os agentes estão se tornando cidadãos de primeira classe no seu fluxo de trabalho de desenvolvimento.

Aqui está o que realmente importa.

O modo Autopilot finalmente lembra sua preferência

Antes, você tinha que reativar o Autopilot toda vez que iniciava uma nova sessão. Irritante. Agora seu modo de permissão persiste entre sessões, e você pode configurar o padrão.

O Agent Host suporta três configurações de sessão:

Default — as ferramentas pedem confirmação antes de executar
Bypass — aprova tudo automaticamente
Autopilot — totalmente autônomo, responde suas próprias perguntas e segue em frente

Se você está montando um novo projeto .NET com migrations, Docker e CI — configure para Autopilot uma vez e esqueça. Essa preferência fica salva.

Worktree e isolamento git para sessões de agentes

Essa é a grande novidade. Sessões de agentes agora suportam isolamento completo com worktree e git. Isso significa que quando um agente trabalha em uma tarefa, ele ganha sua própria branch e diretório de trabalho. Sua branch principal fica intocada.

Melhor ainda — o Copilot CLI gera nomes de branch significativos para essas sessões de worktree. Chega de agent-session-abc123. Você recebe algo que realmente descreve o que o agente está fazendo.

Para desenvolvedores .NET que gerenciam múltiplas branches de features ou corrigem bugs enquanto uma tarefa longa de scaffolding roda, isso é um divisor de águas. Você pode ter um agente construindo seus controllers de API em um worktree enquanto você depura um problema na camada de serviços em outro. Sem conflitos. Sem stashing. Sem bagunça.

Subagentes e equipes de agentes

O Agent Host Protocol agora suporta subagentes. Um agente pode criar outros agentes para lidar com partes de uma tarefa. Pense nisso como delegar — seu agente principal coordena, e agentes especializados cuidam das partes.

Isso é cedo, mas o potencial para fluxos de trabalho .NET é óbvio. Imagine um agente cuidando das suas migrations do EF Core enquanto outro configura seus testes de integração. Ainda não chegamos totalmente lá, mas o suporte ao protocolo chegando agora significa que as ferramentas virão rápido.

Saída do terminal incluída automaticamente quando agentes enviam input

Pequeno mas significativo. Quando um agente envia input para o terminal, a saída do terminal agora é automaticamente incluída no contexto. Antes, o agente precisava de um turno extra só para ler o que aconteceu.

Se você já viu um agente executar dotnet build, falhar, e depois precisar de mais uma ida e volta só para ver o erro — essa fricção acabou. Ele vê a saída imediatamente e reage.

O app Agents no macOS se atualiza sozinho

O app independente Agents no macOS agora se atualiza sozinho. Chega de baixar novas versões manualmente. Ele simplesmente se mantém atualizado.

As coisas menores que vale a pena saber

Os hovers do package.json agora mostram tanto a versão instalada quanto a última disponível. Útil se você gerencia ferramentas npm junto com seus projetos .NET.
Imagens em comentários JSDoc são renderizadas corretamente em hovers e completions.
Sessões do Copilot CLI agora indicam se foram criadas pelo VS Code ou externamente — prático quando você está pulando entre terminais.
Copilot CLI, Claude Code e Gemini CLI são reconhecidos como tipos de shell. O editor sabe o que você está executando.

A conclusão

VS Code 1.117 não é um despejo de features chamativas. É infraestrutura. Isolamento com worktree, permissões persistentes, protocolos de subagentes — esses são os blocos de construção para um fluxo de trabalho onde agentes lidam com tarefas reais e paralelas sem pisar no seu código.

Se você está construindo com .NET e ainda não mergulhou no fluxo de trabalho com agentes, honestamente, agora é a hora de começar.

Docker Sandbox permite que agentes do Copilot refatorem seu código sem colocar sua máquina em risco

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

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

Se você já usou o modo agente do Copilot para algo além de edições pequenas, conhece a dor. Cada escrita de arquivo, cada comando no terminal — mais um prompt de permissão. Agora imagina isso em 50 projetos. Nada divertido.

O time do Azure acabou de publicar um post sobre Docker Sandbox para agentes do GitHub Copilot, e honestamente, essa é uma das melhorias mais práticas que eu já vi em ferramentas agênticas. Usa microVMs para dar ao Copilot um ambiente completamente isolado onde ele pode fazer de tudo — instalar pacotes, rodar builds, executar testes — sem tocar no seu sistema host.

O que o Docker Sandbox realmente te oferece

A ideia central é simples: subir uma microVM leve com um ambiente Linux completo, sincronizar seu workspace para dentro dela, e deixar o agente do Copilot operar livremente lá dentro. Quando termina, as mudanças são sincronizadas de volta.

Eis o que faz isso ser mais do que simplesmente “rodar coisas num container”:

Sincronização bidirecional do workspace que preserva caminhos absolutos. A estrutura do seu projeto fica idêntica dentro do sandbox. Sem falhas de build por causa de caminhos.
Docker daemon privado rodando dentro da microVM. O agente pode construir e rodar containers sem nunca montar o socket Docker do seu host. Isso é muito importante para segurança.
Proxies de filtragem HTTP/HTTPS que controlam o que o agente pode acessar na rede. Você decide quais registries e endpoints são permitidos. Ataques à cadeia de suprimentos por um npm install malicioso dentro do sandbox? Bloqueados.
Modo YOLO — sim, é assim que eles chamam. O agente roda sem prompts de permissão porque literalmente não consegue danificar seu host. Toda ação destrutiva está contida.

Por que desenvolvedores .NET deveriam se importar

Pense no trabalho de modernização que tantos times estão enfrentando agora. Você tem uma solução .NET Framework com 30 projetos e precisa migrá-la para .NET 9. São centenas de alterações de arquivos — arquivos de projeto, atualizações de namespaces, substituições de API, migrações de NuGet.

Com Docker Sandbox, você pode apontar um agente do Copilot para um projeto, deixá-lo refatorar livremente dentro da microVM, rodar dotnet build e dotnet test para validar, e só aceitar as mudanças que realmente funcionam. Sem risco dele acidentalmente destruir seu ambiente de desenvolvimento local enquanto experimenta.

O post também descreve rodar uma frota de agentes em paralelo — cada um no seu próprio sandbox — trabalhando em diferentes projetos simultaneamente. Para soluções .NET grandes ou arquiteturas de microsserviços, isso economiza uma quantidade enorme de tempo. Um agente por serviço, todos rodando isolados, todos validados independentemente.

O ângulo da segurança importa

Aqui está o que a maioria das pessoas ignora: quando você deixa um agente de IA executar comandos arbitrários, está confiando a ele toda a sua máquina. Docker Sandbox inverte esse modelo. O agente recebe autonomia total dentro de um ambiente descartável. O proxy de rede garante que ele só pode baixar de fontes aprovadas. Seu filesystem host, Docker daemon e credenciais ficam intocados.

Para times com requisitos de compliance — e isso é a maioria das empresas .NET — essa é a diferença entre “não podemos usar IA agêntica” e “podemos adotá-la com segurança.”

Conclusão

Docker Sandbox resolve a tensão fundamental da programação agêntica: agentes precisam de liberdade para serem úteis, mas liberdade na sua máquina host é perigoso. MicroVMs te dão os dois. Se você está planejando qualquer refatoração ou modernização .NET em larga escala, vale a pena configurar isso agora. A combinação da inteligência de código do Copilot com um ambiente de execução seguro é exatamente o que times de produção estavam esperando.

A avaliação de modernização do GitHub Copilot é a melhor ferramenta de migração que você ainda não está usando

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Migrar uma aplicação legada do .NET Framework para .NET moderno é uma daquelas tarefas que todo mundo sabe que deveria fazer, mas ninguém quer começar. Nunca é apenas “mudar o target framework.” São APIs que desapareceram, pacotes que não existem mais, modelos de hosting que funcionam de forma completamente diferente, e um milhão de pequenas decisões sobre o que containerizar, o que reescrever e o que deixar como está.

Jeffrey Fritz acabou de publicar um mergulho profundo na avaliação de modernização do GitHub Copilot, e honestamente? Este é o melhor tooling de migração que eu vi para .NET. Não pela geração de código — isso já é padrão agora. Pelo documento de avaliação que ele produz.

Não é apenas um motor de sugestões de código

A extensão do VS Code segue um modelo de Avaliar → Planejar → Executar. A fase de avaliação analisa todo o seu codebase e produz um documento estruturado que captura tudo: o que precisa mudar, quais recursos Azure provisionar, qual modelo de deploy usar. Tudo que vem depois — infraestrutura como código, containerização, manifestos de deploy — flui do que a avaliação encontra.

A avaliação é armazenada em .github/modernize/assessment/ no seu projeto. Cada execução produz um relatório independente, então você vai construindo um histórico e pode acompanhar como sua postura de migração evolui conforme corrige issues.

Duas formas de começar

Avaliação Recomendada — o caminho rápido. Escolha entre domínios curados (Upgrade Java/.NET, Cloud Readiness, Segurança) e obtenha resultados significativos sem mexer em configuração. Ótimo para um primeiro olhar de onde sua aplicação está.

Avaliação Personalizada — o caminho direcionado. Configure exatamente o que analisar: compute alvo (App Service, AKS, Container Apps), SO alvo, análise de containerização. Escolha múltiplos alvos Azure para comparar abordagens de migração lado a lado.

Essa visão de comparação é genuinamente útil. Uma app com 3 issues obrigatórios para App Service pode ter 7 para AKS. Ver ambos ajuda a tomar a decisão de hosting antes de se comprometer com um caminho de migração.

O detalhamento de issues é acionável

Cada issue vem com um nível de criticidade:

Obrigatório — deve ser corrigido ou a migração falha
Potencial — pode impactar a migração, precisa de julgamento humano
Opcional — melhorias recomendadas, não bloqueiam a migração

E cada issue linka para arquivos afetados e números de linha, fornece uma descrição detalhada do que está errado e por que importa para sua plataforma alvo, dá passos concretos de remediação (não apenas “corrija isso”), e inclui links para documentação oficial.

Você pode atribuir issues individuais a desenvolvedores e eles têm tudo que precisam para agir. Essa é a diferença entre uma ferramenta que diz “tem um problema” e uma que diz como resolver.

Os caminhos de upgrade cobertos

Para .NET especificamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada caminho de upgrade tem regras de detecção que sabem quais APIs foram removidas, quais padrões não têm equivalente direto, e quais issues de segurança precisam de atenção.

Para times que gerenciam múltiplas aplicações, também há um CLI que suporta avaliações batch multi-repo — clone todos os repos, avalie todos, obtenha relatórios por app mais uma visão agregada do portfólio.

Minha opinião

Se você está sentado em cima de aplicações legadas em .NET Framework (e vamos ser honestos, a maioria dos times enterprise está), esta é a ferramenta para começar. Só o documento de avaliação já vale o tempo — transforma um vago “deveríamos modernizar” em uma lista concreta e priorizada de itens de trabalho com caminhos claros adiante.

O fluxo de trabalho colaborativo também é inteligente: exporte avaliações, compartilhe com seu time, importe-as sem re-executar. Revisões de arquitetura onde quem toma decisões não é quem roda as ferramentas? Coberto.

Finalizando

A avaliação de modernização do GitHub Copilot transforma a migração .NET de um projeto assustador e indefinido em um processo estruturado e rastreável. Comece com uma avaliação recomendada para ver onde você está, depois use avaliações personalizadas para comparar alvos Azure e construir seu plano de migração.

Leia o walkthrough completo e baixe a extensão do VS Code para testar no seu próprio codebase.

A Engenharia de Plataformas Agêntica Está se Tornando Real — Git-APE Mostra Como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

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

Engenharia de plataformas tem sido um daqueles termos que soam ótimos em conferências, mas que normalmente significam “construímos um portal interno e um wrapper de Terraform.” A verdadeira promessa — infraestrutura self-service que seja realmente segura, governada e rápida — sempre esteve a alguns passos de distância.

O time Azure acaba de publicar a Parte 2 da série sobre engenharia de plataformas agêntica, e esta é toda sobre a implementação prática. Eles chamam de Git-APE (sim, a sigla é intencional), e é um projeto open source que usa agentes do GitHub Copilot mais servidores Azure MCP para transformar solicitações em linguagem natural em infraestrutura validada e implantada.

O que o Git-APE realmente faz

A ideia central: em vez de desenvolvedores aprenderem módulos Terraform, navegarem por UIs de portais ou abrirem tickets para o time de plataforma, eles conversam com um agente Copilot. O agente interpreta a intenção, gera Infrastructure-as-Code, valida contra políticas e implanta — tudo dentro do VS Code.

Aqui está a configuração:

git clone https://github.com/Azure/git-ape
cd git-ape

Abra o workspace no VS Code, e os arquivos de configuração do agente são descobertos automaticamente pelo GitHub Copilot. Você interage diretamente com o agente:

@git-ape deploy a function app with storage in West Europe

O agente usa o Azure MCP Server por baixo dos panos para interagir com os serviços Azure. A configuração MCP nas opções do VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por que isso importa

Para nós que construímos no Azure, isso muda a conversa de engenharia de plataformas de “como construímos um portal” para “como descrevemos nossas guardrails como APIs.” Quando a interface da sua plataforma é um agente de IA, a qualidade das suas restrições e políticas se torna o produto.

O blog da Parte 1 apresentou a teoria: APIs bem descritas, schemas de controle e guardrails explícitas tornam as plataformas agent-ready. A Parte 2 prova que funciona entregando ferramentas reais. O agente não gera recursos cegamente — valida contra melhores práticas, respeita convenções de nomenclatura e aplica as políticas da sua organização.

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

Vou ser honesto — aqui é mais sobre o padrão do que sobre a ferramenta específica. O Git-APE em si é uma demo/arquitetura de referência. Mas a ideia subjacente — agentes como a interface da sua plataforma, MCP como protocolo, GitHub Copilot como host — é para onde a experiência do desenvolvedor enterprise está caminhando.

Se você é um time de plataforma procurando como tornar seu ferramental interno amigável para agentes, não há melhor ponto de partida. E se você é um desenvolvedor .NET se perguntando como isso se conecta ao seu mundo: o Azure MCP Server e os agentes do GitHub Copilot funcionam com qualquer workload Azure. Sua API ASP.NET Core, seu stack .NET Aspire, seus microsserviços em containers — tudo pode ser alvo de um fluxo de deploy agêntico.

Concluindo

Git-APE é um olhar inicial mas concreto sobre engenharia de plataformas agêntica na prática. Clone o repo, experimente a demo e comece a pensar em como as APIs e políticas da sua plataforma precisariam ser para que um agente as use com segurança.

Leia o post completo para o walkthrough e vídeos de demonstração.

Atualização de março do Visual Studio permite criar agentes Copilot personalizados — e o find_symbol é revolucionário

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

O Visual Studio acabou de receber sua atualização Copilot mais significativa. Mark Downie anunciou a versão de março, e o destaque são os agentes personalizados — mas honestamente, a ferramenta find_symbol pode ser a que mais muda seu workflow.

Agentes Copilot personalizados no seu repo

Quer que o Copilot siga os padrões de código do seu time? Agentes personalizados são definidos como arquivos .agent.md em .github/agents/. Cada agente tem acesso completo ao workspace, compreensão de código, ferramentas, seu modelo preferido e conexões MCP.

Agent skills: pacotes de instruções reutilizáveis

Skills são carregados automaticamente de .github/skills/ no seu repo ou ~/.copilot/skills/ no seu perfil.

find_symbol: navegação com reconhecimento de linguagem

A nova ferramenta find_symbol dá ao modo agente do Copilot navegação de símbolos baseada em serviços de linguagem. Em vez de buscar texto, o agente pode encontrar todas as referências de um símbolo e acessar informações de tipo e escopo.

Para desenvolvedores .NET, é uma melhoria enorme — bases de código C# com hierarquias de tipos profundas se beneficiam enormemente.

Perfilar testes com Copilot

Há um novo Profile with Copilot no menu de contexto do Test Explorer. O Profiling Agent executa o teste e analisa performance automaticamente.

Perf tips durante debugging ao vivo

A otimização de performance agora acontece durante o debug. O Visual Studio mostra tempo de execução inline. Linha lenta? Clique no Perf Tip e peça sugestões ao Copilot.

Corrigir vulnerabilidades NuGet do Solution Explorer

Um link Fix with GitHub Copilot aparece diretamente no Solution Explorer quando uma vulnerabilidade é detectada.

Conclusão

Agentes personalizados e skills são o destaque, mas find_symbol é a joia escondida — muda fundamentalmente a precisão do Copilot ao refatorar código .NET. Baixe o Visual Studio 2026 Insiders para experimentar.