1. 首頁 > 生活百科 > >

AI編程的落地真相調查，30位一線開發者給出了答案

人工智能ai軟件編程anthropic

AI編程的落地真相調查，30位一線開發者給出了答案

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

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

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

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

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

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

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

不過 ， 進步速度本身也讓問題變得更復雜 。 新模型的發布的節奏緊密不斷 ， 這些工具的能力與脾氣都在不停演化；而它們的實際效果 ， 往往取決于具體任務 ， 以及組織圍繞它們搭建的流程與結構 。 所有這些因素疊加起來 ， 讓開發者不得不在預期與現實之間的混亂落差中摸索前行 。
借用狄更斯的名言來形容 AI 編程：這是最好的時代 ， 還是最壞的時代？

也許兩者都是 。

一個高速變化的領域
如今 ， 幾乎沒有開發者能完全繞開 AI 編程工具 。 相關產品已經多到讓人難以分辨優劣：既有 Anthropic、OpenAI、Google 這樣的模型開發者提供的工具 ， 也有 Cursor、Windsurf 這類公司把模型封裝進打磨精致的代碼編輯軟件里 。 根據 Stack Overflow 的 2025 年開發者調查 ， 這些工具正被迅速采用：65% 的開發者如今至少每周使用一次 。

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

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

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

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

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

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

更具挑釁意味的是 ， 非營利研究機構 Model EvaluationThreat Research（METR）在 7 月的一項研究顯示：經驗豐富的開發者認為 AI 讓他們快了 20% ， 但客觀測試表明他們實際上慢了 19% 。

日益增長的幻滅感

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

朋友問起時 ， Judge 曾估計這些工具大概能讓他提速 25% 。 所以 ， 當他在 METR 研究中看到開發者給出類似估計時 ， 決定親自測試 。 連續六周 ， 他先估算一項任務需要多久 ， 再拋硬幣決定用 AI 還是手寫代碼 ， 然后計時 。 令他驚訝的是 ， AI 讓他的速度中位數下降了 21% ， 與 METR 的結果如出一轍 。
這促使 Judge 自己動手做了一次數據分析 。 他推理說 ， 如果這些工具真的讓開發者大幅提速 ， 那么應該能看到新應用、網站注冊、電子游戲 ， 以及 GitHub 項目數量出現爆發式增長 。 他花了幾個小時、又花了幾百美元 ， 分析所有公開可得的數據 ， 結果發現各項曲線幾乎都“橫著走” 。

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

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

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

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

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

傳統上 ， 開發者會通過遵循既定傳統（conventions）來應對這一點：也就是一些定義并不嚴格、但在不同項目與團隊之間差異很大的編碼準則 。

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

【AI編程的落地真相調查，30位一線開發者給出了答案】模型也會直接出錯 。 和所有 LLM 一樣 ， 編程模型容易產生幻覺 ， 這是它們工作方式內生的問題 。 但廣告技術公司 Mediaocean 的軟件工程總監 James Liu 說 ， 因為它們輸出的代碼看起來非常像模像樣 ， 錯誤反而更難被發現 。 把這些缺陷疊加起來 ， 使用這些工具的體驗就很像拉一臺單臂老虎機的把手 。 Liu 說：“有些項目里 ， 你能在速度或效率上得到 20 倍提升；但在另一些事情上 ， 它會徹底翻車 ， 然后花大量時間試圖讓它實現你想要的愿望 ， 結果它就是做不到 。 ”

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

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

技術債正在被快速堆高

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

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

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

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

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

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

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

開始轉向擁抱 AI 的人

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

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

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

他說：“我當時就想 ， 對我來說那一刻才是真正的轉折點 。 從這里開始就回不去了 。 ”此后 ， Dilley 聯合創辦了名為 DevSwarm 的初創公司 ， 開發能夠調度多個智能體并行開發同一軟件的系統 。

知名開源開發者 Armin Ronacher 認為 ， 難點在于這些工具的學習曲線“起步很淺 ， 但路很長” 。 到 3 月為止他對 AI 工具仍不以為然 ， 但 4 月他離開軟件公司 Sentry 去創業后 ， 開始試驗智能體 。 “我基本上花了好幾個月什么都不干 ， 就只做這個 。 ”他說 ， “現在 ， 我寫的代碼里 90% 都是 AI 生成的 。 ”

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

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

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

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

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

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

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

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

飛速迭代

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

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

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

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

Tegmark 說 ， LLM 數學能力的快速提升帶來一個誘人的可能性：模型不僅能產出軟件 ， 還能給出無 bug 的數學證明 。 “你只要給出規格說明 ， AI 就會返回可被證明正確的代碼 ， ”他說 ， “你不需要碰代碼 ， 甚至都不必看代碼 。 ”

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

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

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

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

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

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

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

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

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

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

原文鏈接：
https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/

    推薦閱讀