在企業規模打造 AI-native：monday.com、Doctolib 與 Delivery Hero（第 2/2 段）

🧑‍🏫 這段是 monday.com、Doctolib、Delivery Hero 三家大公司技術主管的座談後半場，講他們怎麼把 AI agent 放進每天的開發工作。內容包括怎麼測新模型、怎麼衡量成效、系統如果重做會改哪裡、工程師的角色怎麼變。最後也給還沒開始用的人很實際的起步建議，很適合想知道「AI 在大公司實際怎麼落地」的人。

• 14:35 大型模型版本上線時會照這套流程走；較小的變更也一樣要做完整的 end-to-end 測試，並在正式環境做 A/B testing
  ↳ 大版本模型上線時要照這套流程測。就算只是小改動，也要做 end-to-end 測試，也就是把整條使用流程從頭跑到尾。之後再到正式環境做 A/B testing：使用者分兩組，比較新舊版哪個好。
• 14:35 主持人的整理：先由自家工程師做內部評估（可能與 Anthropic 的人一起），之後再對客戶與使用者做 A/B testing
  ↳ 簡單說分兩關。第一關是自家工程師先在內部試用評估，有時會找 Anthropic 的人一起看。過了這關，才拿到真實客戶身上做 A/B 比較。
• 15:05 換上大版本模型不能假設它跟舊版相容，要把它當成完全不同的東西，用適合它的方式重新 harness
  ↳ 新模型不能當成「舊版升級、直接替換」。harness 指包在模型外面的提示、工具和流程，換上大版本後，這一整套都要照新模型的特性重新調整。
• 15:37 Delivery Hero：agent 盡量整合進公司現有、而且相當分散的軟體交付生態系，串接 Jira、GitHub Issues，之後也會接 GitLab
  ↳ agent 是能自己動手完成任務的 AI。Delivery Hero 不另起爐灶，而是把 agent 接進公司原本分散各處的工具，像 Jira、GitHub Issues 這類開工作單、追進度的系統，之後也會接 GitLab。
• 16:12 不把介面改成聊天視窗之類的新東西，維持大家原本的工作環境：直接把 ticket 指派給 agent，以此推動採用
  ↳ 他們沒有要大家改成對著聊天視窗講話。工程師照舊在 ticket（工作單）系統派工，只是把承辦人設成 agent。不用改習慣，大家就比較願意用。
• 16:12 整合進 CI 系統：由 agent 跑測試，測試中發現的問題再回饋給 agent 修正
  ↳ CI 是程式一更新就自動跑測試的系統。agent 寫完程式交給 CI 測，測出問題再丟回給 agent 修，變成自動來回修正的循環。
• 16:47 flaky CI 是個大問題，現在由 agent 自己修
  ↳ flaky CI 指測試結果時好時壞：程式明明沒改，有時會過、有時不過，很難查又浪費時間。以前要靠人一個一個追，現在直接交給 agent 處理。
• 16:47 與資安團隊整合：跟程式碼有關的資安漏洞會自動指派給 agent 並自動修好，repo 負責人只要審 pull request 決定是否接受
  ↳ 資安團隊查到程式碼漏洞，會自動派給 agent 修好，再送出 PR（請求把修改併進正式程式的申請）。repo（放程式碼的專案庫）負責人只要審核收不收。
• 17:19 Delivery Hero 對成功率的定義：真正被 merge 的 PR，和被軟體工程師主動拒絕的 PR 之間的比例
  ↳ 他們算成功率的方式很實際：比較 agent 送出的 PR 有多少真的被 merge（合併採用），又有多少被工程師主動退件。只有被收下才算數。
• 17:19 把成功率拉高到 85% 的關鍵是「council of agents」：用一組不同的模型審同一份程式碼
  ↳ 成功率能拉到 85%，關鍵在 council of agents（agent 評審團）。同一份程式碼不是只給一個模型看，而是讓好幾個不同的模型一起審。
• 17:50 選用多個不同模型，是為了避免單一模型有盲點或偏誤，漏掉自己產生的程式碼裡的問題；成本沒有原本以為的那麼高，講者建議大家試試
  ↳ 同一個模型很難看出自己寫的錯，就像自己校對自己的稿。換不同模型交叉審，比較抓得到問題。講者說成本沒有原本想的那麼高，建議大家試試看。
• 18:21 另一位講者：公司正從 monolith 轉向分散式架構，目前大約一半的 PR 在 monolith 內、一半在外
  ↳ monolith 指所有功能都塞在同一個巨大程式裡，分散式則是拆成很多各自獨立的小服務。這家公司正在拆，目前 PR 大約一半在舊的大程式，一半在新服務。
