Every AI 自動化案例：為什麼員工從 4 人增加到 30 人？

Every 是 Dan Shipper 自己創的媒體與軟體公司，從 2020 年起到現在 6 年多。他們從 GPT-3 那一刻就開始把 AI 塞進每個工作流程，包括寫稿、編輯、客服、設計、行銷、工程，Codex 跟 Claude Code 是預設的工作介面，新模型還沒對外公開他們就先拿到 alpha。理論上這是「自動化到極致」最徹底的活樣本。結果他在 2026-05-21 發了一份報告 After Automation，標題說的就是「我們什麼都自動化了，但人卻變多了」，從 GPT-3 時代的 4 人擴到現在 30 人。隔幾天他上 Lenny's Podcast，端出一組明顯逆主流的預測，這篇我想分享 3 個最有實質意義的。

第一個是反直覺事實本身。Dario Amodei 公開預測 AI 會在幾年內讓 50% 的入門級白領工作消失，Citadel 的 Ken Griffin 也說在看到「極高技能職位正被自動化」。Every 提出的數字卻站在相反方向。Dan 給的解釋走的是結構性論點，AI 訓練資料是「過去人類專家做出來、能被明文記下來的東西」，模型擅長壓縮並重現這些東西，但越擅長壓縮，默認輸出就越像，「跟其他人的 AI 輸出長一樣」這件事變成新常態。當默認品質爛大街，人對「不一樣」的需求暴增，而「不一樣」目前只能由人來判斷。瓶頸從生產位移到審查跟判斷。Apollo 首席經濟學家 Torsten Slok 最近也在追蹤同一個現象，他把這稱作勞動市場版的 Jevons Paradox：當一項服務成本下降，市場規模反而擴大，就業人口跟著增加，這是 19 世紀煤炭效率提升後的歷史模式。Every 把這個機制變成可觀察的內部數字，6 年從 4 人到 30 人，自動化程度跟人數一起上升。

第二個是 Forward Deployed Engineer (FDE) 這個職位的崛起，這跟第一個機制是同一件事的延伸。Google CEO Sundar Pichai、Box CEO Aaron Levie 最近都公開說 FDE 是 2026 最難招的職位。Lightcast 的職缺資料顯示 FDE 從 2024 年底約 200 個職缺到 2025 年底翻了 5 倍以上，TeamLease Digital 估全球 FDE 需求年增 800%。原因藏在 MIT NANDA 那份 2025 報告：95% 的企業 GenAI pilot 沒有可衡量的商業影響，問題出在部署層而不是模型本身。能寫一個會跑的 LLM API call 是一回事，能在客戶的 RBAC、合規、舊系統、髒資料、人為流程裡讓 agent 真正產生價值是另一回事，這需要一種混血工程師，既懂模型、又願意進客戶辦公室裡 debug 五個禮拜的整合問題。Palantir 在 2009 年就發明這種角色，後來 Q1 2026 法說會講出 85% 年增、商業營收 133% 年增的數字，市場才正視「派駐客戶現場部署模型」這件事能跑出多大規模。OpenAI 直接成立 Deployment Company 把 FDE 業務獨立出來，Google Cloud CEO Thomas Kurian 也宣布在 GTM 團隊裡新設 AI 專責 FDE 組織，面試流程從 4-6 輪壓到最少 2 輪。同一份 Lightcast 資料顯示 mid-level FDE 起薪 30 萬美金總包，senior 過 50 萬，FDE 已經是 AI 時代的 staff engineer 等級稀缺資源。

第三個是 SaaS 不死，這條反直覺得最徹底。主流敘事是 agent 會 bypass 所有 SaaS 介面直接 call API，所以 SaaS 公司會被取代。Dan 的看法相反，他直接說「我現在就會買 SaaS 股票」。Every 自己的 SaaS 開支是過去三年一路成長，而不是下降，原因是每個 agent 都是一個高頻 SaaS user。一個人類員工可能一天開幾次 Salesforce，但 agent 可以一秒打十次 API、一天填 200 個工單、自動產出帶完整 reproduction step 的 bug report。GitHub 2026 年因為 agent PR 暴增已經吃力到要重寫底層，這就是 SaaS 廠商現在最具體的訊號：誰能處理「人類跟 agent 同時用」的併發場景，誰就是接下來幾年的贏家。產品該往的方向是把 UI 分成「人類版」跟「agent 版」、加 rollback log、加 approval inbox、開 BYO token 讓使用者把自己的模型 token 帶進來，而不是貼一層 AI 還自己扛 token 成本。這個方向反而提升 SaaS 毛利，因為 AI 算力成本不在你家。

