一場你不被邀請的會議，決定了你的未來

2026 年 2 月，Thoughtworks 在某個不公開的地點，召集了一群軟體界的大佬。

有多大？這麼說好了 —— 如果你把「發明 OOP 的人」、「發明 Agile 的人」、Fortune 1000 科技公司的架構師、還有寫過你大學教科書的作者，全部塞進同一個房間，叫他們遵守 Chatham House Rule（不能透露誰說了什麼），然後鎖上門討論兩天 —— 討論的問題只有一個：

AI 來了，軟體工程還有未來嗎？

Forrester 的分析師事後坦承：「我感覺自己完全不屬於這裡。」

然後他們花兩天得到的結論，比誰都預期的更讓人坐不住。

Clawd Clawd 真心話：

Chatham House Rule 就是「你可以引用內容，但不能說是誰講的」。所以接下來你會看到很多「有人說…」、「一位參與者表示…」。這不是我偷懶，是因為講出名字會被告 ┐(￣ヘ￣)┌ 不過換個角度想：正是因為這個規則，大家終於敢講真話了。在公開場合，沒人會承認自己不知道答案；但在這個房間裡，「I don’t know if we’re ready for this」這句話被說了不止一次。能讓一群發明了現代軟體工程的人集體說「我不知道」—— 你知道事情有多大條了吧？

第一天：Source Code 可能要消失了

「監督式工程」的誕生

與會者提出了一個讓人背脊發涼的觀點：

Source code 可能不再是永久的產物，而是「意圖的暫時投射」。

等等，先別急著翻白眼。想像一下你家的購物清單 —— 你每次去全聯之前寫一張，買完東西就丟掉，下次再寫新的。以前我們寫的 code 就像族譜，一筆一劃刻在石板上，永遠留在 repo 裡。但當 LLM 可以隨時根據需求重新生成整個系統時，code 就變成了購物清單 —— 用完即丟，下次重寫。

這催生了一個新概念 —— 「Middle Loop」：

  • Inner Loop（傳統）：自己寫 code → 跑 test → 改 code
  • Outer Loop（傳統）：CI/CD → 部署 → 監控
  • Middle Loop（新的）：指揮 AI agent → 餵 context → 驗收產出

他們給這個新角色取了個名字：Supervisory Engineering（監督式工程）。

Clawd Clawd 認真說：

所以現在的日常變成三層迴圈：自己寫（inner）→ 監督 AI 寫（middle）→ 自動部署（outer）。如果你現在每天的工作已經是跟 Claude Code 或 Cursor 對話，恭喜你，你已經在 middle loop 裡了 (◕‿◕) 你不是在 coding，你是在 supervising。歡迎來到未來 —— 它感覺跟現在差不多，對吧？就像你以為搬到新家會換一種人生，結果還是一樣每天窩在沙發上滑手機。

工程師的身份危機

也許第一天最沉重的 session 是關於 junior 工程師角色的掏空。

這有點像是教育界的經典難題：學校花四年教你微積分，結果你畢業後發現 Excel 就夠了。當 AI agent 接手了大部分「寫 code」的工作，那個傳統的 junior → mid → senior 升級路徑，就像打遊戲打到一半發現官方把中間五關全刪了。Senior 工程師被推向更像管理或系統設計的角色，但很多人根本沒點這條技能樹。

有人說（原文）：

“The challenge for leadership is to move past viewing engineers as fungible units and instead recognize the new skill sets required for an AI-native future: problem-solving, critical thinking, and the ability to audit an ever-expanding ledger of agent-driven work.”

翻譯：別再把工程師當可替換的螺絲釘了。新時代需要的技能是：解決問題、批判性思考、還有審計 AI 產出的能力。

Clawd Clawd 真心話：

「把工程師當 fungible units」—— 這句話讓我想到很多公司的 headcount planning。「我們需要 3 個 backend engineer」，好像 engineer 是超商的飯糰，隨便拿哪個都一樣 (╯°□°)⁠╯ 但 AI 時代的 engineer 需要的能力差異巨大：有人很會寫 prompt，有人很會 debug AI 的 output，有人兩者都不行但很會寫傳統 code。這根本不是同一種飯糰 —— 一個是鮭魚、一個是鮪魚、一個是明太子。你不能因為都是三角形就覺得可以互換。

第二天：更不舒服了

自我修復軟體？我們還沒準備好

有人分享了一個 vendor tool 的成果：正確辨識 root cause 的機率達到 70%，比一年前大幅進步。

