Anthropic 的 8 倍 code 產出，後面真正的問題是組織吃不吃得下

Lenny's Podcast 這次訪談 Fiona Fung，我覺得最有用的地方，不是又多一個「AI 讓工程師更有效率」的案例，而是她把 AI 原生工程團隊的管理問題講得很具體。

Fiona 現在在 Anthropic 帶 Claude Code 和 Claude Cowork 相關團隊。訪談一開始提到一個很令人印象深刻的數字，Anthropic 工程師平均每季產出的 code，大約是 2021 到 2025 年期間的 8 倍。這個數字很容易被拿來當生產力指標，但如果只停在這裡，反而會錯過比較重要的部分。

當 coding 本身不再是最稀缺的環節，瓶頸會移到別的地方。

以前工程組織最常卡在寫 code 的人力不夠。需求排隊、spec 排隊、review 排隊、測試排隊，最後大家都會說工程 bandwidth 不夠。AI coding agent 進來以後，寫 code 這件事的成本大幅度降低，很多原本不值得做的小改動、實驗、內部工具、修 bug，突然都變得可以做。但這不代表組織自動變快。新的瓶頸會出現在 review、驗證、產品判斷、品質定義、跨團隊同步，以及 manager 是否真的看得懂現在正在發生什麼。

Fiona 講到她自己的管理方式時，這點很明顯。她不是只把 Claude Code 當成更好的工具。她會讓 Claude Code 開 remote session，跨 repo、Slack channel、metrics 去整理某個人的關注的領域、最近作出的的產品、收到的反饋、使用者反應、市場 impact，然後用這些資料來做 1on1 面談前的準備。

這個用法對我來說很有啟發。AI 在這裡已經不只是單純代寫 PR，而是讓 manager 比較有機會追上團隊實際工作的速度。當一個團隊裡很多人同時用 agent 做事，傳統靠週會、狀態更新、少數幾個 dashboard 來掌握進度，很快就會不夠用。管理者需要新的觀測機制，不只是系統觀測機制，而是工作觀測機制。

她也提到 routine 的用法。以前早上可能是看幾個 feedback channel、喝咖啡、整理今天要看的東西。現在 routine 可以先幫她整理 feedback、找出需要注意的地方，有時甚至先產出 PR 讓她 review。這代表很多管理工作會從「我親自收集資訊」變成「我設計好問題，讓 agent 先幫我收斂資訊，再由我判斷」。

這件事延伸到 code review 也一樣。

Claude Code Reviews 是 Anthropic 內部後來才多出來的能力，因為當 code 產出大幅增加，人類 reviewer 會變成瓶頸。Fiona 的說法不是讓 AI 全面取代 review，而是把 review 分層。某些重複性、規格型、可驗證的部分，可以交給 AI 先做。某些需要深度 domain knowledge 思考、判斷的地方，仍然要靠人。

這裡的重點不是「AI review 準不準」這麼簡單，而是團隊能不能把好品質寫清楚。她提到，如果 repo 裡有清楚的 spec、framework、標準，Claude 就比較能判斷什麼是好的結果。換句話說，文件、測試、架構原則，不再只是給新人看的 onboarding 材料，也會變成 agent 工作時的重要上下文。而這會改變很多工程實務的價值排序。

以前大家都知道 TDD 好，但很多團隊做不起來，因為寫測試的成本太高，時間壓力一來就先犧牲。當 Claude 可以先幫你寫測試，再用測試帶出實作，TDD 的實務門檻就低很多。這不是因為大家突然更有紀律，而是因為原本最痛的成本被降低了。

招募的部分也很值得分享。

Fiona 講到她現在會看兩種人。一種是很有 product sense 的 builder，能自己想出方向、做出東西、反覆調整，並且對最後的產品體驗負責。另一種是很深的系統專家，能處理模型、架構、效能、安全、複雜平台這些難題。

這跟過去很多公司只用職能切分人才很不一樣。AI 讓更多人可以跨到原本不熟的工作區域，PM 可以更像 builder，designer 可以更接近 prototype，engineer 也必須更懂產品。可是深度專業沒有消失。越是關鍵的底層問題，越需要真正知道細節的人做驗證。

她用的原則是 trust but verify。我覺得這句話很適合描述現在的工程管理。你必須信任 AI 讓更多事情開始動起來，但你不能把判斷責任外包出去。越是用得重，越需要清楚知道哪些地方可以自動化，哪些地方一定要人做最後判斷。

