Developer Experience | The .NET Blog

Ревью pull request прямо внутри Visual Studio — это именно тот тип снижения трения, который мне нравится

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

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

Браузер слишком долго забирал на себя слишком большую часть workflow code review.

Поэтому я очень рад видеть, что Visual Studio двигается дальше в сторону end-to-end review pull request прямо внутри IDE.

Это одна из тех функций, которые, возможно, не попадут в большие заголовки, но при этом могут заметно улучшить ежедневную разработку.

Главная ценность проста: меньше переключения контекста

Когда ваш review loop живёт частично в IDE, а частично в браузере, трение накапливается:

открыть PR в другом месте
посмотреть изменения в одном инструменте
вернуться к solution для более глубокого изучения
снова переключиться, чтобы оставить комментарий или одобрить

Это не катастрофа. Это просто неэффективно.

Если Visual Studio позволит открывать, изучать, комментировать, одобрять и merge делать из той же рабочей среды, это будет реальный выигрыш в продуктивности.

Опция “review без checkout” особенно хороша

Одна вещь, которая мне особенно нравится, — возможность делать review без checkout ветки PR.

Это может звучать мелко, но отлично подходит для:

быстрых проходов review
feedback-запросов, возникающих во время прерываний
сохранения текущей ветки и локального состояния без изменений

Это именно тот тип гибкости, который нужен хорошим code review tools.

Моё мнение

Это не революционная функция.

Это лучше: это практичная функция.

Для команд, которые проводят большую часть дня в Visual Studio, более тесная поддержка PR review означает меньше разрывов workflow и более плавный путь от инспекции к действию.

На мой взгляд, это достойное улучшение.

Оригинальная публикация: Ревью pull request без выхода из Visual Studio

Оболочки агентов важны, потому что промптов недостаточно

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

Одна из самых простых ошибок в разработке агентов — считать, что промпт и есть продукт.

Это не так.

Новый обзор agent harness и claw от команды Microsoft Agent Framework ценен тем, что удерживает фокус именно на той части, которая действительно определяет, ощущается ли агент пригодным к использованию: на runtime-оболочке вокруг модели.

Сюда входят:

инструменты
планирование
состояние сессии
память
режимы исполнения
удобная консоль или интерфейс для итераций

Именно здесь агенты перестают быть эффектными демо и начинают ощущаться как программное обеспечение.

Паттерн harness — практичный

Что мне здесь нравится — насколько доступна эта идея.

Вы начинаете с chat-клиента.

Затем оборачиваете его в harness с инструкциями и инструментами.

Затем запускаете через оболочку, которая поддерживает планирование, списки задач, сессии и потоковое взаимодействие.

Это здоровый паттерн, потому что он чётко разделяет ответственности:

модель отвечает за рассуждение
harness отвечает за поведение времени выполнения
приложение решает, какие инструменты и сценарии важны

Это очень хорошо согласуется с тем, как .NET-разработчики строят системы

Идея harness также хорошо ложится на мышление .NET.

Обычно у нас лучше получается, когда поведение времени выполнения явно и композируемо. Middleware, пайплайны, опции, провайдеры и адаптеры — всё это ощущается естественным в этом мире.

Именно поэтому я думаю, что у Agent Framework хорошие шансы прижиться у .NET-разработчиков. Он не загоняет всех в одну магическую абстракцию. Он даёт вам структурированные компоненты времени выполнения, которые вы можете собрать вместе сами.

Моё мнение

Самая полезная часть этого поста — напоминание о том, что агентам нужно нечто большее, чем хорошая модель и удачная строка инструкции.

Им нужна runtime-оболочка, которая даёт структуру, память, доступ к инструментам, планирование и рабочий цикл разработки.

Именно это и даёт harness.

И, честно говоря, именно поэтому этот паттерн заслуживает внимания.

Оригинальный пост: Meet your agent harness and claw

Aspire в VS Code 13.4 правильно подтягивает цикл разработки

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

Лучшие обновления инструментов — те, которые вы ощущаете спустя несколько дней, а не те, что просто хорошо выглядят в release notes.

Именно так я воспринимаю Aspire в VS Code 13.4.

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

Это очень хорошее направление.

Главная победа — меньше переключений контекста

Если вы серьёзно используете Aspire, вы обычно перемещаетесь между несколькими поверхностями:

код AppHost
терминал
дашборд
логи
сессии отладки
эндпоинты сервисов

13.4 хорошо справляется со снижением трения между этими поверхностями.

Новый опыт в VS Code делает больше состояния приложения видимым именно там, где вы уже работаете:

здоровье ресурсов в редакторе
команды рядом с декларациями ресурсов
более лёгкий доступ к дашборду
доступ к логам из контекста AppHost
панель, полезная ещё до начала полноценной отладки

