當寫 code 不再是瓶頸: Anthropic 的 AI-native 工程組織，與那些不買單的聲音

Anthropic 的 Fiona Fung (帶 Claude Code 與 Cowork 工程團隊) 有一場演講 Running an AI-native engineering org，講的是當 coding 不再是瓶頸之後，他們把整個團隊的工作慣例 (norms) 砍掉重練的過程。小編覺得這是目前少數講得很具體的「AI-native 工程組織到底長什麼樣」第一手紀錄，蠻值得看。

編按: 這場演講的中文重點，宝玉 (@dotey) 整理過一個摘要版本 (按讚數破四百，傳得蠻廣)，想先快速掃過重點的可以參考。等一下會提到的 Toby 那串反駁，衝著的就是這篇摘要。

不過這場演講放出來之後，網路上也出現了不少不買單的聲音。剛好 Claude Code 之父 Boris Cherny 最近接受 Platformer 訪談又把話說得更滿:「coding 已經被解決了」「軟體工程師這個頭銜今年可能開始消失」。所以這篇就把三件事疊在一起看: Fiona 講了什麼、反對的人在吐槽什麼、以及一票真的在寫嚴肅軟體的人，怎麼反駁「人類不用再寫 code」這個說法。

一、Fiona 的演講: 瓶頸搬家了

Fiona 整場的主旋律就一句話: 「過去成就你的，未來不一定還能成就你 (what served you prior may not serve you any longer)」。

她說過去這麼多年，工程師的頻寬 (engineering bandwidth) 一直是最貴的東西，寫 code、寫測試、重構都很花時間，所以我們發明了一堆流程 (瀑布、敏捷、六個月 roadmap、設計文件)，本質上都是因為「打 code 很貴」，要好好規劃才不會浪費。

她也提醒這不是業界第一次得適應。她職涯早期在做 Visual Studio 2005，當年軟體還是燒在 CD-ROM 上出貨 (更早是磁片)，有硬死線要趕著把成品送進工廠壓片、裝盒、上架; 後來能線上發佈，整個出貨方式就被改寫了一次。每次底層條件一變，做事方法就得跟著重來。

但現在這個前提變了。在 Claude Code 團隊，「coding 已經很少是慢的那一環」，而且產出量暴增。瓶頸於是從「打字」搬到了它周圍的所有事情，用她那張投影片的講法: 舊瓶頸是「寫與出貨 code 的頻寬」(寫 code、寫測試、重構)，新瓶頸是「驗證、審查、跨職能協作、安全」。問題從「誰來寫」變成「這段 code 對嗎? 誰來 review? 之後誰維護?」

她有個觀察小編特別喜歡: 很多流程是「悄悄地不再有用 (quietly stops working)」。因為流程很少會自己消失，我們總是一層一層往上疊，疊到後來連 SLA 都要排優先順序。於是 Claude Code 團隊把一大堆慣例砍掉重練。最核心的一句話是: 他們把力氣從「事前」搬到了「事後」，少花時間規劃和爭論，多花時間驗證和對齊。

底下分三塊講她實際改了什麼。

規劃與技術辯論: 從「先想清楚」到「先做出來」

規劃變少，而且即時，她叫它 JIT planning (just-in-time，借自 JIT 編譯)。六個月 roadmap 寫完三個月就過期了，所以乾脆少寫; 設計文件大幅減少，改成「與其寫一份 doc，不如丟一個 PR」「有想法就去 prototype」; 產品評審也少做，因為局勢變太快，不如先做原型、讓內部大量試用、再出貨收真實回饋。

至於「加倍投資的驗證」，她叫它「左移 (shift left)」: 與其等 code 出去後自己搶在使用者之前抓 bug，不如用更多自動化，在更接近源頭的地方就攔下來。她講了個很有共鳴的例子: 有次她修了個 bug，隔天看到有人在 Boris 的 thread 上回報「我發現一個 bug」，當下那種「該不會是我吧」的下沉感，所以她希望不管什麼角色，每個人對自己送出的改動都更有信心。

