GitHub Copilot | The .NET Blog

Azure DevOps MCP Сервер Апрельское Обновление: WIQL-Запросы, PAT Аутентификация и Экспериментальные MCP Apps

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

Этот пост был автоматически переведён. Для оригинальной версии нажмите здесь.

Azure DevOps MCP Сервер продолжает совершенствоваться. Апрельское обновление Дэна Хеллема охватывает оба сервера.

Поддержка WIQL-Запросов

Новый инструмент wit_query_by_wiql позволяет запускать Work Item Query Language запросы прямо из MCP-клиента.

Personal Access Tokens

PAT аутентификация на локальном сервере — важна для интеграционных сценариев без интерактивной аутентификации.

Аннотации MCP

Метаданные для read-only, destructive и open-world инструментов — основа надёжности агентов.

Консолидация Wiki-Инструментов

5 отдельных wiki-инструментов → 2 более мощных. Меньше инструментов = лучше производительность LLM.

Экспериментально: MCP Apps

Упакованные рабочие процессы в среде MCP-сервера. Направление правильное.

Оригинальный пост Дэна Хеллема: Azure DevOps MCP Server April Update.

VS Code 1.118: Copilot CLI получает имена сессий, значки модели и TypeScript 7.0 Nightly

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

Этот пост был переведён автоматически. Для просмотра оригинала нажмите здесь.

Visual Studio Code 1.118 — небольшой сфокусированный релиз, в основном с улучшениями Copilot CLI.

Copilot CLI: сессии получают настоящие имена

API заголовков сессий SDK Copilot CLI теперь используются как источник истины для имён сессий. Вместо автоматически сгенерированных меток сессии показывают реальное имя из SDK.

Быстрое переключение между сессиями

В приложение Agents теперь добавлены Ctrl+1, Ctrl+2 и т.д. для быстрого переключения между сессиями.

Значки модели в чате

Ответы Copilot CLI в панели чата теперь показывают значок модели — можно с первого взгляда понять, какая модель обработала каждый запрос.

Автоматический выбор модели в Copilot CLI

Функция автоматического выбора модели теперь работает и в агенте Copilot CLI.

Подключение TypeScript 7.0 Nightly

Теперь можно включить тестирование ночных сборок TypeScript 7.0 прямо из настроек VS Code. TypeScript 7.0 — значительный релиз (бета вышла несколько дней назад).

Смотрите полные примечания к релизу.

68 Минут в День на Переобъяснение Кода? Есть Решение

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

Этот пост был автоматически переведён. Для оригинальной версии нажмите здесь.

Знаете тот момент, когда сессия Copilot достигает /compact и агент полностью забывает, над чем вы работали? Следующие пять минут вы тратите на повторное объяснение структуры файлов, неудачного теста, трёх подходов, которые уже пробовали. Затем это происходит снова.

Деси Вильянуэва измерил: 68 минут в день — только на переориентацию. Не на написание кода, не на ревью PR. Просто на то, чтобы снова ввести ИИ в курс дела.

Ложь о Контекстном Окне

Реальная математика: из 200K токенов, MCP инструменты съедают ~65K, файлы инструкций ~10K. В итоге ~125K до того, как вы напечатали хоть слово. LLM деградируют при 60% заполнении — реальный лимит 45K токенов.

Налог на Компактизацию

Жестокая часть: память уже существует. Copilot CLI записывает каждую сессию в локальную SQLite базу по адресу ~/.copilot/session-store.db. Агент просто не может её прочитать.

auto-memory: Слой Отзыва, Не Система Памяти

pip install auto-memory

~1900 строк Python. Нулевые зависимости. Устанавливается за 30 секунд.

Вместо того чтобы заполнять контекст результатами grep, вы даёте агенту хирургический доступ к тому, что реально важно — 50 токенов вместо 10 000.

Заключение

Context rot — это реальное архитектурное ограничение. auto-memory обходит его, давая агенту дешёвый и точный механизм отзыва.

Посмотрите: auto-memory на GitHub. Оригинальный пост Деси Вильянуэвы: I Wasted 68 Minutes a Day.

azd + GitHub Copilot: настройка проекта с помощью ИИ и умное исправление ошибок

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

Эта статья переведена автоматически. Оригинальную версию на английском можно найти здесь.

