Ramp 工程師如何在每個環節與 AI agents 協作（第 1/2 段）

🧑‍🏫 金融科技公司 Ramp 的工程師分享他們怎麼把 Claude 的新模型 Fable 用在寫程式的每個環節，從寫程式、測試、上線到事後追蹤都有。重點不在教你寫程式，而是一套想法的轉變：怎麼一步步信任 AI、放手讓它做，又怎麼守住安全。就算你不寫程式，也能拿來當和 AI 合作的參考。

• 00:32 拿到 Fable 後，第一步是找 Ramp 裡能用實驗驗證的用例：一大段由 Fable 寫、自己沒讀過的程式碼，而且要放在非產品的地方，例如 CI 測試套件
  ↳ 拿到新模型 Fable 後，他們先挑「結果能用實驗驗證」的地方試：讓 Fable 寫一大段程式、自己不看，放進 CI（每次改程式就自動跑測試的系統）這種不影響客戶的地方。
• 00:32 這段程式碼以 shadow 方式跑了幾週，一直比現行實作還快
  ↳ shadow 是讓新程式在旁邊跟舊程式一起跑，但不真的接手，只拿來比較結果。跑了幾週，新版一直比較快。這表示就算沒逐行讀，也能用數據確認 AI 寫的東西可靠。
• 01:02 他們把程式碼庫的深層問題也丟給 Fable：在大型單體（monolithic）Python 程式碼庫裡修掉所有 import cycle，並讓 app 變成 lazy 載入。兩項都有很大進展，很多程式碼已經 merge
  ↳ import cycle 是程式檔案互相引用、繞成一圈，讓系統難改又啟動慢；lazy 載入是用到才載入，所以 app 開得比較快。這種積了很久的老問題，Fable 也推進了很多，不少修改已經正式併入。
• 01:02 弄清楚模型在哪裡會失敗非常重要。這類問題，就是下一版 Fable 或下一次 release 推出時要讓大家拿去測的題目
  ↳ 知道模型「做不到什麼」跟知道它會什麼一樣重要。這些還沒解決的難題就留下來當考題，下一版模型推出時拿來測，看它是不是真的有進步。
• 01:32 講者有一組測試，每個新模型推出都會跑一次。之前沒有模型能全部完成，這是第一個全部完成的模型
  ↳ 講者自己有一套固定的考題，每次有新模型推出就考一次。以前沒有模型能全部完成，Fable 是第一個全部做完的。
• 01:32 Fable 卡住時就改用 dynamic workflow：Claude 同時指揮一群 subagent，等於一種新形式的 test time compute。只要跟 Claude 說「用 workflow」就行
  ↳ subagent 是主 agent 派出去做子任務的分身。dynamic workflow 是讓 Claude 當工頭指揮一群分身，等於它作答時投入更多運算（test time compute）。直接跟它說「用 workflow」就能開始。
• 01:32 它把 CI 時間從大約 P50 18 分鐘降到 P50 6 分鐘，靠的是一輪接一輪的優化，而且持續做 profiling
  ↳ P50 是中位數，一半的執行比這個快、一半比這個慢。CI 的中位數時間從 18 分鐘降到 6 分鐘，不是一招就見效，而是一邊 profiling（量測哪裡最花時間）一邊一輪一輪改出來的。
• 02:02 程式碼上線後，它用 routine 排程自己一天後再跑，拿真實 production 數據。就這樣連續好幾天重複，把成果都落地，最後還給出一張圖表
  ↳ routine 是可以排程、到時間自動執行的任務。程式上線後，它自己排好「明天再回來看」，用 production（客戶正在用的正式環境）的真實數據檢查，連續好幾天，最後還交出成效圖表。
• 02:32 主持人提問：用 dynamic workflow 前，應該要先把 Fable 當 foreground 主 agent 用到熟悉吧？背景可能有 40 或 100 個 agent 在跑，你看不到全部
  ↳ foreground agent 就是你眼前直接對話的那個主 agent。主持人問：背景可能同時跑 40 或 100 個分身，根本看不完，是不是應該先把單一個 Fable 用熟，再放手？
• 03:03 這些 agent 可以並行或依序執行，也可能依任務需要多加幾輪 adversarial verification。講者的回答是「我就是信任它」
  ↳ 這些分身可以同時做，也可以接力做，需要時再加幾輪 adversarial verification，也就是專門派一方挑毛病、找漏洞的驗證。講者回答得很乾脆：他就是信任它。
• 03:03 講者的心智模型：test time compute 從 low、medium、high、extra high 到 max，代表模型最多能用的思考量（不一定會用滿）。dynamic workflow 則是再上一層、全新的 test time compute
  ↳ 設定裡從 low 到 max 的選項，是模型「最多可以想多久」的上限，不一定會用滿。講者把 dynamic workflow 看成比 max 再高一層：不只是想更久，而是讓一群分身一起想。
