Boris Cherny 與 Jarred Sumner 的現場寫程式實錄（第 2/3 段）

🧑‍🏫 這段是 Bun 的作者 Jarred 在現場示範。Bun 是一個讓 JavaScript 程式跑起來的工具。他讓 agent 自己讀問題、寫程式、開 PR、跑審查，人只要在最後決定要不要合併。agent 是能自己連續做好幾個步驟的 AI 助手。值得看的地方是：他們直接說出現在最卡的已經不是 AI 寫得好不好，而是人怎麼確定它寫對了。

• 10:43 理想流程：agent 先讀完所有錯誤、把一切準備好，程式碼到人手上時，看完就能有很高的信心按合併
  ↳ 最理想的狀況是：agent 先把錯誤訊息都讀過、測試也準備好，東西交到人手上時，只剩「看一遍、放心按合併」這一步。
• 10:43 Boris 說兩人初次見面時，Jarred 就提過「每個人平行跑數百個 agent」的願景；Boris 當時不太懂，現在自己每晚都跑數百個 agent
  ↳ Jarred 很早就想像過，每個人可以同時開幾百個 agent 各做各的。Boris 當時聽不懂，現在自己每天晚上真的這樣跑，這個願景已經變成日常。
• 11:15 想大幅擴增 agent 數量，就需要 self-verification（自我驗證），agent 才能自主執行
  ↳ self-verification 是 agent 自己檢查成果對不對。要同時開幾百個，人不可能一個一個盯，agent 得會自己驗收，人才放得了手。
• 11:15 Bun 程式庫的做法迭代過很多次：以前只是一個 Discord bot，@ 它就會開一個 container，但沒有 CI，也沒有 code review
  ↳ 早期只是一個 Discord（聊天社群平台）機器人，@ 它就開一個 container（隔離的小型執行環境）來做事。但那時沒有自動測試，也沒人審，品質沒人把關。
• 11:46 現在的流程好很多，Jarred 特別提到 Opus 47（字幕原文）
  ↳ 現在的流程成熟很多。Jarred 特別點名 Opus 47（字幕原文，指 Claude 的某一版模型），意思是模型進步是流程能變好的關鍵之一。
• 11:46 現場檢查進度：agent 已經開出第一個 PR，而且寫了測試
  ↳ 現場看了一下進度：agent 已經開出第一個 PR（交給人審的程式改動），而且主動寫了測試，不是改完就丟著。
• 12:18 現場舉手調查：約一半的人是開一堆 terminal 視窗或 desktop 分頁、手動貼 issue；另一種是像 Robo Bun 這樣更接近閉環的「下一層抽象」
  ↳ 現場約一半的人是自己開很多視窗，把問題一個一個貼給 AI。Robo Bun 更進一步：問題進來就自動處理，人不用在中間來回搬。
• 12:18 Boris 認為 47 是第一個真的做得到這件事的模型；以前要靠大量 scaffolding、丟很多 token 才勉強可行，現在效率夠高，可以每天用
  ↳ scaffolding 是額外替模型搭的輔助流程。以前要搭很多、花很多 token（AI 的用量單位）才勉強做得到；現在夠省，天天用得起。
• 12:49 agent 共開了兩個 PR；PR 裡的 before/after 對照不必特別交代，它很會判斷什麼時候該附，例如字串格式化這類改動
  ↳ agent 開了兩個 PR。改前改後的對照不用特別交代，它自己知道什麼時候該附。像改文字輸出格式這種改動，附上對照最清楚。
• 13:23 agent 保留了 Bun 風格的 label，沒有改成 Node 風格（兩者略有不同）
  ↳ Bun 和 Node（另一個常見的 JavaScript 執行環境）的 label 寫法有點不一樣。agent 沒搞混，保留了 Bun 自己的寫法，代表它有照專案的習慣。
• 13:55 Jarred 審查程式碼：好的地方是分塊寫入，不是一次寫一個 byte；不喜歡它用了 saturation，認為不該需要這樣做
  ↳ Jarred 仔細看了程式：稱讚它一次寫入一整塊資料，不是一個 byte 一個 byte 慢慢寫，比較有效率；但他不喜歡它用了 saturation 這種處理，覺得不需要。
• 13:55 程式碼遵循了 CLAUDE.md（字幕寫作 cloud MD）裡的模式：await using，以及同時 resolve 所有 promise
  ↳ CLAUDE.md 是放在專案裡、寫給 Claude 看的規則說明檔。agent 照著裡面規定的寫法做，像是用完自動清理資源、同時等好幾件工作一起完成。
• 14:25 Jarred 的工作流程看複雜度而定：這個 PR 很簡單，測試通過大概就會合併，但仍會等 Claude code review 跑完
  ↳ Jarred 會看難度決定怎麼審：這個 PR 很簡單，測試過了大概就合併，但還是會等 Claude 的自動 code review（程式碼審查）跑完才按。
• 14:55 Jarred 喜歡 Claude code review 的原因：它會追蹤 control flow，找出不在 diff 裡的問題，像一個有大量 context、會想到各種 edge case 的人類 reviewer
  ↳ diff 是這次改了哪幾行，control flow 是程式執行時走的路線。它會順著路線往下追，找出沒改到、但會受影響的地方，也會想到 edge case（少見的特殊狀況）。
• 14:55 code review 的訊噪比不錯，大約 10% 的時候會錯；以前試過的其他 code review 產品，大部分意見基本上都得忽略
  ↳ signal to noise ratio 是指意見裡有用的佔多少。它大約十次錯一次，算可信；以前用過的其他審查工具，大部分意見只能直接略過。