技術辯論也變了，她的講法是「code 說了算」。她剛加入時想做一個重構，本來想拉 Boris 去會議室白板大戰，後來想想，不如直接讓 Claude 生成三個不同版本的 PR，連對所有 API 呼叫端的影響都一起攤開來看。「當『做出來』很便宜，『吵架』就變貴了」。但她特別強調，這反而讓「團隊文化與對齊」更重要，絕對不能變成「最後一個 check-in 的人贏」。

程式碼的歸屬與審查: 「誰寫的?」變成一個怪問題

因為所有 PR 都是 Claude 輔助生成的，「這段 code 是誰寫的?」現在問起來有點怪。她的建議是「往下追問 (double click)」你真正想問的是什麼: 是想找誰造成了這個 regression? 還是想找懂這塊的專家? 還是只是想了解脈絡? 想清楚之後，很多都能自動化，她甚至把每天早上配咖啡、進客戶回饋頻道請 Claude 摘要的儀式，直接變成了一條 routine 自動跑。

至於 code review，重點是分清楚哪裡信任 Claude、哪裡還是要人。風格、lint、補測試、甚至抓些小 bug 並修掉，這些重度交給 Claude; 但本著「信任但要查證 (trust but verify)」，法務審查、信任邊界與安全敏感的 code、產品品味，她還是堅持要拉真人專家進來。(她講了個好笑的例子: 有次想把終端機裡的 Claude 裝飾成雪人，結果做出來像花生人 Mr. Peanut，是設計師夥伴一眼點出來的。品味這種事，模型還沒接手。)

編按: 「你們怎麼跟得上 code review?」是她說過去半年被其他工程主管問最多的一題。這也呼應了新瓶頸的核心: 當生成變快，驗證與審查就成了真正的壓力點。這個主題小編之前整理過一整篇 AI 時代的 Code Review: 當 Pull Request 成為新瓶頸，挑了五篇 2026 年的文章談 review 跟不上之後的各種路線 (規格驅動開發、直接幹掉 review、五層信任框架…)，想往下深挖的可以接著看。

團隊組成與組織形狀

她重度看兩種工程師: 「有產品 sense 的創意建造者」跟「深度系統專家」(例如做 Claude Code Remote 這種分散式系統就少不了後者)，反而比較不看重「原始產出量」，因為那個模型已經幫你補上了。角色也在互相滲透: 她是工程師、自認文筆很糟，就讓 Claude 當她的「內容設計」夥伴，幫忙把問卷文案改得精簡 (終端機裡每一行空間都很珍貴); 反過來她的 PM 也大量在寫 code。

組織則盡量扁平、scrappy，她甚至要求每個 manager 都先從 IC 做起、親手 dogfooding，招募夥伴一度覺得她瘋了，說「哪個 manager 會願意先當 IC」。團隊還立了三條核心原則: ① 每個成員 (含跨職能夥伴) 都要用 Claude Code; ② 能 Claude 化的就 Claude 化 (Claudify everything); ③ 明確授權大家去砍掉沒用的流程。

最後談「這套到底有沒有用」，她給了三個可參考的指標: onboarding 上手時間大幅縮短、PR 週期時間縮短、Claude 輔助的 commit 比例上升 (她說過去四個月幾乎沒看過非 Claude 輔助的 commit)。但她也提醒: 不要盯著新聞標題那種「本公司 X% 的 code 由 AI 生成」，要回去看你真正想解決的問題、想做得更好的產品是什麼，品質與可靠度才是該盯的。

小編覺得這場演講最實在的地方，是它不講願景、只講「我們實際改了哪些慣例」。而且 Fiona 自己留了幾個沒答案的問題給自己 (iOS/Android 還要不要分隊、自動審查要推多遠、角色模糊後怎麼讓大家都覺得有產出感)，姿態其實蠻誠實的。