• 18:21 在 monolith 外導入工具容易得多，因為 codebase 較小、pattern 定義較清楚
  ↳ codebase 是一個專案的全部程式碼，pattern 是固定的寫法套路。拆出來的小服務程式碼少、寫法規範清楚，AI 工具在這裡好上手得多。
• 18:54 monolith 外的服務一律採取很 opinionated 的標準寫法；回到 monolith 內就得額外提供大量 context，說明哪個是正確做法、哪個是舊做法
  ↳ opinionated 指規定只用一種標準寫法。新服務都這樣做，AI 很好跟。舊的大程式新舊寫法混在一起，就得多花很多說明，告訴 AI 哪種才是現在要的寫法。
• 18:54 模型很擅長找出過去的寫法，所以要明確告訴它新的做法，別讓它只照 codebase 裡看到的 pattern 走
  ↳ 模型會模仿它在程式碼裡看到的寫法，舊寫法越多，它就越會照舊的寫。所以要明講「現在改用新做法」，不然它只會一直複製過去的習慣。
• 19:26 心得一：codebase 越小、越標準化、內建越多文件，模型表現差異越大
  ↳ 第一個心得：程式碼越精簡、寫法越統一、附的說明文件越多，模型就表現得越好，而且差距很明顯。
• 19:26 心得二：以前寫程式是瓶頸，多一點人工介入無所謂；現在 coding 交給 agent 後，這些地方代價變高，會不斷冒出新瓶頸
  ↳ 以前最慢的是寫程式本身，流程裡多幾道人工關卡也沒差。現在寫程式交給 agent、速度變快，那些人工環節反而變成卡關的地方，解決一個又會冒出下一個。
• 20:27 想要走得更快，就要重新檢視各個接觸點與流程（不只是架構），質疑一切，因為過去的做法已經不適用
  ↳ 想再加速，不能只調整系統架構。每個交接點、每道流程都要拿出來問「還需要這樣做嗎」，因為舊做法是為了人工寫程式的時代設計的。
• 20:27 monday.com：如果重來，會更早、更徹底投入 API first，讓每個服務都一致、邊界乾淨
  ↳ API 是程式跟程式之間溝通、互相取用功能的窗口。API first 指先把這個窗口設計好。monday.com 說重來的話會更早這樣做，讓每個服務規格一致、分工清楚。
• 20:59 這裡講的不只是對外公開的 GraphQL API，也包括內部 API 和服務間的邊界
  ↳ 這不只是給外部開發者用的 GraphQL API（一種對外提供資料查詢的介面格式），也包括公司內部各服務之間怎麼互相呼叫、界線怎麼劃分。
• 20:59 monday.com 過去重押 UI；現在 agent（連外部 agent 也是）需要透過 API 存取系統，但有時預設根本沒有 API
  ↳ monday.com 以前把力氣都放在給人點的畫面上。但 agent 要透過 API 操作系統，外部別家的 agent 也一樣，偏偏有些功能一開始根本沒有 API。
• 21:33 也要徹底重新思考身分與授權系統，把 agent 當成 first-class user；權限模型很細，這部分一直是挑戰
  ↳ 身分和權限也要重新想，把 agent 當成 first-class user，也就是跟真人一樣的正式使用者。但他們的權限分得很細，要給 agent 多少權限一直很難拿捏。
• 22:03 Lightning round，generalist 還是 specialist？monday.com 講者：由一個 generalist 調度多個 specialist（至少目前如此）；另一位也站 specialist 這邊
  ↳ 快問快答：要一個什麼都做的通才 agent，還是各有專長的專才？monday.com 選「一個通才當總指揮，分派工作給多個專才」，至少現階段是這樣。另一位也偏向專才。
• 22:37 頂尖工程師通常是 principal engineer，以往主要審別人的 code、參與架構討論，很少自己寫 code
  ↳ principal engineer 是公司裡最資深的技術專家職級。以前他們主要在審別人的程式、參與系統設計討論，自己很少親手寫程式。
• 23:08 現在情況反過來：他們靠 Claude 等工具產出大量程式碼，比以前更 hands-on
  ↳ 現在反過來了：有了 Claude 這類工具，這些資深工程師自己就能寫出大量程式碼，比以前更常親自下場做事。
• 23:08 PM、engineering manager 等非工程師角色也變得更 hands-on，能自己交付東西或做 prototype
  ↳ 不只工程師，PM（產品經理）、工程主管這些原本不寫程式的人，也開始自己交付功能，或做 prototype（先做出能實際試用的雛形）。
• 23:41 做法也變了：不是守著一個 terminal 同步作業，而是調度多個 agent 替他們做事
  ↳ 工作方式也變了。以前是守著一個 terminal（輸入指令的文字視窗），一步一步等 AI 回應；現在是同時派好幾個 agent 各做各的，自己負責調度。
