從 1 人到 80 人：用 Claude Code 擴張高速成長的工程組織（第 1/2 段）

🧑‍🏫 這場演講由 Base44 的兩位負責人分享：公司從一個人寫程式，一路擴編到 80 位工程師，怎麼靠 Claude Code 讓速度不變慢。這一段最值得看的是他們不走複雜制度，只用幾個簡單的 prompt，就解決了帶新人、審程式、確認產品好不好用這些難題。

• 00:01 講者 Yoav 負責 Base44 的產品，Gabriel 負責 AI；主題是 Base44 從一人創辦工程師擴展到 80 位工程師
  ↳ 兩位講者：Yoav 負責 Base44 的產品方向，Gabriel 負責 AI。他們要講 Base44 怎麼從一個人寫程式，變成 80 位工程師的團隊。
• 00:33 主軸是 Claude Code 如何協助團隊成長，同時維持開發速度（velocity）
  ↳ Claude Code 是 Anthropic 推出、能直接讀寫程式碼的 AI 工具。這場的核心問題是：人一多通常會變慢，他們怎麼用它擴編，出貨速度（velocity）又不掉。
• 00:33 演講分成簡短介紹和兩個階段：從 1 位到 15 位工程師，以及從 50 位到 80 位工程師
  ↳ 先簡單介紹公司，再分兩段講：從 1 人長到 15 人時怎麼做，以及從 50 人衝到 80 人時又遇到哪些新問題。
• 00:33 Base44 是 vibe coding 平台，初衷是打造一個讓任何人都能做出軟體的平台
  ↳ Base44 是 vibe coding 平台。vibe coding 就是用說的描述你想要什麼，讓 AI 幫你寫出程式。它的目標是讓不會寫程式的人也能做出軟體。
• 01:11 創辦人在 2024 年底開始做這個平台，到 2025 年已有可用的產品，並在 LinkedIn 和 Twitter 上 building in public，獲得大量關注
  ↳ 創辦人 2024 年底開始做，2025 年就有能用的產品。他一路在 LinkedIn、Twitter 公開分享開發過程，這叫 building in public，因此累積了很多關注。
• 01:11 2025 年 4 月產品已經獲利，Yoav 就在這時加入
  ↳ 2025 年 4 月產品已經開始賺錢，Yoav 就是在這個時間點加入的。
• 01:46 因為產品獲利、使用者以 AI 為主，引來許多公司關注和收購機會
  ↳ 產品能賺錢，使用者又多半是用 AI 做東西的人，所以有不少公司找上門，想談合作或收購。
• 01:46 被 Wix 收購後，Wix 希望 Base44 保持原本的速度，團隊則從 2 人擴大到 15 位工程師
  ↳ 後來 Base44 被做網站架設的 Wix 收購。Wix 希望他們維持原本的衝勁，所以工程師從 2 人擴編到 15 人。
• 02:17 挑戰一：onboarding 無法擴展，Maor 不可能親自帶每一位新工程師
  ↳ 第一個卡關是 onboarding，也就是帶新人熟悉環境和程式。原本帶頭寫程式的 Maor 不可能一個一個親自帶。
• 02:17 挑戰二：code review 無法擴展，Maor 對 Base44 後端的程式碼非常謹慎，想親自審每個 PR
  ↳ 第二個卡關是 code review。工程師每次改程式都要發一個 PR，也就是提交變更請人審核。Maor 對後端程式很謹慎，想每個 PR 都自己看，人一多就看不完。
• 02:17 挑戰三：不可能讓每位工程師都和 beta tester 坐在一起確認產品是否正常，這件事也必須自動化
  ↳ 第三：以前可以找 beta tester（搶先試用的使用者）坐在旁邊，看產品正不正常。現在不可能每位工程師都這樣做，得改成自動化。
• 02:49 挑戰四：產品很快就有 product market fit，要顧的範圍很廣（integration、agentic flow、視覺化編輯器等），新工程師必須很快上手
  ↳ 第四：產品很快達到 product market fit（市場真的買單），要顧的範圍很廣：外部串接、agentic flow（AI 自己逐步完成任務的流程）、視覺化編輯器等，所以新人得快速上手。
• 02:49 核心心得：尤其是小團隊，一切都要保持非常簡單
  ↳ 整段最重要的心得是：團隊小的時候，不要急著蓋複雜制度，做法越簡單越好。
