Developer Experience | The .NET Blog

Visual Studio の中で pull request をレビューできるのは、まさに私が好きな摩擦軽減です

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

この記事は自動翻訳されています。原文はこちらをご覧ください。

ブラウザは、コードレビューのワークフローからあまりにも長く、あまりにも多くを奪ってきました。

だからこそ、Visual Studio が IDE の中で最初から最後まで pull request をレビューする 方向へさらに進んでいるのを見るのは、とても嬉しいです。

これは大きな見出しを作るタイプの機能ではないかもしれませんが、日々の開発を確実に良くしてくれます。

主な価値は単純です。コンテキスト切り替えが減ること

レビューのループが IDE とブラウザの両方にまたがっていると、摩擦が積み重なります。

別の場所で PR を開く
あるツールで変更を確認する
より深く調べるために solution に戻る
コメントや承認のためにまた切り替える

それは致命的ではありません。ただ非効率なだけです。

Visual Studio が、同じ作業環境から PR を開き、確認し、コメントし、承認し、マージできるなら、それは本当の生産性向上です。

“checkout せずにレビュー” は特にいい機能です

私が特に気に入っているのは、PR ブランチを checkout せずにレビューできる点です。

小さく聞こえるかもしれませんが、次のような場面にぴったりです。

素早いレビュー
割り込みベースのフィードバック依頼
現在のブランチとローカル状態をそのまま保つこと

これはまさに、優れたコードレビューツールに必要な柔軟性です。

私見

これは革命的な機能ではありません。

もっと良いものです。実用的な機能です。

Visual Studio で一日の大半を過ごすチームにとって、PR レビューのサポートが強化されることは、ワークフローの中断を減らし、確認から行動までをより滑らかにします。

それは十分に価値のある改善だと思います。

原文: Visual Studio を離れずに pull request をレビューする

Agent Harnesses Matter Because Prompts Are Not Enough

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

エージェント開発における最も陥りやすい間違いのひとつは、プロンプトが製品そのものだと考えてしまうことである。

そうではない。

Microsoft Agent Framework チームによる新しいエージェントハーネスとクローのチュートリアルが価値を持つのは、エージェントを使い物にするかどうかを実際に決定する部分、すなわちモデルの周囲のランタイムシェルに焦点を当てているからだ。

それには以下が含まれる:

ツール
計画
セッション状態
メモリ
実行モード
イテレーションのための使えるコンソールまたはインターフェース

これこそが、エージェントが単なる巧妙なデモから、実際のソフトウェアのように感じられ始めるポイントである。

ハーネスパターンは実践的である

私が気に入っているのは、このアイデアがいかにアプローチしやすいかという点だ。

チャットクライアントから始める。

次に、それを指示とツールを持つハーネスでラップする。

そして、計画、TODO、セッション、ストリーミングインタラクションをサポートするシェルを通じて実行する。

これは健全なパターンである。なぜなら関心事を明確に分離しているからだ:

モデルは推論を担当する
ハーネスはランタイム動作を担当する
アプリはどのツールと体験が重要かを決定する

これは .NET 開発者のシステム構築方法に非常によく適合する

ハーネスのアイデアは .NET の考え方にも見事にマッピングされる。

ランタイム動作が明示的で構成可能である場合、私たちは通常より良い結果を出せる。ミドルウェア、パイプライン、オプション、プロバイダー、アダプターはすべてこの世界で自然に感じられる。

だからこそ、Agent Framework が .NET 開発者に受け入れられる可能性は高いと思う。全員をひとつの魔法の抽象化に押し込めるのではなく、配線可能な構造化されたランタイム部品を提供しているからだ。

私の見解

この記事の最も有用な部分は、エージェントには優れたモデルと巧妙な指示文字列以上のものが必要であるというリマインダーである。

エージェントには、構造、メモリ、ツールアクセス、計画、そして機能する開発者ループを与えるランタイムシェルが必要である。

それがハーネスが提供するものである。

そして正直なところ、だからこそこのパターンに注目する価値がある。

元記事: Meet your agent harness and claw

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

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

最高のツーリングアップデートとは、リリースノートで見栄えがするものではなく、数日使ってみて実感できるものである。

それが Aspire in VS Code 13.4 に対する私の印象である。