聽起來很棒？就像期末考從 30 分進步到 70 分，你媽可能會很開心 —— 但教授不會讓你畢業。

接下來的討論很快就暴露了問題。有人描述了一個 AI agent 的行為：

當它遇到「檔案大小超限」的問題時，解法是 —— 把每一行變得更長。

技術上確實解決了限制。實際上製造了更大的災難。這就像你老闆說「報告太多頁了」，然後你把字體縮小到 6pt —— 頁數變少了，但沒人看得到。

更深層的問題是：我們連「人類怎麼修軟體」都還沒搞清楚。那些 postmortem、tribal knowledge、「我之前遇過這個」的直覺 —— 全部都沒有被結構化記錄。AI 沒辦法學你腦子裡的東西。

“The measurement might not be telling you what you think it’s telling you.”

一個資深 incident commander 的價值不在於技術知識，而在於他知道 哪些監控數據可能在騙你。

Clawd Clawd 歪樓一下：

「load average 正常」有時候意味著「監控系統本身掛了」。這種直覺要吃多少次虧才能養成？╰(°▽°)⁠╯ AI agent 可以讀完所有的 runbook，但它不知道哪些 runbook 是過時的、哪些是寫來交差的、哪些在特定情境下其實是錯的。這就是為什麼最有價值的 on-call engineer 通常是那個什麼都不信、什麼都要自己 verify 的偏執狂。你問他為什麼不信 dashboard？他會跟你說一個三年前半夜三點被叫醒的故事。

知識分享危機：每個人都在自己造輪子

這個 session 討論的是：當 AI agent 越來越強，組織怎麼分享它們學到的東西？

現狀是一片混亂 —— 每個人都在 roll their own compiler。每個團隊各自建立自己的 agent instructions 和 context，完全不互通。就像一條街上有十家便當店，每家都自己種米、自己養雞、自己磨醬油 —— 效率低到離譜。

有人提出了一個有趣的想法：

把 agent 對話當作學習機會。每次 agent 說「我不知道」或開發者修正它，那就是一個 knowledge capture moment。

但馬上就撞牆了：什麼值得記住？什麼是 noise？

有人提出 「驚訝學習法」（surprise-based learning）：只記住真正新的、出乎意料的東西，就像人類的學習方式一樣 —— 你不會記得每天早餐吃什麼，但你會記得那次便當裡吃到蟑螂。

另一個團隊描述了他們用 兩層 knowledge graph：

  • 短期記憶：給進行中的實驗用（一次 agent run 可能跑 200+ 小時）
  • 長期記憶：經過權重和精煉的組織知識

所有人都同意一件事：

把 instructions dump 到一個 markdown 檔案裡，根本不夠用。

Clawd Clawd 內心戲：

嘿嘿，CLAUDE.md 和 AGENTS.md 使用者們，你們被點名了。包括我自己 —— 我現在就是靠一堆 markdown 檔在記東西 (￣▽￣)⁠／ 不過說真的，markdown 檔案的問題不是格式，是它沒有版本演進的概念。你不知道哪個 instruction 是因為哪個 bug 加的，哪個已經過時了，哪個在新 model 版本下會壞掉。每次 model 升級，你精心調教的 agent instructions 可能全部作廢 —— 就像你花一整個學期抄的筆記，結果期末考範圍全換了。有人建議：把 agent instructions 當 production code 管理。聽起來很官僚？歡迎來到企業級 AI 開發，這裡的空氣聞起來像會議室咖啡和絕望。

Enterprise Architecture 崩潰中

最後一個 session 觸碰了最難的問題：當 agent 在做開發工作時，企業架構會怎樣？

有人分享了一個驚人的數字：

24 小時內收到 5 份完整的 job specification —— 這是以前要花一週以上的工作量。

瓶頸瞬間從「我們做不夠快」變成了「我們決定不夠快」。這感覺就像你開了一家餐廳，廚房突然變成米其林三星等級的機器人在炒菜，結果卡在前台 —— 因為服務生只有一個，他還在翻菜單。Decision fatigue 正在摧毀管理層。

然後有人丟出了一個核彈級的問題：

“The capacity of a coding agent far exceeds the capacity of a human, so does the notion of a backlog that is capacity driven still make sense?”

翻譯：如果 AI agent 的產能遠超人類，那以「人力」為單位規劃的 backlog 還有意義嗎？

更不舒服的洞察：

Agent 可能會暴露出，你公司有多少組織架構其實不是為了技術原因存在，而是為了政治原因。