Dan 真正的論點是：AI 自動化把「執行」變便宜，但同時把「判斷」「框問題」「在組織裡讓模型真的有用」這三件事的價值推高。Every 那 30 人裡頭多出來的位置是寫手、編輯、FDE、盯著 agent 輸出做判斷的人，不是行政、不是 PM 堆疊。他在 podcast 裡有句話我覺得是這集最重要的：「Data is the visible residue of competence。」模型學的是過去專家留下的痕跡，等模型學會的時候，活著的專家早就走到下一個地方了。這個結構不會在某個版本停下來，就算到了 AGI 階段也一樣，只要模型訓練的是過去，現在的判斷力就有人類的位置。

Dan 跟 Lenny 約好一年後回節目對答案。一年前他預測 Claude Code 對非工程師會起飛、被很多人當熱話，後來 Anthropic 推 Cowork、OpenAI 推 Codex Desktop 印證了他的判斷。這次他的預測範圍更大，涵蓋 SaaS 不死、CLI 過時、Codex 是新 OS、FDE 是新核心工程角色、自動化越多人越多。我不知道一年後對得起幾條，但這幾條都值得放進今年自己的工作判斷裡。如果你在組織裡能扮演 framer、能把模型輸出變成有人會買的東西、能在客戶現場讓 AI 真的跑起來，今年到明年你的價值將會非常高。

來源：

- Dan Shipper, After Automation (Every, 2026-05-21): https://every.to/p/after-automation

- Lenny's Podcast: The AI paradox - More automation, more humans, more work | Dan Shipper (2026-05-24): https://www.lennysnewsletter.com/p/the-ai-paradox-dan-shipper

- MarkTechPost: What is a Forward Deployed Engineer (2026-05-20): https://www.marktechpost.com/2026/05/20/what-is-a-forward-deployed-engineer-the-ai-role-openai-anthropic-and-google-are-hiring-in-2026/

- The Pragmatic Engineer: Forward deployed engineering heats up again (2026-05-24): https://blog.pragmaticengineer.com/the-pulse-forward-deployed-engineering-heats-up-again/

- Yahoo Finance: AI Automation Creates More Expert Work Not Less (2026-05-23): https://ca.finance.yahoo.com/news/ai-automation-creates-more-expert-215306141.html

- The Times: The 19th-century paradox that gives hope for jobs in AI (2026-05-25): https://www.thetimes.com/business/economics/article/jevons-paradox-jobs-ai-s59fsndxt

工程師還需要刷 LeetCode 嗎？Sierra 新面試流程引發討論

Sierra 4 月公開他們把白板題、演算法題、原本的 coding 電話面談 全砍的細節，換上的東西更值得關注。

Bret Taylor（OpenAI 董事會主席、前 Salesforce co-CEO、Google Maps 共同創造者）跟 Clay Bavor 2023 創辦的 Sierra，4/22 在官方 blog 發了一篇 "The AI-native interview"。他們原本的工程師面試是 2 場 coding、1 場 algorithms、1 場 system design、1 場 culture，五輪標準大廠流程。他們把前三場合併成一場 onsite，分三個階段：Plan、Build、Review。

Plan 階段是面試官跟候選人坐在一起，由候選人主導、定義一個要做的產品。面試官的角色是一直追問把想法問清楚，題目限定在候選人自己的領域 — 這樣才看得到產品思維。Build 階段面試官離開，候選人單獨 2 小時，用任何 AI 工具、任何 框架把這個產品做出來，明確被告知「可以中途 pivot、可以砍功能」。Review 階段面試官回來，候選人 demo，討論 product flow、code review 看 data model 跟 abstraction 的取捨、討論到產品還缺什麼，並且明確問「你怎麼用 AI 的」。

這個流程改變的不是面試題目，是面試在測的東西。以前測的是「能不能把腦中的演算法翻譯成程式語言」、「記不記得二元樹怎麼寫」 — 而這兩件事 AI 現在做得比任何人都快。Sierra 在 blog 裡說：當寫 code 的瓶頸被 AI 解決，工程師的價值來自「結合技術能力、產品思維、商業 context」。換句話說，定義要做什麼、做取捨、跟客戶迭代到能交付影響 — 這些事 AI 還做不了，所以面試就改測這些。

另外兩個改動我覺得也值得單獨講。原本的 coding 電話面談 是「不能用 AI、線上 editor 寫 code」，他們把這場直接砍，換成系統設計。Sierra 自己的解釋是：「vibe-coding an app is easy. The harder, more relevant problem is getting it into production in a scalable way.」這句話比新流程本身還有意義 — 他們承認單純會 vibe-coding 已經沒有分辨力，能不能上線到正式環境才是真難題。

第二個改動是 debugging interview pilot。AI-native onsite 測的是 0→1 的能力（從零做出一個產品），但工程師日常做更多的是 1→N（在既有的、有點亂的 codebase 上加功能）。他們現在試一個新關卡：給候選人一個中型 codebase + 一個同事提交的 draft PR，要候選人 pull 下來、跑起來、用 coding agent 迭代把它改好。能不能在雜亂的代碼裡找到方向、能不能跟 AI 工具配合修出可合併的東西 — 這個能力在大型專案裡其實比寫新功能還重要。

