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

🧑‍🏫 這段是 Claude Code 團隊的 Boris Cherny 和 Bun 的 Jarred Sumner 現場示範。他們同時開好幾個 Claude 修 Bun 的問題，大約 30 分鐘內陸續交出好幾份修改。值得看的是他們怎麼讓 AI 長時間自己跑，還有當寫程式不再是難關之後，人的工作重心移到了哪裡。

• 21:23 講者說自己只放了大約 10% 的注意力，同時在做五件事。這種做法在 6 個月前還做不到，3 個月前也才剛變得可行
  ↳ 講者一邊直播聊天，一邊讓五個 Claude 各做各的事，自己只分出大約一成的心思盯著。這種一個人顧好幾條線的用法，半年前還做不到，三個月前才剛行得通。
• 21:23 查看各 session 的進度：已經有一個 PR，另一個 PR 看起來很快也會出來
  ↳ session 就是一個獨立的 Claude 工作對話。他一個一個看進度：有一個已經交出 PR（pull request，就是「我改了這些，請審核」的修改申請），另一個也快好了。
• 21:54 講者認為這個 PR 應該是最棘手的。看起來大致合理，但講者自己不會完全這樣寫，因為檢查太多，需要更優化的做法
  ↳ 他覺得這份 PR 是今天最難的一題。Claude 的改法大致說得通，但加了太多檢查，效率不夠好，他自己寫會更精簡。可見 AI 的結果能用，不代表就是最好的寫法。
• 21:54 這套設定主要用 CLI，權限一律用 auto mode。在這之前用的是 dangerously skip permissions
  ↳ CLI 是在終端機裡打字下指令的操作方式，他主要用這個。權限一律交給 auto mode，讓系統判斷哪些動作可以直接做，不用每一步都等人同意。在這之前他用的是另一種比較危險的做法。
• 22:29 用 dangerously skip permissions 可能會刪掉東西，講者說自己不應該推薦它
  ↳ dangerously skip permissions 就是「跳過所有權限確認」，Claude 想做什麼就直接做，連刪檔案也不會先問。名字裡就寫了「危險」，講者也承認自己不該推薦。
• 22:29 等 Claude 請你按 approve 很無趣：你跑去做別的事，它就一直卡在那裡。auto mode 是真正解決這件事的方法，而不是單純放手信任
  ↳ 如果每一步都要你按 approve（同意），你一走開它就停在原地乾等，同時做好幾件事的好處就沒了。auto mode 不是乾脆全部放行，而是真的解決「卡著等人」這個問題。
• 22:59 輸入框（composer）固定在畫面底部，因為開了 no flicker mode。講者覺得它好很多，應該直接設為預設
  ↳ composer 是畫面最下面、打字給 Claude 的輸入框。開了 no flicker mode（不閃爍模式）以後，輸入框會固定在底部不亂跑。講者覺得好用到應該直接設成預設。
• 22:59 no flicker mode 下可以快速捲動。以前也能快速捲動，但有時會閃爍，現在不會了
  ↳ Claude 輸出一大串內容時，可以快速上下捲動查看。以前也能捲，但畫面偶爾會一閃一閃，看得很累。新模式把閃爍的問題解決了。
• 22:59 no flicker mode 是在愚人節推出的，事後回頭看，有點被當成玩笑
  ↳ 這個功能剛好在 4 月 1 日愚人節推出。回頭看，很多人把它當成玩笑，沒有認真看待。
• 23:30 啟用方式是把 no flicker 的環境變數設為 1。CLI 的 renderer 整個重寫過
  ↳ environment variable（環境變數）是啟動程式前先設好的開關，把 no flicker 那個變數設成 1 就能開啟。背後是把 renderer（CLI 負責把畫面畫出來的部分）整個重寫過。
• 23:30 新的 renderer 使用 virtualized scrolling 與 virtualized selection，所以記憶體和 CPU 使用量都維持固定
  ↳ virtualized scrolling／selection 的意思是只處理你眼前看得到的那一段，不會把整串紀錄一次全塞進畫面。所以對話再長，記憶體和 CPU 用量都不會一路往上加。
• 23:30 打字時可以用滑鼠在 composer 裡點擊移動，滑鼠事件在終端機裡也能用
  ↳ 終端機通常只能用鍵盤移動游標。現在可以直接用滑鼠在輸入框裡點一下，把游標移到想改的地方，就跟在一般文書軟體裡打字一樣。
• 23:30 讓 Claude 監控 PR：它跑了一些指令後會睡 20 分鐘再醒來。講者覺得 20 分鐘可能有點太長。被問到是不是用 loop，回答「我想是」
  ↳ 他讓 Claude 顧著 PR：跑完檢查就先睡 20 分鐘，醒來再看，像定時巡邏。他覺得 20 分鐘有點久。被問是不是用了 loop（定時重複執行的功能），他說應該是。
• 24:04 其他 session 還在跑，其中一個還順手多修了一個 bug
  ↳ 其他 session 同時繼續工作。其中一個在做原本的任務時，還順手多修好一個 bug（程式錯誤）。
• 24:38 大約過了 20～25 分鐘，已經拿到 3 個 PR。等測試跑完，應該會有第 4 個
  ↳ 開始後大約 20 到 25 分鐘，手上已經有 3 份 PR。第 4 份在等測試（自動檢查程式有沒有改壞）跑完，應該也快出來了。
• 24:38 同一時間 Robo（字幕也寫作 Robbo）持續產生更多 PR：每次有人提 issue，它就會嘗試重現問題
  ↳ Robo 是他們團隊設的自動化機器人。只要有人開 issue（在專案上回報問題的單子），它就自動試著把問題重現出來，同時也不斷產出更多 PR。
