一、先把數字讀對：32％ 代表「曾經放棄一項採購」

這篇文章最重要的第一步，是先避免把一個很有訊號的數據寫成過度延伸的結論。

McKinsey 這次調查於 2026 年 5 月 4 日至 6 月 8 日進行，共有 1,719 名受訪者，來自 97 個國家，涵蓋不同產業、公司規模與職能；36％ 的受訪者來自年營收超過 US$1 billion 的組織，並依各國對全球 GDP 的貢獻進行加權。

其中，40％ 這個數字只適用於大型企業受訪者，定義為年營收超過 US$1 billion 的公司。McKinsey 指出，這些大型企業受訪者中，表示公司已在至少一個功能領域 Scale AI Agents 的比例，從前一年的 27％ 上升到 40％。較小型企業的相同比例則大致維持在 22％。

另外，McKinsey 表示，約兩成全體受訪者的公司已將 Software Coding Agents 推進到 Scale 階段；大型企業的比例則達 31％。這顯示 Coding Agent 已開始離開個人開發者的實驗環境，進入企業級部署。

最值得 SaaS 業者注意的是 32％。這些受訪者表示，公司至少曾有一次因為 Agentic Coding 能自行完成所需功能，而決定不購買某項軟體產品或功能。這裡描述的是「至少一次採購決策受到影響」，沒有證據支持「32％ 企業已經大幅削減所有 SaaS」。

可被確認的趨勢，是 Build vs. Buy 的邊界正在移動。企業第一次有更低成本的第三個選項：先讓 AI Coding 把功能做出來，再決定這個需求是否值得買成一套長期軟體。

二、為什麼這會碰到 SaaS 的 Seat Economics？

過去二十年的 SaaS 模式有一個非常強的經濟基礎。對多數企業而言，自己開發一套 CRM、專案管理、報表、表單、審批、客服或資料整理系統，通常需要產品規格、工程師、測試、部署、資安、維運與持續更新。即使某套 SaaS 只有 60％ 的功能真正被使用，直接購買依然經常比自己開發便宜。

Seat Based Pricing 因而合理。企業按使用者數量付費，軟體公司負責持續開發、維運、資安、功能更新與基礎設施。當公司新增 100 名使用者，SaaS 供應商可以增加 100 個 Seat 的收入，邊際交付成本卻通常不會等比例增加。這也是 SaaS 長期具備高毛利與可預測經常性收入的重要來源。

AI Coding 改變的是「內製軟體的起始成本」。當 Coding Agent 可以協助建立資料表、管理介面、API 串接、權限邏輯、通知流程、報表與測試時，過去必須投入數週甚至數月才能驗證的內部工具，有些需求現在可以更早得到可運作的原型。

這不會讓軟體開發變成免費。產品定義、資料模型、權限設計、整合、測試、維運、安全與責任仍然存在。改變最大的地方，是企業過去遇到一個需求時，很快就會進入「找 SaaS」；現在多了一個前置問題：「這個需求是否值得先內製一個 80 分版本？」

三、這不等於 SaaS 支出會縮水，可能是軟體預算重新分配

如果只看 McKinsey 的 32％，很容易得到一個過度簡化的敘事：企業開始自己寫軟體，所以 SaaS 市場要縮小。

目前可取得的市場數據沒有支持這個結論。Gartner 於 2026 年 7 月 27 日發布的全球 IT 支出預估顯示，2026 年全球軟體支出預計達 US$1.468 trillion，比 2025 年成長 15.5％。整體 IT 支出則預估成長 14.2％，達 US$6.369 trillion。

因此，目前更合理的解讀是企業軟體市場正在發生預算重配。部分低差異、低切換風險、功能相對單純的 SaaS 可能面臨更高的價格壓力；同時，AI 模型、Agent 平台、雲端算力、資料基礎設施、API、整合、資安與企業級治理仍會吸收新的預算。

Gartner 在 2026 年 7 月提出「Agentic Arbitrage」概念，指 AI Agents 可以跨越多個系統直接完成工作，使使用者不必逐一進入不同應用程式介面。Gartner 估計，到 2030 年，最多 US$234 billion 的企業應用軟體支出可能暴露於這種改變，約相當於企業應用 SaaS 支出的 20％。

四、Build vs. Buy 的門檻正在重新計算

企業長期都有 Build vs. Buy 的問題。AI Coding 的影響在於，Build 的第一階段成本下降了，原本沒有資格進入討論的需求，開始可以被拿來比較。

一個很典型的例子，是企業為了某個內部流程購買一套 SaaS。實際使用需求可能只有登入、填表、查詢、審核、通知、匯出與 Dashboard。若這套系統有 80 個 Seat，每個 Seat 都持續付費，但每天真正發生的核心交易只有少數幾種，管理者就會開始問：我們付費的單位究竟是「人數」，還是「完成這條流程」？

這時 Build vs. Buy 不能只比較訂閱費與開發費。企業應比較完整的 Total Cost of Ownership。

AI Coding 最容易壓低的是建置、修改、測試與部分整合成本。它沒有自動消除維運、資料責任、資安、法遵、可用性與人員接手問題。因此，看到 AI 能在一天內做出 Demo，不應直接推導為企業應把所有 SaaS 改成自建。

五、哪一類 SaaS 功能最先受到壓力？

從經濟結構判斷，最先受到影響的通常會是「功能可以清楚描述、流程不複雜、資料主要掌握在企業自己手上、出錯風險可控制」的工具。這類需求的內製成本下降最快。