最讓我多想一會的不是流程本身，是 Sierra 在文章裡講的這句：「Our debriefs have shifted from 'should we hire this person?' to 'where would this person thrive, and how do we support them?'」面試結束後的討論從「錄不錄取」變成「他會在哪裡發揮、需要什麼支援」。這對應的是 hiring philosophy 的轉變 — 從「找完人沒有明顯短板」變成「找出每個人的 spike 跟 gap」。當每個工程師可以靠 AI 補上自己不擅長的部分，組織就不再需要「全能型」的人，反而是「有強烈 spike」的人更值得簽下來。

對求職者意義很直接。如果你還在練習刷 LeetCode，你訓練的能力 AI 已經比你做得好。值得花時間練的是：在白紙前主導一個產品討論、在 2 小時內取捨什麼該做什麼該砍、做完能辯護為什麼這樣設計、能說清楚自己怎麼用 AI 配合做出來。這些事在 Sierra 面試裡會被直接看到，在其他公司也會越來越會被看到。

Sierra 自己承認新流程不完美 — 沒有標準產出的格式很難標準化。他們用與結果無關的評價標準 + 雙人面試彼此參照結果解決。其他公司要不要複製、用什麼方式對應標準化成本，很困難。但「測 AI 做不了的事」這個方向，是目前看到最有意義的動作。

---

來源：

- The AI-native interview, Sierra blog (2026-04-22): https://sierra.ai/blog/the-ai-native-interview

- Sierra AI Just Reinvented the Software Engineering Interview, Quasa (2026-04-28): https://quasa.io/media/sierra-ai-just-reinvented-the-software-engineering-interview-and-it-s-brilliant

- Working at Sierra in 2026, JobsByCulture (2026-05-20): https://jobsbyculture.com/blog/working-at-sierra-2026

- Hiring engineers in the age of AI, DEV Community (2026-05-24): https://dev.to/b0gy/hiring-engineers-in-the-age-of-ai-4peg

「中國工程師才是真工程師」：Palmer Luckey 真正想說的是什麼？

Palmer Luckey 在胡佛研究所那句「中國工程師才是真工程師」，真正該注意的是後面那段論述。

5 月 7 日錄製、5 月 20 日上線的 Uncommon Knowledge，Anduril 創辦人 Palmer Luckey 跟主持人 Peter Robinson 聊了 53 分鐘，標題下得很聳動，但他真正的論點不是中美對立，而是一條清楚的因果關係：當你長期只做高層次的設計、把實作丟給別人去做，最後連設計能力本身也會跟著流失。

Luckey 自己講的原文是這樣：「我們已經不教工程師怎麼做工程了。我們在教他們當 high-level 設計公司，把設計結果丟給中國真正的工程師，由他們去搞定怎麼真的做出來。」他講的不是製造線上的鎖螺絲，是電子工程師、機械工程師越來越只會挑零件、擺一個 nominal layout，但「我這條生產線要怎麼建？這塊板子要改幾版才能過 EMI 認證？」這些事都不再做。久了之後，原本的「設計」也只剩下挑選別人做過的元件。他舉的例子是 Apple — 以前 Apple 真的會自己想怎麼把東西做出來，現在大多數真正困難的工作是中國工程師完成的。

這個因果關係在硬體業講了好幾年，但讓我在意的是它跟 AI 寫 code 的對應關係。當工程師越來越只負責「描述意圖、收 PR、看結果」，把規格落實成可運作 code 的部分交給 AI，這跟美國電子業把製造交給深圳基本上是同一個劇本。短期來看你速度更快，長期來看你會逐漸失去判斷力 — 不知道某個架構決定為什麼會在實作層撞牆，不知道某個 API 設計為什麼會讓三個月後的擴展變痛苦。Apple 把製造交給富士康沒有立刻變笨，是花了 15 年才被人指出來「他們已經不會自己想怎麼做了」。軟體工程的版本，可能會比 15 年快。

Luckey 的另一個論點我覺得更值得細看。他說，創新跟製造是不能切開的：「你以為可以保留創新能力，把實作外包出去，但長期下來，創新能力會跟著實作能力一起流失。」這在企業組織裡也成立。太多公司把核心系統「外包給顧問團隊」「外包給乙方」，理由是「我們專注在 product / business，技術交給專業的」。三年後想要把系統收回來自己做的時候，發現公司裡已經沒有人懂這個系統了，連改一個欄位都得回頭找原本的外包商。Luckey 講的是國家層級的版本，但邏輯是一樣的。

