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

🧑‍🏫 這場是 Anthropic 在倫敦辦的座談。三家十多年前就成立的公司分享，他們怎麼在一大堆舊系統和舊習慣上，改造成 AI-native 公司。AI-native 指做事的預設方式就是用 AI，而不是把 AI 當成外掛工具。三家都成立在 LLM 出現之前（LLM 是大型語言模型，也就是 Claude、ChatGPT 背後的技術），這種老公司怎麼轉型，比新創從零開始更貼近大多數人的處境。

• 00:18 主持人 Rebecca 來自 Anthropic Go-To-Market 團隊，這場是在倫敦的首場活動。座談來賓來自 monday.com、Doctolib、Delivery Hero
  ↳ 主持人 Rebecca 來自 Anthropic 的 Go-To-Market 團隊，負責把產品推向市場、和企業客戶合作。這是 Anthropic 在倫敦的第一場活動，請來三家大型企業分享經驗。
• 00:18 三家公司都在 2011–2013 年間成立，比 LLM 時代早。這場座談的主題是它們如何轉型成 AI-native 企業
  ↳ 重點在『老公司怎麼轉』。三家都成立十幾年，產品、流程和人都是在沒有 AI 的年代建立起來的。所以要改的不只是工具，還有整套做事的方式。
• 01:18 monday.com（Ruslan）：Claude 支撐公司的新任務，要從「管理工作的平台」轉型成「幫客戶執行工作的平台」，包括建立 agent 團隊和大量原生 AI 功能
  ↳ 以前 monday.com 是讓你排任務、追進度的地方，事情還是要人自己做；現在要變成 AI 直接幫你把事做完。agent 指的是能自己規劃、動手完成任務的 AI 助手。
• 01:18 monday.com 成立大約 14 年，程式碼一直處在新創模式，是一個 monolith，要拆開需要很長時間，也有很多不完美的地方
  ↳ monolith 指所有功能綁在同一大包程式碼裡，改一個地方可能牽動全身。monday.com 坦白說舊程式碼不完美，要拆開很花時間，這是轉型時的現實包袱。
• 01:48 Doctolib 有兩個使命：讓人們更健康，以及改善醫療專業人員的日常工作。對一般民眾提供預約看診、病患訊息、個人健康紀錄等服務
  ↳ Doctolib 是醫療服務平台，一邊服務民眾：線上預約看診、跟診所傳訊息、保存自己的健康紀錄；另一邊服務醫護人員，減輕他們日常工作的負擔。
• 02:21 Doctolib 用 Claude 開發的採用率幾乎達到 100%，不只工程師，產品經理和設計師也在用。技術與產品部門以外，也有很大比例的員工開始用 Claude 處理日常工作
  ↳ 在 Doctolib，用 Claude 幫忙寫程式幾乎是全員標配，連不寫程式的產品經理和設計師也在用。其他部門也有很多人用它處理日常工作，AI 已經不只是工程師的工具。
• 02:21 Doctolib 的程式碼大約一半是十多年前創立時寫的 monolith，另一半是近幾年建置的分散式系統和服務
  ↳ distributed systems（分散式系統）是把功能拆成很多小服務，各自運作。Doctolib 的程式碼新舊各半，AI 工具得同時應付舊的一大包程式和新的拆分架構。
• 02:53 Ulrich Schäfer 是 Delivery Hero 的 VP for tech foundations。Delivery Hero 是全球領先的在地外送網路，在超過 60 個市場配送餐點、生鮮雜貨等
  ↳ Ulrich 負責 Delivery Hero 的技術基礎建設，也就是讓全公司工程師開發順暢的底層工具和平台。Delivery Hero 在 60 多個市場做外送，規模很大。
• 03:24 Delivery Hero 正在把 Claude Code 推廣給工程師，產品裡也用了 Claude。這次分享的重點是他們的自主軟體交付系統 HeroGen
  ↳ Claude Code 是 Anthropic 推出、讓 AI 直接讀寫和修改程式的工具。Delivery Hero 一邊推廣給工程師用，一邊自己做了 HeroGen：讓 AI 自己完成開發工作的系統。
• 03:24 主持人指出：三家公司都不是 Greenfield 開發，都已經有運作中的產品、大量客戶、大型工程組織和多年的程式碼
  ↳ Greenfield 指在空地上從零開始蓋，沒有歷史包袱。這三家剛好相反：產品每天都有客戶在用、工程師很多、舊程式一大堆，一改錯就會直接影響營運。
• 03:58 Delivery Hero 呼應當天早上 keynote 的說法：要為「下一代模型」而不是目前的模型來打造。他們去年看了模型的發展軌跡，就照這個原則做
  ↳ keynote 是活動開場的主題演講。這句的意思是：不要照現在 AI 的能力來設計，要預想下一代更強的模型。Delivery Hero 去年看了模型進步的速度，就照這個方向先蓋系統。
• 04:29 HeroGen 會接收 Jira ticket 或 GitHub issue，一路做到 production readiness，產出可以直接 merge 的 pull request
  ↳ Jira ticket 和 GitHub issue 是登記待辦事項的工單；PR 是改好程式後送出的審查單，merge 是審過後併入正式版。production readiness 指品質夠格上線，HeroGen 從接單一路做到這一步。