Это звучит незначительно, пока вы не начинаете делать так каждый день.

Отладка смешанных стеков важнее, чем кажется

Одна из самых сильных частей этого обновления — более естественная история отладки C#, TypeScript, Python, Go, браузерных приложений и Azure Functions в едином процессе на базе Aspire.

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

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

Тот факт, что Aspire делает это более единым внутри VS Code, — очень практичное улучшение.

Достижение GA у поддержки TypeScript AppHost также значимо

Я бы не стал игнорировать сторону TypeScript AppHost в этом релизе.

То, что Aspire становится более естественным и для C#, и для TypeScript, расширяет круг тех, кто может работать в одной и той же модели системы без странных процессов второго сорта. Это важно для команд, где платформенный код, фронтенд-код и оркестрация сервисов живут рядом друг с другом.

Моё мнение

Aspire 13.4 в VS Code — не про одну убийственную функцию. Это про сглаживание шероховатостей в ежедневном цикле:

быстрее стартовать
видеть больше состояния там, где вы пишете код
отлаживать более естественно
переходить к логам и дашборду только тогда, когда нужно

Именно так и должны развиваться хорошие инструменты.

Если вы уже используете Aspire, это обновление выглядит достойным установки. Если вы всё ещё сомневаетесь, серьёзное ли VS Code место для разработки на Aspire, ответ становится всё очевиднее.

Оригинальный пост: Aspire in VS Code: the 13.4 developer loop

Новый Plan agent в Visual Studio решает очень реальную проблему AI-workflow

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

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

Один из самых раздражающих AI coding workflow — это когда реализация начинается слишком быстро.

Код может даже быть технически нормальным, но он решает не ту версию проблемы, которую вы имели в виду.

Вы хотели рефакторинг. Начался rewrite. Вы хотели scoped improvement. Он затронул половину проекта. Вы хотели обсудить варианты. Он сразу перешёл к изменениям файлов.

Вот почему новый Plan agent в Visual Studio — настолько полезное дополнение.

Это решает реальную проблему workflow, а не просто косметическую

В оригинальном посте описана очень знакомая ситуация: “Код не неправильный… он просто не такой, как вы хотели.”

Эта фраза отличная.

Потому что слабое место многих AI-assisted development не в том, может ли модель генерировать код. Вопрос в том, создаёт ли workflow достаточно пространства, чтобы договориться о нужной форме работы до начала реализации.

Это особенно важно для:

больших функций
незнакомых codebase
нетривиальных рефакторингов
архитектурно чувствительных изменений
работы, которой нужен team review до начала правок

В таких ситуациях сразу прыгать в implementation часто означает сделать неверный ход.

Планирование не является overhead, когда задача настоящая

Мне кажется, команды иногда недооценивают, сколько времени они теряют, начиная реализацию слишком рано.

Если agent:

трогает не те файлы
выбирает не тот подход
пропускает важное ограничение
игнорирует нужный edge case

то “быстрый” старт в итоге превращается в более медленный workflow в целом.

Именно поэтому мне нравится эта функция.

Она создаёт пространство для:

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

Это не бюрократия. Чаще всего это просто хорошая инженерия.

Markdown-файл плана — это разумный выбор

Особенно мне нравится то, что каждый plan сохраняется в .copilot/plans/plan-{title}.md.

Это делает этап планирования осязаемым.

План не заперт внутри chat transcript. Он становится чем-то, что вы можете:

просматривать
редактировать
мысленно отслеживать версии
обсуждать с командой
более осознанно передавать в реализацию

Благодаря этому функция выглядит гораздо серьёзнее, чем просто временное вступление перед генерацией кода.

Здесь AI workflows начинают уважать процесс команды

Мне кажется, это один из сильных признаков того, что эти tools взрослеют.

Лучшие AI developer workflow — это не те, что убирают все промежуточные шаги. Это те, что улучшают правильные промежуточные шаги.

И планирование — один из таких шагов.

Если plan сильный, implementation становится проще. Если plan слабый, implementation становится шумной.

Эта функция признаёт это напрямую.

Моё мнение

Это не просто AI nicety.

Это улучшение workflow.

И для настоящих функций и настоящих рефакторингов это именно тот тип улучшения, который может сэкономить много лишнего churn, review noise и rework в духе “я имел в виду не это”.

Думаю, всё больше agent experiences в итоге будут нуждаться в чём-то подобном.

Visual Studio пришёл к этому раньше и сделал это полезным образом.

Оригинальная публикация: Планируйте перед сборкой: представляем Plan agent в Visual Studio

Ваш dev loop полон неявных знаний, и у Aspire есть правильный ответ

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

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

Это, возможно, один из самых важных постов про Aspire для понимания того, почему продукт важен.

