（來源：麻省理工科技評論）

如果你現(xiàn)在去問一個程序員怎么看 AI 編程，可能會得到兩種截然不同的回答。

可能有人認(rèn)為，AI 編程將把軟件開發(fā)者的生產(chǎn)力推到前所未有的高度；也可能有人批評它只會源源不斷地產(chǎn)出設(shè)計糟糕的代碼，不僅耗盡開發(fā)者的注意力，還會讓軟件項目在長期維護(hù)上埋下嚴(yán)重隱患?，F(xiàn)階段，我們很難說哪種判斷更接近事實。

在科技巨頭向大語言模型（LLM）投入數(shù)十億美元之后，編程已成為這項技術(shù)最受推崇的殺手級應(yīng)用。微軟 CEO 薩蒂亞·納德拉和谷歌 CEO 桑達(dá)爾·皮查伊都聲稱，他們的公司如今大約四分之一的代碼由 AI 生成。3 月，Anthropic 的 CEO 達(dá)里奧·阿莫代伊還預(yù)測，六個月內(nèi) 90% 的代碼都將由 AI 編寫。

這種判斷聽起來似乎既誘人又順理成章：代碼也是一種語言，我們需要大量代碼，而人工編寫的成本很高；并且代碼是否可用也很容易驗證，只要運(yùn)行程序就能立刻看出它是否能正常工作。

科技公司的高管們看中 AI 突破人類效率瓶頸的潛力，正在推動工程師更積極地?fù)肀?AI 驅(qū)動的未來。《麻省理工科技評論》在與 30 多位開發(fā)者、科技公司高管、分析師與研究人員交流后發(fā)現(xiàn)，實際上現(xiàn)實遠(yuǎn)沒有宣傳中那么簡單。

隨著一次次碰到技術(shù)瓶頸，一部分一線開發(fā)者的最初熱情正在消退。而隨著越來越多研究顯示，所謂的生產(chǎn)力提升可能只是“幻象”，也有人開始質(zhì)疑：皇帝是不是根本沒穿衣服。

不過，進(jìn)步速度本身也讓問題變得更復(fù)雜。新模型的發(fā)布的節(jié)奏緊密不斷，這些工具的能力與脾氣都在不停演化；而它們的實際效果，往往取決于具體任務(wù)，以及組織圍繞它們搭建的流程與結(jié)構(gòu)。所有這些因素疊加起來，讓開發(fā)者不得不在預(yù)期與現(xiàn)實之間的混亂落差中摸索前行。

借用狄更斯的名言來形容 AI 編程：這是最好的時代，還是最壞的時代？

也許兩者都是。

一個高速變化的領(lǐng)域

如今，幾乎沒有開發(fā)者能完全繞開 AI 編程工具。相關(guān)產(chǎn)品已經(jīng)多到讓人難以分辨優(yōu)劣：既有 Anthropic、OpenAI、Google 這樣的模型開發(fā)者提供的工具，也有 Cursor、Windsurf 這類公司把模型封裝進(jìn)打磨精致的代碼編輯軟件里。根據(jù) Stack Overflow 的 2025 年開發(fā)者調(diào)查，這些工具正被迅速采用：65% 的開發(fā)者如今至少每周使用一次。

AI 編程工具大約在 2016 年出現(xiàn)，但隨著 LLM 的到來得到了加速。早期版本幾乎只是給程序員做自動補(bǔ)全，提示下一步該敲什么；而今天，它們已經(jīng)可以分析整個代碼庫、跨文件編輯、修復(fù) bug，甚至生成解釋代碼如何工作的文檔。所有這些都可以通過聊天界面，用自然語言提示來引導(dǎo)完成。

智能體（agents）是 AI 編程的最新前沿：這類由 LLM 驅(qū)動的自主編程工具可以接收一個抽象的目標(biāo)，然后獨(dú)立構(gòu)建完整程序。實現(xiàn)這一躍遷的關(guān)鍵，是最新的推理模型（reasoning models）：它們能把復(fù)雜問題拆成步驟逐一解決，更重要的是，還能訪問外部工具來完成任務(wù)。Anthropic 編程智能體 Claude Code 的負(fù)責(zé)人 Boris Cherny 說：“正因為如此，模型才是真正在寫代碼，而不是只會聊編程。”

