每十年，總有人信心滿滿地宣稱：“這次，我們終于可以讓軟件開發(fā)變得簡單，不再需要那么多開發(fā)者了?！钡F(xiàn)實是，我們真的不再需要開發(fā)者了嗎？

近日，資深開發(fā)者 Stephan Schwab 在《Why We’ve Tried to Replace Developers Every Decade Since 1969》一文中回顧了過去五十年軟件開發(fā)的迭代歷程——從阿波羅計劃手寫導(dǎo)航軟件的壯舉，到 COBOL、CASE 工具、Visual Basic，再到今天的 AI 編程助手，他深度分析了為什么試圖“替代開發(fā)者”的夢想總是反復(fù)出現(xiàn)。

通過剖析這一模式，我們不僅能理解工具如何改變開發(fā)方式，更能看清軟件工作的本質(zhì)：復(fù)雜性不可消解，而真正的核心，是人的思考。這篇文章帶你回到每一次技術(shù)浪潮的現(xiàn)場，看看每一次嘗試如何既帶來便利，又揭示了不可繞過的挑戰(zhàn)——也讓我們明白，開發(fā)者從未真正被替代，只是工作方式在不斷進(jìn)化。

來源：https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html

作者 | Stephan Schwab 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

夢想誕生于人類最偉大的成就

1969 年，當(dāng)尼爾·阿姆斯特朗踏上月球時，全世界見證了有組織的人類智慧能實現(xiàn)的奇跡。而這背后，是瑪格麗特·漢密爾頓及其團(tuán)隊手寫的阿波羅導(dǎo)航軟件，通過仔細(xì)復(fù)核捕捉關(guān)鍵錯誤，證明軟件可以至關(guān)重要。

阿波羅計劃展示了軟件開發(fā)在實現(xiàn)“不可能”任務(wù)中的核心價值，但也暴露了一個讓企業(yè)高管數(shù)十年困擾的問題：寫軟件需要專業(yè)知識、高度專注和大量時間投入。于是，讓開發(fā)更簡單、減少對這些昂貴專家依賴的夢想幾乎立刻誕生。

COBOL：讓業(yè)務(wù)人員自己寫程序

上世紀(jì) 60-70 年代，COBOL 出現(xiàn)了，其名字本身就明確目標(biāo)：Common Business-Oriented Language（通用業(yè)務(wù)導(dǎo)向語言）。理念很清晰：讓語言像英語一樣可讀，業(yè)務(wù)分析師就能自己寫程序，無需專業(yè)程序員。

“如果語法足夠易讀，任何理解業(yè)務(wù)的人都能寫代碼?！?/p>

這個愿景確實很吸引人。軟件對業(yè)務(wù)運作越來越關(guān)鍵，但程序員仍然稀缺且昂貴。COBOL 承諾讓軟件開發(fā)大眾化。

然而，現(xiàn)實并非如此。COBOL 最終還是一門需要專業(yè)培訓(xùn)的語言。業(yè)務(wù)分析師嘗試寫 COBOL 時很快發(fā)現(xiàn)：可讀的語法并不能消除邏輯、數(shù)據(jù)結(jié)構(gòu)或系統(tǒng)設(shè)計的復(fù)雜性。于是，出現(xiàn)了一類新的 COBOL 程序員，而消除專業(yè)開發(fā)者的夢想依然未能實現(xiàn)。

夢想并未消亡，它只是等待下一波技術(shù)浪潮。

20 世紀(jì) 80 年代：CASE 工具將生成一切

20 世紀(jì) 80 年代，計算機(jī)輔助軟件工程（CASE）工具出現(xiàn)，帶來了巨大的期望。只需繪制流程圖或?qū)嶓w關(guān)系圖，工具就能生成可運行的代碼。它的宣傳口號很有吸引力：可視化設(shè)計比輸入復(fù)雜難懂的命令更直觀。業(yè)務(wù)專家可以建模自己的流程，而軟件就會自動生成。

企業(yè)投入巨大，供應(yīng)商承諾生產(chǎn)力提升十倍以上。然而，大多數(shù) CASE 工具項目要么掙扎，要么徹底失敗。

生成的代碼往往需要大量手工干預(yù)。性能問題頻出。維護(hù)更是噩夢——生成代碼與視覺模型一旦偏離，問題層出不窮。最關(guān)鍵的是，畫準(zhǔn)確的圖表仍然需要理解與編程同樣的邏輯復(fù)雜性。工具改變了界面，但沒改變根本挑戰(zhàn)。

問題再次證明，比解決方案更難應(yīng)對。

Visual Basic 和 Delphi：拖一拖，寫好了