Не потому, что он анонсирует огромную новую функцию.

А потому, что он называет проблему, которую почувствовала почти каждая инженерная команда, но не каждая сумела хорошо описать:

dev loop полон неявных знаний.

Эта фраза цепляет, потому что она правдива.

Проблема не в нехватке инструментов

Основной тезис оригинальной статьи отличный: командам часто не не хватает инфраструктуры, скриптов, дашбордов или команд.

Им не хватает согласованной модели, которая превращает все скрытые операционные знания вокруг приложения в нечто видимое и воспроизводимое.

Настоящая архитектура многих приложений живёт в:

shell history
разбросанных скриптах
фрагментах README
Slack-threads
одном senior engineer, который знает порядок операций

Это неустойчивый dev loop для людей.

И уж точно не для агентов.

Цитата, которая, как мне кажется, подытоживает весь пост

В оригинальной статье есть одна фраза, которая очень хорошо передаёт главную мысль:

“Приложения уже существуют как системы. Aspire делает эти системы явными, потому что явные системы масштабируются лучше, чем неявные знания.”

Это и есть вся аргументация в одной строке.

И, честно говоря, это одно из самых сильных однофразовых объяснений Aspire, которые я видел.

Почему это важнее сейчас, чем год назад

Я думаю, эта статья особенно хорошо попадает в текущий момент, потому что AI-assisted development меняет цену неоднозначности.

Люди удивительно хорошо компенсируют неполные системы.

Мы помним:

какой script запускать первым
какая переменная окружения тайно нужна
какой terminal обычно показывает полезные логи
какой service нужно перезапустить дважды по причинам, которые никто не документировал

Агенты намного хуже справляются с таким скрытым operational folklore.

Поэтому, если мы хотим, чтобы агенты действительно были полезны в реальных репозиториях, нам нужно делать систему более явной, а не менее.

Вот почему такой framing Aspire важен.

Настоящая ценность Aspire — не только orchestration

Распространённая ошибка с Aspire — воспринимать его только как distributed app launcher или локальный orchestration-helper.

Это слишком узко.

Более сильная value proposition в том, что Aspire даёт приложению:

model
shape
именованные resources
explicit dependencies
health и operations surface
commands, которые могут понять и люди, и automation

Это меняет dev loop сильнее, чем иногда кажется.

Потому что, когда app перестаёт быть кучей implicit conventions и становится system с реальной моделью, несколько вещей сразу становятся проще:

onboarding
debugging
repeatable setup
consistency CI
AI-assisted workflows

Это очень большая отдача от одного design choice.

Особенно мне нравится угол про “commands как first-class operations”

Ещё один момент из оригинальной статьи, который, на мой взгляд, заслуживает больше внимания, — переход от README instructions к commands, привязанным к resources.

Это обманчиво большое изменение.

Вместо:

запусти этот script, потом тот, а если первый сломается, возможно, ещё и этот другой

можно моделировать operations прямо в контексте приложения.

Это означает, что люди могут находить их проще.

И это означает, что агентам не нужно гадать об intent по prose.

Это то, что превращает приложение из “operable, если ты уже его знаешь” в “operable by design”.

Что бы я вынес из этого как team lead

Если бы я посмотрел на dev loop своей команды через эту линзу, я бы задал несколько прямых вопросов:

насколько наша настройка зависит от памяти?
сколько критических dev actions существует только в docs или chat threads?
как часто новые contributors застревают из-за невидимого system behavior?
сможет ли automation tool или coding agent понять нашу app topology только по repo?

Если ответ на последний вопрос — “даже близко нет”, то этот пост должен задеть полезную струну.

Моё мнение

Это очень сильный framing реальной ценности Aspire.

Это не просто orchestration.

Речь о том, чтобы сделать application model достаточно явной, чтобы system было проще эксплуатировать, понимать и автоматизировать.

Это важно для людей. Это важно для команд. И это ещё важнее сейчас, когда большая часть современного development движется к agent-assisted workflows.

Это именно тот тип статьи, который помогает объяснить, почему Aspire кажется всё более значимым за пределами просто .NET marketing label.

Оригинальная публикация: Ваш dev loop полон неявных знаний

Герметичные end-to-end тесты Aspire — это паттерн, который стоило бы перенять большему числу команд

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

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

Нестабильные end-to-end тесты обходятся дорого, и не всегда это видно на дашборде.

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

Именно поэтому статья про Azure Chaos Studio + Aspire сразу привлекла моё внимание. Это не яркий продуктовый анонс. Это приземлённая инженерная история о том, как сделать так, чтобы end-to-end тесты перестали ощущаться как переговоры с удачей.

И, честно говоря, я думаю, что большему числу команд стоит перенять этот паттерн.

Основная идея проста, но выигрыш огромен

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

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