• 04:29 HeroGen 在去年最後兩季建置、今年 Q1 上線，在所有工程師和集團子公司之間獲得很大的迴響
  ↳ HeroGen 去年下半年開發，今年第一季正式推出。不只總部工程師，連集團底下各子公司都很買單，代表這是大家真的想用的工具，不是實驗室裡的玩具。
• 04:59 數據：最近 10 天平均每天約 173 個 merge 進 production 的 PR。2 月上線至今總共約 7,000 個 merged PR，成長趨勢是指數型的
  ↳ production 是真正給用戶用的正式系統。最近平均每天約 173 個 PR 被合併上線，從 2 月上線到現在累計約 7,000 個，而且用量越長越快。
• 05:33 Doctolib 的重點是讓每個人都開始用 Claude，而且用得有效。他們刻意不只讓平台團隊負責，也要善用所有工程師的專業、創意和創新
  ↳ Doctolib 不把導入 AI 的工作丟給平台團隊（負責內部共用工具的團隊）一手包辦，而是要每個工程師都用、都用得好，讓大家的點子一起貢獻出來。
• 05:33 理由：最優秀的工程師最能找到運用新技術的有趣方法
  ↳ 新技術的好用法常常不是事先規劃出來的，而是第一線的高手自己摸索出來的。與其由上而下規定怎麼用，不如讓最厲害的人自由去試。
• 06:06 平台團隊的工作是「賦能」：找出大家在用的最佳實踐，排除瓶頸或把它們工業化，再推廣到所有團隊
  ↳ 平台團隊的角色不是發號施令，而是當推手：找出誰的用法最好，排除卡住大家的地方，或把好做法做成標準化工具，再推廣到每個團隊。
• 06:06 Doctolib 建了一個 skills marketplace，讓每個人把自己做的 skill 分享給所有人。上面的 skill 都能被搜尋到，也看得到哪些使用量最高、哪些正在流行
  ↳ skill 是一套寫好的做法說明，Claude 需要時會照著做。marketplace 像公司內部的 App 商店：大家上架自己做的 skill，可以搜尋，也看得到哪個最多人用、最近最紅。
• 06:36 他們也提供一個開發環境，一開始工作所有工具就自動連好，許多 skill 直接打包在裡面，新人一到職就能使用。實驗性的 skill 則用 plugins 提供
  ↳ 新人開機就有設定好的開發環境，工具都接好了，常用的 skill 也內建，不用自己摸索安裝。還在測試的 skill 則做成 plugins（可自行加裝的外掛），想試的人自己裝。
• 07:06 公司裡最熱門的頻道叫「Build With AI」，大家在裡面分享心得、發問、推廣自己的 skill。目標是一起走過學習曲線，而不是各自摸索
  ↳ 公司裡最熱門的頻道叫『Build With AI』，大家在裡面分享心得、發問、推廣自己的 skill。重點是一起學，不要每個人各自踩同樣的坑。
• 07:36 monday.com 在平台上建置能執行工作的 platform agent，也讓外部 agent 成為平台上的一等公民，因此在身分系統和權限模型上遇到不少挑戰
  ↳ platform agent 是 monday.com 自己做、在平台上幫你做事的 AI。他們也讓外部的 AI 能像正式用戶一樣操作，因此得重新設計：這個 AI 是誰、能看什麼、能改什麼。
• 08:06 monday vibe 是 monday.com 史上最成功的發布之一。這是一個開放給使用者、用 prompt 建立應用程式的工具，採用量呈指數成長
  ↳ monday vibe 讓用戶用一段文字指令（prompt）描述需求，就能做出一個應用程式，不用會寫程式。這是 monday.com 史上最成功的發布之一，使用量成長得非常快。
• 08:06 monday vibe 會把簡單的 prompt 轉成詳細的 PRD，理解客戶的意圖並和客戶一起修改，幾分鐘內就能做出可運作的應用程式
  ↳ PRD 是產品需求文件，寫清楚要做什麼、怎麼運作。你只要說一句『我要一個請假審核工具』，vibe 就會先寫成詳細規格、跟你確認修改，幾分鐘內做出能用的程式。
• 08:36 因為 monday.com 很早就投資了給外部開發者用的開放平台，vibe 的 POC 只花了幾天就完成
  ↳ POC（概念驗證）是先做一個能動的雛形，證明想法可行。monday.com 早年就開放平台給外部開發者使用，vibe 直接建立在這個基礎上，所以幾天就做出來了。
• 09:06 vibe 使用和外部開發者相同的 API、SDK、部署機制和發布方式，因此能把老舊程式碼的複雜度隔開，大幅加速初期開發
  ↳ API 是程式之間溝通的標準窗口，SDK 是配套的開發工具包。vibe 用的是和外部開發者同一套工具，不必直接碰內部複雜的舊程式，所以起步特別快。
