Datadog 如何為 Claude Code 打造通用的 machine tool（第 2/3 段）

🧑‍🏫 這段是 Datadog 講者談：AI agent（能自己連續做多步工作的 AI 助手）越來越強以後，工程師的工作方式正在大變。現有工具跟不上，他提出 TEMPR 這個工具來把混亂變成有規矩的「軟體工廠」。你每天在用 AI、卻常覺得產出很多但很亂，就很值得看。

• 10:17 工作正在這張圖上移動：一個軸是「越來越難產生」，另一個軸是「越來越難驗證」
  ↳ 講者用一張有兩個軸的圖來看工作：一個軸是「東西越來越難做出來」，另一個是「做出來後越來越難確認對不對」。他說各種工作在這張圖上的位置正在移動。
• 10:17 講者展示幾個具體例子，重點是這些例子都在軟體開發生命週期中產生「個人化的流程」
  ↳ 他舉了幾個實例，共同點是每個人都在軟體開發過程裡長出「自己專屬的做法」，不再大家照同一套標準流程走。
• 10:47 原因是一個人現在能做的事，比以前多很多
  ↳ 會這樣，是因為有 AI 幫忙以後，一個人能完成的量比以前大很多，自然會發展出只適合自己的工作方式。
• 10:47 以前工程師的 flow 是意圖和程式碼直接相連：理解問題、寫 code、測試、review、上線、維運，然後一再重複
  ↳ 以前工程師的工作節奏（flow，指順暢的工作流程）是：想清楚要做什麼，就直接寫成程式，接著測試、互相檢查、上線、顧系統，一輪一輪重複。
• 11:17 有了 agent，抽象層級變化很快；講者說自己很久沒看 code 了，但很多人還在經歷「看不到 code」的七階段悲傷
  ↳ 有了 agent，人離程式碼越來越遠。講者說他很久沒看 code 了，但也借「悲傷的七個階段」開玩笑：很多人對看不到 code 還在經歷失落和調適。
• 11:17 工程師不再寫 code，而是形塑工作：決定 agent 該看到什麼、有哪些工具、成功的定義、失敗怎麼偵測
  ↳ 工程師的工作從「親手寫」變成「安排」：決定 agent 看得到哪些資料、能用哪些工具、做到什麼算成功，還有出錯時怎麼發現。
• 11:47 就像每個人都被升了三級當主管，但他們並沒有報名要當主管；這個跳躍很大，讓人迷失方向，還不適應這種工作高度
  ↳ 這就像每個人一夕之間被升三級，要帶一群 AI 下屬，可是沒人問過你想不想當主管。跳得太大，很多人還不習慣從這麼高的位置看工作。
• 11:47 模型能力躍升之前，人類團隊就是工廠
  ↳ 在 AI 模型大幅變強之前，真正在「生產軟體」的就是一群人組成的團隊，人就是整座工廠。
• 12:18 工具是圍繞人的注意力和判斷設計的；production 上實際發生什麼事的維運記憶，存在人類組織的集體腦袋裡
  ↳ 以前的工具都假設有人在看、有人在判斷。系統在 production（正式給用戶用的環境）上實際怎麼運作，這些經驗都記在團隊成員的腦袋裡。
• 12:18 回到 Courier：12 個月前還是這樣；四個月前開始改變，轉折點是 Claude Code（字幕作 Cloud Code）和 Opus 4.5
  ↳ 回到 Courier 這個例子：一年前還是舊模式，四個月前開始變。講者說轉折點（inflection point）是 Claude Code（Anthropic 的寫程式 AI 工具）和 Opus 4.5 模型出現。
• 12:49 開始出現一位主導的人同時協調多個互動 session，例如 3、4、5 個 agent 同時處理不同部分
  ↳ 開始出現新的做法：一個人當指揮，同時開好幾個 session（和 AI 的一段工作對話），讓 3 到 5 個 agent 各自處理不同部分。
• 12:49 講者提到 Jared 說自己同時在做 10 件事，他展示的東西只佔他時間的 10%
  ↳ 講者提到 Jared 說他同時在做 10 件事，今天展示的東西只佔他一成的時間，可見一人多工已經到這種程度。
• 12:49 但工具仍然是照人的形狀設計的；agent 快了兩個數量級，這套 tool chain 跟不上它們的速度
  ↳ 但工具還是照「人」的節奏設計。agent 快了大約百倍（兩個數量級），整套 tool chain（一連串搭配使用的工具）跟不上它們。
• 13:20 結果人變成 agent 執行和人形系統之間的橋樑；維運知識只存在那個人腦中，加上 agent 之間寫的一些 markdown 檔
  ↳ 結果人卡在中間當轉接頭，把 agent 的成果搬進給人用的系統。系統怎麼維運，只記在這個人腦中，還有 agent 互相留的幾份 markdown（簡單文字格式）筆記。
• 13:20 這個現象被 Cloud-managed agents 進一步放大
  ↳ 字幕寫作 Cloud-managed agents，字面上是交給平台代管、在背景自己跑的 agent。這種 agent 越來越多，上面說的「人當轉接頭」問題就更嚴重。
