Stanford CS146S 是什麼？

Stanford 的課程代碼是 CS146S，課名是 The Modern Software Developer，由 Mihail Eric 授課，是一門在 2025 年秋季首次開設的課程。想看課程的官方概覽和 syllabus 細節，可以直接到官方課程網站 https://themodernsoftware.dev。想看作業與配套材料，可以看 GitHub 上的 mihail911/modern-software-dev-assignments；其中 mihail911 就是 Mihail Eric，這個 repo 的描述是 “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”，homepage 也指向課程官網。簡單說，這門課不是泛泛地談 AI，而是在正式定義 Stanford 眼中的現代軟體開發者應該具備什麼能力。

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 在這件事上是對的。現代軟體開發者確實需要懂怎麼寫 prompt、怎麼和 agents 協作、怎麼串工具、怎麼檢查輸出結果，以及怎麼在 AI 進入工作循環之後把東西更快交出去。假裝這件事不存在，只是在落後市場。

問題從來都不是第一版

但我認為目前整個 AI-development 討論，仍然低估了真正的問題：AI coding 很少在第一版就失敗。

第一版反而是最簡單的部分。

登入畫面能用，dashboard 也渲染出來，CRUD flow 交付了，demo 甚至還會贏得掌聲。真正的麻煩，是從第四、第五、第六次變更開始。那時團隊需要替換 auth provider、換掉 analytics、拆解一個早期做錯的 styling 決策，或只是多加一個功能，卻不能順手把另外三個不相關的系統一起弄壞。

這時大多數 AI-generated codebase 才會暴露它真正的本質：生成很快，但修改很貴。

真正的失敗模式不是模型寫出胡話。真正的失敗模式是整個生成出來的系統邊界太弱，所以之後每一次變更都帶著看不見的影響範圍。

會用工具，不等於系統安全

一門課可以教 prompting、AI IDE 工作流、MCP、agent automation、Semgrep、Graphite、multi-stack generation。這些都重要。但沒有任何一項，能保證一個 codebase 在一個月持續迭代後仍然保持清醒。

一個團隊完全可以很會用 AI-native 工作流，卻仍然造出一個系統，讓：

  • screens 直接 import implementation details
  • 生成出來的 modules 把 vendor APIs 洩漏進 app code
  • optional services 被當成 hard dependencies 初始化
  • 第二次 LLM 審查被誤當成 verification
  • 每一次 refactor 都變成考古工作

所以我不認為 AI-native development 的決定性優勢，最後會只來自工具使用能力。

真正的優勢會來自一種可以撐過反覆變更的 architecture。

真正缺的主題是 replaceability

每一個 AI-generated subsystem，預設都應該被視為可替換的。

這代表 auth 要躲在 interface 後面，analytics 要躲在 interface 後面，storage 要躲在 interface 後面，styling 要躲在 contract 後面，dependency construction 要集中在一個 composition root，validation 要放在 system edges，deterministic checks 要在每次 commit 都跑。

如果一個壞掉的 module 可以在同一個 contract 後面被刪掉重寫，AI 的速度就會累積成真正的優勢。如果每個生成出來的部分都伸手碰其他部分，那麼不管 prompts 有多好，團隊最後都還是會慢下來。

這就是我希望更多 AI-development 討論能明講的主題。

真正的問題不只是「AI 能不能幫我們更快做出第一版？」

真正的問題是「等產品現實出現之後，我們能多便宜地替換掉原本做錯的版本？」

現代軟體開發者仍然需要 guardrails

現在很多 AI 建議，本質上仍然太依賴品味：

  • prompt 再寫好一點
  • 審查再仔細一點
  • 比較多個模型輸出
  • 給 agent 更多上下文
  • 再加一個 AI reviewer

這些做法有幫助。但它們不適合作為基礎。

人類審查本來就不穩定。模型審查更不穩定。我唯一相信能規模化的模式是：

  • 讓 AI 生成
  • 讓 deterministic rules 做 enforcement
  • 讓人來判斷 specification 和 tradeoffs

這也是為什麼我一直回到同一組東西：contracts、boundary rules、composition roots、contract tests，以及快速、不可協商的 checks。目標不是讓模型完美表現。目標是讓整個系統在結構上更難被破壞。

Stanford 是對的。但下一步更難。

CS146S 重要的地方，在於它把一個產業再也不能忽視的事實正式說了出來：AI-native development 現在已經是這門技藝的一部分。

但我不認為現代軟體開發者的定義，只是會用 AI tools。

下一個標準更難。

現代軟體開發者還需要知道，怎麼建出一個 codebase，讓 AI-generated parts 可以被約束、被驗證、被替換，而不必每次都把整個系統拖進一次 rewrite。

Stanford 正在教現代軟體開發者。

很好。

真正還缺的一門課，是那種架構紀律：它能讓 AI-native codebase 不會被自己的速度拖垮。