Patrick Collison 談 Stripe 如何使用 Claude Code

🧑‍🏫 線上金流公司 Stripe 的執行長 Patrick Collison 在這支影片裡談三件事：Stripe 怎麼用 Claude Code 加快開發，同時又顧住金流服務最在意的穩定度；Stripe 資料裡看到的創業潮；還有他對「AI agent 彼此交易」這個未來的看法。想知道 AI 在大公司裡實際怎麼用、效果有多大，這支影片有很多具體數字可以參考。

• 00:00 開場提到家裡裝了氣象站，用 Claude 從零設計一個 multimodal model，預測午後天氣比 National Weather Service 還準
  ↳ 他在家裝了氣象站，請 Claude 從頭設計一個 multimodal model（能同時處理多種資料的 AI 模型），預測午後天氣竟然比美國國家氣象局還準。
• 00:31 Stripe 核心 API 的可靠度是五個半 9（five and a half nines），同時又要很快開發、推出新產品，並且持續部署（continuous deployment）API
  ↳ Stripe 的核心 API（商家串接收款功能用的介面）可靠度是「五個半 9」，比 99.999% 還穩。同時它還要快速推出新產品，並做到 continuous deployment（程式改好就隨時上線）。
• 00:31 金融服務業通常一個月、一季，甚至半年才部署一次，這樣換來的是局部的穩定
  ↳ 一般金融業一個月、一季，甚至半年才更新一次系統。少動就少出錯，換來的是某種程度的穩定。
• 01:03 但低頻部署有兩個很大的代價：一是拿不到客戶的即時回饋、無法定期出貨；二是累積好幾個月的變更，每次遷移都很驚險
  ↳ 但這樣有兩個代價：一是聽不到客戶的即時反應，也沒辦法定期推出新東西；二是幾個月的改動擠在一起上線，出錯時很難查出是哪個改動造成的。
• 01:03 Stripe 開發時希望一天拿到好幾次客戶回饋，所以不願意在這點上妥協
  ↳ Stripe 希望一天內就能多次拿到客戶回饋、馬上修正，所以不接受「為了穩定就少更新」這條路。
• 01:33 為了兼顧可靠度和持續演進，Stripe 投資了端到端的開發與品質保證流程，devbox 是第一環，可以在上面做 instrumentation 和 observability
  ↳ 為了既穩又能一直改，Stripe 把從開發到檢查的整條流程都顧好。起點是 devbox（工程師寫程式用的開發環境），上面可以加 instrumentation（埋設紀錄點）和 observability（看清系統在做什麼）。
• 01:33 部署採漸進式：先推到少數幾台機器，再到 1% 的機器，接著依 progressive rollout 策略往外擴大
  ↳ 新版本不會一次全部上線：先放到幾台機器試，沒問題再推到 1% 的機器，再照 progressive rollout（分批逐步擴大）推開。萬一出事，影響範圍也很小。
• 02:04 Stripe 要的是極高的可靠度與安全性，也要極快的開發速度，他們認為這是兩者兼得的唯一方法
  ↳ Stripe 要穩定、要安全，也要快。他們認為靠「小步頻繁更新，加上層層檢查」才能兩者兼得，這是唯一的路，不必二選一。
• 02:04 進入 agentic development 時代，外界在問 AI 對可靠度是順風還是逆風，也擔心寫得快、審得不夠細
  ↳ 現在進入 agentic development（AI agent 自己動手寫程式、跑任務的開發方式）的時代。外界擔心 AI 寫得太快、人審不過來，系統反而更容易出包。
• 02:34 Stripe 一位工程師上半年（H1）合併了 600 多個 PR，全部用 AI 寫，只有一個被 revert，顯示加速開發仍能維持高可靠度
  ↳ 一位工程師上半年合併了 600 多個 PR（提交給團隊審核、再併入正式程式的一包修改），全部由 AI 寫，只有一個被 revert（撤回）。可見速度快也能維持穩定。
• 03:06 Minions：可以從 Slack、網頁介面或任何工具用 prompt 協調 VM。提出需求後，它會開一台全新的 VM 執行任務，打包、送出、建置，再跑完測試套件
  ↳ Minions 是 Stripe 的內部工具：在 Slack（公司聊天軟體）或網頁上打一句需求，它就開一台全新的 VM（虛擬電腦）去做，做完會打包送出、建置，再跑完所有自動測試。
• 03:06 過去 18 個月，每個 PR 的品質是上升的
  ↳ 過去 18 個月，平均每個 PR 的品質反而變好，沒有變差。
