Emergent 如何用 Claude 讓人人都能更容易打造 app ☕ Buy me a coffee

🧑‍🏫 這是 Anthropic 和 Emergent 執行長 Mukund 的對談。Emergent 讓不會寫程式的人，用 AI 做出能真正上線營業的 app。影片講了他們怎麼從做測試工具轉型到現在、為什麼選 Claude、別人為什麼很難追上他們，以及想怎麼服務小型企業。如果你想知道「用 AI 做 app」離真的能拿來做生意還差哪些環節，這支很值得看。

• 00:00 Emergent 服務小型企業：全球小型企業占 70% 就業、50% GDP，但過去一直缺少合適的工具
  ↳ Emergent 的客戶是小型企業。全球七成的工作、一半的經濟產出都來自小公司，但好用的軟體工具多半是為大公司設計的，小店家一直很難用上。
• 00:00 小型企業有上百萬個利基市場，有了 AI 之後，第一次能以零邊際成本服務這些利基市場
  ↳ 利基市場就是很小眾、很特定的需求，例如專做寵物美容預約的系統。以前替這種小市場寫軟體不划算。零邊際成本的意思是多服務一個客戶幾乎不用多花錢，AI 讓這件事第一次做得到。
• 00:00 主持人是 Anthropic Applied AI 團隊負責新創的 Carly，來賓是 Emergent CEO 暨共同創辦人 Mukund
  ↳ 這是一場對談。主持人 Carly 在 Anthropic（開發 Claude 的公司）的 Applied AI 團隊，專門協助新創公司把 AI 用進產品；來賓是 Emergent 的執行長兼共同創辦人 Mukund。
• 00:30 Mukund 和雙胞胎兄弟 Madhav 一起創業，兩人 12 歲開始寫程式，從一開始就專注在自動化軟體工程
  ↳ Mukund 和雙胞胎兄弟 Madhav 12 歲就開始寫程式。兩人創業一開始就鎖定同一個目標：讓電腦自己完成寫軟體的工作。
• 00:30 Mukund 之前經營 Dunzo，帶過 500 人的工程團隊
  ↳ 創業前，他在 Dunzo 帶過 500 人的工程團隊。他很清楚大型軟體團隊實際會卡在哪裡，這段經驗直接影響了後來的產品方向。
• 01:02 進 YC 時最初想做自動化軟體測試，因為他在 Dunzo 看到測試是快速出貨的瓶頸
  ↳ YC（Y Combinator）是矽谷知名的新創加速器，會投資並輔導早期公司。他們剛進 YC 時想做自動化測試，因為在 Dunzo 看到，程式寫完之後的測試最拖慢上線速度。
• 01:02 為了自動化測試，他們得自己打造 container 技術和 coding agent，進而發現只要解決驗證迴圈，agent 就能跑得更久
  ↳ container 是把程式和執行環境打包起來、彼此隔離的空間；coding agent 是會自己寫程式、執行、再修改的 AI。他們發現，agent 只要能自己驗證做得對不對，就能連續工作更久。
• 01:33 後來轉向做通用 coding agent，像應用研究實驗室一樣運作，發明了 test time compute 等技術
  ↳ 後來他們改做「什麼程式都能寫」的 agent，公司運作得像研究單位，邊做邊發明技術。test time compute 一般是指讓 AI 回答時多花運算去想，影片沒有細講他們的做法。
• 01:33 研究跨 agent 的記憶、agent 之間的溝通，是最早把 multi-agent 系統推上正式環境的團隊之一
  ↳ multi-agent 系統就是讓好幾個 AI agent 分工合作。他們研究怎麼讓 agent 共享記憶、互相傳話，而且很早就讓真實用戶用上這種系統，不只停在實驗階段。
• 01:33 一開始先做企業客戶，但發現企業導入速度會很慢
  ↳ 他們一開始先賣給大企業，但大公司的評估、採購、導入流程都很長，要等很久才會真正用起來。
