背景

在軟體工程界，「程式碼行數」（Lines of Code, LOC）長期以來被視為衡量生產力的負面指標，因為它往往鼓勵開發者撰寫冗長且低效的程式碼。然而，隨著生成式 AI 的普及，各大科技公司執行長開始競相吹捧 AI 生成程式碼的比例，這讓原本已遭摒棄的 LOC 指標以另一種形式重返舞台，並引發了關於軟體品質與複雜度管理的新一輪爭論。

社群觀點

Hacker News 的討論呈現出對 LOC 指標回歸的高度警惕與深刻反思。多數資深開發者認為，將 AI 生成的行數視為進步是一種誤導。有觀點指出，程式碼應該被視為一種「成本」而非「資產」，如同 Dijkstra 所言，行數是「花掉的」而非「產出的」。當 AI 能夠以極低成本生成數萬行程式碼時，這種「量化」的衡量標準便徹底失去了意義。評論中提到，AI 往往傾向於增加程式碼量來解決問題，而非透過重構來簡化邏輯，這會導致嚴重的程式碼膨脹與技術債。

然而，社群中也存在較為務實的看法。部分討論者認為，雖然 LOC 不適合衡量個人生產力，但它在評估專案整體複雜度或 AI 介入程度時仍具備參考價值。了解一個專案中有多少比例由 AI 撰寫，對於管理品質風險與安全審查具有實質意義。此外，也有人提到 AI 在程式碼審查（Code Review）中的潛力，認為 AI 雖然會產生冗餘，但若能快速捕捉到人類可能遺漏的低級錯誤或命名不一致，仍能提升開發效率。

爭論的核心在於「偶然複雜度」的失控。許多開發者擔心，當企業追求 AI 生成行數的指標時，會誘使開發者忽視程式碼的簡潔性與可維護性。有人分享了過去外包浪潮的慘痛經驗，當時同樣以行數衡量產出，結果導致大量垃圾程式碼產生，最後仍需人類工程師耗費數倍精力去修復。社群達成的一個共識是：真正的技術突破不在於 AI 能寫出多少行程式碼，而在於 AI 是否能用更少的程式碼實現相同的功能，並保持系統的清晰與正確。

最後，有討論者提出「氛圍編程」（Vibe Coding）的概念，擔憂當開發者不再需要理解底層邏輯，只需透過 AI 堆疊程式碼時，軟體工程的專業性將被侵蝕。這種缺乏理解的產出，最終會讓系統變得難以調試與維護。

延伸閱讀

• No Silver Bullet：Fred Brooks 提出的經典理論，區分了本質複雜度與偶然複雜度。
• Programming as Theory Building：Peter Naur 的論文，探討編程本質上是建立理論的過程，而非單純的產出。
• Goodhart's Law：當一個指標變成目標時，它就不再是一個好指標。
• Greptile 數據報告：關於 AI 採用後開發者產出行數增長的統計分析。