在軟件工程基準(zhǔn)測試（用來衡量模型表現(xiàn)的標(biāo)準(zhǔn)化測試）上，這些智能體取得了令人印象深刻的進(jìn)展。OpenAI 在 2024 年 8 月推出 SWE-bench Verified 基準(zhǔn)，為評估智能體在開源代碼庫中修復(fù)真實 bug 的成功率提供了一種方法；當(dāng)時最強(qiáng)模型只能解決 33% 的問題。一年后，領(lǐng)先模型的得分已穩(wěn)定超過 70%。

2 月，OpenAI 創(chuàng)始成員、特斯拉前 AI 負(fù)責(zé)人 Andrej Karpathy 提出了 vibe coding（氛圍編程）一詞，指的是一種做法：人們用自然語言描述軟件需求，讓 AI 編寫、完善并調(diào)試代碼。社交媒體上充斥著認(rèn)同這種愿景的開發(fā)者，他們宣稱自己的生產(chǎn)力獲得了巨大提升。

但盡管一些開發(fā)者和公司報告了這樣的效率提升，更“硬”的證據(jù)卻更為復(fù)雜。來自 GitHub、Google 和 Microsoft（它們也都是 AI 工具供應(yīng)商）的早期研究發(fā)現(xiàn)，開發(fā)者完成任務(wù)速度快了 20% 到 55%。不過，咨詢公司貝恩（Bain & Company）在 9 月的一份報告中形容，真實世界的節(jié)省效果“并不顯著”。

開發(fā)者分析公司 GitClear 的數(shù)據(jù)顯示，自 2022 年以來，大多數(shù)工程師產(chǎn)出的“更耐久的代碼”（即不會在幾周內(nèi)被刪除或重寫的代碼）大約增加了 10%，這很可能得益于 AI。但這種提升伴隨著多項代碼質(zhì)量指標(biāo)的明顯下滑。Stack Overflow 的調(diào)查也發(fā)現(xiàn)，人們對 AI 工具的信任和正面情緒首次出現(xiàn)顯著下降。

更具挑釁意味的是，非營利研究機(jī)構(gòu) Model Evaluation & Threat Research（METR）在 7 月的一項研究顯示：經(jīng)驗豐富的開發(fā)者認(rèn)為 AI 讓他們快了 20%，但客觀測試表明他們實際上慢了 19%。

日益增長的幻滅感

對軟件咨詢公司 Substantial 的首席開發(fā)者 Mike Judge 來說，METR 的研究戳中了他的痛點(diǎn)。他曾是 AI 工具的熱情早期用戶，但隨著時間推移，他越來越受挫于這些工具的局限，以及它們對自己生產(chǎn)力帶來的有限提升。他說：“我會跟人抱怨，因為我覺得，它確實在幫我，但我就是搞不清怎樣才能讓它真正大幅幫到我。”他還說：“我總覺得 AI 很笨，但也許只要我找到正確的‘咒語’，就能把它騙得聰明一點(diǎn)?！?/p>

朋友問起時，Judge 曾估計這些工具大概能讓他提速 25%。所以，當(dāng)他在 METR 研究中看到開發(fā)者給出類似估計時，決定親自測試。連續(xù)六周，他先估算一項任務(wù)需要多久，再拋硬幣決定用 AI 還是手寫代碼，然后計時。令他驚訝的是，AI 讓他的速度中位數(shù)下降了 21%，與 METR 的結(jié)果如出一轍。

這促使 Judge 自己動手做了一次數(shù)據(jù)分析。他推理說，如果這些工具真的讓開發(fā)者大幅提速，那么應(yīng)該能看到新應(yīng)用、網(wǎng)站注冊、電子游戲，以及 GitHub 項目數(shù)量出現(xiàn)爆發(fā)式增長。他花了幾個小時、又花了幾百美元，分析所有公開可得的數(shù)據(jù)，結(jié)果發(fā)現(xiàn)各項曲線幾乎都“橫著走”。

