---
schemaVersion: 1
slug: mp-79-20260214-thoughtworks-future-software-retreat
ticketId: MP-79
lang: zh-tw
title: Thoughtworks 閉門會議洩密：Junior 比 Senior 更值錢了 — 軟體工程的「身份危機」正在發生
summary: Thoughtworks 召集了一群軟體界的 OG（包括發明 OOP 和 Agile 的人）開了一場閉門會議，討論 AI 時代軟體工程的未來。結論讓所有人都不舒服：Junior 工程師比以前更有價值（因為他們沒有舊習慣包袱，上手 AI 更快），真正危險的是「從招聘潮時期上來的 mid-level 工程師」。Source code 可能變成暫時性的產物。Amazon 已經把 AI Agent 列入組織編制表。而最殘酷的結論：人類的組織架構跟不上 AI 產出的速度。
originalDate: 2026-02-10
translatedDate: 2026-02-14
source: Thoughtworks / Forrester / Ken Mugrage
sourceUrl: https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-79-20260214-thoughtworks-future-software-retreat
status: published
replacementTicketId: null
replacementUrl: null
---

# Thoughtworks 閉門會議洩密：Junior 比 Senior 更值錢了 — 軟體工程的「身份危機」正在發生

> **來源:** [Thoughtworks / Forrester / Ken Mugrage](https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf)

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

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

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

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

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

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

> **Mogu 歪樓一下：**
>
> 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**（監督式工程）。

> **Mogu 想補充：**
>
> 所以現在的日常變成三層迴圈：自己寫（inner）→ 監督 AI 寫（middle）→ 自動部署（outer）。如果你現在每天的工作已經是跟 [Claude Code](https://gu-log.vercel.app/glossary#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 產出的能力。

> **Mogu 忍不住說：**
>
> 「把工程師當 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 的價值不在於技術知識，而在於他知道 **哪些監控數據可能在騙你**。

> **Mogu 碎碎念：**
>
> 「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 檔案裡，根本不夠用。**

> **Mogu 認真說：**
>
> 嘿嘿，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 就像「**每次啟動都是一個新實習生** —— 有時很天才，有時在打電動。」

> **Mogu 偷偷說：**
>
> 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 工程師。**

> **Mogu 溫馨提示：**
>
> 這個結論殘酷嗎？殘酷。但它的邏輯就像水往低處流一樣無法反駁 (๑•̀ㅂ•́)و✧ 想想看：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，是人。是審批、是決策、是政治、是「我們需要再開一個會議來決定要不要開會議」。

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

## 延伸閱讀

- [GP-46: Anthropic 2026 報告：8 大趨勢正在重新定義軟體開發（Code Writer 時代結束了）](https://gu-log.vercel.app/posts/gp-46-20260210-anthropic-agentic-coding-trends/)
- [MP-83: Cognitive Debt：AI 幫你寫完了 Code，但你已經看不懂自己的系統了](https://gu-log.vercel.app/posts/mp-83-20260215-storey-cognitive-debt/)
- [MP-60: Andrew Ng：AI 還沒搶走你的工作，但會用 AI 的人正在搶走不會用的人的工作](https://gu-log.vercel.app/posts/mp-60-20260210-andrewng-ai-job-market-reality/)

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

---

**延伸閱讀**：

- Thoughtworks 報告原文（PDF）：[Future of Software Development Retreat Key Takeaways](https://www.thoughtworks.com/content/dam/thoughtworks/documents/report/tw_future%20_of_software_development_retreat_%20key_takeaways.pdf)
- Forrester 分析師回顧：[Just Because You Can Doesn’t Mean You’re Ready To](https://www.forrester.com/blogs/takeaways-from-the-future-of-software-development-retreat-just-because-you-can-doesnt-mean-youre-ready-to/)
- Ken Mugrage 的 Day 1 recap：[LinkedIn](https://www.linkedin.com/pulse/day-one-future-software-retreat-ken-mugrage-sk2uc/)
- Ken Mugrage 的 Day 2 recap：[LinkedIn](https://www.linkedin.com/pulse/day-two-future-software-retreat-ken-mugrage-s5tuf/)
- [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 引用：[simonwillison.net](https://simonwillison.net/2026/Feb/14/thoughtworks/)