90 年代出現(xiàn)了不同的思路。微軟的 Visual Basic 和 Borland 的 Delphi 大幅降低了用戶界面開發(fā)難度：拖組件、設(shè)置屬性、寫事件處理程序，Windows 應(yīng)用開發(fā)對經(jīng)驗有限的開發(fā)者來說也變得可行。

這波浪潮與 COBOL 或 CASE 工具不同。它承認(rèn)編程知識仍然必不可少，但降低了入門門檻，讓更多人能夠創(chuàng)建有用應(yīng)用。

然而，消除開發(fā)者的夢想依然存在：“高級用戶”和“公民開發(fā)者”可以構(gòu)建部門級應(yīng)用，IT 部門只管基礎(chǔ)設(shè)施，業(yè)務(wù)部門解決自己的軟件需求。

現(xiàn)實更微妙。簡單應(yīng)用確實更易被更多人使用，但隨著需求復(fù)雜度增加——與現(xiàn)有系統(tǒng)集成、安全性要求、負(fù)載性能、長期維護(hù)——對經(jīng)驗豐富開發(fā)者的需求變得顯而易見。工具擴(kuò)大了可編程人群，卻無法消除構(gòu)建復(fù)雜系統(tǒng)所需的專業(yè)知識。

于是，這個循環(huán)延續(xù)到新千年。

2000 年代及以后：Web 框架、低代碼和無代碼

每個十年都會帶來新的變化。Ruby on Rails 推出了“約定優(yōu)于配置”；低代碼平臺提供可視化開發(fā)，幾乎無需編碼；無代碼平臺宣稱可以完全免編程完成常見業(yè)務(wù)應(yīng)用。

每一波都帶來了真正價值。開發(fā)在特定場景下確實更快了，更多人能參與軟件創(chuàng)建。然而，專業(yè)開發(fā)者仍不可或缺，且對其技能的需求非但沒有減少，反而持續(xù)增長。

這就引出一個問題：為什么這個模式總是重復(fù)？

為什么這個夢想一直存在

反復(fù)出現(xiàn)的模式揭示了我們對復(fù)雜性認(rèn)知的重要事實：軟件開發(fā)看起來應(yīng)該簡單，因為我們可以用普通語言描述需求。

“當(dāng)客戶下單時，檢查庫存、計算運費、處理支付，并發(fā)送確認(rèn)郵件?！边@樣的描述聽起來很簡單明了。

但復(fù)雜性隱藏在細(xì)節(jié)中：庫存被其他訂單暫時占用怎么辦？部分付款如何處理？郵件服務(wù)暫時不可用怎么辦？是否重試？重試幾次？客戶在結(jié)賬時會話過期怎么辦？如何避免重復(fù)訂單？

每個答案又會引出更多問題。累積的決策、極端情況和交互產(chǎn)生真正的復(fù)雜性，沒有工具或語言可以消除。有人必須思考這些情境，這就是軟件開發(fā)——無論是用 COBOL、CASE 工具圖、Visual Basic 還是 AI 提示。

AI：漫長故事中的最新章節(jié)

今天的 AI 編程助手是迄今最強(qiáng)大的嘗試，它們可以根據(jù)自然語言描述生成大量可運行代碼，解釋現(xiàn)有代碼、提出改進(jìn)建議、幫助調(diào)試。

這確實是進(jìn)步。對經(jīng)驗開發(fā)者來說，它們提高了效率；對學(xué)習(xí)者來說，交互式指導(dǎo)非常有幫助。

然而，我們已經(jīng)看到熟悉的模式出現(xiàn)：初期對 AI 替代開發(fā)者的興奮，正在被更細(xì)致的理解取代——AI 改變的是開發(fā)者的工作方式，而不是消除他們的判斷需求。復(fù)雜性依然存在：有人必須理解業(yè)務(wù)問題，評估生成代碼是否正確，考慮安全性，確保與現(xiàn)有系統(tǒng)整合，并在需求變化時維護(hù)代碼。

AI 擴(kuò)大了開發(fā)者能力，卻無法替代那些既懂業(yè)務(wù)又懂技術(shù)的人。

機(jī)會巨大，但仍然捉襟見肘

這是讓這個模式更具諷刺意味的悖論。軟件能力進(jìn)步驚人：阿波羅導(dǎo)航電腦只有 4KB 內(nèi)存，你的智能手機(jī)計算能力比它強(qiáng)幾百萬倍。我們擁有真正能讓開發(fā)更容易的工具和框架。

然而，對軟件的需求遠(yuǎn)超我們創(chuàng)造能力。每個組織需要的軟件比能開發(fā)的還多，待辦功能和新項目的積壓增長速度超過開發(fā)團(tuán)隊的處理能力。