• 03:22 他們沒有建立審查流程、onboarding 文件或每晚更新的機制，而是讓每位新工程師開工前先下兩個 prompt
  ↳ 他們沒寫新人手冊，沒設審查流程，也沒有安排每晚更新文件，只要求新人開工前先對 Claude 下兩個 prompt（給 AI 的指令）。
• 03:22 第一個 prompt：看過所有 commit，說出每個人在意的是什麼
  ↳ 第一個 prompt：請 Claude 讀過所有 commit（每一次存進程式庫的修改紀錄），整理出每位同事負責什麼、在意什麼。
• 03:53 到了第五、第六位工程師加入時，這個 prompt 就能即時給出整個組織的分工地圖，不必維護 onboarding 文件
  ↳ 團隊到五、六個人時，這招就能馬上產出一張「誰管什麼」的地圖。因為資料來自真實的修改紀錄，內容一定是最新的，不用有人維護文件。
• 03:53 第二個 prompt：深入某個區塊前，請 Claude 畫出該元件運作方式的 mermaid chart
  ↳ 第二個 prompt：要動某一塊程式之前，先請 Claude 畫出 mermaid chart（用文字自動產生的流程圖），看懂那個元件怎麼運作。
• 04:26 因為系統一直在變，這種做法能即時反映現況，由 Claude 幫你保持最新，不用手動更新文件
  ↳ 系統天天在改，手寫的文件很快就會過時。每次需要時才請 Claude 照現況畫圖，看到的永遠是最新版，也不用指派誰負責更新。
• 04:26 為了擴大 Maor 審 PR 的能力：大約一到兩週後，repo 裡就累積了大量 Maor 留下的 PR 評論
  ↳ 接著要把 Maor 審程式的能力「複製」出去。大約一兩週後，程式庫裡已經累積了很多 Maor 在 PR 上留下的評語。
• 04:59 讓 Claude 檢視這些 PR 評論，歸納寫新程式碼時最重要的注意事項，放進 instruction，每隔幾天跑一次
  ↳ 他們請 Claude 讀這些評語，歸納出寫程式時最該注意的規則，寫進給 AI 的指示（instruction）裡，而且每隔幾天重跑一次，讓規則跟上最新狀況。
• 04:59 結果等於在 Base44 內有一個 Maor 版的 PR reviewer，不需要建立複雜的流程
  ↳ 結果就像多了一個照 Maor 標準審程式的 AI 審查員。Maor 不用每個 PR 都自己看，也不需要設計複雜的流程。
• 05:33 案例：新工程師負責 WhatsApp integration，讓使用者透過 WhatsApp 和 agent 溝通
  ↳ 實際例子：一位新工程師負責 WhatsApp 串接，讓使用者可以直接在 WhatsApp 裡跟 AI agent（能自己動手執行任務的 AI 助手）對話。
• 06:05 這個功能需要 integration、改 agentic flow、使用新的 meta API，原本預估要一到兩週
  ↳ 這個功能要串接外部服務、修改 agent 的運作流程，還要用 Meta 的新 API（程式之間溝通的介面），原本估計要一到兩週。
• 06:05 實際上週四晚上交辦、週日早上就完成；新人週四用那兩個簡單 prompt 完成 onboarding
  ↳ 結果週四晚上交辦，週日早上就完成了。而且這位新人週四才剛靠那兩個 prompt 熟悉環境。
• 06:05 PR 審查模型只提出兩三個小意見，接著就能上 production
  ↳ AI 審查員只提出兩三個小意見，改完就直接上 production，也就是真實使用者在用的正式版本。
• 06:37 下一個問題：如何確保上線的東西（尤其是 agent）對客戶真的好用；以前團隊小，會直接坐在客戶旁邊觀察
  ↳ 下一個問題是：上線的東西，尤其是 agent，對客戶真的好用嗎？以前人少，可以直接坐在客戶旁邊看對方怎麼用。
• 07:09 建立 eval suite 對 15 人的團隊來說通常負擔太大
  ↳ 常見的做法是建一套 eval suite，也就是一整組測試題，用來檢查 AI 的表現有沒有變差。但對 15 人的團隊來說，這樣太花力氣。
• 07:09 改從既有的大量 production 流量判斷模型對客戶是否有效
  ↳ 他們改成直接利用手上已有的大量真實使用流量，來判斷 AI 對客戶有沒有用，不另外做測試。
