軟體開發成本會歸零嗎? AI coding 衝擊 SaaS 的正反論點 PK
來源：https://blog.aihao.tw/draft/software-cost-zero-debate/ 日期：2026-07-08 媒體：愛好 AI 工程 Blog 狀態：頁面標示為草稿（Draft）
軟體開發成本會歸零嗎? AI coding 衝擊 SaaS 的正反論點 PK | 愛好 AI 工程 Blog
愛好 AI 工程 Blog
關於本站
訂閱電子報
草稿 Draft
軟體開發成本會歸零嗎? AI coding 衝擊 SaaS 的正反論點 PK
2026-07-08
Industry
Coding
「所有應用軟體的價值終將歸零。」Replit CEO Amjad Masad 這句話，是「AI 讓軟體開發成本趨近於零」這派說法最極端的版本。這個說法的影響力不用懷疑: 今年 2 月軟體類股幾週內蒸發近一兆美元市值，市場認真拿它定價了一輪。不過這篇想談的不是股價，而是它背後的軟體工程問題: 寫 code 的成本真的在趨近零，但「軟體開發」的成本會跟著歸零嗎?
小編找了兩篇立場鮮明又互補的深度分析當主軸:
Andreas Kirsch 的
The Flawed Ephemeral Software Hypothesis
: 從軟體工程的本質，駁斥「軟體會變成用完即丟」的預言
Nicolas Bustamante 的
10 Years Building Vertical Software
: 作者做過被 LLM 威脅的法律 SaaS (歐洲最大法律資訊平台 Doctrine)，現在做的 Fintool 是 Anthropic 投資的 AI 股票研究平台，直接跟 Bloomberg、FactSet 競爭。用他的話說:「我做過如今被 LLM 威脅的那種軟體，現在做的則是發動威脅的那種。」
加上小編搜集的更多正反方素材，整理成以下這場論點 PK。
正方陣容: 歸零派說了什麼
先把正方的說法完整擺出來，這些都不是隨便講講的人:
Amjad Masad (Replit CEO)
:
「所有應用軟體的價值終將歸零」
，2025 年在 YC AI Startup School 講的
Andrej Karpathy
: 在
2025 年終回顧
寫道，他為了在別的專案裡找一個 bug，直接 vibe code 出整個一次性 app，「程式碼突然變得免費、短暫、可塑、用一次就能丟」。他也
預測
App Store 會被即時生成的拋棄式軟體取代
Tomasz Tunguz
:
拋棄式 app 的數量會超過 SaaS 應用
，「也許是百萬比一」
Anish Acharya (a16z)
:
「軟體不再需要是永久的或實用的」
，做軟體的投資報酬率限制已經被解除，並投了 2,000 萬美元 pre-seed 給 Wabi 來證明這件事
Guillermo Rauch (Vercel CEO)
: 未來的 app 是
「按需生成，而不是下載安裝」
Satya Nadella (Microsoft CEO)
: 在 BG2 podcast 上說
「商業應用這個概念，大概會在 agent 時代整個瓦解」
: SaaS 本質上是 CRUD 資料庫加業務邏輯，而業務邏輯會移到 AI 這一層
正方的推論鏈很直觀: 既然生成軟體的成本趨近於零，維護軟體看起來就是浪費時間。何必 debug? 重新生成就好。何必重構? 重新描述需求就好。何必付 Bloomberg 每席一年 25,000 美元? 讓 agent 直接查資料就好。
資本的態度也很明確: Cursor 估值 293 億、Cognition 102 億、Lovable 66 億、Replit 30 億美元，
四家加起來近 500 億
。行為數據也在動: Claude Code 上線六個月
營收 run-rate 破 10 億美元
; 依
New Relic 2026 State of AI Coding 報告
彙整的業界基準，Google 宣稱自家 75% 的 code 由 AI 生成，GitHub Copilot 遙測顯示使用者平均 46%; 該報告自己的調查(200 位美國技術主管)更發現，三分之二的組織每週有 5175% 的 code 產出是 AI 生成或大幅重構的，62% 的團隊經常不逐行驗證就讓 AI code 上 production。寫 code 這件事，行為上已經大規模交給 AI 了。
反方陣容: 誰在反駁
反方這邊的名單同樣有份量:
Andreas Kirsch
: 本文主軸之一，機器學習研究員，論點詳見回合一、二、四
Nicolas Bustamante
: 另一位主軸，兩邊都做過的 vertical SaaS 創業者，詳見回合五
Benedict Evans
: 獨立科技分析師，
認為
AI 的結果會是「更多軟體」而不是沒有軟體，詳見回合一、六
Aaron Levie (Box CEO)
: 歸零論
最大聲的反對者
，主張 AI 對 SaaS 是利多不是威脅，詳見回合六
Ben Thompson (Stratechery)
: 認為軟體類股重新定價合理，但結論不是軟體之死:
「有些軟體也許會死，但不是全部，至少現在還不是」
Kent Beck、Martin Fowler、Grady Booch
: TDD、《重構》、UML 的作者們。三位在 2026 年都重度使用 coding agent，也都沒有買單歸零論，詳見下面的場邊觀察與回合四
Gartner
: 在股災隔週發出
反向意見
: Cowork 這類 plugin 衝擊的是任務層的知識工作，不會取代管理關鍵營運的 SaaS
Fred Brooks (1986)
: 反方還有一位不在場的成員，
《沒有銀彈》
的作者。他 40 年前就把軟體開發的困難分成「意外複雜度」和「本質複雜度」: 寫 code 的成本屬於前者，搞清楚系統該做什麼屬於後者，而後者沒有數量級的解法。這場辯論某種程度是這篇 1986 年論文的重演
加上回合三會出場的 New Relic、Entelligence 這些 2026 年的實測數據。前四個回合談軟體工程本身，後三個回合談它對 SaaS 的衝擊。
場邊觀察: 誰站在哪一邊，跟他的位置有關
把兩邊名單放在一起看，有個模式很難不注意到。正方的組成是: 平台 CEO(Replit、Vercel)、投資人(a16z、Tunguz)、AI 研究者(Karpathy)。他們的共同點是，多半不是每天對大型 production 系統負長期責任的人，而且不少人的生意直接受惠於「軟體是拋棄式」這個敘事。這點 Kirsch 在原文就自我提醒過: 如果一個人的生意靠 vibe coding 賺錢，把軟體說成拋棄式對他的經濟利益有利。這不代表論點是錯的，但值得多一分檢視。
科學家型的正方要另外分析: 他們沒有賣工具的動機，對模型能力的判斷通常也最準，問題出在經驗的結構。研究用的 code 本來就是拋棄式的: 跑完實驗、產出結果，code 就功成身退，沒有長期狀態、沒有向後相容、沒有使用者一致性期待、沒有 on-call。從這種成本結構外推到所有軟體，自然會低估「發現正確行為」那一段的成本。Karpathy 的原話其實把範圍限定在個人一次性小工具，這在他的使用情境裡完全成立，是後面的人把它放大成了產業預言。
反方的組成則偏向對長期執行的系統負責的人: 寫出 TDD、《重構》、UML 的 Beck、Fowler、Booch，做了十年 vertical 軟體的 Bustamante，以及調查對象是要輪值 on-call 的組織的那些數據報告。
不過公平起見，這個模式有反例，分界線也不是頭銜。反方也有 CEO: Levie 的 Box 靠 SaaS 活著，他的立場同樣有經濟動機; 反方主軸 Kirsch 自己就是機器學習研究員。更值得注意的是: 最重度使用 coding agent 的工程組織(包括 Anthropic 自己)也沒有宣稱成本歸零，他們照樣跑 PR、CI、code review。所以比較準確的分界線不是頭銜，而是:
真正對長期系統負責的人大量採用工具，但不買單歸零敘事; 歸零敘事主要來自賣工具的、投資工具的，和寫拋棄式 code 出身的人
。
回合一: 「寫 code 便宜了」不等於「軟體便宜了」
Kirsch 的第一個反擊，是指出正方的論證偷換了概念: 拿「code 生成變便宜」的證據，去支撐「軟體會變成拋棄式」的結論。仔細看那些證據: Cursor 的營收、YC 新創的 AI 生成比例、Claude Code 的營收，證明的都是「開發者在持久的工程流程裡，更快地生產 code」: PR、code review、CI、Git，一個都沒少。連 Anthropic 自己(發言人說 7090% 的 code 出自 Claude Code)也是在標準工程流程裡用它。「AI 生成的」不等於「拋棄式的」。
他的核心主張是: 軟體工程最難的部分從來不是寫 code，而是「發現正確的行為」(discovering correct behavior): 當軟體撞上真實世界，把邊界情況和營運上的模糊地帶一個一個解決掉。code 生成再快，這個發現過程的時間和成本都不會消失。他類比 Amdahl’s law: 平行化的加速上限，取決於那些無法平行化的部分; 同樣地，生產「可信軟體」的速度上限，取決於 AI 加速不了的部分。
Martin Fowler 在今年 2 月的
AI 工作坊筆記
把同一件事濃縮成一句話: AI 確實讓寫 code 變快了，「但寫 code 從來就不是瓶頸」，如果團隊本來就沒有健全的交付實務，這個速度倍增器只會變成「債務加速器」。
那個加速不了的部分就是驗證。這半年「驗證是新瓶頸」幾乎變成工程圈的共識，
TypeDB 這篇
講得最直白: 生成很便宜，可以交給 LLM 無限擴充; 驗證很昂貴，因為人類注意力稀缺、昂貴、又容易疲乏。如果 LLM 幫你省了十分鐘寫 code，卻讓你多花三十分鐘 debug 一個微妙的 runtime 錯誤，你根本沒省到時間。
Benedict Evans 在今年 3 月的
MAD podcast
把這件事講得更根本: 就算模型真的達到 AGI 等級，「你還是很難描述清楚你到底要什麼」。回頭看成功的軟體，使用者通常看不出問題在哪、也想不出每個畫面該發生什麼事。搞清楚問題、把需求定義明白，這件事從來就不在「生成」的範圍裡。
回合二: 「重新生成取代維護」撞上四道結構性障礙
正方最誘人的推論是: 既然重新生成近乎免費，維護就是浪費。Kirsch 列出四道不會因為工具進步而消失的結構性障礙:
- 邊界情況 。「測試抓得到你預期的，production 抓的是你沒預期的。」邊界情況來自真實使用者做出意料之外的事、第三方服務行為不一致、資料違反你不知道自己做過的假設，這些知識只能靠系統實際跑過才累積得出來。每次重新生成，都把這個時鐘歸零，而且新的實作還可能觸發全新的邊界情況。
- 狀態、資料與整合面 。vibe coding 在無狀態、資料模型簡單、整合面少的應用上最好用，但多數真實系統不是這樣。重新生成的 code 必須跟既有資料、API 的版本怪癖、模組間的隱性相依全部對上，最危險的是「幾乎正確」: 無聲的資料損毀比明顯的錯誤更貴。這也是 50 年軟體重寫史的教訓: Fred Brooks 1975 年說「計畫好丟掉第一版」，20 年後在《人月神話》紀念版裡承認這建議太簡化，改成「用成長的，不是用重建的」(grow, not build); Netscape 從頭重寫瀏覽器花了三年，把舊版早已解決的邊界情況重新遇了一遍，市占被 IE 拿走，公司再也沒有恢復。 Joel Spolsky 那句經典 :「當你把程式碼丟掉重來，你丟掉的是所有累積的知識、所有修好的 bug、好幾年的工程工作。」
- 介面穩定性 。任何被使用超過一次的軟體都會產生一致性期待。自然語言規格裡沒解決的模糊性，會在每次重新生成時變成行為差異: 使用者週一看到的表格排序，週二打開變了樣。這不需要系統多複雜就會發生。風險高的場景更嚴重: 醫療 EHR 系統改版造成的介面變動，已被列為用藥錯誤的促成因素。
- 模糊性與可稽核性 。「我們跑了這個 prompt」過不了 SOC2、HIPAA、財務稽核。更深的問題是自然語言天生模糊:「暫時性失敗要重試」，哪些算暫時? 重試幾次? 用什麼間隔? 行銷信件佇列可以容忍這種模糊，支付系統不行。要消除模糊，規格就得越來越形式化，而形式化的盡頭就是 code。這也是為什麼「編譯器讓組合語言變成拋棄式，LLM 也會讓 code 變成拋棄式」的類比不成立: 過去每一次抽象層轉移，都是從形式語言到另一個形式語言(組語到 C、C 到 Python、raw query 到 SQL)，語意明確、可機器驗證。把天生模糊的自然語言當成持久的規格層，是沒有歷史先例的事。 Kirsch 引了 Chesterton 的圍籬原則總結這一回合:「在搞清楚圍籬為什麼蓋起來之前，先別拆它。」對改動保守從來不是因為寫 code 貴，而是因為「發現正確行為」貴。生成便宜了，這四項成本一項都沒少。 回合三: 數據對決 (只看 2026 年的) 先說一個方法論警告: 評估 coding agent，2025 年的數據已經過時，因為工具能力進步太快。最著名的例子就是 METR 那個「開發者自認變快、實測反而慢 19%」的隨機對照實驗: METR 自己在 2026 年 2 月的更新 說明，用更新的工具重跑，原班底開發者的初步估計翻轉成快 18%，而且他們相信 2026 年初的真實加速還更大，只是現在連實驗都難做了: 開發者不願意為了實驗放棄 AI 工具。速度紅利是真的，這局正方先拿一分。 但反方要問的從來不是「有沒有變快」，而是「帳單移去哪了」。2026 年的結果數據: New Relic 2026 State of AI Coding 報告 (2026 年 6 月)抓到了整場辯論最核心的矛盾: 94% 的技術主管認為 AI 生成的 code 在 review 當下品質比人寫的高，但同一群人回報: 78% 說 production 事故變多了，86% 說資深工程師的重工時間增加了，74% 說至少四分之一的 AI code 需要大幅重做，82% 過去半年至少發生過一次和 AI code 直接相關的 production 事故。報告自己的總結:「AI 生成的 code 在 review 當下被評為品質更高，進了 production 卻產生可測量的更差結果。」 Entelligence 分析 2,444 個工程組織的 100 萬個以上 PR (2026 年 5 月): 12 週內 PR 量成長 2.6 倍，但被 revert 的 PR 成長 3.7 倍，失敗率成長得比產出還快; 48.5% 的 PR 在一小時內就被核准(實質上沒有 review); 每寫四行 code 就有一行活不過當週。他們的估算是每 1 元 AI 工具支出，有 0.82 元被事後的維護循環消耗掉 學術端也有了大規模研究: 一篇分析 6,299 個 GitHub repo、30 萬個 AI 產出 commit 的論文 (2026 年 3 月)發現，每一種 coding agent 都有超過 15% 的 commit 至少引入一個新問題，而且 22.7% 的問題一路存活到 repo 最新版本，變成長期維護成本; 另一篇 MSR 2026 的因果研究 發現，採用 coding agent 後靜態分析警告增加約 18%、認知複雜度增加約 39%，速度紅利會隨時間消退，複雜度成本卻持續累積 Glean 的 Work AI Index 調查了 6,000 名知識工作者 : 每週靠 AI 省下約 11 小時，卻多花 6.4 小時在照看 AI: 準備 context、檢查輸出、修它的錯; 41% 的人承認交出過自己無法完整解釋的 AI 產出 個案代表還是 Amazon: 2026 年頭幾個月 因為 AI 工具出了兩次大規模當機事故 ，3 月全站中斷六小時後， 內部強制要求資深工程師簽核初階員工的 AI 生成 code ，官方稱之為「受控的摩擦」(controlled friction) 另一篇 2026 年中的分析 把這個現象叫做「驗證護城河」: Copilot 授權一個月才幾美元，但中型團隊為了消化大幅增加的 PR 量，光是 CI/CD 基礎設施就要多花 5 到 15 萬美元。這回合的判定: 成本沒有消失，它從「寫 code」那一欄，移到了 CI、code review、驗證、事故處理這些欄位。這跟 blog 之前寫過的 AI 時代的 Code Review 瓶頸 是同一件事。 回合四: 那軟體工程會變成什麼樣? 可塑軟體與規格驅動開發 Kirsch 不是只有駁斥，他的正面主張叫「可塑軟體」(malleable software): code 仍然是權威來源，但 spec、測試、遷移計畫、事故報告這些工程產物會跟 code 一起持久保存，AI agent 讓修改它們的摩擦大幅下降。具體的工作流是: 永遠有一個穩定部署的基準線(code + 基礎設施 + schema + 介面); agent 持續累積 production 記憶(事故報告、log、部署結果); 每個變更請求一次更新多個持久產物: spec、code、測試、遷移計畫、runbook; 驗證同時跑合成測試和重播的 production trace; 部署結果再回饋到記憶層。 他用「幫支付系統加多幣別支援」做了一組對比，這段對工程師特別有感: 傳統團隊 : 花幾週寫設計文件、實作、測邊界情況(進位、匯率過期、混合幣別的部分退款)、feature flag 上線。慢，但知識累積在 code、測試、PR 討論裡 拋棄式團隊 : 用更新過的 prompt 重新生成整個支付模組，把 production trace 和歷史事故報告都放進 context。生成器正確保留了已知的 workaround，但新的幣別轉換 code 裡有一條進位路徑，跟既有的部分退款邏輯產生了歷史上從未出現過的組合。巴西使用者開始收到錯誤幣別的退款，幾天後才被發現: 失敗不在任何歷史 trace 裡，它來自新 code 撞上舊狀態 可塑團隊 : 用自然語言描述變更，agent 起草實作、更新 spec、生成遷移腳本; 部署前的 trace 分析標出已知風險，而團隊清楚知道這不可能抓到所有 bug，所以照樣走 feature flag + canary 漸進部署。第二天監控就在 canary 族群裡抓到同一種錯誤幣別退款，影響範圍只有一小群使用者。比不用 AI 快得多，但快的原因是持久產物加上增量上線，不是丟掉 code 工程實務上的工具也正往這個方向收斂: GitHub 的 Spec Kit、AWS 的 Kiro 這些「規格驅動開發」(spec-driven development)工具，做法都是先寫更完整的規格來約束 agent，生成的 code 仍然要被檢驗和測試。前面提過的 TypeDB 那篇主張也相同: 要讓驗證變便宜，就要把規格寫得更形式化，型別系統、design by contract、測試先行，都是讓機器幫人做驗證的手段。注意這個方向跟「拋棄式」正好相反: 所有人都在增加持久的工程產物，不是減少。 這也是幾位軟體工程老將在 2026 年的共同觀察。Kent Beck 在 Pragmatic Summit 與 Fowler 的對談 裡說，TDD 在 agent 時代比以往更重要: 你有一個威力強大的精靈(genie，他對 coding agent 的稱呼)，就必須有辦法驗證它做的事是對的; Fowler 那場工作坊的結論之一乾脆是「TDD 是最強形式的 prompt engineering」。Fowler 對「code 不重要了」的說法 也不買單 :「當我狀態最好的時候，code 清楚而精確地承載了我的意圖」，而用自然語言寫的 BDD 規格「冗長又模糊」。同一篇裡他引用 Chad Fowler 的架構視角:「問題不再是生產 code，而是安全地替換 code」，重新生成只有在「元件」這個粒度上可行，前提是清楚的資料所有權和可獨立驗證的介面。繞了一圈，又回到 Kirsch 的結論: 讓重新生成變得安全的，正是那些持久的架構產物。 回合五: SaaS 的十道護城河，五破五守 Kirsch 回答的是「軟體會不會變拋棄式」，Bustamante 回答的是投資人和創業者更關心的那題:「那 SaaS 公司會不會死?」他把垂直產業軟體(vertical SaaS，像金融的 Bloomberg、法律的 LexisNexis、醫療的 Epic)的競爭優勢拆成十道護城河(moat)，逐一檢查 LLM 對每一道做了什麼: 被攻破的五道 ▼
- 學來的介面 十年 Bloomberg 快捷鍵的肌肉記憶，被一個聊天框取代
- 客製工作流與業務邏輯 幾千行 if/then 的業務邏輯，變成一份 markdown skill 檔
- 公開資料的存取層 模型本身就是 parser，自建解析器的溢價消失
- 人才稀缺 領域專家不再需要工程師轉譯，直接把方法寫成 skill
- 綁售 (bundling) agent 本身就是 bundle，還會幫你挑最便宜的資料源 守住的五道 ▲
- 專有資料 (反而更強) 別人拿不到的資料，變成每個 agent 都需要的稀缺輸入
- 法規與合規鎖定 HIPAA 不在乎 LLM，Epic 的認證與 18 個月導入週期照舊
- 網路效應 交易對手都在 Bloomberg IB chat 上，你就得在
- 交易嵌入 在金流裡的軟體(支付、清算)，agent 架在上面而不是取代
- System of record (長期有變數)
目前安全，但 agent 的長期記憶正在累積成新的權威資料來源
✏️ 小編製圖，整理自 Bustamante 原文
關鍵在被攻破那五道的共同點: 它們都是「把競爭者擋在門外」的那種護城河。以前要跟 Bloomberg 競爭，你需要幾百個既懂金融又能寫 production code 的稀有工程師、幾年的開發時間、大筆資料授權費，所以每個垂直領域只有 2
3 家認真的玩家。現在一個小團隊配上 frontier model API 加領域知識，幾個月就能做出 80% 的功能、賣 20% 的價格。Bustamante 說得直接: 競爭者不是從 3 家變 4 家，是從 3 家變 300 家。摧毀定價能力的是這個，不是「軟體歸零」。 其中最值得 AI 工程師注意的是第二道: 業務邏輯的形態改變了。Fintool 的 DCF 估值功能不是幾千行 if/then，而是一份 markdown skill 檔: 教 agent 該抓哪些資料、怎麼按產業計算 WACC、怎麼跑敏感度分析。寫這份檔案花一週，更新只要幾分鐘，而且他們的客戶(基金經理人)自己就能寫。「幾年的工程 vs 一週的寫作，這就是這次的轉變。」 編按: 這跟上週整理的 如何萃取老師傅的知識做成 Agent Skill 是同一件事: 領域專家的方法論不再需要透過工程師轉譯成 code，可以直接寫成 skill。 但注意，Bustamante 的結論不是「SaaS 完蛋」。守住的五道反而可能更值錢: Bloomberg 的即時報價資料是每個 agent 都需要的稀缺輸入; S&P 的信用評等是受監管的專業意見，LLM 發不出來。他的判讀是: 市場在定價的是「溢價倍數的終結」，不是營收消失。文章最後一節的標題乾脆就叫「SaaS 沒有要死」，而且他認為現在「有點把嬰兒跟洗澡水一起倒掉了」。 他給所有 SaaS 公司的三個測試題: (1) 資料是專有的嗎? (2) 有法規鎖定嗎? (3) 嵌在交易流程裡嗎? 三題全「否」是高風險，一題「是」中風險，兩題以上大概沒事。 他也點出真正的威脅形狀: 不是 LLM 本身，而是「鉗形攻勢」: 下面有幾百家 AI 原生新創進場，上面則是水平平台第一次有能力做深垂直領域: Microsoft Copilot 在 Excel 裡直接做 DCF 模型; Anthropic 用 agent SDK + MCP + skills 這套組合從水平切進垂直，不需要領域工程師、不需要多年開發。「軟體正在變成 headless: 介面消失，一切流經 agent。重要的不再是軟體本身，而是誰擁有客戶關係，也就是誰擁有 agent。」 回合六: SaaS 這邊，反方連前提都不接受 Bustamante 至少同意「五道護城河被攻破」，但還有一批人連這個都要爭。 Box CEO Aaron Levie 是歸零論 最直接的反對者 ，他的論點正面回應了 Bustamante 的第十道護城河: agent 不會讓 system of record 貶值，反而更依賴它。agent 要能動工，得先知道能存取哪些資料、權限怎麼管、工作流怎麼定義、結果呈現給誰， 這些全是軟體問題 :「AI 對 SaaS 基本上是純利多，因為 agent 需要一個 system of record 才能在裡面運作。我預期我們的產品路線圖一年後會比一年前大兩到三倍，因為每個工程師都能多產出兩三倍的 code。」 有意思的是，Levie 完全接受正方對 coding 的判斷: 他自稱「百分之百看好 vibe coding」，也同意未來軟體會多一百倍。但 Box 還是不打算自建 CRM，因為相對於其他優先事項，ROI 不划算: 企業的工程資源有限，拿去重造市面上已經有幾千套的普通軟體，不如拿去做真正帶來營收的客製功能。他舉的例子:「福特的供應鏈 ERP 處理幾十億筆交易，那不是你能 vibe code 出來的東西。」 Benedict Evans 給了一個更完整的分類: 企業軟體有三塊: 大型 system of record(SAP、ERP 這類，「沒有人會 vibe code 自己的 ERP」)、垂直 SaaS，以及中間那塊「臨時軟體」: 以前用 Excel 加 email 加共享資料夾硬撐的流程。AI 真正擴張的是第三塊，而且會把以前根本做不成軟體的需求也變成軟體。SaaS 那一波讓美國大企業從幾十套軟體用到 400500 套，所以他對「AI 會對軟體做什麼」的回答是:「更多軟體，多非常多。」 Ben Thompson 的判定落在中間: 這波 重新定價完全合理 ，按席次計價的模式受壓、產業會整併、會裁員，「過去十年 SaaS 的故事是把餅做大，下一個十年是搶餅，而模型商就是軍火商」。但這是產業重組的劇本，不是歸零的劇本。 營運數據目前也站在「重組而非滅絕」這邊: 一篇彙整 指出，Atlassian 的付費席次持續穩定擴張，Jefferies 的通路調查找不到 AI 壓縮席次的證據，Gartner 的反向意見也是: Cowork 這類 plugin 衝擊的是任務層的知識工作，不是管理關鍵營運的系統。真正在發生的是「agent 卡進使用者與軟體之間」的中介化，不是軟體消失。 回合七: Klarna 把整個循環走完 理論吵不完，看一個把完整循環走完的真實案例。 編按: 這是 2024~2025 年的案例，當時的模型能力比現在弱不少，客服品質那部分放到今天未必一樣。但它展示的成本項目(資料、合規、制度記憶)是架構問題，不是模型能力問題，這是它到現在還值得回顧的原因。 2024 年 8 月 ，Klarna CEO Siemiatkowski 對分析師宣布 :「我們剛關掉 Salesforce，幾週內會關掉 Workday」，要靠 AI 整併大量 SaaS。他們的 AI 客服號稱頂替 700 名客服的工作量，處理時間從 11 分鐘降到 2 分鐘，一年省 4,000 萬美元。SaaS 末日論的完美範本。 2025 年 3 月 ，Siemiatkowski 出來澄清 :「不，我們沒有用 LLM 取代 SaaS。」實際做的是把散在各個 SaaS 裡的資料，整併到自建的內部技術架構(用了 Neo4j 圖資料庫)，再讓內部 AI 使用這些知識。他還補了一句「我不認為這是 Salesforce 的末日，可能恰恰相反」，並預測多數公司不會學 Klarna 自建，更可能的走向是 SaaS 市場整併。Salesforce CEO Benioff 當時的反問，正好就是反方的論點: 你的資料放在哪? 合規治理怎麼做? 公司的制度記憶在哪裡? 2025 年 5 月 ，Klarna 開始回聘人類客服 。CEO 承認過度自動化犧牲了服務品質:「從品牌的角度來看，讓客戶知道永遠找得到真人，是非常關鍵的。」 一個案例，兩邊各拿走一半: 正方拿到「大企業真的有動機、也真的有能力用 AI 取代部分 SaaS」; 反方拿到「資料、合規、營運、品質，這些成本一項都沒有消失，只是換了地方付」。 小編評判: 成本沒有歸零，而是移轉 先把整場 PK 的主要論點放進一張對照表: 議題 正方: 歸零派 反方: 移轉派 寫 code 的成本 生成的邊際成本趨近零，還會更便宜 同意，但寫 code 從來不是瓶頸，主要成本在「發現正確行為」(Brooks 的本質複雜度) 開發速度 10 倍生產力 加速是真的(連 METR 都翻轉了結論)，但帳單移到驗證、review、事故處理 維護 何必 debug? 重新生成就好 重新生成把 edge case 時鐘歸零; 50 年軟體重寫史沒有例外 規格 用自然語言描述需求就夠了 自然語言天生模糊，消除模糊的盡頭就是 code; 歷史上的抽象層轉移都是形式語言對形式語言 品質 94% 的技術主管在 review 當下認為 AI code 品質更高 同一群人回報 production 事故變多; 看起來乾淨不等於行為正確 工程實務 測試、review 這些舊紀律的重要性下降 紀律更重要:「TDD 是最強形式的 prompt engineering」(Fowler) 軟體型態 拋棄式: 按需生成、用完即丟 可塑式: code、spec、測試一起持久保存，修改摩擦大幅下降 軟體總量 即時生成取代持久軟體 更多軟體(Evans)，以及更多驗證、整合、營運工作 SaaS 價值 介面與工作流的溢價瓦解，價值歸零 溢價重新分配: 專有資料、法規、交易嵌入更值錢; agent 仍需要 system of record ✏️ 小編製表 小編的判定是:「軟體開發成本降到零」這個說法，把兩個不同的東西混在一起了:「程式碼生成的邊際成本」真的在趨近零，這是事實，而且還會更便宜; 但「軟體工程的總成本」沒有歸零，而是移轉了: 從「寫 code」移到驗證、整合、稽核、營運，以及對生成結果建立信任。 而第二項才是 SaaS 定價的基礎。你付給 Salesforce 或 Bloomberg 的錢，買的從來不只是那份 code: 是資料、是合規、是 SLA、是幾十年下來已經被解決掉的邊界情況。AI coding 讓「介面 + 工作流」這部分的溢價瓦解了，所以會重新定價、競爭者從 3 家變 300 家、汰弱留強，而擁有專有資料和法規地位的公司反而變強。這是價值的重新分配，不是歸零。 Kirsch 的一句話可以當這場 PK 的結語:「程式碼生成正在變得極度便宜，但軟體工程沒有。」對工程師來說，這句話還有另一面，跟之前寫過的 當寫 code 不再是瓶頸 收斂到同一個結論: 當寫 code 不再稀缺，價值就流向瓶頸移轉過去的地方: 驗證、整合、領域知識，和判斷力。 至於工程師該用什麼心情看這場辯論，Grady Booch 的版本也許最合適。他一邊說自己被 Claude 的能力「大為驚豔」，一邊在 Pragmatic Engineer 的訪談 裡主張: 軟體工程不是在消失，而是繼演算法、物件導向之後，正在進入以系統為核心的「第三個黃金年代」，系統思考、人類判斷、責任歸屬仍然是這門工程的核心。他給焦慮的開發者的建議只有兩句:「冷靜，深呼吸。」 © 2026 愛好資訊科技 關於本站 訂閱電子報 RSS