• 09:40 要讓 vibe 接上平台的每個功能，每個功能都必須開放 API、能被正確存取。這條路還很長，但早期對開放平台的投資在這裡得到了回報
  ↳ vibe 要能用到平台的所有功能，每個功能都得開好 API 窗口。這件事還沒全部做完，但當年投資開放平台，現在證明很值得：地基打好了，AI 才接得上。
• 10:11 主持人問：每當有新的 Claude 模型推出，組織內部那一週會發生什麼事
  ↳ 主持人想知道：每次 Claude 推出新模型，公司內部實際上會怎麼反應、怎麼處理，是立刻換、先測試，還是觀望。
• 10:11 Delivery Hero：去年 11 月推出的新 Opus 模型帶來了跳躍式的進步，讓 HeroGen 的願景真正實現。在那之前，這只是一個看起來很酷的想法
  ↳ Opus 是 Claude 最高階的模型系列。去年 11 月推出的新版 Opus 能力大躍進，HeroGen 才真的做得起來；在那之前，『AI 自己完成開發』只是聽起來很酷的點子。
• 10:42 他們當初下了一個大賭注：賭模型會進步到能接手整個功能，替工程師完成所有工作
  ↳ 他們先押了寶：在模型還做不到的時候就開始蓋系統，賭模型會強到能把一整個功能從頭做完，而不只是幫忙寫一小段程式。
• 11:12 HeroGen 之後一直使用 Opus 4.5，還沒做較大的模型切換，主要是因為還沒有 A-B testing 的設置和足夠的量
  ↳ A-B testing 是讓兩個版本同時跑，比較哪個效果好。Delivery Hero 還沒建好這套比較機制，累積的資料也不夠多，所以不敢貿然換模型，一直停在 Opus 4.5。
• 11:44 Doctolib：新模型推出時，大家首先是很興奮，會想「現在能做哪些以前做不到的事」
  ↳ Doctolib 的第一反應是興奮。大家會去想：以前 AI 做不到、只能放棄的事，現在是不是做得到了？他們把新模型當成新機會，而不是麻煩。
• 11:44 以前寫 skill 或 workflow 時，常常要彌補模型的不足。新模型出來後可以回頭檢查：「這段還需要嗎？」
  ↳ workflow 是一連串固定步驟的工作流程。以前為了彌補舊模型的弱點，常要多寫提醒或繞路；新模型出來後就該回頭檢查，這些補丁還需要嗎？也許可以刪掉。
• 11:44 如果已經有實驗文化，大家會主動想嘗試新模型，不需要別人提醒「你看到了嗎？要不要處理一下？」
  ↳ 如果公司本來就鼓勵大家嘗試新東西，新模型一出，員工會自己去試，不用主管追著問『你看到了嗎？要不要處理一下？』。
• 12:16 Doctolib 提供給客戶的 AI 產品有團隊負責很嚴格的 evals。每次有新模型發布，都會檢查表現，以及各項變數之間的取捨
  ↳ evals 是一組固定的測驗題，用來評估 AI 的表現。Doctolib 給客戶用的 AI 產品有專門團隊把關，新模型一出就先測驗，看哪裡變好、哪裡變差，再權衡取捨。
• 12:46 在開發端，Doctolib 目前還是比較「憑感覺（vibes）」。他們希望有更好的驗證方式，讓團隊更有信心，也能更快推進
  ↳ 不過在內部寫程式這一邊，新模型好不好目前還是憑感覺判斷。他們希望建立更可靠的檢驗方法，讓團隊換模型時更有把握、推進得更快。
• 13:16 monday vibe 是 multi-model 系統：orchestrator 用 Opus 模型，底下的 workflow 則由確定性動作和較簡單的模型執行各個子動作
  ↳ multi-model 是一個系統裡混用好幾種模型。orchestrator 是總指揮，由最強的 Opus 負責規劃和分工；底下的細項交給固定的程式步驟或較簡單的模型執行。
• 13:16 新模型發布通常只影響系統的其中一部分，所以 end-to-end evaluation 是關鍵，同時每個部分也對各自的 atomic action 跑 evals
  ↳ atomic action 指拆到最小的單一步驟。換模型通常只動到系統的某一塊，所以要做 end-to-end evaluation，從頭到尾測整套流程，每個小步驟也各有自己的測驗。
• 13:46 從 Opus 4.5 換到 4.6 是很大的改變：新能力很強，但之前優化好的 system prompt 都移轉不過去，模型「完全不一樣」，必須重新思考並調整 prompt 技巧
  ↳ system prompt 是事先給 AI 的固定指示，決定它的角色和做事方式。從 Opus 4.5 換到 4.6，能力更強了，但原本調好的指示反而不適用，得重新摸索怎麼下指令。
• 14:18 monday.com 團隊和 Anthropic 的 solution engineers 密切合作，深入了解最佳實踐。之後遇到重大模型發布都照這個方式做
  ↳ solution engineers 是 Anthropic 協助企業導入產品的技術顧問。monday.com 和他們密切合作，搞懂新模型的最佳用法，之後每次重大改版都照這個模式處理。

依照 Delivery Hero 的分享，HeroGen 最近 10 天平均每天大約有多少個 merge 進 production 的 pull request？