• 15:59 從 commit 數量圖表看，commit 量從原本較低大幅上升；Bun 用 Rust 重寫一事，Jarred 說只是讓 Claude 跑著，看結果如何
  ↳ commit 是每次存進專案的一筆改動紀錄，圖上的數量大幅上升。Bun 改用 Rust（一種程式語言）重寫這件事，Jarred 說只是讓 Claude 跑跑看會怎樣。
• 15:59 現在的瓶頸是「我有沒有信心合併、它的改動對不對」；這是新情況，以前的瓶頸是程式碼品質不夠好
  ↳ 以前卡在 AI 寫得不夠好。現在寫得出來了，卡點變成人有沒有把握它是對的、敢不敢按合併。這是新出現的狀況。
• 16:33 要讓 Robo Bun 做到 issue 進來、fix 自動出去的完全閉環，難處在驗證改動是否正確很花時間（人推的 PR 也一樣）
  ↳ 目標是問題進來、修好自動出去，全程不用人。難在確認改得對不對很花時間，這點就算是真人工程師交的 PR 也一樣。
• 17:04 兩個改進方向：一是傳達足夠的證據，證明改動正確；二是讓回滾（roll back）更容易
  ↳ 有兩個方向：一是讓 agent 附上足夠證據，人看了就能信；二是讓 roll back（把已合併的改動撤回）更容易，出錯也能馬上退回去。
• 17:35 多數簡單的 issue 應該多按 merge；現在的瓶頸其實是 CI，以及完整執行程式碼、確保測試都能跑；大型專案仍不簡單
  ↳ 簡單的問題其實該放手多按合併。現在真正慢的是 CI（自動跑測試的流程），還有把整套程式實際跑完。大型專案還是不容易。
• 17:35 Jarred 最近用 Claude 做了一些相當大的 PR，主要是用 Claude Code 而不是 Robo Bun，例如為 Bun 加入內建影像處理函式庫，還有一系列後續 PR
  ↳ Jarred 最近的大改動多半直接用 Claude Code（在終端機裡寫程式的 Claude 工具）做，不是用 Robo Bun。例如幫 Bun 內建影像處理功能，後面還接了一串改動。
• 18:07 Boris 觀察：每個人使用 Claude Code 的成熟度與採用程度都不同；對他來說最難的是模型常常變，得不斷重新校準對它能力的認知
  ↳ 每個人用 Claude Code 的熟練程度差很多。Boris 覺得最難的是模型一直更新，得不斷重新確認它現在到底做得到哪些事。
• 18:39 Boris 認為 Jarred 的做法比 Claude Code 團隊開發 Claude Code 本身還領先；團隊已經很自動化，但 Jarred 幾乎是完全閉環
  ↳ Boris 說，Jarred 的做法比 Claude Code 團隊開發 Claude Code 本身還領先：團隊已經很自動化了，Jarred 則幾乎做到全程不用人插手。
• 18:39 過去兩週 Bun 的成果：HTTP3 server、一個 HTTP2 server 的 PR、fetch 支援 HTTP3 與 HTTP2、影像處理 API、進行中的 Rust 重寫（可能不會出貨，是目前最有野心的專案）
  ↳ 兩週內的成果：新版網路協定 HTTP3 的伺服器、一個 HTTP2 伺服器的 PR、fetch（抓網路資料的功能）支援兩者、影像處理 API（給程式呼叫的功能介面），還有可能不會出貨的 Rust 重寫。
• 19:16 benchmark 是 Claude 在另一台 Linux 機器上跑的；Jarred 給的指令基本上就是「make it faster than sharp」
  ↳ benchmark 是跑分、測速度。Claude 自己在另一台 Linux 電腦上跑分，Jarred 的指令幾乎只有一句「做得比 sharp 快」。sharp 是常用的影像處理套件。
• 19:53 Jarred 只給幾個點子，例如去讀 JavaScriptCore 的程式碼，找出如何在非必要時避免複製 typed array，剩下由 Claude 自己完成；這在幾個月前完全行不通
  ↳ Jarred 只給方向，例如去讀 JavaScriptCore（Bun 用的 JavaScript 引擎）的原始碼，想辦法在不必要時別複製資料，剩下由 Claude 自己完成。幾個月前這樣做完全行不通。
• 20:23 AI lab 內部把這叫 hill climbing：給模型一個 metric 和驗證結果的方法，它就會反覆迭代，直到達到那個 metric
  ↳ hill climbing 就像爬坡：給模型一個 metric（能量化的指標，例如速度）和檢查方法，它就改一版、量一次，變好就留下，一路往上直到達標。
• 20:23 Boris 認為 47 特別擅長 hill climbing，是第一個真正擅長這件事的模型，而這個用法還很少人用
  ↳ Boris 認為 47 是第一個真的擅長這種「改、量、再改」的模型，而且這種用法現在還很少人用。
• 20:53 只要給目標、改善效能的方法和衡量方式，並讓它在 auto mode 下跑，它就會一直做到完成
  ↳ 要準備好三樣：目標、可以怎麼改進、怎麼衡量。給齊之後開 auto mode（不用每一步都問人就會繼續做的模式），它會一路做到完成。
• 20:53 code review 的另一個例子：某個 PR 大約有 100 則 comment，Claude 逐一修正，這段時間人可以去做別的事
  ↳ 另一個例子：某個 PR 有大約 100 則審查意見，Claude 一條一條修掉。這段時間人不用在旁邊守著，可以去做別的事。

Jarred 說 Claude code review 的意見大約有多少比例是錯的？