編譯說明：本文譯自 adrq（Adam Quinton）發表於其個人部落格的〈Here Be Monsters: What Do You Still Need to Know When Agents Do the Work?〉（原文連結），HN 討論串為 #50258868（10 月 28 日抓取時 183 分、97 則留言）。人名首次出現附原文，之後只寫中文。文末附 HN 網友討論整理與視覺懶人包。
CI 掛了。出乎意料。我的 agent 工作流已經調到一個程度：如果 agent 交出來的分支測試會掛，我會很驚訝。是 CI flake 還是環境問題？結果是 SonarQube 在抱怨 App.tsx？難道拉進了什麼可疑的 npm 相依套件？沒有。SonarQube 挑的是圈複雜度。好久沒見過這個了。
沒錯，App.tsx 號稱三十行，實際上其中十五行、每一行都是一個完整的 component，全是 Codex 寫的，而且是每個 component 各佔一行。這本身倒還好，丟給 prettier 格式化就完事。但這解釋不了圈複雜度。這些 component 每一個都不單純，顯示邏輯加商業邏輯份量十足。以前的我會小心重構，確保程式碼可讀。但 Codex 不在乎整坨 component 擠在一行，更不在乎複雜度。好幾個功能一路下來，它在這個檔案裡迭代得又穩又開心。
CI 工具 flag 了一個問題，可能對，可能錯。但這是正式系統，我得親自跳下去。格式化之後，我把 component 和邏輯逐一檢查。Codex 有沒有比一般工程師更愛覆蓋邊界案例、有沒有稍微過度設計？有，但全是對的，我沒什麼好抱怨。複雜度都是業務需求撐起來的。於是我叫 Codex 去把 SonarQube 哄開心，它照辦，拆成十個檔案。CI 過了，東西上線。這次收尾很快，但你大概想像得到事情可能糟得多。畢竟，這份 code 我之前一行都沒看過。
這就是我們產業的走向：擁有一個軟體系統，越來越不取決於你有沒有親手寫過它（或類似的系統）；最重要的反而是：懂得到剛好能察覺不對勁，並且在必要時願意、有能力潛到多深去看。
潛水機器人與金塊
想像你在船上（什麼船隨你挑），工作是從海底撈小金塊。直到最近，想拿一袋金子，你得自己跳下水、游到底、四處張望、裝滿袋子。在清澈淺水裡很簡單，但你想像得到事情多快會變難。淺礦挖完之後，你和同行造出各種機器工具，去越來越深、越來越危險的水域採礦。多半管用：你們小心組裝、維護、輪替機器，不時潛到海底礦場維持運轉。偶爾聽說某處礦場崩了，有時是水壓，有時是意外，有時是操作員太菜。麻煩的是這片海地質活躍，海床一直在變，舊礦枯掉，新礦在別處冒出來。
好消息是：近幾年潛水機器人（divebots）越來越強，能自己潛下去蓋出一座礦場。你只管指位置，它們潛下去，只浮上來回報進度、交出金塊。日子太美了，你在船上躺著，煩惱只剩船艙塞得下多少金子。這是樂觀派。
直到……「等你的機器人潛太深迷路你就知道了」、「哈哈你的機器人撈回來看像金子、其實是發光章魚屎」。機器人一多，恐怖故事跟著來：迷路、忘記自己要蓋什麼；蓋出複雜畸形的東西，自己都維護不動，最後被下一代機器人整個丟掉。海底礦場從精心設計的大教堂，變成暗藏密道和怪物的拼裝豪宅。你離作業越遠，失敗越壯觀。這是悲觀派。
此地有怪獸
軟體工程業（我懷疑很多產業很快跟上）正在經歷上面那一幕。你大概已經知道自己是悲觀派還是樂觀派，哪怕還沒決定押哪邊。
傳統智慧說：要開發維護一個像樣的系統，你得有像樣的工作模型（working model）。這句大概沒什麼人反對。在軟體業，這個模型是靠親手碰 code 長出來的：經年累月寫 code、讀 code，每次 production incident、每次半夜 debug、每次成功上線，都在長出擁有一個系統所需的視角。這裡的擁有意思是：半夜壞掉時，被 call 起來的是你。
Agent（潛水機器人）把這整套掀了。機器人產出比人吸收快得多；以前的複雜系統，你至少能假設 code 曾經經過人手，現在不行了。有經驗的人可以指揮一支機器人艦隊，以前所未見的規模寫軟體。這些人懂行，帶著深厚經驗，管出以前要整個團隊才蓋得起的大系統。但這掀出產業最大的難題：下一代工程師怎麼練出來？
兩極的答案差很大。一邊是有頭有臉的人說：要掌控系統，只能逐行讀懂機器人吐出來的 code。要能親手寫出來。要能解釋每段 code 在幹嘛、在系統裡的位置。另一邊同樣有頭有臉的人說：看都別看，把力氣花在決定做什麼，怎麼做交給模型。我認為兩邊都不對。
事實是：今天資深工程師那套學法，親手寫、無盡 debug、production incident，這條路對新人已經走不通了。說清楚，是經濟上走不通：指望公司花幾年養新人「親手練」，想都別想。常聽到的替代方案，「agent 寫的每行都要看懂」、「跟資深 pair」、「認真 code review」，除了極少數店家，同樣是想都別想。誰相信產業界會普遍這麼幹，我有座橋想賣你，來談。
要找出可行的精通之路，得先看擁有一個像樣的軟體系統是什麼意思。想想你見過的架構師、tech lead、CTO 怎麼運作：成功的人腦中都有系統的模型，一張海圖。真正的問題是顆粒度。想像一個百萬行 legacy codebase，多年下來多人經手，CTO 搞不好當年寫過其中幾塊。現在半夜兩點 production 出事，倒楣的 SRE，同時被不同時區的人傳訊轟炸，要他找出問題。這時需要的海圖是什麼？一張高空全系統地圖，加上剛好夠用的判斷力：知道該潛哪裡，知道怪獸住哪，知道怎麼跳進任何沒見過的 codebase，搞懂狀況、推 hotfix、把 incident report 寫清楚。
注意，這不是全系統的細節知識。複雜系統只能靠抽象管理，一層疊一層，每層多蓋一點。但不管地圖多大，記住下面全是抽象，一層漏一層，沒人真懂每一層。「我親手寫了模組 X，裡外皆熟」和「我有合適的系統抽象模型，哪個模組壞掉都潛得下去修」，是兩回事。親手寫 code 給你前者，但半夜被 call 的人需要後者。
這張圖怎麼長出來？一個沒親手撈過金子的人，憑什麼跳進未知水域、收拾機器人留下的爛攤子？
基本功、廣度、即時深度
複雜系統最陰險的失敗是靜默失敗：大致能跑，但哪裡怪怪的。突然變慢，錯誤率微升，或者平時好好的、每第十九次壞一次。不到半夜被叫醒的程度，但你就是覺得不對勁。系統擁有者，得懂系統的失敗模式。而我們產業本來就會教人偵測、推理這類失敗：基本功。好消息是，我們已經對著不知情的大學生教了幾十年：資料結構與演算法、網路、並行、分散式系統。不必正規教育出身，這些都能自學。
畫個簡單的圖（資深工程師請忍耐）：你派潛水機器人出任務。淺水區，兩米深，撈金塊，四秒回來，很好。下次四米深，這次花了十六秒，怪了。再下次十六米深，花了兩百五十六秒。你看出來了，哪裡不對。在電腦科學裡這叫平方複雜度，而認出它的最好辦法，是學過理論，知道有這種東西存在。
這帶出擁有的第二根柱子：廣度。我合作過的最強工程師和技術主管，幾乎什麼題目都能聊，不管技術非技術。他們可能各有專精，但最厲害的，是隨手把不同領域的概念織起來解題。這就是海域的高空地圖，告訴你哪些海特別危險。廣度讓你說得出「潛這裡」。說清楚，我不是指每個領域都專家級，而是指夠用就好：不對勁時知道查什麼。指引你探索海洋的浮標。
有人問我廣度怎麼教，開一門「什麼都教 101」嗎？我當時答不上來。後來想了想，這東西教不來，沒有這種課。我們最多鼓勵大家讀、逛、好奇，盡量吸收。記住那些怪 incident、那些慘叫時刻，想想跟手邊工作的關聯。經驗越攢越多之後，刻意把日常見聞跟工作連起來。多少次，多年前隨手專案學到的怪知識，關鍵時刻從天而降救我一命。這種經驗和廣度會複利，但要維持。
擁有的第三根柱子，我叫它即時深度：潛進任何問題、把它搞定的意願和能力。哪怕是未知水域，哪怕要關進籠子跟鯊魚游一會，哪怕要集合全隊、開大潛艇、越過大王烏賊去看系統到底哪裡壞。這是為把事做成、什麼都肯學的意願，也是知道這潛超出能力、該求救的謙卑。不是每潛都能單人完成，不是每潛都值得。
幾個月前，我在寫自己的 agent orchestrator，agent 和 subagent 的穩定性和生命週期 bug 一堆。我知道要它們幹嘛，但蓋房子的機器人蓋得潦草，報應一次全來。我盯著螢幕看 agent 一小時 crash 第 N 次，叫機器人自己收爛攤子也失敗幾輪之後，突然想起多年前讀過的一本 Kubernetes 書（對，我是 nerd），level-triggered state machine 幾個字跳到眼前。於是我潛下去，比原先打算的更深，一路挖到電機工程裡 level-triggered 的源頭，帶著機器人把核心架構從頭重設計。上線後穩如石頭。這次重寫能成，主要靠多年前讀過的東西剛好記得，加上願意為把事做成、學一切要學的。
所以你從海域高空地圖出發，明白下面是層層抽象一路到底。而所有抽象都會漏（Joel on Software 的漏抽象定律），系統擁有者的工作就是知道潛哪裡、潛多深。不再是 generalist 對 specialist，也不是神話 T 型人。
新的蓋法要的，是能潛進未知的 generalist，貨真價實的「高壓下快速學習者」，不是履歷灌水那種。這些年我面試過很多人，履歷寫 quick learner 的，我愛問：講一次你被迫快速搞懂複雜系統的經驗，怎麼搞懂的？你的答案會是什麼？
未來的擁有者
基本功可以學，廣度靠攢，即時深度可以練。這三根柱子讓人一點一點長出對系統的擁有份額。也許你從淺水開始，派機器人下去。基本功夠硬，廣度夠用，那就去蓋。只是東西壞掉時，記得穿上潛水衣，去跟怪獸游泳。
未來 sprawling 的海底礦場歸誰管？沒人知道。但我賭，會是玩得轉上面三根柱子的人。會是那個把舊收音機拆了又修好的小孩，對收音機一竅不通，只想聽音樂，哪怕裝回去多了兩顆螺絲。
HN 網友討論整理
統計列：score 183、留言 97、頂層 36（約十則已刪或被 flag），抓取時間 10 月 28 日。以下按回覆量取六個熱串，子串追高回覆者，覆蓋約四十則活著的留言。
一、這就是帶團隊（mrothroc，最熱）
mrothroc 說這跟他前 AI 時代的經驗一模一樣：從 IC 變成帶團隊之後，產出的 code，本來就超過他能逐行懂的量。他練出的正是作者講的那招：理解系統，具體就是 boxes and lines，component 和互動。他要求團隊把 sequence diagram 當 deliverable 的一部分，雙方都好把 code 放進系統脈絡。盒子可以不透明，因為他知道邊界和預期的輸入輸出，盒子吐畸形訊息，就知道進哪個盒子打獵。coding agent 時代更要練系統視角當地圖，邊界告訴你進哪個盒子。
- datsci_est_2015：大致同意，但帶團隊不等於帶 AI，AI 沒有 skin in the game。AI 的決策跟人的決策不等價，因為後果不等價。AI 不會被開除，不會心碎，不會露宿街頭。做決策完全不顧後果的人，你會立刻請他走人；對 AI 得抱著同一層警覺蓋系統。
- mrothroc 回：團隊確實不同，但交付軟體要練的肌肉高度重疊。倒是點出另一件事：驅動 agent 的，跟驅動人做好工作的，完全是兩套東西，管人的技巧到此為止。
- scottLobster：只做高層系統工作，進盒子的本事從哪來？測試再完整，寫測試驗證的人也得懂底層。只要人還有法律責任，這套只撐到有人被告上法院為止。新人還得練出專家，只是練法要改成明的，不能靠蓋產品順便練。公司會恨死這筆帳。
- mrothroc 回：他的本事是老派攢的，從 vi 手刻組語一路到 serverless tracing。年輕人沒那幾年苦工怎麼長肌肉，他也沒答案。
- blub：manager 類比是自我安慰。sloperator 出事法律找的是你，review 和 QA 流程得自己搭，偶爾得親自看 code。公司沒把這些人當 manager，他們還是 IC。
二、不適感才是訊號（trjordan，作者親自回）
trjordan 說喜歡這個寓言，感覺對，但不真對，因為它押在失敗的感覺，而不是真實的失敗。真正要緊的是產品失敗：憤怒的使用者、資安事件、downtime、壞掉的工作流。以前壓力大、不舒服的工程師，正是產品失敗的領先指標：系統太複雜，人同時扛廣度和深度就會產出爛活。但 agent 是不是同樣 way 壞掉、我們對 agent 的信任直覺夠不夠預測產品失敗，都還不清楚。他舉反例：認識一票 growth SaaS 和上一批 IPO 公司，工程師個個壓力爆表，出貨更快，incident 反而更少，三件事同時成立。所以即時學習和即時深度重要沒錯，但 equally 重要的是練出直覺：哪裡的不適感會長成真失敗。不適感不是丟掉的感覺，ownership 是腦中持有系統模型、主動決定潛哪裡。
- 作者 adrq 親回：完全同意，不適感是該下潛的訊號，是心智模型該更新的訊號，靠很多次下潛長出來。
- trjordan 再補：不是所有失敗都要緊（多半不要緊），seed 到 A 輪很多家就是全上線、被罵才修，只要修得夠快，中位數體驗就不差。但有些失敗還是痛：資料毀損、被利用的資安洞，因為難察覺。ownership 的首要目標可能就是練出這種直覺。
三、實戰派：DB schema 最危險（smallerfish）
網站曾經掛掉，但他點名最要盯的是 DB schema。LLM 的正規化決策很爛，模組化擋得了一部分，但一定外溢到 object model。在 AI-heavy 專案，他每幾天停下 feature，做 code 和 schema review，外加後續 cleanup。
四、人類不可取代是偽命題（LewisOrton）
他不太服氣：大家忙著找 AI 還不行（或很行）的面向，來定義人類不可取代的價值，沒意識到這些能力明天就被 AI 的擴張圈吞掉。幹嘛預設，百分之九十九點九九的人，能解 AI 解不了的問題？該守的是 human agency，這是道德問題，不是能力問題。
五、tribal 知識才是硬骨頭（EduardLev）
大致同意即時學習，但這不只看 code 就能學：跨多個 repo 和 config、歷史、流程、各種 tribal 知識，才是工作裡最難的那塊。AI 有幫忙，沒解完。它常在差一點的層次解題，深度和高層理解都不到位。
六、廣度等於應急導航（zaphar）
廣度是對的思考方式。緊急時就算用 agent，你知道問什麼、怎麼引導，速度快得多。
站內原文底下兩則讀者留言，正好打中要害：Abhinav Sharma 問，SonarQube 的例子把 ownership 講具體了，那給新人的小 debugging 練習該長什麼樣，才能練出「在沒寫過的 code 裡找對模組」？WIO 問得更狠：即時深度這段最打中他，但 SonarQube 故事正好暴露破口，你是因為 CI flag 才跳下去的，沒有 flag、agent 的 code 靜靜腐爛時，trigger 是什麼？這題作者還沒答。
視覺懶人包
八格一頁，結論先行：
手機打不開時走直連：https://static.blog.derekhsu.net/monsters-agents-ownership.html（備援 pages.dev 版）