このアップデートはすべて、インナーループの強化に関するものである: プロジェクトの迅速な作成、複数言語リソースのより自然なデバッグ、エディタ上でのヘルスとコマンドの直接表示、ダッシュボードを唯一の作業場所にせずに近くに保つこと。

これは非常に良い方向性である。

最大の成果はコンテキストスイッチの削減

Aspire を本格的に使う場合、通常は複数の画面を行き来することになる:

AppHost コード
ターミナル
ダッシュボード
ログ
デバッグセッション
サービスエンドポイント

13.4 がうまくやっているのは、それらの画面間の摩擦を減らすことである。

新しい VS Code エクスペリエンスは、アプリの状態をユーザーがすでに作業している場所でより多く可視化する:

エディタ上のリソースヘルス
リソース宣言の横のコマンド
より簡単なダッシュボードアクセス
AppHost コンテキストからのログアクセス
フルデバッグ開始前でも有用なパネル

それは毎日使うと小さくは感じられない。

混在スタックのデバッグは人々が考える以上に重要

このアップデートの最も強力な部分のひとつは、C#、TypeScript、Python、Go、ブラウザアプリ、Azure Functions をひとつの Aspire 駆動フローでデバッグするためのより自然なストーリーである。

これは、すべてが単一のランタイムに存在するふりをするよりも、現代のアプリの実際の形状をはるかによく反映している。

特に .NET 開発者にとって、これは価値がある。なぜなら、私たちの多くは現在、API プロジェクト、フロントエンド、ワーカー、AI 関連サービスを異なる言語で混在させたシステムを構築しているからだ。

Aspire がこれを VS Code 内でより統一感のあるものにしていることは、非常に実用的な改善である。

TypeScript AppHost サポートの GA も重要

このリリースの TypeScript AppHost の側面も無視すべきではない。

Aspire が C# と TypeScript の両方でより自然になることで、奇妙なセカンドクラスのワークフローなしに同じシステムモデルで作業できる人が増える。これは、プラットフォームコード、フロントエンドコード、サービスオーケストレーションがすべて近接しているチームにとって重要である。

私の見解

VS Code における Aspire 13.4 は、ひとつのキラー機能に関するものではない。日々のループにおける粗いエッジを滑らかにすることである:

より速く開始する
コードを書く場所でより多くの状態を確認する
より自然にデバッグする
必要なときだけログとダッシュボードにジャンプする

それは優れたツールが進化するべき正確な方法である。

すでに Aspire を使用しているなら、このアップデートはインストールする価値がある。VS Code が Aspire ベースの開発の真剣な拠点かどうかまだ疑問に思っているなら、その答えはますます明確になりつつある。

元記事: Aspire in VS Code: the 13.4 developer loop

Visual Studio の新しい Plan agent は、実在する AI ワークフローの問題を解決します

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

この記事は自動翻訳されています。原文はこちらをご覧ください。

AI コーディングのワークフローで最もイライラするもののひとつは、実装が早すぎることです。

コード自体は技術的には問題ないこともありますが、頭の中にあった問題の別の版を解いてしまっています。

リファクタリングをしたかったのに、書き換えが始まった。範囲を絞った改善をしたかったのに、プロジェクトの半分に触れた。選択肢を話し合いたかったのに、すぐにファイル変更へ進んだ。

だからこそ、Visual Studio の新しい Plan agent はとても有用な追加機能です。

これは見た目の問題ではなく、実際のワークフローの問題を解決します

元の投稿は、とてもよくある状況をこう表現しています。"コードは間違っていない… ただ、あなたが望んだものではない。"

この一文は本当に的確です。

なぜなら、AI 支援開発の弱点はモデルがコードを出せるかどうかではないからです。実装が始まる前に、作業の意図した形について合意するための十分な余地がワークフローにあるかどうかが問題なのです。

それが特に重要なのは次のような場合です。

大きな機能
なじみのないコードベース
単純ではないリファクタリング
アーキテクチャに敏感な変更
編集を始める前にチームレビューが必要な作業

こうした状況では、すぐに実装へ飛び込むのはたいてい間違いです。

タスクが本物なら、計画はオーバーヘッドではありません

チームは、とても早く実装を始めることでどれだけ時間を失っているかを、時々見積もり違いしていると思います。

もし agent が:

間違ったファイルを触る
間違ったアプローチを選ぶ
重要な制約を見落とす
必要なエッジケースを無視する

