2026年6月11日 星期四

Anthropic 執行長 Dario Amodei:AI 為何需要像飛機一樣被監管?

2026 年 6 月 10 日,Anthropic 執行長 Dario Amodei 發表新文章〈Policy on the AI Exponential〉,主張 AI 進步的速度遠遠超過政府立法的速度,並且提議該用管飛機的方式來管 AI。文章一開頭他借《魔戒》裡那棵走路、講話都很慢的樹人 Treebeard 來比喻政府在政策制定上的動作:AI 用四年從「連一行像樣的程式都寫不出來」,變成「在主要 AI 公司裡包辦了大部分的程式碼」,但國會要推動一條法案往往要好幾年。


但是,真正讓我想寫這篇文章的,是 Dario 整篇文章透出來的那種對於 AI 深信不已的信念。Dario 不是把 AI 當成又一個很強的軟體工具,他是真心相信 AI 會變成「a country of geniuses in a datacenter」(一整個資料中心的天才之國),在認知工作上全面超過人、變成人類腦力的通用替代品。他把 AI 拿來跟核武、工業革命並列,說它會重設整個地緣政治的棋盤。文章裡有一句:一個有強 AI 的國家對上沒有強 AI 的國家,差距就像是二戰的美國海軍陸戰隊對上一群拿劍的中世紀士兵。會這樣寫的人,心裡對 AI 的認定的絕對不只是「工具升級」,是典範轉移等級的改變。


我個人也覺得這個信念是真的,不是行銷話術。Dario 自己在文章裡反過來拒絕「AI 只是公關問題、需要更好的行銷」這種說法,他說大家會怕 AI 是因為風險真的存在。他舉的具體證據是 Anthropic 自家 Claude Mythos Preview 在資安攻防上展現的能力,他說這證明 AI 已經是「具有全球與國家戰略後果的工具」。一個會把自家模型的能力講成國安威脅、還主動要求政府應該有權擋下自家產品上市的人,我覺得是很難說他只是在演戲。


但是,到底會不會真的走到那一步,另一派有完全不同的看法。a16z 的合夥人 Martin Casado 長期的論點是:AI 的影響力大概就跟微晶片、跟網路同一個等級。很大、會改變很多產業,但它畢竟還是工具。他公開說自己不是 AGI 那一派的,覺得 AGI 這個詞反而讓討論失焦;他把現在的 AI 形容成「感覺像 1996 年」,意思是還在很早期、後面還有很長的路要走。他做了一個有趣的算數:AI 要競爭的對象其實是人腦,而人腦只用 15 瓦、又便宜又有效率。在這個計算框架下,AI 只是一個成本被壓得很低的工具,不是一個新的智慧生命。


這兩種看法差距非常明顯,而且現在還沒辦法判斷誰對。我自己比較靠近後面這種:AI 是我這些年看過最強的工具,但「工具」這兩個字我還是想留著。它跟網路、跟 iPhone 一樣,會重新分配誰有生產力、會長出新的公司和新的工作,可是它終究要有人去用、去指揮它做什麼。Dario 描繪的那個「比所有人都強、還會自己把自己愈做愈好」的版本,有沒有可能發生?有可能,我不敢說一定不會。但把「有可能」直接當成「已經是現狀」來規劃,跟 Casado 講的「先看清楚多出來的風險再動手」,中間的作法差很多。


不過講到要不要監管,我反而覺得不用先吵贏「AI 到底是天才之國還是高級工具」這一題。有意思的是,兩派講監管時抓的比喻其實是同一組。Dario 拿汽車、飛機、藥物來類比,說 AI 該像美國聯邦航空總署(FAA)管飛機那樣,超過一定運算規模的模型,上市前要先過第三方安全測試,政府有權擋下或召回不合格的模型。Casado 那一派則拿網路來類比,說當年網路出現新型威脅(像電腦蠕蟲)時,我們是看清楚「相對於既有系統多出來的那部分風險」才動手,主張用證據、不要用生存焦慮去立法。


可是網路這個比喻,其實同時也是支持監管的理由。網路一開始也被當成「只是一個很強的工具」,結果這二、三十年我們還是替它建了一大堆規矩:個資保護、網路犯罪、平台責任、反壟斷。社群平台的推薦演算法在過去十幾年對社會做了什麼,大家也都還記得。所以用「它只是個工具、跟網路一樣」這句話,並不會推導出「不用管」,反而正好說明我們最後一定會去管它,就像我們管每一個夠強的工具一樣。你不需要先相信 AI 會變成資料中心裡的天才之國,才會覺得這東西需要被治理;一個很強、很多人手上都有、又確實能造成真實傷害的工具(Dario 舉的那個資安能力已經是真的),這個理由就夠了。


真正要小心的不是「該不該管」,而是「誰來寫規則」。Dario 的提案一出來,Steven Sinofsky 這些人馬上點出 regulatory capture(監管俘獲)的疑慮:當被監管的公司自己跳出來設計監管,而且這套規則剛好對資本雄厚的大公司(Anthropic、Google、Microsoft)比較有利、對小新創比較難跨過門檻時,你就得多注意了。想要監管,跟想要好的監管,是兩件不同的事。


所以我讀完這篇的感想是,大家現在花很多力氣在吵 AI 到底是神還是烤麵包機,可能吵錯了方向。網路當年也「只是個工具」,我們照樣替它寫了幾十年的法規。AI 會不會強到取代人,這題可以慢慢辯論;但它需要被好好管理這件事,這應該是無庸置疑的。比起要多害怕它,我比較在意的是這支筆最後握在誰手上。


資料來源:

Dario Amodei〈Policy on the AI Exponential〉:https://darioamodei.com/post/policy-on-the-ai-exponential

a16z, Martin Casado〈The Economic Case for Generative AI and Foundation Models〉:https://a16z.com/the-economic-case-for-generative-ai-and-foundation-models/

The Generalist 對 Martin Casado 的訪談〈This feels like 1996〉:https://www.generalist.com/p/this-feels-like-1996-martin-casado

2026年5月29日 星期五

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


2026年5月28日 星期四

工程師還需要刷 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


2026年5月26日 星期二

軟體工程師不會被 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


2026年5月23日 星期六

微軟取消使用 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