當你的 PM 比你還早送 PR

想像一下：禮拜一早上九點半，你打開 GitHub notifications，發現 PM 昨晚送了一個 PR 來改 SQL query。你揉揉眼睛看了第二遍——不是 Draft，是 Ready for Review。

2026 年 2 月 17 日，Ramp 的 Data 主管 Ian Macomber 在 X 上發了一篇貼文，把這個畫面從科幻小說搬進現實。

Ramp 的非工程團隊 Claude Code 採用率：

  • 80% 的 Product Manager
  • 70% 的 Compliance（法遵）團隊
  • 55% 的 Finance（財務）團隊

而且這不是「從公司成立就在用」——Ian 說這是過去六週的採用率。六週。你家的健身房會員可能撐不了六週，但 Ramp 的 PM 們已經在六週內學會送 PR 了。

Clawd Clawd 插嘴：

六週學會送 PR，但我認識的工程師六週還學不會準時交 Jira ticket ╰(°▽°)⁠╯

好啦認真說，Ramp 不是什麼車庫新創在 demo day 吹的牛皮——估值超過 $130 億、客戶有 Shopify、Notion、Loom。他們 1/5 的企業客戶在付費用 Anthropic 的服務，一年前這比例才 1/25。當一家這種規模的公司說「我們的 PM 在自己送 PR」，這不是趣聞，是產業訊號。

一張時間軸看完 Data Team 怎麼從英雄變成按鈕

Ian 畫了一張殘酷的演化時間軸。讀完你會覺得自己在看一部慢動作的職業轉型紀錄片。

2021-2024（古典時代）

分析師在 Slack 的 #helpdata 頻道問：「這個數字看起來怪怪的。」Data Team 有人接單 → 挖 code → 找 bug → 發 PR → 修好。你是英雄，stakeholder 感謝你，這份工作有意義又有存在感。日子很美好。

2024-2025（過渡期）

同一個問題，同一個 #helpdata。但現在 Data Team 的人把問題複製貼上到 Claude Code → AI troubleshoot → 發 PR。人還是那個人，但中間多了一個不用吃飯不用睡覺的超強助手。你開始跑得更快了，但也開始有點心虛——你到底是在寫 code，還是在 copy-paste？

2024 年底-2025（覺醒）

畫風突變。分析師自己先用 Claude Code 查過了，然後帶著答案跑來 #helpdata：「這個數字不對，我知道為什麼了，而且我覺得是這行 code 需要改。」

你還站在原地，但分析師已經起跑了。

2026 年 2 月（現在）

分析師：「這個數字不對，這是我改好的 PR，幫我 approve 就好。」

好的。

Clawd Clawd 補個刀：

四個階段的 Data Team 角色：英雄 → 幫手 → 顧問 → 按 approve 的人。

這不就是每間便利商店的進化嗎？以前你要走到櫃台跟店員說「我要一杯美式」，現在你用 app 下單、到店取杯、連話都不用講。店員的工作從「服務你」變成「確認你拿對杯子」。(╯°□°)⁠╯

但 Ian 接下來說的話，比這張時間軸更重要。

Jevons Paradox：效率越高，你反而要做更多

Ian 沒有說「Data Team 完蛋了」。他搬出了 Jevons Paradox——一個 19 世紀的經濟學觀察：當煤炭的使用效率提高，煤炭的總消費量反而上升了。因為效率讓更多應用場景變得可行。

套到現在就是：AI 讓寫 code 的門檻降低了，所以需要寫的 code 反而更多了。

Ian 的原話很直白：

如果你極度有資源感、充滿好奇心、有品味知道什麼對客戶重要、能自己發掘專案並在兩天（或兩小時）內 ship——我可以用 100 個你這樣的人。

但他也立刻甩了一巴掌：

如果你用「我做 dbt models 和 dashboards」、「我做因果分析」、「我寫 Airflow DAGs」來定義自己——那個範圍正在快速萎縮。

Clawd Clawd OS：

Ian 引用了同事 @giansegato 的觀察：「我們正在把 Data 工作中較簡單的部分交給 Agent，剩下來的任務複雜度和影響力都在增加。」

白話翻譯：以前你可以靠「會寫 SQL」吃飯。現在你的 PM 也會寫 SQL 了（用 Claude Code）。「會寫 SQL」的價值，就像「會用 Word」的價值——大家都會的東西就不是技能了，是基本素養。 ┐(￣ヘ￣)┌

這跟 Spotify 的故事如出一轍——他們最強的工程師從 12 月起就沒寫過一行 code，全靠 AI 和內部系統。但那些工程師沒有被裁，他們被升級了。（見 CP-77）

留言區比本文更精彩

Boris Cherny（Claude Code 創造者）親自回覆：

「Love this. Send us bug reports so we can keep making it even better」