Знаком ли вам момент, когда хочешь задеплоить существующее приложение в Azure и смотришь на пустой azure.yaml, пытаясь вспомнить, какой тип хостинга выбрать для Express API — Container Apps или App Service? Этот момент станет намного короче.

Azure Developer CLI (azd) теперь интегрируется с GitHub Copilot двумя практичными способами: AI-ассистированный скаффолдинг проекта при azd init и интеллектуальное устранение ошибок при сбое деплоя. Обе функции работают полностью в терминале — именно там, где они и должны быть.

Настройка с Copilot при azd init

При запуске azd init теперь появляется опция “Set up with GitHub Copilot (Preview)”. Выберите её, и Copilot проанализирует вашу кодовую базу, чтобы сгенерировать azure.yaml, шаблоны инфраструктуры и Bicep-модули — на основе вашего реального кода.

azd init
# Выберите: "Set up with GitHub Copilot (Preview)"

Что потребуется:

azd 1.23.11 или новее — проверьте azd version или обновитесь через azd update
Активная подписка GitHub Copilot (Individual, Business или Enterprise)
GitHub CLI (gh) — azd запросит вход при необходимости

Что мне по-настоящему нравится: это работает в обоих направлениях. Строите с нуля? Copilot поможет настроить правильные сервисы Azure с самого начала. Есть существующее приложение, которое давно хотели задеплоить? Направьте на него Copilot — конфигурация будет сгенерирована без необходимости что-либо переструктурировать.

Что происходит на самом деле

Допустим, у вас есть Node.js Express API с зависимостью от PostgreSQL. Вместо того чтобы вручную выбирать между Container Apps и App Service, а затем писать Bicep с нуля, Copilot определит стек и сгенерирует:

azure.yaml с правильными настройками language, host и build
Bicep-модуль для Azure Container Apps
Bicep-модуль для Azure Database for PostgreSQL

Перед любыми изменениями выполняются предварительные проверки — убеждается в чистоте рабочей директории git, заранее запрашивает согласие на инструменты MCP-сервера. Ничего не произойдёт без вашего понимания того, что именно изменится.

Устранение ошибок с помощью Copilot

Ошибки деплоя неизбежны. Пропущенные параметры, проблемы с правами, недоступность SKU — и сообщение об ошибке редко подсказывает именно то, что нужно: как это исправить.

Без Copilot цикл выглядит так: скопировать ошибку → искать в документации → читать три нерелевантных ответа на Stack Overflow → выполнить команды az CLI → попробовать снова. С Copilot в azd этот цикл рушится. При любом сбое команды azd сразу предлагаются четыре варианта:

Explain — простое объяснение того, что пошло не так
Guidance — пошаговые инструкции по исправлению
Diagnose and Guide — полный анализ + Copilot применяет исправление (с вашего одобрения) + опциональный повтор
Skip — разобраться самостоятельно

Ключевой момент: у Copilot уже есть контекст вашего проекта, упавшей команды и деталей ошибки. Его предложения специфичны именно для вашей ситуации.

Настройка поведения по умолчанию

Если всегда выбираете одно и то же, пропустите интерактивный запрос:

azd config set copilot.errorHandling.category troubleshoot

Значения: explain, guidance, troubleshoot, fix, skip. Можно включить автоматическое исправление и повтор:

azd config set copilot.errorHandling.fix allow

Вернуться к интерактивному режиму в любой момент:

azd config unset copilot.errorHandling.category

Итоги

Запустите azd update для получения последней версии и попробуйте azd init на следующем проекте. Это именно та интеграция Copilot, которая приносит реальную ценность.

Читайте оригинальное объявление здесь.

VS Code 1.117: Агенты получают собственные ветки Git, и я полностью за

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

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Грань между «ИИ-ассистентом» и «ИИ-тиммейтом» продолжает стираться. VS Code 1.117 только что вышел, и полные заметки о релизе насыщены, но суть ясна: агенты становятся полноценными участниками вашего рабочего процесса разработки.

Вот что действительно важно.

Режим Autopilot наконец запоминает ваши настройки

Раньше приходилось заново включать Autopilot каждый раз при запуске новой сессии. Раздражало. Теперь режим разрешений сохраняется между сессиями, и вы можете настроить значение по умолчанию.