• 03:38 每單位時間的事故數略有上升，但大多是很小的事故；靠著各種次級攔截機制，整體可靠度基本上不變
  ↳ 單位時間內的事故數稍微變多，但大多是小事。因為後面還有好幾道關卡會把問題攔下來，整體穩定度大致沒變。
• 04:09 有了 LLM，可以打造以前做不到的 observability、instrumentation、harness 和自動化審查，他有信心未來一兩年 AI 整體會讓 Stripe 更可靠
  ↳ 有了 LLM（大型語言模型，像 Claude 這類 AI），以前做不起的監控、harness（自動跑測試的框架）和自動程式審查都做得出來了。所以他相信一兩年內 AI 會讓 Stripe 更穩。
• 04:39 護欄的核心是依靠 invariance（不變量）和硬性屏障，而不是主觀、看情況或機率性的東西
  ↳ 護欄的關鍵是 invariance（不管怎樣都必須成立的規則）和硬性屏障，也就是系統直接不允許某些操作；而不是靠人判斷，或賭「應該不會出事」的機率。
• 05:09 模型對齊得好、比較會寫出正確或安全的程式當然不錯，但沒有什麼是完美的，真正要依靠的是保證（guarantees）
  ↳ 模型越守規矩、越會寫安全的程式當然越好，但誰都會出錯。真正能放心依靠的是 guarantees（由系統機制保證一定成立的事），而不是期待 AI 不犯錯。
• 05:09 主持人歸納：把護欄做成基礎設施、做資料隔離，讓人根本碰不到不該碰的資料，這些投資現在開始回收
  ↳ 主持人總結：把 guardrails（防止犯錯的限制）直接做成系統的一部分，並把資料隔開，讓人根本碰不到不該碰的東西。這些早年的投資現在開始回收了。
• 05:42 Stripe 從 2017 年開始認真投資資料的標記和語意感知護欄。這花了好幾年，因為要做大量標註和細粒度權限。當初是為了安全，意外讓他們在 agentic development 來臨時更有優勢
  ↳ Stripe 從 2017 年開始替資料貼標籤，讓護欄看得懂資料的性質，例如哪些是敏感資料，還設了很細的權限，花了好幾年。本來是為了資安，沒想到正好適合 AI 時代。
• 06:12 主持人提到 Claude 也很會寫護欄。Patrick 猜測幾年後到達均衡時，AI 會大幅偏向有利防守方（defense advantaging）
  ↳ 主持人說 Claude 也很會寫護欄。Patrick 猜幾年後攻守達到平衡時，AI 會明顯 defense advantaging（對防守方比較有利），也就是幫守護系統的人比幫攻擊者多。
• 06:42 每台 devbox 都預裝 Claude Code，是一般人要完成任務時第一個打開的工具，確實帶來明顯的加速
  ↳ 每台 devbox 都預裝 Claude Code（讓 AI 直接在電腦上讀寫程式、執行指令的工具）。大家要做事時第一個打開的就是它，速度也確實明顯變快。
• 06:42 Stripe Projects 的靈感來自 Claude Code：用 Claude Code 做有一定規模的專案，一定得串接其他服務
  ↳ Stripe Projects 的點子來自使用 Claude Code 的經驗：專案一做大，就一定得接上各種外部服務，例如資料庫或放網站的主機。
• 07:13 例如想用 PostHog 做 logging、放在 Vercel 上 host、需要資料庫。這些公司幾乎都是 Stripe 客戶，所以 Stripe 和他們合作，讓 agent 能輕鬆替使用者開好帳號
  ↳ 例如用 PostHog 記錄使用資料、把網站放在 Vercel 上、再加一個資料庫。這些公司多半是 Stripe 客戶，於是 Stripe 跟它們合作，讓 agent 能直接替使用者把帳號開好。
• 07:43 Stripe Projects 從點子到公開上線，大約 2～3 位工程師花了約兩個月，包含內部 API、服務、harness，以及串接約 50 個各有怪癖和偶發 bug 的服務
  ↳ Stripe Projects 從點子到公開上線，只花了約 2～3 位工程師、兩個月左右。這包括內部系統，還要串接約 50 個各有怪脾氣、偶爾出 bug 的外部服務。
• 08:13 參與的工程師估計，以前需要更大的團隊做六個月。Patrick 假設團隊大一倍、時間長 3 倍，相對差距是 6 倍，並說至少有 6 倍加速
  ↳ 參與的工程師估計，以前要更大的團隊做六個月。Patrick 的算法是：人數多一倍、時間多三倍，等於 6 倍的工作量，所以至少快了 6 倍。