• 07:40 轉換率有參考價值，但他們想知道 agent 本身（特別是對付費客戶）是否正常運作，於是開始看對話內容
  ↳ 轉換率（例如多少人付費）有參考價值，但太間接。他們想直接知道 agent 本身有沒有正常運作，尤其是對付費客戶，所以去看實際的對話內容。
• 07:40 觀察到的規律：運作正常時使用者不太講話，直接做下一個功能；出問題時，使用者會在聊天裡大聲抱怨
  ↳ 他們發現：運作正常時，使用者幾乎不多說，直接做下一個功能；出問題時，使用者會在對話裡大聲抱怨。所以沒人說話反而是好消息。
• 08:10 利用這個強烈訊號，用簡單的模型讓 Claude 把每則訊息的使用者挫折程度分成高或低
  ↳ 抱怨是很明顯的訊號，所以他們用簡單的模型，請 Claude 把每則訊息的使用者挫折程度（frustration level）分成高或低。
• 08:10 每個要發布的 agent 新版本，都先讓一小部分客戶使用，並追蹤挫折程度
  ↳ agent 每推出一個新版本，都先給一小部分客戶使用，並追蹤挫折程度有沒有上升，再決定要不要全面推出。
• 08:43 不管改的是基礎架構、prompt 還是模型，都能用這個方法判斷改動後對使用者是否一樣好用
  ↳ 不管改的是底層系統、給 AI 的指示，還是換了模型，都用挫折程度這一把尺來量，就知道改完之後使用者用起來是不是一樣順。
• 08:43 再次強調：小團隊不必急著建 agent 或 agent orchestration，用精簡的流程就能得到接近的價值
  ↳ 再強調一次：小團隊不必急著打造一堆 agent 或 agent orchestration（讓多個 agent 分工協作的系統），用精簡的流程就能拿到接近的效果。
• 09:43 Gabriel 負責 Base44 的 app builder agent；最近幾個月開始大量對外招募，也有人從 Wix 內部轉調
  ↳ 接著換 Gabriel 講第二階段。他負責 Base44 裡幫使用者做 app 的 AI agent。最近幾個月公司大量對外招募，也有人從 Wix 內部轉調過來。
• 10:16 他們還併入另一個做 vibe coding 的產品，一夜之間人數從 40 人翻倍到將近 80 人
  ↳ 他們又併入另一個做 vibe coding 的產品，人數一夜之間從 40 人變成將近 80 人。
• 10:16 這個階段的三大挑戰之一：如何大規模做實驗；不能期待新人知道要測哪些 KPI、測多久，或是否能直接上線
  ↳ 這個階段的第一個挑戰是怎麼大規模做實驗。新人不會知道該看哪些 KPI（衡量成效的關鍵指標）、要測多久，或能不能直接上線。
• 10:46 不是每件事都需要實驗，他們想把產品管理和 A-B testing 的決策 shift left
  ↳ 不是每個改動都需要做實驗。他們想 shift left，也就是把「要不要做 A-B test（新舊版各給一部分人用、比較結果）」這類判斷，提前到開發階段就決定。
• 10:46 挑戰之二：需要更好的 evals；以前 evals 投資報酬率不高，現在變成必須重視的事
  ↳ 第二個挑戰是需要更好的 evals（檢驗 AI 表現的測試）。以前覺得花力氣做它不划算，現在規模變大，變成非重視不可。
• 11:17 挑戰之三：在非常消費者導向的公司裡，如何做好 QA，又不讓測試人員跟著總人數線性增加
  ↳ 第三個挑戰：公司很面向一般消費者，品質很重要。問題是怎麼做好 QA（品質檢查），又不用每多一批工程師就多請一批測試人員。
• 11:17 實驗流程的構想：在 pull request 準備好時自動執行
  ↳ 他們對實驗流程的構想是：工程師的 PR 一準備好，就自動啟動判斷，不用人另外去問。
• 11:47 目標是讓 bot 在 GitHub 上留言，告訴開發者能否直接上線、是否需要 A-B test、要跑多久、要監控哪些 KPI
  ↳ 目標是讓 bot 直接在 GitHub（存放和審查程式碼的平台）上留言，告訴工程師：能不能直接上線、要不要做 A-B test、要跑多久、要盯哪些 KPI。

Base44 如何在不建立 eval suite 的情況下，判斷新版 agent 對使用者是否好用？