• 內部表單、申請與審批流程。
• 簡單 CRM 延伸工具與內部查詢介面。
• 跨 Excel、Email、Google Workspace 或 Microsoft 365 的自動化。
• 特定部門使用的 Dashboard、報表與資料整理工具。
• 一次性或特定活動使用的後台、名單管理與通知系統。
• 既有核心系統外圍的小型 Workflow 與 Integration Layer。

這些場景的共同點，是企業實際需要的範圍往往只占完整產品的一部分。當 Coding Agent 可以快速建立這段功能，購買完整 SaaS Package 的必要性就會下降。

相對而言，涉及金流、薪資、會計核心帳務、身份驗證、醫療資料、法遵、高可用性、跨國稅務、複雜供應鏈或大量第三方整合的系統，企業仍有充分理由選擇成熟產品。這些軟體的價值主要來自可靠性、責任承擔、標準化、持續更新與制度性信任。

六、軟體公司的護城河，會從「功能很多」移向「企業離不開」

如果 AI Coding 讓複製一個功能變得更便宜，軟體公司的防禦力就不能只建立在 Feature List。

未來較強的軟體護城河，可能集中在六個方向。

1. System of Record：掌握企業長期、結構化且具有交易意義的核心資料。
2. Workflow Depth：深入企業日常營運，處理例外、權限、審核與跨角色協作。
3. Institutional Context：累積公司歷史、規則、客戶脈絡與決策背景，使 Agent 能更準確執行。
4. Trust and Governance：提供權限、Audit Log、安全、法遵、可追溯性與企業級 SLA。
5. Integration Network：與大量外部系統、資料源與合作夥伴建立穩定連接。
6. Outcome Ownership：從提供工具轉向直接改善轉換率、處理時間、錯誤率、營運成本或其他可衡量成果。

這也解釋 Gartner 為什麼把 Agentic AI 對 SaaS 的影響描述為定價與價值鏈的重組。當 Agent 可以直接執行工作，UI 的使用頻率可能降低。軟體供應商需要證明自己仍控制重要資料、工作流或交易，而不只提供另一個 Dashboard。

七、IT 採購會從「買多少 Seat」走向「哪一層能力值得外包」

企業採購部門過去經常以帳號數量、功能模組與授權範圍作為軟體談判基礎。Agentic AI 進來之後，採購問題會增加幾個新的維度。

• 這個功能一年實際被執行多少次？
• 需要多少人直接登入，多少工作可以由 Agent 完成？
• 供應商提供的是 UI、資料、流程引擎，還是可被 Agent 呼叫的 API？
• 如果企業自行做一個 80 分版本，三年成本與風險是多少？
• 如果供應商價格上升，企業是否具備 Exit Plan 與資料可攜性？
• 公司是否願意承擔自建後的維護、安全與營運責任？

這些問題會讓 IT 採購從產品比較，逐漸走向 Capability Sourcing。企業不再只決定「買哪一套軟體」，還要決定資料層、流程層、Agent 層、介面層與基礎設施分別由誰負責。

八、中小企業得到的新機會：先做「邊緣工具」，不要急著重做核心系統

這一波變化對中小企業的意義可能更直接。過去一間 20 人或 50 人的公司，很難為自己特定的營運流程開發專用軟體。需求太小，外包開發不一定划算，內部也缺乏完整工程團隊。

AI Coding 降低了這個門檻。企業可以先從一條範圍清楚的 Workflow 開始，例如：表單進件後自動整理資料、判斷條件、產生文件、寄送通知、更新 Sheet 或 CRM，最後建立追蹤 Dashboard。這些工作過去可能分散在 3 至 5 套工具裡，現在有機會用較小的客製層把它們串起來。

適合先做的原則，可以濃縮成四個條件：高頻、耗時、規則相對清楚、失敗風險可控制。若再加上現有 SaaS Seat 成本偏高或功能使用率偏低，Build 的經濟性就更值得評估。

九、AI Coding 降低開發成本，也會把維運責任送回企業

自建工具最容易被忽略的是第二年。第一版系統可以很快做出來，接著會遇到帳號離職、權限改變、API 版本更新、資料格式變更、套件漏洞、錯誤紀錄、備份、異常通知與需求追加。

企業如果把 Coding Agent 當成「更快的開發能力」，就需要同步建立最低限度的工程治理。至少要處理資料分類、最小權限、身分驗證、Secret 管理、傳輸與儲存加密、Dependency 更新、Log、Audit Trail、備份、保存期限、刪除機制與 Incident Response。

高風險動作則應設定 Human Review，例如付款、刪除資料、修改正式合約、發送大量外部訊息、變更客戶主檔或高權限帳號。Agent 能執行工作，不代表企業可以把責任一起交出去。

十、給管理者的結論：不要先問「SaaS 會不會死」，先重算軟體價值

McKinsey 的 32％ 是一個很重要的早期訊號。它表示 Agentic Coding 已經從「工程效率工具」跨進「企業採購決策」。當企業能更便宜地做出特定功能，軟體市場的比較基準就會改變。

但目前數據同時顯示，全球軟體支出仍在成長。這個產業短期內更可能發生的是預算結構重組、定價方式改變與軟體價值重新定位。

對 SaaS 公司而言，重要的是把價值從 Seat、Feature 與 UI 往資料、Workflow、Context、Governance 與 Outcome 推進。對企業而言，重要的是重新建立 Build vs. Buy 規則，把核心系統、可商品化能力、內部差異化流程與短期工具分開管理。

AI Coding 帶來的最大改變，可能不是「每家公司都變成軟體公司」。更具體的影響是，每家公司都開始有能力問一句以前成本太高而無法認真回答的問題：

這個功能，我們為什麼一定要買？

當這個問題進入每一次續約、增購、採購與流程改造會議，SaaS 的遊戲規則就已經開始改變。