• 03:33 loop 跟 dynamic workflow 的差別：loop 處理重複性工作；dynamic workflow 處理事先不知道步驟的動態工作
  ↳ loop 是讓 agent 反覆做同一件事的機制。分工的原則是：固定、重複的工作交給 loop；不知道下一步是什麼、要邊做邊決定的工作交給 dynamic workflow。
• 03:33 舉例：用 loop 照看自己的 pull request，自動修 CI、rebase；做系統優化時用 dynamic workflow，因為不知道下一個優化是什麼
  ↳ pull request（PR）是把改好的程式送審的申請。loop 適合顧 PR：CI 壞了就修、自動 rebase（同步主線最新版本）；優化系統要用 workflow，因為下一步得看到結果才知道。
• 04:04 這是心智模型的全面轉變，就像第一次用 Claude Code，要開始把軟體工程流程（包括執行指令）交給 agent
  ↳ 就像第一次用 Claude Code（Anthropic 的寫程式 agent 工具）時，要學著把下指令、跑流程交給它，這次又是一次整個思維的轉換，要學著交出更多工作。
• 04:04 loop 像是從眾多工程師的工作中切一條「橫向」：每個工程師每天都做的事，就放進 loop 或 routine，例如 code review、照看 PR、處理回饋
  ↳ 「橫向」指的是每個工程師每天都在做的共同雜事，像 code review（審查別人的程式）、顧 PR、回應別人的意見。這種每個人都要做的事，就做成 loop 或 routine 讓它自動跑。
• 04:35 他們有好幾十個這種 routine，例如每天跑一次、刪除 dead code 的 routine
  ↳ 他們已經有好幾十個這種自動任務。例如有一個每天跑一次，找出已經沒在用的 dead code（沒用到的程式碼）並刪掉，讓程式碼庫保持乾淨。
• 04:35 「縱向」切法是 Claude tag。例如讓它上線一個實驗：建實驗、land PR、用 routine 設提醒隔天檢查，確認 exposure 平衡後調高 exposure；幾週後再開 PR 上線勝出的 variant
  ↳ 「縱向」是用 tag 把一件事從頭到尾交給 Claude。以上線實驗為例：它建實驗、併入 PR、隔天回來確認各組 exposure（被看到的人數）平衡再加量，幾週後上線勝出的版本。
• 05:05 整個實驗過程講者只在開頭請 Claude 做，並核准了 pull request，其餘都是 Claude 自己完成
  ↳ 整個實驗，講者只做了兩件事：一開始交代任務，中間核准 PR。其他幾週的檢查、調整、上線都是 Claude 自己完成。人從動手做的人，變成負責把關的人。
• 05:05 講者之一的設定：iTerm2、不用 IDE、螢幕能開幾個窗格就開幾個；Claude Code 很陽春，plugin、skill、MCP 很少，CLAUDE.MD 很簡單
  ↳ iTerm2 是 Mac 的終端機程式。他不用 IDE（寫程式的整合軟體），只開一堆終端窗格；plugin、skill、MCP（接外部工具的擴充）都很少，CLAUDE.MD（給 Claude 看的說明檔）也寫得很簡單。
• 05:35 這種陽春設定的靈感來自 vanilla setup 的 Twitter 貼文，他認為這是學會模型最好的方式；也大量用 subagent 和 adversarial review
  ↳ vanilla setup 指幾乎不改裝、接近原廠的設定。他認為東西加得少，才看得清模型本身的能耐；不過他會大量用分身和 adversarial review（專門挑毛病的審查）。
• 05:35 另一位講者的工作越來越偏背景執行，大部分 session 都在蒐集資訊，例如「這個服務的記憶體為什麼飆高」。可以一次展開很多 session 來蒐集 context
  ↳ 另一位講者多半讓 Claude 在背景跑，而且主要拿來查資料，不是寫程式，例如「這個服務的記憶體為什麼暴增」。可以一次開很多 session（對話工作階段），同時蒐集線索。
• 05:35 在本機用 Claude Code 通常是比較需要親自動手的程式工作，例如近距離 debug，或需要自己電腦上的服務與 context
  ↳ 會在自己電腦上用 Claude Code 的，通常是需要親自盯的工作，例如近距離 debug（抓錯），或是需要本機才有的服務和背景資料的時候。
• 06:05 他們服務很多（資料庫、message queue 等），同時跑多個 local dev instance 很快就會碰到限制
  ↳ local dev instance 是在自己電腦上跑的一整套開發環境。Ramp 的系統有資料庫、message queue（讓程式排隊傳訊息的元件）等很多服務，本機同時開好幾套很快就吃不消。
• 06:05 最新模型需要的手把手引導少很多，有時就該放手讓它做。講者發現自己太常開著筆電蓋子走來走去，所以決定改變做法
  ↳ 新模型不太需要人一路牽著走，有時候就該放手。講者發現自己常掀著筆電蓋子走來走去，等於被本機跑的任務綁住，所以決定改變做法。