Judge 說：“這難道不應(yīng)該向右上方飆升嗎？這些圖里所謂的‘冰球桿曲線’在哪里？我以為大家都變得異常高產(chǎn)。”他認(rèn)為，一個顯而易見的結(jié)論是：對大多數(shù)開發(fā)者而言，AI 工具提供的生產(chǎn)力提升并不大。

接受《麻省理工科技評論》采訪的開發(fā)者總體上認(rèn)可 AI 工具擅長的地方有：生成樣板代碼（boilerplate code）（指幾乎無需修改、在多個地方重復(fù)使用的可復(fù)用代碼片段）、編寫測試、修復(fù) bug，以及向新開發(fā)者解釋陌生代碼。有幾位指出，AI 能通過提供一個并不完美的初版來幫助解決空白頁問題，從而激發(fā)開發(fā)者的思路。此外，它還可以讓非技術(shù)同事快速做出功能原型，減輕本就過載的工程師負(fù)擔(dān)。

這些任務(wù)往往枯燥，開發(fā)者通常樂于把它們交給工具。但其只占資深工程師工作量的一小部分。對于那些更復(fù)雜、真正體現(xiàn)工程師價值的難題，許多開發(fā)者告訴《麻省理工科技評論》，這些工具仍面臨顯著挑戰(zhàn)。

也許最大的問題在于，LLM 只能在上下文窗口（context window）里容納有限的信息，這本質(zhì)上就是它們的工作記憶。這意味著它們很難解析大型代碼庫，也容易在耗時更長的任務(wù)中忘記自己在做什么。Judge 說：“它會變得非常短視，只盯著眼前那一小塊。你讓它做十二件事，它會做完十一件，然后把最后一件給忘了。”

LLM 的這種“近視”，會讓人類程序員非常頭疼。LLM 針對某個問題給出的代碼，也許單獨(dú)運(yùn)行沒問題，但軟件由成百上千個相互連接的模塊組成。如果生成的模塊沒有考慮軟件的其他部分，很快就會導(dǎo)致代碼庫糾纏不清、前后不一致，讓人類難以理解，更重要的是難以維護(hù)。

傳統(tǒng)上，開發(fā)者會通過遵循既定傳統(tǒng)（conventions）來應(yīng)對這一點(diǎn)：也就是一些定義并不嚴(yán)格、但在不同項目與團(tuán)隊之間差異很大的編碼準(zhǔn)則。

GitClear 的 CEO Bill Harding 說：“AI 有一種壓倒性的傾向，即不理解一個代碼庫里已經(jīng)存在的既定傳統(tǒng)。于是，它很可能會自己想出一種略有不同的解法版本。”

模型也會直接出錯。和所有 LLM 一樣，編程模型容易產(chǎn)生幻覺，這是它們工作方式內(nèi)生的問題。但廣告技術(shù)公司 Mediaocean 的軟件工程總監(jiān) James Liu 說，因為它們輸出的代碼看起來非常像模像樣，錯誤反而更難被發(fā)現(xiàn)。把這些缺陷疊加起來，使用這些工具的體驗就很像拉一臺單臂老虎機(jī)的把手。Liu 說：“有些項目里，你能在速度或效率上得到 20 倍提升；但在另一些事情上，它會徹底翻車，然后花大量時間試圖讓它實現(xiàn)你想要的愿望，結(jié)果它就是做不到。”

Judge 懷疑，這正是工程師經(jīng)常高估生產(chǎn)力提升的原因。他說：“你會記住中大獎的時候；但是，你不會記得自己坐在那里往老虎機(jī)里塞籌碼塞了兩小時。”

如果開發(fā)者對任務(wù)并不熟悉，問題可能更嚴(yán)重。Judge 記得自己曾讓 AI 幫忙配置微軟的云服務(wù) Azure Functions，而他此前從未用過。他以為大概需要兩小時，但九小時后他放棄了。他說：“它不斷把我?guī)нM(jìn)一個又一個死胡同，而我對這個主題了解不夠，甚至沒法對它抱怨‘嘿，這完全不合邏輯’?！?/p>

