每10年一次的“開發者淘汰戰”，自1969年就已開局！

每十年，總有人信心滿滿地宣稱：“這次，我們終于可以讓軟件開發變得簡單，不再需要那么多開發者了。”但現實是，我們真的不再需要開發者了嗎？

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

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

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

作者 | Stephan Schwab 責編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

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

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

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

COBOL：讓業務人員自己寫程序

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

“如果語法足夠易讀，任何理解業務的人都能寫代碼。”

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

然而，現實并非如此。COBOL 最終還是一門需要專業培訓的語言。業務分析師嘗試寫 COBOL 時很快發現：可讀的語法并不能消除邏輯、數據結構或系統設計的復雜性。于是，出現了一類新的 COBOL 程序員，而消除專業開發者的夢想依然未能實現。

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

20 世紀 80 年代：CASE 工具將生成一切

20 世紀 80 年代，計算機輔助軟件工程（CASE）工具出現，帶來了巨大的期望。只需繪制流程圖或實體關系圖，工具就能生成可運行的代碼。它的宣傳口號很有吸引力：可視化設計比輸入復雜難懂的命令更直觀。業務專家可以建模自己的流程，而軟件就會自動生成。

企業投入巨大，供應商承諾生產力提升十倍以上。然而，大多數 CASE 工具項目要么掙扎，要么徹底失敗。

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

問題再次證明，比解決方案更難應對。

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

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

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

然而，消除開發者的夢想依然存在：“高級用戶”和“公民開發者”可以構建部門級應用，IT 部門只管基礎設施，業務部門解決自己的軟件需求。

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

于是，這個循環延續到新千年。

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

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

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

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

為什么這個夢想一直存在

反復出現的模式揭示了我們對復雜性認知的重要事實：軟件開發看起來應該簡單，因為我們可以用普通語言描述需求。

“當客戶下單時，檢查庫存、計算運費、處理支付，并發送確認郵件。”這樣的描述聽起來很簡單明了。

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

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

AI：漫長故事中的最新章節

今天的 AI 編程助手是迄今最強大的嘗試，它們可以根據自然語言描述生成大量可運行代碼，解釋現有代碼、提出改進建議、幫助調試。

這確實是進步。對經驗開發者來說，它們提高了效率；對學習者來說，交互式指導非常有幫助。

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

AI 擴大了開發者能力，卻無法替代那些既懂業務又懂技術的人。

機會巨大，但仍然捉襟見肘

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

然而，對軟件的需求遠超我們創造能力。每個組織需要的軟件比能開發的還多，待辦功能和新項目的積壓增長速度超過開發團隊的處理能力。

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

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

那么，領導者應該如何運用這種認知？

對領導者的啟示

理解這個模式能改變你評估新工具和方法的方式。當有人承諾業務用戶無需開發者就能構建應用時，你可以理解他們的愿景，同時保持現實預期。

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

而是：

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

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

• 這能減少重復性任務，讓開發者專注于獨特挑戰嗎？

• 團隊是否需要學習新技能才能有效使用？

這些問題承認開發涉及不可簡化的復雜性，同時對提供真正杠桿作用的工具保持開放態度。

模式揭示了問題的本質

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

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

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

目光清醒地前行

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

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

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

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

夢想的意義

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

COBOL 沒讓業務分析師寫程序，但讓一代開發者有效構建了業務系統；CASE 工具沒生成完整應用，但推進了視覺建模的思考；Visual Basic 沒消除專業開發者，但讓更多人能開發應用；AI 不會替代開發者，但會改變我們的工作方式。

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

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