• 06:35 Ramp 幾乎在業務的每個環節都導入了 agent，工程生命週期尤其多：想點子、找 bug、從 log 和系統收到問題通知、寫程式、review、部署後觀察 production 表現
  ↳ Ramp 幾乎每個部門都在用 agent，工程最多：從想點子、找 bug、從 log（系統紀錄）收到異常通知、寫程式、審查，一直到上線後觀察正式環境的表現，都有 agent 參與。
• 07:05 他們也從資安角度建置 agent 系統，用來找 bug 和其他問題
  ↳ 他們也從資安的角度做了一套 agent 系統，專門用來找 bug 和其他安全問題。
• 07:37 他們逐漸體認到模型會持續進步，所以不該為 2.7 打造，而是為下一代甚至再下一代模型打造
  ↳ 他們體認到模型會一直變強，所以不為現在的 2.7 版量身打造，而是預先替下一代、甚至下下代的模型設計系統，免得一做完就過時。
• 07:37 他們學會退一步等待，因為常常一再拆掉自己搭的 scaffolding：模型的能力已經超過 harness 了
  ↳ harness 和 scaffolding 是替模型搭的輔助架子，例如額外的規則、流程、補強工具。他們常發現架子才搭好，模型就已經用不到，只好拆掉，所以學會先等一等再搭。
• 08:07 產品今天就得能用，但遇到 harness 或模型的不足時，他們盡量往另一個方向走：給模型更多工具、context 和自主權，目標是把 agent 當同事對待
  ↳ 產品今天就得能用，但碰到模型能力不夠時，他們不是加更多限制，而是反過來給更多工具、資料和自主權。目標是把 agent 當成同事，而不是要一步步操作的工具。
• 08:07 例如直接請 agent 查某個突然冒出來的 exception，或處理客戶抱怨的問題。希望模型能用適當權限存取對的系統，寫出剛好需要的程式碼
  ↳ 例如直接叫 agent 去查突然冒出來的錯誤（exception），或處理客戶抱怨的問題。希望它有剛好的權限、進得了對的系統，只寫剛好需要的程式。
• 08:39 這是一場「速度的賭注」：為了讓現在的模型好用而加的東西，很快會變成技術債、拖慢速度；瞄準更遠的未來，用同樣的資源反而走得更遠
  ↳ technical debt（技術債）是為了一時方便留下、之後得花力氣收拾的東西。為了遷就現在的模型而加的補丁，很快會變成負擔；瞄準未來做，同樣的資源能走得更遠。
• 09:09 主持人問到擴大規模時的 guardrail：怎麼控制資料存取範圍、控制成本、確保程式碼品質
  ↳ guardrail 是防止出事的護欄。主持人問：agent 規模變大之後，要怎麼管它能碰哪些資料、怎麼控制花費、怎麼確保程式品質？
• 09:09 他們在堆疊的各層都加了 safeguard，而且花很多時間研究 trace：更重視逐一研究個別 trace，比較少看整體 benchmark
  ↳ safeguard 是安全防護。他們在系統每一層都設防護，也花很多時間看 trace（模型一步步實際做了什麼的紀錄），比起看整體分數，更重視一筆一筆細看。
• 09:41 benchmark 能提供跨模型的資訊，但通常存在一條「正確 trace」：模型當下該跑什麼指令、為什麼沒做到？是 context 問題，還是沒有對的工具？
  ↳ benchmark（標準化評測）適合拿來比較不同模型，但更有用的是對照「正確的做法」：這一步模型該下什麼指令？為什麼沒做到？是缺資訊，還是缺工具？
• 09:41 他們建立了多層防禦，而且會持續加。防禦層數越多，就越能加快腳步，也越能給模型更多自主權和存取權
  ↳ 防護是一層一層疊上去的，而且會持續增加。防護越多，他們反而越敢加快速度，也越敢給模型更多權限，就像煞車夠好的車才敢開快。
• 10:11 原則是在每一層都給模型需要的一切，但不多給。例如接 BigQuery 或 Data Dog 時，給它唯讀的 service key
  ↳ 原則是「需要的都給，多的不給」。例如讓它連 BigQuery（Google 的資料倉儲）或 Data Dog（系統監控服務）時，只給唯讀的 service key（程式用的存取憑證），只能看、不能改。
• 10:11 他們專注在預設體驗，也就是「iPhone 體驗」：打開就是一個文字框，說要完成什麼，而不是怎麼做
  ↳ 他們最重視預設體驗，要像 iPhone 一樣打開就會用：畫面上只有一個文字框，你說想達成什麼就好，不需要教它怎麼做。
• 10:11 prompt 必須是 declarative 的：不要指示 agent 用特定方法做，只要說「實作這個功能」「修這個 bug」「幫這個人」
  ↳ declarative（宣告式）prompt 就是只講目標、不講步驟。例如「修這個 bug」「幫這位客戶」，不規定要用什麼方法，讓 agent 自己判斷怎麼做。

根據影片，Fable 用 dynamic workflow 優化後，Ramp 的 CI 時間有什麼變化？