なら、“速い” はずの開始が、全体としては遅いワークフローになります。

だからこそ、この機能が好きです。

次のための余地を作ります。

明確化の質問
計画の作成
計画の直接編集
コード変更が始まる前に計画を共有すること

それは官僚主義ではありません。多くの場合、ただの良いエンジニアリングです。

Markdown の plan ファイルは賢い選択です

特に気に入っている点のひとつは、すべての plan が .copilot/plans/plan-{title}.md に保存されることです。

これで計画のステップが具体的になります。

plan がチャットの transcript の中に閉じ込められません。次のようなものになります。

確認する
編集する
頭の中で version 管理する
チームと話し合う
より意図的に実装へ渡す

そのおかげで、この機能は単なる一時的な前置きではなく、かなり本格的に感じられます。

ここで AI ワークフローはチームのプロセスを尊重し始めます

これは、これらのツールが成熟してきている強い兆候のひとつだと思います。

優れた AI 開発ワークフローは、途中の手順を全部なくすものではありません。正しい途中の手順を改善するものです。

そして計画は、その手順のひとつです。

plan が強ければ、実装は簡単になります。 plan が弱ければ、実装は雑然とします。

この機能はそれをそのまま認めています。

私見

これは単なる AI の気の利いた機能ではありません。

ワークフローの改善です。

そして、実際の機能や実際のリファクタリングにおいては、不要な churn、レビューのノイズ、“それはそういう意味じゃない” という手戻りをかなり減らせる種類の改善です。

今後、もっと多くの agent 体験がこういうものを必要とするはずだと思います。

Visual Studio は、それを実用的な形で早く実現しました。

原文: ビルドする前に計画する: Visual Studio に Plan agent を導入

あなたの dev loop は tribal knowledge でいっぱいだ - そして Aspire は正しい答えを出している

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

この記事は自動翻訳されています。原文はこちらをご覧ください。

これは、Aspire の製品価値を理解するうえで最も重要な記事のひとつかもしれません。

大きな新機能を発表しているからではありません。

ほぼすべてのエンジニアリングチームが感じたことがあり、しかしすべてのチームがうまく言語化できているわけではない問題に名前を付けているからです。

dev loop は tribal knowledge でいっぱいだ。

この言葉が刺さるのは、それが事実だからです。

問題はツール不足ではない

元記事の中心的な主張は非常に優れています。チームはしばしば、インフラ、スクリプト、ダッシュボード、コマンドが足りないわけではありません。

足りないのは、アプリケーションの周りにある隠れた運用知識を、見えるもの、繰り返せるものに変える一貫したモデルです。

多くのアプリの本当のアーキテクチャは次の場所にあります。

shell history
バラバラのスクリプト
README の断片
Slack のスレッド
手順を知っている唯一の senior engineer

それは、人間にとって持続可能な dev loop ではありません。

そしてエージェントにとっては、なおさらです。

この投稿全体を要約していると思う引用

元記事には、全体のポイントをよく表している一文があります。

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

これが一行でこの主張のすべてです。

正直に言って、これは今まで見た中でも最も強い Aspire の一文説明のひとつです。

なぜ今は1年前よりも重要なのか

今この投稿が特に響くのは、AI 支援開発が曖昧さのコストを変えているからだと思います。

人間は不完全なシステムを驚くほどよく補完できます。

私たちは次のことを覚えています。

最初にどの script を実行するか
ひそかに必要な environment variable は何か
どの terminal がたいてい有用な logs を出すか
誰も文書化していない理由で、どの service を2回 restart しなければならないか

エージェントは、こうした隠れた運用上の folklore に対してははるかに弱いです。

だから、エージェントを実際の repository で本当に役立つものにしたいなら、システムをより explicit にする必要があります。逆ではありません。

その意味で、Aspire の framing は重要です。

Aspire の本当の価値は orchestration だけではない

よくある誤解は、Aspire を分散アプリの launcher か、ローカル orchestration ヘルパー程度に見ることです。

それでは小さすぎます。

より強い価値提案は、Aspire がアプリケーションに次のものを与えることです。

model
shape
named resources
explicit dependencies
health と operations の surface
人間と automation の両方が理解できる commands

これが dev loop を変える力は、時に想像以上です。