技術(shù)債正在被快速堆高

達(dá)特茅斯學(xué)院工程創(chuàng)新教授 Geoffrey G. Parker 表示，開發(fā)者不斷在開發(fā)速度與代碼可維護(hù)性之間做權(quán)衡，從而產(chǎn)生所謂的“技術(shù)債（technical debt）”。每一次走捷徑都會增加復(fù)雜度，讓代碼庫更難管理，并累積需要通過重構(gòu)來償還的“利息”。隨著技術(shù)債越堆越高，新增功能與維護(hù)軟件都會變得更慢、更難。

Harding 說，在大多數(shù)項目里技術(shù)債的累積幾乎不可避免，但 AI 工具讓時間緊張的工程師更容易走捷徑。GitClear 的數(shù)據(jù)表明，這正在以規(guī)?；姆绞桨l(fā)生。自 2022 年以來，公司觀察到復(fù)制粘貼代碼的數(shù)量顯著上升，這表明開發(fā)者復(fù)用更多代碼片段，很可能來自 AI 的建議；與此同時，“代碼從一個地方移動到另一個地方”的數(shù)量下降得更厲害，而這種移動往往發(fā)生在開發(fā)者清理、整理代碼庫時。

代碼質(zhì)量檢查工具公司 Sonar 的 CEO Tariq Shaukat 說，隨著模型不斷改進(jìn)，它們生成的代碼變得越來越冗長、越來越復(fù)雜。這會減少明顯 bug 和安全漏洞的數(shù)量，但代價是代碼異味（code smells）增加，也就是更難精準(zhǔn)定位、卻會導(dǎo)致維護(hù)問題與技術(shù)債的缺陷。

Sonar 的最新研究發(fā)現(xiàn)，在領(lǐng)先 AI 模型生成的代碼中，這類問題占其發(fā)現(xiàn)問題的 90% 以上。Shaukat 說：“容易發(fā)現(xiàn)的問題正在消失，剩下的是更復(fù)雜、需要花時間才能找出來的問題。這正是我們目前對這個領(lǐng)域最擔(dān)心的地方，你幾乎會被哄進(jìn)一種虛假的安全感里?！?/p>

喬治城大學(xué)的安全研究員 Jessica Ji 表示，如果 AI 工具讓代碼越來越難維護(hù)，可能會引發(fā)嚴(yán)重的安全問題。Ji 說：“更新和修復(fù)越困難，代碼庫或任何一段代碼隨著時間推移變得不安全的可能性就越大。”

她說，還存在更具體的安全擔(dān)憂。研究人員發(fā)現(xiàn)了一類令人不安的“幻覺”：模型會在代碼里引用并不存在的軟件包。攻擊者可以利用這一點(diǎn)，創(chuàng)建同名但含有漏洞的軟件包，隨后模型或開發(fā)者可能在不知情的情況下把它們引入軟件中。

LLM 也容易遭受數(shù)據(jù)投毒攻擊（data-poisoning attacks）：黑客向模型訓(xùn)練所用的公開數(shù)據(jù)集注入數(shù)據(jù)，以不良方式改變模型行為，例如在特定短語觸發(fā)下生成不安全的代碼。Anthropic 在 10 月的一項研究中發(fā)現(xiàn)，無論模型規(guī)模多大，只需要 250 份惡意文檔就可能向 LLM 引入這種“后門”。

開始轉(zhuǎn)向擁抱 AI 的人

不過，盡管存在這些問題，現(xiàn)實可能已難以回頭。微軟旗下代碼托管平臺 GitHub 的首席運(yùn)營官 Kyle Daigle 說：“很可能，用鍵盤手工敲下每一行代碼的日子，正在迅速成為過去?！盙itHub 出品了一款流行的 AI 工具 Copilot（不要與微軟同名產(chǎn)品混淆）。

Stack Overflow 的報告發(fā)現(xiàn)，盡管人們對這項技術(shù)的不信任在加深，但過去三年里使用率仍快速且持續(xù)增長。Stack Overflow 的高級分析師 Erin Yepis 表示，這意味著工程師在利用這些工具時，對風(fēng)險保持相對清醒的認(rèn)知。報告還發(fā)現(xiàn)，高頻用戶往往更熱情；而超過一半的開發(fā)者并未使用最新的編程智能體，這也許解釋了為什么許多人仍對這項技術(shù)感到“不過如此”。

