回顧這個部落格過去的歷史。裡面有許多關於用 AI 寫程式的文章，其中幾篇早在 2024 年 1 月就已發表（例如：https://antirez.com/news/140）。畢竟，我算是個頗受肯定的程式設計師。我不需要像個渴求關注的老頭那樣硬要留在「圈內」刷存在感，我最近重新加入了 Redis，現在也正在開發一套用於本地 LLM 推論的開源軟體，在社群中獲得了不錯的迴響。那我為什麼還要一直做這種事，不斷說些大家不想聽的話？為什麼還要不斷預告未來程式設計的預設樣貌？因為我有一股迫切感，想為那些比我更沒準備好面對這場轉變的人降低衝擊——他們往往比我年輕，而且不像我，沒能預見許多事情的到來（早在 ChatGPT 問世前的 2022 年，我就出版了一本書，預告了許多如今已發生的事，以及其他我相信*將會*發生的事，所以我覺得自己這麼說並不算自以為是）。

所以，我這其實是個小把戲。越來越多人感覺到程式設計已經被 AI 徹底改變，卻不知道自己該怎麼做，不知道是否真的能以一種完全不同的方式開始寫程式，不再把程式碼本身當成主要的產出。他們覺得這麼做好像背叛了自己的專業。所以我的用意就是出面說：「看看我，我會寫程式，你們知道的，我不是躲在 AI 背後——然而，事情真的已經變了，這不是你的弱點，也不是因為你被 AI 洗腦了。這只是我們的領域正朝著一個不可思議*且*痛苦（卻也充滿喜悅）的方向演進而已。」

這就是為什麼我昨天在 X 上說，我認為現在有許多程式設計師之所以無法發揮應有的影響力，就是因為他們一直盯著程式碼。我是真心這麼認為的。請注意，這並不代表要用 vibe code(氛圍編程) 的方式，只對 AI 要求一個最終成品就算了。重點是：如果你能掌控軟體背後的想法，一直盯著程式碼本身反而是次佳、甚至毫無意義的做法。原因如下：

1. 你現在可以產生大量的程式碼，就算*不*把 LLM 程式碼冗長的問題算進去（那在很大程度上也是因為大多數人還不懂得如何好好下指令所致）。你怎麼可能每天審查五千行程式碼？
2. LLM 非常擅長寫出局部最佳化的程式碼，但在宏大的構想上就比較弱（不過正在進步中）。逐個函式、一行一行地掃描有什麼意義？相反地，你應該直接提示（prompt）你心中的設計，有時問問「那個部分的設計到底是怎麼做的？它是怎麼運作的？」，然後評估那個模型是否正確。這樣快得多。
3. 一天的工作時間只有八小時。如果你把時間花在讀程式碼上，就是一種取捨。你等於少做了在今天最重要的工作，也就是問自己：我用這個軟體到底想做什麼？接下來想往哪個方向走？同時，也要思考新的點子、功能、最佳化技巧。還要做大量的 QA。

掌控想法。你還記得 The Mythical Man Month（《人月神話》）裡的這句話嗎？嗯，一本七〇年代的書，對於當今軟體時代的描述，竟比 2000 年到 2020 年間所說的許多東西都還要貼切。為什麼那些現在抗議 AI 的人，當初沒有對過去十年軟體的慘況感到震驚？近年來，在 AI 出現之前，我們所觸及的 slop(粗製濫造) 程度，簡直難以置信。我再告訴你一件事。什麼是 slop？以 DwarfStar 為例，我用完全自動化的方式為兩個 LLM（DeepSeek v4 和 GLM 5.2）實作了推論，但：你自己試試看就會發現，你不能只是說「幫我實作 XYZ」然後就等著它能跑。你必須理解事情是怎麼運作的、什麼是最好的設計、如何達到一定的效能水準。接著我為了驗證正確性，把這個實作和其他系統做了比較，發現其他實作有時反而包含更多錯誤。我進一步研究後發現，本地推論的世界充滿了細微且會累積、進而破壞模型輸出的錯誤，例如 attention implementation(注意力機制實作) 中的問題，會在上下文超過某個長度後導致效能陡降，因為 indexed attention implementation 是壞的（例如，做了比實際需要更多的工作），諸如此類。這是一個極難駕馭、變化快速的領域，每天都有在 inference graph(推論圖) 上略有不同的新模型發布。對開發者來說，這是一場不公平的遊戲。嗯：AI 在這方面幫了大忙。有許多領域，嚴謹的工程（在設計端）與測試，*遠*比親手寫一個 GPU kernel(GPU 核心) 來得好（或是去讀它）。那麼，我們能確定大多數的抗拒不是出於意識形態嗎？

Matteo Collina（馬泰奧·柯林納）昨天在回覆我的貼文時問我：但你不是說過你會檢查所有為 Redis 產生的 AI 程式碼嗎？這的確是個好問題。是的，我是會檢查，但到了這個時間點，這是我*必須*做的事，卻也是我認為大多已經沒有意義的事，在 GPT 5.5 發布後就有一部分是如此，現在有了 Fable 和 GPT 5.6 Sol 之後更是如此。沒錯：我會找出一些我不喜歡的寫法，但如果我去打開其他 Redis 貢獻者寫的 Redis 檔案，裡面有*更糟*的情況，而且不是因為他們不是好的程式設計師，而是因為這只是品味問題。我寫的程式碼非常乾淨，因為我希望它易於閱讀，所以在實作 Redis Arrays 時我做了一些修改。現在為了 Redis sorted sets 節省 50% 記憶體的最佳化，我也正在做同樣的事，這是一個我很快就會提交的 PR。但我已經不覺得這還有用了。已經沒有人應該再去看這些程式碼，而應該只看程式碼背後所包含的想法。我之所以還繼續這麼做，是出於對使用者的尊重。Redis 到了這個階段已經是個被廣泛使用的東西，許多程式設計師會打開檔案、親手修改東西。但如果我能放手去做，你知道我會做什麼嗎？我會把花在審查上的所有時間，用來做更多的 QA、思考下一個最佳化的點子並付諸實行，以及利用 LLM 來撰寫一份 DESIGN.md 檔案，在其中用自然語言描述每一個資料結構，說明它所包含的想法、實作技巧與設計。那在未來將會有用得多。想修改 sorted sets 嗎？你打開檔案，讀懂設計，然後你就掌握了那些想法。你可以打開你的 agent 去問它該怎麼做，帶著正確的心智模型。這比審查程式碼有用太多了。

Fable 和 GPT 5.6 針對 sorted sets 節省記憶體的審查，將會比我的審查找出多得多、更細微的錯誤與 race conditions(競態條件)。但我還是會去做。然而，對於大多數的軟體專案來說，這一切已經沒有意義了。轉而專注於掌控想法吧。專注於品質、測試，以及對你想交付的軟體有清晰的想法。世界已經改變，這很痛苦，但也充滿了機會，去改善一個早已徹底腐壞的軟體世界。

我唯一的疑慮是關於那些經驗還不夠、無法建立心智模型的年輕程式設計師。我們還不知道，他們是否會需要非常透徹地理解某段程式碼是如何運作的，但我相信他們應該學習如何寫程式。然而，我不確定檢查 LLM 的輸出是否是他們該做的事。如果他們去學一種程式語言，並實作一個小型的 interpreter(直譯器)、小型的資料庫、hash table(雜湊表) 之類的東西，可能會有用得多。至於為客戶審查某個網站的那些 JavaScript 程式碼？見鬼，才別在那種鳥事上浪費時間。