• 13:50 agent 做更多背景工作，開始擔任需要判斷的角色，不只照指令，而是自己做決定
  ↳ agent 在背景做的事越來越多，還開始擔任要做判斷的角色（judgment-bearing roles）：不只照指令做，也會自己決定下一步。
• 13:50 agent 一跑就好幾小時，有時整晚甚至好幾天；講者提到有 benchmark 最長任務 20、28 小時
  ↳ agent 一跑就好幾小時，有時整晚甚至好幾天。講者提到在某個 benchmark（用來比較 AI 能力的標準測驗）裡，最長的任務跑了 20、28 小時。
• 13:50 agent 在 session 裡自己建工具、自己寫 code
  ↳ agent 在工作途中，會為了完成任務自己做小工具、自己寫程式，不只用人事先準備好的東西。
• 14:20 錯配仍在：每個 agent 都發明自己的工具、黏合程式和慣例，整個系統變得很難分享和維運
  ↳ 問題還是在：每個 agent 都各做各的工具、串接用的程式和習慣做法，彼此不相通，別人很難接手，整個系統越來越難顧。
• 14:20 session 產生的中間工具和真正的產品 code 界線變模糊；產出又多又快，很多有用，但有些看起來像假進度
  ↳ 臨時做的工具和真正要交付的產品程式混在一起分不清。產出又多又快，很多有用，但有些只是看起來有進度（false progress），其實沒往前推。
• 14:50 大部分工具建構只在那個本地 session 裡才有意義
  ↳ 大部分這種自製工具，只在做出它的那個 session 裡有意義，換個情境就用不上了。
• 14:50 講者認為需要更有結構的東西：如果 agent 要建置和維運關鍵的系統和資料庫，就需要 machine tool
  ↳ 講者認為需要更有結構的做法：如果要讓 agent 建立並維護重要的系統和資料庫，就需要 machine tool（工作母機，穩定製造其他東西的機器）。
• 14:50 TEMPR 是一種 machine tool：agent 不再為每個本地需求發明互不相連的工具，而是產出意圖與問題領域的精確規格
  ↳ TEMPR 就是講者介紹的工作母機：agent 不再每次都自己拼湊零散的工具，而是寫出清楚的規格，說明要做什麼、問題的範圍在哪。
• 15:21 它是 machine tool 的意思跟 jig 或 CNC 機器一樣：給出精確規格（例如螺紋要怎樣），高度可重複，可以用來造飛機
  ↳ 稱它 machine tool，是比照工廠的治具（jig，讓每次加工位置都一樣的固定模具）或 CNC 機器（電腦控制的加工機）：給準確規格就能一再做出一樣的零件，精準到能造飛機。
• 15:21 agent 不用每次都即興做出最終機制，而是產出精確描述，和 TEMPR 或類似機制反覆迭代
  ↳ 所以 agent 不用每次都臨場發揮，把整套機制從頭做出來；而是寫出準確描述，再和 TEMPR 這類工具來回修正。
• 15:51 先讓東西能動，之後再變成可重複、可檢查、可重用的東西，就能圍繞你的 code base 打造軟體工廠
  ↳ 先讓東西能動，之後再整理成可重複、可檢查、可重用的形式。這樣一步步累積，就能在自家程式碼周圍蓋出一座「軟體工廠」。
• 15:51 Simon Wilson（SimonWilson.net）一直在推廣 dark factory 這個詞，講者認為他是目前最有影響力的 AI 聲音之一
  ↳ 講者提到 Simon Wilson（網站 SimonWilson.net，一般拼作 Simon Willison）一直在推廣「dark factory」這個說法，並認為他是目前最有影響力的 AI 評論者之一。
• 16:23 dark factory：agent 在虛擬工廠裡持續工作，現場不需要人，可以把燈關掉
  ↳ dark factory（關燈工廠）原本指全自動、現場不用人、可以關燈的工廠；這裡指 agent 在虛擬工廠裡不停工作，不需要人在旁邊盯。
• 16:23 人的角色變成設計工廠、限制條件、成果和驗證迴圈，讓它能跑好幾小時、好幾天、好幾週
  ↳ 人的工作變成設計這座工廠：訂規則和限制、訂要交出的成果、設好檢查機制，讓它能自己穩穩跑上幾小時、幾天，甚至好幾週。
• 16:54 TEMPR 這類東西可以扮演 machine tool 的角色，用來打造這種工廠
  ↳ 講者的主張是：TEMPR 這類工具，就是用來蓋這種關燈工廠的工作母機。
• 16:54 具體例子是 Helix：類似 Kafka 的串流服務，可能是 Datadog 最貴的五個服務之一
  ↳ 實例是 Helix：類似 Kafka（常見的開源系統，負責在系統之間大量、即時地傳送資料）的串流服務。講者說這可能是 Datadog 最貴的五個服務之一。
