Claude Code 創作者 Boris Cherny：不要為今天的模型開發，要為六個月後的模型開發

本文整理自 The Developing Dev Podcast 訪談，來賓為 Claude Code 創作者、前 Meta 首席工程師 Boris Cherny。

一個違反直覺的產品決策

當 Boris Cherny 在 Anthropic 開始打造 Claude Code 時，AI 編碼的主流思維還停留在自動補全。工程師們想到 AI 寫程式，腦中浮現的是按下 Tab 鍵讓編輯器幫你補完下一行程式碼，頂多再加上問答功能解釋某段程式的用途。這是當時的技術現實，也是市場上大多數產品的設計方向。

Cherny 原本也這麼想。但他的主管 Ben Mann——Anthropic 的共同創辦人之一——推了他一把，要他跳脫眼前的限制去思考。Ben 從 Anthropic 創立之初就深度參與模型開發，對 Scaling Laws 有著直覺性的理解。他知道模型能力的進步速度，也知道如果只為今天的模型設計產品，等產品上線時就已經落後了。

這個建議聽起來簡單，執行起來卻需要勇氣。為六個月後的模型開發，意味著你做出來的產品在當下可能根本不好用。Cherny 坦承，Claude Code 剛推出時的確是個普通的產品，他自己也只用它來寫大約一成的程式碼。模型能力還沒到位，工具再怎麼設計精良也發揮不出來。

轉折發生在 2025 年三月。Anthropic 釋出了新版本的 Sonnet 和 Opus 4，模型能力跨過了某個臨界點。Cherny 發現自己開始用 Claude Code 寫一半以上的程式碼，而這個時間點距離專案啟動正好是六個月。Ben 的預判完全應驗了。

生產力提升 70% 的真實數據

現在走進 Anthropic 的辦公室，你會看到一個奇特的景象：不只是工程師，連資料科學家和業務團隊都開著 Claude Code 在工作。資料科學家 Brandon 有一天讓 Cherny 嚇了一跳，他自己搞懂怎麼安裝 Node.js 和使用終端機，然後用 Claude Code 幫他寫 SQL 查詢和做資料分析。現在他同時開著好幾個 Claude Code 視窗，讓它們平行處理不同的分析任務。

這不是個案。Anthropic 的業務團隊有一半的人用 Claude Code 來處理日常工作，他們把它連接到 Salesforce 和各種資料來源，讓 AI 代理幫忙整理客戶資料和準備報告。這些人不是工程師，但他們找到了讓 AI 編碼工具為自己所用的方式。

更驚人的是工程團隊的數據。Cherny 透露，即使 Anthropic 的員工人數在一年內成長為原來的三倍，每位工程師的產出（以 Pull Request 計算）卻提升了將近 70%。有些團隊高達九成的程式碼是用 Claude Code 寫出來的，Claude Code 團隊本身也是如此。這個工具正在用自己來開發自己。

Cherny 提到一個具體的例子：他們最近推出了外掛功能，負責開發的工程師 Daisy 讓 Claude 自動建立 Asana 看板和任務，然後同時啟動二十個 Claude 代理在 Docker 容器裡平行開發不同的外掛。整個週末跑下來，功能就完成了。這種「代理群集」的工作方式，正在改變軟體開發的本質。

程式碼品質不能打折

外界對 AI 生成程式碼最常見的批評，就是品質參差不齊。Andrej Karpathy 在一次訪談中提到「vibe coding」雖然能快速產出結果，但也會產生大量品質不佳的程式碼。這個批評是真實的，Cherny 並不迴避。

但他認為問題不在工具本身，而在使用者如何設定標準。在 Claude Code 團隊，他們對程式碼的要求完全一視同仁，不管是人寫的還是模型寫的。如果程式碼品質不好，就不會被合併進主分支，無論它來自哪裡。如果模型產出的程式碼有問題，就要求它改進，就像對待任何一位同事的程式碼審查一樣。

