再談軟體工程幻滅
# 軟體工程大約 6 年前，我讀過一篇文章標題是「軟體工程幻滅」。
我認為用飛機、建築來對比軟體開發不太恰當，因為一個是不太容易變動的流程；軟體開發則是以持續迭代為前提開發的，兩者的特性不同，很難相提並論。這就像我不會要求房子蓋到一半要加入霍爾移動城堡的功能，房子要能自行移動。
AI 出現後，從原本（2023 年）覺得不怎樣，離取代日常開發還太遠；2025 年已經習慣透過 AI 輔助開發，自動補全已經是不可或缺的功能；到現在幾乎 90% 以上的程式碼都是由 AI 直接產出。軟體工程幻滅用另外一種形式再次席捲而來。
以前是工程師自己寫出爛 code，現在是 AI 大量產出看起來能跑但沒人真正理解的 code。
現在的軟體開發有 AI 的出現，大致上可以分成兩派人。一派人認為應該把寫程式全部交給 AI 來處理，不需要管可維護性、閱讀性、擴充性，人類只要負責確認意圖、方向即可；另一派人則認為這些 AI Slop 沒有任何幫助。
這位推文的作者是 Hono 的作者（如果你還在用 Express，非常推薦試試看 Hono），他就發了好幾篇推文，講述他最近遇到很多低品質、明顯是由 AI 生成的 Pull Request，讓他感到非常困擾。
我們現在正處在這個 LLM 出現跟 LLM 成熟的中間這段混亂期。
LLM 模型穩定成熟的時代總有一天會到來，模型的進步會徹底改變軟體開發的樣貌，但是我們不知道那一天是什麼時候。在奇點還沒到來的那天，我們也只能隨波逐流吧。
處在痛苦與興奮中
我一方面很看好之後 AI 的發展，只要模型的能力越來越好、越來越強，現在很多需要人類介入的事情必然會慢慢被取代。
不管是程式碼的品質也好，還是 AI 產出來的程式碼品質也好，或是為了讓這個作品變更好需要花的工夫也好，門檻都會越來越低。
但最近發生的一些事情也讓我相對有點痛苦，在專案當中或者是在社群上，你常常看到很多人他們直接把 AI 寫的東西，也不 review 就直接丟出來了。
這代表他們沒有考慮過閱讀者的感受，不管是程式碼也好，或是文件也好，甚至有時候在討論一些東西的時候，對方是直接把他跟 Gemini 的那個對話串的直接丟上來。我認為，我們的最低標準應該是你應該要先有自己的想法，然後透過 AI 去確認或者是去加強你的論點之後呢，再把它提出來。然後呢，你要先做第一手的整理，我覺得這樣才是對閱讀者的尊重。
就像 Simon 在 Anti-patterns: things to avoid 這篇文章提到的，如果你用 AI 生成了幾千行的程式碼，沒有自己確認過就開了 PR——這等於是把「確認這段 code 能不能用」的工作轉嫁給 reviewer。
Reviewer 自己也可以叫 AI 寫，那你到底貢獻了什麼？
一個負責任的 PR 應該是這樣的：你對這段 code 能正常運作有信心，因為你自己驗證過了；變更的範圍夠小，不會讓 reviewer 一打開就想關掉；PR description 裡有足夠的脈絡說明你為什麼要做這個改動，而不是讓 AI 生成一段看起來很專業但你自己都沒讀過的描述。 AI 讓產出 code 變得太容易了，所以反過來說，你更需要主動證明自己有投入。
附上手動測試的紀錄、對實作選擇的說明、甚至一張截圖，這些都是在告訴 reviewer：我有讀過，這不是我丟給你的垃圾。
品味
另一個讓我痛苦的，是關於品味和經驗的部分。
寫程式寫久了，你會很自然地辨識出一些 anti-pattern——你知道這樣寫現在能跑，但遲早會出事，有些修正甚至只需要幾行就能解決。
但問題是，現在很多人習慣讓 AI 產出 code 後就直接用，不太會回頭檢視（甚至連我自己也是）。這就形成了一種負循環：AI 讀了有問題的 code 作為 context，接下來產出的 code 都建立在這個有問題的基礎上，越寫越歪而使用者渾然不覺。
舉幾個具體的例子。
在 React 的 useEffect 裡面呼叫 setState，造成不必要的重複渲染；或者是架構上的決策，像是不使用 CDN，直接從檔案系統讀取靜態資源。
這些東西在本地測試完全沒問題，使用者少的時候也沒問題。等到流量變大、程式碼規模開始膨脹，才發現要改已經不是改幾行的事了。
而且這不一定是開發者偷懶沒做檢查——他可能根本不知道哪裡有問題。他沒有踩過這個坑，所以他看不見。但這些事情對軟體品質的影響很大，最後的結果就是誰在意品質，誰就痛苦。像是 Huli、龍哥也都說過類似的事。
也可以說我的品味建立在「紮實的基礎」上，當其他人的產出沒有符合我認為的基礎時，就是我的痛苦來源之一，久而久之連自己也會被影響。
我仍在尋找答案
就在昨天，Claude Code 因為人為失誤導致 Source Map 流出，人們可以很容易還原原始碼。就連 Anthropic 這些年薪破千萬台幣的工程師都會犯錯（但起因可能不是因為 AI）。那是否代表在乎基礎、資安問題、品質也已經不再重要了？
Coding is largely solved ——Boris Cherny
圍棋與棒球
AlphaGo 在十年前就打敗了世界第一的棋士李世乭、打敗柯潔，現在也沒有任何人類棋士能贏過 AI。圍棋在某種意義上已經被「解決」了——但圍棋並沒有因此消失。人們還是在下棋，還是有職業棋士，還是有人為了一手好棋而激動。
棒球也是。客觀來說，9+1 個人在場上丟球打球跑壘，對這個世界的運作沒有任何實質的幫助。所有競技運動大概都是如此。但人類就是會去做這些「沒有用」的事情，而且做得非常認真。
也許當 AI 把大部分的生產性工作都解決之後，寫程式也會變成一種更接近圍棋或棒球的活動——你寫程式不是因為非你不可，而是因為你在意那個過程本身。
下一步
隨波逐流。可能就是最好的答案吧。在科技奇點之前，還有一些事情是我想嘗試的。
- 把我心中的品味具現化成可以復現的標準
- 分享這幾年的軟體開發經驗，包含架構與技術選型
- 對日本軟體開發的一些想法
另外一點最近感觸有點深，但還沒有明確的想法成型，有進展再與各位分享。
最後分享一下《百米》裡我很喜歡財津的一段話：
不安は対処すべきではない。人生は常に失う可能性に満ちている。そこに命の醍醐味がある。 恐怖は不快ではない。安全は愉快ではない。不安とは君自身が君を試す時の感情だ。 栄光を前に対価を差し出さなきゃならない時、ちっぽけな細胞の寄せ集めの人生なんてくれてやればいい。
不安是不應該被處理的。人生總是充滿了失去的可能性。這就是生命的真諦。恐懼並不是不愉快的，安全也不是令人愉快的。不安是你自己在考驗自己的時候所產生的情感。在面對榮耀必須付出代價時，那微不足道的小細胞組成的人生就隨便給它吧。
你想做什麼呢？