AI 沒有取代工程師，但正在淘汰「只會寫程式的人」：談 AI 時代下的軟體工程價值轉移
摘要：當 Claude Code、Cursor 與 Copilot 等 Agent 級 AI 工具能在一分鐘內生成千行程式碼時，軟體開發的瓶頸已從「程式碼產出速度」轉移至「系統認知與驗證能力」。本文從實際工程案例、團隊 KPI 盲點、認知負荷到架構師思維，深度探討工程師的核心價值該如何重新定義。
一、 事情是怎麼變化的？從「程式碼撰寫者」到「監工」
最近 Business Insider 一篇報導引發廣泛討論：一位資深工程師抱怨自己每天工作 12 到 13 個小時，卻只是在不斷按下
Enter，讓 Claude Code 幫忙完成產品規格、單元測試、API 文件與業務程式碼。他感嘆自己「正在失去身為工程師的靈魂」。觀看目前的開發現場，這種感覺並不陌生。過去與現在的開發工作流已經發生根本性的改變：
【傳統開發工作流】
需求分析 ──> 架構設計 ──> 手寫程式碼（主要時間瓶頸） ──> 單元測試 ──> Code Review ──> 部署
【AI Agent 時代工作流】
需求分析 ──> Prompt / Context 餵給 AI ──> AI 生成程式碼 ──> 驗證與 Code Review（新瓶頸） ──> 部署
以前開發者的主要產出時間花在撰寫與實現；現在的時間則大量轉移至理解、邏輯審查與邊界條件驗證。
二、 產出的通膨與「認知速度」的極限
以 Laravel 12 開發一個標準的「會員訂閱與權限管理模組」為例：
- 傳統做法：手寫 Migration、Model (包含 Relation & Scope)、Controller、Form Request Validation、Service / Action Layer、API Resource、Event / Listener 以及 Feature Test。手動刻完並確認細節，可能需要半天到一整天的專注時間。
- AI 時代：下達指令
請依據 Laravel 12 最佳實務建立會員訂閱模組，包含 Stripe Webhook 處理與乾淨的 Domain Service，AI 可以在幾分鐘內一口氣產出十幾個檔案。
看似生產力暴增 10 倍，但「AI 寫程式的速度」遠遠超過了「人類大腦理解與審查程式碼的速度」。
這種產出速度與認知速度的不對稱，正在帶來新的系統性風險：
- Pull Request 體積暴增：過去一個 PR 包含 200 行程式碼，現在動輒 2,000 行，導致 Code Review 流於形式，大家都蓋章（LGTM） passed。
- 微小的邏輯隱患被稀釋：AI 產出的程式碼語法完美、風格乾淨，甚至連註解都寫得很漂亮，但暗藏在邊界條件（Edge Cases）裡的邏輯缺陷極難被眼尖察覺。
- 黑盒化與知識斷層：工程師對自己專案庫的熟悉度下降。當整套系統有 70% 的程式碼是 AI 生成且未經深度消化時，一旦發生線上事故（Outage），無人能第一時間定位問題。
三、 管理者的 KPI 盲點：產出（Output）不等於價值（Value）
當前許多工程團隊管理者開始陷入一種盲目的樂觀，用以下指標來衡量 AI 導入的成功：
- Sprint Velocity（衝刺速度）暴增多少？
- Story Points / PR 提交數量增加多少？
- Feature 交付時間縮短多少？
這些指標衡量的全是「產出（Output）」，而不是「業務價值（Business Value）」。
假設 AI 幫團隊一天產出 10 個功能，但如果這 10 個功能：
- 沒有精準解決使用者的核心痛點（產品定位偏差）
- 增加了系統併發時的 DB Deadlock 風險（架構設計缺陷）
- 引入了未考慮到的併發安全性問題（Race Condition）
- 帶來巨大的後續維護成本（技術債累積）
那麼，這 10 個功能的產出非但沒有創造價值，反而是在為企業製造未來的營運風險與負債。
工程團隊真正的瓶頸，從來不是「寫程式的速度」，而是「搞清楚真正的問題是什麼」。
四、 寫程式是工程師最廉價的能力，昂貴的是「技術取捨（Trade-offs）」
在 AI 時代，語法與基礎實作能力正快速貶值。任何懂 Prompt 的人都能讓 AI 生成漂亮的 Redis 快取邏輯或 RabbitMQ 消息佇列（Queue）代碼。
但 AI 無法為你做出高階的架構決策（Architecture Decisions）：
案例 1：快取策略與資料一致性
AI 可以秒寫出 Redis
Cache::remember() 的程式碼。但它無法替你回答：- 這個資料的讀寫比是多少？值得佔用 Redis 記憶體嗎？
- 在高併發情境下，如何防範快取穿透（Cache Penetration）與快取雪崩（Cache Avalanche）？
- 業務場景容許最終一致性（Eventual Consistency）嗎？如果失效策略設計錯誤導致使用者看到舊資料，對業務的損失有多大？
案例 2：非同步架構與併發控制
AI 可以輕鬆寫出 Queue Job 與 Event Listener。但它無法替你做出以下取捨（Trade-offs）：
- 當佇列積壓（Queue Backlog）達 10 萬筆時，系統的降級機制（Fallback）是什麼？
- 關鍵的交易 Job 是否做到了冪等性設計（Idempotency）？
- 系統延遲（Latency）、資料一致性（Consistency）、營運成本（Cost）與開發複雜度（Complexity）這四者之間，目前的業務階段應該偏向哪一方？
做出取捨、設計邊界、並為系統的穩定性承擔責任，這才是工程師無法被取代的核心價值。
五、 工程師的兩極化分流：AI Operator vs. AI Architect
未來 3 到 5 年內，軟體工程師將加速分化為兩種完全不同的形態：
┌─────────────────────────────────────────────────────────────┐
│ AI Operator │
├─────────────────────────────────────────────────────────────┤
│ 模式：需求 ──> 複製給 AI ──> 複製貼上 ──> 提交 PR │
│ 思維：將大腦「外包」給 AI │
│ 危機：缺乏深度理解，工具一旦升級，其可替代性極高 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ AI Architect │
├─────────────────────────────────────────────────────────────┤
│ 模式：問題定義 ──> 系統設計 ──> 任務拆解 ──> AI 執行 ──> 嚴密驗證 │
│ 思維：將 AI 作為「外骨骼（Exoskeleton）」 │
│ 優勢：把省下的打字時間，投入至模組邊界、效能與商業邏輯 │
└─────────────────────────────────────────────────────────────┘
- AI Operator（AI 操作員）：
- 特徵：遇到問題第一時間問 AI，直接複製貼上 AI 給的程式碼；只要程式碼能跑通就提交，不關心底層原理與效能衝擊。
- 命運：價值被快速壓縮。因為他的核心能力只是「操作介面」，一旦 AI 工具更加自動化，此類角色將首當其衝被邊緣化。
- AI Architect（AI 架構師）：
- 特徵：擁有紮實的電腦科學基礎（OS、網路、資料庫、設計模式），將 AI 當作「高效率的打字員與初級助理」。由他來定義問題、拆解架構、設定約束條件，最後進行極為嚴格的防禦性審查（Defensive Review）。
- 命運：生產力被放大數倍。他能用過去三分之一的時間完成系統設計，並將更多精力放在業務理解、技術選型與團隊賦能上。
六、 結語：淘汰你的不是 AI，而是「放棄思考」
當 Production 環境在半夜三點爆發 DB 死鎖、Kubernetes 節點 OOM（Out of Memory），或是 Queue 發生嚴重堵塞時，AI 可能會給出 5 種看起很合理的解決方案。
這時，真正有價值的人，絕不是那個只會按 Enter 的人，而是那個能夠憑藉經驗與對系統全貌的掌握，準確判斷出「前 4 個方案會引發二次災害，只有第 5 個方案才是根本解」的人。
AI 的普及，正在將軟體工程回歸到它的本質：解決問題。
如果公司只獎勵「寫程式碼的速度」，而不獎勵「理解系統的深度」，工程師確實會逐漸變笨。但身為專業的工程技術人員，我們必須意識到：程式碼只是解決問題的手段，而不是目的本身。
當人人都能用 AI 在幾秒鐘內產生千行程式碼時，最終能站穩腳步的，絕對不是打字最快的人，而是最懂得思考、最精準定義問題，並能做出正確技術取捨的人。