但最新工具也可能帶來醍醐灌頂?shù)捏w驗。軟件開發(fā)機(jī)構(gòu) Twenty20 Ideas 的 CTO Trevor Dilley 說，他曾覺得 AI 編輯器的自動補(bǔ)全有點(diǎn)價值，但一嘗試更復(fù)雜的事情就會失敗。后來在 3 月，他和家人度假時，讓剛發(fā)布的 Claude Code 去處理他的一個業(yè)余項目。它在兩分鐘內(nèi)完成了一項原本要四小時的任務(wù)，而且代碼比他自己寫的還要好。

他說：“我當(dāng)時就想，對我來說那一刻才是真正的轉(zhuǎn)折點(diǎn)。從這里開始就回不去了?！贝撕?，Dilley 聯(lián)合創(chuàng)辦了名為 DevSwarm 的初創(chuàng)公司，開發(fā)能夠調(diào)度多個智能體并行開發(fā)同一軟件的系統(tǒng)。

知名開源開發(fā)者 Armin Ronacher 認(rèn)為，難點(diǎn)在于這些工具的學(xué)習(xí)曲線“起步很淺，但路很長”。到 3 月為止他對 AI 工具仍不以為然，但 4 月他離開軟件公司 Sentry 去創(chuàng)業(yè)后，開始試驗智能體。“我基本上花了好幾個月什么都不干，就只做這個?！彼f，“現(xiàn)在，我寫的代碼里 90% 都是 AI 生成的?！?/p>

要達(dá)到這種程度需要大量試錯，以弄清楚哪些問題容易把工具絆倒，哪些問題它們能高效處理。Ronacher 說，只要有合適的護(hù)欄，當(dāng)下模型可以應(yīng)對大多數(shù)編程任務(wù)，但這些護(hù)欄往往與具體任務(wù)和項目高度相關(guān)。

獸醫(yī)人力公司 IndeVets 的 CTO Nico Westerdale 表示，要把這些工具用到極致，開發(fā)者必須放棄對每一行代碼的控制，把注意力轉(zhuǎn)向整體軟件架構(gòu)。他最近構(gòu)建了一個數(shù)據(jù)科學(xué)平臺，代碼量達(dá) 10 萬行，幾乎完全是通過提示模型來完成，而不是自己逐行編寫。

Westerdale 的流程從與模型進(jìn)行一段較長對話開始，用來形成“要做什么、怎么做”的詳細(xì)計劃；接著，他再引導(dǎo)模型一步步執(zhí)行。模型很少一次就能做對，需要持續(xù)“拽著走”，但 Westerdale 說，只要你強(qiáng)制它遵循明確的設(shè)計模式，模型就能生成高質(zhì)量、易維護(hù)的代碼。他會審查每一行，并表示這些代碼不比他過去產(chǎn)出的任何作品差：“我覺得它完全是革命性的。當(dāng)然，它也很讓人挫敗、很難、是一種不同的思考方式，而我們才剛剛開始適應(yīng)?！?/p>

但當(dāng)個體開發(fā)者逐漸學(xué)會有效使用這些工具時，要在大型工程團(tuán)隊里獲得一致的效果就難得多。Google 產(chǎn)品管理高級總監(jiān) Ryan J. Salva 說，AI 工具會放大工程文化中的優(yōu)點(diǎn)與缺點(diǎn)：如果你有強(qiáng)流程、清晰的編碼模式、定義明確的最佳實踐，它們就能大放異彩。

但如果你的開發(fā)流程本來就混亂，它們只會把問題放大。同樣關(guān)鍵的是把組織內(nèi)部的經(jīng)驗知識制度化、文檔化，讓模型能夠有效調(diào)用。Salva 說：“為了建立足夠的上下文、把那些口耳相傳的隱性知識從我們腦子里拿出來，有大量工作要做。”