アプリが implicit な慣習の塊ではなく、実際の model を持つ system になった瞬間、次のものが同時に簡単になります。

onboarding
debugging
再現可能な setup
CI の一貫性
AI 支援ワークフロー

これは、たった一つの design choice から得られる大きな leverage です。

「commands as first-class operations」の観点が特に好きです

元記事のもうひとつの重要な点は、README の手順から resource-attached commands への移行です。

これは見た目以上に大きな変化です。

たとえばこうではなく:

この script を実行して、次にあれを、最初のものが失敗したら別のこれを

アプリの context の中で operation を直接 model 化できます。

それにより、人間はそれらを見つけやすくなります。

そして、エージェントは prose から意図を推測しなくて済みます。

これは、アプリケーションを「知っていれば操作できる」から「design により操作できる」に変える種類のものです。

team lead として何を得るか

この観点で自分のチームの dev loop を見るなら、私はいくつか率直な質問をします。

どれだけの部分が記憶に依存しているか
重要な dev action のうち、docs や chat thread にしか存在しないものはどれだけあるか
新しい contributor はどのくらい invisible な system behavior で詰まるか
automation tool や coding agent は repository から app topology を理解できるか

最後の質問の答えが「まったく無理」なら、この投稿は有益な痛点に触れるはずです。

私の考え

これは Aspire の本当の価値をとても強く表した framing です。

単なる orchestration ではありません。

app model を十分に explicit にすることで、system を運用し、理解し、自動化しやすくすることです。

それは人間にとって重要です。チームにとって重要です。そして、modern development の多くが agent-assisted workflows に向かっている今、さらに重要です。

これは、Aspire が単なる .NET の marketing label を超えて、なぜますます relevant に見えるのかを説明するのにぴったりな種類の記事です。

原文: あなたの dev loop は tribal knowledge でいっぱいだ— title: “あなたの Dev loop は暗黙知だらけで、Aspire には正しい答えがある” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Aspire の新しい投稿は非常に重要な点を指摘しています。多くのチームに足りないのはツールではなく、隠れた運用知識を人間・スクリプト・エージェントが本当に使えるものへ変える一貫したアプリケーションモデルです。” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

この記事は自動翻訳されています。原文はこちらをご覧ください。

これは、なぜ Aspire が重要なのかを理解するうえで、最も重要な記事のひとつかもしれません。

巨大な新機能を発表しているからではありません。

ほとんどすべてのエンジニアリングチームが感じていて、しかし全員がうまく言語化できているわけではない問題に名前を与えているからです。

Dev loop は暗黙知だらけです。

この一文が刺さるのは、まさに事実だからです。

問題はツール不足ではありません

元記事の中心的な主張は非常に優れています。チームに足りないのはたいてい、インフラでも、スクリプトでも、ダッシュボードでも、コマンドでもありません。

足りないのは、アプリケーションの周りにある隠れた運用知識を、見える形で再現可能なものへ変える一貫したモデルです。

多くのアプリの本当のアーキテクチャは次の場所にあります。

shell の履歴
散らばったスクリプト
README の断片
Slack のスレッド
手順を知っているたった一人のシニアエンジニア

それは、人間にとって持続可能な dev loop ではありません。

そしてもちろん、エージェントにとってもそうではありません。

この投稿全体を要約していると思う引用

元記事には、全体のポイントをとてもよく表している一文があります。

“アプリケーションはすでにシステムとして存在しています。Aspire はそのシステムを明示化します。なぜなら、明示されたシステムは暗黙知よりもよくスケールするからです。”

これが一行で示された全体の主張です。

正直に言って、これは私が今まで見た Aspire の一文説明の中でも、かなり強い部類です。

なぜ今この話が昨年より重要なのか

AI 支援開発は、あいまいさのコストを変えます。だからこそ、この投稿は今のタイミングで特に響きます。

人間は、不完全なシステムを驚くほど上手く補えます。

私たちは覚えています。

どのスクリプトを最初に実行するか
こっそり必要な環境変数は何か
どのターミナルが役に立つログを出すか
誰も文書化していない理由で、どのサービスを 2 回再起動する必要があるか

エージェントは、こうした隠れた運用上の folklore にかなり弱いです。

だから、エージェントを実際のリポジトリで本当に役立つものにしたいなら、システムをより明示的にする必要があります。逆ではありません。