• 24:12 案例：一位原本做 prompt 優化的資料科學家，調度多個 agent 並寫了一個 skill，用遺傳演算法產生不同 prompt 變體、對每個變體跑 evals
  ↳ 舉例：一位資料科學家寫了個 skill（可重複使用的 AI 工作說明），用遺傳演算法（模仿生物演化，反覆產生、篩選變體）做出多種 prompt，每個都跑 evals（用固定題目測分數）。
• 24:42 頂尖工程師也花時間打造統一共享的 context layer，也就是他們所說的「AI brains」，這在一年半前還不存在
  ↳ 頂尖工程師也在打造大家共用的 context layer，就是把公司的知識和規範整理成 AI 隨時讀得到的背景資料，他們稱為「AI brains」。一年半前還沒有這種東西。
• 24:42 每天早上看什麼指標？其中一位：PR 與 agent 的成功率，用來看 agent 表現如何
  ↳ 每天早上看什麼數字？其中一位看 PR 和 agent 的成功率，也就是 agent 做出來的東西有多少真的被採用，用來判斷 agent 表現好不好。
• 25:14 另一位：品質與可靠度指標。這些是 control KPI，可以確認速度加快之後一切仍然正常
  ↳ 另一位看品質和穩定度。KPI 是關鍵績效指標，control KPI 則是拿來把關的指標：速度變快之後，確認出錯率、故障這些沒有跟著變糟。
• 25:14 monday.com 講者：面向客戶的 AI 體驗除了看成功率，更要深入研究失敗，例如為什麼沒呼叫到正確的 tool、使用者為什麼沒得到想要的結果，常常能挖到新 use case 的金礦
  ↳ 面向客戶的 AI 功能，除了看成功率，更要追失敗案例。例如 AI 為什麼沒叫對 tool（它能使用的功能工具），使用者為什麼沒拿到想要的結果。這常常挖得出新需求。
• 25:44 最後一題：對落後半年的工程師，星期一早上第一件要叫 agent 做的事是什麼？
  ↳ 最後一題：如果有工程師在 AI 這件事上已經落後半年，星期一早上第一件該叫 agent 做的事是什麼？
• 26:14 建議一：先用就對了。過去 12 個月工程師對 AI 有抗拒，一開始模型確實不夠好，但現在光是試用就能做到很多
  ↳ 第一個建議：先用再說。過去一年工程師多半抗拒 AI，早期的模型也確實不夠好。但現在光是動手試，就能做到很多事。
• 26:14 這位講者的公司本季下了 mandate：每個團隊都要用 AI end-to-end 開發一個功能，幫工程師跨過最初的抗拒
  ↳ 他的公司這一季直接下了 mandate（硬性規定）：每個團隊都要完全靠 AI，從頭到尾做出一個功能，幫大家跨過一開始「不想用」的心理關卡。
• 26:44 公司裡不能用，就私下自己用，做出很棒的東西，會感受到早上 Boris 分享時那種熱情
  ↳ 如果公司還不准用，就私下自己試，做點東西出來。做出成果的時候，就會感受到當天早上 Boris 上台分享時的那股熱情。
• 27:14 建議二：請 agent 檢查你的 codebase，告訴它你喜歡和不喜歡哪些地方，請它提改善計畫，再和它一起建立完整的執行流程
  ↳ 第二個建議：讓 agent 看看你的專案程式碼，告訴它你喜歡和不喜歡哪些地方，請它提出改善計畫，再跟它一起把整套做事流程建起來。
• 27:45 建議三：別等完美條件、完美 use case 或「AI-ready」的工作；不要老想著等 monolith 拆完、大型重構做完（可能要一兩季）才開始
  ↳ 第三個建議：別等條件完美，也別等挑到最適合 AI 的任務。更不要想等大程式拆完、大改版做完再開始，那可能要等上一兩季。
• 28:18 可以挑團隊重複在做、屬於 toil、讓人覺得是負擔的工作，放手交給 Claude，看看它的完整潛力
  ↳ 可以先挑團隊一直重複在做、做了又很煩的 toil（瑣碎的苦工），整個丟給 Claude，看看它最多能做到什麼程度。
• 28:48 主持人總結：三位的看法一致，就是先動手試、持續迭代，讓 agent 幫你引路；這場是 Code with Claude 大會的座談
  ↳ 主持人收尾：三位看法一致，就是先動手、邊做邊改，讓 agent 帶你找到方向。這場是 Anthropic 開發者大會 Code with Claude 上的座談。

Delivery Hero 的講者說，把 agent 的成功率拉高到 85% 的關鍵架構做法是什麼？