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

🧑‍🏫 Datadog 的工程主管用他們自己的四個專案，講 AI 能寫的程式越來越大之後，真正卡住的地方怎麼一路換位置。他的結論是：只讓 AI 多寫一點程式不夠。要像工廠用工具機大量生產零件那樣，把 AI 寫程式這件事變成可重複、可檢驗、可以放大規模的流程。想知道 AI 寫程式下一步會卡在哪裡的人，這支值得看。

• 00:53 講者是 Datadog 的 VP of engineering，Sesh Nala。
  ↳ 講者是 Sesh Nala，Datadog 的 VP of engineering（工程副總，管整個工程部門）。Datadog 是一家做系統監控的公司。
• 01:23 machine tools 是製造業用的 jigs、fixtures、gauges、mills 等工具，用來生產精確、可重複的機械零件，再組裝成引擎、飛機、核反應爐、登月艙等大型機器。
  ↳ machine tools（工具機）是工廠裡的夾具、治具、量規、銑床。它們本身不是成品，作用是讓每個零件都做得一模一樣，這樣才組得出引擎、飛機這種大機器。
• 01:23 machine tools 是工業化時期的突破：靠標準化和精確度帶來的零件互換性，才做得到規模化。這也是這場演講和 Datadog 這套系統的靈感來源。
  ↳ 關鍵是 interchangeability（零件互換性）：同規格的螺絲，壞了隨便換一顆就能用，不用每台機器另外訂做。工業化能大量生產就是靠這個。講者想把這套想法搬到 AI 寫程式上。
• 01:55 投影片是講者對過去 18 個月模型能力的個人看法。他特別強調這張圖不科學，不能當成他的 eval。
  ↳ 他放了一張「模型這 18 個月變多強」的曲線，特別說這只是個人感覺，不是 eval（用固定題目正式測模型能力的評估），不要當成數據引用。
• 01:55 2025 年大部分時間，模型對他有用，但只限在很窄的範圍：局部修改、小函式、測試、glue code，還有用完就丟、拿來學習的 prototype。
  ↳ 2025 年大半年，AI 對他來說只是順手的小幫手：改幾行、寫小函式、補測試、寫 glue code（把兩個系統接起來的程式），或做個用完就丟、拿來學東西的 prototype（原型）。
• 02:27 2025 年底左右曲線開始變陡、呈指數成長，他開始把範圍更大、更模糊的系統層級工作交給 Claude。
  ↳ 2025 年底模型進步突然加快。他開始把「整個系統怎麼設計」這種範圍大、需求還說不太清楚的工作交給 Claude，不再只給它小任務。
• 03:01 2024 年：他們從零打造分散式佇列系統 Courier。那時還沒有 agents，全部由人手寫。
  ↳ 2024 年他們做了 Courier，一種分散式佇列系統：很多台機器一起接收、排隊處理大量工作。那時還沒有 agents（會自己規劃、分好幾步把事情做完的 AI），程式全靠人手寫。
• 03:01 不管分散式系統是人寫的還是 agent 寫的，難的都不只是做出各個部件，而是讓部件之間的互動可觀察（observable）、可測試（testable）、可驗證（verifiable）。
  ↳ 分散式系統最難的不是寫出各個零件，而是零件湊在一起時會不會出事。所以要看得到它在做什麼、能測試、能證明它是對的，不然出錯了連原因都找不到。
• 03:33 Courier 用了嚴謹的 formal modeling 和模擬。這是經典的系統工程做法：找出出錯代價高、難以回復的部分，提高這些地方的嚴謹度，不讓問題溜進 production。
  ↳ formal modeling（形式化建模）是用數學描述系統行為，先檢查設計有沒有漏洞。重點是找出壞掉最難救回的地方，只在那裡加嚴把關，不讓問題流進 production（正式給客戶用的環境）。
• 03:33 2025 年 9 月推出 Bits Evolve：一個閉環的演化式最佳化 harness，靈感來自 DeepMind 的 Alpha Evolve。
  ↳ Bits Evolve 是一個 harness（把 AI 關在裡面跑的受控環境，規定它能改什麼、怎麼打分數）。產生、測試、篩選會自動一輪接一輪地跑，靈感來自 DeepMind 的 AlphaEvolve。
• 04:05 Bits Evolve 的概念是讓部分程式碼在一個範圍窄、受控制的 harness 裡自我改進。講者提到當天 keynote 也有宣布 dreaming 和各種 loop 相關的東西。
  ↳ 意思是只圈出一小塊程式，讓 AI 在嚴格規則下自己反覆改良，不讓它亂改整個系統。講者也順帶提到，當天 keynote 發表了 dreaming 和各種 loop 相關的新東西。