Agent Host поддерживает три конфигурации сессии:

Default — инструменты запрашивают подтверждение перед запуском
Bypass — автоматически одобряет всё
Autopilot — полностью автономный, сам отвечает на свои вопросы и продолжает работу

Если вы создаёте новый .NET-проект с миграциями, Docker и CI — установите Autopilot один раз и забудьте. Эта настройка сохранится.

Worktree и git-изоляция для сессий агентов

Это главное. Сессии агентов теперь поддерживают полную изоляцию worktree и git. Это значит, что когда агент работает над задачей, он получает собственную ветку и рабочую директорию. Ваша основная ветка остаётся нетронутой.

Ещё лучше — Copilot CLI генерирует осмысленные имена веток для этих worktree-сессий. Никаких больше agent-session-abc123. Вы получаете название, которое действительно описывает, чем занимается агент.

Для .NET-разработчиков, управляющих несколькими feature-ветками или исправляющих баги, пока длительная задача скаффолдинга выполняется, это кардинально меняет ситуацию. Можно поручить агенту создавать API-контроллеры в одном worktree, пока вы отлаживаете проблему в сервисном слое в другом. Никаких конфликтов. Никакого стеширования. Никакого хаоса.

Субагенты и команды агентов

Agent Host Protocol теперь поддерживает субагентов. Агент может запускать других агентов для обработки частей задачи. Считайте это делегированием — ваш главный агент координирует, а специализированные агенты занимаются отдельными частями.

Это пока на ранней стадии, но потенциал для .NET-рабочих процессов очевиден. Представьте: один агент обрабатывает ваши миграции EF Core, пока другой настраивает интеграционные тесты. Мы ещё не совсем там, но поддержка протокола появляется сейчас — значит, инструменты подтянутся быстро.

Вывод терминала автоматически включается, когда агенты отправляют ввод

Мелочь, но значимая. Когда агент отправляет ввод в терминал, вывод терминала теперь автоматически включается в контекст. Раньше агенту требовался дополнительный ход, чтобы просто прочитать, что произошло.

Если вы когда-нибудь наблюдали, как агент запускает dotnet build, терпит неудачу, а потом делает ещё один round-trip, чтобы увидеть ошибку — это трение исчезло. Он видит вывод мгновенно и реагирует.

Приложение Agents на macOS обновляется автоматически

Автономное приложение Agents на macOS теперь обновляется самостоятельно. Больше не нужно вручную скачивать новые версии. Оно просто остаётся актуальным.

Мелочи, которые стоит знать

Подсказки package.json теперь показывают и установленную версию, и последнюю доступную. Полезно, если вы управляете npm-инструментами наряду с .NET-проектами.
Изображения в комментариях JSDoc корректно отображаются в подсказках и автодополнении.
Сессии Copilot CLI теперь показывают, были ли они созданы в VS Code или извне — удобно, когда переключаетесь между терминалами.
Copilot CLI, Claude Code и Gemini CLI распознаются как типы оболочек. Редактор знает, что вы запускаете.

Итог

VS Code 1.117 — это не броский набор фич. Это инфраструктура. Изоляция worktree, постоянные разрешения, протоколы субагентов — это строительные блоки для рабочего процесса, в котором агенты выполняют реальные параллельные задачи, не затрагивая ваш код.

Если вы разрабатываете на .NET и ещё не погрузились в агентный рабочий процесс, честно говоря, сейчас самое время начать.

Docker Sandbox позволяет агентам Copilot рефакторить ваш код без риска для машины

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

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Если вы использовали агентный режим Copilot для чего-то большего, чем мелкие правки, вы знаете эту боль. Каждая запись файла, каждая команда в терминале — ещё один запрос на разрешение. А теперь представьте это на 50 проектах. Совсем не весело.

Команда Azure опубликовала пост о Docker Sandbox для агентов GitHub Copilot, и, честно говоря, это одно из самых практичных улучшений в агентном инструментарии, которое я видел. Система использует микро-ВМ, чтобы дать Copilot полностью изолированную среду, где он может делать всё что угодно — устанавливать пакеты, запускать сборки, выполнять тесты — не затрагивая вашу хост-систему.

Что Docker Sandbox реально даёт