В оригинальной статье проблема описана очень ясно: общие тестовые окружения приносят “cross-talk, flaky behavior и сообщения в групповом чате в стиле ‘кто сломал staging?’” как часть операционных затрат.

Эта фраза смешная, потому что она болезненно правдива.

Слишком многие команды принимают такой обмен как норму. Я не думаю, что так должно быть.

Почему этот паттерн важен не только для тестов

Больше всего мне нравится здесь то, что статья не просто говорит: “мы сделали наши тесты надёжнее”.

Она говорит нечто большее:

если вашу распределённую систему трудно воспроизвести, трудно изолировать и трудно проверить, весь ваш инженерный цикл замедляется.

Это влияет не только на CI.

Это влияет на то:

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

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

Самая важная цитата в статье

В статье есть одна фраза, которую, на мой взгляд, стоит повторить:

“Agents не обязаны быть идеальными. Они должны быть проверяемыми.”

Это отличная формулировка.

Люди много времени тратят на вопрос, достаточно ли надёжны AI coding agents, чтобы помогать в нетривиальной работе. Я думаю, лучший вопрос звучит так: достаточно ли тестируемы наши системы, чтобы правильно оценивать эту работу.

Если agent предлагает осмысленный refactor, а единственный сигнал безопасности — это куча хрупких, полурандомных end-to-end проверок, запускаемых в общем окружении, то проблема не только в agent.

Проблема в модели валидации.

Этот Aspire-паттерн радикально улучшает ситуацию.

Что делает эту реализацию особенно хорошей

Несколько деталей исходной истории делают её гораздо больше, чем просто очередной пост в духе “мы улучшили тесты”.

1. Настоящий граф сервисов, а не театр фальшивых mock’ов

Тесты не строятся на куче разрозненных mock’ов, которые делают вид, что это end-to-end валидация.

Они запускают реальные бинарники, подключают emulators там, где это возможно, и используют ту же application model, что и в локальной разработке.

Это важно.

Потому что как только end-to-end тесты превращаются в театр mock против mock, они перестают давать что-либо надёжное о реальной композиции.

2. Запуск на основе health вместо магических sleep

Этот момент важнее, чем кажется.

Статья прямо говорит, что тесты ждут реальный health с помощью WaitForResourceHealthyAsync, а не полагаются на произвольные догадки по времени.

Разница огромная.

Test suite, который говорит: “спи 30 секунд и надейся на лучшее”, по сути документирует неопределённость. Suite, который ждёт реальную readiness, документирует намерение системы.

3. Одна и та же модель управляет локальной разработкой и тестами

Мне это особенно нравится, потому что это хорошо совпадает с самыми сильными историями про Aspire в целом.

Одна и та же application model управляет:

локальной разработкой
wiring сервисов
эмулированными зависимостями
health checks
hermetic orchestration тестов

Это уменьшает drift, а drift — один из самых тихих убийц доверия.

Такой тип инвестиций в devex часто недооценивают

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

Они не бросаются в глаза.

Их не продемонстрируешь как новую AI-функцию.

И не всегда они дают один слайд, который сразу зажигает руководство.

Но со временем они создают нечто куда более ценное: команду, которая может двигаться быстрее, не обманывая себя насчёт качества.

Это очень важно.

В статье сказано, что теперь они запускают около 90 hermetic тестов, включая сценарии вроде zone outage, DNS failure и geo-replication failure. Это не просто лучшая test hygiene. Это гораздо более сильная модель доверия для распределённой платформы.

Что бы я вынес из этого, если бы управлял распределённой .NET-системой

Если вы сегодня работаете с распределёнными сервисами, Aspire и CI/CD-пайплайнами, я бы сразу вынес следующее:

перестаньте нормализовать flaky behavior в общих окружениях
переходите на health-based startup gates, где это возможно
относитесь к AppHost как к настоящему production-grade orchestration code
стройте end-to-end checks, которые валидируют композицию сервисов, а не только корректность отдельных сервисов
если вы внедряете разработку с поддержкой ИИ, сначала инвестируйте в checkability, а уже потом гонитесь за более широкой автоматизацией

Именно последний пункт, по моему мнению, должны услышать больше команд.

Моё мнение

Это один из самых сильных материалов про Aspire в этом наборе, потому что он решает очень практичную проблему.

Он не пытается впечатлить абстракцией. Он показывает, как сделать end-to-end тесты более детерминированными, более полезными и более надёжными в реальной распределённой системе.

И как только видна связь с development, поддержанным agent’ами, паттерн становится ещё убедительнее.

Если ваша история end-to-end тестов всё ещё зависит от общих окружений, скрытых знаний о настройке и немного молитвы, это действительно стоит изучить.

Оригинальный пост: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests