少寫程式碼，多負起責任

背景

這篇文章源自 Orhun 的部落格，探討在 AI 輔助編程盛行的時代，開發者應如何重新審視自身的責任。作者分享了從最初過度依賴 AI 導致喪失主導權，到後來轉向「逐行審查」並將 AI 用於處理瑣碎任務的轉變過程，強調開發者必須對最終產出的品質負責，而非僅是追求開發速度。

社群觀點

Hacker News 的討論聚焦於「寫程式的瓶頸究竟在哪裡」。部分資深開發者認為，軟體開發的核心在於思考與理解問題，而非單純的打字輸入。他們指出，增加程式碼行數往往是負債而非資產，過度追求 AI 生成的速度可能導致系統複雜度失控，最終讓測試、驗證與維護成本大幅攀升。一位獨立遊戲開發者提到，即便不使用任何 AI 助手或語言伺服器，開發進度依然能保持合理節奏，因為真正的挑戰在於架構決策，而非撰寫程式碼的體力活。

然而，另一派觀點則強烈反對「寫程式不是瓶頸」的說法。有技術主管分享其招募經驗，認為在許多高速成長的環境中，產出程式碼的速度確實是限制業務發展的關鍵因素。他們將開發者比喻為建築工地的泥水匠，認為如果基礎建設與需求已經明確，快速「鋪設磚塊」就是核心價值所在。這引發了關於軟體工程本質的爭論：究竟開發者是解決問題的工程師，還是按圖索驥的代碼工廠員工？支持 AI 的觀點認為，AI 能有效處理如 CSS 樣式調整或樣板代碼等單調工作，讓開發者有更多精力進行實驗與原型設計。

此外，社群也對 AI 帶來的「認知負荷」表示擔憂。一名機器學習工程師提到，隨著 AI 工具與框架的更迭速度加快，開發者被迫不斷學習新工具，卻難以累積深厚的技術回報。這種環境下，開發者可能不得不屈服於使用 AI 來應付日益增長的複雜度，即便明知這可能埋下未來的災難。討論中也達成了一種微妙的共識：AI 的價值取決於使用者的意圖。如果將其視為加速創新的工具，並保持對代碼品質的嚴格把關，AI 確實能發揮正面作用；但若僅是為了裁員或取代思考，最終只會產出難以維護的垃圾代碼。

延伸閱讀

在討論串中，多位參與者引用了 Fred Brooks 的經典著作《人月神話》（The Mythical Man-Month），特別是關於「向進度落後的專案增加人力只會使其更落後」的布魯克斯定律。此外，有留言推薦了 Jim Coplien 於 1994 年發表的論文《Borland Software Craftsmanship》，該文探討了高素質團隊的生產力指標。針對減少程式碼的實踐，也有人分享了關於「配置優先工具」（config-first tools）以及強調驗證變更重要性的技術文章。