• 08:13 Stripe 有數千名工程師。他認為加速幅度會有分布，有些快很多、有些沒變；但就算整體只有 2 倍，也是非常大的事
  ↳ Stripe 有幾千名工程師，每個人加速的程度不同，有人快很多、有人沒變。但他說就算整體只快 2 倍，對公司也是很大的事。
• 08:44 不只做得更快、用的人更少，每個 PR 的品質也更高
  ↳ 重點不只是更快、用更少人，每個 PR 的品質也更好。
• 09:14 Stripe 做了更多產品和實驗。今年年度大會 Sessions 發表的新產品和新功能數量遠超過往年；工程組織雖然稍微變大，但顯然有生產力效應
  ↳ Stripe 推出了更多產品和實驗。今年年度大會 Sessions 發表的新產品、新功能遠多於往年，工程部門人數卻只稍微增加，可見多出來的是生產力。
• 09:44 跟外界對 slop 的擔憂相反，Stripe 現在做了更多改善架構和程式碼庫的專案
  ↳ 外界擔心 AI 會產出一堆 slop（粗製濫造的內容或程式），但 Stripe 反而有更多餘力去整理架構、改善舊程式碼。
• 09:44 Stripe 常引用一位朋友的話：「每個程式碼庫現在都是另一個程式碼庫的 prompt」；前 Stripe 成員 Jared Sumner 的 Bun rewrite 就是例子
  ↳ 朋友說「每個程式碼庫現在都是另一個程式碼庫的 prompt（給 AI 的指令）」，意思是舊程式可以當規格，讓 AI 照著寫出新版。前 Stripe 成員 Jared Sumner 重寫 Bun 就是一個例子。
• 10:16 他認為三年後 Stripe 的程式碼品質一定會更高
  ↳ 所以他很篤定：三年後 Stripe 的程式碼品質一定會更好。
• 10:16 主持人觀點：tokens 可以寫產品、寫基礎設施、寫護欄，很多人太專注在直接做產品，其實中間這些用途才最強大
  ↳ 主持人認為，tokens（AI 處理文字的計量單位，大約等於用掉的 AI 用量）不只能拿來直接做產品，也能拿來寫基礎設施和護欄。很多人只盯著產品，其實這些幕後用途才最有威力。
• 10:47 內部採用非常熱烈又快。關鍵的轉折點有兩個：Claude Code 這種使用模式本身，以及去年底的模型進步
  ↳ 公司內部採用得又快又熱烈。轉捩點有兩個：一是 Claude Code 這種「讓 AI 直接動手做」的使用方式，二是去年底模型能力明顯進步。
• 11:18 今年大家最主要要適應的，是搞清楚現在能做到什麼、可以怎麼工作
  ↳ 今年大家最主要的功課，是弄清楚 AI 現在到底能做到哪裡，以及工作方式該怎麼跟著改。
• 11:18 一位 Stripe 員工的做法：先用最聰明的模型花大量心力做出複雜完整的計畫，再派出 10 台 devbox，由不同 agent 執行計畫的不同部分，可能跑一整天，甚至好幾天
  ↳ 有位員工先用最強的模型，花很多力氣寫出一份完整的計畫，再開 10 台 devbox，讓不同 agent 各做一部分，一跑可能就是一整天，甚至好幾天。
• 11:50 就算有了 Claude Code，也不容易想到一次交出去的工作量可以這麼大；只要協調和引導得當，模型也能做大量自我驗證
  ↳ 就算用了 Claude Code，多數人也想不到一次能交出這麼大量的工作。只要分工和指引做好，模型還能自己檢查做得對不對。
• 12:20 Patrick 說自己最近低估了 plan 模式，也改變了使用模型的方式；重點是對這個不斷變動的模式培養直覺
  ↳ Patrick 坦言最近才發現自己低估了 plan 模式（先讓 AI 規劃步驟，確認後再動手），用法也跟著改了。重點是持續摸索，對不斷變化的 AI 能力培養手感。
• 12:20 主持人：以前有一大堆開了頭沒做完的專案，現在每個都能做完，再決定要不要
  ↳ 主持人說，以前有一堆開了頭卻沒做完的專案，現在每個都能先做完，再看成果決定要不要留。
• 12:51 洗澡時冒出的點子現在更常真的被做出來，保持好奇心的回報變高了
  ↳ 洗澡時想到的點子，現在更常真的被做出來。越有好奇心，得到的回報就越多。