Основная идея проста: запустить легковесную микро-ВМ с полноценным окружением Linux, синхронизировать в неё ваше рабочее пространство и позволить агенту Copilot свободно работать внутри. Когда он закончит, изменения синхронизируются обратно.

Вот что делает это чем-то большим, чем просто «запустить что-то в контейнере»:

Двусторонняя синхронизация рабочего пространства с сохранением абсолютных путей. Структура вашего проекта выглядит идентично внутри песочницы. Никаких ошибок сборки из-за путей.
Приватный Docker-демон работает внутри микро-ВМ. Агент может собирать и запускать контейнеры, не монтируя Docker-сокет вашего хоста. Это серьёзное преимущество для безопасности.
HTTP/HTTPS-фильтрующие прокси контролируют, к чему агент может обращаться в сети. Вы решаете, какие реестры и эндпоинты разрешены. Атаки на цепочку поставок через вредоносный npm install внутри песочницы? Заблокированы.
Режим YOLO — да, именно так они его называют. Агент работает без запросов на разрешения, потому что буквально не может повредить ваш хост. Каждое деструктивное действие изолировано.

Почему разработчикам .NET стоит обратить внимание

Подумайте о работе по модернизации, с которой сейчас сталкивается так много команд. У вас есть решение на .NET Framework с 30 проектами, и его нужно перенести на .NET 9. Это сотни изменений в файлах — файлы проектов, обновления пространств имён, замена API, миграция NuGet.

С Docker Sandbox вы можете направить агента Copilot на проект, позволить ему свободно рефакторить внутри микро-ВМ, запустить dotnet build и dotnet test для валидации и принять только те изменения, которые реально работают. Никакого риска, что он случайно разрушит вашу локальную среду разработки во время экспериментов.

В посте также описывается запуск флота параллельных агентов — каждый в своей песочнице — одновременно работающих над разными проектами. Для крупных .NET-решений или микросервисных архитектур это огромная экономия времени. Один агент на сервис, все работают изолированно, все валидируются независимо.

Вопрос безопасности имеет значение

Вот что большинство людей упускает: когда вы позволяете ИИ-агенту выполнять произвольные команды, вы доверяете ему всю вашу машину. Docker Sandbox переворачивает эту модель. Агент получает полную автономию внутри одноразовой среды. Сетевой прокси гарантирует, что он может загружать только из одобренных источников. Ваша хостовая файловая система, Docker-демон и учётные данные остаются нетронутыми.

Для команд с требованиями комплаенса — а это большинство корпоративных .NET-компаний — это разница между «мы не можем использовать агентный ИИ» и «мы можем внедрить его безопасно».

Итог

Docker Sandbox решает фундаментальное противоречие агентного программирования: агентам нужна свобода, чтобы быть полезными, но свобода на вашей хост-машине опасна. Микро-ВМ дают вам и то, и другое. Если вы планируете масштабный рефакторинг или модернизацию .NET, стоит настроить это прямо сейчас. Сочетание интеллекта Copilot в работе с кодом и безопасной среды выполнения — это именно то, чего ждали продакшн-команды.

Агентная платформенная инженерия становится реальностью — Git-APE показывает как

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

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Платформенная инженерия была одним из тех терминов, которые звучат отлично на конференциях, но обычно означают «мы построили внутренний портал и обёртку для Terraform.» Настоящее обещание — самообслуживающаяся инфраструктура, которая действительно безопасна, управляема и быстра — всегда была в нескольких шагах.

Команда Azure только что опубликовала Часть 2 серии об агентной платформенной инженерии, и эта часть целиком о практической реализации. Они называют это Git-APE (да, акроним намеренный), и это open-source проект, который использует агенты GitHub Copilot плюс серверы Azure MCP для превращения запросов на естественном языке в валидированную и развёрнутую инфраструктуру.

Что Git-APE делает на самом деле

Основная идея: вместо того чтобы разработчики изучали модули Terraform, навигировали по UI порталов или создавали тикеты для платформенной команды, они разговаривают с агентом Copilot. Агент интерпретирует намерение, генерирует Infrastructure-as-Code, валидирует его по политикам и разворачивает — всё внутри VS Code.

Вот настройка:

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

Откройте workspace в VS Code, и файлы конфигурации агента автоматически обнаруживаются GitHub Copilot. Вы взаимодействуете с агентом напрямую:

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

