我們是否正處於程式碼的過剩期？

Andrej Karpathy 於 12 小時前發布（粗體為我所加）：

我從未感到作為一名程式設計師如此落後。隨著程式設計師貢獻的位元變得越來越稀疏且間隔越來越大，這個職業正在經歷劇烈的重構。我有一種感覺，如果我能妥善地將過去一年左右出現的工具串聯起來，我的能力可以增強 10 倍，而未能掌握這種提升顯然感覺像是技能問題。現在有一層新的可編程抽象層需要掌握（除了原有的底層結構），涉及代理（agents）、子代理、它們的提示詞、上下文、記憶、模式、權限、工具、插件、技能、鉤子（hooks）、MCP、LSP、斜槓命令、工作流、IDE 集成，並且需要為那些本質上是隨機的、易錯的、難以理解且不斷變化的實體建立一個全方位的心理模型，以了解其優點和陷阱，而這些實體突然間與過去那種老派的工程開發交織在一起。顯然，某種強大的外星工具被分發到了大家手中，只是它沒有附帶說明書，每個人都必須摸索如何握持和操作它，而由此產生的 9 級大地震正震撼著這個行業。捲起袖子吧，別掉隊了。

這似乎是自他 10 月 17 日發布的 Dwarkesh 訪談節目以來的一次重大更新（儘管我知道這些內容的剪輯需要時間，所以實際間隔可能更長），當時他說：

總體而言，模型還沒達到那種水平。我覺得業界跨出的步子太大了，試圖假裝這一切很神奇，但事實並非如此。這只是垃圾（slop）。他們沒有正視現實，也許他們是在試圖融資之類的。我不確定發生了什麼，但我們正處於這個中間階段。模型很棒，但仍需要大量改進。目前，自動補全（autocomplete）是我的最愛。但有時，對於某些類型的代碼，我會求助於 LLM 代理。

這只是我的猜測，但 Claude Opus 4.5 僅在一個月前發布，而 Opus 4.5 + Claude Code 對許多人來說似乎是那個重大的轉折點。

事實上，Claude Code 的創作者 Boris Cherny 在 Karpathy 的貼文下留言道（粗體為我所加）：

老實說，我大多數時候都有這種感覺。有時我開始手動處理問題，然後不得不提醒自己「Claude 可能能做這個」。最近我們在調試 Claude Code 中的內存洩漏，我開始用老方法處理：連接分析器（profiler）、運行應用、暫停分析器、手動查看堆分配。我的同事也在看同一個問題，他只是讓 Claude 生成一個堆轉儲（heap dump），然後閱讀轉儲文件以尋找不應存在的保留對象；Claude 一次性解決了問題並提交了 PR。 這種情況幾乎每週都在發生。在某種程度上，新同事甚至社會新鮮人，因為他們對模型能做什麼和不能做什麼沒有各種假設（那些在使用舊模型時形成的舊記憶），反而能最有效地使用模型。每隔一兩個月就要重新調整心理預期以適應模型的能力，這需要大量的腦力勞動，因為模型在編碼和工程方面的表現持續變得越來越好。過去一個月是我作為工程師以來，第一次完全沒有打開 IDE 的一個月。Opus 4.5 撰寫了約 200 個 PR，每一行代碼都是它寫的。 軟體工程正在發生根本性的變化，即使對於像我們這樣的早期採用者和實踐者來說，最困難的部分也是不斷重新調整我們的預期。而這僅僅是個開始。

需要說明的是，這些 PR 中有很多可能是「非常小的，只有幾行代碼和錯誤修復」（參考另一位 Anthropic 員工的評論）。Boris 剛向用戶徵求反饋，隔天早上就關閉了 19 個 PR。儘管如此，一個月內不打開 IDE 就能完成 200 個 PR 仍是一件大事 [1]。

更新：Boris 剛剛發布了另一篇貼文，提供了更多細節（粗體為我所加）：

[...]

在過去的 30 天裡，我提交了 259 個 PR —— 497 次提交，新增 4 萬行，刪除 3.8 萬行。每一行都是由 Claude Code + Opus 4.5 編寫的。 Claude 經常連續運行數分鐘、數小時甚至數天（使用 Stop 鉤子）。軟體工程正在改變，我們正進入編碼歷史的一個新時期。而我們才剛剛開始。

AI 加速 AI

看起來我們可能正在進入某種「人類 + AI」系統的自我改進反饋循環：實驗室的員工正在使用這些 AI 編碼代理來開發 AI 編碼代理，而這些模型的視野長度（horizon length）正以比我們想像中更快的指數速度增長（參考 Opus 4.5）[2]，甚至可能不只是指數級。

這並非 AI 自主地自我改進，但訓練更好的 AI 模型與讓這些模型加速 AI 研發自動化之間的反饋循環似乎正在收緊 [3] [4]。

「編碼懸置」（Coding Overhang）

2020 年 7 月，在 GPT-3 出現後，Andy Jones 詢問我們是否處於「AI 懸置」中，因為（當時）感覺公司只需將 GPT-3 這樣的模型擴展多個數量級，就能獲得更多的「智能」。

有了編碼代理和推理/測試時計算（test-time compute），在我看來，Karpathy 和 Boris 所描述的是一種「編碼懸置」，即處於尖端的人員，尤其是技術人員，正試圖追趕那些純粹取決於用戶技能問題的 ~10 倍效能提升。

「我其實很享受軟體開發的最後這段日子。雖然有一絲悲傷，但知道我們已接近尾聲，這讓它再次變得新奇且甜美。」—— Moxie Marlinspike（Signal 創辦人）

在什麼樣的情況下，我們才不會在 2026 年底前迎來超越人類的編碼員？

^註：作為 Claude Code 的創作者，Boris 顯然有動力去推廣它。

^更新：在看到 Daniel Kokotajlo 的回答並進一步思考後，我應該澄清，如果情況大致保持目前的趨勢，即使翻倍時間為 5 個月，我們也要到 2029 年 4 月才能以 80% 的可靠性完成為期 1 個月的任務。參見此處的完整評論。

^參見我 2021 年寫的關於自我改進 {人類 + AI} 系統的舊文，或這段解釋 Tom Davidson 完整起飛模型的影片，以獲得更多直覺。

^Boris 剛在 X 上寫道：「[...] 在過去的 30 天裡，我對 Claude Code 的貢獻 100% 是由 Claude Code 編寫的。」