寫程式是困難的部分嗎？在 AI 時代辯論程式設計的價值

軟體開發產業目前正因大型語言模型 (LLMs) 的興起而面臨根本性的身分認同危機。一種常見的論點認為「程式碼從來不是最困難的部分」——這暗示著軟體工程真正的難點在於產品發現、需求收集以及利害關係人管理，而實際撰寫程式碼的行為則是微不足道的。

這種說法極具爭議。對許多人來說，這是對程式設計這門手藝的侮辱；對其他人來說，這是在區分「輸入語法」的行為與「工程設計複雜系統」的行為之間的必要區別。

將寫程式視為一門困難的手藝

撰寫高品質、可靠且可維護的程式碼是一門需要深厚專業知識的技術。關於寫程式很「容易」的論點與幾項產業現實相矛盾：

經濟價值： 歷史上對「10x developers」的高需求與高薪資，顯示出實現複雜邏輯的能力是一種稀缺且寶貴的技能。
技術深度： 如 The Art of Computer Programming 與 Structure and Interpretation of Computer Programs (SICP) 等基礎著作的存在，顯示出其理論與實務複雜度遠超「微不足道」的工作。
系統穩定性： Bug 的普遍存在以及維護遺留系統 (legacy systems) 的困難，證明了實作過程鮮少是直截了當的。
「天才」因素： 產業持續認可如 John Carmack 與 Fabrice Bellard 等個人，並非因為他們與利害關係人溝通的能力，而是因為他們非凡的技術實作能力。

反方論點：寫程式 vs. 工程設計

許多經驗豐富的開發者認為「程式碼從來不是最困難的部分」這句話是一個定義問題。他們區分了「coding」（將已知解決方案轉換為語法）與「programming/engineering」（解決問題的行為）。

寫程式即翻譯

有人認為，一旦問題被完全分解為技術規範，輸入程式碼的行為就是流程中最簡單的部分。在這種觀點下，寫程式類似於手術過程中的最後「切割」——這是必要的最後一步，但它發生在 99% 的關鍵決策之後。

「非程式碼」工作的複雜性

從組織的角度來看，瓶頸鮮少是程式碼行數本身，而是：

需求模糊性： 理解客戶真正需要什麼，與他們口頭說想要什麼之間的區別。
架構與建模： 設計能夠演進且不會在自身複雜度下崩潰的系統。
分散式系統挑戰： 管理 CAP theorem 的權衡、時鐘同步以及 exactly-once delivery。
組織協調： 協調多個團隊與利害關係人以達成方向共識。

"Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers."

AI 對開發者角色的影響

LLMs 正在加速開發者如何分配時間的轉變。雖然 AI 可以產出數千行程式碼，但它引入了新的複雜度，將「困難的部分」進一步推向技術棧的更高層。

從撰寫到驗證

開發者正日益從程式碼的作者轉變為編輯與架構師。挑戰不再是撰寫函數，而是工程設計驗證框架、架構規範與驗證系統，以確保 AI 生成的程式碼不會引入安全漏洞或架構偏移 (architectural drift)。

「Vibe Coding」的風險

對於「vibe coding」的擔憂日益增加，即開發者使用 AI 生成看起來功能正常的程式碼，卻不理解底層機制。這會導致脆弱的程式碼庫，使得開發者無法解釋數據如何流經系統，或為何選擇了特定的實作方式。

如何在技術變革中茁壯成長

為了保持競爭力，開發者必須在技術深度與對業務與使用者體驗的更廣泛理解之間取得平衡。

對於資深開發者

深化技術專業知識已不再足夠。資深開發者應投資於相鄰領域：使用者體驗 (UX)、客戶訪談技巧以及業務策略。理解「為什麼」要建立某個功能，與知道「如何」建立它同樣關鍵。

對於初級開發者

儘管語法已自動化，但基礎知識仍然至關重要。理解指標 (pointers)、記憶體階層 (memory hierarchy)、網路協定 (HTTP) 與資料結構，能提供必要的心理模型，以進行 AI 生成的幻覺 (hallucinations) 除錯除錯與設計高效能系統。

不變的變數

無論使用何種工具集，關於軟體的一些真理仍然不變：

熵 (Entropy)： Bit-rot 與軟體複雜度將會持續增加。
使用者需求模糊性： 使用者將會持續在表達需求時感到困難。
維護： 軟體始終需要人類的判斷力來進行長期維護與演進。

最終，目標是避免「將判斷力、同理心與品味外包給 AI」。最成功的開發者將是那些能夠在對系統的深刻理解與對使用者問題的深刻理解之間架起橋樑的人。