寫程式碼從來不是瓶頸：LLM時代的軟體開發挑戰

多年來，我始終認為在軟體工程中，撰寫程式碼的行數從來都不是真正的瓶頸所在。

真正的瓶頸過去是，現在依然是程式碼審查、透過指導和配對進行的知識傳遞、測試、偵錯，以及協調與溝通的人為成本。所有這些都被包裹在工作票、規劃會議和敏捷儀式的迷宮中。

這些原本旨在提升品質的流程，往往比撰寫程式碼本身更能拖慢我們的速度，因為它們需要思考、共享理解和健全的判斷力。

如今，隨著大型語言模型（LLMs）使生成可運行程式碼變得比以往更快，一種新的說法出現了：撰寫程式碼曾經是瓶頸，而我們終於突破了它。

但這種說法並不完全正確。

新增軟體的邊際成本正趨近於零，尤其是有了LLMs的幫助。但理解、測試和信任該程式碼的代價是什麼？比以往更高。

LLMs轉移了工作負載——而非消除它

像Claude這樣的工具可以加快初始實現速度。但結果往往是更多的程式碼流入系統，以及對負責審查、整合和維護它的人員施加更大壓力。

這在以下情況尤為明顯：

• 不清楚作者是否完全理解他們提交的內容。
• 生成的程式碼引入了不熟悉的模式或違反了既定慣例。
• 邊緣案例和非預期的副作用並不明顯。

我們最終陷入這樣一種情況：程式碼變得更容易生成，但更難驗證，這並不一定能讓團隊整體移動得更快。

這不是新挑戰。開發人員長期以來一直在調侃「複製貼上工程」，但LLMs所實現的速度和規模放大了這些複製貼上的習慣。

理解程式碼仍然是最難的部分

「程式碼最大的成本是理解它——而非撰寫它。」

LLMs減少了生成程式碼所需的時間，但它們並未改變推理行為、識別細微錯誤或確保長期可維護性所需的努力。當審查者難以區分生成和手寫的程式碼，或理解為何選擇特定解決方案時，這項工作可能會更加困難。

團隊仍然依賴信任和共享背景

軟體工程一直是協作性的。它依賴於共享理解、一致性和指導。然而，當程式碼生成的速度快於討論或審查的速度時，團隊就有可能陷入一種假定品質而非確保品質的模式。這會給審查者和指導者帶來壓力，可能會以更微妙的方式減慢進度。

LLMs功能強大——但它們無法修復基本面

更快的原型設計、腳手架和自動化確實具有真正的價值。但是，LLMs並不能消除對清晰思考、仔細審查和深思熟慮的設計的需求。如果說有什麼區別的話，那就是隨著生成更多的程式碼，這些需求變得更加重要。

是的，編寫程式碼的成本確實下降了。但是，作為一個團隊共同理解它的成本並沒有下降。

那才是瓶頸所在。讓我們不要假裝它不存在。

人類協作：LLM時代的新挑戰

對於可能不太熟悉這個主題的讀者來說，讓我們進一步解釋為什麼這很重要。想像一下，您正在建造一棟房子。LLMs就像是一台能夠快速生產磚塊和材料的機器。過去，製作這些材料可能需要時間和努力，但實際建造房子的挑戰在於如何將它們放在一起，如何確保結構穩固，以及如何使各個部分協調工作。

在軟體世界中，程式碼行是我們的基本構建塊。當這些構建塊變得廉價且容易獲取時，我們面臨的真正問題是：

• 品質控制：我們如何確保這些自動生成的構建塊符合我們的標準？
• 系統理解：開發人員是否真正理解他們正在組合的部分？
• 整合複雜性：程式碼數量增加會導致互動增加，從而增加複雜性。

當我們使用LLMs等工具，很容易認為我們的生產力激增，因為我們可以快速生成程式碼。但現實是，軟體開發的最大挑戰一直是，也將繼續是人際溝通和協作。

在這個AI輔助開發的新時代，最成功的團隊不會只是那些生成最多程式碼的團隊。而是那些最善於：

• 建立使AI合作夥伴能夠增強而非取代人類判斷的工作流程
• 維持清晰的架構和命名規範，使生成的程式碼更容易理解
• 投資於培訓開發人員在理解和整合生成的程式碼方面的技能
• 認識到審查、討論和適當測試的價值超過了「馬上完成」的速度

換句話說，速度一直是一個誤導性的指標。真正的衡量標準應該是：我們能否生產出既可靠又可維護的軟體，能讓使用者滿意並有效解決問題？

隨著我們擁抱LLMs的強大能力，讓我們記住，編程的真正藝術不僅僅在於生成程式碼，而是在於創建有意義的解決方案，這些解決方案能夠隨著時間的推移而發展並被人類理解。