• 04:05 做法是由大小模型組成的 ensemble（council）針對指定的程式碼產生不同變體，他們的案例是困難的函式和程式碼區塊。
  ↳ 他們找一組大大小小的模型組成 ensemble／council（模型委員會），針對某段特別難寫好的函式，各自提出不同改法，一次產生很多候選版本。
• 04:35 再由 benchmarks、tests、production observability 組成的 cascade 決定哪個變體存活，就像天擇。
  ↳ 候選版本要過好幾關 cascade（一關接一關的篩選）：benchmark（效能評比）、測試、再加上 observability（上線後系統運作看得多清楚）。撐到最後的才留下，就像天擇。
• 04:35 這讓講者第一次覺得，軟體的某些部分也許能像植物、微生物這類生物一樣被培育，透過變異、回饋和適應來成長。
  ↳ 講者第一次覺得，程式不一定只能一行一行「蓋」出來，有些部分也許能像種植物、養細菌那樣「養」出來：讓它變化、給它回饋，留下適應得好的。
• 05:05 心得：這種演化的品質取決於它適應的環境。benchmark 不好，演化結果就不好；observability 太弱，最佳化就只會停在表面。
  ↳ 演化得好不好，看篩選標準。題目出得爛，考第一名也沒意義；監控資料看得太淺，AI 就只會把表面數字改漂亮，真正的問題沒解決。
• 05:05 講者提到 Opus 4.5 是轉折點，他從那時開始提高企圖心，用 Claude Code 打造完整的分散式系統。
  ↳ 他認為 Opus 4.5 這個模型是轉捩點。從那之後，他才敢用 Claude Code（Anthropic 的 AI 寫程式工具）挑戰做一整套分散式系統。
• 05:05 對 Claude 的信任是漸進累積的，不是某天突然就把整個系統甚至資料庫交給它。
  ↳ 對 AI 的信任是一點一滴累積的。不會哪天突然就把整個系統、甚至資料庫全交給它，而是先看它小事做得穩不穩。
• 05:35 過程是先試更難的任務、再試更大的子系統，失敗很多次，也從大量實驗中學到很多，之後才開始看到成功。
  ↳ 他是一步步加難度：先給比較難的任務，再給比較大的子系統。中間失敗很多次，但做了很多實驗、學到很多，後來才開始成功。
• 05:35 接著他們挑戰能不能從零做出像 Kafka 這麼大的系統。講者說明 Kafka 是一種 streaming service。
  ↳ 接著他們挑戰從零做出跟 Kafka 一樣大的系統。講者說明 Kafka 是一種 streaming service（串流服務），專門即時傳送源源不斷的資料流，規模和複雜度都很高。
• 06:05 做法沿用 Courier 那套 playbook（兩者都是佇列系統），嚴謹度也一樣。差別是大部分建造工作由 Claude Code 完成，只有一個人在帶。
  ↳ 做法照搬 Courier 那套流程（兩者都是佇列系統），把關一樣嚴格。差別只在這次主要是 Claude Code 在寫，人只有一位，負責帶方向。
• 06:05 幾天內就做出完整可運作、相容 Kafka 的系統，他們自己也不敢相信。系統命名為 Helix，原始碼、方法論和細節都附在文章裡。
  ↳ 幾天內就做出完整能跑、跟 Kafka 相容（原本接 Kafka 的程式可以直接接上）的系統，連他們自己都不敢相信。取名 Helix，程式碼和做法都公開在文章裡。
• 06:38 但 Helix 要上 production，必須先累積實際運行的里程（mileage），這對他們一直是挑戰。
  ↳ 但做得出來不代表能上線。Helix 要進 production，得先累積 mileage（實際運轉的經驗，像新車要跑夠多公里才敢說可靠），這一直是他們的難題。
• 06:38 下一步，他們想用 Bits Evolve 演化 Helix 的部分元件，希望從演化小函式擴大到演化整個元件，藉此累積上 production 需要的里程。
  ↳ 他們想：既然 Bits Evolve 能演化小函式，能不能拿來演化 Helix 的整個元件？讓系統在反覆演化、測試中，累積上線前需要的運轉經驗。
• 07:08 結果不太行：要處理的範圍太大，即使有嚴謹的驗證 cascade，還是有太多地方需要人來判讀和修正，太多輪、太需要互動。
  ↳ 結果不太行。一次要改的範圍太大，就算層層篩選，還是一堆地方要人看、要人修，來回太多輪。AI 沒辦法自己跑完，人反而被綁住。
