スタンフォード大学の新しいAIエンジニアリングカリキュラム、コーディングからレビューへ焦点を移行

スタンフォード大学で「The Modern Software Developer」を教えており、Monaco社でAI部門を率いるMihail Eric氏は、コーディングエージェントが支配する時代においてソフトウェアエンジニアがどのように学ぶべきかに対応するために、カリキュラムを更新しました。AI Engineer YouTubeチャンネルとの最近の対談で、Eric氏は学術的な課題やプロフェッショナルなワークフローが、コードを書くことから、その評価、エージェント環境の管理、そしてコードベース内の歴史的コンテキストの理解へとシフトしていることを説明しました。

何が起きたのか

スタンフォード大学のCS146Sコースの構成は、第1回と第2回の開講間で大きく変化しました。当初、このコースには9つの課題とキャップストーンプロジェクトが含まれており、その一つでは学生がリポジトリに対してAIコードレビュアーを実行し、そのフィードバックを評価することが求められていました。しかし、Eric氏は学生たちがすでにエージェントを広く使用しており、多くの場合、以前の練習問題を単一のプロンプトで完了させていたことに気づきました。その結果、現在のシラバスでは、これらの孤立したタスクの多くが、人間のメンテナーが学生のパッチをレビューするオープンソースプロジェクトへの貢献という要件に置き換えられています。

このシフトにより、学生は単なる実装を超えた、ソフトウェア開発の社会的および技術的現実に関与せざるを得なくなります。エージェントが一晩で機能実装を生成できる場合でも、学生はメンテナーがその変更を望んでいるかどうかを判断し、既存のコードがなぜそのように動作するのかを理解し、潜在的な破損を予測する必要があります。このプロセスは、ジュニアエンジニアとシニアエンジニア間の学習動態を反映しており、価値は生の出力そのものではなく、会話と批判にあります。

Monaco社では、Eric氏のチームも専門的なエンジニアリングプラクティスにおいて同様の哲学を採用しています。彼らはさまざまなコードレビュー製品を評価し、特定のタスクについてはDevinの使用を継続することを決定しました。しかし、既製のエージェントワークスペースは、背景エージェントが製品を実行し、障害を再現し、パッチをテストするために具体的な環境を必要とするため、彼らのニーズを満たさないことが判明しました。これらの詳細はMonaco社の特定のクラウドセットアップに大きく依存しているため、チームは独自ワークスペースインフラストラクチャを構築し、Halという内部ツールを作成しました。

仕組み

Halは、会社内の異なる役割に対する統一インターフェースとして機能し、エージェントの出力がユーザーの意図に合わせて調整される必要があることを示しています。エンジニアはHalに本番環境の問題を調査し、修正を含むプルリクエストを生成するよう依頼できます。営業担当者は同じシステムに製品機能がどのように動作するかを尋ねることができます。前者の場合、出力は人間のレビュー用に準備されたコード変更であり、後者の場合は顧客コミュニケーションに適した説明です。この区別は、生のデバッグ出力がエンジニアにとってのみ有用である一方、他のステークホルダーには統合された回答が必要であることを強調しています。

このワークフローの重要な要素は、「権限マップ（authority map）」の問題に対処することです。エージェントが変更を提案する場合、通常、コードの現在の状態のみを見ます。6か月前に類似の変更がなぜ拒否されたのか、または現在の設計を駆動したアーキテクチャ上の決定事項についての可視性を持っていません。これを解決するために、チームは過去のプルリクエストの議論や意思決定ログなど、歴史的コンテキストへのアクセスをエージェントに提供する必要があります。このコンテキストがない場合、エージェントは以前に誤りまたは望ましくないと判断された解決策を繰り返し提案する可能性があります。

Eric氏はまた、AI生成コードに対する人間の理解を深めるための手法にも言及しています。一つの手法には、Geoffrey Litt氏のexplain-diffスキルなどのツールを使用することが含まれます。これはコード変更を視覚的なウォークスルーに変換し、開発者に変更点についてクイズを出します。このアプローチにより、エンジニアはエージェントが書いたコードを盲目的にマージせず、統合前にロジックと潜在的な副作用に対する理解を検証することが保証されます。

主要な詳細

• スタンフォード大学のCS146Sでは、孤立したAI評価演習を完了する代わりに、人間のメンテナーによるレビュー付きでオープンソースプロジェクトに貢献することが学生に義務付けられるようになりました。
• Monaco社は、既存のソリューションがテストと再現のために特定のクラウド環境を十分に複製できなかったため、独自のエージェントワークスペースツールHalを構築しました。
• Halはユーザーの役割に基づいて異なる出力を生成します。エンジニアにはプルリクエストを、営業担当者には説明文を提供します。
• 対談で引用された研究によると、AI採用率の高いチームはプルリクエストのマージ数が98%増加しましたが、レビュー時間は91%増加しました。
• 効果的なエージェントワークフローには、冗長または不正確な提案を防ぐために、歴史的な決定事項や過去の拒否理由を含む「権限マップ」へのアクセスが必要です。
• diffを可視化し、開発者に変更点についてクイズを出すツールは、誤解されたAI生成コードのマージリスクを軽減するのに役立ちます。

なぜ重要なのか

ソフトウェアエンジニアや技術リーダーにとって、このシフトはコーディングエージェントの熟練度がもはやプロンプトエンジニアリングだけではないことを示唆しています。ボトルネックはコードを書くことから、それをレビューし、エージェントが正しく動作するために必要なコンテキストを提供することに移動しました。カスタムエージェント環境や歴史知識ベースへの投資を怠るチームは、エージェントが確立されたアーキテクチャパターンと整合させるのに苦労するため、プルリクエストの頻繁な変更（churn）が増加し、レビューサイクルが長くなる可能性が高いでしょう。

マージ率の上昇にもかかわらずレビュー時間が増加することは、人間の監督が依然として重要であることを示唆しています。エンジニアは、AI生成の変更を効率的に監査するための新スキルを開発する必要があり、意図、エッジケース、歴史的整合性に焦点を当てる必要があります。これには、速度がシステムの安定性や保守性を損なわないように、コードレビューが表面的なチェックではなく、より深い調査プロセスになるような文化的な転換が必要です。

あなたができること

• 厳格な人間レビューを伴う実際のオープンソースプロジェクトや社内レガシーコードベースへの貢献を要求するタスクで、孤立したコーディング演習を置き換えてください。
• テストと障害調査のために本番環境を正確に再現できるエージェントワークスペースを構築または設定してください。
• マージ前に深い理解を確保するために、コードdiffを可視化し、開発者に変更点についてクイズを出すツールを実装してください。
• エージェントがアクセスできるように、過去のプルリクエストコメント、設計ドキュメント、拒否理由を索引付けして「権限マップ」を作成してください。
• エンジニアには実行可能なコードを、非技術系ステークホルダーには明確な説明を提供するなど、エージェントの出力を特定の役割に合わせて調整してください。
• AI支援ワークフローのボトルネックを特定するために、特にレビュー時間とマージ率を追跡しながら、プルリクエストメトリクスを注意深く監視してください。