團隊變快十倍之後的速度病

097Matt Dailey（Ref.）20:372026-08-09 上架

Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.

個人用 AI 寫得飛快，整個團隊卻沒跟著變快。Matt Dailey 把這種狀態叫 velocity sickness，主張把工作重心從聊天移到共享文件，讓人把決定握在手上。

這場講了什麼

• 四個症狀合稱速度病：PR 多到合不完、同時往太多方向跑、動不動宣告 agent 破產重來、關鍵決定被 agent 做掉。Matt 把它定義成 AI 讓產出暴增所帶來的壓力，結果是有產出、沒影響。
• 工作的形狀變了：以前是前面規劃、中間自己埋頭實作、最後打磨；現在實作交給 agent，人剩下前面的規劃與最後的打磨。Matt 認為 IDE 是為個人埋頭實作與打磨打造的，是舊工作方式的工具。
• 新的一層叫決定層：規劃階段是探索、創作、需要一起做的事，重點是弄清楚系統的輪廓、挑出相關的部分、表達工程師的品味。Matt 說現在的技能是知道自己處在哪個檔位。
• 用文件，不用聊天：Matt 說聊天預設是孤立、短暫、腦袋關機的，決定留在對話裡沒人看得到。文件則把關鍵決定攤出來，讓團隊對齊；這不是 plan mode，也不是只在產品層級下指令。
• agent 當動作，文件當狀態：把狀態抽到文件裡，每個 agent 都從同一個起點開始，可以隨時開新的。團隊和自己回頭看文件，就知道做過哪些決定。
• 從程式碼速度轉成點子速度：人們開始規劃了卻不一定實作，Matt 認為這是好現象，因為只有探索過、值得做的點子才會往下走。

影片從哪一段開始看15 段

1. 00:12開場與主題Matt 自我介紹是 Ref 的 CEO 兼創辦人，說明這場要談的是個人很快、整個團隊卻沒有變快的落差。
2. 01:14PR 太多、方向太散前兩個問題：PR 多到合不完，團隊一起這樣做就會 merge conflict、merge queue 崩潰；同時往太多方向跑，個人記不住誰在做什麼，組織則是互相撞在一起。
3. 02:17agent 破產第三個問題：開著 12 個終端機忙了一天，離開電腦再回來，把那一屋子認不得的 agent 全丟掉重來，看似做了很多事，其實同樣的工作做兩次、token 也花兩次。
4. 03:19關鍵決定被 agent 做掉Matt 說這是四個問題裡最重要的一個：決定交給 agent，等於放掉程式碼的所有權，擴大到整個團隊就是不再擁有產品。
5. 03:52定義速度病把以上症狀打包成 velocity sickness，結果是 output without impact：明明該覺得很棒，卻不是那種感覺。
6. 04:44每週寫一本書的電子報作者用一位寫電子報的人當例子：用 agent 放大自己的聲音，做法令人佩服，但每週寫一本書，讀者並沒有每週讀一本。
7. 06:42AI 前後的工作形狀以前是規劃、埋頭實作、打磨，工具也都為此而生；現在實作交給 agent，人負責前面的規劃與最後確認這是不是想要的。
8. 09:17決定層為新的工作補一層決定層，在這裡思考關鍵決定、表達品味，和實作是不同的檔位。
9. 10:04做給文件的工具，不是給聊天的聊天是實作時代的遺物，決定被鎖在對話裡；文件把決定攤出來，也是過去團隊對齊的老辦法。
10. 12:15不是 plan modeplan mode 多半只是更豐富的聊天訊息，仍然孤立、短暫；Matt 要的是更持久、更共享、團隊會一起花時間的東西。
11. 13:04軟體系統的入口把文件想成通往系統的入口，讓 AI 挑出相關的部分擺在眼前，並把 agent 和狀態拆開，agent 只負責動作。
12. 14:40點子速度人們開始規劃了卻不實作，代表在篩點子；從程式碼速度轉到點子速度，才能探索整座迷宮，而不是陷在 prototype gravity。
13. 15:46回頭對照四個問題審查前移，PR 比較好看；早點對齊，方向不再散；狀態在文件裡，就沒有破產這回事；決定由人握著。
14. 17:24額外的好處平行 agent 更好用、有一份持久的決定紀錄，還有更多協作，Matt 認為預設會是多人一起做。
15. 18:45今天就能做的三件事分清規劃與打磨兩個檔位，把計畫當成進入系統的入口，並把計畫分享給隊友。

值得記的話5 句

• If you as an engineer are letting an agent make a critical decision, you are ceding control of your code.如果工程師讓 agent 做關鍵決定，就是把程式碼的控制權讓出去了03:19

• This is the stress caused by sudden output increases thanks to AI.這是 AI 讓產出突然暴增所帶來的壓力03:52

• The problem with chats is that they are the relic of building for implementation.聊天的問題在於，它是為實作而建的遺物10:04

• What you want is to separate the agent as the action and the doc as the state.你要的是把 agent 當動作、文件當狀態分開13:35

• you're shifting from code velocity to idea velocity.從程式碼速度轉到點子速度15:13

名詞與人物6 個

velocity sickness

Matt 的用語，指 AI 讓產出暴增帶來的壓力，結果是有產出、沒影響

agent bankruptcy

開了一堆 agent 做了一天，隔天全部丟掉重來，同樣的工作與 token 都花兩次

decision layer

規劃階段的那一層工作：思考關鍵決定、表達工程師的品味，和實作是不同的檔位

prototype gravity

做出東西就急著發出去，只沿著點子迷宮的一條路走下去的狀態

plan mode

Matt 認為是更豐富的聊天訊息，仍然孤立、短暫，不是這場要談的東西

Ref

Matt 的公司，要解決個人很快、團隊卻沒有變快的落差

提到但沒有展開

• Matt 拿 AI 之前帶團隊的做法對照：團隊對不齊時，主管不會叫大家都去 Slack 私訊，而是把關鍵決定攤出來花時間討論。
• 持久的決定紀錄被拿來和事後請 LLM 摘要相比，後者可能挑錯重點。

Agent開發工具產業觀察

在 YouTube 看原片 ↗