Cherny 把 AI 編碼工具的使用方式分成幾種層次。Vibe coding 適合用在原型開發和拋棄式程式碼，這種時候速度比品質重要。但對於需要長期維護的核心功能，他會進入「配對模式」，先讓模型提出計畫，審視過後再讓它實作，然後根據需要要求它改進或清理。對於某些他有強烈意見的核心程式碼，例如參數命名或特定程式碼的位置，他仍然會自己動手寫。

這不是非此即彼的選擇，而是根據情境使用不同的工具組合。學會這種彈性運用，是讓 AI 編碼工具真正發揮效用的關鍵。

軟體工程正在變成管理工作

Cherny 現在的工作方式，跟一年前完全不同。每天早上他打開手機上的 Claude 應用程式，啟動幾個代理開始處理當天的程式碼任務。等他到辦公室坐到電腦前，這些代理已經跑了一段時間，有些產出的程式碼可以直接合併，有些需要他在本機上調整一下。

他的同事、一位多年沒寫程式的工程主管 Fiona，現在每週都會寫好幾次程式碼。她用手機應用程式和網頁版 Claude 來啟動代理，在會議空檔讓它們跑著，然後檢視結果。對於行程被會議塞滿的主管來說，這打開了一個過去無法想像的可能性。

這讓 Cherny 想起 Paul Graham 那篇經典文章中關於「創作者行程」和「管理者行程」的區分。過去，軟體工程師需要大塊完整的專注時間才能進入心流狀態寫程式，被會議打斷是生產力的大敵。但現在，工程工作越來越像管理工作：你同時監督一群代理在執行任務，在它們之間切換注意力，審視它們的產出，決定哪些可以採用、哪些需要調整方向。深度專注的價值並沒有消失，但它不再是唯一的工作模式了。

這是最差的時候，也是起點

在訪談的最後，Cherny 提到一個值得玩味的觀點：現在的 AI 模型在寫程式這件事上，其實還不算太厲害。以他的標準來看，進步空間還非常大。但他緊接著說，這也是它能力最差的時候了。

回想一年前，AI 編碼的最先進技術就是自動補全。現在，工程師可以同時操控二十個代理平行開發功能，非技術人員可以用自然語言讓 AI 幫忙寫 SQL 和處理資料，工程主管可以在會議空檔用手機啟動程式碼任務。這個轉變發生在短短幾個月內。

如果這個軌跡繼續下去，三個月後、六個月後的情況會是什麼樣子？Cherny 說他沒辦法給出具體預測，因為變化的速度讓任何預測都顯得保守。但有一件事是確定的：理解這個軌跡、為未來而非當下設計產品，是他在 Anthropic 學到最重要的一課。

我的觀察

Boris Cherny 的故事對台灣的開發者有幾個值得深思的啟示。

首先是工具採用的心態。很多人在試用 AI 編碼工具後覺得「也就那樣」，沒有想像中厲害。這個反應是正常的，Cherny 自己一開始也是這麼覺得。但關鍵是理解模型能力的進步曲線，以及願意持續調整自己的使用方式。今天覺得雞肋的功能，三個月後可能變成不可或缺的工作流程。

其次是對「工程師」這個角色的重新定義。當程式碼可以被代理群集量產時，工程師的價值會越來越集中在判斷、品味和架構決策上。知道什麼該做、什麼不該做、程式碼品質的標準在哪裡，這些「軟性」能力會變得比打字速度更重要。Cherny 提到他對程式碼品質的堅持，不因為它是 AI 生成的就降低標準，這個態度值得學習。

最後是關於早期採用的優勢。Anthropic 內部的資料科學家和業務團隊，在工具還不完美的時候就開始摸索使用方式，現在他們已經建立了自己的工作流程和心智模型。等到工具變得更強大，他們可以直接升級，而不是從零開始學習。這種提早進場、在混沌中建立手感的策略，對於任何想在 AI 時代保持競爭力的人都適用。