Boris 沒說「wow non-engineers are using my tool」——他說的是「請回報 bug」。就像你開了一間餐廳，聽到隔壁辦公室的人天天來吃午餐，你的反應不是「天啊有人來吃了」，而是「那個炸雞有沒有要改一下」。因為這早就在他的規劃裡了。

其他留言也很有看頭：

Insights 團隊主管 @roudyb03 直接喊出了 Data Team 的最佳姿勢：

「Data Team 是所有團隊裡最適合用 Claude Code 的。GitHub Repo 存 SQL + 文件，再接上 Claude Code，直接印鈔。」

開發者 @kayintveen 道出了很多人不敢講的真話：

「這個時間軸打中我了。沒人在討論的轉變是：資深開發者正在變成所有人的 code reviewer。我的工作在 6 個月內從『寫 code』變成『review PM 和分析師的 PR』。」

@anayatkhan09 潑了一盆冷水：

「PM 帶著 PR 出現很瘋狂，但現在的瓶頸是安全審查。真正的 Data 工作正在轉向建立 guardrails、linters 和 approval flow。」

Clawd Clawd murmur：

@kayintveen 的觀察直接呼應了 Drexel 研究（CP-84）——當 Agent PR 數量暴增，bottleneck 不在「寫 code」而在「review code」。現在這件事又加了一個維度：不只 Agent 在送 PR，你的 PM 和 Finance 團隊也在送。

想像一下：你是 Ramp 的 Senior Data Engineer，早上打開 GitHub，15 個 PR 等你 review——3 個來自 PM、5 個來自 Compliance、2 個來自 Finance、5 個來自 Claude Code Agent。你的工作不是寫 code，是品質閘門。你就是那個海關人員，所有人排隊等你蓋章。 (⌐■_■)

Matt Pocock 的大腦也在重新接線

同一天（2 月 18 日），TypeScript 社群最有影響力的人之一 Matt Pocock 分享了他「100% AI 貢獻 code」幾個月後的 9 個腦部變化。不是那種「AI 改變了我的生活」的空泛感想，是真正摸過 code 的人的 field report。

他最先講的一件事讓我特別有感：pre-commit hooks。Matt 說以前他覺得 CI 和 linting 是 friction——像高速公路上的減速丘，煩死了。但現在？他說這是整條公路上最重要的東西。因為 AI 寫 code 的速度太快了，沒有自動化品質檢查就像開一台 300 km/h 但沒有 ABS 的賽車，爽三秒鐘然後撞牆。

然後他講到品味的問題。AI 可以瞬間生出 10 個 prototype，但它不知道哪個值得留下來。它可以實作任何 module 介面，但它不會幫你定義介面長什麼樣。Matt 的結論很直接：人類的工作從「做事」變成「做判斷」。這句話聽起來像廢話，但你仔細想——你上次花一整天「做判斷」而不是「做事」是什麼時候？大部分人根本還沒學會這件事。

Clawd Clawd 想補充：

Matt 還提了一個我覺得最精彩的觀點：deep grey-box modules。把系統切成有簡單介面的盒子，讓 AI 管裡面的實作，你只需要知道進去什麼、出來什麼。這恰好解釋了為什麼 Ramp 的 PM 能送 PR——當 module boundary 夠乾淨，你不用懂整個 codebase，你只需要知道「這個 SQL query 在哪個 module、要改哪行」。

說白了：好的軟體架構 = 降低貢獻門檻。以前只有資深工程師能安全改 code，現在架構乾淨的話 PM 也能改。這不是 AI 的魔法，是架構的勝利。 (๑•̀ㅂ•́)و✧

但最反直覺的一點是 cognitive load 反而更高了。AI 幫你寫了更多 code，但你要花更多腦力去理解 AI 到底改了什麼。Code 產出速度加快了，你的大腦頻寬沒有升級。這直接對應我們報導過的 Cognitive Debt（CP-83）——AI 幫你寫完了 code，但你已經看不懂自己的系統了。速度的代價是理解力。

回到那個禮拜一早上

記得開頭那個畫面嗎？你打開 GitHub，PM 的 PR 等著你 review。

現在你知道了：這不是意外，這是趨勢。Ramp 的數據說 80% 的 PM 已經在用 Claude Code。Matt Pocock 說你的煞車系統（CI、hooks、linters）比油門更重要。Drexel 的研究說 bottleneck 已經從「寫 code」轉移到「review code」。

所以那個 PR，你 approve 還是 request changes？

老實說，答案沒那麼重要。重要的是你已經從寫 code 的人，變成了決定什麼 code 能上線的人。Ian 說他可以用 100 個有品味、有好奇心、能自己 ship 的人。你的 PM 已經在學怎麼 ship 了——你呢？ (￣▽￣)⁠／

延伸閱讀：