Агент использует Azure MCP Server под капотом для взаимодействия с сервисами Azure. Конфигурация MCP в настройках VS Code активирует конкретные возможности:

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

Почему это важно

Для тех из нас, кто строит на Azure, это смещает разговор о платформенной инженерии с «как построить портал» на «как описать наши ограничения как API.» Когда интерфейс вашей платформы — это ИИ-агент, качество ваших ограничений и политик становится продуктом.

Блог Части 1 изложил теорию: хорошо описанные API, схемы контроля и явные ограничения делают платформы agent-ready. Часть 2 доказывает, что это работает, поставляя реальные инструменты. Агент не генерирует ресурсы вслепую — он валидирует по лучшим практикам, соблюдает соглашения об именовании и применяет политики вашей организации.

Очистка так же проста:

@git-ape destroy my-resource-group

Моё мнение

Буду честен — здесь больше о паттерне, чем о конкретном инструменте. Git-APE сам по себе — это демо/референсная архитектура. Но лежащая в основе идея — агенты как интерфейс к вашей платформе, MCP как протокол, GitHub Copilot как хост — вот куда движется experience корпоративного разработчика.

Если вы — платформенная команда, которая ищет, как сделать внутренние инструменты agent-friendly, лучшего стартового пункта не найти. А если вы .NET-разработчик и думаете, как это связано с вашим миром: Azure MCP Server и агенты GitHub Copilot работают с любыми нагрузками Azure. Ваш ASP.NET Core API, ваш стек .NET Aspire, ваши контейнеризированные микросервисы — всё это может быть целью агентного потока деплоя.

Подведём итоги

Git-APE — это ранний, но конкретный взгляд на агентную платформенную инженерию на практике. Клонируйте репозиторий, попробуйте демо и начните думать о том, как API и политики вашей платформы должны выглядеть, чтобы агент мог безопасно их использовать.

Читайте полный пост для walkthrough и видео-демонстраций.

Оценка модернизации GitHub Copilot — лучший инструмент миграции, который вы ещё не используете

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

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Миграция устаревшего приложения .NET Framework на современный .NET — одна из тех задач, о которых все знают, что их нужно сделать, но никто не хочет начинать. Это никогда не просто «сменить целевой фреймворк». Это API, которые исчезли, пакеты, которых больше нет, модели хостинга, которые работают совершенно по-другому, и миллион мелких решений о том, что контейнеризировать, что переписать и что оставить как есть.

Джеффри Фриц только что опубликовал глубокий разбор оценки модернизации GitHub Copilot, и честно? Это лучший инструмент миграции для .NET, который я видел. Не из-за генерации кода — это уже стандарт. Из-за документа оценки, который он создаёт.

Это не просто движок предложений кода

Расширение VS Code следует модели Оценить → Спланировать → Выполнить. Фаза оценки анализирует всю кодовую базу и создаёт структурированный документ, фиксирующий всё: что нужно изменить, какие ресурсы Azure предоставить, какую модель развёртывания использовать. Всё последующее — инфраструктура как код, контейнеризация, манифесты развёртывания — вытекает из результатов оценки.

Оценка хранится в .github/modernize/assessment/ вашего проекта. Каждый запуск создаёт независимый отчёт, поэтому вы накапливаете историю и можете отслеживать, как меняется ваша позиция по миграции по мере исправления проблем.

Два способа начать

Рекомендованная оценка — быстрый путь. Выберите из курируемых доменов (Обновление Java/.NET, облачная готовность, безопасность) и получите значимые результаты без настройки конфигурации. Идеально для первого взгляда на состояние вашего приложения.

Пользовательская оценка — прицельный путь. Настройте точно, что анализировать: целевой compute (App Service, AKS, Container Apps), целевую ОС, анализ контейнеризации. Выберите несколько целей Azure для сравнения подходов к миграции бок о бок.

Это представление сравнения действительно полезно. Приложение с 3 обязательными проблемами для App Service может иметь 7 для AKS. Видеть оба варианта помогает принять решение по хостингу до того, как вы привяжетесь к пути миграции.

Разбивка проблем действенна

Каждая проблема сопровождается уровнем критичности:

