前言：當「寫得更少」反而做得更多
最近出現一個不太直覺的現象：
實際寫下的 Code 變少了，但系統產出反而變多。功能推進更快、跨領域專案可以同時進行，甚至在 Driver 與團媽系統這種性質完全不同的場景中，都出現了類似的開發節奏。
如果只看結果，這應該是效率提升。
但問題在於：
當 Code 不再是主要產出，工程師的價值，還剩下什麼？
1. 被誤解的疲倦：不是寫 Code，而是開發摩擦力
所謂的倦怠，其實很少來自「解決問題」本身，而是來自長期累積的開發摩擦力：
- 環境與依賴的反覆衝突
- 無法穩定重現的錯誤
- 為了讓系統運作而存在的大量過渡代碼
- Debug 過程中不可預期的時間消耗
這些活動的共同特徵是，它們幾乎不直接創造價值，只是維持系統能繼續運行。
當大部分時間被這些摩擦力佔據時，「寫 Code」會逐漸從創造行為，變成維持秩序的勞動。
2. 一個關鍵的卡點：系統其實沒有被定義
轉折出現在一個意外的地方——團媽系統的對帳邏輯。
如果用傳統方式實作，問題並不複雜：
資料對齊、金額計算、例外情況補上條件判斷，系統就能運作。
但當嘗試把這段邏輯交給 AI 時，問題反而被放大了。
困難不在於 AI 寫不出程式，而在於一個更根本的問題：
無法清楚說明，什麼情況算「正確」，什麼情況算「錯誤」。
這種模糊在過去往往被人力吸收掉。
工程師可以透過經驗反覆修正，讓系統「看起來是對的」。
但 AI 不會這樣工作。
它會忠實放大規則的不完整，讓問題無法被掩蓋。
這時才會意識到：
系統之所以能運作，不代表它已經被定義清楚。
3. Driver 與團媽系統，其實是同一個問題
把視角拉回 Driver 專案，會發現同樣的結構：
- protocol 規範是否完整
- 錯誤處理是否有明確邊界
- 裝置行為在例外情況下是否仍然可預期
在這些問題上，系統往往「可以運作」，但不代表「可以被推導」。
兩個領域看似不同，本質卻一致：
當邊界沒有被清楚定義時，系統的正確性其實是偶然的。
4. AI 的真正作用：放大模糊，而不是解決模糊
AI 並沒有讓開發變簡單，而是讓一種原本可以忽略的問題變得無法忽略。
當邏輯被轉換成「需要明確描述」的形式時，系統至少需要具備三個元素：
- 邊界定義（什麼是合法）
- 執行邏輯（系統如何運作）
- 驗證機制（如何判斷結果正確）
只要其中任何一項不完整，輸出就會變得不穩定。
這種不穩定，不是 AI 的問題，而是設計本身的問題。
5. 工程師的角色正在轉移
當上述過程反覆出現，角色的重心會自然轉移：
- Code 仍然存在，但不再是核心資產
- 定義邊界與驗證規則，開始主導系統品質
這帶來一個不太容易接受的事實：
Code 可以被大量生成，但「什麼是正確」無法被外包。
結語：那剩下的 10%，真的叫「品味」嗎？
一個常見的說法是：
AI 可以完成 90% 的 Code，剩下的 10% 是「品味」。
這句話直覺上成立，但如果進一步追問，就會出現問題：
所謂的「品味」，如果只是指：
- 簡潔的結構
- 適度的抽象
- 避免過度設計
那這些東西其實可以被學習、被規則化，甚至逐漸被 AI 模仿。
但在實際系統中，真正困難的從來不是這些。
困難的是：
在不完整資訊與模糊情境中，仍然能劃出一條可被驗證的邊界。
在團媽系統中，是金額何時算正確；
在 Driver 中，是裝置行為何時被視為合法。
這些問題沒有標準答案，也難以完全形式化。
但只要邊界沒有被定義清楚，系統的穩定性就無從談起。
因此，那剩下的 10%，或許不是「品味」，而是另一種能力：
在不確定中定義正確性的能力。
如果這個判斷成立，那未來工程師的分水嶺，可能不再是誰寫得更快，而是誰更清楚自己在定義什麼。
至於這種能力，究竟能否被系統化、被訓練，還是只是被重新命名的「品味」，目前仍沒有答案。
但可以確定的是——
當 Code 不再稀缺時，
「定義」本身，會變得非常昂貴。
