coding
寫程式碼從來不是瓶頸:LLM時代的軟體開發挑戰
多年來,我始終認為在軟體工程中,撰寫程式碼的行數從來都不是真正的瓶頸所在。 真正的瓶頸過去是,現在依然是程式碼審查、透過指導和配對進行的知識傳遞、測試、偵錯,以及協調與溝通的人為成本。所有這些都被包裹在工作票、規劃會議和敏捷儀式的迷宮中。 這些原本旨在提升品質的流程,往往比撰寫程式碼本身更能拖慢我們的速度,因為它們需要思考、共享理解和健全的判斷力。 如今,隨著大型語言模型(LLMs)使生成可運行程式碼變得比以往更快,一種新的說法出現了:撰寫程式碼曾經是瓶頸,而我們終於突破了它。 但這種說法並不完全正確。 新增軟體的邊際成本正趨近於零,尤其是有了LLMs的幫助。但理解、測試和信任該程式碼的代價是什麼?比以往更高。 LLMs轉移了工作負載——而非消除它 像Claude這樣的工具可以加快初始實現速度。但結果往往是更多的程式碼流入系統,以及對負責審查、整合和維護它的人員施加更大壓力。 這在以下情況尤為明顯: * 不清楚作者是否完全理解他們提交的內容。 * 生成的程式碼引入了不熟悉的模式或違反了既定慣例。 * 邊緣案例和非預期的副作用並不明顯。 我們最終陷入這樣一種情