• 12:51 主持人認為有了 AI，小團隊比以前更容易跟大團隊競爭
  ↳ 主持人認為，有了 AI，小團隊比以前更有機會跟大團隊競爭。
• 13:21 主持人每三個月到 Y Combinator 演講。以前問誰用 Claude Code，現在改問誰 100% 用 AI 寫程式，這些小新創約 70% 舉手
  ↳ 主持人每三個月去 Y Combinator（美國知名的新創加速器）演講。以前問誰用 Claude Code，現在改問誰的程式 100% 由 AI 寫，這些小新創約 70% 舉手。
• 13:21 主持人觀察到新創變多、動作更快，也在挑戰更有野心的問題
  ↳ 他觀察到新創變多、動作變快，而且敢挑戰更難、更有野心的題目。
• 13:51 Stripe 成立 15 年，累積了公司創立的長期時間序列，可以當作整個生態系的指標；2020 年 3 月曾出現明顯的新創加速
  ↳ Stripe 成立 15 年，累積了很長一段「新公司何時成立」的資料，可以用來看整個創業圈的冷熱。2020 年 3 月就曾出現明顯的創業加速。
• 14:21 過去一年的加速幅度，相對來說是史上最大：在 Stripe 上每單位時間新成立的企業大約增加一倍
  ↳ 但過去一年的加速，相對來說是史上最大的：在 Stripe 上，每單位時間新成立的公司大約多了一倍。
• 14:21 約四分之一的 Delaware 公司是透過 Stripe 設立；扣掉跨國企業子公司之類的，真正新創的比例會高於 25%
  ↳ 美國 Delaware 州（很多公司選擇在那裡登記）的公司，約四分之一是透過 Stripe 設立的。扣掉大企業子公司這類情況，只算真正的新創，比例還會超過 25%。
• 14:52 這波加速很普遍，大多數國家都一樣，很多政府數據甚至還沒反映出來
  ↳ 這波加速很普遍，大多數國家都是這樣，很多政府統計甚至還沒反映出來。
• 14:52 Stripe economics 的 Substack 文章指出：英國官方統計顯示新公司年減，但 Stripe 依自己的方法論認為英國創業其實大幅增加
  ↳ Stripe 經濟研究在 Substack（電子報平台）上的文章指出：英國官方統計說新公司比去年少，但照 Stripe 自己的算法，英國創業其實大幅增加。
• 15:24 新企業的平均營收在上升而不是下降；達到 10 萬或 100 萬等營收門檻的企業數也都大幅增加
  ↳ 新公司的平均營收在上升而不是下降，營收衝過 10 萬、100 萬等門檻的公司數量也都大幅增加。
• 15:56 有人擔心 AI 會讓經濟更集中，但 Stripe 的微觀數據顯示相反：新公司更多、成功機率更高、整體成長率在改善
  ↳ 有人擔心 AI 會讓市場集中在少數大公司手上，但 Stripe 的細部資料顯示剛好相反：新公司更多、更容易成功，整體成長也在變好。
• 16:26 Stripe 在思考 agent 和 Claude Code 實例要怎麼直接使用 Stripe，也在思考一個大多數交易雙方都是 agent 的世界
  ↳ Stripe 在思考 agent 和 Claude Code 要怎麼直接使用 Stripe，也在思考一個買賣雙方大多是 agent 的世界。
• 16:57 他們在想的問題：agent 怎麼註冊 Stripe？MCP 夠不夠？Stripe CLI 該做什麼？怎麼讓 Stripe 的一切都能從 CLI 或其他 agent 可用的方式操作？agent 之間怎麼付款、用什麼貨幣？
  ↳ 例如：agent 怎麼自己註冊 Stripe？MCP（讓 AI 連接外部工具的標準介面）夠用嗎？CLI（打指令操作電腦的介面）該怎麼設計？agent 之間要怎麼付錢、用什麼貨幣？
• 16:57 Stripe 的內部看法（house view）：大約三年內，大多數交易會發生在 agent 之間
  ↳ Stripe 內部的判斷（house view）是：大約三年內，大多數交易會發生在 agent 跟 agent 之間。
• 17:27 金額上不一定大多數直接在 agent 之間，但若沒有出現大量小額的 agent 對 agent 支付，他會蠻意外的
  ↳ 以金額來算，不一定大多數都直接發生在 agent 之間；但如果沒有出現大量 agent 之間的小額付款，他會蠻意外的。

Patrick 提到一位 Stripe 工程師上半年合併了 600 多個全部用 AI 寫的 PR，其中有多少個需要被 revert？