加密貨幣交易所 Coinbase 一直高調(diào)談?wù)撟约簩?AI 工具的采用。CEO Brian Armstrong 在 8 月披露公司解雇了不愿使用 AI 工具的員工，一度引發(fā)關(guān)注。但 Coinbase 的平臺負(fù)責(zé)人 Rob Witoff 告訴《麻省理工科技評論》，盡管他們在某些方面看到了生產(chǎn)力的巨大提升，但整體效果卻并不均衡。對重構(gòu)代碼庫、編寫測試這類更簡單的任務(wù)，AI 驅(qū)動的工作流最高能實現(xiàn) 90% 的提速；但對其他任務(wù)，提升更有限，而且改造既有流程帶來的擾動往往會抵消編碼速度的增長，Witoff 說。

其中一個因素是，AI 工具讓初級開發(fā)者能夠產(chǎn)出更多代碼。像幾乎所有工程團(tuán)隊一樣，這些代碼必須由其他人（通常是更資深的開發(fā)者）進(jìn)行評審，以發(fā)現(xiàn) bug 并確保符合質(zhì)量標(biāo)準(zhǔn)。但如今被“卷”出來的代碼量之大，正在迅速壓滿中層人員審查變更的能力。Witoff 說：“我們幾乎每個月都在經(jīng)歷這樣一個循環(huán)：我們在技術(shù)棧更底層自動化了一件新事，于是更上層就承受更大壓力。然后我們又開始考慮把自動化應(yīng)用到更上層的部分?！?/p>

貝恩合伙人 Jue Wang 說，開發(fā)者真正用于寫代碼的時間只有 20% 到 40%，所以即便編碼本身大幅提速，整體收益也往往更為有限。開發(fā)者其余時間要用于分析軟件問題、處理客戶反饋、產(chǎn)品策略以及行政事務(wù)。Jue 表示，要獲得顯著的效率提升，公司可能也需要把生成式 AI 應(yīng)用于這些其他流程，但這仍在推進(jìn)之中。

飛速迭代

用智能體來編程與以往工作方式差異巨大，所以公司會遇到“長牙期”的問題并不意外。況且這些產(chǎn)品都很新，幾乎每天都在變。Anthropic 的 Cherny 說：“每隔幾個月模型就會變強(qiáng)，編碼能力會出現(xiàn)一次大的階躍式提升，你就必須重新校準(zhǔn)自己的使用方式?！?/p>

例如，Anthropic 在 6 月為 Claude 引入了內(nèi)置的規(guī)劃模式（planning mode），后來也被其他提供商效仿。10 月，公司又讓 Claude 在需要更多上下文或面對多種可行解法時向用戶提問。Cherny 指出，這有助于它避免“直接自作主張地認(rèn)為某條路徑最好”的傾向。

最重要的是，Anthropic 增加了一些功能，讓 Claude 更擅長管理自己的上下文。Cherny 說，當(dāng)它接近工作記憶的上限時，會自動總結(jié)關(guān)鍵細(xì)節(jié)，并基于這些總結(jié)開啟一個新的上下文窗口，從而在效果上擁有一個“無限”的窗口。Claude 還可以調(diào)用子智能體（sub-agents）處理更小的任務(wù)，這樣它就不必把項目的所有方面都同時裝在“自己腦子里”。公司聲稱，其最新模型 Claude 4.5 Sonnet 現(xiàn)在可以連續(xù)自主編碼超過 30 小時，而不會出現(xiàn)明顯的性能衰減。

軟件開發(fā)中的新方法也可能繞開編程智能體的其他缺陷。MIT 教授 Max Tegmark 提出一種他稱為 vericoding 的概念，可能讓智能體從自然語言描述出發(fā)生成完全沒有 bug 的代碼。它基于形式化驗證（formal verification）方法：開發(fā)者為軟件建立數(shù)學(xué)模型，從而無可辯駁地證明其功能正確。這種方法用于飛行控制系統(tǒng)、密碼學(xué)庫等高風(fēng)險領(lǐng)域，但由于成本高、耗時長，一直限制了其更廣泛的應(yīng)用。

