AI 會取代軟體工程師嗎？三大瓶頸與 WARN Act 裁員數據解讀

重點摘要

• 2025 年 3 月，紐約州在 WARN Act 裁員申報表單中首度加入 AI 勾選欄位，首年超過 160 家企業提交通報，無一勾選 AI 為裁員原因
• Arvind Narayanan 與 Sayash Kappor 的分析指出，AI 真正加速的只是「把程式碼輸入電腦」這個環節，而這從來不是軟體工程的主要瓶頸
• 決定要做什麼、驗證交付成果、以及對程式碼庫與業務的深層理解，是三個目前 AI 無法完整承擔的核心環節

2026 年 6 月 14 日，Arvind Narayanan 與 Sayash Kappor 發表一篇以軟體工程師為主角的分析，正面對抗「AI 能力一旦突破某個門檻，就會引發大規模裁員」的論述。論點的起點不是預測，而是現有的可驗證資料：即便在監管障礙最少、AI 工具滲透率最高的產業，目前的資料也無法支持「AI 正在造成大量失業」的說法。Simon Willison 的部落格同日引述了這篇分析，並補充了他自己作為工程師的實際觀察。

紐約 WARN Act 的資料說了什麼？

這個論點最具說服力的部分，來自一項很具體的政策觀察。2025 年 3 月，紐約州成為美國第一個在 WARN Act（企業裁員預告法）申報表單中加入「AI」勾選框的州，要求企業在申報大規模裁員時，說明是否與 AI 有關。整個首年，共有超過 160 家企業提交 WARN 通報，沒有任何一家勾選了那個 AI 欄位。

一個完整年度、超過 160 件、零次勾選。這個數字本身就是結論。當然，有人會說企業可能刻意迴避，或勾選標準不夠明確，但問題的核心在於：如果 AI 真的是裁員的主因，企業在法律文件上隱瞞的動機是什麼？紐約的資料至少提供了一個可觀察的基準，而這個基準目前沒有支持「AI 引發大規模失業」的說法。

Narayanan 與 Kappor 進一步指出，即便只考慮軟體業，這個產業幾乎是所有職業中最缺乏監管保護、AI 工具部署障礙最低的一類。如果連這裡都沒有出現明顯的就業崩潰，其他職業受到的衝擊理論上只會更小，軟體工程師的案例因此成為一個有效的壓力測試。

AI 真正加速了什麼？

把 AI 對軟體工程的影響說清楚，要先拆開「軟體工程」這個詞。

根據 Narayanan 與 Kappor 的分析，AI 工具確實大幅加速了一件事：「把程式碼輸入電腦」這個動作本身。自動補全、生成樣板程式碼、根據描述產生函式，這些是目前 AI 助理最擅長的場景，也是工程師在任務拆解調查中最常回報 AI 有幫助的地方。

但同樣的調查也揭示了另一件事：除了寫程式碼，工程師把大量時間花在開會與除錯上。這帶出一個問題：這些時間在做什麼，為什麼 AI 目前還沒自動化它們？

除錯不只是找語法錯誤。它要求工程師理解系統在什麼業務前提下被構建、做了哪些假設、哪個環節在什麼時間點出了問題。開會也不是在傳遞指令，而是釐清模糊需求、協調不同利益方對「完成」的定義。兩件事都牽涉到同一種東西：對上下文的深層掌握，而這恰好是三個核心瓶頸的共同根源。

三個核心瓶頸是什麼？

Narayanan 與 Kappor 在做過定性分析後，把軟體工程的核心瓶頸歸納為三件事。

第一是「決定要做什麼，並把它規格化」。一個功能需求背後，往往有十幾個隱含前提、幾種可能的詮釋方式、以及對下游系統的連鎖影響。把這些釐清成可執行的規格，本質上是一種跨領域翻譯：業務目標、技術限制、使用者行為之間的落差都要對齊。AI 目前能在這個環節提供輔助，但決定本身的責任仍在人身上。

第二是「驗證交付成果，並為它當責」。程式碼跑起來和程式碼做對了是兩回事。確認交付物真的符合原始意圖、在各種邊界條件下行為可預期、以及在出問題時有人能說清楚「為什麼」，目前 AI 無法完整承擔。「當責」要求行為者對業務與系統有足夠的理解，能在問題發生時快速定位根因，而不只是重新執行一次。

第三，也是他們認為最根本的，是「深層理解」：對程式碼庫的理解、對業務邏輯的理解、以及對整個開發環境的理解。這三種理解構成一個工程師在組織裡真正的不可替代性，不是因為他能寫出最快的程式碼，而是因為他知道這個系統在什麼前提下成立、哪裡有地雷、某個決策在多年前為什麼這樣做。

Simon Willison 在他的部落格中補充了一層個人觀察：他自己使用 AI 助理時，發現 AI 在「決定」與「驗證」兩個環節也能提供幫助，但「深層理解」仍是他提供價值的核心。他的說法是，給他再多 AI 工具，他所能產出的價值，仍然來自他對問題本身以及解法的理解深度。

對工程創業者的具體意涵

這個分析對 AI/Web3 領域的工程創業者有幾個直接的推論。

AI 確實壓縮了「寫程式碼」的單位時間成本，這意味著同樣規模的工程團隊，理論上能覆蓋更寬的功能範圍。但瓶頸從「能不能寫出來」移向「決定先做哪個」與「怎麼驗證做對了」，後兩件事更需要業務判斷，而不只是技術能力。從這個角度看，AI 工具的普及未必讓工程師更容易被取代，而是讓「決策品質」與「驗證能力」的重要性相對放大了。

深層理解目前也是 AI 最難複製的能力。一個工程師如果把所有判斷都外包給 AI，長期下來可能在「決定」與「驗證」兩個環節慢慢退化，反而讓自己變成更容易被替換的角色。用 AI 加速執行、但刻意保留對問題與系統的深度掌握，看起來是目前最合理的分工。

早期創業團隊的工程師通常同時扮演三個角色：決策者、驗證者、程式碼庫的首席理解者。這三個角色恰好是 Narayanan 與 Kappor 指出的三個瓶頸。AI 能幫你更快寫出原型，但它沒辦法替你判斷這個原型是否真的解決了使用者的問題，也沒辦法在產品方向轉彎時告訴你哪些技術債是地雷。

「AI 加速的只是打字那一段」，這句話既是對裁員恐慌的反駁，也是一個提醒：工程師的核心價值，從來都不在打字速度上。