AI 時代，軟件開發(fā)的成本真的下降了 90% 嗎？資深工程師 Martin Alderson 在本文中分享了自己的最新觀察結果：AI Agent 正在大幅壓縮開發(fā)中的人力成本，讓原本需要數(shù)周甚至數(shù)月完成的項目，在幾小時或一周內(nèi)就能交付。同時，AI 不僅能加速新項目開發(fā)，還能輕松理解和維護三年以上的老舊代碼庫。這種變化釋放了巨大的潛在軟件需求，讓小團隊也能實現(xiàn)過去整個開發(fā)小隊才能完成的產(chǎn)出。

這篇文章深入探討了成本下降背后的原因、AI 工具對開發(fā)模式的重塑，以及為什么 2026 年可能成為行業(yè)的大轉折點。

原文：https://martinalderson.com/posts/has-the-cost-of-software-just-dropped-90-percent/

作者 | Martin Alderson 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我做軟件開發(fā)已經(jīng)將近 20 年了，見證過不少浪潮——SaaS 的“誕生”、移動應用的全面崛起、區(qū)塊鏈的瘋狂炒作，以及那些總說要讓程序員失業(yè)的低代碼工具。

但隨著代理式編碼（Agentic Coding）的出現(xiàn)，軟件開發(fā)的經(jīng)濟模型正在發(fā)生劇變，這股力量將徹底重塑整個行業(yè)（甚至會波及更廣的經(jīng)濟結構）。2026 年可能會讓很多人措手不及。

之前，我也討論了為什么現(xiàn)有的評測標準可能忽略了某些關鍵躍遷，而這段時間的思考和親身經(jīng)歷，更讓我確信我們正走進一場“十年一遇”的行業(yè)大轉折。

軟件交付成本

我開始做開發(fā)的時候，正好趕上開源開始大規(guī)模興起——而那算是自定義軟件開發(fā)成本的第一波大幅下降。我還記得，當年用 SQL Server 或 Oracle 的授權費用高得離譜，所以我從一開始就用開源 MySQL，它讓你能構建定制化的網(wǎng)絡應用，而不用承擔動輒五六位數(shù)的年度數(shù)據(jù)庫授權費。

后來我們經(jīng)歷了云計算（它是否真的省錢其實還有爭議，不過就先假設它在初期確實減少了部分資本支出）。最近幾年的特點，我覺得是“復雜性時代”。軟件工程變得——在我看來往往是不必要地——復雜了。大家一頭扎進對人力要求極高的模式，比如 TDD、微服務、極其復雜的 React 前端，以及 Kubernetes。我甚至覺得過去幾年，軟件開發(fā)的成本幾乎沒有下降。

然而在我看來，AI Agent 會大幅降低軟件開發(fā)中的人力成本。

那 90% 的成本節(jié)省到底來自哪里？

2025 年初，我對各種 AI 編碼工具都持懷疑態(tài)度——現(xiàn)在依然如此。很多平臺看起來就是換了皮的低代碼工具（比如 Loveable、Bolt 等），或者是一些帶點自動補全增強功能的 VS Code 衍生版本，用起來感覺一半有用一半煩人。

以公司里一個典型的內(nèi)部系統(tǒng)項目為例。假設數(shù)據(jù)模型已經(jīng)有了雛形，你要做的是構建一個 Web 應用來管理某個“widget”類的業(yè)務對象。

按照過去的流程，你通常需要一個小團隊來搭建 CI/CD、整理數(shù)據(jù)訪問模式、開發(fā)核心服務。然后是大量 CRUD 頁面，再加上一些儀表盤或可視化。最后（理想情況下）還得寫一套自動化的單元測試、集成測試、端到端測試，確保質量過關，然后大概一個月后才能上線。

而這還只是“純勞動力”。每多一個人，溝通成本就往上疊：各種會議、任務管理、Code Review、前后端對接、等待別人解決難題，你真正寫代碼的時間往往只是全部工時很小的一部分。

用代理式編碼的 CLI 工具，這些流程里幾乎所有步驟都能在幾小時內(nèi)完成。我曾讓 Claude Code 花幾小時寫完一個復雜內(nèi)部系統(tǒng)的完整單測 + 集成測試套件（300 多條）。這種規(guī)模的測試，對我自己，或我認識、尊重的開發(fā)者來說，都得花上好幾天寫。

AI Agent 已經(jīng)非常擅長把業(yè)務邏輯規(guī)范轉成結構清晰、可用性很高的 API 和服務。

過去一個月的項目，現(xiàn)在一個星期搞定。思考時間差不多，但實現(xiàn)時間直接塌縮。而且團隊越小，溝通開銷越低，甚至反向驗證了“布魯克斯定律”的鏡像效應：溝通成本不再是人越多效率越低，而是人越少效率爆炸提升。一兩個開發(fā)者突然就能做到過去一個團隊才能完成的量。