• 02:03 內部 coding agent 被團隊裡的非技術人員用得比開發者還多，讓他們決定讓人人都能做軟體工程
  ↳ 轉捩點是：公司內部的 coding agent，不會寫程式的同事反而用得比工程師還多。他們因此判斷，這東西最大的價值是讓一般人也能做出軟體。
• 02:03 6 月以類似 research preview 的形式推出，當時 agentic coding 還不流行，推出後就爆紅
  ↳ research preview 是「先開放試用、還在實驗中」的版本；agentic coding 是讓 AI 自己規劃並完成寫程式的工作。他們 6 月推出時這種做法還很少見，結果一推出就爆紅。
• 02:03 當時其他人多半在做偏前端、偏展示用途的應用，Emergent 則鎖定能上線的正式軟體
  ↳ 當時同類工具多半做出好看的畫面或示範品，看起來很酷，但不能真的拿來營業。Emergent 的目標是做出能正式上線、給客人使用的軟體。
• 02:34 核心做法是自動化測試、linting、部署、資安和 code review
  ↳ 為了讓軟體真的能用，他們把寫完程式之後的關卡都自動化了：測試、linting（自動檢查程式寫法和明顯錯誤）、部署上線、資安檢查，還有 code review（檢查程式碼有沒有問題）。
• 02:34 使用者多是認真的開發者：想從做出的軟體得到經濟價值的小型企業和創業者
  ↳ 他們的用戶不是玩玩看的人，而是想靠做出來的軟體賺錢的小老闆和創業者，所以要的是真的能營運的成品。
• 03:06 一開始就用 Claude，剛好趕上 Sonnet 推出；他認為做 AI 要想像六個月後的世界，而不是只為現有能力做產品
  ↳ Sonnet 是 Claude 的一個模型系列，他們創業時剛好碰上它推出。Mukund 認為 AI 進步很快，產品要照半年後模型的能力來設計，不要被現在的能力綁住。
• 03:36 Sonnet 的指令遵循很好，擅長寫程式和前端，讓他們能想像長時間運行的 agent 會是什麼樣子
  ↳ instruction following（指令遵循）是 AI 照你交代的要求做事、不自作主張的能力。Sonnet 這點做得好，又擅長寫程式和做畫面，讓他們敢想像 AI 長時間自己工作的樣子。
• 03:36 使用者拿 Emergent 跟 dev shop 比，而不是跟 IDE 或工具比，所以成果最重要
  ↳ dev shop 是接案寫軟體的外包公司；IDE 是工程師寫程式用的軟體。用戶把 Emergent 當成外包團隊而不是工具，所以只看最後有沒有做出能用的東西。
• 04:07 他們重視品質和做出正確成果的機率，勝過速度；Opus 是他們的主力模型，指令遵循能力很強
  ↳ 他們寧可慢一點，也要提高一次就做對的機率。Opus 是 Claude 裡能力更強的模型系列，是他們主要使用的模型，因為它特別能照指令做事。
• 04:07 靠 multi-agent 系統建立的緊密回饋迴圈，能讓 agent 持續運行更久
  ↳ 多個 agent 一起運作時，每做一步就馬上看到結果、立刻修正，形成很緊密的回饋迴圈。錯誤越早被抓到，agent 越不容易走偏，也就能連續工作更久。
• 04:37 現在他們的 agent 能連續跑好幾個小時來打造軟體，內部也有執行嚴謹的 evals
  ↳ evals 是用一套固定題目測量 AI 表現的方法。現在他們的 agent 能連續工作好幾個小時做出軟體，內部也會嚴格測試，確認每次改動是不是真的變好。
• 04:37 小插曲：Emergent 很多工程師在印度，台灣時間半夜也願意在 15 分鐘內上線開會
  ↳ 對談中的小插曲：Emergent 很多工程師在印度，就算是台灣時間的半夜找他們開會，他們也願意在 15 分鐘內上線。
