1773251808
2026-03-11 17:40:00
今年の初めに、 ピアース・ボガンMicrosoft の VS Code および GitHub Copilot のプロダクト リードである 氏は、製品管理の世界に静かに爆弾発言をしました。彼のチームは、エンジニアではなく PM が AI エージェントを使用してユーザー向けの機能を定義、プロトタイプ、評価できるツールを構築していました。 「本当の力は、これが PM のワークフローをどのように変えるかです」と彼は 1 月 9 日付けの記事で書いています。 LinkedInの投稿では、PM がシナリオを定義し、それを GitHub Copilot に渡して実装し、数日間ビルドを自己ホストし、プロトタイプが運用準備が整うまで反復されるループを説明しています。
反応は素早く、鋭いものでした。熱心な人もいました。実際、マイクロソフトの同僚 PM は、それを「スーパーパワー」を持っているような感覚と呼んでいました。他の人たちは押し返した。 「別の道を行く必要があると思う」と書いた アルヌール・イスマイル元マイクロソフトのエンジニア。 「あなたのエンジニアが担当すべきです」 [who] このツールを使用してください。彼らはコードベースを知っているので、ここを活用することで顧客に近づくことができます。」
それから２か月後の今、 新しいスタック ボガンに会い、実験が実際にどのように行われているかを確認しました。彼の答えは率直かつ具体的で、時には驚くべきものでした。AI が打ち破るのに貢献した 10 年間のリリース サイクル、数千万のユーザーに配信された PM 作成の PR、そして「エージェント対応のコードベース」がすべてのエンジニアリング チームが現在必要としているメタ スキルであると彼が考える理由に触れました。
このインタビューは、明確かつ簡潔にするために編集されています。
VS Code チームは現在、プロダクト マネージャーやエンジニアの日常業務を支援するために、具体的にどのような AI ツール、モデル、または内部エージェントを使用していますか?
ピアース・ボガン： VS Code チームの核となる原則は、常に VS Code を使用して VS Code を構築するということです。同じことが AI にも当てはまります。プロダクト マネージャーとして、私は常に VS Code と GitHub Copilot を自己ホストするように努めています。 VS Code は最大のオープンソース リポジトリの 1 つであり、安定版リリースを毎週数千万のユーザーに配布しています。
私の朝は、カレンダー、メール、Teams メッセージを取り込むプロンプト ファイルから始まります。 仕事のIQ また、GitHub MCP を使用して、製品およびエンジニアリングの更新に関する関連コンテキストを取得します。私はこのプロンプト ファイルを利用して、過去 24 時間の VS Code の新機能をすべて要約しています。
当社の中核となる PM ワークフローのほとんどは、VS Code と Copilot でも実行されます。フィードバック リポジトリを分析するための専用プロンプト、ソーシャル メディアを分析するための専用 Web アプリ、ドキュメントやリリース ノートを最新の状態に保つための AI を活用した自動化などです。
エンジニアリング面では、 彭劉、VS Code の主任ソフトウェア エンジニアリング マネージャーなどは、VS Code を離れることなく過去 24 時間のコミットを要約し、問題のグルーミングと重複排除を行うワークフローに合わせたカスタム エージェントとスラッシュ コマンドを構築しました。私たちが使用するのは コパイロットのコードレビュー 人間によるレビューの前に必須の最初のパスとしてすべての PR に適用されます。チームはまた、実際に VS Code を起動し、機能に移動し、スクリーンショットを撮り、変更が期待どおりに機能するかどうかを評価することで、GitHub Copilot が自己検証できるようにする「demonstrate」と呼ばれるカスタム エージェントも構築しました。
モデル側には、VS Code ハーネスでさまざまなモデルがどのように動作するかを知らせる独自の内部ベンチマーク (vsc-bench) があります。コミットの要約には、より高速なモデルを使用します。コードの生成またはレビューには、利用可能な中で最も機能的なものを使用します。場合によっては、複数のモデルを並列サブエージェントに生成し、相互の作業を評価させます。
ツールは急速に進化しているため、現在使用しているものと 1 か月後に使用しているものはおそらく異なっています。それが重要な点です。
PR 向けのソリューションのプロトタイプをどのように作成しているかについて詳しく教えていただけますか?
私にとっての変化は根本的なものでした。仕様や PRD に相当するものはプロトタイプになり、そのプロトタイプが PR になります。
X、Reddit、GitHub の問題など、誰かがフィードバックをくれると、エクスペリエンスがどうあるべきかについてドキュメントを書く代わりに、VS Code でプラン モードを開いてビルドを開始します。製品について書くだけでなく、使用するにつれて仕様が研ぎ澄まされます。
たとえば、私たちの前日、 エージェントセッションデー 録音中に、副操縦士チャットで会話を分岐するための PR を送信しました。私たちのエンジニアの 1 人が私にフィードバックをくれ、私たちはいくつかの CSS 変更を一緒に検討し、それをマージしました。それは現在 VS Code にあります。
これが最もうまく機能するのは、UI とインタラクション レベルの変更、つまり「これは正しいか?」という点です。質問は実際にはエクスペリエンスに関するものであり、アーキテクチャに関する深い決定ではありません。ただし、明確にしておきたいのは、エンジニアは依然としてコードの品質とアーキテクチャに対して責任を負っているということです。 Peng が私の PR を見て「これは正しく設計されていない」と言ったとしても、それは完全に公平です。私はコードが破棄されて再構築されても問題ありません。
実際に起こっているのは、役割の境界が崩れつつあるということです。私は常にプロダクト思考を持っていましたが、構築スキルによって制限されていました。それがボトルネックではなくなりました。
AI 導入の直接的な影響を定量化するために、チームは具体的にどのような指標を追跡していますか?
最も具体的な証拠の 1 つは、すべての VS Code ユーザーが目にすることができます。10 年間毎月リリースを行った後、毎週リリースに移行しました。リリース サイクルのオーバーヘッド (トリアージ、テスト、リリース ノート、安定化) には、以前は丸 1 か月のリズムが必要でした。現在では、その十分な部分が自動化またはエージェント支援されているため、毎週のペースを維持しながら品質を維持することができます。
コミット速度は実際に継続的に増加しています。以前は git fetch を使用した場合、コミット数は 20 または 30 でした。今では、1 日あたり 100 件以上が定期的に発生しています。 PR サイクル時間が短縮されました。また、当社のエージェントベースのトリアージ パイプラインは、初期の並べ替え、重複検出、所有者の割り当てを処理します。これには、以前は毎週専任の人間がローテーションする必要がありました。
品質に関しては、注意しないとベロシティに悪影響を与える可能性があるため、回帰率を注意深く監視しています。私たちが最も気にしている指標は、「安定版に出荷する回帰は以前よりも少ないか?」ということです。今のところ、答えは「はい」ですが、常に注意を払う必要があります。
AI ツールが開発プロセスにさらに深く統合されるにつれて、チームは今後 1 ～ 2 年で役割がどのように進化すると予想していますか??
「プロダクトを考える人」と「プロダクトを作る人」の境界は本当に曖昧になってきています。誰もが結果に対してよりフルスタックで貢献するようになっています。
エンジニアリングの面では、エージェントがあらゆるコンポーネントへの貢献を誰でも支援できるようになると、「ここは私の担当分野だから、外に出ないでください」という従来のモデルは成り立ちません。人々を締め出すのではなく、安全に迎え入れるためには、テスト、文書化、明確な所有権境界などのハーネスが必要です。
仕事の機械的な部分 (定型文の作成、日常的な問題の優先順位付け、レビューでの一般的なバグの検出など) は、エージェントによって処理されることが増えています。より価値のあるものとなるのは、センス、判断力、そして実際にそれを使う人が喜ぶかどうかを評価する能力です。コードベースをエージェント対応にするために投資したチームは、倍増の利益を得るでしょう。これは、すべてのエンジニアリング チームが今開発する必要があるメタ スキルです。
YouTube.COM/THENEWSTACK
テクノロジーの進歩は速いので、エピソードを見逃さないでください。 YouTube チャンネルに登録すると、すべてのポッドキャスト、インタビュー、デモなどをストリーミングできます。
購読する
スケッチで作成されたグループ。
Darryl K. Taft は、ボルチモア地域のオフィスで DevOps、ソフトウェア開発ツール、開発者関連の問題をカバーしています。彼はこの業界で 25 年以上の経験があり、常に次のスクープを探しています。彼は働いてきました…
ダリル・K・タフトの続きを読む
#Microsoft #の #Code #チームは10 #年間の月次リリースを経て週次リリースに移行しましたそれを可能にしたのは #のおかげだと評価しています