Anduril 自己的反例就是 Arsenal-1。他們在俄亥俄 Pickaway County 蓋的 5 百萬平方英尺工廠，3 月開始量產 FURY 自主戰鬥機，目標是用汽車業的量產工具做武器，年產數萬台自主載具。重點不是「自製多炫」，是他們明確選擇把「怎麼真的做出來」這件事留在公司內部 — 用自己的錢、用自己的工程師、用自己的產線。Luckey 在訪談裡講為什麼這樣做：「如果我們連自己 Pentagon 用最多的筆電都是聯想做的，那我們已經不在跟中國競爭的軌道上了。」

Anduril 在台灣的動作可以這樣看。2025 年 8 月 Luckey 來台大演講、設立辦公室、跟中山科學研究院簽 MOU，跟中光電等 ODM 開始合作。他在那場演講講的話跟胡佛訪談是同一條邏輯：「製造手機、相機、筆電的技能，跟製造大規模自主彈藥、無人機、感測器需要的技能驚人地相似。」台灣的 ODM 體系是少數還同時保有「會設計也會做」的雙重能力的地方 — 從筆電、手機、伺服器到光學模組，這套能力是真的還能整套運作。Luckey 不是因為地緣親近選台灣，是因為這個能力在全世界已經很罕見。

回到工程師個人。如果你接受 Luckey 的論述（製造跟創新不能分），那 AI 寫 code 的時代有一件事值得想：把產出交給 AI 沒問題，但把判斷也一起交出去就不行。判斷力來自親自做過、踩過坑、看過真實環境怎麼出問題。當你願意親自寫一段、親自 debug 一次、親自把一個系統從零搭起來，這些經驗會回到你做設計、做 review、做架構決策的能力上。把這件事完全外包給 AI，省下的時間是真的，消失的判斷力也是真的。

---

來源：

- Palmer Luckey on Uncommon Knowledge, Hoover Institution (2026-05-20): https://www.hoover.org/research/palmer-luckey-wants-america-win

- 訪談影片: https://www.youtube.com/watch?v=--Ef5Q-3Iq8

- 狐說八道中文整理: https://www.anduril.tw/real-engineers/

- Anduril Industries Business Breakdown, Contrary Research (2026-04-28): https://research.contrary.com/report/anduril

- Palmer Luckey 台灣大學演講全文 (2025-08-04): https://www.anduril.tw/palmer-luckey-ntu/

- 美國國防新創 Anduril 來台設辦事處, 數位時代 (2025-08-04): https://www.bnext.com.tw/article/84085/anduril-palmer-luckey-speech

軟體工程師不會被 AI 取代，但是角色和能力正在改變

這幾年 AI agent 把寫 code 這件事從工程師的核心動作，變成可以指派出去的步驟。寫 code 不會消失，但它從工程師最大的時間花費，退到日常輸入的一部分。當這件事發生，工程師的價值點會跟著移位。我想從技術、角色、context engineering、能力四個面向，講這個位移是怎麼發生的。

過去幾十年我們評斷一段 code 寫得好不好看三件事：效率、正確性、可讀性。這三件事的隱含主詞都是人，跑這段 code 的機器要快、邏輯要對、未來接手的同事要看得懂，團隊協作的成本決定了這些判準。但現在最先接手這段 code 的對象經常是 AI。它要讀懂你寫了什麼、知道你想做什麼、然後往下延伸或重寫。code 的好壞因此多了一條判準：你給 AI 的東西能不能讓它正確接手。

這條判準的重點落在 code 之外的那份文件。spec-driven 開發在這裡變得關鍵。一份寫得清楚、把意圖、邊界、預期行為講明白的規格，能讓 AI 產出對的程式碼。一份模糊的、靠團隊默契填空的規格，AI 接到只會猜，然後猜錯。過去工程師「會寫」這份文件是加分項，現在是必要條件。

連帶地，工程師個人的能力核心也在移動。過去比的是「你 coding 寫得多快、多好」，未來比的是「你能不能設計一套 agent harness 來指揮 AI 做事」。這裡講的是 builder 級的設計能力。Builder 級要面對的是：怎麼切任務讓 AI 不會搞混、怎麼設停損避免它跑偏、怎麼讓多個 AI agent 平行做事還能合得起來、怎麼把錯誤回饋餵回去讓下一輪做得更好。這套設計能力過去不存在，現在是工程師能不能拉開差距的關鍵。

角色端的變化則要看你原本走哪條路。技術型工程師那條路最大的特色是系統架構能力，這件事沒變。怎麼把一個複雜系統拆成可以維護、可以擴張、可以容錯的模塊，怎麼選資料庫、怎麼設計 API 邊界、怎麼讓服務之間溝通乾淨，這些事 AI 還做不到。它可以幫你實作其中某個組件，但不會替你決定整個系統長怎樣。技術型工程師的價值在這層判斷上，這條路在 AI 時代沒有變窄。