• 07:08 於是縮小範圍、降低企圖心，改選 Datadog 的 metrics aggregation server 當目標（講者說：我們是 Datadog，metrics 很多）。
  ↳ 所以他們退一步、縮小目標，改挑 Datadog 的 metrics aggregation server（把大量監控數據彙整計算的伺服器）。講者笑說：我們是 Datadog，最不缺的就是 metrics（監控數據）。
• 07:40 這次的目標是即時（live）改進 materialization 邏輯，而不是像 Bits Evolve 那樣離線做；並且針對每個客戶最佳化。
  ↳ 這次要在系統運轉中即時改良 materialization 邏輯（把原始數據先算成可以直接查詢的結果），不像 Bits Evolve 是離線改。而且要依每個客戶的狀況分別最佳化。
• 07:40 每次變更都附帶 proof-carrying path，這樣人就不必審查每一個產生出來的候選版本。
  ↳ 每次修改都附一條 proof-carrying path（隨變更一起附上、證明這個改法沒問題的依據）。有了它，人就不用逐一檢查 AI 產出的每個候選版本。
• 07:40 回顧這四個專案的規律：每個專案都暴露出下一個專案要面對的瓶頸。
  ↳ 回頭看這四個專案有個規律：每解決一個卡關點，下一個卡關點就冒出來。瓶頸不會消失，只會換地方。
• 08:10 Courier 的瓶頸在建造本身：人要靠仔細的設計、建模、驗證來蓋系統，花了一年。相比之下，Kafka 相容系統大約三天就做出來。
  ↳ Courier 卡在「蓋」本身：全靠人仔細設計、建模、驗證，花了一整年。對照之下，Kafka 相容的 Helix 大約三天就做出來。
• 08:10 Bits Evolve 的瓶頸移到回饋迴圈：模型負責產生變異，harness 決定誰存活。
  ↳ 到 Bits Evolve，寫程式不再是問題，卡點變成回饋迴圈：模型負責想出各種改法，但誰留下由 harness 決定，所以篩選標準的品質變成關鍵。
• 08:41 Helix 的瓶頸又移動了：agents 能做出系統的一大部分，但人得透過為人類設計的工具和機制，協調把成果送上 production。
  ↳ 到 Helix，AI 能蓋出系統的一大塊，但要上線時，還是得由人透過原本為人設計的流程和工具一步步協調。AI 很快，卡在人這關。
• 08:41 講者說這就是 Dario 當天稍早提到的 Amdahl's Law。
  ↳ Amdahl's Law（阿姆達爾定律）：整體速度被最慢的那段卡住。AI 寫程式再快，上線協調還是靠人慢慢來，整體就快不起來。講者說這就是 Dario 當天稍早提到的。
• 08:41 他們正在做的轉變，是從 mechanization（機械化）走向 industrialization（工業化）。
  ↳ 他們正在做的轉變，是從 mechanization（機械化）走向 industrialization（工業化）。兩個詞聽起來很像，差別在下一條。
• 09:12 mechanization 指 agents 做更多工作；industrialization 借用工具機的比喻，指工作變得可重複、可驗證、可控制、可規模化。
  ↳ 機械化只是「AI 做更多事」；工業化是像工具機那樣，讓成果每次都能重複做出來、能驗證、能控制、能放大規模。前者靠做得多，後者靠標準和制度。
• 09:42 為什麼 agent 寫的軟體現在需要 machine tool？因為每次提高企圖心（從對既有系統做小範圍修改開始），複雜度和模糊度都跟著增加。
  ↳ 因為野心每加大一次，從改既有系統的一小塊到從零蓋整套系統，複雜度和不確定性就跟著往上疊。光靠人一次次盯著 AI 已經不夠，需要標準化的工具。
• 09:42 過去四個月，約 90% 的 Datadog 工程師用 AI coding 工具寫 production code，大約 3,000 人，其中至少三分之二由 Claude Code 驅動。
  ↳ 過去四個月，Datadog 約 90% 的工程師（約 3,000 人）用 AI 寫程式工具寫正式上線的程式，其中至少三分之二用的是 Claude Code。
• 09:42 但大部分工作（像 Helix）仍是單人驅動：一位工程師操控一個或多個 agent session。
  ↳ 但大多數工作還是「一個人帶 AI」，像 Helix 就是：一位工程師同時操作一個或幾個 AI 工作視窗。做法還是靠單人在推，還沒變成整個組織都能重複用的流程。

根據講者的說法，Datadog 在沒有 agents 的時代由人手打造分散式佇列系統 Courier，花了多久？