Code 變便宜後，工程師的價值換了位置
當程式碼產出不再稀缺，真正拉開差距的是問題定義、架構判斷與把系統做得可維護、可更新、可驗證的能力。
有些轉折不是技術本身造成的，而是「證明能力」的方式被改寫了。
二十多年前，Linus Torvalds 那句「Talk is cheap. Show me the code」之所以有力，是因為把想法落成可跑的程式碼，本身就要付出時間、經驗與認知負荷。你能交付程式碼，往往就代表你真的懂。
今天，這個等式正在失效。
LLM 把「寫出來」這件事的門檻壓到很低：語法熟練度、框架肌肉記憶、甚至打字速度，都不再是稀缺資源。程式碼變得像空氣一樣容易產出，能力證明也跟著變得模糊。
Code 變便宜以後，貴的是什麼
我在工作裡看到的變化很具體：
- 問題定義變得更重要：你描述得不清楚，模型就會很誠實地把錯誤放大。
- 系統架構變得更重要：把一堆「看起來可用」的片段組成能長期演進的系統，才是難題。
- 批判思考變得更重要：模型很會給答案，但不會替你承擔錯的代價。
當程式碼輸出不稀缺，判斷輸出的能力才是差距。
會用的人是加速器，不會用的人只是更快撞牆
我同意那個中間派的觀點：LLM 對熟手是加速器，對新手則可能是遮羞布。
熟手有足夠的直覺去拆解需求、切出邊界、設定驗收標準，也能把模型產出的東西當作草稿來審稿。
新手如果從第一天就把「能跑」當作終點，很容易跳過那些很痛苦、但會長出判斷力的基本功：
- 讀錯誤訊息、追 stack trace
- 了解資料流與狀態變化
- 把抽象概念落地成可測試的模組
這些能力不是為了炫技，而是為了在系統失控時能把它拉回來。
下一個稀缺能力：secure code 與更新速度
原文底下有個回覆我覺得很點：未來更值錢的會是「你能不能維護安全的程式碼」，以及「你能不能把更新速度拉上去」。
原因很現實：攻擊者也會用 AI。漏洞挖掘、PoC 生成、釣魚腳本、社工內容的產出成本都下降，安全循環會被迫加速。另一方面，研究員也會用 AI 更快找到問題、更快釋出修補，結果就是企業面臨更密集的升級壓力。
這會把工程團隊推向兩條分岔路：
- 一邊是「寫得快」
- 一邊是「寫得對、修得快、能持續運營」
真正拉開差距的，會落在流程與基礎建設：測試、回歸、觀測性、依賴管理、部署策略、權限與金鑰治理。
Talk 的價值，其實是可驗證的判斷
如果把那句話翻成今天的版本，我更在意的是：
你能不能把問題講清楚、把風險講清楚、把 trade-off 講清楚，然後把結果交付成一個可以被驗證、可以被維護的系統。
程式碼可以很便宜，但判斷不會。
原文連結：Threads 貼文