• 16:54 Helix 一直在 shadow production workload，有些情況下相信它能比現行方案便宜不少
  ↳ Helix 一直在 shadow（字幕沒細講，一般指在旁邊跟著處理真實工作量、但不真正接手）正式環境的 workload（系統要處理的工作量）。有些情況下，他們相信它比現行做法便宜不少。
• 17:24 Helix 花了大約一週建好，shadow 後看到可能便宜 2 到 5 倍的機會
  ↳ Helix 大約一週就做出來，shadow 之後看到可能便宜 2 到 5 倍的機會。
• 17:24 從看起來有前景到上 production，系統還要累積足夠里程，證明能穩定運作，而且不只建造者一人能維運
  ↳ 但從「看起來不錯」到正式上線，還得實際跑夠久，證明它穩定，而且不是只有做它的那個人才顧得了。
• 17:24 他們建立一批模擬 production 形態的合成 workload，並建構了一座工廠
  ↳ 為此他們做了一批 synthetic workloads（模仿正式環境工作量樣貌的合成測試資料），並蓋了一座工廠來跑。
• 17:56 TEMPR 用法一：當 agent control plane，更精確管理 Cloud managed agents 的 session、角色、工作和維運生命週期
  ↳ 用法一：當 agent 的 control plane（負責管理調度的那一層），更精準管理背景 agent 的 session、角色、任務，還有從開始到結束的維運流程。
• 17:56 TEMPR 用法二：讓 agent 用小型 TEMPR app 自建工具，串接 Git、CI、部署等 SDLC 工具
  ↳ 用法二：讓 agent 用小型 TEMPR app 做自己的工具，接上 Git（程式版本管理）、CI（自動測試和建置）、部署等 SDLC（軟體開發生命週期）工具。
• 18:26 TEMPR 用法三：當 Helix control API，也就是圍繞 Helix data plane 的介面和生命週期層，用來運行這些 workload
  ↳ 用法三：當 Helix 的控制介面，包在 Helix 實際處理資料的那一層（data plane）外面，管理它的操作和生命週期，用來跑那些測試工作量。
• 18:26 意外發現：TEMPR 感覺比 agent 基礎設施更通用
  ↳ 做著做著他們發現，TEMPR 的用途好像不只是管 agent，而是更通用的東西。
• 18:26 很多軟體仔細看，其實就是資料庫的控制邏輯、狀態的 API、變更的政策、生命週期轉換、外部系統整合
  ↳ 因為仔細看，很多軟體其實就是：管資料庫的規則、存取狀態的 API（程式之間溝通的介面）、哪些改動可以做、階段怎麼轉換、怎麼跟外部系統串接。
• 18:57 所以 TEMPR 可以是「通用」的：任何具備上述形狀的軟體都能套用
  ↳ 所以只要軟體是這種結構，都能用 TEMPR 來做，這就是講者說它「通用」的意思。
• 18:57 跟請 Claude Code 用 TypeScript 或 Python 寫 CRUD app 有什麼不同？Claude 做這件事很在行
  ↳ 有人會問：這跟叫 Claude Code 用 TypeScript 或 Python（常見程式語言）寫個 CRUD app（能新增、讀取、修改、刪除資料的基本程式）有什麼不同？Claude 做這個很拿手。
• 19:27 一般 CRUD app 的控制邏輯分散在 routes、資料庫限制、service code、背景工作和文件裡
  ↳ 差別在於一般 CRUD app 的規則散在各處：routes（網址對應的處理程式）、資料庫限制、商業邏輯程式、背景工作、文件，沒有一個地方能一次看全。
• 19:27 就算測試和覆蓋率都很好，形狀像 state machine 的維運模型大多隱含在 code base 裡
  ↳ 就算測試寫得很完整，系統「現在是什麼狀態、可以變成什麼狀態」這套邏輯（state machine，狀態機）大多藏在程式碼裡，沒有明白寫出來。
• 19:27 TEMPR 的概念就是把這個 state machine 明確化
  ↳ TEMPR 的核心想法，就是把這套狀態機明明白白寫出來，不讓它藏在程式各處。
• 19:27 這不算新點子：Erlang OTP 等 actor runtime 已有幾十年，近年還有 workflow engine 和像 TEMPORAL 的 durable execution runtime
  ↳ 講者也承認這不是新點子：Erlang OTP（打造不容易停擺的系統的老牌工具）已經用了幾十年，近年還有 workflow engine（工作流程引擎），以及 Temporal 這種程式中斷後還能接著跑的執行環境。
• 19:57 TEMPR 的 build path 會要你用 blueprint 描述維運領域：有哪些狀態
  ↳ 用 TEMPR 建東西時，要先寫一份 blueprint（藍圖），描述這個要維運的範圍裡有哪些狀態，例如訂單有「已下單、已付款、已出貨」。
• 20:28 blueprint 還要回答：哪些狀態轉換合法、誰可以請求、允許哪些效果
  ↳ 藍圖還要寫清楚：哪些狀態之間可以切換、誰有權提出切換、切換時允許發生哪些事。例如只有客服能把「已付款」改成「已退款」。

講者說 Datadog 的 Helix 軟體工廠用了 TEMPR 的哪三種方式？