“手寫代碼已不再必要！”Redis之父罕見表態(tài)：AI將永遠改變編程，網(wǎng)友質(zhì)疑：我怎么沒遇到這么好用的AI！

編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

當(dāng) AI 開始提筆寫代碼，程序員的飯碗真的要被搶了嗎？

關(guān)于這個話題，科技圈大佬們的看法堪稱“神仙打架”。

Google 首席工程師 Jaana Dogan 曾分享過一個頗具沖擊力的對比：“谷歌團隊耗時一整年攻堅的工作成果，Anthropic 的 Claude Code 僅用 1 小時，就拿出了一份方向高度一致的方案?！?這并不是“AI 寫幾行腳本”的層面，而是直接對工程效率與組織協(xié)作方式的挑戰(zhàn)。

而 Linux 之父 Linus Torvalds 則給出了截然不同的視角。他坦言：“就我個人來說，因為我是維護者，代碼審查對我非常重要，所以我對‘用 AI 寫代碼’反而沒那么感興趣。很多人一談編程就想到用 AI 寫代碼，但在我看來，這遠沒有‘用 AI 來幫助維護代碼’有意思?！?話雖如此，這位嘴上說著 “不感興趣” 的大佬，不久前卻悄悄體驗了一把 Vibe coding，還順勢搗鼓出一個全新的開源項目，身體力行地打破了自己立下的 “flag”。

如果說 Jaana Dogan、 Linus 的態(tài)度仍然偏向克制與保留，那么 Redis 之父 Salvatore Sanfilippo（網(wǎng)名 antirez）的表態(tài)，則直接拋出了一個顛覆性論斷：

在絕大多數(shù)情況下，寫代碼本身已經(jīng)不再是必要的工作了。

在他看來，倘若開發(fā)者一味抵觸 AI，很可能會錯過這場已經(jīng)發(fā)生的行業(yè)變革。

這個觀點瞬間戳中了無數(shù)程序員的痛點——多少個挑燈夜戰(zhàn)的夜晚，多少行反復(fù)調(diào)試的代碼，都是自己實打?qū)嵉男难?，如今機器卻能輕松代勞，心里難免五味雜陳。

對此，antirez 發(fā)出了靈魂拷問：

“當(dāng)年你熬夜敲代碼，只為見證項目成功跑通的那一刻，內(nèi)心真正燃燒的熱情是什么？答案其實是‘創(chuàng)造’。既然 AI 能幫我們更快抵達創(chuàng)造的終點，又何樂而不為呢？”

這番犀利的言論，正出自他撰寫的文章《不要被反 AI 的炒作所蒙蔽》。文章一經(jīng)發(fā)布，立刻在科技圈掀起軒然大波，截至目前，瀏覽量已突破 30 萬，熱度持續(xù)居高不下。接下來，我們就一起來看看 antirez 的最新觀點。

從“手寫一切”到和“模型一起寫”

在文章中，antirez 率先明確表明了自己的立場：他一直熱愛親手寫代碼，追求簡潔、可讀、帶有個人風(fēng)格的軟件設(shè)計。

“可以說，我的整個職業(yè)生涯，都是在努力寫出結(jié)構(gòu)良好、盡可能簡潔、以‘人的痕跡’為核心特征的軟件。我也一直希望生活在一個不會遺忘弱者的社會里。”

他甚至開玩笑地坦言，如果 AI 最終沖擊現(xiàn)有經(jīng)濟結(jié)構(gòu)，迫使社會重新思考財富分配，他也無所謂：

“我并不希望 AI 在經(jīng)濟層面取得成功——但如果現(xiàn)有的體系因此被顛覆，我并不在意。老實說，如果這能推動一次大規(guī)模的財富再分配，我甚至?xí)械礁吲d?！?/blockquote>

當(dāng)然，這番話中帶著幽默，但他也強調(diào)：如果因為自己對軟件和社會的理想，就扭曲對現(xiàn)實的判斷，“那我既不尊重自己，也不尊重理性?！?/p>

他進一步說道——“事實就是事實：AI 將永遠改變編程。”

“親自去寫所有代碼已經(jīng)不再是一個理性的選擇”

事實上，這場轉(zhuǎn)變并非一蹴而就。

早在 2020 年，antirez 就離開工作崗位，開始構(gòu)思一部探討 AI、普遍基本收入以及自動化時代社會適應(yīng)問題的小說。到 2024 年末，他進一步把注意力轉(zhuǎn)向現(xiàn)實技術(shù)實踐，開設(shè)了一個專門討論 AI 編程應(yīng)用及其社會、經(jīng)濟影響的 YouTube 頻道。

