Claude Code 負責人 Boris Cherny：我已經不再手寫程式，AI 正在重塑軟體工程
本文為 Boris Cherny × Lenny Rachitsky 訪談逐字稿系列第 1 篇，共 3 篇。
Claude Code 負責人 Boris Cherny：我已經不再手寫程式，AI 正在重塑軟體工程
Claude Code 一年改變了什麼
Boris Cherny： 我 100% 的程式碼都是由 Claude Code 撰寫的。自去年十一月以來，我沒有親手手寫過任何一行程式碼。我每天都會發布 10、20、甚至 30 個 Pull Request。就在我們錄音的當下，我背景還有大概五個 Agent 正在同時運行。
Lenny Rachitsky： 你會懷念親自寫程式嗎？
Boris Cherny： 我從來沒有像今天這樣享受寫程式，因為我不再需要去處理那些微枝末節的事。每位工程師的生產力提升了 200%。大家總是在問：「我還該不該學寫程式？」在一到兩年之內，這件事根本就不重要了，寫程式這件事在很大程度上已經被解決了。我憧憬的世界是每個人都能編寫程式，任何人都可以在任何時候隨手構建軟體。
Lenny Rachitsky： 軟體開發方式的下一個重大轉變會是什麼？
Boris Cherny： Claude 已經開始自己發想點子了。它會去查看使用者的反饋、去翻閱錯誤報告、檢視遙測數據以找出 Bug 修復方案和可以上線的功能。它變得越來越像是一個真正的同事。
Lenny Rachitsky： 很多在聽這期節目的聽眾都是產品經理（PM），他們現在可能正在冒冷汗。
Boris Cherny： 我認為到了今年年底，每個人都會成為產品經理，而且每個人都會寫程式。「軟體工程師」這個職稱將會開始消失，取而代之的就只是「建構者（Builder）」。這對許多人來說將會是一段痛苦的轉變期。
Lenny Rachitsky： 今天我的來賓是 Anthropic 的 Claude Code 負責人 Boris Cherny。很難用言語形容 Claude Code 對整個世界帶來的衝擊。在這期節目上線的前後，正好是 Claude Code 推出一週年的日子。在短短一年時間裡，它徹底改變了軟體工程師這份工作，而且現在也開始改變科技界許多其他職能的工作方式，我們在今天這集都會深入探討。
Claude Code 本身也是過去一年推動 Anthropic 整體飛速成長的巨大引擎。他們剛完成一輪估值超過 3,500 億美元的融資。正如 Boris 所提到的，Claude Code 本身的增長仍在持續加速，光是在過去這一個月裡，他們的每日活躍用戶數（DAU）就翻了一倍。
Boris 本身也是一位非常有深度、思想敏銳且值得深聊的人。在談話過程中，我們甚至驚訝地發現我們倆居然出生在烏克蘭的同一座城市。這實在太巧了，我之前完全不知情。
非常感謝 Ben Mann、Jenny Wen 和 Mike Krieger 為這次對話提供精彩的主題建議。別忘了瀏覽 lennysprodpass.com 查看專為 Lenny 通訊訂閱者提供的各項獨家優惠。
Lenny Rachitsky： Boris，非常感謝你來到節目中，歡迎！
Boris Cherny： 嗨，謝謝你邀請我。
Lenny Rachitsky： 我想先從一個比較辛辣的問題開始。大約六個月前，我不知道大家還記不記得，你其實離開了 Anthropic 加入了 Cursor，但兩週後你又回到了 Anthropic。那時候到底發生了什麼事？我好像從沒聽過這背後完整的故事。
Boris Cherny： 這大概是我經歷過換工作換得最快的一次了。我當初加入 Cursor，是因為我本身就是這款產品的超級粉絲。坦白講，當我見到他們的團隊時，我留下了非常深刻的印象。他們是一支非常棒的團隊，我至今依然覺得他們極為優秀。他們正在打造很酷的東西，而且比許多人都更早看清了 AI 輔助寫程式的未來走向。所以對我來說，能去打造優秀的產品是非常令人興奮的。
但我想，當我一到那裡之後，我開始意識到，我在 Anthropic 真正懷念的是它的「使命（Mission）」。而這其實也是我當初加入 Anthropic 的初衷。因為在進 Anthropic 之前，我在大型科技巨頭工作，到某個時間點，我想要去一間 AI 實驗室工作，希望能以某種方式協助塑造我們正在構建的這個不可思議之物的未來。而吸引我加入 Anthropic 的正是它的使命——也就是完全以安全（Safety）為核心。
當你在 Anthropic 和同仁聊天時，隨便在走廊遇到一個人問他為什麼在這裡，得到的答案永遠都會是「安全」。這種以使命為導向的氛圍讓我產生了極為強烈的共鳴。而且就我個人而言，我知道這是我想要感到快樂所不可或缺的東西。這是我深切想念的一點。我也發現，無論手頭上的工作是什麼、無論有多令人興奮，即便是在打造一款非常酷的產品，都無法真正取代那種使命感。所以對我來說，我很迅速地就意識到自己缺少了什麼。
Lenny Rachitsky： 那我們就順著你重返 Anthropic 以及你在那裡所做的工作繼續聊下去。這期節目上線時，大概正好是 Claude Code 推出一週年。我想花點時間回顧一下你所帶來的影響力。
最近 SemiAnalysis 發布了一份報告，我相信你肯定看過了，報告指出目前全球 GitHub 上有 4% 的 Commit 是由 Claude Code 所貢獻的。他們更預測到今年年底，這個比例將達到 GitHub 全球所有程式碼 Commit 的五分之一。他們的形容是：「在我們眨眼之間，AI 已經吞噬了所有的軟體開發。」
就在我們錄音的今天，Spotify 剛發表了一則頭條新聞，提到拜 AI 所賜，他們頂尖的開發人員自去年十二月以來就沒再親手寫過一行程式碼。越來越多頂尖資深的工程師——包括你在內——都在公開分享自己不再手寫程式碼、全部交由 AI 生成，甚至許多人根本不再去看程式碼了。
我們能走到這一步，很大程度都要歸功於你啟動的這個小專案，以及你的團隊在過去一年中的拓展擴充。我很想聽聽你對這過去一年的回顧，以及你的工作所帶來的影響有什麼感想要分享？
Boris Cherny： 這些數字真的太瘋狂了，對吧？佔全球所有 Commit 的 4%，這遠遠超出了我當初的想像。而且正如你所說，這感覺還只是起點而已。這還只是公開的 Commit 數據，我們內部推估，如果是看私有程式碼倉庫（Private Repositories），這個比例其實要高出不少。
對我來說，最瘋狂的甚至不是我們目前所處的數字，而是我們增長的速度。因為如果你檢視 Claude Code 的增長率，幾乎從任何指標來看，它都在持續加速。它不僅僅是在往上攀升，而且是上升得越來越快。
Claude Code 是怎麼誕生的
當我最初著手開發 Claude Code 時，它原本只是一個小小的黑客專案（Hack）。在 Anthropic 內部，我們大體上都知道我們想要推出某種類型的 Coding 產品。長久以來，Anthropic 在訓練模型時所遵循的方式，正好契合我們構建安全 AGI 的心智模型：模型會先在寫程式（Coding）上表現得非常出色，接著在工具使用（Tool Use）上變得極為擅長，然後在電腦操作（Computer Use）上變得非常厲害。這大概就是我們發展的軌跡。
我們朝這個方向努力了很久。當你回看我最初加入的團隊，叫做 Anthropic Labs 團隊。其實 Mike Krieger 和 Ben Mann 最近又重啟了這個團隊進行第二輪的探索。這個團隊過去打造了一些相當酷的東西：我們打造了 Claude Code、打造了 MCP（Model Context Protocol）、打造了桌面應用程式。所以你可以看到這個想法最初的雛形——先是寫程式，再來是工具調用，接著是電腦操作。
這之所以對 Anthropic 至關重要，核心依然是「安全」。AI 正在變得越來越強大、能力越來越全面。過去一年發生的轉變是：至少對工程師而言，AI 不再只是寫寫程式碼、不再只是一個陪你聊天的對話夥伴，而是能真正使用工具、能在真實世界中採取行動。
現在透過 Cowork，我們也開始看到非技術背景的使用者迎來這樣的轉變。對於很多使用對話式 AI 的人來說，這可能是他們第一次接觸到「真正具備行動能力」的工具。它能真正去操作你的 Gmail、操作你的 Slack，幫你處理各種雜事，而且做得非常好，未來只會越來越好。
所以長久以來，Anthropic 一直有一種感覺，想要打造點什麼，但當時並不明確究竟該做什麼。當我加入 Anthropic 時，我花了一個月的時間隨性折騰（Hacking），做了一堆稀奇古怪的原型。其中大部分都沒有上線，甚至根本談不上接近上線，那純粹是為了摸清模型能力的邊界在哪裡。
接著我花了一個月的時間投入在後期訓練（Post-training）上，去了解研究端的運作方式。坦白說，作為一名工程師，我發現若想做出好的成果，你真的必須去理解你工作所在層級之下的那一層。以傳統的工程工作來說，如果你在做產品，你會想了解底層的基礎設施、Runtime、虛擬機器、語言，也就是你所構建系統的基石。但如果你是在 AI 領域工作，在某種程度上你必須真正去理解模型本身，才能做出優秀的工作。
因此我繞了點路去深入了解模型，之後我回來，開始動手做原型，也就是後來演變成的 Claude Code。它最早的版本——我記得某個夏天我拍了一段影片記錄下來，因為我錄了 Demo 並發布出去，當時叫做 ClaudeCLI。我當時只是展示了它是如何調用幾個工具的。而讓我感到震撼的是，我給了它一個 Bash 工具，當我問它「我現在正在聽什麼音樂？」時，它居然能利用那個工具自己寫出程式碼，並準確回答我正在聽什麼音樂！
這簡直是最不可思議的事情，對吧？因為我們根本沒有事先指示模型說「遇到這個情況你要用這個工具去做某件事」。模型只是被賦予了這個工具，它就自己摸索出該如何使用它來回答這個我自己都不確定它答不答得出來的問題。
於是我開始對這個原型進行更多擴充。我寫了一篇貼文在內部公告發布，結果只得到了 2 個讚。在當時這就是全部的反應了。因為公司內部的人在想到寫程式工具時，想到的都是 IDE，想到的是各種非常複雜精密的開發環境。沒有人會想到這東西居然可以做成終端機介面（Terminal-based），這是一種滿奇怪的設計方式，原本也算不上是有意為之。
但我一開始之所以把它做在終端機裡，是因為頭幾個月就只有我一個人，終端機是最容易快速構建的方式。對我來說，這其實是一個非常重要的產品啟示：在一開始時，你反而應該讓資源稍微匱乏一點。
後來我們開始思考是否該打造其他形態的外觀介面，但最終我們決定在終端機形式上堅持一陣子。最大的原因在於，模型進步得太快了，我們覺得當時根本沒有其他產品形態能夠跟得上模型進步的速度。老實說，這也是我自己當時一直在苦苦思索的問題。過去這一年裡，我腦子裡想的全部都是 Claude Code。很多個深夜裡我都在想：「好吧，模型正在以驚人的速度進步，我們該怎麼做？我們到底要怎樣才能跟上它的步伐？」而在當時，終端機是我唯一能想到的解法。
從內部 Hack 到全球使用
結果，在發布之後，它很快就流行了起來，在 Anthropic 內部大受歡迎。每日活躍用戶數呈現垂直暴增。其實在非常早期、我還沒正式推行之前，Ben Mann 就催促我去做一張 DAU（日活躍用戶）圖表，我當時還說：「現在是不是太早了，我們真的有必要現在做嗎？」他說：「要做。」果不其然，那張圖表幾乎是立刻垂直向上飆升。
接著在二月，我們將它推向了外部。其實大家現在可能不太記得了，Claude Code 在剛對外發布時並不是一砲而紅的。它確實吸引了一批使用者，也有不少早期採用者立刻理解了它的價值，但其實經歷了好幾個月，大家才真正看懂這到底是什麼東西。
再次強調，它實在是太顛覆、太不一樣了。每當我回想這點，Claude Code 之所以能成功，部分原因在於「潛在需求（Latent Demand）」的理念——我們把工具帶到人們已經身處的工作環境中，讓既有的工作流程變得更順手一點；但同時也因為它身處終端機內，給人一種新奇甚至有點異類的感覺，因此你必須抱持開放的心態去學習如何使用它。
當然，現在 Claude Code 已經無所不在了：在 iOS 和 Android 的 Claude App、在桌面版應用程式、在網頁端、在各種 IDE 擴充套件，以及 Slack 和 GitHub 裡。在工程師所在的這些地方它顯得親切多了，但最初並不是這樣的。
所以剛開始時，這項工具居然如此有用，連我們自己都感到驚奇。隨著團隊擴大、產品成熟，並對大眾越來越有幫助，從小型新創到頂尖的科技巨頭，全球各地的人都開始使用它並給予我們回饋。回首這一切，這真的是一段讓人非常謙卑的經歷，因為我們不斷在向使用者學習。最令人興奮的是：其實我們沒有人真正全盤知道自己下一步該做什麼，我們只是和所有人一起邊走邊摸索，而其中唯一最強烈的指引訊號，就是來自使用者的回饋。這一直是最好的部分，我無數次為此感到驚喜。
Lenny Rachitsky： 在當今世界，事物變化的速度實在驚人。你一年前推出這個專案時，這並不是人們第一次用 AI 來寫程式，但僅僅在一年的時間裡，軟體工程這整個職業已經發生了翻天覆地的變化。
以前有各種預言說「程式碼未來將 100% 由 AI 撰寫」，當時每個人都說：「怎麼可能，這太扯了，你在胡說八道什麼。」但現在，大家的反應變成了：「當然啊，事情正如預測的那樣發生。」現在事物演進和變化的步伐實在太快了。
Boris Cherny： 真的非常快。回想去年五月的「Code with Claude」大會，那是我們 Anthropic 舉辦的第一場開發者大會。我發表了一場簡短的演講，演講後的 Q&A 環節有人問我：「你對今年年底有什麼預測？」
我在 2025 年 5 月時給出的預測是：「到了今年年底，你寫程式可能不再需要 IDE 了，我們將開始看到工程師不再親手撰寫程式碼。」我記得當時全場聽眾倒抽了一口涼氣，因為在當時看來那是個無比瘋狂的預測。
但我認為在 Anthropic，我們思考事情的方式就是「指數級思維（Exponentials）」。這深植於我們的 DNA 之中。如果你看我們的共同創辦人，其中三位正是 Scaling Laws（縮放定律）論文的前三位作者。我們真的是以指數規律在思考問題。
如果你去觀察當時由 Claude 撰寫的程式碼比例所呈現的指數曲線，只要順著那條線延伸下去，到了年底越過 100% 是顯而易見的趨勢，即便這完全違背常理與直覺。所以我當時所做的就只是把那條趨勢線畫下去而已。到了十一月，就我個人而言，這件事確實發生了，自那時起一直維持至今，而且我們現在也開始看到許多不同的客戶身上出現了同樣的狀況。
Lenny Rachitsky： 你剛才分享的這段心路歷程非常耐人尋味——也就是「放手去試、到處折騰、看看會發生什麼事」的心態。這點在 OpenClaw 上也經常被提到，Peter 就是隨意嘗試，然後某個突破就發生了。這似乎是 AI 領域許多最重大創新的核心要素：人們花時間反覆摸索，把模型推向比其他人走得更遠的極限。
Boris Cherny： 這就是創新的本質，對吧？你無法去強迫它發生，創新是沒有既定路線圖（Roadmap）的。你必須給予人們空間，給予他們——或許該用這個詞——「心理安全感」，讓他們知道失敗是完全沒問題的、80% 的點子是爛點子也無所謂。
但同時你也必須保持某種程度的問責制，如果某個點子行不通，你就得及時停損，轉向下一個點子，而不是一味追加資源。
在 Claude Code 的早期階段，我根本不知道這東西到底會不會管用。因為即使到了二月我們對外發布時，它頂多只寫了我大約 20% 的程式碼，不會更多了；甚至到了五月，它也大概只寫了 30% 左右。我大部分的程式碼依然是使用 Cursor 寫的。直到十一月，它才真正跨越了 100% 的門檻。
所以這花了相當長的一段時間。但即使在最初期，我也強烈感覺自己抓到了某種脈絡，每天晚上和週末都全心撲在上面鑽研。幸運的是我的妻子非常支持我。那種感覺就是你摸到了一條線索，雖然還看不清全貌，但你明白只要順著那條線一直抽絲剝繭下去就對了。
100% 的程式碼交給 Claude Code
Lenny Rachitsky： 所以到了現階段，你 100% 的程式碼都是由 Claude Code 撰寫的，這就是你目前寫程式的現狀嗎？
Boris Cherny： 是的，我 100% 的程式碼都由 Claude Code 撰寫。我是一個產出量相當大的工程師，即便以前在 Instagram 工作時，我也是全公司最具生產力的前幾位工程師之一，而在 Anthropic 這裡依然如此。
Lenny Rachitsky： 哇，即使身為團隊負責人也是？
Boris Cherny： 對，我現在依然寫非常多的程式碼。每天我都會發送大約 10、20、30 個 Pull Request，大概是這個量級。
Lenny Rachitsky： 每天？天啊。
Boris Cherny： 是的，每天。100% 都是由 Claude Code 寫的。自去年十一月以來，我沒有親手改過任何一行程式碼。
不過我確實會去看程式碼。我不認為我們目前已經到了可以完全不管它的地步，特別是當有很多人在運行你的程式時，你必須確保它的正確性、安全性等等。
此外，我們也讓 Claude 自動為所有的程式碼進行 Code Review。在 Anthropic 內部，Claude 會審查 100% 的 Pull Request。雖然在這之後仍然有人工審查的一層把關，但你確實還是需要這些檢查點，仍然需要有人類去檢視程式碼——除非那是純粹的原型程式碼，你清楚它不會跑在任何生產環境中。
下一個前沿：AI 開始決定該做什麼
Lenny Rachitsky： 那下一個前沿會是什麼？目前你 100% 的程式碼都已經由 AI 代筆，而這顯然也是整個軟體工程界的大勢所趨。這在過去聽起來像不可思議的里程碑，但現在大家已經習以為常。
對於軟體構建方式的「下一個重大轉變」，無論是你的團隊已經在著手實踐的，還是你認為未來必將發生的，會是什麼呢？
Boris Cherny： 我認為眼前正在發生的事情是：Claude 已經開始自己發想解決方案和點子了。Claude 會去研讀使用者的反饋、去檢視 Bug 報告、去查看各類遙測資料（Telemetry），並開始主動提出 Bug 修復構想以及可以發布的新功能。它正變得越來越像是一個能並肩作戰的同事。
第二點是，我們正開始跨出純寫程式的範疇。我認為到了現在這個節骨眼，可以篤定地說「寫程式這件事在很大程度上已經被解決了」——至少對我所從事的那類編程工作而言，它就是一個已經被攻克的問題，因為 Claude 已經能搞定了。
所以現在我們開始思考：好，那接下來呢？在這之上還有什麼？有非常多圍繞在寫程式周圍的事情。我認為這些即將被逐一接管，甚至包括各類通用任務。舉例來說，我現在每天都會用 Cowork 來處理各種完全與寫程式無關的雜務，並且完全自動化。例如前幾天我要繳一張違規停車罰單，我就直接讓 Cowork 幫我繳掉了；我們團隊所有的專案管理也全由 Cowork 包辦，它負責在各個試算表之間同步進度、在 Slack 和 Email 上通知相關人員等等。
所以我認為下一個前沿將會是這類領域。它不再只是單純的寫程式，因為寫程式已經基本被解決了。在接下來的幾個月裡，我們將看到整個產業在面對各種類型的程式庫、各類技術棧時，編程問題都將變得越來越容易被全面解決。
Lenny Rachitsky： 讓 AI 協助你發想該做什麼的這個點子真的太有意思了。很多正在聽這集播客的人都是產品經理，他們現在可能正滿頭大汗。你是怎麼利用 Claude 來做到這點的？你就只是直接跟它對話嗎？還是你有摸索出什麼巧妙的方法，讓它幫你決定該打造什麼？
Boris Cherny： 老實說，最簡單的作法就是：打開 Claude Code 或 Cowork，然後直接把它指向一個 Slack 討論串。舉例來說，在我們公司內部，有一個頻道專門收集自從我們最早在 2024 年對內推出 Claude Code 以來的所有內部回饋。那裡一直是一道源源不絕、像消防水栓一樣噴湧的回饋洪流，那是最好的寶庫。
在早期的時候，我的作法是只要有人回報問題，我就立刻衝進去，用最快的速度修復每一個細節——可能在一分鐘內、五分鐘內之類的。這種極度迅速的回饋循環會激勵大家提出越來越多的意見。這至關重要，因為這讓他們覺得自己的聲音有被聽見。通常你在使用某個產品時提出建議，那往往就像掉進某個黑洞一樣無聲無息，之後你就不會想再提了。但如果你讓人們感受到被重視，他們就會願意持續參與，想幫忙把這項工具打磨得更好。
現在我的作法本質上差不多，只不過很多繁重工作坦白說都由 Claude 包辦了。我把 Claude 指向那個頻道，它就會說：「好的，這裡有幾件事我可以處理，我剛剛開了幾個 PR，你想看一下這一個嗎？」我就回它：「好啊。」
工程生產力提升 200%
Lenny Rachitsky： 你有注意到它在這方面有顯著的進步嗎？因為這可以說是當前的終極聖杯：一開始大家覺得「寫程式解決了」，接著 Code Review 變成了下一個瓶頸——那麼多 PR 到底誰來審查？而現在下一個巨大的未解之謎則是：「人類現在必須負責弄清楚到底該做什麼、該排定哪些優先順序。」而你卻說 Claude Code 已經開始在這些事情上為你分擔了。自從有了 Opus 4.6 之類的模型之後，它有變得更強大嗎？這當中的軌跡是怎樣的？
Boris Cherny： 是的，進步幅度非常大。我認為一部分原因來自我們針對寫程式所做的特定訓練。顯然我們擁有全世界最強大的編程模型，而且它正變得越來越好，像是 4.6 簡直不可思議。但其實我們在編程以外領域所做的大量訓練，遷移效果也非常好。這種「遷移能力」確實存在：你教模型學會做 X，它在做 Y 時也會跟著變好。
其帶來的效益簡直瘋狂。在 Anthropic 過去這一年裡，自從引進了 Claude Code，我們的工程團隊規模大概擴大了 4 倍左右，但就 PR 數量等指標而言，每位工程師的平均生產力提升了 200%。
對於任何真正從事這個領域、負責開發者生產力的人來說，這個數字根本是天方夜譚。因為在上一段職業生涯中，我在 Meta 工作，當時我的職責之一就是負責全公司的程式碼品質——涵蓋我們所有的程式庫，包括 Facebook、Instagram、WhatsApp 等等。其中很大一部分工作就是圍繞在生產力上，因為如果你能提升程式碼品質，工程師的生產效率就會更高。而在當時，幾百名工程師努力一整年，通常也只能看到幾個百分點的生產力提升。因此在今天看到這種數百個百分點的暴增，簡直太驚人了。
Lenny Rachitsky： 同樣讓人難以置信的是，這一切居然這麼快就被大家視為理所當然了。我們聽到這些數據時，反應都是「AI 帶來這種改變本來就是理所當然的」。軟體開發、產品構建以及整個科技界正在經歷的變革規模完全是前所未有的。我們太容易習慣這一切了，但必須意識到這真的是一件極為瘋狂的事。
別被舊模型的能力困住
Boris Cherny： 這確實是我偶爾必須提醒自己的一點。而且這件事在某種程度上也有負面影響——因為模型進步得實在太快了。其實我們可以聊很多這方面的負面影響，但從個人層面來說，其中之一就是模型迭代太快，導致我有時會被困在舊有的思考模式裡。
我甚至發現，團隊裡新來的同仁，甚至是剛畢業的新鮮人，在做事時都比我更具備「以 AGI 為先（AGI-forward）」的思維。舉個例子，大概幾個月前，我遇到了記憶體洩漏（Memory Leak）的問題。也就是 Claude Code 的記憶體使用量一路狂飆，飆到某個點就崩潰了。這是每位工程師都 Debug 過上千次、非常典型的工程難題。
傳統上的處理步驟是：先抓取 Heap 快照，倒進專門的 Debugger 裡，利用各類專業工具去層層剖析，看看到底出了什麼問題。我當時就在做這件事，埋頭在那堆 Trace 紀錄裡試圖理出頭緒。
結果團隊裡一位資歷較淺的工程師，直接把問題丟給 Claude Code，說：「嘿 Claude，這裡好像有記憶體洩漏，你能找出來嗎？」結果 Claude Code 做的步驟跟我一模一樣：它自己擷取了 Heap 快照，為了能自己分析數據，它還現場替自己寫了一個小型即時分析程式，迅速找出了問題所在，送出 PR 的速度甚至比我還快。
這就是我想說的：對於我們這些長年使用模型的人來說，你必須時時刻刻把自己的心態拉到當下的最新維度，不要固步自封在舊模型的世界裡。現在早就不是 Sonnet 3.5 的時代了，新的模型已經完全、徹頭徹尾地不一樣了。這種心態上的轉換是非常劇烈的。
刻意保持資源匱乏
Lenny Rachitsky： 我聽說你為團隊總結了一些非常具體的原則，新成員加入時你都會帶他們走一遍。我記得其中一條是：「有什麼比親自動手做某件事更好？那就是讓 Claude 來做。」聽起來剛才那個記憶體洩漏的案例，就像是你自己差點忘了這條原則，沒第一時間想著「先讓 Claude 來解解看」。
Boris Cherny： 當你刻意讓各個專案的資源都保持一點點匱乏（Underfund）時，也會引發一個非常有趣的現象：大家會被迫學會「把事情交給 Claude（Claudify）」。這也是我們經常看見的。在很多工作上，我們有時只安排一個工程師去負責一個專案。而他們之所以能極其迅速地上線，是因為他們內心本來就想快點把東西推出去——這是一種發自內心的內在動力，純粹想要把事情做好。當你有了一個好點子，你自然會迫不及待想讓它面世，不需要任何人逼你，那是你自發的動力。
所以當你擁有了 Claude，你就可以用它來將大量的工作自動化。我們一次又一次目睹這種情況。
因此，我認為第一個原則就是讓專案稍微保持資源匱乏；另一個原則是鼓勵大家跑得更快——如果一件事你今天就能做完，那你今天就應該把它搞定。這是我們在團隊裡極力提倡的。在早期這點尤為關鍵，因為當時團隊就只有我一個人，速度是我們唯一的競爭優勢。那是我們唯一能在這個競爭極為激烈的編程工具市場中勝出的方法。即便到了今天，這依然是我們團隊的核心準則。而如果你想跑得更快，一個極好的方法就是把更多事情交給 Claude 去做。
Lenny Rachitsky： 「刻意保持資源匱乏」這個觀點太耐人尋味了。普遍大眾的直覺往往是：AI 能讓企業減少招募、不用請那麼多工程師。所以這不僅僅是 AI 提升了個人產能，照你的說法，當你配置的人力更少時，反而能做得更好——不是單純因為 AI 讓你變快，而是當同一個專案上的人數變少時，你反而能從 AI 工具中搾出更多潛能。
Boris Cherny： 是的。只要你聘雇優秀的工程師，給予他們足夠的授權，他們自然能摸索出達成目標的方法。這也是我經常跟許多公司的 CTO 與管理階層交流的話題。
Token 預算不要太早最佳化
我給他們的建議通常是：初期不要試圖去最佳化，不要一開始就想著縮減成本。一開始的做法應該是盡可能給工程師最多的 Token 預算。現在我們開始看到很多公司在這麼做——像是在 Anthropic 內部，大家都能使用非常大量的 Token；甚至有些公司開始把這當成一項員工福利：「加入我們，Token 吃到飽。」
我非常鼓勵這種做法，因為這能讓大家自由地去嘗試那些原本可能被認為太過瘋狂的構想。如果某個點子驗證有效，那時你再來思考該如何擴大規模，那才是你進行最佳化和成本控管的時機——比如評估是否可以用 Haiku 或 Sonnet 來取代原本的 Opus。但在最開始的時候，你只要盡情投入大量 Token 去測試點子到底行不行得通，並賦予工程師自由去放手一搏。
Lenny Rachitsky： 所以這裡的建議是：在調用這些模型的成本上要捨得大方花費。聽眾聽到這裡可能會想：「廢話，你在 Anthropic 工作，你當然希望我們多消耗一點 Token。」但你真正要表達的是：最有趣、最具開創性的創新，往往誕生於某個人把模型推到極限、去探索所有可能性的過程。
Boris Cherny： 沒錯。而且事實上在小規模探索時，你根本不會收到什麼天文數字般的帳單。如果是單一工程師在做實驗，相較於他的薪資或營運公司的其他開銷，消耗的 Token 成本其實依然是相對微不足道的。這真的不是什麼巨額支出。直到專案規模擴大——假設他們做出了極為出色的成果，而這套系統需要消耗極龐大的 Token 量，成本開始變得可觀時——那才是你需要著手最佳化的時間點，千萬不要太早做這件事。
Lenny Rachitsky： 你有見過哪些公司，他們的 Token 支出已經高過工程師的薪水了嗎？你認為這會成為一種普遍趨勢嗎？
Boris Cherny： 在 Anthropic 內部，我們已經開始看到有些工程師每個月的 Token 消耗高達數十萬美元了。我們確實開始看到這種現象，而且在某些外部公司身上，類似的苗頭也正在浮現。
寫程式是工具，不是終點
Lenny Rachitsky： 回到寫程式本身。你會想念親手寫程式碼嗎？這會不會是一件讓你感到有些傷感的事——作為軟體工程師，這項技能你以後再也不用做了？
Boris Cherny： 這對我來說滿有趣的。當我最早開始學工程時，出發點非常務實，我學工程純粹是為了能把東西做出來。我是完全自學的，在學校我唸的是經濟學，我並沒有受過正規的資工教育。我很早就自學工程，初中時就開始寫程式了，而從一開始我的目的就極其務實。
其實我當初之所以學寫程式，是為了在數學考試上作弊。那是我做的第一件事。當時我們用那種圖形計算機，我就把答案寫進 TI-83 裡面。
Lenny Rachitsky： TI-83 Plus 對吧？
Boris Cherny： 沒錯，就是 Plus。我把答案預先寫進去。到了下一次數學考試——好像是隔年吧——題目變得太難了，我沒辦法把所有答案預先存進去，因為我根本不知道會考什麼題目。於是我必須寫一個小小的方程式解算器（Solver），讓這個程式能自動去解那些代數題目。
接著我發現只要買一條連接線，就能把這套程式傳給班上其他同學，這樣全班都能拿 A。不過後來我們全被抓到了，老師叫我們不要再搞鬼。但從最一開始，編程對我來說始終都極其務實——它是構建出某個東西的手段，而非目的本身。
當然，在某個階段，我個人也曾深陷於編程的精妙美感之中。我寫過一本關於 TypeScript 的書；我創辦了當時全球最大的 TypeScript 聚會，純粹是因為我深愛上了這門語言；我也曾深入鑽研過函數式編程（Functional Programming）等等。我認為很多寫程式的人常常會分心沉迷於此。對我而言，編程確實有其美妙之處，特別是函數式編程，型別系統裡有一種獨特的美感。當你解出一道極為複雜的數學難題，或是精準理順了型別定義、程式碼寫得極為優雅時，內心會有一種難以言喻的興奮感。
但這終究不是終點。對我來說，寫程式本質上就是一種工具，是完成事情的手段。
不過，並非每個人都有同感。舉例來說，我們團隊裡的一位工程師 Lena，在週末時依然會親手純手寫 C++，因為對她來說，她就是由衷享受手寫 C++ 的過程。每個人都是不同的。我認為即使這個領域發生了翻天覆地的變化，永遠都會有空間保留給這份工藝，永遠都有空間讓人去享受其中的藝術，只要你願意，你隨時可以繼續純手寫。
Lenny Rachitsky： 你會擔心自己身為工程師的技能因此退化（Atrophy）嗎？這是你會擔憂的事，還是你覺得這就是時代的必然方向？
Boris Cherny： 我覺得這本來就是歷史發展的必然軌跡，我個人並不是太擔心這點。
在我看來，編程始終處在一個不斷抽象演進的連續體上。在很早以前——軟體其實是個相對年輕的產物，對吧？如果看我們今天寫程式的方式，跑在虛擬機之類的軟體層上，這種開發模式大概是從 1960 年代才確立的，至今也不過六十幾年。在那之前是打孔卡（Punch Cards），再之前是硬體開關，再之前是純硬體，而更早之前就純粹是紙和筆——一整個房間的人坐在那裡用紙筆手算數學。
所以編程從以前到現在一直都在經歷這種轉變。在某種程度上，你依然會想去了解底層那一層的運作邏輯，因為這有助於你成為一名更出色的工程師，我想在接下來的一年左右依然會是這樣。但我想很快地，這就不再那麼重要了，它將會演變成類似跑在程式員底層的組合語言那樣的存在。
在情感層面上，我覺得自己好像總是在學新東西。作為一個程式設計師，這其實並不會讓人覺得突兀，因為歷史上總是不斷有新的框架、新的語言冒出來，這原本就是我們身處這個領域早已習慣的事。但我也明白這無法套用到每個人身上，有些人必然會感受到更強烈的失落感、懷舊情懷，或是技能生疏退化的焦慮。
Lenny Rachitsky： 我不知道你有沒有看到 Elon Musk 先前說的，他說為什麼 AI 不直接寫二進位碼？既然如此，搞那麼多程式語言抽象層到底有什麼意義？
Boris Cherny： 是啊，這是個好問題。我的意思是，如果我們想的話，AI 絕對完全做得到這一點。
Lenny Rachitsky： 大家總是在問同一個問題：「我還該不該學寫程式？學校裡的孩子還需要學寫程式嗎？」從你剛才的分享看來，你的觀點是一兩年之內，其實真的不需要了。
Boris Cherny： 我的看法是：對於今天正在使用 Claude Code、正在借助 Agent 寫程式的人來說，你目前依然需要理解底層的運作。但是在一到兩年之內，這真的不再重要了。
古騰堡印刷機與 AI 編程革命
我一直在思考，什麼才是這場變革最恰當的歷史對照物？因為我們總需要將這件事放在歷史脈絡中定位，去看看人類何時經歷過類似的巨變，什麼樣的心智模型才是貼切的。
對我來說，最貼近的歷史事件就是古騰堡印刷機。回看 15 世紀中葉的歐洲，當時的識字率其實極低，不到總人口的 1%。那時候全靠抄寫員（Scribes），所有文字的書寫、閱讀全由他們包辦。他們受雇於貴族與領主，而那些領主老爺自己往往大字不識一個。因此整個社會就是仰賴這極小比例的人口在處理文字。
後來，古騰堡發明了印刷機。有一個驚人的歷史數據：在印刷機問世後的短短 50 年內所產出的印刷品總量，超過了此前一千年歷史所產出的總和。印刷品的產量迎來了指數級爆發，而成本則雪崩式下跌，在接下來的 50 年裡降了大概 100 倍。
再看看識字率——這確實經歷了一段時間，因為學習讀寫是需要教育體系、需要閒暇時間的，你得擺脫成天在農田裡勞動的生活才能有空接受教育。但在接下來的 200 年裡，全球識字率上升到了大約 70%。
我認為我們即將見證的正是這樣一場轉型。
在相關的歷史文獻中，有一份很有趣的記錄：那是一段在 15 世紀對某位抄寫員的訪談，詢問他對印刷機的看法。結果那位抄寫員其實感到非常興奮！他說：「事實上，我最討厭的工作就是在兩本書之間反覆機械地抄寫文字；我真正喜歡做的是在書本裡繪製插圖與裝訂書籍。我很慶幸現在我的時間終於被解放了。」
作為一名工程師，我在這件事上感受到了強烈的共鳴。這完全就是我的心境：我終於不用再去處理那些枯燥繁瑣的寫程式細節了。那些細枝末節、那些在 Git 上遇到的各種折騰、去擺弄各種瑣碎的工具——那些從來就不是真正好玩的部分。
真正好玩的是去想清楚究竟要打造什麼、去把好點子生出來；是去和使用者溝通、去構思龐大系統的架構、去擘劃未來的藍圖、去和團隊中的夥伴並肩協作。而這正是我現在能夠花更多時間去做的事情。