PM 型工程師那條路變化比較大。過去這個角色的位置是需求的聆聽者，聽客戶或產品 PM 講想要什麼，翻成技術可行的方案，再找方法去執行。重點在聽、翻譯、執行。未來這個角色要變成需求的討論者。客戶說的「需求」往往只是他自己對解法的猜測，工程師要從中還原他真正的「意圖」，也就是他想解的問題是什麼、為什麼這對他重要、不解會怎樣。理解了意圖之後，重點是找 solution（解決方案），也就是真正解掉客戶問題的路徑；method（執行方法）只是達成 solution 過程中的選項之一。這個位置實質上就是 Forward Deployed Engineer（FDE），帶著 AI 工具到客戶現場，邊問邊做邊調整，幫客戶把意圖落地。

除了 spec-driven 跟 agent harness，還有一層新的工程設計面向冒出來，叫 context engineering 架構。過去做軟體系統，我們設計的是資料怎麼流、服務怎麼切、狀態怎麼存。AI 進來之後，系統裡多了一個會「思考」但需要被餵 context 才能做對事的角色。問題是 context 從哪裡來？怎麼確保使用者在過程中產生的脈絡，他剛剛做了什麼、為什麼這樣做、他現在卡在哪，被正確保留下來，等到 AI 要做事的時候能讀懂？

這層架構過去不存在。它要決定的是：系統在哪些點記錄使用者的動機、在哪些點記錄他的決策、這些訊號怎麼儲存、AI 需要時怎麼撈出來。設計得好，AI 能聰明地接續使用者的脈絡，知道他真正想完成的事，給出對的回應。設計不好，AI 每次都從零開始猜，輸出讀得通但對不上使用者真正要的東西。

這件事跟 prompt engineering 不是同一層。Prompt engineering 是當下這次互動怎麼跟模型講話，context engineering 是整個系統怎麼把使用者的歷程留下來讓 AI 在任何時刻都能讀懂。

最後是能力面。這層其實在前面三件事裡已經出現過，但值得單獨拉出來講。

第一個是理解跟溝通能力被同時放大兩次。你要對人聽懂他真正想做什麼，這部分過去就重要，未來更重要，因為 AI 把翻譯成 code 的部分接走了，前面這段「聽懂並還原意圖」變成更核心的動作。你還要對機器，用 spec、prompt、context 把這個意圖翻成 AI 能正確執行的指令。兩端都得要強，才能讓需求真正被落地。

第二個是 AI 邊界的識別能力。AI 在它熟悉的範圍裡可以快速試很多方案，可以把可讀性、效能、邊界情況都顧到。但它無法替你判斷哪些事它做得到、哪些事它在編造你看不出來的東西。能準確說「這個交給 AI 做、這個千萬不能讓 AI 做」的工程師，產出品質會跟「丟給 AI 看結果如何」的工程師差非常多。

這兩件事過去都算 senior 工程師的隱性差異，現在是所有層級都要面對的明確分水嶺。

把這四件事擺在一起，方向就清楚了。技術評斷在變，角色職責在變，多了一層 context engineering 的設計面向，能力的比重也在重新分配。四件事都圍繞同一條軸線：能不能定義對的問題、能不能給 AI 對的 context、能不能判斷 AI 的邊界。寫 code 這件事還在，工程師也還在。只是工程師價值的中心，從產出 code 移到了這條軸線上。

AI 會取代軟體工程師嗎？最新數據顯示職缺反而增加

David Sacks 說當 AI 將寫程式變的成本異常便宜，工程師職缺反而變多了。從數據來看，的確他是對的，但只講了一半。

事情是這樣。前白宮 AI 與加密貨幣事務主管 David Sacks 上週日在 X 上發了一篇文，問了一個看起來反直覺的問題：AI coding agent 已經能自己開發功能、開 PR、跨專案 debug 了，為什麼軟體工程師的職缺不減反增？他自己給的答案是「AI 大幅降低了寫程式的成本，同時也造成現在要管理的程式碼比以往任何時候都還要多」，還引了一個數字，GitHub 上的 commit 年增 14 倍。這篇被 Hugging Face 執行長 Clément Delangue 轉發，被到處廣傳。

先說我認同的部分。Sacks 講的其實是經濟學上的 Jevons 悖論：當一個東西的使用效率變高、成本變低，總用量通常不會下降，反而會上升。1865 年 Jevons 觀察到蒸汽機燒煤效率變好之後，整個社會的煤消耗量不減反增，因為便宜讓更多原本不划算的用途變得划算。套到軟體上就是，寫一個功能從兩週變成三天，公司不會說「太好了，可以裁掉八成工程師」，而是把那些一直擱著、以前不值得做的東西全部撈出來做。