回顧這段經(jīng)歷，他坦言：盡管很早就意識到 AI 會對編程產(chǎn)生深遠影響，他曾認為，這個轉(zhuǎn)折點至少還需要幾年才會到來。然而，最近的實際體驗讓他改變了判斷。

他指出，隨著最先進的大語言模型不斷成熟，AI 已經(jīng)能夠在幾乎不需要人工干預(yù)的情況下，獨立完成中等規(guī)模的子任務(wù)，甚至是完整的中等體量項目——前提是開發(fā)者能給出清晰的目標(biāo)描述，明確希望得到的結(jié)果。

在 antirez 看來，模型的表現(xiàn)很大程度上取決于兩點：

• 編程任務(wù)類型——任務(wù)越獨立、越容易用文本完整描述，模型表現(xiàn)就越好。系統(tǒng)編程就是典型例子。

• 開發(fā)者能力——能否在腦中建立對問題的清晰抽象，并準(zhǔn)確傳達給模型。

基于這些觀察，他得出了一個相對激進、但越來越難以回避的結(jié)論：在當(dāng)下的技術(shù)條件下，對大多數(shù)項目來說，親自去寫所有代碼已經(jīng)不再是一個理性的選擇——除非你只是為了享受寫代碼本身的樂趣。

Redis 之父自己的親身體驗

antirez 并沒有泛泛談?wù)?AI 能“提高效率”，而是用自己的具體經(jīng)歷說明變化到底發(fā)生在什么地方。

就在過去一周，他僅僅通過不斷向模型提示、偶爾檢查生成代碼并給出方向性指導(dǎo)，就在幾小時內(nèi)完成了原本可能需要數(shù)周才能完成的一些事情：

1. 改進 linenoise 庫。

   他修改了自己的 linenoise 庫，使其支持 UTF-8，并為行編輯功能構(gòu)建了一套測試框架。這個框架使用模擬終端，能夠精確報告每個字符單元格的實際顯示內(nèi)容。antirez 解釋道，這一直是他想做的事情，但過去很難為一個個人小項目投入如此多的測試成本?，F(xiàn)在，只需描述自己想法，AI 就能直接在代碼中實現(xiàn)，一切就變得不一樣了。

2. 修復(fù) Redis 測試中的瞬態(tài)失敗。

   所謂瞬態(tài)失敗，指的是由于網(wǎng)絡(luò)波動、服務(wù)器暫時不可用、連接池耗盡、高并發(fā)下的資源爭搶或部分節(jié)點故障等原因，導(dǎo)致 Redis 命令執(zhí)行短暫失敗。這些問題極其令人頭疼，涉及各種時間相關(guān)的問題、TCP 死鎖條件等等。Claude Code 會持續(xù)反復(fù)運行測試，直到復(fù)現(xiàn)問題為止，然后檢查各個進程的狀態(tài)，理解到底發(fā)生了什么，最后修復(fù)了這些 bug。

3. 構(gòu)建純 C 實現(xiàn)的 BERT 推理庫。

   antirez 透露，當(dāng)自己有這樣的想法時，僅用了 5 分鐘，Claude Code 就完成了這個庫，輸出結(jié)果與 PyTorch 一致，速度只慢了大約 15%?？偞a量大約 700 行，同時還生成了一個用于轉(zhuǎn)換 GTE-small 模型的 Python 工具。

4. 復(fù)現(xiàn) Redis Streams 內(nèi)部實現(xiàn)。

   在過去幾周，antirez 對 Redis Streams 做了一些修改，并寫了一份設(shè)計文檔。他把文檔交給 Claude Code，大約 20 分鐘內(nèi)就復(fù)現(xiàn)了全部實現(xiàn)。主要耗時反而是他自己檢查結(jié)果、確認并允許模型執(zhí)行必要的操作。

「在這樣的現(xiàn)實面前，你幾乎不可能視而不見。在絕大多數(shù)情況下，寫代碼本身已經(jīng)不再是必要的工作了」，antirez 說道，「現(xiàn)在真正更有意思的，是理解“要做什么”，以及“應(yīng)該如何去做”——而在第二點上，大語言模型同樣是非常出色的伙伴?！?/p>

對于 AI 是否能帶來經(jīng)濟收益、股市是否會崩盤，antirez 認為長期來看并不重要?！蹦硞€獨角獸公司的 CEO 說了什么令人不適或荒唐的話，也并不重要。無論如何，編程已經(jīng)被永久性地改變了?！?/p>