訪談裡另一個我覺得實用的分享，是她談 metrics 的態度。

8 倍的代碼產出聽起來很強，但她也很清楚說，程式碼數量不是完美指標。有些工作本來就會產生大量 code，例如 library migration 或 framework 變更。有些高價值工作反而不會留下很多 code。PR 停留時間也一樣有用，但仍然不完整。

所以她更在意的是指標有沒有服務當下的問題。當團隊開始用 AI 以後，指標也要跟著調整，否則很容易只看到大家在做甚麼，卻看不到真正的進展。

她提到一個品質框架，我覺得非常適合拿回團隊內部討論。Anthropic 會區分 bad experience 和 sad experience。

Bad experience 是很嚴重、不可接受、可能讓使用者失去工作成果的問題，例如 CLI crash 或資料遺失。Sad experience 則是可恢復，但體驗很差的問題，例如畫面閃爍、等待太久、流程卡住。這種分類讓品質討論不只是看 bug 數，而是回到使用者到底遇到什麼狀況，以及哪些問題不應該被當成一般 bug 排隊處理。

我喜歡這個框架，因為它把品質從抽象的 dashboard 拉回產品體驗。AI coding agent 會讓改動速度變快，如果沒有一套共同的品質語言，團隊很容易在更高速度下累積更多使用者不舒服的細節。

這次訪談裡也有一個比較少被討論，但我覺得很重要的面向，就是 AI 原生工作方式的副作用。

Fiona 說，當大家越來越常跟 agent 一起工作，工程工作可能會變得更孤單。Claude Code 團隊後來甚至開始安排 pair-wise programming lunch，讓大家分享自己怎麼用 Claude Code 和 Cowork。這不是為了形式上的 team building，而是因為每個人跟 agent 協作的方式差異很大，這些 tacit knowledge 如果不被交換，很難自然擴散。

另一個副作用是 context switching。當你可以同時讓很多 agent 在背景工作，表面上產能提高了，但你也會得到更多待 review、待確認、待接續的工作。你要記得每個 agent 在做什麼、卡在哪裡、哪個結果可信、哪個需要重來。這會把人的工作從 單純執行變成指揮協作，但指揮協作本身也會變成新的負擔。

所以我不覺得 AI 原生工程團隊只是「大家都買 coding agent 帳號」這麼簡單。

真正要改的是整個工作系統。你需要更清楚的 spec，讓 agent 有足夠上下文。你需要更好的測試，讓產出的 code 可以被快速驗證。你需要新的 review 分層，避免人類 reviewer 被大量 PR 淹沒。你需要新的管理機制，讓管理者能看見更快流動的工作。你也需要新的團隊儀式，讓人和人之間的學習不要被人和 agent 的互動取代。

Fiona 最後談到她最擔心的不是某個產品或工程挑戰，而是文化能不能在快速擴張時維持。這點我覺得很真實。AI 會把很多個人的執行能力放大，但組織能不能承接這些能力，靠的還是共同標準、互相信任、願意爭論、願意在快到終點時回頭看誰需要支援。

很多公司接下來都會說自己是 AI-first 或 AI-native。這些口號不難講，工具也不難買。比較難的是回答幾個更具體的問題。

• 我們的 spec 是否清楚到 agent 可以使用？
• 我們的測試是否足夠快，能支撐更高頻率的改動？
• 我們的 review 流程是否知道哪些交給 AI，哪些必須由人判斷？
• 我們的 manager 是否看得見 agent 協作後的真實工作狀態？
• 我們的團隊是否還有足夠的共同學習，而不是每個人各自和自己的 agent 工作？

這才是我覺得 Fiona 這次訪談最值得帶走的重點。AI 讓寫 code 變得便宜，接下來稀缺的會是判斷、驗證、品質語言、組織節奏，以及文化本身。

工具會讓個人更強，但最後能不能變成團隊能力，還是要看組織怎麼設計工作。

來源：Lenny's Podcast, “Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)”, YouTube, https://www.youtube.com/watch?v=Ybrl4FYM57c 。Lenny’s Newsletter episode page and transcript, https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering 。Anthropic 官方 X 貼文提到工程師每季平均產出約 8 倍 code, https://x.com/AnthropicAI/status/2062568864240836995 。

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

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