Tegmark 說，LLM 數(shù)學(xué)能力的快速提升帶來一個誘人的可能性：模型不僅能產(chǎn)出軟件，還能給出無 bug 的數(shù)學(xué)證明。“你只要給出規(guī)格說明，AI 就會返回可被證明正確的代碼，”他說，“你不需要碰代碼，甚至都不必看代碼?！?/p>

根據(jù) Tegmark 團(tuán)隊一項未經(jīng)同行評審的研究，在 Dafny（為形式化驗證設(shè)計的語言）中大約 2,000 個 vericoding 題目上測試時，表現(xiàn)最好的 LLM 解決了超過 60%。這一結(jié)果是在“開箱即用”的通用 LLM 上實現(xiàn)的，Tegmark 預(yù)計，如果針對 vericoding 做專門訓(xùn)練，得分可能會快速提升。

但出乎意料的是，AI 生成代碼的速度也許反而能緩解可維護(hù)性的擔(dān)憂。商業(yè)軟件巨頭 Intuit 的首席工程師 Alex Worden 指出，維護(hù)之所以困難，往往是因為工程師在不同項目間復(fù)用組件，形成一團(tuán)依賴關(guān)系：一次改動會在整個代碼庫里引發(fā)連鎖反應(yīng)。過去復(fù)用代碼能節(jié)省時間，但在一個 AI 幾秒鐘就能生成數(shù)百行代碼的世界里，這種必須復(fù)用的動力已經(jīng)消失了。

因此，他主張可棄用代碼（disposable code）：每個組件都由 AI 獨(dú)立生成，不必考慮它是否遵循某種設(shè)計模式或約定；然后再通過 API（讓組件彼此請求信息或服務(wù)的一組規(guī)則）把它們連接起來。Worden 說，由于每個組件的內(nèi)部實現(xiàn)不依賴代碼庫的其他部分，就可以在不產(chǎn)生更大影響的情況下將其替換或移除。

他說：“行業(yè)仍在擔(dān)心人類如何維護(hù) AI 生成的代碼。但我懷疑人類還會看代碼、或在乎代碼多久。”

程序員的人才梯隊正在變窄

不過在可預(yù)見的未來，人類仍需要理解并維護(hù)支撐項目運(yùn)行的代碼。而 AI 工具最隱蔽、也最棘手的副作用之一，可能是能勝任這項工作的人才池在縮小。

一些早期證據(jù)表明，人們對 AI 摧毀崗位的擔(dān)憂可能并非空穴來風(fēng)。斯坦福大學(xué)最近的一項研究發(fā)現(xiàn)，在 2022 年到 2025 年間，22 到 25 歲軟件開發(fā)者的就業(yè)人數(shù)下降了近 20%，這與 AI 編程工具的興起時間相吻合。

資深開發(fā)者也可能遇到困難。游戲基礎(chǔ)設(shè)施開發(fā)公司 Companion Group 的工程師 Luciano Nooijen 在日常工作中大量使用 AI 工具，因為公司免費(fèi)提供；但當(dāng)他開始一個無法使用這些工具的副業(yè)項目時，他發(fā)現(xiàn)自己竟在過去本能完成的任務(wù)上頻頻卡殼。“我感覺自己很蠢，因為以前憑直覺就能做的事變成了手工操作，有時甚至很笨重。”Nooijen 說。

與運(yùn)動員仍要做基礎(chǔ)訓(xùn)練類似，他認(rèn)為保持編碼“手感”的唯一方式，就是定期練習(xí)那些苦活累活。這也是他基本棄用 AI 工具的原因，盡管他承認(rèn)背后也還有更深層的動機(jī)。

Nooijen 和《麻省理工科技評論》采訪到的其他開發(fā)者之所以抵觸 AI 工具，部分原因在于他們認(rèn)為：這些工具正在掏空工作中他們熱愛的那部分。“我進(jìn)入軟件工程行業(yè)，是因為我喜歡和計算機(jī)打交道，我喜歡讓機(jī)器按我想要的方式做事。”Nooijen 說，“但如果只是坐在那里，看著原本屬于我的工作被代勞，那一點(diǎn)也不好玩。”

https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/