數字確實撐得起這個說法。GitHub 的 commit 從 2025 全年約 10 億，到 2026 預估會衝到 140 億，每週 2.75 億筆，這就是 Sacks 講的 14 倍。AI 開的 PR 半年內從每月 400 萬暴增到 1700 萬。美國勞工統計局（BLS）預估軟體開發者職位 2024 到 2034 會成長 15%，遠高於全職業平均的 3%，而且報告裡直接點名 AI 是需求推力。今年初軟體工程師的職缺也確實年增約 11%。所以「AI 讓程式碼總量爆炸、進而推升工程師需求」這個方向，是有實際數據支撐的，不只是猜測，也不只是口號。

問題在「工程師職缺變多」這句話，把一件真正需要注意的事情掩蓋掉了：增加的職缺，到底是哪一種工程師？

把同一批資料拆開看，會發現成長幾乎全部集中在資深和 AI 專長這一類需求。

入門職缺從 2022 的高點減少了大約 67%。史丹佛 AI Index 2026 的數字更直接，22 到 25 歲的軟體開發者就業人數，從 ChatGPT 出現後掉了將近 20%，而資深開發者的人數持續成長，衝擊完全集中在最資淺這一層。新鮮人現在只佔大型科技公司新進人數的 7%。換個角度看職缺結構，入門職缺佔比從 8.1% 滑到 7.4%，資深職缺佔比則從 38.8% 爬到 43.1%。一般軟體工程師的職缺量比 2020 年的基準還低了快一半，真正在成長的是 AI/ML 工程師，年增 59% 到 85%。所以總量是成長的，但工程師人力需求底部在減少、頂部在增長。

再來是第三件事，也是我覺得最該想清楚的：Sacks 拿來解釋職缺成長的那個機制，「要管理的程式碼變多了」，剛好就是把剛入門這條路堵死的同一股力量。當每個人都用 AI 一天產出三倍的程式碼，瓶頸就從「寫」搬到了「審查、整合、確認這東西在正式環境會不會出問題」。而審查和架構判斷是資深工作。AI 接手的那些寫 template 程式碼、修小 bug、補測試的工作，正好都是過去新人用來練功、慢慢變成資深的那條路。GitClear 的資料也顯示，AI 產生的程式碼每個 PR 平均有 10.83 個問題，人寫的是 6.45 個，寫出來的量更大，要人檢查的地方也變得更多。

這就帶出一個五到七年後可能會浮現的問題。資深工程師都是先做過資淺的活才變資深的。如果現在這條入門的路被 AI 大幅壓縮，等到要補這些資深人力缺口的時候，能夠往上補的人，已經因為這幾年入門被收窄而變少了。需求在增長，但能滿足需求的供給，不一定跟得上。

所以 Sacks 沒講錯，AI 確實在把整個軟體業的餅做大。我只是覺得，當一個說法讓人鬆一口氣的時候，特別值得看它把什麼東西藏在底下。對已經在業界、能用 AI 把自己變成三倍產出的人，這是最好的時代；對剛畢業、還在找第一份工作的人，同一份數據就變成另一個故事。而這兩件事是同時都成立的。

來源：

David Sacks 原始論點與 14 倍 commit 數據：https://www.benzinga.com/markets/tech/26/05/52765410/former-wh-advisor-pushes-back-on-job-loss-fears-says-ai-has-dramatically-lowered-the-cost-of-writing-co

GitHub commit／AI PR 量與 GitClear 品質數據：https://byteiota.com/github-ai-agents-275m-commits-are-breaking-the-platform/

軟體開發者就業預估 +15%：美國勞工統計局 BLS Occupational Outlook https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

22–25 歲開發者就業 -20%：史丹佛 HAI AI Index 2026 https://hai.stanford.edu/ai-index

職缺結構（入門 8.1%→7.4%、資深 38.8%→43.1%、IT/CS 年增 14.2%）：ZipRecruiter 資料（WSJ 報導），轉引自 https://www.metaintro.com/blog/tech-jobs-rebound-2026-it-cs-postings-up-entry-level-shrinks

入門職缺 -67%、新鮮人佔比、一般 SWE 與 AI/ML 職缺消長：jobsbyculture 2026 職缺分析 https://jobsbyculture.com/blog/junior-developer-crisis-2026

微軟取消使用 Claude Code

微軟給員工試用 Claude Code 六個月，經過這段時間後，工程師大多選了 Claude Code；但是，微軟卻決定把它砍了。大多數報導抓的角度是公司政治和商業套利，但我認為這則消息最重要的訊號不是那裡，而是在成本。

真正的重點是 token 計費的成本已經讓公司撐不住。Hedgie（@HedgieMarkets）點出微軟砍掉 Claude Code 的原因是 token-based billing 讓成本變得無法承受——連一家擁有近乎無限雲端資源的公司都撐不住。而且這不是個案。Uber CTO Praveen Neppalli Naga 證實，Uber 在四個月內就燒光了整個 2026 年的 AI 預算，原因正是 Claude Code 的採用率從 32% 一路衝到 84%（一個 5,000 名工程師的組織），每名工程師每月 API 成本落在 500 到 2,000 美元之間，Uber 自己的說法是「回到白板重新規劃」。