潛在需求的釋放

乍看之下，這對軟件行業(yè)似乎是個壞消息，但從經(jīng)濟學的角度并不是這樣。

杰文斯悖論（Jevons Paradox）告訴我們，當某種東西的生產(chǎn)成本下降時，我們并不會只是“花更少的錢做同樣的量”，而是會做更多。電燈就是典型例子：蠟燭和煤氣燈銷量掉了，但整個社會的人造光源總量卻大幅增加。

這一點，應用到軟件開發(fā)上，就是供需關系問題：社會對軟件有著巨大的“潛在需求”。

幾乎每家公司都有幾百甚至幾千份 Excel 表格在記錄關鍵業(yè)務流程，而這些東西本該做成 SaaS。如果一家外包公司報價 5 萬美元來把其中一個做成應用，那只有最核心的項目能立項。但如果成本降到 5000 美元（找個不錯的開發(fā)者配合 AI 工具即可），那就完全是另一個世界——需求會大爆發(fā)。

唯一的護城河：領域知識

那么開發(fā)者會被淘汰嗎？現(xiàn)實沒那么簡單。

目前，人類仍然非常重要，因為你得“看著 AI 干活”：審核它的輸出、提出建議、避免它走偏。如果完全 YOLO 式（You Only Live Once）地放任 AI 寫代碼，項目很快會亂成一團。但只要有人類的參與，AI 能幫你在短時間內(nèi)構建質量非常高的軟件。

掌握這些工具的開發(fā)者，會在解決業(yè)務問題時變得異常高效。而他們的領域知識與行業(yè)理解會成為最大的杠桿：知道什么架構合適、用什么框架、哪些庫穩(wěn)定好用。

再疊加對業(yè)務本身的理解，你會真切感受到“傳說中的 10 倍工程師”正在變成現(xiàn)實。同樣，業(yè)務專家 + 一個熟練掌握 AI 工具的開發(fā)者這樣的組合，將變得非常強大。未來我們可能不再需要“一個業(yè)務專家 + 一整個開發(fā)小隊”，而是只需要兩三個人緊密配合即可。

這種組合讓迭代速度快得驚人，軟件變得幾乎是一次性的：如果方向不對，直接丟掉重來，從經(jīng)驗中學習就行。這需要轉變心態(tài)，但真正難的是想清楚問題，而不是敲鍵盤。

不要措手不及

AI Agent 和模型仍在快速進化，而我覺得現(xiàn)有的基準測試（benchmarks）并沒有真正反映這一點。比如 Opus 4.5 似乎能在 10–20 分鐘的長會話中保持較好理解，不會偏離主題。我們才剛剛開始看到數(shù)千億美元資本投入到 GB200 GPU 上的成果，而我相信更新一代的模型很快就會讓這些看起來完全過時。

然而，我遇到過太多抵觸這種變化的軟件工程師。我聽過的反對理由總是雷同：LLM 會犯太多錯誤、它理解不了某個框架、或者根本沒節(jié)省時間。

這些說法正迅速變得完全不成立，讓我想起 2007 年那些看不起 iPhone 的桌面工程師們。大家都知道后來發(fā)生了什么——網(wǎng)絡更快了、手機性能提升、移動操作系統(tǒng)也越來越強大。

我認為，工程師們需要積極擁抱這場變革。這不會一夜之間完成——大企業(yè)總體上仍然落后，被繁瑣的供應商審批和管理結構困住，這讓它們對小型競爭者極度脆弱。

但如果你在一家小公司或團隊工作，并且有機會使用這些工具，就應該抓住它。你的工作會發(fā)生變化——不過軟件開發(fā)一直都在變化。只是這一次，變化可能比任何人預料的還要快。2026 年即將到來。

我經(jīng)常聽到的一個反對意見是：LLM 只適合新項目。我強烈反對這種觀點。我花了不少時間去理解三年以上、原作者已離職的舊代碼庫。AI Agent 可以大幅簡化這個過程——解釋代碼功能、定位 Bug、提出修復建議。我寧愿接手一個由 Agent 協(xié)助、并有優(yōu)秀工程師監(jiān)督完成的代碼庫，也不愿接手三年前某個水平可疑的承包商寫的、沒有測試、充滿“意大利面式”類和方法的混亂項目。

【報名倒計時，限免】C++之父中國行 · 40周年慶典｜北京·上海開發(fā)者見面會正式開啟！

• 北京站：12月12日 · 北京金隅喜來登酒店

• 上海站：12月14日 · 上海淳大萬麗酒店