這種緊張關(guān)系——強(qiáng)大工具卻不足以應(yīng)對——讓夢想保持活力。企業(yè)高管看到積壓功能時會想：“一定有辦法更快，讓更多人參與?！边@是合理的思路，也自然催生了對任何“讓軟件開發(fā)大眾化”工具的熱情。

問題是，軟件開發(fā)的瓶頸并不是打字速度或語法知識，而是處理復(fù)雜性所需的思考。打字再快，也無法解決并發(fā)數(shù)據(jù)庫更新的設(shè)計思考；語法更簡單，也不能幫你推理安全問題。

那么，領(lǐng)導(dǎo)者應(yīng)該如何運用這種認(rèn)知？

對領(lǐng)導(dǎo)者的啟示

理解這個模式能改變你評估新工具和方法的方式。當(dāng)有人承諾業(yè)務(wù)用戶無需開發(fā)者就能構(gòu)建應(yīng)用時，你可以理解他們的愿景，同時保持現(xiàn)實預(yù)期。

正確的問題不是：“這會讓我們不再需要開發(fā)者嗎？”

而是：

• 這能讓開發(fā)者在處理復(fù)雜問題時更高效嗎？

• 這能讓我們更快地構(gòu)建某些類型的解決方案嗎？

• 這能減少重復(fù)性任務(wù)，讓開發(fā)者專注于獨特挑戰(zhàn)嗎？

• 團(tuán)隊是否需要學(xué)習(xí)新技能才能有效使用？

這些問題承認(rèn)開發(fā)涉及不可簡化的復(fù)雜性，同時對提供真正杠桿作用的工具保持開放態(tài)度。

模式揭示了問題的本質(zhì)

五十年的循環(huán)教會我們一個基本道理：軟件開發(fā)的挑戰(zhàn)不是機(jī)械性的——不是打字太多、語法太復(fù)雜、步驟太多。COBOL 讓語法可讀，CASE 工具減少了輸入，視覺工具消除了語法，AI 可以根據(jù)描述生成完整的函數(shù)。

每一次進(jìn)步都解決了實際存在的痛點，但根本挑戰(zhàn)依舊存在，因為它并非機(jī)械性的，而是智力性的。軟件開發(fā)是“思考的可視化”。我們創(chuàng)造的產(chǎn)物——COBOL 程序、Delphi 表單、Python 腳本——是對復(fù)雜性進(jìn)行思考的可見結(jié)果。

這種推理沒有捷徑，就像設(shè)計建筑或診斷病癥一樣。工具更好，經(jīng)驗豐富確實有幫助，但有人仍必須認(rèn)真思考。

目光清醒地前行

新一波開發(fā)工具遲早會到來，有些能帶來真正價值，有些則只是用新技術(shù)重復(fù)舊承諾。理解這個循環(huán)模式，能讓你更有效地使用新工具。

使用 AI 助手，評估低代碼平臺，嘗試新框架。但最重要的是投資于團(tuán)隊清晰思考復(fù)雜問題的能力——這才是限制因素，就像阿波羅計劃時期一樣。

登月之所以成功，是因為杰出的科學(xué)家們對極其復(fù)雜的挑戰(zhàn)進(jìn)行了周密的思考，考慮到了每一個細(xì)節(jié)。他們手寫軟件，因為這是當(dāng)時可用的工具。如果有更好工具，他們會欣然使用，但工具無法消除思考復(fù)雜性的需求。

如今情況相同。我們有更好的工具——但思考仍不可或缺。

夢想的意義

或許，人們反復(fù)萌生 “替代開發(fā)者” 的想法并非謬誤。這種執(zhí)念更像是一種必要的樂觀主義，持續(xù)推動著工具的迭代與創(chuàng)新。每一次嘗試讓開發(fā)更易上手，都會帶來真正幫助。夢想可能未能按最初設(shè)想實現(xiàn)，但追求它本身創(chuàng)造了價值。

COBOL 沒讓業(yè)務(wù)分析師寫程序，但讓一代開發(fā)者有效構(gòu)建了業(yè)務(wù)系統(tǒng)；CASE 工具沒生成完整應(yīng)用，但推進(jìn)了視覺建模的思考；Visual Basic 沒消除專業(yè)開發(fā)者，但讓更多人能開發(fā)應(yīng)用；AI 不會替代開發(fā)者，但會改變我們的工作方式。

這種模式之所以持續(xù)存在，因為夢想反映了真實需求。我們確實需要更快、更高效地創(chuàng)造軟件，只是發(fā)現(xiàn)限制因素不是工具，而是我們要解決問題的復(fù)雜性。

理解這一點，不意味著拒絕新工具，而是要明確它們能提供什么，以及哪些永遠(yuǎn)需要人類判斷。