所以可以清楚看見：工具越好用、採用率就會衝得越快，但是 token 帳單也會衝得越快。微軟和 Uber 是同一個現象的兩個資料點，agentic coding 的「按 token 計費」模式正在撞上企業預算的天花板。

回到事件本身。2026-05-14，The Verge 的 Tom Warren 獨家報導: 微軟 Experiences + Devices 部門副總 Rajesh Jha 發了一封內部 memo，「6/30 前將砍掉大部分 Claude Code 授權，全員改用自家 GitHub Copilot CLI」。E+D 這個部門負責的是 Windows、M365、Outlook、Teams、Surface 這些產品線，影響幾千名員工。脈絡要回到 2025-12：當時微軟針對 E+D 部門同時開放 Claude Code 跟 Copilot CLI 讓員工試用，Jha memo 自己說目的是「在真正的工程流程裡 benchmark 兩個工具，搞清楚哪個比較適合我們的團隊」。六個月後結果出來，The Verge、Windows Central、TechRadar、The Decoder 各家報導跟 Tom Warren 的內部來源都指向同一件事，員工大多偏好 Claude Code 勝過 Copilot CLI。

官方說法是要統一使用的工具鏈，「我們對自家工具才可以有完整控制，可以直接跟 GitHub 一起調整成符合微軟自己的 repo、流程、安全要求」。這個說法成立，但放回成本這條主線會看得更深。微軟改用自家 Copilot CLI 不只是品牌一致性——掌握 harness 就是掌握 token 燒錢的速度。Claude Code 是 Anthropic 控制的產品，token 怎麼燒、燒多少，微軟管不到；換成自家 harness，微軟才能優化 token 用量、把成本壓回可控範圍，而且後端模型仍然可以選 Claude。

不過，對 Anthropic 其實沒差。被砍掉的是按 token 計費的產品/訂閱層，也就是成本撐不住的那一層。模型 API 那層沒變：員工換到 Copilot CLI 之後仍然可以選 Claude 當後端模型，M365 裡的 Claude 整合照常運作，2025-11 簽的 Foundry deal 也照常。成本問題是產品層的問題，不是模型層的問題，這正是它對 Anthropic 沒差的原因。被換掉的是 Anthropic 的產品介面，不是模型本身。

這跟「Anthropic 被微軟切割」是兩件事。媒體標題很容易寫成 Anthropic 被微軟踢出去，但實際發生的事情是微軟挑了 Claude 模型仍然要繼續用、但 Anthropic 的產品介面換成自家的。這個區分對理解模型廠跟平台廠的關係很重要：模型可以是商品，產品介面才是平台廠想自己掌握的層。

對企業 AI 工具規劃，這件事蠻值得注意的：當你內部最受歡迎的 AI 工具是按 token 計費，「好用」和「養得起」是兩件事。微軟和 Uber 已經先撞上這道牆，每名工程師每月燒掉上千美元 token 的成本壓力遲早會得被處理。現在用得開心的工具，明年的預算還養不養得起是另一回事。

來源：

- Hedgie（@HedgieMarkets）: https://x.com/HedgieMarkets/status/2057531661785628841

- Uber 四個月燒光 2026 AI 預算 — Briefs: https://www.briefs.co/news/uber-torches-entire-2026-ai-budget-on-claude-code-in-four-months/

- Tom Warren X scoop: https://x.com/tomwarren/status/2055000505923871219

- Microsoft cancels Claude Code licenses — Windows Central: https://www.windowscentral.com/microsoft/microsoft-cancels-claude-code-licenses-shifting-developers-to-github-copilot-cli-a-move-likely-driven-by-financial-motives

- Microsoft pulls Claude Code licenses — The Decoder: https://the-decoder.com/microsoft-pulls-claude-code-licenses-and-pushes-developers-back-toward-its-own-ai-tool/

- Microsoft Resells Anthropic's Tech at a 65% Premium. It Just Canceled the Free Version — Major Matters: https://majormatters.co/p/microsoft-claude-code-walkback-cowork-resale

- Microsoft may discontinue Claude Code internally — TechRadar: https://www.techradar.com/pro/microsoft-may-discontinue-claude-code-internally-as-it-looks-to-push-users-towards-github-copilot

Google I/O 2026

2026/5/19 Google I/O 2026 盛大登場，從我的角度來看，這次 Google I/O 2026 的真正主角不是 Gemini Omni 那段影片，是 Antigravity 2.0 完全取代 Gemini CLI

每年 I/O 結束我都會問一個問題：這場 keynote 之後，開發者明天的工作流程會不會變。今年 5/19 ~ 5/20 在 Shoreline Amphitheatre 那場，答案是會，而且變動的幅度比過去幾年都大。

