當所有人都能寫程式，軟體工程師到底還剩下什麼？
執行被工業化了。判斷沒有。這就是我們正在走進的裂縫。
Turing Post 這週發了一篇長文，標題是「What Happens to Software Engineering When Anyone Can Build?」。作者 Ksenia Se 做了一件我覺得很有價值的事：她把幾篇不同作者、不同語境、彼此並未協調的文章擺在一起，試圖拼出一幅更大的圖。
Charlie Guo 談 harness engineering、Karpathy 談 bespoke software、Thomas Wolf 談重寫成本的崩塌、Andrew Ng 談需求的無上限、Russinovich 和 Hanselman 談初階工程師的人才斷層——這些人各自站在不同的山頭，但他們看到的是同一片風景。
我讀完之後，有些觀點覺得精準得令人不舒服，有些則覺得還沒說到最深的那一層。以下是我的消化。
工廠蓋好了，但品管員不夠用
文章提出的核心框架很簡單：軟體工程正在分裂成兩個學科。一個叫 harness engineering——設計約束、工具鏈、回饋迴路和文件，讓 AI Agent 可靠地運作。另一個叫 judgment manufacturing——培養能指揮、驗證、維護 Agent 產出的人類。
這個分法我覺得抓到了一個要害：我們正在以極快的速度把「執行」工業化，但「判斷」這件事完全沒有跟上。Agent 可以一週合併一千個 PR，但誰來判斷這一千個 PR 合併之後系統還是不是健康的？Stripe 的 Minions 每週產出那麼多程式碼，背後一定有一套嚴謹的 harness 在撐——但不是每個團隊都有 Stripe 的工程文化密度。
Guo 描述的那套 harness engineering playbook 本身是合理的：Agent-first 開發、架構即護欄、記憶可累積、先計畫後執行、不收爛 PR。但我想問一個更根本的問題：這套方法論假設了一件事——你的團隊裡有人知道什麼是好的約束。 約束不會自己冒出來。寫出一個好的 AGENTS.md 需要你先踩過足夠多的坑。設計一組有效的架構護欄需要你理解系統在哪些地方容易斷裂。這些都是資深工程師花了多年經驗才累積出來的直覺。
所以 harness engineering 不是一個「任何人都能做」的事。文章裡有一句話說「with agents, almost anyone can do a form of harness engineering」，我對此持保留態度。任何人都能「操作」Agent，但「設計讓 Agent 不容易犯錯的環境」是一種完全不同的能力。這就像說任何人都能開車，但不是任何人都能設計安全的道路系統。
Bespoke Software 的美麗與危險
Karpathy 那個跑步機儀表板的故事是一個很好的起點：他想要一個極度特化的心肺訓練追蹤器，App Store 上當然找不到，所以他用 Agent 在一小時內自己寫了一個。Andrew Ng 接著從經濟學的角度補上一刀——即使每個開發者變成十倍生產力，我們也不會只需要十分之一的開發者，因為客製化軟體的需求根本沒有天花板。
這兩個觀察結合在一起，描繪出一個趨勢：軟體從「包裝好的產品」變成「持續流動的客製工具」。文章甚至懷疑這已經不是 Software 3.0 而是 4.0 了。
我同意這個趨勢的方向，但我擔心的是另一面。
當每個人都可以用 Agent 快速搓出一個能用的工具，我們會看到的不是軟體品質的提升，而是軟體數量的爆炸。而這些 bespoke software 絕大多數不會有測試、不會有文件、不會有人維護。它們是即拋型的。用了三天覺得不對再搓一個新的。
對 Karpathy 來說這不是問題——他有判斷力知道什麼時候該信任 Agent 的產出、什麼時候不該。但對一個沒有工程背景的行銷人來說呢？他不知道那個 Agent 幫他寫的資料處理腳本裡有一個靜默的浮點精度問題，會在三個月後讓他的報表出現微妙的偏差。他甚至不知道自己不知道。
Bespoke software 的真正風險不是它「不能用」，而是它「看起來能用但暗藏問題」，而使用者不具備發現問題的能力。 這是一種新型態的技術債——分散在每一個非工程師的桌面上，沒有人在管理，沒有人在追蹤。
重寫的誘惑
Thomas Wolf 的觀察更大膽：如果重寫和理解陌生程式碼變得便宜，依賴樹就從超級武器變成負債。為什麼維護一棵深度依賴樹，如果 Agent 可以直接提取你需要的東西或乾脆重寫？更少的依賴意味著更小的攻擊面、更小的套件、通常也更快的軟體。
文章對 Lindy 效應的討論也很精彩。真正讓老系統存活的不是它們「好」，而是「替換它們的痛苦太大」。如果 Agent 讓替換痛苦降低，老系統就失去了部分護城河。
但我想在這裡提一個反面觀點。
重寫成本下降不代表重寫風險下降。一個在生產環境跑了十年的系統，它身上帶著的不只是程式碼，而是十年的 edge case 處理、十年的業務邏輯修補、十年的隱含假設。這些東西不在程式碼的文字裡，而在程式碼的「上下文」裡。一個函式為什麼要先做一次看似多餘的空值檢查？因為七年前有一個客戶的資料庫有一筆奇怪的 null，導致了一次嚴重的線上事故，工程師在事故後加了這行，但沒留任何註解。
Agent 可以讀程式碼，但它不能讀歷史。它可以翻譯，但它不知道為什麼有些句子是故意寫得那麼彆扭的。
Wolf 自己也意識到了這一點，所以他才說 formal verification 在 AI 主導的時代不再是可選項。但我認為問題比 formal verification 更深。Formal verification 能證明程式碼符合規格，但它不能告訴你規格本身是否完整。 那些 unknown unknowns——系統在十年運行中遇到過但從未被明確記錄的邊界情況——不在任何規格文件裡。它們活在老工程師的記憶中、活在隱晦的 commit message 裡、活在 Slack 頻道的考古對話裡。
重寫的成本正在接近零。重寫的風險不是。這個落差會讓很多團隊付出代價。
判斷力的培養危機
所有這些論點匯流到 Russinovich 和 Hanselman 的那篇 CACM 文章，我覺得也是整篇裡最讓人不安的部分。
邏輯很簡單：AI 編程助手放大資深工程師的能力，因為資深工程師有判斷力去駕馭 Agent 的產出。初階工程師沒有，所以同樣的工具反而可能令他們跑偏。隨之而來的經濟誘因就是：少雇初階的，讓 Agent 吃掉初階的工作。
但你不是「雇來」下一代的資深工程師的。你是「長出來」的。如果整個產業都停止培養初階人才，十年後的資深工程師從哪裡來？
他們提出的解方是結構化的學徒制：讓三到五個初階工程師配一位資深導師，做一年以上的深度指導。甚至建議 AI 助手要有「初階模式」，預設用蘇格拉底式的提問引導，而不是直接吐答案。
這個方向我完全支持，但我擔心的是執行面。在短期績效壓力下，哪個主管會選擇讓資深工程師花 30% 的時間帶人，而不是讓他配六個 Agent 去產出三倍的 code？培養人才的回報週期是年，而企業的考核週期通常是季。
而且問題不只在「有沒有人帶」。初階工程師的成長有一個很大的部分來自「自己踩坑」——寫出有 bug 的程式、部署後爆炸、凌晨被叫起來修、隔天早上回頭看自己的程式碼想摔鍵盤。這個過程很痛苦但不可替代。如果 Agent 在你犯錯之前就幫你修好了，你永遠不知道自己會犯什麼錯。你的判斷力不是被教會的，是被失敗鍛造出來的。
Agent 可以加速學習，但不能替代犯錯。 如果我們用 Agent 來消滅所有犯錯的機會，我們也消滅了成長的空間。這不只是一個教育問題，而是一個文明層級的判斷力危機。
我不完全同意的地方
讀完整篇文章之後，有一個隱含的假設我想挑戰：文章在很大程度上把「軟體工程」當成一個統一的東西在談它的分裂。但軟體工程從來就不是一個統一的東西。
寫一個跑步機追蹤器和維護一個金融交易系統所需要的能力完全不同。前者 Karpathy 在一小時內搓出來沒問題，後者你讓十個 Agent 跑一個月也未必敢上線。文章裡有提到「deep engineering remains essential when stakes go up: security, reliability, performance, compliance, messy integrations」，但我覺得這一句被淹沒在了整體的「harness engineering 是新趨勢」的敘事裡。
實際情況可能是：我們正在看到的不是軟體工程的「分裂」，而是一次「光譜的拉寬」。左端是零成本的即拋式 bespoke software，右端是高風險、高複雜度、需要深度工程判斷的系統。中間的灰色地帶——那些「有點重要但不致命」的軟體——會越來越被 Agent 吃掉，而兩端會越來越極端。
左端不需要傳統意義上的軟體工程師，右端對工程師的要求反而比以前更高。問題是，大部分工程師現在都站在中間那個正在消失的地帶。
最後
文章最後一句話寫得好：「If we don’t train that skill on purpose, we’ll ship more software than ever and end up in encoded chaos: code that passes automated checks, looks fine, and still breaks in the real world.」
我想補一個更暗的版本：我們可能不只是 ship more software。我們可能會 ship more confidence。每個人都覺得自己的軟體「能用」，因為 Agent 幫你通過了所有的自動化檢查。但「通過檢查」和「正確」之間的距離，恰好就是判斷力所填補的那道縫隙。
而這道縫隙正在以一種很難被察覺的方式擴大。不是因為工具變差了，恰恰相反，是因為工具變得太好了——好到讓人以為不需要判斷力也可以。
這大概就是最危險的地方：不是我們失去了判斷力，而是我們失去了「我們需要判斷力」這個認知本身。