她最後留給聽眾一個可以帶回去做的事: 挑一個你最「吵」的工作流程 (最貴的、或大家最不想碰的那個)，問一句「它還有在服務當初的目的嗎?」。她舉了個例子: 以前有個 50 人的週會，她發現大家全程都在滑筆電、只有輪到自己報告時才抬頭講兩句，於是她問了句「我們到底為什麼要開這個會?」，然後就把它取消了。

二、反方一: Toby 的吐槽

不過工程師 Toby (@TobyAtLarge) 就不太買單，他針對宝玉那篇演講摘要寫了一串挺兇的反駁 (他自己也自嘲「好擔心自己變成槓精」)。幾個重點:

1️⃣ 「code 幾乎免費」是演講修辭，不是事實。code 確實便宜很多了，但「好的 code」(考慮架構、邊界條件、測試覆蓋) 仍然有成本。而 Fiona 自己也承認「維護成本不會跟著歸零」，代表她心裡清楚，只是台上為了衝擊力把話說滿了。

2️⃣ Source of truth 不只一層。她說「code 是唯一的事實來源」太絕對。真實工程至少三層: 需求 (為什麼做) → 設計 (怎麼做) → code (做出來了)。code 是執行結果，常常處在折中狀態。沒有需求文件做參照，你連「這個折中是刻意的還是 bug」都分不清。

3️⃣ JIT planning = 沒有規劃。他覺得對一個正經的 toB/toC 產品不做規劃很誇張，「先發 PR、少開會」容易導致功能失控。而且諷刺的是，從使用者端看，Claude Code 的發布節奏看起來反而是有規劃、有節制的，不像她描述的那種野蠻生長。

4️⃣ 整體判斷: 特殊環境裡的個人經驗，被包裝成了普適方法論。Anthropic 是極端特殊的環境: AI-native 產品、極高人才密度、公司本身就是最好的 dogfooding 場景。在這種環境跑一年的實驗，外推到「所有工程團隊都該這樣」，折扣要打得很大。

小編覺得 Toby 第三點對 open question 的批評有點過嚴 (她明明就說那是「還在想的問題」)，但第一點跟第四點蠻值得記住的。其實 Fiona 自己在台上就講了「do what makes sense for your team」，她沒要你照抄。真正的風險是聽眾，很容易把 Anthropic 的做法當聖經，忘了自己的 codebase 和人才密度根本不是那回事。

三、Boris 把話說得更滿: 「coding is solved」

如果說 Fiona 還算克制，Boris Cherny (Claude Code 的創造者) 在 Platformer 的訪談裡就直接得多了。他說自己已經超過六個月沒寫過一行 code、對他做的工作來說 coding「基本上解決了」，還公開預測「軟體工程師」這個頭銜今年就可能開始消失，融化成某種「builder」的角色，因為他身邊的設計師、PM、主管現在全都在寫 code。

Claude Code 已經有超過半年是 100% 由 Claude Code 寫的。Boris 說他去 Y Combinator 最新一批新創做分享，問「有誰 100% 的 code 是 Claude Code 寫的」，現場一半的手舉起來; 問「有誰完全沒用模型寫 code」，兩百多人裡只有一隻手。

不過小編要幫他說句公道話，因為這句話常常被斷章取義。Boris 在訪談裡其實有把 caveat 講清楚: 「對我做的那種 coding 來說，coding 已經被解決了」。他做的是相對簡單的 codebase (Claude CLI 還很新，桌面和 App 都是小型、單純的 codebase)。但 Anthropic 也有 NASA 這種大型、超複雜 codebase 的企業客戶，「對他們來說還沒解決，模型還是會出錯」。而且他強調 coding 只是工程師工作的一小部分，他以前大概 50% 時間在打 code，另外 50% 在跟使用者聊、腦力激盪、debug、規劃。他甚至預測未來「寫 code / 用 agent 寫 code 的人」會比現在多 100 倍。