• 05:08 要打造自動化軟體工程平台，就得掌握整個技術堆疊的每一層，讓基礎設施和 agent 互相配合一起打造
  ↳ 技術堆疊是做一個 app 需要的各層技術，從主機、資料庫到程式本身都算。他們認為要把做軟體自動化，每一層都得自己掌握，讓底層設施配合 agent 一起設計。
• 05:40 他們在 Kubernetes 上自建 container 技術，支援記憶體 snapshotting，能保存狀態並平行執行 agent
  ↳ Kubernetes 是管理大量 container 的常用系統。他們在上面自己建執行環境，能把 agent 工作到一半的狀態存成快照（snapshotting），也能同時跑好幾個 agent。
• 05:40 心得：agent 在很多方面就是產品本身，harness 的品質非常關鍵
  ↳ harness 是包在 AI 模型外面的整套機制，例如給它哪些工具、工作流程怎麼走。他們的心得是：agent 本身就是產品，這套機制做得好不好，決定了產品的成敗。
• 05:40 multi-agent 的經驗包括：記憶、agent 間溝通、context 管理、用 caching 降低成本、收緊 container 的回饋迴圈
  ↳ 多 agent 的經驗包括：共享記憶、互相溝通、context 管理（決定 AI 當下要看哪些資料）、用 caching（把重複內容存起來、不再重算）省錢，還有讓執行環境更快回報結果。
• 06:12 從第一天就掌握整個堆疊，因為大部分解決方案都卡在最後一哩路；確保開發環境的表現能在正式環境重現
  ↳ 最後一哩路是指從「做出來」到「真的上線能用」的那一段，很多方案都卡在這裡。所以他們從第一天就掌握所有環節，確保開發時能跑的東西，上線後也一樣能跑。
• 06:12 自認擁有 app 建置領域最完整的 log；很多錯誤只有上線、真實使用者在用時才會出現
  ↳ log 是系統運作時留下的紀錄。他們自認在做 app 這個領域累積了最完整的紀錄，因為很多問題要等真實用戶開始使用才會冒出來，測試階段看不到。
• 06:44 他們把正式環境的錯誤導回開發環境，讓 agent 從中學習
  ↳ 上線後發生的錯誤，他們會送回開發環境，讓 agent 看到並學會怎麼修，下次就不會再犯。
• 06:44 long-term memory：agent 不只從單一使用者 session 學習，還會從所有正在建置的 app 學習，下次用更少 token、更準確地處理
  ↳ long-term memory 是 agent 長期累積的經驗。它不只記得你這一次的使用內容，還會從平台上所有 app 學習，下次處理得更準，也更省 token（AI 的計算用量單位）。
• 07:17 使用者無法自己 debug，所以讓使用者成功的責任大多落在 Emergent 身上
  ↳ 用戶多半不會寫程式，軟體出錯也不會自己修，所以用戶能不能成功，大部分要靠 Emergent 把關。
• 07:17 部署成功率從幾個月前的 84% 提升到將近 98%，靠的是收緊回饋迴圈，讓 agent 可靠又能自我學習
  ↳ 部署成功率是做好的 app 能順利上線的比例。幾個月內從 84% 拉到將近 98%，靠的是讓 agent 更快發現錯誤，並且從錯誤中學習。
• 07:48 使用者拿他們跟 dev shop 比：外包要花 $250,000、做三個月，所以對價格和延遲都不太敏感
  ↳ 找外包做一套軟體要花 25 萬美元、等三個月。相比之下，用戶不太在意 Emergent 多花一點錢或多等一點時間。
• 07:48 他們最重視產品品質而非成本，追求最高推理能力、最高品質的輸出，而不是最快的輸出
  ↳ 所以他們挑模型時先看品質、不看省錢：要最會推理、產出品質最好的，而不是回應最快的。
