Stanford CS146S とは何か

Stanford CS146S は、正式には CS146S: The Modern Software Developer という授業です。担当は Mihail Eric で、2025年秋に初めて開講されたコースです。授業の公式な概要や syllabus の確認には themodernsoftware.dev がもっとも確実で、課題は mihail911/modern-software-dev-assignments に公開されています。公式サイトは授業全体の overview と syllabus details を確認する場所として役立ち、GitHub リポジトリは実際の assignments を見るための一次情報です。

Stanford は本当に起きている変化を制度化している

Stanford に今、CS146S: The Modern Software Developer という授業がある。それ自体がかなり大きなシグナルです。

長い間、AI coding をおもちゃや近道、あるいは「本物のエンジニアリング」の上に載った薄い生産性レイヤーとして扱うのが、いわば無難な立場でした。しかし、この見方はすでに急速に古くなっています。

公開されている授業説明や課題の流れを見ると、CS146S は prompting、Cursor と Warp のワークフロー、MCP servers、autonomous coding agents、security scanning、AI code review、multi-stack app generation を扱っています。これは物珍しさだけを売りにしたセミナーではありません。ソフトウェア開発そのものが、モデルを前提に再編されていることを Stanford が認めたということです。

この点で Stanford は正しいと思います。現代のソフトウェア開発者は、どう prompt するか、どう agents と協働するか、どうツールをつなぐか、どう出力を検査するか、そして AI をループに入れたままどう速く出荷するかを理解する必要があります。そうではないふりをしても、市場に遅れるだけです。

問題は最初の version ではなかった

ただ、いまの AI development の議論がまだ十分に捉えていない点があります。AI coding は version one ではめったに失敗しません。

Version one はむしろ簡単です。

login screen は動く。dashboard も描画される。CRUD flow も出荷できる。demo は拍手を受ける。問題が始まるのは、四回目、五回目、六回目の変更あたりです。チームが auth provider を差し替え、analytics を置き換え、初期の styling decision をほどき、ある feature を追加しながら無関係な三つのシステムを壊さずに済ませなければならなくなるときです。

その時、ほとんどの AI-generated codebases は自分の正体を見せます。作るのは速いが、変えるのは高くつくのです。

中核の失敗モードは、モデルがでたらめを書くことではありません。中核の失敗モードは、生成されたシステムの boundaries が弱く、あらゆる後続変更が見えない blast radius を抱えることです。

ツールに慣れていても、構造的に安全とは限らない

授業は prompting、AI IDE のワークフロー、MCP、agent automation、Semgrep、Graphite、multi-stack generation を教えられます。どれも重要です。けれど、それだけで一か月後の codebase がまだ健全だとは保証されません。

チームが AI-native なワークフローにかなり習熟していても、次のような system は普通にできてしまいます。

  • screens が implementation details を直接 import する
  • generated modules が vendor APIs を app code に leak する
  • optional services が hard dependencies のように初期化される
  • 二回目の LLM review が verification として扱われる
  • あらゆる refactor が archaeological work になる

だから私は、AI-native development の決定的な優位は、ツール利用だけからは生まれないと思っています。

それは、繰り返しの変更に耐える architecture から生まれます。

足りない subject は replaceability だ

すべての AI-generated subsystem は、default で replaceable とみなされるべきです。

つまり、auth は interface の後ろに置く。analytics も interface の後ろに置く。storage も interface の後ろに置く。styling は contract の後ろに置く。dependency construction はひとつの composition root に集める。validation は system edges で行う。deterministic checks は every commit で走らせる。

悪い module を同じ contract の後ろで delete して re-implement できるなら、AI の speed は compound します。生成された各 part が他の part すべてに手を伸ばすなら、prompts がどれだけ良くてもチームは最終的に遅くなります。

これこそ、もっと多くの AI development の会話で明示されるべき主題です。

重要な問いは、ただ「AI は first version を速く出荷するのに役立つか」ではありません。

本当に重要なのは、「product reality がやってきたとき、間違った version をどれだけ安く置き換えられるか」です。

現代のソフトウェア開発者にも guardrails は必要だ

いまの AI についての助言の多くは、まだ taste に寄りすぎています。

  • もっと良く prompt する
  • もっと丁寧に review する
  • 複数の model outputs を比較する
  • agent にもっと文脈を渡す
  • さらに別の AI reviewer を足す

これらは役に立ちます。ですが、土台にはなりません。

人間の review は一貫しません。モデルの review はさらに一貫しません。規模化できる形で私が信頼する唯一のパターンは次のものです。

  • AI に generate させる
  • deterministic rules に enforce させる
  • 人間に specification と tradeoffs を判断させる

だから私はいつも同じものに戻ってきます。contracts、boundary rules、composition roots、contract tests、そして高速で譲れない checks です。目標は model を完璧に振る舞わせることではありません。目標は system を構造的に壊しにくくすることです。

Stanford は正しい。次の step はもっと難しい。

CS146S が重要なのは、業界がもう無視できない事実を formalize しているからです。AI-native development は、すでにこの仕事の一部になっています。

しかし、現代のソフトウェア開発者が AI tools への習熟だけで定義されるとは思いません。

次の基準は、もっと高いです。

現代のソフトウェア開発者は、AI-generated parts を constrain し、verify し、replace できる codebase を、システム全体を rewrite に引きずり込まずにどう作るかも知らなければなりません。

Stanford は現代のソフトウェア開発者を教えています。

それは良いことです。

足りない授業は、AI-native codebase が自分自身の速度で崩れないようにするアーキテクチャ規律です。