それが、この Aspire の捉え方が重要だと思う理由です。

Aspire の本当の価値は orchestration だけではない

Aspire を単に分散アプリのランチャーやローカル orchestration ヘルパーとして見るのは、よくある誤解です。

それでは小さすぎます。

もっと強い価値は、Aspire がアプリケーションに次のものを与えることです。

モデル
形
名前付きリソース
明示的な依存関係
health と operations の面
人間と自動化の両方が理解できるコマンド

これは、思っている以上に dev loop を変えます。

なぜなら、アプリが暗黙の慣習の集まりであることをやめ、実際のモデルを持つシステムになった瞬間、いくつものことが一気に楽になるからです。

onboarding
debugging
再現可能なセットアップ
CI の一貫性
AI 支援ワークフロー

ひとつの設計判断から得られるレバレッジとしてはかなり大きいです。

「コマンドを第一級の操作として扱う」観点が特に良い

元記事の別のポイントで、もっと注目されてよいと思うのは、README の手順からリソースに結び付いたコマンドへの移行です。

これは見た目以上に大きな変化です。

このスクリプトを実行して、それからあれを、最初のものが失敗したら別のものを

と言う代わりに、アプリの文脈の中で操作を直接モデル化できます。

それによって、人間はそれらを見つけやすくなります。

そして、エージェントは文章から意図を推測する必要がなくなります。

これは、アプリを「すでに知っていれば操作できるもの」から「設計上、操作できるもの」へ変える類のことです。

チームリードとしてこれから何を受け取るか

この視点で自分のチームの dev loop を見るなら、私は次のような率直な質問をします。

セットアップのどれだけが記憶に依存しているか
重要な開発操作のうち、docs や chat thread にしか存在しないものはどれだけあるか
新しい貢献者が見えないシステム挙動でどれくらい詰まっているか
自動化ツールや coding agent は、リポジトリだけからアプリのトポロジーを理解できるか

最後の答えが「全然無理」なら、この投稿はきっと有益な痛点に触れます。

私見

これは Aspire の本当の価値を非常によく表した捉え方です。

単なる orchestration ではありません。

アプリのモデルを十分に明示的にして、システムを運用しやすく、理解しやすく、自動化しやすくすることです。

それは人間にとって重要です。チームにとって重要です。そして、現代の開発の多くがエージェント支援ワークフローに向かっている今、さらに重要です。

Aspire が .NET のマーケティングラベルを超えて、なぜますます重要に見えるのかを説明するのに、まさにこういう記事が役立ちます。

原文: あなたの Dev loop は暗黙知だらけ

Aspire の hermetic なエンドツーエンドテストは、もっと多くのチームが採用すべきパターンだ

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

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

フレークしやすいエンドツーエンドテストは、ダッシュボードには常に見えない形で高くつきます。

単に失敗するだけではありません。チームにフィードバックループを信用しなくなるよう、少しずつ学習させてしまいます。

だからこそ、Azure Chaos Studio + Aspire のこの記事はすぐに目に留まりました。派手な製品発表ではありません。エンドツーエンドテストを、運の悪さと交渉しているような感覚から引き離すにはどうすればいいのかを示す、実直なエンジニアリングの話です。

率直に言うと、もっと多くのチームがこのパターンを採用すべきだと思います。

コアの考え方はシンプルですが、効果は大きいです

重要なのは、各テストに固有の hermetic で一時的な環境 を与え、実際のサービス、実際の依存関係、そして状態に基づく明示的な起動を使うことです。

一文で読むと当たり前に見えます。しかし実際のシステムではずっと難しく、とくにクラウド依存、共有環境、分散サービスが絡むと一気に複雑になります。

元記事は問題をとても明確に表現しています。共有テスト環境には “クロストーク、フレーク、そして『staging を壊したのは誰だ』というグループチャット” が、運用コストとしてつきまといます。

この一文が笑えるのは、痛いほど本当だからです。

あまりにも多くのチームが、その取引を普通のこととして受け入れています。私は、そうすべきではないと思います。

このパターンがテスト以上に重要な理由

ここで一番気に入っているのは、この記事が単に「テストをより信頼できるようにした」と言っていないことです。

実際には、もっと大きなことを言っています。

分散システムが再現しづらく、分離しづらく、検証しづらいなら、エンジニアリング全体のループは遅くなる。