• 08:21 目標不是一次產出（one-shot），而是可靠的正式系統；跑到 10,000 步時小錯誤會快速累積，所以指令遵循必須很好
  ↳ one-shot 是一次就產出結果。他們要的是能長期穩定運作的系統。agent 要跑上萬個步驟，每一步的小偏差都會越滾越大，所以 AI 一定要能照指令做事。
• 08:53 他認為市場成長的速度比所有業者能服務的還快，所以不太擔心競爭對手或 AI 實驗室在做什麼
  ↳ 他認為這個市場長得比所有業者加起來能服務的還快，所以不太擔心競爭對手，也不太擔心 AI 大廠自己跳進來做。
• 09:23 貼近客戶打造產品：客戶在乎的是真實正式環境的用途、第三方整合、金流、身分驗證，而不是 demo
  ↳ 他們貼近客戶做產品。客戶在意的不是 demo 好不好看，而是能不能真的營業：能不能串接其他服務（第三方整合）、能不能收款、有沒有會員登入這些實際功能。
• 09:23 使用者上傳很大的檔案，所以他們得支援正式環境上的大型檔案系統
  ↳ 例如用戶會上傳很大的檔案，所以上線後的系統必須能存放、處理大量檔案。
• 09:53 程式碼以可水平擴展的方式撰寫，流量成長時基礎設施也會跟著擴大
  ↳ horizontally scalable（水平擴展）是指流量變大時，加開更多機器一起分擔。他們的程式都照這個方式寫，客人變多時系統也撐得住。
• 09:53 護城河一：agent 品質，harness 很強而且持續演進
  ↳ 護城河是競爭者很難追上的優勢。他們的第一道護城河是 agent 的品質：包在模型外面的 harness 很強，而且一直在改進。
• 09:53 護城河二：收集到的資料會用在 long-term memory、自我學習的 agent 和 RL 系統
  ↳ 第二道是資料：累積下來的使用紀錄會用來強化長期記憶、讓 agent 自我學習，也會用在 RL 系統。RL（強化學習）是讓 AI 從做對、做錯的結果中調整行為。
• 09:53 護城河三：只專注一種 tech stack，就像寫程式的 vertical agent，能加速在這套 stack 上累積經驗
  ↳ 第三道是專注：只做一套 tech stack（技術組合），就像專攻單一領域的 vertical agent，在同一套技術上的經驗會累積得更快。
• 10:23 程式碼生成只占問題的 20%，另外 80% 是部署、正式環境維護和資安
  ↳ 他們認為生成程式碼只占整個問題的兩成。剩下八成是部署上線、上線後的維護和資安，這些才是真正難的部分。
• 11:24 他們有 refactoring agent 負責重構 app，還有部署前、部署後的 agent 檢查資安漏洞和金鑰外洩
  ↳ refactoring 是在不改變功能的前提下整理程式碼，方便之後擴充。他們有專門做這件事的 agent，也有在上線前後檢查資安漏洞、金鑰（連接其他服務用的密碼）有沒有外洩的 agent。
• 11:24 Carly 認為新創最能防守的第一點：深入了解使用者、快速迭代，再圍繞使用者建立品牌、go-to-market 策略和使用者體驗
  ↳ Carly 認為新創最守得住的第一點是：比誰都懂自己的用戶、改得夠快，再圍繞用戶打造品牌、go-to-market（把產品推向市場的策略）和使用體驗。
• 11:54 第二點：模型智慧無法跨越的護城河，例如專有資料、基礎設施，或高度監管的領域
  ↳ 第二點是模型再聰明也無法取代的東西，例如只有你手上有的資料、自己建的基礎設施，或是法規很嚴、門檻很高的產業。
• 12:26 第三點：人的信任短期內不會被自動化；最後一點是除了做好現在的產品，也要為未來做準備
  ↳ 第三點是：人與人之間的信任，短期內不會被 AI 取代。最後一點是，除了把現在的產品做好，也要替未來做準備。