antirez 對自己親手寫的代碼被大模型“接手”持坦然態(tài)度，甚至感到欣慰。

因為在我看來，這正是我一生所做事情的延續(xù)：讓代碼、系統(tǒng)和知識更加民主化。大語言模型將幫助我們更快地寫出更好的軟件，也將讓小團隊擁有與大公司競爭的機會——就像 90 年代的開源軟件所做的那樣。

然而，antirez 也指出，AI 這項技術(shù)的重要性決定了它不能只掌握在少數(shù)幾家公司手中。目前，不同團隊在預(yù)訓(xùn)練和強化學(xué)習(xí)方面各有優(yōu)勢，但開放模型——尤其是中國的一些模型——仍在與封閉實驗室的前沿模型競爭，即使暫時略有差距。AI 在一定程度上保持了民主化，但這種狀態(tài)能否長期維持，仍不確定。

他對技術(shù)集中化表示擔(dān)憂，同時也相信，大規(guī)模神經(jīng)網(wǎng)絡(luò)本身具備做出驚人成果的能力，而最前沿的 AI 并不存在多少“不可復(fù)制的魔法”，否則難以解釋 OpenAI、Anthropic 和 Google 多年來結(jié)果如此接近。

作為一名程序員，antirez 稱，自己現(xiàn)在比以往任何時候都更想寫開源代碼。他計劃維護一些因時間原因被擱置的倉庫，把 AI 引入 Redis 工作流，繼續(xù)改進 Vector Sets，并像處理 Streams 一樣，逐步優(yōu)化其他數(shù)據(jù)結(jié)構(gòu)。

與此同時，他對可能因此失業(yè)的人表示擔(dān)憂。企業(yè)最終會走向哪種路徑仍不明確：是雇傭更多人、構(gòu)建更多產(chǎn)品，還是削減薪酬成本，僅保留少數(shù)擅長提示模型的程序員？在其他行業(yè)，人類甚至可能被完全取代，這讓他感到不安。

針對社會層面的影響，antirez 表示：”創(chuàng)新一旦發(fā)生，就無法被收回。我認為，我們應(yīng)該通過投票支持那些真正理解正在發(fā)生什么、并愿意為失業(yè)人群提供支持的政府。隨著失業(yè)人數(shù)增加，政治壓力也會隨之增大，促使更多人支持能夠提供一定保障的政策?！?/p>

此外，antirez 也對 AI 的積極影響抱有期待，比如推動科學(xué)進步、減少人類生活中的痛苦，而這種改善并不總是直接帶來幸福，但確實能提升人類整體生存狀態(tài)。

開發(fā)者質(zhì)疑：自己的 AI 為什么沒那么好用？

然而，antirez 的判斷并非所有人都認同。

在 Hacker News 上，這篇文章引發(fā)了長時間討論。一些開發(fā)者指出，目前的 AI 在復(fù)雜系統(tǒng)設(shè)計、長期維護和邊界條件處理上依然存在明顯不足。

正如 HN 熱評第一的 totallykvothe 寫道：

我一直無法理解這樣一種說法：AI 現(xiàn)在已經(jīng)可以自動化完成非簡單的編程任務(wù)。

自從 GPT-3.5 發(fā)布以來，我?guī)缀醭掷m(xù)不斷地在嘗試這件事，幾乎用遍了當(dāng)下所有最先進的模型，從 GPT-5.1 Codex Max 到 Opus 4.5，沒有例外。

每一次，AI 確實都能給我一個“能跑起來”的結(jié)果。但問題在于，當(dāng)我開始對這些代碼進行自我審查，準(zhǔn)備提交給同事評審時，最終幾乎都會重寫其中大約 70% 的內(nèi)容。AI 方案里有太多細節(jié)處理得不到位，很多時候甚至存在根本性的架構(gòu)問題，以至于無論我怎么繼續(xù)通過 prompt 去修正，都很難補救——哪怕我在整個原型階段都深度參與、一步步引導(dǎo)。

到最后，我只能得出兩個結(jié)論之一：

1）要么是我真的不擅長寫 prompt?？蓡栴}是，我算是我身邊最早一批把 AI 用在編碼里的開發(fā)者之一，而且已經(jīng)持續(xù)使用很多年了，這個解釋我自己都很難接受。

2）要么就是其他人沒我這么挑剔，或者他們的代碼評審文化沒那么嚴格，更容易放過質(zhì)量一般的代碼。

我實在想不出還有什么別的解釋。