編按: 問題就出在這個 caveat 在傳播時被剝掉了。新聞標題只留下「coding is solved」「工程師要消失了」，後面那半句「for the kinds of coding that I do」不見了。下面這群人反駁的，其實主要是被剝掉 caveat 之後的那個版本。

四、多方反駁: 瓶頸沒消失，它搬到了判斷力

小編搜尋了一輪這半年的論戰，發現一件有意思的事: 真正天天在用這些工具寫嚴肅軟體的人，幾乎沒有人站「人類不用再寫 code」這一邊。他們的反駁很一致: 生成 code 從來就不是軟體工程的難處。

Simon Willison 把 AI 寫 code 拆成兩個世界: 「vibe coding」(完全不看 code，壞了再求模型一次) 跟「agentic engineering」(專業工程師用 agent 放大自己的專業)。他不怕飯碗不保，因為這些工具是「既有經驗的放大器」，你越懂跑得越快。他有句話講得很白: 「做出軟體是一件兇殘地困難的事，給我全世界所有的 AI 工具，我們想達成的目標還是非常難。」

Armin Ronacher (Flask、Jinja 作者) 的例子更具體。他新公司的基礎設施九成以上是 AI 寫的，但他點出: 要用到這個程度，「你得知道 goroutine 和 thread 的差別、得懂 rate limiter 為什麼需要 jitter」。結論是: 「這些工具不會取代程式設計師，它們讓我們能在更高的層次施展專業。」

Mario Zechner (Pi agent 框架作者) 講得最直白: 人類是個瓶頸，而這恰恰是一種保護。

「人類沒辦法在幾小時內吐出兩萬行 code。但一支被編排好的 agent 大軍沒有瓶頸、沒有疲累，那些看似無害的小錯會以不可持續的速度複利累積。你把自己移出了迴圈，根本不知道這些小錯已經長成了一隻怪物，等你感覺到痛，已經太遲了。」

最後是 Matt Asay 在 InfoWorld 的提醒，正好打中 Fiona 那個「別盯著 AI%」的點: 對管理者來說，最糟糕的指標就是「AI 生成 code 的百分比」，真正該看的是缺陷有沒有變少、事故有沒有減少、客戶有沒有更開心。他總結得很到位: 「AI 並沒有消除工程紀律的必要，它只是提高了『沒有紀律』的代價。」

所以呢?

把這一圈聲音疊在一起，會發現它們其實沒有互相矛盾，反而拼出了一個共識。

Fiona 在台上已經親口說了答案: 瓶頸搬到了「驗證、審查、安全」。只是到了 Boris 的 slogan 裡，後半句被吃掉，變成了爽快的「coding is solved」。但這兩件事是一體的: code 變便宜，不代表「做出好軟體」變便宜，它只是把成本從「打字」搬到了「判斷、驗證、長期維護」。而那恰好是最難自動化、最吃經驗的部分。

有意思的是，連把話說得最滿、喊出「coding is solved」的 Boris 自己都留了一手。訪談最後問他要不要把「在 X 和 Threads 上回覆使用者 bug 回報」這件事也自動化掉，他說: 「我已經自動化了，但我還是偏好自己來。」原因很簡單: 跟人互動、聽人說哪裡壞了，是他最喜歡的部分。你看，連他都選擇把這件事留在迴圈裡親自做，而那正是判斷與品味。

所以與其問「人類還要不要寫 code」，不如問一個更實際的問題: 當生成幾乎免費，你打算把省下來的時間拿去做什麼? 是塞進更多沒人看得懂、沒人 review 的 code，還是拿去想清楚到底該做什麼、把它做對?

Armin 在另一篇文章裡有句話，小編覺得很適合收尾: 「沒有人能量產一棵五十歲的橡樹，也沒有人能用一個週末的衝刺，變出信任、品質或社群。」生成速度可以無限快，但有些東西，就是需要時間。