これは CI だけの話ではありません。

影響するのは、たとえば次のような点です。

開発者がどれだけ安心してリファクタリングできるか
リグレッションをどれだけ速く診断できるか
大きなアーキテクチャ変更をどれだけ安全に試せるか
自動検証にチームがどれだけ信頼を置けるか

そして 2026 年には、AI 支援開発がどれだけ役立つかにも影響します。

記事で最も重要な引用

記事の中に、何度でも繰り返したい一文があります。

“Agent は完璧である必要はありません。検証可能である必要があります。”

これはとても良い捉え方です。

AI コーディング agent が、非自明な作業を助けるのに十分信頼できるのかは、よく議論されます。私は、より良い問いは 私たちのシステムがその作業を正しく評価できるほどテスト可能かどうか だと思います。

agent が意味のある refactor を提案しても、唯一の安全信号が、共有環境で動く脆くて半ランダムな end-to-end チェックの山だけなら、問題は agent だけではありません。

問題は検証モデルです。

この Aspire パターンはそれを大きく改善します。

この実装を特に良くしている点

元の話には、これを単なる「テストを改善しました」という曖昧な投稿以上のものにしている要素がいくつもあります。

1. 偽の mock 劇場ではなく、本物のサービスグラフ

テストは、end-to-end 検証を装う断片的な mock の山の上には作られていません。

本物のバイナリ を実行し、可能なところでは emulator をつなぎ、ローカル開発と同じ application model を使っています。

これは重要です。

end-to-end テストが mock 対 mock の劇場になった瞬間、実際の構成について信頼できることを何も教えてくれなくなります。

2. 魔法の sleep ではなく、状態に基づく起動

この点は見た目以上に重要です。

記事では、テストが WaitForResourceHealthyAsync を使って本当の health を待ち、恣意的な時間の推測に頼らないことが明示されています。

これは大きな違いです。

「30 秒寝て、うまくいくことを祈る」テスト suite は、要するに不確実性を記録しているだけです。実際の readiness を待つ suite は、システムの意図を記録しています。

3. 同じモデルがローカル開発とテストを動かす

これは Aspire の強いストーリーとよく噛み合っています。

同じ application model が次を動かします。

ローカル開発
サービス接続
emulator 化した依存関係
health check
hermetic なテスト orchestration

これにより drift が減ります。drift は、信頼を静かに壊す最大の敵のひとつです。

こうした devex への投資は軽く見られがちです

この投稿を単なる短い反応ではなく、もう少し長くしたかった理由のひとつは、こうした engineering 改善はしばしば軽視されると思っているからです。

派手ではありません。

新しい AI 機能のように demo しやすいわけでもありません。

経営層を一発で沸かせるスライドになるとも限りません。

でも時間が経つと、もっと価値のあるものを生みます。品質について自分たちに嘘をつかずに、より速く動けるチーム です。

それはとても大きなことです。

記事によると、今では約 90 個の hermetic test を実行しており、zone outage、DNS failure、geo-replication failure のようなシナリオも含まれています。これは単なる test hygiene の改善ではありません。分散プラットフォームに対する、はるかに強い信頼モデルです。

分散 .NET システムを運用していたら、私なら何を持ち帰るか

今、分散サービス、Aspire、CI/CD パイプラインに取り組んでいるなら、私はすぐに次を持ち帰ります。

共有環境の flakiness を普通だと思うのをやめる
可能な限り health ベースの startup gate に移行する
AppHost を本物の production-grade orchestration code として扱う
個々のサービスの正しさだけでなく、サービス構成を検証する end-to-end check を作る
AI 支援開発を採用するなら、オートメーションの幅を広げる前に、まず checkability に投資する

この最後の点こそ、もっと多くのチームが聞くべきことです。

私の考え

これは今回の中でもかなり強い Aspire 記事です。非常に実用的な問題を解決しています。

抽象論で感心させようとしていません。実際の分散システムで、end-to-end テストをどうやってより deterministic に、より有用に、より信頼できるものにするかを示しています。

そして agent 支援開発とのつながりが見えてくると、このパターンはさらに説得力を増します。

もし、あなたの end-to-end テスト戦略が今も共有環境、隠れたセットアップ知識、そして少しの祈りに依存しているなら、これはぜひ学ぶ価値があります。

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