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

所以我的做法其實是一種策略。越來越多人感覺到寫程式這件事已經被 AI 徹底改變，卻不知道自己該怎麼辦——到底能不能真的用一種完全不同的方式開始寫程式，不再把程式碼本身當成主要的產出。他們甚至會覺得這樣做好像背叛了自己的專業。所以我的用意就是站出來說：「看看我，我會寫程式，你們知道的，我不是躲在 AI 背後才敢說話：但時代真的變了，這不是你的弱點，也不是你被 AI 洗腦了。只是我們的領域，正在往一個不可思議*而且*痛苦（卻也充滿樂趣）的方向演化而已。」

這就是為什麼我昨天在 X 上說，我認為現在有許多程式設計師之所以未能發揮本來可以有的影響力，就是因為他們還在盯著程式碼看。我是真心這麼認為的。先說清楚，這不是叫你去 vibe coding，隨口要個最終成品就算了。重點是：如果你能掌控軟體背後的想法，一直盯著程式碼本身看，反而是事倍功半，甚至常常是白費功夫。原因如下：

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

掌控想法。你還記得《人月神話》裡的這句話嗎？一本 70 年代的書，對當前軟體時代的描述，竟然比 2000 到 2020 年間的許多論述都還要貼切。為什麼那些現在跳出來抗議 AI 的人，當初對過去十年軟體的慘況卻無動於衷？在 AI 出現前這幾年，我們所達到的粗製濫造的程度，簡直難以置信。我再跟你說一件事。什麼是粗製濫造？用 DwarfStar，我以完全自動化的方式為兩個 LLM（DeepSeek v4 和 GLM 5.2）實作了推論，但：你自己試試看就會發現，你沒辦法只是說一句「幫我實作 XYZ」然後就期待它能跑。你必須理解背後的原理是什麼、最好的設計是什麼、要怎麼達到一定的效能。接著我為了驗證正確性，把這個實作和其他系統拿來比較，發現其他實作有時反而包含更多錯誤。我進一步研究後發現，本地推論的世界充滿了細微且會累積、進而破壞模型輸出的錯誤，例如 attention 實作上的問題，在上下文超過某個長度後會導致效能下滑，因為 indexed attention 的實作是壞的（舉例來說，做了比實際需要更多的工作），諸如此類。這是一個對開發者極不友善的領域：領域本身極其複雜、變化飛快，每天都有在推論圖上略有不同的新模型被釋出。面對這種情況，AI 幫上了大忙。有很多領域，嚴謹的工程（在設計層面）和測試，*遠比*親手寫一個 GPU kernel（或去讀它）來得好。所以我們能確定，那些抗拒大多不是出於意識形態嗎？

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

Fable 和 GPT 5.6 對 sorted sets 節省記憶體的審查，將會比我的審查找出更多錯誤和細微的 race condition。但我還是會去做。不過對絕大多數的軟體專案來說，這整套做法已經沒有意義了。轉而去掌控想法吧。專注在品質、測試，以及對你想交付的軟體要有清楚的構想。世界已經變了，這很痛苦，但也充滿了機會，讓我們去改善那個早已徹底腐爛的軟體世界。

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