編按：本文綜合整理自 Florian Herrengt 個人部落格 與 Hacker News 討論串，並加入 Siami 編輯部觀點與分析。作者 Florian Herrengt 為德國軟體工程師，本文是他 2026 年 8 月 11 日發表的職場觀察長文。
一個 25,000 行的 PR：六年前 vs 今天的對比
故事從 2020 年說起。Florian 假設你是一個五人團隊裡最資深的工程師，負責程式碼品質與架構。你建立了一套穩健的 review 制度，認真地批改資淺同事送的 PR，把 codebase 維持得乾乾淨淨。然後某一天你出國度假兩週，回來發現一切都崩壞了——同事彼此 merge 彼此的 PR、有人為了方便把資料庫反正規化、有人把 Kafka 加進 stack 但根本沒人能說出為什麼要加。
當年你可以收拾這個殘局。然後快轉到 2026 年，你根本沒出門，只是個普通的週一早上。你沖了杯好咖啡、打開電腦，看到桌上躺著 7 個 PR 等著你 review。你打開第一個：
+24,506 −3,938 行，附帶一份 AI 生成的描述。
你的團隊光這個週末寫的程式碼，比你以前出國兩週累積的還多。
「AI 取消了速度上限」
Florian 把這篇文章的副標寫得很直接：「AI 讓工程文化薄弱的專案死得更快。」
過去一個團隊在動手前會坐下來討論該怎麼做。現在，工程師可以花個幾小時 prompt 一個 agent，然後直接開 PR。最悲劇的是，這套工作方式在外行人眼中「看起來有效」——你 pull branch 跑測試，多半會得到一個大致能跑的東西。所以他們繼續衝，一次又一次，直到專案進入「沒人知道系統到底怎麼運作」的狀態。
「就像刷卡買一台新的豪華車，當下看不到負債，只看到一台漂亮的車。」
當 Bug 連 AI 都修不好的時候
接下來使用者回報一個奇怪的 bug，這已經是團隊第 4 次嘗試修它了——準確地說，是第 4 次叫 AI 修它。你走去找負責這個功能的工程師：
「這份資料到底從哪來？」 「嗯……其實我不知道，讓我問 Claude。」
兩個工程師並肩坐著看 Claude 一行一行吐出文字，誰也不確定那些內容是不是真的，但 Claude 看起來非常自信。
「我們把 ultracode 打開，叫它 double-check 一下？」
這次等得比較久，兩個人開始聊 X 上的最新八卦。終於 Claude 回覆了：
「這樣寫你看懂嗎？」 「我不太確定。」 「這個不是你上週自己寫的嗎？」 （沉默。）
Florian 寫道：「這個專案已經變得如此糾結，層層疊疊的服務架構讓你團隊裡沒有任何人能真的理解底層發生什麼事。」
你再也「養不起」菜鳥工程師了
Florian 列了一張清單，列出故事中每一個「失敗」的環節：
- 那個開 25,000 行 PR 的工程師，應該在 agent 失控之前就把它叫停，把工作拆小、質疑每一個新加的抽象層。
- 那個負責 review 的人，應該拒絕 review 這麼巨大的 PR，而不是妥協放行。
- 那個加 Kafka 的工程師，應該能講清楚為什麼需要 Kafka。
- 那個寫 feature 的人，應該能解釋資料從哪來——而不是丟一個 Claude 對話連結。
「那我們就叫 AI 修啊？」——沒那麼簡單。
Florian 強調，他不是在說技術債一定是壞事。重點是你必須知道那是條捷徑。
LLM 花 10 分鐘就能在資料庫裡加一堆表格欄位；但一旦資料寫入後，你想拿掉它就得寫 migration plan、確認不會在半夜掛掉、防範孤立的外鍵。修一個爛決策的成本遠比當初做出來高。即使你用了最強的模型也一樣。
「新的 AI 經濟」
Florian 寫道：當然，糟糕的工程師一直是負債。這件事幾十年來都這樣，早在 OpenAI 或 Anthropic 存在之前就這樣。壞決策會累積、不必要的複雜度會堆疊、最後團隊就在維護一個沒人真的理解的系統。
差別在於：過去你做這些壞事有速度上限。
「今天，『實作』這件事已經變便宜了。你領高薪，是因為公司要你做出好的決定——是因為你能寫出會 scale 的軟體，同時管理複雜度。」
Florian 提出一個尖銳的問題：如果公司只需要把規格轉成可執行的程式碼，那他們為什麼要付倫敦或舊金山六位數高薪？為什麼那些宣稱「軟體開發問題已經被 AI 解掉」的大公司，還在砸重金搶最好的人才？
他的預測是：AI 會讓薪資兩極化。
要能在這個產業存活，你必須跨過一道門檻——門檻的高度，就是當下最強模型的能力。好的工程師會因為 AI 讓他們更快而更有價值，他們身邊不再需要一堆人幫忙做純實作。但糟糕的工程師會變得更難被雇用，因為他們造成的破壞速度太快了。
Florian 早先在另一篇文章《vibe coder 的職涯注定完蛋》裡也提過：「你必須貢獻一些超出『給 agent 一段 prompt』就能得到的東西。如果你沒有能力判斷 LLM 的建議，光叫它再『多想一下』根本解決不了問題。」
🚨 為什麼這件事重要
這篇文章之所以在 Hacker News 拿到 240 分、213 則留言（截稿為止），不是因為它點出了一個新現象——而是因為它把大家私下感覺但說不出口的問題一次講清楚了。
第一，「速度」不等於「價值」這件事，現在第一次被量化。 一個資深工程師一年寫 5,000 行 production code，AI 一個下午就能產出 20,000 行。但這 20,000 行帶來的技術債，可能要那個資深工程師花六個月才能收拾完。過去「review 速度」是天然的安全閥，現在這個安全閥已經被打穿。
第二，Florian 點出了一個大多數 AI 行銷文章故意迴避的現實：vibe coding 的天花板是「判斷力」，不是 prompt 能力。 一個 25,000 行的 PR 之所以會發生，是因為工程師自己不知道自己在做什麼。如果 AI 不會讓你「變懂」，那就只會讓你「更快地變不懂」。
第三，這個觀察不限於軟體業。 Florian 在文章結尾寫道：「我認為這件事不會只限於軟體工程。AI 會讓最好的人產出大幅提升，讓最差的人幾乎無法被雇用。」法律、會計、行銷、顧問——只要是「知識工作」這個賽道，都在走同一條路。差別只是軟體業因為生成式 AI 進展最快，最先撞到這個牆。
第四，這也跟矽谷最近的「頂端集中」完全吻合。 Anthropic、OpenAI 的高階主管公開承認公司內部已經在縮減「中階」名額；Meta、Google 在 2024-2026 年的大規模 layoff 都是把責任往外推、把決策權往上收。如果連最頂尖的科技公司都這樣調整，一般企業跟進只是時間問題。
🚨 數據解讀與質疑
雖然這篇文章獲得很高的社群共鳴，但有幾點 Siami 編輯部必須老實提出來：
1. 樣本偏差： Florian 是單一作者、單一觀點，他描述的場景雖然普遍但並非全部。事實上，很多團隊在導入 AI coding 工具後，新人 onboarding 速度反而加快（因為他們可以邊寫邊問 Claude），這跟「AI 讓菜鳥更難雇用」是相反方向的證據。
2. 沒有量化： 文章沒有引用任何統計數據——沒有 Atlassian、GitHub、Stack Overflow 的官方調查，也沒有獵頭公司的薪資中位數變化。「好工程師更有價值、差工程師更難雇用」聽起來合理，但要說服企業 HR 還需要更多客觀資料。
3. 沒考慮「程式碼生成」的下一步： Anthropic、Cursor、Devin 這一波工具目前還在第一代，未來幾個月會有更專注於「理解整體 codebase」而非「產出局部 patch」的模型。換言之，今天 vibe coder 犯的錯，可能就是明天「會自動偵測抽象層過度設計」的工具被開發出來的理由。
4. 「頂端集中」的因果關係還沒釐清： 大公司縮減中階名額，也可能是因為疫情後過度擴張正在修正——跟 AI 的因果關係需要更嚴謹的研究才能斷定。
但即便如此，這篇文章仍點出了一個真實的職場警訊：AI 給了所有人不對稱的能力槓桿。在你能駕馭這個槓桿之前，它只會放大你原本的弱點。
對台灣與中文開發者的啟示
對台灣的軟體業來說，這篇文章有三層意義：
-
外包文化需要重定位。 台灣過去承接大量美、日軟體外包，這些案子很多是「規格明確、實作單純」的傳統工程——正好是 AI 自動化最快的區段。短期內產值還在，但 2-3 年後毛利勢必壓縮。轉型到「判斷 + 整合」是必然趨勢。
-
新進工程師的訓練模式必須改。 如果職場不再有「中階」這個位置，大學 CS 學程與企業內部培訓都必須從「教你寫 code」轉為「教你 review code」。後者需要更深的系統思維、更強的 domain knowledge，這是當前教育體系普遍缺乏的。
-
個人品牌比團隊頭銜更重要。 當「我在某公司當 senior engineer」這個 title 越來越難撐起六位數薪資，能證明「我能為複雜系統做出正確判斷」的個人聲譽，將會成為 AI 時代最值錢的貨幣。
Florian 給的不是一個答案，而是一面鏡子——它照出的是一個讓所有工程師都必須正視的問題：當工具給了所有人不對稱的槓桿，你要嘛成為那個會用的人，要嘛成為被它放大弱點的人。
網友熱門留言 (5)