Обязательная — необходимо исправить, иначе миграция провалится
Потенциальная — может повлиять на миграцию, требует человеческого суждения
Необязательная — рекомендуемые улучшения, не блокируют миграцию

И каждая проблема ссылается на затронутые файлы и номера строк, предоставляет подробное описание того, что не так и почему это важно для вашей целевой платформы, даёт конкретные шаги по устранению (не просто «исправьте это») и включает ссылки на официальную документацию.

Вы можете передать отдельные проблемы разработчикам, и у них есть всё необходимое для действий. В этом разница между инструментом, который говорит «есть проблема» и инструментом, который говорит, как её решить.

Охваченные пути обновления

Для .NET конкретно:

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

Каждый путь обновления имеет правила обнаружения, которые знают, какие API были удалены, какие паттерны не имеют прямого эквивалента и какие проблемы безопасности требуют внимания.

Для команд, управляющих несколькими приложениями, есть также CLI, поддерживающий пакетные оценки нескольких репозиториев — клонируйте все репо, оцените их все, получите отчёты по каждому приложению плюс агрегированное представление портфолио.

Моё мнение

Если вы сидите на устаревших приложениях .NET Framework (а давайте будем честны, большинство корпоративных команд именно так и делает), это тот самый инструмент, с которого стоит начать. Только документ оценки стоит потраченного времени — он превращает расплывчатое «нам бы модернизировать» в конкретный, приоритизированный список рабочих элементов с чёткими путями вперёд.

Коллаборативный рабочий процесс тоже продуман: экспортируйте оценки, поделитесь с командой, импортируйте без повторного запуска. Архитектурные ревью, где решения принимают не те, кто запускает инструменты? Учтено.

Подводя итоги

Оценка модернизации GitHub Copilot превращает миграцию .NET из пугающего, неопределённого проекта в структурированный, отслеживаемый процесс. Начните с рекомендованной оценки, чтобы увидеть текущее состояние, затем используйте пользовательские оценки для сравнения целей Azure и построения плана миграции.

Прочитайте полное руководство и установите расширение VS Code, чтобы попробовать на своей кодовой базе.

Мартовское обновление Visual Studio позволяет создавать собственные агенты Copilot — и find_symbol меняет правила игры

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

Этот пост был переведён автоматически. Оригинальную версию можно найти здесь.

Visual Studio только что получила самое значительное обновление Copilot. Mark Downie объявил о мартовском релизе, и заголовок — пользовательские агенты, но честно говоря, инструмент find_symbol может оказаться функцией, которая больше всего изменит ваш рабочий процесс.

Пользовательские агенты Copilot в вашем репозитории

Хотите, чтобы Copilot следовал стандартам кодирования вашей команды? Пользовательские агенты определяются как файлы .agent.md в .github/agents/. Каждый агент имеет полный доступ к workspace, пониманию кода, инструментам, вашей предпочтительной модели и MCP-соединениям.

Навыки агента: переиспользуемые наборы инструкций

Навыки автоматически подхватываются из .github/skills/ в вашем репозитории или ~/.copilot/skills/ в профиле.

find_symbol: навигация с поддержкой языка

Новый инструмент find_symbol даёт агентному режиму Copilot навигацию по символам на основе языковых сервисов. Вместо текстового поиска агент может находить все ссылки на символ и получать доступ к информации о типах и области видимости.

Для .NET-разработчиков это огромное улучшение — кодовые базы на C# с глубокими иерархиями типов получают огромную пользу.

Профилирование тестов с Copilot

В контекстном меню Test Explorer появился Profile with Copilot. Profiling Agent запускает тест и автоматически анализирует производительность.

Perf Tips во время отладки

Оптимизация производительности теперь происходит прямо во время отладки. Visual Studio показывает время выполнения inline. Увидели медленную строку? Кликните Perf Tip и попросите Copilot предложить оптимизации.

Исправление уязвимостей NuGet из Solution Explorer

При обнаружении уязвимости NuGet-пакета в Solution Explorer появляется ссылка Fix with GitHub Copilot.

Подведём итоги

Пользовательские агенты и навыки — заголовок, но find_symbol — скрытая жемчужина, которая фундаментально меняет точность Copilot при рефакторинге .NET-кода. Скачайте Visual Studio 2026 Insiders, чтобы всё попробовать.