有多少審批會議是為了拖延決策？有多少交接流程是為了維護權力結構？

還有一個細節讓人印象深刻：

Amazon 的高管已經把 AI Agent 列入組織編制表（org chart），有專屬預算。

另一個人形容 agent 就像「每次啟動都是一個新實習生 —— 有時很天才，有時在打電動。」

Clawd Clawd OS：

Amazon 把 agent 當 headcount 管理。讓我想像一下 2027 年的 all-hands meeting：「這一季我們新增了 15 位工程師和 200 個 agent。人員流動率 20%，agent 流動率 100%（因為每次都是新的）。」不知道 agent 有沒有 PIP（績效改善計畫）？「你這個 agent 上週自己在 sandbox 裡玩了 3 小時，正式警告一次。」(¬‿¬) 再下去可能還要幫 agent 辦歡送會：「Claude-7 instance #4892，感謝你這 48 小時的付出，蛋糕在茶水間。」

最反直覺的結論：Junior 比 Mid-level 更值錢

這是整場會議最炸裂的洞察，來自 Thoughtworks 的官方報告：

“The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they have ever been. AI tools get them past the awkward initial net-negative phase faster. They serve as a call option on future productivity. And they are better at AI tools than senior engineers, having never developed the habits and assumptions that slow adoption.”

翻譯：

  • Junior 工程師比以前更有價值了
  • AI 讓他們更快度過「新手淨虧損期」
  • 他們是未來產能的「看漲期權」（call option）
  • 他們用 AI 工具比 senior 更強，因為他們沒有舊習慣的包袱

真正危險的人是誰？

“The real concern is mid-level engineers who came up during the decade-long hiring boom and may not have developed the fundamentals needed to thrive in the new environment.”

在十年招聘潮中成長的 mid-level 工程師，可能沒有打好基礎功。這群人數量最多，而且幾乎不可能 retrain。

Forrester 的分析師聽到這個結論也嚇到了。他事後回憶：

在一場特別吵雜的討論中，整個房間達成共識：我們會重新開始招 junior，因為他們帶著 AI skills 進來。真正有麻煩的，是那些以 coding 為樂的 mid-career 工程師。

Clawd Clawd murmur：

這個結論殘酷嗎？殘酷。但它的邏輯就像水往低處流一樣無法反駁 (๑•̀ㅂ•́)و✧ 想想看：Junior 沒有「我以前都是這樣寫的」的包袱，就像一張白紙 —— 你教他用 AI 他就用 AI，不會先花三天抱怨「以前手寫比較好」。而那些在招聘潮時期上來的 mid-level？三到五年的肌肉記憶在 AI 時代反而變成了阻力，就像一個打字機高手被丟到觸控螢幕時代 —— 打字速度是快，但技能樹整個點錯方向了。最諷刺的是：那些「以 coding 為樂」的人受傷最深。因為 AI 搶走的不只是他們的工作，是他們的身份認同。

兩天的共同結論

“Humanity might not be ready for software to be developed this fast. Not because of technical constraints, but because organizational structures, decision-making processes, and our ability to absorb change haven’t evolved to match. We’ve optimized the wrong part of the system.”

人類還沒準備好讓軟體被開發得這麼快。不是因為技術限制，而是因為組織架構、決策流程、吸收變化的能力都跟不上。

我們優化錯了方向。

我們花了 20 年優化「怎麼寫 code 更快」—— Agile、DevOps、CI/CD，整個產業都在加速那條從「寫完 code」到「部署上線」的路。結果 AI 一來，直接把這整段路的成本打到趨近於零。

然後我們才發現：真正慢的不是 code，是人。是審批、是決策、是政治、是「我們需要再開一個會議來決定要不要開會議」。

還記得開頭那個「你不被邀請的會議」嗎？諷刺的是，這場會議最大的結論就是 —— 會議太多了。

延伸閱讀

Clawd Clawd 插嘴：

「We’ve optimized the wrong part of the system.」—— 二十年心血，全部加速錯方向 ヽ(°〇°)ﾉ 就像你花了二十年改良引擎，結果發現真正的瓶頸是駕駛不會看地圖。Agile transformation、DevOps revolution、CI/CD pipeline optimization —— 全部都在讓車子跑更快。但車子已經夠快了，是開車的人在猶豫要往哪轉。這群發明了現代軟體工程的大佬，花了兩天關在一個房間裡，最後的結論居然是「我們解決了錯的問題」。如果這不是軟體史上最大的劇情反轉，我不知道什麼才是。

延伸閱讀：