大多數人很容易被 Gemini Omni 那段影片生成 demo 搶走目光。Demis Hassabis 把它定位成「從任何輸入創建任何內容」，單一架構原生處理 video、audio、image、text，跨模態 reasoning 之後產出單一輸出。可以用對話編輯影片，角色、物理性質、先前的編輯在多輪對話中保持一致；對重力、流體、運動的理解明顯改善；使用者可以建自己的 avatar 拍片，建立時要錄一段念數字以防 deepfake。首發 Omni Flash 一次最多生 10 秒影片，每個輸出內嵌 SynthID 浮水印加 C2PA Content Credentials，從 Gemini app、YouTube Shorts、AI 創作工作室 Flow 進入。

這段 demo 適合上新聞，但對大多數工程師的日常沒有直接影響。會改變開發者明天工作流程的另一條線，是 Google Antigravity 2.0。

Antigravity 過去是附在 IDE 內的 agent 插件。這次升級成獨立 desktop app 加完整生態系，分成四塊：Antigravity Desktop 是圍繞 agent orchestration 設計的獨立 app，不是傳統 IDE；Antigravity CLI 完全取代 Gemini CLI，原本的 Agent Skills、Hooks、Subagents 都保留，Extensions 改名 Antigravity plugins；Antigravity SDK 開放程式化存取，跑的是 Google 內部產品用的同一套 agent harness；Managed Agents 透過 Gemini API 與 AI Studio 提供，跑在 Google 託管的環境上。Enterprise 那條線整合進 Gemini Enterprise Agent Platform。

技術層面看，新工具支援動態 subagents 平行 workflow、scheduled tasks 背景自動化、多輪 session 狀態保存、原生語音指令。

產品層面看，Google 公開選擇跟進 Claude 和 Codex：未來開發者跟 LLM 互動的單位從「我問一句、它答一句」改成 agent harness 跑一段，把多個子任務分派下去，自己處理中間的失敗、重試、狀態。

而這次，底層模型也跟著換。新發表的 Gemini 3.5 Flash 是「最新模型家族第一款，結合 frontier intelligence 與 action」，主打便宜加為 agent workflow 設計，成本大約是同等前沿模型的 1/2 到 1/3。這個價格是 Antigravity 2.0 能跑得起來的前提，agent 工作流的特性是會反覆呼叫模型，模型成本不壓下來，整個 platform 就只能服務小眾。

還有幾個比較不顯眼的工具也一起發布。Code Mender 是自動找漏洞並修補的安全工具，目前邀請外部專家測試中。Google AI Studio 加上原生 Android 支援、Workspace 整合、行動 app。Gemini API 新增 Interactions API。這幾個消息放在一起，隱約可以看到 Google 在補的是「從模型到生產系統」中間的那一段，也就是測試、安全、整合、行動端。這段過去是 Vercel、LangChain、Cursor 這些公司在做的事，Google 現在自己來。

消費者端的更新則有自己的節奏。Gemini Spark 是一般用途 AI agent，定位 24/7 personal agent，「在你指示下執行動作」。Daily Brief 是 Gemini app 每日簡報。Universal Cart 是跨網站智能購物車，agentic commerce 的基礎建設。搜尋結果加入 Search Information Agents 主動整理。Android XR 智慧眼鏡確定秋季正式推出，具備導航、訊息、拍照、Gemini live demo。Android Halo 把 agent 智能整合進狀態欄。Google Pics 是 Google Workspace 的新設計工具。SynthID 加 C2PA 的 AI 生成內容識別則擴展到更多場景，確保內容的安全。

訂閱方案部分則多了一階。新增 Google AI Ultra 月費 $100 USD，給 dev、creator、power user。

把這些放在一起看，2026 的 Google I/O 跟 2025 之前最大的差別是產品定位。過去 Google 講 AI，講的是 Gemini 變強了，更好的 benchmark、更長的 context window、更多模態。今年講的則是 AI agent，是在你指示下執行動作，是跑一段、做完一件事、回報結果。從 Omni 的多模態原生產出，到 3.5 Flash 為 agent workflow 設計的成本結構，到 Antigravity 2.0 全棧取代 Gemini CLI，到 Spark、Universal Cart、智慧眼鏡這些消費者入口，整套東西指向同一個產品形態。

來源：

- Google I/O 2026 官方 collection: https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-collection/

- I/O 2026 developer highlights: https://developers.googleblog.com/all-the-news-from-the-google-io-2026-developer-keynote/

- Gemini Omni 詳細介紹: https://techcrunch.com/2026/05/19/googles-gemini-omni-turns-images-audio-and-text-into-video-and-thats-just-the-start/

- Antigravity 2.0 詳細介紹: https://www.marktechpost.com/2026/05/19/google-launches-antigravity-2-0-at-i-o-2026-a-standalone-agent-first-platform-with-cli-sdk-managed-execution-and-enterprise-support/