• 25:08 Claude Code 帶來的思考方式：每出現一個新瓶頸就把它自動化，然後轉向下一個瓶頸
  ↳ Claude Code 讓人養成一個習慣：找出現在最卡的那一關，交給自動化，再去處理下一關。bottleneck（瓶頸）指的就是整個流程裡最拖慢進度的那一步。
• 25:08 瓶頸的演變：一開始是寫程式，接著是驗證和跑測試，現在兩者都不再是瓶頸，剩下的是更深一層的驗證
  ↳ 最早卡在寫程式，後來卡在驗證、跑測試，這兩關現在都能交給 Claude。剩下的是更深一層的驗證，例如這個改法是不是真的對。
• 25:40 講者預期再下一個瓶頸是規劃：該做什麼、不該做什麼，以及正確的修法是什麼
  ↳ 他預期再下一個卡關點是規劃：哪些該做、哪些不該做、怎麼修才對。換句話說，人的價值會越來越集中在「做決定」，而不是「動手做」。
• 25:40 理想狀態是 Claude 夠聰明、夠值得信任，可以自己 merge PR。某些專案可能已經能全自動，但 Bun 還沒到那一步
  ↳ merge 是把 PR 正式併進專案。理想狀態是 Claude 夠聰明、夠可靠，可以自己決定併入。有些專案也許已經能全自動，但 Bun（一個 JavaScript 執行環境）還沒到這一步。
• 26:13 Robbo 不會主動做 feature request。不過在 Discord 或 Slack 上 @ 它，它就會嘗試實作功能，大概一小時後就有 PR
  ↳ feature request 是「想要新功能」的請求。Robbo 不會自己去做，但有人在 Discord 或 Slack（團隊聊天工具）上 @ 它，它就會動手，大約一小時後就交出 PR。
• 26:45 有人在 Twitter 上請講者修 bug 時，講者基本上就是 @ 機器人，再回覆 PR 連結。有人開玩笑問要不要幫 Robbo 開 Twitter 帳號
  ↳ 有人在 Twitter 上請他修 bug，他基本上就是 @ 機器人去處理，再把做好的 PR 連結回給對方。現場還有人開玩笑說，乾脆幫 Robbo 開個 Twitter 帳號。
• 26:45 講者不太想讓它實作 GitHub issue 裡每個人提的所有要求。例如把 image processing library 放進 Bun 有點瘋狂
  ↳ 但他不想照單全收。GitHub 上大家的要求五花八門，例如想把 image processing library（處理圖片用的程式工具包）塞進 Bun，這對 Bun 來說太誇張了。
• 27:18 這類決定需要 engineering taste，目前還不確定 Claude 是否已經能判斷這是不是好主意，但未來可能會做到
  ↳ 要不要加某個功能，需要 engineering taste，也就是工程上的判斷眼光，看得出加進去會讓產品更好還是更亂。他不確定 Claude 現在有沒有這種眼光，但未來可能會有。
• 27:18 PR 變成了「建議」：不 merge 同事的 PR 會不好意思，因為對方花了心力；但 Claude 的 PR 不 merge 就不用有這種負擔
  ↳ 同事送來的 PR 不併會不好意思，因為對方花了心力。Claude 的 PR 就沒有這層人情壓力，比較像一份「建議」，看了不合適就放著。
• 28:21 因為不用顧慮別人白做工，某種程度上反而提高了決定要不要 merge 的門檻
  ↳ 正因為不用擔心別人白忙一場，他反而可以更挑，只併真正好的改動，要不要併的門檻就拉高了。
• 28:21 瓶頸移動後，團隊動態也跟著變：以前重點是信任隊友，現在更在於有沒有對的自動化，以及整個團隊是否信任自動化
  ↳ 瓶頸移動了，團隊的運作方式也跟著變。以前重點是信不信得過隊友，現在變成自動化有沒有設對，還有整個團隊願不願意信任這些自動化。
• 28:55 第 4 個 PR 還在進行，Claude 來回找 bug、修 bug，接著準備送出 PR
  ↳ 第 4 份 PR 還在做。Claude 自己找 bug、修 bug，來來回回幾輪，接著準備送出。
• 28:55 auto mode 讓 Claude 可以一次連跑好幾個小時。講者幾乎每晚都讓一堆 Claude 用 auto mode 跑。以前做不到，因為總會卡在權限請求
  ↳ 有了 auto mode，Claude 可以連續跑好幾個小時不中斷。他幾乎每天晚上都讓一堆 Claude 用 auto mode 跑。以前做不到，因為總會卡在某個權限請求上。
• 29:25 這整件事只下了一個 prompt，就跑了 30 分鐘
  ↳ 這一整串成果只靠一次 prompt（交代給 AI 的一段文字指令），Claude 就自己連續做了 30 分鐘。
• 29:57 第 4 個 PR 修的是一個開了很久的 issue，有 20 個 upvote，講者認為這看起來也是正確的修法
  ↳ 第 4 份 PR 修的是一個放了很久的問題，有 20 個人按 upvote（表示「我也遇到／我也想要」）。他看過後覺得這也是正確的修法。
• 30:30 結語：這是工程未來發展的願景，他們會比其他人先遇到、先摸索出答案。他們還沒全部想通，但會持續實驗、找出下一個瓶頸並解決它
  ↳ 他說這就是他們眼中工程工作的未來，他們會比別人先遇到問題、先摸索答案。現在還沒全部想通，但會持續實驗，找出下一個瓶頸再解決它。

根據影片，no flicker mode 是在什麼時候推出的？