Good code will still win

背景

隨著 AI 輔助編程工具普及，開發者社群開始擔憂大量由模型生成的「垃圾代碼」（Slop）正充斥著生產環境。Greptile 博客的文章指出，雖然 AI 導致代碼量激增且軟體脆性增加，但基於經濟誘因，未來 AI 模型將被迫生成更簡潔、易維護的「好代碼」，因為這能有效降低 Token 消耗與維護成本。

社群觀點

Hacker News 的討論呈現出明顯的兩極分化，核心爭議在於「好代碼」在商業現實中是否真的具備競爭力。部分資深開發者對文章的樂觀態度持懷疑立場，認為在 AI 時代之前，好代碼就從未真正勝出過。軟體產業的常態往往是「先求快速上線，後續再修補」，但現實中「後續」通常永遠不會到來。這種快速迭代的文化在 AI 加入後變本加厲，開發者發現自己正淹沒在 LLM 瞬間產出的低品質模組中，試圖釐清邏輯的速度遠趕不上代碼生成的效率。

關於軟體工程的本質，社群中出現了「手段派」與「工藝派」的精彩辯論。手段派認為代碼僅是達成產品目標的工具，用戶只在乎功能與體驗，並不在意底層是否為義大利麵代碼。然而，工藝派則反駁，低劣的代碼結構最終會反映在用戶體驗上，如軟體變得肥大、緩慢或頻繁崩潰。更有觀點指出，真正的工程學並非追求「最強大的橋樑」，而是「在預算內建造剛好不會倒塌的橋樑」。但在軟體領域，由於缺乏像土木工程那樣的法律責任與執照制度，導致開發者往往忽視安全邊際，將「崩潰」視為家常便飯。

有趣的是，部分討論將焦點轉向了蘇聯式的「粗獷主義」工程哲學。與追求精密如勞力士手錶、一碰就壞的美國設計不同，蘇聯傾向建造如廉價鬧鐘般耐操、能在惡劣環境下運作的機器。這引發了對軟體健壯性的思考：好代碼不一定非得優雅，有時具備高度容錯與防禦性設計的「粗糙」代碼，反而比過度設計的精巧架構更具生命力。

此外，針對 AI 是否能自動優化性能，開發者們也意見不一。有人認為性能優化可以透過反饋迴路自動完成，但也有人感嘆，只要執行效率不影響高層主管在意的業務指標，代碼的臃腫與低效往往會被視而不見。最終，社群達成了一種微妙的共識：人類開發者的價值將從「編寫代碼」轉向「系統分析」與「數據建模」。如果能定義出正確的數據模型與架構邊界，即便內部的實作是由 AI 生成的雜亂代碼，整體系統仍能保持一定的靈活性與可維護性。

延伸閱讀

在討論過程中，參與者提到了幾本經典著作與相關概念，包括 John Ousterhout 的《軟體設計哲學》（A Philosophy of Software Design），該書強調複雜度是軟體設計的最大敵人。此外，Ben Rich 的著作《臭鼬工廠》（Skunk Works）中關於蘇聯與美國工程哲學的對比，也被用來類比軟體開發的取捨。針對羅馬混凝土與現代混凝土耐用性的科學差異，亦有相關的維基百科條目被引用，用以討論「過度工程」與「長效設計」的經濟效益。