• 12:26 Carly 指出模型在長期任務、自主任務上持續進步，一年半前的人可能想不到 Emergent 這種產品會存在
  ↳ long horizon tasks 是需要很多步驟、很長時間才能完成的任務。Carly 說模型在這類任務和自主工作上一直進步，一年半前的人大概想不到會有 Emergent 這種產品。
• 12:59 Emergent 在九個月內重寫了系統四次；每次推出新一級的模型，就把舊東西砍掉，用新模型的角度重新想像
  ↳ 九個月內他們把系統整個重寫了四次。每次有更強一級的模型推出，他們不在舊架構上修修補補，而是直接砍掉，照新模型做得到的事重新設計。
• 12:59 他覺得 Opus 是不同等級的模型，更擅長長期任務，現在還能讓多個 agent 協作同一個任務
  ↳ 他覺得 Opus 是另一個等級的模型，特別擅長需要長時間完成的任務，現在還能讓好幾個 agent 合作完成同一件事。
• 13:29 原本以為用戶會是 PM、設計師等半技術背景的人，結果很多是用它打造正式應用的企業經營者
  ↳ 他們原本以為用戶會是產品經理、設計師這類懂一點技術的人，結果很多用戶是企業老闆，拿它來做真正營業用的 app。
• 14:00 Emergent 其實是為領域專家打造的：深入描述問題，agent 就會替他們把應用做出來
  ↳ 所以 Emergent 其實是給各行各業的專家用的：只要你很懂自己領域的問題，把它講清楚、講深入，agent 就會幫你把 app 做出來。
• 14:00 使用者遍布 190 個國家，將近七百萬人
  ↳ 目前用戶遍布 190 個國家，總數將近七百萬人。
• 14:00 案例：Alaska 的 Christie，身兼臨床心理師和馬術教練，等了 10 年想結合這兩個領域
  ↳ 舉個案例：住在阿拉斯加的 Christie 是臨床心理師，也是馬術教練。她等了十年，一直想把這兩個專業結合起來。
• 14:30 她在 Nova Scotia 找 dev shop 拿到 $1,000 的報價但沒成功；改用 Emergent 後做出 EquiMind，已經上架 App Store，有上百名使用者
  ↳ 她先找了 Nova Scotia 的外包公司，拿到 1,000 美元的報價，但沒做成。改用 Emergent 之後，她做出了 EquiMind，已經上架 App Store，有上百名用戶。
• 15:00 過去的 SaaS 因為經濟考量被迫往高階市場走；有了 AI，能以零邊際成本服務上百萬個利基市場
  ↳ SaaS 是用訂閱方式賣的線上軟體。以前 SaaS 為了賺錢，只能往付得起大錢的大客戶靠攏；AI 讓服務小眾客戶幾乎不增加成本，上百萬個小市場都能照顧到。
• 15:31 未來一年會鎖定中小企業和新創業者；即將推出新 agent，他們認為會比現有的好得多
  ↳ 接下來一年，他們會主攻中小企業和剛創業的人，也即將推出新的 agent，他們認為會比現在的好很多。
• 15:31 隨著長期任務 agent 成熟，他們想從做軟體走向自動化小型企業的整體營運，讓自主運作的企業在平台上成形
  ↳ 等能長時間工作的 agent 更成熟，他們想從「幫你做軟體」，走到「幫小公司把日常營運都自動化」，讓企業可以在平台上自己運轉。
• 16:01 即將推出新產品 Wingman：給企業用的 agent，自動化財務、營運、業務、行銷等業務流程
  ↳ 即將推出的新產品 Wingman 是給企業用的 agent，負責把財務、營運、業務、行銷這些日常流程自動化。
• 16:01 他預測 2026 年大家會開始把大部分業務自動化，Emergent 想成為這樣的平台
  ↳ 他預測 2026 年大家會開始把大部分業務交給自動化處理，Emergent 想成為提供這件事的平台。

Mukund 說 Emergent 的部署成功率，從幾個月前的 84% 提升到將近多少？