作為背景說明：我目前維護的是一個有 15 年歷史的 Java Spring + React 的 Web 應(yīng)用（其中還有一些老頁面仍然使用 Thymeleaf）。系統(tǒng)包含多個子服務(wù)、兩套獨立的數(shù)據(jù)庫，同時還需要與客戶的硬件設(shè)備進行雙向通信。

這當(dāng)然不是一個簡單的項目，但即便如此，我也很難相信它會比大多數(shù)企業(yè)級、遺留系統(tǒng)復(fù)雜到哪里去……

這種經(jīng)歷讓不少開發(fā)者都感同身受。另一位網(wǎng)友補充道：

“到目前為止，我向大語言模型提出過的所有技術(shù)問題，只要是我自己已經(jīng)知道答案的，幾乎無一例外都會在某些方面出現(xiàn)明顯錯誤。

我經(jīng)常遇到的另一個問題，是錯誤率與響應(yīng)速度之間的權(quán)衡。那些速度最快的前沿模型，錯誤頻率高得驚人，錯誤程度也相當(dāng)嚴重，以至于我根本不敢把它們當(dāng)作可靠的搜索工具來用；而那些更大、更慢、花更多時間“思考”的模型，雖然給出的結(jié)果確實更好一些，但等待時間又長到讓我覺得，與其等它們回復(fù)，不如直接自己去做一次網(wǎng)頁搜索來得更快。

在我剛開始接觸某個新領(lǐng)域，或者還沒完全熟悉某個 API、語言或相關(guān)文檔之前，這些模型確實能發(fā)揮一定作用。但一旦我花了些時間完成“入門”，哪怕只是順著它們給出的鏈接自己看過幾次資料，后續(xù)再查問題時，直接自己搜索反而更高效?！?/p>

除此之外，還有開發(fā)者擔(dān)心，過度依賴 AI 可能削弱工程師對系統(tǒng)的整體理解。有人指出，這類工具更適合原型開發(fā)或中小項目，而非嚴肅的生產(chǎn)環(huán)境。

這些質(zhì)疑并非毫無道理，反而說明，AI 在工程實踐中的角色仍在快速演化，真正的價值和局限都還有待進一步驗證。

逃避并不會讓變化消失

即便如此，antirez 的態(tài)度依然明確：無論你認為什么才是“正確的道路”，拒絕眼前正在發(fā)生的事情，并不能讓你掌控它。

他進一步指出：

“也許你會覺得，自己曾經(jīng)那么努力學(xué)習(xí)編程，而現(xiàn)在機器卻替你做了這件事。但當(dāng)年熬夜寫代碼，只為了看到項目跑起來時，你真正追求的是什么？是‘創(chuàng)造’。現(xiàn)在，如果能找到有效使用 AI 的方式，你能夠創(chuàng)造得更多，也創(chuàng)造得更好。那種樂趣依然存在，絲毫未減?！?/p>

對此有網(wǎng)友表示認同。HN 用戶 daxfohl 寫道：

“我同意你的看法，但想補充一點：過去幾個月里，AI 發(fā)展出現(xiàn)了一次明顯躍遷，現(xiàn)在這已經(jīng)是一種不可避免的趨勢。曾經(jīng)我還在期待 AI 會撞上‘天花板’，到那時我們回頭看，會覺得‘它們怎么可能取代程序員’這種想法很可笑。但現(xiàn)在，這件事看起來只是時間問題。

從更長遠來看，我認為未來一到兩年內(nèi)，Anthropic 和 OpenAI 會把產(chǎn)品從‘編碼助手’升級為‘工程團隊替代方案’。這些產(chǎn)品可能內(nèi)置完整的標(biāo)準(zhǔn)工具和框架，也會提供接口接入其他技術(shù)棧。它們的直接客戶，可能不再是單個工程師，而是沒有深度技術(shù)經(jīng)驗的產(chǎn)品團隊。

我還預(yù)計，單體架構(gòu)可能會回潮?，F(xiàn)在采用微服務(wù)，很大程度上是為了并行開發(fā)和減少沖突。但如果 AI 能顯著加快開發(fā)周期，這種優(yōu)勢就沒那么重要；反而把業(yè)務(wù)邏輯放在一個統(tǒng)一‘容器’里，更便于 AI 整體分析和理解。”

antirez 最后提醒——「跳過 AI，不會對你或你的職業(yè)生涯有任何幫助。相比快速體驗幾分鐘，他建議花幾周時間，謹慎而深入地測試這些新工具。如果一開始不適合自己，可以隔幾個月再嘗試一次?！?/p>