研究範圍與證據邊界
本報告整理前 Meta React Compiler 工程師、現任職於 SpaceXAI 與 Cursor 團隊的 Lauren Tan(X 帳號 @poteto,GitHub 帳號 backnotprop)與主持人 Colin 長達 55 分 30 秒的技術對談(由 X 帳號 42 @NoDiscoInHere 於 2026-10-28 發布雙語字幕影片)。對談核心聚焦於工程師如何建立自動化驗證與程式碼庫硬約束,從單機手動監督推進至夜間自動合併(Auto-merge)與跨職能多 Agent 協作。
工作坊公開的四組技術元件分別對應執行期驗證、技能盲測、雲端分流與靜態架構約束:
| 系統元件 | 公開狀態 | 核心職責與解決的工程瓶頸 |
|---|---|---|
control-glass + Feature Map | 內部工具(方法已開源於 pstack) | 透過 Chrome DevTools Protocol(CDP)驅動 Cursor Agents Window(內部代號 Glass),搭配使用者視角導航地圖完成實機驗證 |
pstack + playbooks/eval.md | 公開 GitHub 外掛 | 將常見 Agent 失敗模式編碼為 Markdown 技能,以偽裝目錄盲測、異構模型評審與 /loop 迴圈優化至 10/10 |
Benny + Grok Bot | 內部雲端代理與桌面應用 | Benny 於雲端虛擬桌面自動重現 Slack 缺陷並比對 main;Grok Bot 提供類似 iMessage 的具名多角色協作介面 |
sand/dune + 硬性 CI | 內部 Electron 架構框架 | 以單一 Feature 目錄內聚、禁用 useEffect、禁用程式碼註解與執行緒依賴圖檢查,在 CI 階段攔截捷徑與效能退化 |
信任曲線與核心工具總覽
資深工程師在導入 Coding Agent 初期,常因目睹模型反覆誤判根因而退回微觀管理(Micromanagement):逐行盯視輸出串流、手動截圖貼回錯誤訊息、親自驗證每次本地建置。當人類成為每次迭代的唯一驗證器時,單人注意力上限僅能維持 1 至 3 個本地 Agent;在缺乏信任機制的狀態下盲目擴充至 15 或 100 個並行 Agent,只會加速產出低品質程式碼(AI slop)。
Lauren Tan 入職首月面對陌生程式碼庫時同樣處於低產出階段,隨後 4 個月內依序建立執行期驗證、技能盲測與架構硬約束,使交付規模沿信任曲線爬升至單月 1,000 個 PR 與夜間自動合併。她將工程師的新職責比喻為餐廳行政主廚(Head Chef):主廚負責設計廚房動線、驗收門檻與工位分工,將日常烹調交由副主廚、工位領班與產線廚師執行。
But like I woke up today and there were like 20 PRs landed and I just reviewed them on main, like they were already landed. And they were good. So how did I get to that point is basically what I wanted to talk about today.
排名 01/04
control-glass + Feature Map執行期實機驗證與功能地圖
以 CDP、模擬器與效能追蹤關閉本地驗證迴路
讓 Agent 像真實使用者一樣啟動並操作應用程式、擷取 CPU 火焰圖與記憶體快照,搭配一功能一檔案的 Feature Map 導航至目標畫面並確認零 Console 報錯。
- CDP
- Feature Map
- Runtime QA
排名 02/04
backnotprop/pstackpstack 技能庫與雙盲評測迴圈
將工程除錯紀律寫成 Markdown 技能並以盲測驗證
開源 Cursor 外掛(Potato Stack),收錄 create-verification-skill、maintain-verification-skill、how 與 poteto-mode 下的 playbooks/eval.md,透過偽裝工作目錄與跨模型評審防止評測作弊。
- Skills
- Blind Evals
- /loop
排名 03
Benny + Grok Bot雲端自動重現與具名角色編排
將本地驗證技能部署至隔離雲端桌面與跨職能介面
Benny 監聽 Slack #issues-glass 回報,啟動雲端桌面跑實機重現並比對舊 Commit 與 main;Grok Bot 以對話介面支援工程師、PM、設計師與業務管理專屬具名 Agent。
- Cloud VM
- Bug Triage
- Multi-Agent UI
排名 04
sand/duneDune 架構契約與機械式 CI 防線
專為 Agent 編寫設計的 Electron 應用框架與靜態檢查
以 5 條架構規則與 5 個公開名詞將 80% 功能封裝於單一目錄,並在 CI 層禁用 useEffect、禁用程式碼註解及強制隔離 electron-main 與 electron-renderer 依賴圖。
- Architecture
- Static Analysis
- Electron 60FPS
執行期驗證與 Feature Map 規格
建立 Agent 信任的第一步是執行期驗證(Verification):賦予 Agent 啟動並操作真實應用程式的能力,而非依賴靜態 Mock 單元測試。依應用型態不同,驗證介面包含驅動 Electron 或 Web 應用的 Chrome DevTools Protocol(CDP)、控制 iOS 模擬器的 Apple CLI 工具鏈,以及擷取執行期 CPU 追蹤(CPU Traces)與記憶體堆積快照(Heap Snapshots)的診斷指令。
Whatever, you know, however your application is exposed to your users, it can do the same thing and run it for real and actually test and verify its own work. Because that's the thing that really closes the loop. It doesn't guarantee your agent writes good code, but it allows them to at least write correct code, which is a big, a really big step forward for being able to trust your agents.
Lauren Tan 在入職第一週支援 Cursor Agents Window(內部代號 Glass,採 React 與 Electron 建置)上線前夕,開發了第一個驗證技能 control-glass。實測隨即暴露第二層瓶頸:Agent 雖能啟動開發版視窗並錄製效能軌跡,卻不具備產品操作路徑知識。面對內部 Slack 頻道常見的極簡回報(如「左側邊欄卡頓」、「右側 PR 分頁壞掉」,或僅附一張局部截圖加 ???),Agent 會在畫面隨機點擊並反覆檢索原始碼,無法抵達目標 UI 狀態。
為解決產品導航盲區,她在驗證技能中設計了 Feature Map(功能地圖),並將生成與維護流程開源至 pstack 的 create-verification-skill 與 maintain-verification-skill。演講畫面展示的 Glass 功能地圖遵循以下檔案與操作規範:
| 規格項目 | 畫面確認之具體做法 | 工程目的 |
|---|---|---|
| 使用者視角單檔結構 | 每個功能對應獨立檔案(sidebar.md、pull-requests.md、named-agents.md、queue-and-multitask.md、terminal.md)另加 cross-cutting-flows.md | 僅記載功能定義、抵達路徑、快捷鍵與 CDP 選取器;排除易過時的內部實作細節 |
| 基準環境前提(Preconditions) | 執行 control-glass info 與 control-glass doctor 檢查健康狀態;以 clone-userdata --force --overwrite 載入預先驗證的登入態 | 避開無法自動化的瀏覽器 OAuth 登入,並清除殘留 Modal、Toast 與非預設分組 |
| 語意化選取器與快捷鍵優先 | 優先選取 ARIA 標籤與 data-component、data-action-id、data-tool-* 屬性;優先發送已註冊鍵盤快捷鍵而非座標點擊 | 降低 CSS Class 變動造成的腳本脆性,同時覆蓋重度使用者的快捷鍵路徑 |
| 非確定性狀態輪詢與零報錯 | 對串流輸出採用可觀測結束狀態輪詢(Polling),禁止固定秒數等待;全程監控執行期 Console 輸出 | 確保非同步 UI 穩定收斂,並強制要求驗證期間維持 0 筆 Console 錯誤 |
技能工程與雙盲子 Agent 評測
Lauren Tan 將 Coding Agent 比喻為語法熟練但 5 秒前才剛入職、缺乏團隊脈絡的工程師;Markdown 技能檔(Skills)的作用是在上下文開頭注入高密度領域指令,引導下一個 Token 的預測進入高品質推理路徑。她的開源外掛 pstack(Potato Stack,命名呼應個人帳號 poteto 並致敬 Garry Tan 的 GStack)由早期逐一展開 Agent 工具呼叫(Tool Calls)與思考區塊(Thinking Blocks)、針對實測失敗模式逐項編寫而成。
典型案例為 pstack 中的 how 技能:針對 Agent 未開啟受影響原始碼便斷言找到「確鑿證據(Smoking Gun)」的慣性,how 強制要求先讀取實際檔案並派發旁路子 Agent(Side Agents)蒐集呼叫鏈證據,禁止無證據猜測根因。為確保技能隨產品演進與模型更迭持續有效,pstack 在 poteto-mode 下提供評測劇本 playbooks/eval.md,將技能視為可執行單元測試的程式碼。
主協調者制定量化評分規準(Rubric)
由主協調 Agent(Main Coordinator)依目標技能定義明確的行為檢核項、通過條件與扣分標準,作為後續自動化評分依據。
建立偽裝命名的雙盲子 Agent 工作目錄
主協調者平行啟動多個子 Agent,並將工作區命名為一般開發目錄名稱。實測顯示現代模型一旦從路徑或提示詞察覺自身處於 Eval 測試環境,行為模式便會異常改變;偽裝目錄可維持真實開發反應。
指派異構模型擔任交叉評審(Judge Agent)
選用與執行端不同模型家族的 Judge Agent 依規準交叉打分,消除同模型自我偏好(Self-bias),並於 Cursor 支援的多模型矩陣上驗證技能穩定度。
透過 /loop 自動迭代至 10/10 滿分
利用量化評測分數搭配 Cursor 的 /loop 指令,自動微調技能文字與控制 CLI、重跑盲測迴圈,持續爬山優化直到所有規準項目達到 10/10。
雲端重現佇列與多角色團隊編排
在多 Agent 擴展順序上,Lauren Tan 明確要求先於本地端建立驗證信任,再將工作負載全面移往雲端(Cloud Agents)。本地端便於直接觀察 Agent 呼叫 API、操作桌面視窗與執行 CLI 的細節;當 control-glass 與 Feature Map 在單機端穩定運作後,部署至雲端虛擬機即可轉化為全團隊共享的自動化基礎設施。
以下卡片依序對應貼文摘要與演講實例中的三個多 Agent 運作層級(1 幕僚長、3 經理工位、11 執行助手):
排名 01/03
Chief of Staff / Main Coordinator幕僚長與主協調層(1 名協調角色)
拆解高階意圖、制定評測規準與產出每日變更摘要
負責將工程師或 PM 的目標拆分為工位任務與 Eval Rubric,並彙整跨分支進度;例如產品經理每日早晨透過專屬協調 Agent 自動總結 Lauren 團隊夜間合入的所有 PR 變更。
- Coordinator
- Rubric
- Daily Digest
排名 02/03
Benny + Triage & Judge Stations問題重現、拆單與評審經理層(3 類把關工位)
涵蓋 Benny 雲端自動重現、原子 PR 拆分與異構模型把關
Benny 監聽 Slack #issues-glass 頻道,自動開啟雲端虛擬桌面執行 Cursor 與 Feature Map 重現問題並比對舊 Commit 與 main;開發與評審工位則負責拆分原子化小 PR 並執行跨模型 Judge 與 Bugbot 檢查。
- Benny
- Atomic PRs
- Cross-Model Judge
排名 03
Grok Bot Execution Fleet隔離執行助手群(11+ 具名專職助手)
於 Grok Bot 對話介面按單一功能目錄或客戶帳戶平行推進
Grok Bot 以類似 iMessage 的對話介面賦予每個 Agent 獨立名稱與身份;工程端按獨立 Feature 資料夾派工並經 CI 自動合併,業務(GTM)端則為每個企業客戶配置 1 名專屬 Account Agent。
- Grok Bot
- Feature Isolation
- GTM Accounts
演講畫面展示的 #issues-glass 真實對話中,同事回報一項 UI 異常後,Benny 自動在雲端電腦重跑並回覆「已在前一個 Commit 重現此問題,但在最新 main 分支上已消失」,使工程師免除手動排查時間,僅需發布新建置版本即可結案。
Like here in this example, you can see that, uh, the Benny actually reproduced the bug, uh, but it's already fixed on main. So it actually confirms that we fixed this problem already. And all I need to do is just release another build of, of cursor.
Dune 架構契約與五層品質防線
針對是否應重寫既有應用程式,Lauren Tan 區分了兩類程式碼庫的風險結構。大型科技公司的成熟存量專案(Brownfield,如她在 Meta 經歷的萬人 Monorepo)早已針對經驗最淺的貢獻者建立嚴格權限隔離與框架護欄,以防範人類粗製濫造(Human Slop),因此 Agent 進入此類專案較難造成系統性破壞。相反地,以 Vibe Coding 直接生成的全新原型(Greenfield,包含最初版本的 Grok Bot)缺乏人工審查與架構邊界,Agent 每次皆沿最短編譯路徑堆疊捷徑,形成難以維護的「有機架構(Organic Architecture)」。
為根除此問題,她投入超過 600 個 PR 將 Grok Bot 遷移至自建的 Dune 架構(儲存庫代號 Sand,框架層位於 sand/dune,應用層位於 sand/src)。她將 Dune 定義為「專為 Coding Agent 編寫而設計的 Electron 版 Next.js」:假設每位貢獻者僅具備極窄的 Prompt 與鄰近數個檔案、缺乏全局心智模型,架構必須讓「局部最顯而易見的改法」直接等同於「全局最正確的改法」。
演講畫面的 Dune: Agent-friendly architecture 文件明列五種 Agent 慣性、五條核心規則與五個公開名詞:
| 架構維度 | 畫面文件確認之規範條目 | 工程約束效果 |
|---|---|---|
5 種可預測的 Agent 慣性 | 1. 複製最近的可運作模式;2. 直接修改已開啟的檔案;3. 選擇能通過編譯的最短路徑;4. 避免刪除看不見呼叫者的程式碼;5. 即使違反系統不變量(Invariants)仍照單執行使用者提示詞 | 將 Agent 的偷懶與局部最佳化視為固定輸入參數,不依賴提示詞祈求模型自律 |
Dune 的 5 條設計規則 | 1. 正規路徑所需的決策數少於走捷徑;2. 禁止的依賴直接以機械方式報錯失敗;3. 每個持久化值只有唯一明確的寫入者;4. 新產品功能只新增隔離檔案,不在共用根檔案加分支;5. 例外必須極窄、顯式,並視同架構變更審查 | 消除 15 個以上並行 Agent 在共用註冊表的合併衝突,讓違規捷徑於編譯與 CI 階段直接失敗 |
5 個公開架構名詞 | Feature(單一專屬目錄封裝約 80% 功能程式碼,免全局 grep)、Entrypoints、Transcript cards(由保留檔名自動發現,免中央清單註冊)、Client(具名 Hooks 與 Commands 確保本地狀態單一寫入者)、Host(單一強型別契約,sand/dune 絕不反向引用 sand/src) | 順應 Agent 複製鄰近檔案的強項,使中小型模型與非工程背景貢獻者皆能依樣寫出合規模組 |
在靜態分析與工作流層面,Grok Bot 與 Dune 實施了四項機械式 CI 與提交規範;對人類手寫而言繁瑣的檢查,由 Agent 在提交前自動修正並吸收檢查成本:
| 硬性檢查與提交規範 | 實施方式 | 解決的具體失效模式 |
|---|---|---|
全面禁用 React useEffect | 於 Lint 與 CI 層直接阻斷 useEffect 呼叫 | 消除 React 最常見的連鎖重繪、狀態失步與效能退化來源 |
| 全面禁用程式碼註解 | CI 偵測到新增程式碼註解即判定失敗 | 講者觀察到 99% 的 Agent 註解僅在記錄無關的對話歷史(如 PR 被糾正後寫下 // Lauren said you should never do this),禁令可防止歷史雜訊污染後續上下文 |
electron-main 與 electron-renderer 依賴圖隔離 | 對目錄依賴圖執行 CI 靜態檢查,搭配 pretext 處理高效能列表虛擬化 | 守護 60 FPS 下每幀 16ms 的渲染預算,防止高運算或 I/O 模組被誤引入渲染執行緒造成畫面卡頓 |
| 原子化多 PR 拆分(Atomic PRs) | 不設死板行數上限(單筆介於 50 行至整批刪檔的 1,000 行),避免 40,000 行巨型 PR | 保持 Git 歷史成為高訊號上下文,並確保單一變更出錯時可立即獨立回退(Revert) |
So Dune is just, you know, the, the mental model of what Dune is, uh, you can kind of think of it as like Next.js for, uh, Electron apps and it's designed for agents to write. Uh, and it's like custom for, you know, our agent powered applications. Um, so the CI checks are very like specific to that. Like, you know, don't use useEffect. It's, it's, it's banned. Like CI will fail, uh, and yell at you. We have like some of the more interesting ones that people might raise eyebrows is like, I actually ban code comments as well.
Lauren Tan 將程式碼庫的品質防線由強至弱劃分為 5 個層級(同時指出具備嚴格型別與 Borrow Checker 的 Rust 在禁用 unsafe 後,能由編譯器直接提供極強的第 2 層保證):
第 1 層(硬約束):Codebase 目錄拓撲
以 Dune 單一 Feature 目錄與保留檔名自動發現,讓最短路徑成為唯一正規路徑
- 單一目錄封裝 80% 變更
- sand/dune 與 sand/src 單向依賴
第 2 層(硬約束):Static Analysis(Lint / Compiler / CI)
違規直接讓 CI 變紅阻斷合併,不依賴模型記憶力
- 禁用 useEffect 與程式碼註解
- electron-main / renderer 16ms 依賴圖檢查
第 3 層(軟引導):Rules 與 Bugbot
AGENTS.md 規範與 CI 上的 AI 自動審查,模型仍可能偶發遺漏
- AGENTS.md 規則檔
- Bugbot 自動 PR 審查
第 4 層(軟引導):Skills 作業技能
如 pstack 將推理拉入高密度潛空間,需搭配盲測 Eval 維護
- control-glass / Feature Map
- how 證據查核與 playbooks/eval.md
第 5 層(軟引導):Style Guide 與人工 PR 留評
最脆弱的防線;每一次人工 PR 糾正都應視為反模式訊號並升級為第 1 至 2 層硬檢查
- 純文字風格指南
- 重複性人工 Code Review 評論
整理自演講 44:42 至 47:25 畫面清單與口述說明:僅依賴第 3 至 5 層軟性約束無法阻止程式碼庫長期腐化。
And if you, if you only have rules and Bugbot and skills and a style guide for your code, you will, it's only a matter of time before your code base looks like complete trash. Um, sorry to say that, but, uh, I definitely recommend, yeah, like, you know, investing in, you know, things that can be hard enforced, right?
Token 投資報酬率與分階段導入程序
針對外部團隊質疑「AI 實驗室擁有充裕 Token,一般新創與個人開發者是否負擔得起 600 個重構 PR 的前期成本」,Lauren Tan 以工程投資報酬率(ROI)與成本與智力帕累托前沿(Pareto Frontier)拆解:
前期重構替代多年人力與組織內耗:單一工程師若不靠 Agent 手動搭建
Dune、遷移600個 PR 並逐項實測,需耗時數年或增聘多名資深工程師,並承擔大型組織的溝通成本。硬護欄降低日常推論模型門檻:當第
1至2層硬約束就位後,日常功能開發無須處處仰賴最昂貴的旗艦模型;推論成本較低的中小型模型,或演講當日發布、以4.5單價提供更高智力的Grok 4.6,皆能在明確護欄內穩定產出合規程式碼。跨職能直接交付程式碼:嚴格的架構與 CI 讓非工程專職的產品經理(PM)與設計師也能直接提交修復 PR,工程師檢視後即可核准放行(Stamp)。
So I think our PMs are leveraging that a lot. And they're shipping code, too. So, you know, like, oftentimes they will just say, oh, here's a bug. I fixed it. Can you look at it? And then I'll go review it. And actually, it's just perfect. I'm like, okay, stamp. So I think that shows that, you know, the Dune architecture is holding up, right?
以下五階段導入程序與交接契約為供一般工程團隊採用的實作方案,避免在缺乏驗證前過早開啟多 Agent 並行而浪費 Token:
| 導入階段 | 執行範圍 | 驗收與升級條件 |
|---|---|---|
第 1 階段:實機驗證迴路 | 參考 pstack 建立本地 CDP、瀏覽器或模擬器控制腳本,撰寫首批使用者視角 Feature Map | Agent 能載入預先驗證登入態、導航至目標功能並以 0 筆 Console 錯誤完成操作驗證 |
第 2 階段:失敗模式技能化 | 維持 1 至 2 個本地 Agent,展開 Tool Calls 與思考區塊,將未讀檔瞎猜等行為寫成 3 至 5 個核心技能 | Agent 在提交修復前皆附上實際檔案讀取紀錄與根因證據鏈 |
第 3 階段:雙盲評測與爬山 | 為關鍵技能撰寫 Rubric,於偽裝名稱目錄跑子 Agent 盲測,指派異構模型擔任 Judge 並以 /loop 迭代 | 核心技能於跨模型矩陣穩定取得 10/10,且子 Agent 未觸發評測偵測異常 |
第 4 階段:PR 評論轉硬性 CI | 將重複出現的人工 Code Review 意見改寫為自訂 Lint、AST 規則或目錄依賴圖檢查,推進單一 Feature 目錄內聚 | 違規依賴與禁用 API 直接使 CI 變紅,人工審查不再重複糾正相同風格與邊界問題 |
第 5 階段:雲端重現與角色編排 | 先部署 1 個類似 Benny 的雲端缺陷重現代理,再按標準交接契約擴展至主協調者與平行執行助手 | 雲端重現能自動區分舊版缺陷與 main 現況,每個自動合併 PR 皆維持原子化且可獨立回退 |
團隊將任務由主協調層派發至平行執行助手時,可使用以下可審查的英文任務契約模板(此為依公開方法設計的採用模板,非講者內部原始提示詞):
Role: isolated feature execution worker.
Workspace: dedicated branch/worktree; modify only the assigned feature directory unless architecture review is explicitly requested.
Before proposing a root cause or edit:
1. Read every affected file and trace callers; never guess a smoking gun without file evidence.
2. Boot the real dev build via the verification skill, load pre-authenticated user state, and navigate using the Feature Map (ARIA / data-* selectors and registered keyboard chords).
3. Reproduce the baseline behavior or bug and capture runtime logs / traces.
Implementation & gate requirements:
- Follow Layer 1-2 mechanical constraints (no banned hooks, no conversational history comments, no forbidden cross-process imports).
- Keep the PR atomic so it can be reverted independently on main.
- Poll observable end-states during verification and assert 0 console errors before marking ready.
Return: changed files, reproduction comparison (prior commit vs HEAD), verification output, and rollback command.導入時需控管三項操作邊界:
未建立本地驗證與硬性 CI 前禁止啟動大規模雲端
/loop,避免無效消耗推論預算。夜間自動合併至
main僅限具備實機 UI 驗證、依賴圖靜態檢查、Bugbot審查與即時回退路徑的原子 PR。若專案涉及密碼學、底層硬體協定或法規演算法,實施全庫禁註解規則時須同步將系統不變量寫入受審核的架構契約文件。
原始逐字稿(一):信任曲線與交付規模
以下收錄 00:00 至 05:24(共 12 段)經 whisper-cli 與時間軸字幕交叉校正之完整英文對話,涵蓋講者背景、單月 1,000 個 PR 與夜間自動合併 20 個 PR 的信任曲線起點。
[00:00-00:38] Lauren Tan: So the first thing I want to talk about is pretty serious, okay? I need all of you to take this seriously. Put your phones down. Put your laptop down. Put your water bottles down. We're done hydrating. Are you all ready? Very excited to announce. You can't npm install yet. We'll release that later today. So don't take your laptops out. But yes, very exciting milestone. And after I do the release, you can get started.
[00:38-00:44] Lauren Tan: Your applications by installing Babel plugin, React, as well as the new ESLint plugin. Okay, so I assume you can see my screen.
[00:45-00:46] Colin: Yes, yeah, we're good.
[00:47-01:24] Lauren Tan: So yeah, today, yeah, I think the big theme for me as I've been using agents to write code, and I'm sure a lot of you have had the same experience as well, is how do you trust it? You know, especially if you are an engineer that's been writing code for a very long time, you have a lot of opinions and lessons that you've learned about doing good engineering. And when you see agents just, you know, winging it and, you know, guessing, hallucinating, you know, confidently stating that they found the smoking gun for the hundredth time, but it's actually not the real problem, you lose a lot of trust.
[01:24-02:00] Lauren Tan: And when you lose, when you don't have much trust in your agents, I feel like you really can't get the most out of them. And for me, the parallel is like with management. So if I'm an engineer manager of a team, and I have a bunch of, you know, I have a team of engineers on my team, and I don't trust them, then the mode of operation I'm going to be in is going to be like micromanagement, right? I'll have to spend a lot of time looking over my reports' shoulders and checking that they're doing their work well, you know, that they're not shipping bugs to production.
[02:00-02:26] Lauren Tan: And so I drew this chart because it's not a very scientific chart, but like this is how I imagine myself and my journey through using agents. So, you know, like fast forward or back forward or fast back, fast backwards, like a year or so, when, you know, nobody was or not many people were using agents to code.
[02:26-02:57] Lauren Tan: So I think you, you know, get into this mode where you are in very heavily in the loop with one or several, like a handful of agents. And you find yourself just constantly, you know, trying to understand what your agents are doing. And you're very, very in the loop. You're watching every single output. You are sitting there prompting. And you really can't parallelize beyond that because you don't, again, you don't have that trust, right?
[02:57-03:29] Lauren Tan: You can't go to a hundred agents, like spawn a hundred agents when you don't even trust the output of one agent. So over the past five months, I feel like I've really been able to like ascend this trust curve. And now I'm at the point where I actually have, this sounds kind of scary to say this, and it makes me sound like a slop artist, but I promise I'm not. But I actually have my agents now auto-merging PRs for me, which is like a wild thing to say.
[03:29-04:05] Lauren Tan: But like I woke up today and there were like 20 PRs landed and I just reviewed them on main, like they were already landed. And they were good. So how did I get to that point is basically what I wanted to talk about today. And again, like, yeah, feel free to jump in if you have questions, Colin. But, oh yeah, of course I got to show this, this chart where, do not trust, someone requested to control my computer. Probably won't do that.
[04:05-04:32] Lauren Tan: But yeah, so this chart, I think, I'm sharing this chart not to kind of like flex, but to kind of show like the journey. Like, so you can see like the curve, like it's sort of like inversely matches the contributions I've been able to land at Cursor. So I joined five months ago and five months ago, like I, you know, my first month I was like not very productive because I was, you know, I was learning the code base. Didn't know what the heck was going on.
[04:32-05:07] Lauren Tan: And as I got more confident in my agents, I've really been able to kind of ramp up my productivity. And again, like, yeah, like last month I shipped a thousand PRs, which is ridiculous. And then this month, we're only on the 12th. I'm already at like almost 800 PRs landed. So the velocity is definitely high. And I'm sure a lot of you will definitely be questioning like how much of this code is actually good. And I think, yeah, that's definitely fair to question.
[05:09-05:21] Lauren Tan: But yeah, I think if you set up your agents well, you can definitely get to a very similar level. And so I'm going to talk about how we do that.原始逐字稿(二):執行期驗證與 Feature Map
以下收錄 05:24 至 13:07(共 15 段)完整英文對話,涵蓋執行期實機驗證、control-glass、Glass(Cursor Agents Window)與使用者視角 Feature Map 設計。
[05:24-05:54] Lauren Tan: So for me, I think I'm curious, like, I guess, Colin, your experience as well. But for me, I think the most important skill that you should have in your toolbox when you work with agents is verification. And by verification, I mean the ability for an agent to actually run the code or take CPU traces or heap snapshots or, you know, open an iOS simulator.
[05:54-06:21] Lauren Tan: Whatever, you know, however your application is exposed to your users, it can do the same thing and run it for real and actually test and verify its own work. Because that's the thing that really closes the loop. It doesn't guarantee your agent writes good code, but it allows them to at least write correct code, which is a big, a really big step forward for being able to trust your agents.
[06:42-07:20] Lauren Tan: Let me just make this way. Make me full screen. There you go. So for the for Cursors Agent Window. So this is actually an interesting story. But when I joined Cursor five months ago, they're actually, well, I was supposed to join a different team. I was supposed to join like the Cloud Agents team. But then since I have a lot of experience working on React and Agents Window is a React application, I was asked to basically help out with the Agent Window work.
[07:20-07:47] Lauren Tan: But there wasn't really a lot of like skills to help me. So I just found myself that, okay, Agents Window is going to launch in like a week. All right, we have a really tight deadline. And there was, you know, I was just sitting there like, okay, I'm going to open up the performance, the Chrome Dev tools and just like take a trace, look at it myself and try to make sense of this flame graph. And keep in mind, I was just like in my first week.
[07:47-08:10] Lauren Tan: So I had no idea what I was looking at. No idea what, you know, I mean, I had some idea, but, you know, the code base was completely fresh to me. And I realized like my agent had no idea either, you know, like I would take a screenshot of the trace, I would download trace, I would send it to it and it'd be like, yeah, it kind of looks like this, you know, and it would like confidently state like it's this thing. And then I'd try to fix that.
[08:10-08:35] Lauren Tan: And turns out that's not the actual thing. So this was a very, very slow process. And if you've ever done any like performance work yourself or, you know, just even development with an agent where you don't have a verification skill, you are the verifier. All right, you're the bottleneck. You tell your agent to do something and then it goes off and write some code. Then you open up your, you know, local dev build and then you start to say, oh, you know, it doesn't work.
[08:35-09:05] Lauren Tan: Then you have to copy paste screen, you know, screenshots or console errors or whatever. And then your agent like slowly kind of like, you know, works with that and then tries to understand it and fix the thing. But then you're constantly just in the loop and being a bottleneck. So there's really no way to parallelize. So the control glass skills are like one of the first skills I built for cursor and glass, by the way, is the code name for agents window that we use internally.
[09:05-09:42] Lauren Tan: But it's just cursor, I guess. And so this skill is, I guess, the code itself is not super interesting. Your agent can very easily make one for you, where if you're building an electron app or a web app or even iOS applications, you can teach your agent how to use like the Chrome DevTools protocol or through Apple has some utilities as well for running the simulator and taking traces and controlling programmatic control as well. So that's really useful.
[09:42-10:15] Lauren Tan: But one thing I actually want to talk about is the this thing. Where is the read me? So this skill comes with this very unique feature called or not feature, unique file called a feature map. And so the story then is like I built this skill. And so now the agent was able to actually run the agent window and take traces and whatnot. But it had no idea what what the agent's window was.
[10:15-10:45] Lauren Tan: So, you know, like someone would say, like, oh, the left sidebar is like laggy or something like that. Or, you know, the right side, the PR tab is not working. And the agent would just be like kind of flailing around. It would spend a lot of time trying to like look up the code and, you know, where is this feature? How do I actually get to it on the UI? Which made it basically completely useless. You know, like we would I would run the skill locally and, you know, it would spawn a dev build.
[10:45-11:17] Lauren Tan: But then it just be churning. Like I just try to click here. It wouldn't know how to get to things. And it was just an awful experience. So who is putting arrows on my screen? So, yeah, this this feature map has been really useful because it teaches the agent how to get to all of the features that you have. And in pstack, the plugin that I've made, if you search for pstack cursor on Google, you'll find it.
[11:17-11:46] Lauren Tan: But there is a create verification skill in that plugin where it actually helps you set up something like this for yourself, including the feature map. So it will actually explore the code and build up this initial feature map that tells your agent how to get to all of the different features that you have. And this is extremely powerful because now that you have these user reports that come in, you can actually map even like a vague report or even a screenshot.
[11:46-12:13] Lauren Tan: So we have this internally at Cursor where we have a Slack channel where, you know, lots of people giving us feedback on the agents window and Grok Bot and whatnot. And oftentimes the report is very bad, like very low quality. Like someone will just put very often we get like a screenshot and then someone just says question mark, question mark, question mark. Like, what is this? And, you know, like without this, your agent is like, I have no clue.
[12:13-12:51] Lauren Tan: Right. But with a feature map like this, it has a lot more context and understanding of how to actually navigate, how to get to all of the different features. So like, you know, example, like I guess like the sidebar, like what is the sidebar? You know, like all the different sub features that are present in it, like from the user point of view, which is how to get to it. All the different keyboard shortcuts, even like the what do you call it, the DOM elements or like the attributes that you use for selecting things through the CDP are all there.
[12:51-13:07] Lauren Tan: So again, yeah, this is like really, really powerful for agents. And pstack ships that create verification skill, but also a maintain verification skill. So you can keep this up to date.原始逐字稿(三):pstack 技能庫、盲測與主廚模型
以下收錄 13:07 至 23:11(共 23 段)完整英文對話,涵蓋 pstack、how 技能、playbooks/eval.md 偽裝目錄雙盲評測、異構模型 Judge、/loop 爬山迴圈與餐廳主廚(Head Chef)分工模型。
[13:07-13:16] Colin: Cool. Yeah, I was just going to ask how you created that. So do you mind sharing a little bit more about that process in the context of pstack and maybe just what pstack is for the folks who aren't familiar?
[13:16-13:47] Lauren Tan: Yeah, so pstack is pretty interesting because, well, first of all, the name is kind of goofy, like the P, the P and pstack is like potato, potato stack, because I so there is a pretty famous person, Garry Tan, who is the CEO of Y Combinator. And he's come up with this plugin called GStack, GarryStack. And funnily enough, we share the last name. We have no relations.
[13:47-14:23] Lauren Tan: But I thought it would be funny to kind of, you know, poke fun at Garry and make pstack my version of his plugin, but kind of just tailor it to my own set of engineering practices. But I honestly actually never set out to build pstack. It just started with a bunch of skills, right? Like I started with that control glass skill. And then I started with another skill like called how, which I also noticed through like observing agents. So like, you know, in the early days of me, you know, trying to climb this ladder, I was like super in the loop.
[14:23-14:51] Lauren Tan: And I was basically nitpicking my agents to an extreme degree. I was like, I would tell it, you know, this feature has stopped working. Here's a bug report. Like, why isn't it working? And very often the agent would just like confidently state like, oh, it has to be this, right? It has to be this thing. And I noticed like when I looked at the actual tool calls, I noticed it wasn't actually reading the code that I thought should be affected.
[14:51-15:20] Lauren Tan: And that made me just extremely suspicious. And at that point else is that I'm not gonna, I can't trust any, this agent anymore. Because it's just, it's just completely hallucinating. And I think, I think it's very easy to just, you know, like build up that distrust and not, and kind of feel helpless. Like, you know, you don't know how to help your agents succeed. But like, again, I think the management analogy is super helpful because like, imagine if you were a manager of an engineering team.
[15:20-15:58] Lauren Tan: And you had an engineer on your team who was a really good coder, no business context whatsoever. You know, they just, you just hired them and they onboarded, you know, like five seconds ago. And so how do you actually teach that person to be effective? So how you do that is through a skill. A skill being just, you know, it's just markdown, right? But, you know, it encodes a lot of information, instructions, a lot of, you can really draw out a lot of intelligence from an agent by, well, some people on Twitter call it like, you know, pull the agent to a different latent space.
[15:58-16:31] Lauren Tan: Which is kind of like a fancy way of just saying, like, since, you know, LLMs are sort of like, they predict the next token. When you give it some high quality tokens to begin with, then, you know, it can kind of pattern match on like a higher space that's, you know, smarter. So that's like a very interesting model there. But yeah, I built pstack very, very incrementally. So started with just really observing how agents, you know, all the different failure modes of that agents were having.
[16:31-16:47] Lauren Tan: And every time I saw that I just, okay, I'm just going to make that a skill, right? Like stop hallucinating, actually go and search up, look up the code, use a lot of side agents and yeah, stop guessing. Yeah, that makes sense.
[16:47-17:12] Colin: One, one kind of follow up question here, both for myself and from a bunch of people in the chat. So I guess it's two, two parts. So one is like, how do you maintain these skills? So like the product changes over time, obviously there's a lot of people who are shipping against the code base. So how do these skills get maintained? And then second to that is like, how do you know when your verification is, is good enough? Like, and you know, you can trust that the verification loops that you've built are going to, I guess you trust that that opens up.
[17:12-17:17] Colin: I guess you trust that the outputs when they're done.
[17:17-17:52] Lauren Tan: Yeah, maybe I'll talk about, I think I was somewhat related. Maybe I'll start with this one first. So like, how do I maintain these skills? So if you're not familiar with this concept, an eval is essentially like a way to, well, I think the mental model I have is like, it's like a unit test for an agent. And you can actually make your own evals. You don't need like a special framework for them. You can build, you can, you can build one depending on like, you know, how scientific and how rigorous you want to be.
[17:52-18:01] Lauren Tan: My screen is red. Yeah, there's a little button. Sorry. Oh, if you mind like disabling the drawing or something, I can't see my screen.
[18:01-18:04] Colin: Yeah, sorry. If you guys could not draw on the screen, that'd be great.
[18:04-18:38] Lauren Tan: But there's a little button in the... Yeah, is that a troll? Yeah, the little dropdown. How did I clear? Yeah. Okay. Yeah. You got it. Perfect. Continue. Yeah, so evals are a way to unit test your skills basically. And actually in pstack, we ship under poteto-mode, there's a playbook if you search for it called eval playbook. And it's like not... It's actually pretty rigorous the way it's done.
[18:38-19:09] Lauren Tan: But essentially what I do is I spawn a lot of different sub-agents. I have like my main coordinator agent come up with a rubric for what I want the skill to do. And then it spawns all these sub-agents and it creates individual directories for them, which are cleverly named to not let the sub-agent know that it's being evaluated. Because agents can actually tell and when they do, they change their behavior.
[19:09-19:42] Lauren Tan: But it does a bunch of stuff like that to essentially test whether or not the skill I'm making or changing is actually doing what I think it does. And one of the really nice things about Cursor is that we support so many different models. So you can actually eval your skill across all sorts of different models and get a sense of how well it performs across that different matrix, especially for the models that you use.
[19:42-20:16] Lauren Tan: So I do this a lot. Every time I modify a skill, I will run one of these, like the eval playbook, and make sure that it's actually leading to a result I want. But I will say like, maintaining skills is actually pretty hard. It requires, I think, a lot of taste and observation. So you kind of need to be very good at being a backseat driver. You know what I mean? Like if you've ever done pair programming, for example, and you watch a coworker code and you just like, you could probably do this better.
[20:16-20:50] Lauren Tan: Or you know, you could do, you know, like, why did you not do this? Right. You ask a lot of questions to your coworker. And it's kind of a similar thing here. Like, you don't want to just be a passive observer of the agent. You want to be very in the driver's seat in the initial stages when you're building up your own set of skills. You know, obviously you can use something like pstack, but if you're building your own set of skills, it's very, I think, you know, opening up all the tool calls and reading the code and reading all the agent behavior and their thinking blocks is a really great way to see where they fail.
[20:50-21:20] Lauren Tan: Right. Like what, what, you know, where are they being done? And then you can go and build a skill for that. And then with verification, how you trust it is, it's, I think it's also a very similar iteration loop where, you know, like I actually did the same process for verifying the verification skill where I actually get. So one thing that's interesting about evals is that you can sort of hill climb them, meaning that your eval can produce a score, right?
[21:20-21:51] Lauren Tan: A score that you can get your coordinator to produce, but also you can have a judge agent of a different model to kind of cross reference and make sure that the first model is not being biased. Right. The model that's judging all of the sub agents that are running the thing. But you can also like hill climb. So meaning that you can, you can use like slash loop in cursor and you can say, okay, keep looping on this eval, right? Until everything is 10 out of 10, as an example.
[21:51-22:24] Lauren Tan: And I did the same, the basically the same approach with the control skill. And so I kind of, it was very, it was very hands off actually. So, you know, I, I kind of built, I built that skill that way, like the CLI and that skill. And over time, it's gotten really good. But yeah, it was definitely not super smooth at the beginning. It required a lot of iteration. And I think there's an analogy here for me, which is, well, I make this analogy later in a different slide on my drawing here.
[22:24-22:59] Lauren Tan: But I think of it like, you know, as a, as a engineer now, you're sort of more like, like maybe manager or the analogy I like is like, you're like a chef in a restaurant. You know, you're the head chef. You're not cooking all the food yourself anymore. You have a team of cooks, right? You have line cooks, you have a sous chef, you have, you know, all these different stations. And it's your job to really design the environment. You know, you, you're in charge of setting up the kitchen. You're in charge of, you know, like giving tasks to different people.
[22:59-23:11] Lauren Tan: So, yeah, it's a very interesting way of working. But yeah, that's, that's how I basically built these verification skills.原始逐字稿(四):雲端擴展與 Benny 自動重現
以下收錄 23:11 至 29:24(共 14 段)完整英文對話,涵蓋本地至雲端擴展順序,以及雲端代理 Benny 於獨立虛擬桌面自動重現 Bug 並比對 main 分支的實例。
[23:11-23:46] Colin: Yeah, just, just one fault there on like, to go try to go one layer deeper. So are you, let's say we wanted to build an eval or a skill for something. And we wanted to kind of get better on its own, which is what I think you're suggesting. Are you doing that in like a work tree, kind of isolated with like the sub agents and then the reviewer agents and all that? Is it happening like in some type of cloud hosted environment? Like what's the more, the practical steps? If I wanted to go do this and like set up a verification system for something, what would I, what would I do or where would I start?
[23:46-24:22] Lauren Tan: Um, I think that the best place to start is local, because you can observe, you can definitely observe what your agents are doing. So, if you're building a verification skill for yourself, I would definitely start local and just have your agent bring up the application, whether it's like a CLI or a desktop app or whatever. And so you can actually observe, right? You can see how the agent is interacting with the application. You can see it, you know, how it calls like the different APIs that allow it to interact with the application.
[24:22-24:59] Lauren Tan: Um, but, uh, for me personally, uh, I have basically been kind of all in, mostly all in on cloud agents because they're extremely powerful. Uh, and the really powerful thing about cursor is the, the cloud agents actually, where if you spend a little bit of time setting up your environment, these control skills, these verification skills pay a huge amount of dividends. Because it's not just something that makes you as a single engineer better. It actually levels up your whole team. Uh, and even your whole company, because, uh, you can actually start thinking about cloud agents.
[24:59-25:36] Lauren Tan: You can start thinking about automations that automatically do things like, uh, I'll, I get to, I kind of talk about this a bit later, but I'll just kind of get into it. Uh, where, where, you know, for example, like I talk a lot about this agent we have called Benny, right? Who, who, uh, you know, takes all of the bug reports that we get and it automatically goes off in the cloud, opens up a cloud, uh, it's, you know, it's desktop. It runs cursor in its own computer and it uses the same control skills to interact with the application and try to reproduce the bug, uh, or the user report.
[25:36-26:08] Lauren Tan: Right. And this is so, so powerful because at once I can immediately, I get so much information from this automatically. Like here in this example, you can see that, uh, the Benny actually reproduced the bug, uh, but it's already fixed on main. So it actually confirms that we fixed this problem already. And all I need to do is just release another build of, of cursor. Uh, so that's like huge information there that I didn't have to go off and sit with an agent, you know, and spend an hour trying to fit like, is this fixed? Is this not fixed?
[26:08-26:30] Lauren Tan: Uh, so you, you, you, you gain back so much time. Uh, but you know, everybody on my team benefits from this. Everybody in the company benefits from this. Uh, so definitely think that, uh, you know, keeping these, uh, using cloud agents is super powerful. Uh, but yeah, it's like a journey. You have to trust it first, right? Before you, you get to this point.
[26:30-26:53] Lauren Tan: And that's, it goes back to what I was saying here where, you know, it's very hard. It's almost impossible. And I would definitely encourage you not to try to jump from, you know, like if you're still in this zone, you don't want to jump to like, I'm going to spawn a hundred or thousands of cloud agents right now, because you're just going to waste a lot of tokens. Um, and it's going to be extremely expensive.
[26:53-27:23] Colin: Yeah. So just to kind of recap so far, basically the, if we wanted to go on the journey that you've kind of gone on, it would be to start with verification, um, building some, some skills and some, some ways of determining that the agents are producing at least like correct code, whether, like you said, whether it's good code or not, it's maybe a separate question, but like it's, it's technically solving the problem by looking at, you know, stack traces, looking at, you know, the actual behavior in the app and so on. Um, and then once we trust it locally, then we can start to think about scaling into the cloud and running.
[27:23-27:43] Colin: Maybe more agents that are picking up signals, I guess, on their own. Right. So whether that's like a bug report that comes in or something, they can go and pick it up and solve the problem and give us back a PR. And then maybe the last step is like auto-merging the PRs, which, uh, is where you're at. And then reviewing them on main, but, um, is that, is that about right?
[27:43-28:11] Lauren Tan: Yeah, exactly. I think, yeah, that's why I drew this, this, uh, this, this curve, right? Because that this, this basically describes my journey of, you know, when I started barely could, use a couple of agents and I was just observing every single thing, I think there's really no shortcut for going from here to there, because this is really about your personal level of trust in agents. Right. Um, obviously, you know, as a, as an engineer, you don't want to just slop code into production. So how do you actually build up that trust?
[28:11-28:32] Lauren Tan: It takes, um, a lot of, uh, I guess, taste and judgment. Um, but, uh, you know, like I think plugins like pstack definitely can help you, uh, get up to speed much quicker. Uh, and so I guess it's like, if you trust me and you trust pstack, then in, by extension, you can maybe trust your agents.
[28:32-28:58] Lauren Tan: But if you don't trust me and I definitely would not encourage people to blindly trust me, uh, uh, you know, if you build up your own set of skills that you can obviously, you know, take a look at pstack and kind of fork it, make it your own, improve the skills, definitely encourage that. Uh, but for me, it's really all about, it just keeps coming back to trust. You know, every one of us here in this chat have a different standard for engineering.
[28:58-29:21] Lauren Tan: Uh, and there are different things that are important for us in our code base. And, uh, when you are able to encode all of that into skills and you can verify that your agent is actually doing them, that allows you to really kind of ascend this curve and, um, uh, you know, start automating things. Uh, there's another piece I wanted to talk about. Um, if there's.
[29:22-29:24] Colin: Yeah, go for it. I'll pick up more questions as we go, but yeah.原始逐字稿(五):存量護欄、Grok Bot 重構與原子 PR
以下收錄 29:24 至 38:00(共 21 段)完整英文對話,涵蓋大廠存量專案(Brownfield)與全新 Vibe-Coded 專案的風險差異、投入超過 600 個 PR 重構 Grok Bot,以及原子化小 PR 拆分策略。
[29:24-29:51] Lauren Tan: I think there's a third part to this, which I haven't talked about yet, which is kind of an interesting one, which is like refactoring and rewriting. Like one of the, uh, I guess most controversial, one of the most controversial topics in the industry, I think is like, should you rewrite your app or not? Um, because I think engineers are very prone to this where, especially when you join a company, you come in and you see like the code base and you're like, man, this is shit.
[29:52-30:24] Lauren Tan: Like who wrote this code? You know, it's, it's terrible. I want to rewrite the whole thing. There is a very common inclination. And I think a lot of, you know, before agents, um, and I guess arguably even now people will definitely discourage you from rewriting stuff. Um, but I'm actually here to make a case for why you might want to consider it. Um, because I think it really depends. Uh, you know, uh, brownfield applications, I think are actually in a pretty good spot, especially if they're set up well already.
[30:24-30:51] Lauren Tan: Uh, and like recently I've been talking to some people, but, uh, you know, I was just observing. I just noticed this parallel, which is that a lot of big tech company problems are now everybody's problems. Um, and the big tech company problem, you know, like when I was working at Meta, like we had this giant monorepo. We had like, I don't know, tens of thousands of engineers just, you know, like banging on their keyboards and shipping code.
[30:51-31:26] Lauren Tan: Um, and a lot of really great engineers at Meta, uh, but, uh, I'll say like, you know, you'll be surprised that the code quality is actually not that good. Um, and so I often joke that like, you know, before AI slop, we had human slop. Um, and so, uh, you know, I think a lot of big tech info, like, uh, like what Meta has or Google, you know, you know, really big tech companies are actually designed for that, where you're sort of like, you're catering to the, the, you know, like, uh, that sounds so bad to say, but like the, the least capable engineer on your team.
[31:27-31:56] Lauren Tan: Right. You build, you build frameworks, you build conventions, you build guardrails, you know, you restrict credentials so that, you know, your intern doesn't wipe your production database. Um, there's, uh, you know, if you have that level of infra already, I think your agents can actually already do a very solid job, right? Because they have the, the guardrails are already in place for agents to not cause havoc or not cause too much havoc, uh, in your code base.
[31:57-32:25] Lauren Tan: Um, and you can always add more, you know, guardrails. Uh, but I think like greenfield applications, especially are, you know, like the brand new applications are like the biggest risk in my opinion. Uh, and also the greatest opportunity because, you know, if you vibe code a project, uh, a prototype, um, like we did for Grok Bot, you know, Grok Bot was spun up very, very, very quickly. Um, and if you, uh, if you haven't heard of, of Grok Bot, it's like our, a new application we just launched yesterday.
[32:25-32:54] Lauren Tan: Uh, it's, it's really cool. Uh, lets you orchestrate your, create like individual agents that have their own identity and you can kind of orchestrate them. It's super cool. Definitely check it out. Uh, but yeah, that was, it's like a very, it was a very greenfield application. Like most prototypes are. So it was like vibe coded very quickly. Humans were not reading the code at all. And, uh, I had this tweet recently, uh, where I said something about organic architecture.
[32:55-33:32] Lauren Tan: Um, maybe I'll find it. Uh, but the idea is that, uh, when you have a completely vibe coded application, you essentially have no guardrails whatsoever. So, uh, your agents, when you give them a task, they will just solve it in whatever method is the most convenient. And over time you get into this, uh, situation where you have a code base that is spiraling out of control because you don't understand it. Uh, your agents understand it, I guess, in a way, but like they've built something that is, you know, optimized for short, for shortcuts.
[33:32-34:09] Lauren Tan: Uh, and, uh, you know, it will, you will suffer, you'll have a lot of issues with that application. Uh, so I think starting your code base with, uh, like very strong constraints is very much needed. Uh, because like when you have a code base that you can trust, right? When you have guardrails that actually help you, uh, uh, help your agents write good code, you can get into the, you know, like into this part of the curve where I, I, where I, like I said, you know, I woke up today and I had like 20 PRs merged, uh, by my agents.
[34:09-34:44] Lauren Tan: And that's because I invested a lot of time, uh, over 600 PRs. I, I, I calculated yesterday, uh, when I refactored all of Grok Bot to this new architecture that I've been building. Um, and yeah, I've gotten to a point where I, I don't really look, I really don't look at the code anymore. And, um, I say that not just, you know, to sell you tokens, but because I, you know, it, it took a lot of work to get to that point. I spent a lot of tokens to get the code base to this point where I no longer have to look at it.
[34:45-35:11] Lauren Tan: Uh, but I'm very excited because, you know, of the potential where, you know, it's not just, this doesn't just benefit me. It benefits everyone contributing to Grok Bot and it also empowers, you know, designers and product managers and, you know, people, even GTM people to add features to Grok Bot. And I don't have to worry, you know, I don't have to wake up at night in, in the middle of the night and worry like, oh shit, someone's just merged a perf regression.
[35:11-35:25] Lauren Tan: Right. I have a ton of constraints and CI is like, it's actually very annoying to write code in, in Grok Bot, but like agents absorb all of that annoyance. Um, but yeah, I'm happy to talk about what exactly that is.
[35:25-35:52] Colin: Um, yeah, I think one question, um, before we get into the, this part here is just around that element of like what your, your, your CI looks like, or maybe some of the constraints. And then also like the average PR size. I saw a question about that earlier, just to give people a, you know, kind of a glance, it doesn't have to be like mathematically average, but just, uh, you know, like what generally the size of the PR is. Um, if it's only a couple lines of code or, you know, um, yeah.
[35:53-36:02] Lauren Tan: Um, I think it depends on me. I'm trying to do this in a way where I'm not gonna like. Yeah.
[36:02-36:06] Colin: You don't have to share the actual number of you, like the actual average. This is fine.
[36:06-36:35] Lauren Tan: Benchmark. But like we have, so, okay, this is not that interesting, but, uh, well, fun fact is that virtualization in Grok Bot and in, uh, cursor is actually powered by, uh, pretext, uh, which is a sort of new library that someone's built. Um, that's really interesting. You should, you should check it out. But that's not really that important. Uh, I think the average PR size, I actually don't know. I don't know if I want to click on these.
[36:36-36:57] Lauren Tan: Uh, I probably can, but I would say like they can range anywhere from a few hundred lines or 50 lines to like a thousand, depending on what the thing is doing. Uh, so like here I'm actually like deleting a bunch of files. So I expect that it's just, it's like mostly deletion. Uh, but yeah, it, it kind of varies. There's no like, yeah.
[36:57-37:00] Colin: There's no like hard cap or hard limit or they're all like 50 line PRs.
[37:01-37:37] Lauren Tan: There's definitely no hard cap, but I do encourage my agents to split up their work into multiple PRs. Uh, I do that mostly because, uh, I like, I like the idea of the, I guess maybe this is much harder to do now as in the world of agents and you have like so many commits. But I like the idea that, you know, the Git history is a very rich source of context. Uh, and I like the, I like each PR to sort of atomically describe what that small piece of thing is doing, which also makes it easier for me to revert changes and like figure out, you know, oh, I shipped a bug and it's just, it's here.
[37:37-37:47] Lauren Tan: It's not in this 40,000 line PR where who knows what landed in there. Uh, but yeah, I don't have a hard cap on PR size.
[37:48-38:00] Colin: Cool. And then, um, yeah, also quick question on like CI. So again, you don't have to go into like, uh, the screen share of like your, your CI does, but just generally, would you describe what the CI kind of looks like, uh, or how strict it is?原始逐字稿(六):Dune 規範、CI 禁令與五層防線
以下收錄 38:00 至 48:00(共 21 段)完整英文對話,涵蓋 Dune 架構契約、禁用 useEffect 與程式碼註解、electron-main 與 electron-renderer 的 16ms 依賴圖隔離、Feature 單一目錄內聚,以及 5 層品質防線與人工 PR 評論反模式。
[38:00-38:34] Lauren Tan: Uh, yeah. So, uh, well, specifically for Grok Bot. So Dune is the, it's the sort of cheeky code, codename for the architecture that we've built for Grok Bot. Um, the CI looks pretty annoying because there's checks for everything. So like literally I have, um, uh, well, if you've written any React, for example, you know, you know that one of the biggest foot guns in React is useEffect. Uh, so in, uh, Dune and in Grok Bot, we've banned useEffect.
[38:34-39:06] Lauren Tan: So Dune is just, you know, the, the mental model of what Dune is, uh, you can kind of think of it as like Next.js for, uh, Electron apps and it's designed for agents to write. Uh, and it's like custom for, you know, our agent powered applications. Um, so the CI checks are very like specific to that. Like, you know, don't use useEffect. It's, it's, it's banned. Like CI will fail, uh, and yell at you. We have like some of the more interesting ones that people might raise eyebrows is like, I actually ban code comments as well.
[39:07-39:36] Lauren Tan: Uh, which is very interesting. Um, but I've noticed that 99% of the time agents just write code comments that kind of describe some historical thing that is actually totally irrelevant to the code. Um, like it will often say like, you know, oh, Lauren said you should never do this and it's now in a code comment. Like what? Like why? That was, I didn't say that as like a durable, you know, global rule. I just meant like your, this PR sucks and you should change that part.
[39:37-40:05] Lauren Tan: But agents don't really understand us that well, surprisingly. Uh, and, or they kind of assume too much and they kind of do things in like very stupid ways. So like, yeah, we just ban everything. Everything you can imagine like the agents are bad at, we ban. Um, uh, so one example that we actually suffer a lot in the agents window is we have, uh, you know, if you've used agents window, you've definitely seen performance issues and, you know, we're constantly trying to fix them.
[40:06-40:36] Lauren Tan: Uh, but it's like a, it's a never ending struggle because there's so many pull requests that get merged. Any one of them could just regress performance or stability or reliability. Uh, you know, the agents window doesn't have this architecture yet. I plan to do, bring this learning back there and kind of refactor everything there. Uh, but, uh, it just regresses super often, uh, because, uh, there's just one example is like we have very poor, um, isolation between processes.
[40:37-41:08] Lauren Tan: So like on, you know, on, on Electron, you have a renderer thread that renders your UI, but you also have like a main thread that you can run other code that, you know, doesn't need to block the renderer. Um, but we do a poor job of separating those things. And so oftentimes you just accidentally have code that gets pulled into running on the renderer thread. And then all of a sudden you're competing with the, the renderer that, you know, that has a very, if you want like 60 FPS, you have to, every frame that gets drawn has to be done in 16 milliseconds.
[41:08-41:36] Lauren Tan: So very, very small, you know, deadline per frame, uh, if you want, you know, a very smooth product. Uh, and when you start building, bringing in, accidentally bringing in, you know, things that are like very computationally heavy, or they have a lot of IO, uh, then you just get into like a lot of jank. And your, your, your FPS really drops. You start, uh, you know, losing frames. You get long tasks that take more than 16 milliseconds and you just get this really choppy experience.
[41:37-42:14] Lauren Tan: So all of those patterns that we've learned, basically building electron apps, we've encoded into this framework and it becomes like a hard failure. So I literally, in, in Grok Bot, we literally have a directory called electron main, electron renderer. And we have, uh, import, uh, CI, I guess, where we actually check the dependency graph to make sure they're not accidentally importing code from one directory to another. Uh, so that's enforced by CI, um, as well as Bugbot, uh, which is our, which cursor's, um, like code review tool that runs on CI.
[42:14-42:46] Lauren Tan: Uh, you know, uh, you know, in our AGENTS.md, it's everywhere. Like, so I, I, I, um, I have this thing here where I talk about like, um, you know, like there are multiple layers, I think for building a good code base. Uh, obviously the code base is one where, uh, if you have an architecture like this, where it's extremely strict, uh, you know, the, the, the way to build features is very conventional. That's like the strongest, strongest level of enforcement because agents just love to copy existing patterns.
[42:47-43:14] Lauren Tan: So, uh, one example of this in Grok Bot is like, we have this, these concepts called like a feature and we have entry points and transcript cards. Like, oh, you know, the cards that you see in the chat, these are all like, like nouns, I guess, in, in the framework. And so there's a very conventional way of creating them. And so like a feature is all in a, in a single directory as an example. And so all of the code that contributes to that feature lives in one directory.
[43:14-43:42] Lauren Tan: So it's all co-located in one place. It makes it super easy. You know, agents don't have to like, uh, grep around and try to figure out like where all the things are. It just looks at the feature and like, oh, okay, I'm working on the onboarding feature in Grok Bot. Uh, I'm just going to work in this directory. And for 80% of the work, it's mostly just very encapsulated there. But, uh, like it's like very, it's like designed again for, you know, like the dumbest agent.
[43:42-44:10] Lauren Tan: Like you don't have to think, right? The, the, the, one of the key principles I have for this framework is like the shortest, the shortest path is the best path. So, uh, because that plays exactly to how agents love to write codes. Like they like to take shortcuts really, you know, they'll, they'll find the quickest way to solve the problem. So why not make that the best way to solve the problem? Uh, so I, I, I probably won't get into all the specific details.
[44:11-44:42] Lauren Tan: Um, and, uh, the, the, this framework is really more of a collection of ideas and principles rather than something that will open source. Uh, you can, you can, you know, screenshot this, I guess, if you want and, uh, tell your agent to, uh, do some, build, build something like this for you too. Um, yeah, but it's really all about the layers. Uh, you know, like the, the code base is one part with features, uh, and directories and, you know, import or blocking import dependencies, uh, that shouldn't be imported.
[44:42-45:18] Lauren Tan: Uh, but, and, and it all enforces that and static analysis. So like, uh, there's CI checks. We have a lot of lints for bad patterns that we observe, uh, compiler diagnostics. Uh, there's also rules and Bugbot, which are, um, I think like three, four, five are more soft, right? These two actually make CI red, right? So that, you know, there's a hard constraint where the agent can't just write crappy code. For rules and skills and Bugbot, your agents can still forget, right?
[45:18-45:51] Lauren Tan: You can still, or it may not always consistently apply them. So I like to layer them, but I don't, I don't like to rely on them as the only source of enforcement because it's very, very soft, right? And if you, if you only have rules and Bugbot and skills and a style guide for your code, you will, it's only a matter of time before your code base looks like complete trash. Um, sorry to say that, but, uh, I definitely recommend, yeah, like, you know, investing in, you know, things that can be hard enforced, right?
[45:51-46:21] Lauren Tan: And this is why, you know, maybe, uh, the choice of tech stack that you use is also very important. Um, like, I think for example, Rust is sort of making, you know, it's like getting super popular again, uh, because the compiler is so strict, right? The compiler enforces so many different things, you know, there's a borrow checker that you have to appease. And if, as long as you make sure your agents don't write unsafe code blocks, uh, you can more or less feel somewhat confident that if the code compiles, it's probably works and it's good.
[46:21-46:58] Lauren Tan: Uh, but you'll see, it gives you that level of trust and confidence that you as a human engineer no longer need to go and check it yourself. You know, you, you rely on code and static analysis to actually make that, uh, a lot smoother. Um, and I guess the worst part, the worst place to be in is if you are stuck in code review land where you actually enforce all of the constraints, the invariants in your codebase by literally the human person saying, you know, reading the code and like, okay, you should not do this.
[46:58-47:25] Lauren Tan: Right. Every time you have to do that, you should consider that as a code smell, like a, uh, uh, anti pattern. And you should say, okay, instead of me commenting on the PR, how do I turn this into a hard rule? Right. How do I turn this into a lint rule? How do I turn this into a CI failure? Or how do I even categorically eliminate this problem, uh, entirely? Uh, I, I can talk about another migration I've done, but I'll probably pause here.
[47:26-47:49] Colin: Sure. Yeah. I feel like that's, that's where I am to be honest is, is what you're describing right now, which is that like, I don't have all of these rules. Uh, so I have some things to go do after this session, uh, in terms of being able to scale my agents. I'm, I'm definitely on like the, uh, you know, maybe a couple of parallel ones locally stage, like two to three locally. And I'm sure most people here are on the same. So, uh, yeah, I know we only have a couple minutes left.
[47:49-47:56] Colin: Uh, Lauren, was there anything else that you wanted to, to highlight? I obviously there's lots of questions, so I can grab more, but I want to give you a few minutes. Uh, if there's anything else you want to talk about.
[47:56-48:00] Lauren Tan: Well, I think I've been yapping for quite a lot. So maybe let's just do questions.原始逐字稿(七):Token ROI 與跨職能協作
以下收錄 48:00 至 55:30(共 16 段)完整英文對話,涵蓋前期重構 Token 投資報酬率、Grok 4.6 成本與智力帕累托前沿,以及 PM、設計師與業務透過 Grok Bot 直接交付成果的跨職能實況。
[48:01-48:20] Colin: Okay, cool. Uh, one question that had, uh, a couple of, uh, came up a couple of times was just around like token usage. So the question is like, is, is what you're describing a realistic thing for people who are on, you know, uh, a normal set of token usage. They don't have, you know, basically unlimited tokens, uh, to work with.
[48:21-48:46] Lauren Tan: I think that's a really good point. I mean, like, obviously, you know, I work at an AI lab where we have unlimited tokens. So, uh, I definitely cannot say that, you know, this is something everyone should do in the exact same way that I did it. I think it's possible to get to this point without, you know, breaking the bank. But, you know, if you're like an engineering leader or, you know, you're, you're, you have a startup that you lead.
[48:46-49:16] Lauren Tan: Um, I think to me, it's a question of ROI. Um, and it's like, uh, yes, you spend a lot of money on tokens in the upfront stage. You know, like refactoring your code base is going to take a lot of tokens. Uh, adding all these things, uh, is going to take a bunch of tokens. But if we're heading to a world where agents are writing all the code and, you know, you want to be very lean, right? You don't want to have to hire, you don't want to be, you don't want to become like meta, right?
[49:16-49:43] Lauren Tan: Like, I mean, like in terms of, you don't want to become a 10,000 person engineering org because, I mean, that's a cool problem to have. But also, you know, you, you have so much overhead. And there's like planning, you know, like it's, it's, uh, personally, I wouldn't, uh, it's not super fun, but, um, I think you want to stay very nimble, right? And you want to, you want to be like agents are all about allowing you to do things that you couldn't do before.
[49:43-50:17] Lauren Tan: That's really to me, like the value of agents, you know, it's not just storing tokens on every single little thing. But, um, to me, like the thing I couldn't do before is like enforce this level of constraints in a code base by myself, right? Like I'm just a single person, you know, uh, it would have taken me years to build this framework, uh, and do all the refactoring and test everything myself and verify, you know, like run. Imagine if it was just me right now in, in pre-agent era, just like running, you know, by myself.
[50:17-50:48] Lauren Tan: It would take me so long, right? And my salary is pretty high, right? Like, so, you know, the, the question I think an engineering leader might have is just then, you know, like what is, there's a trade-off of, do you hire someone to do this? Or do you spend the tokens to set up a code base so that even the, the most naive, right? The dumbest agents can do a good job. And when you actually get to this point, like even agents that are not frontier-sized do an excellent job of writing code.
[50:48-51:20] Lauren Tan: And this pays a lot of dividends as well for me personally, where I've empowered, not just myself, but again, like PMs, designers, engineers who are not familiar with Grok Bot to just contribute in a way that is sustainable. So I think, yeah, it's definitely like a trade-off for sure. You know, like nothing is like free for sure. And tokens are pretty expensive. But, oh, actually, I don't know how many of you have seen this, but we actually announced Grok 4.6 today.
[51:20-51:56] Lauren Tan: So very exciting, finally out. So yeah, Grok 4.6 would be like a great, it's very, very smart. It's really good on the, on the benchmarks. And it's the same, the tokens, well, I hopefully I'm not saying this incorrectly, but I believe the cost per token is the same as 4.5. So you're actually getting more intelligence for the same cost. I think this is an area that Cursor tries to, Cursor and SpaceXAI try to really optimize for, like that Pareto frontier of, you know, cost versus intelligence.
[51:56-52:22] Lauren Tan: You know, we don't necessarily want to build the biggest model ever because that is extremely expensive to run. It's really about, like, how do you find that sweet spot, right? You don't, you don't need a giant model, but it's just super smart, right? And it's not very expensive for inference. But, yeah, I think to kind of round it up, I think it's like a, it's, it's, there's a, if you do your own analysis, I feel like it's pretty positive.
[52:22-52:45] Lauren Tan: It will be pretty positive that the ROI you get from investing in stuff like this just empowers, not just yourself, but your whole team to be so much more productive, right? Like, imagine if you have an army of engineers like me who are shipping so much improvements and bug fixes, you know, every day, right? Like, that is pretty exciting.
[52:47-53:11] Colin: Cool. One last question before we wrap up. This one is for the people in product on the call. So, let's say we do have an army of engineers who are shipping like Lauren. I'm just curious, like, how is the product team or other functions of your company keeping up, given that, like, if you're shipping so quickly, have, are they using AI more to do their jobs? Like, as much as you can speak to that, I know, obviously, you don't have, like, you're not in that role, but just curious about how that works.
[53:12-53:38] Lauren Tan: I think this is where Grok Bot has been actually exceedingly powerful. So, before Grok Bot, like, you know, obviously, cursor only had cursor. Like, we only had agents window. We had a CLI. We had an IDE. And these are really, like, power user tools, right? They're designed for developers. So, it's very, very developer-centric. You can do knowledge work in them, but, like, the UI is not really optimized for that.
[53:38-54:10] Lauren Tan: So, we actually didn't really have, well, I think, like, a lot of people, like, you know, GTM product, like, they might have used cursor to do their work, but it definitely wasn't, like, a delightful experience for them. I think now with Grok Bot, it's become, Grok Bot is basically, like, their cursor moment for people who are not in tech, in my opinion. Like, it's, like, it's, like, a very, very accessible way to use agents in a very comfortable, very familiar interface.
[54:10-54:34] Lauren Tan: It looks like iMessage. And it's very fun, too. You know, you can give your agent a fun name. You can have, you can kind of do orchestration in a very, like, natural way where you can sort of, you know, each agent is, like, a person. And now you've got a team of agents, like, working on. You have one agent per account that you manage, as an example. Or if you're a PM, you have, you know, you can have an agent that summarizes all the work that Lauren did last night.
[54:34-55:03] Lauren Tan: And then now you know what I did, right? So I think our PMs are leveraging that a lot. And they're shipping code, too. So, you know, like, oftentimes they will just say, oh, here's a bug. I fixed it. Can you look at it? And then I'll go review it. And actually, it's just perfect. I'm like, okay, stamp. So I think that shows that, you know, the Dune architecture is holding up, right? Like, all the really strict constraints allow people who are not experts in engineering to contribute at a high level.
[55:04-55:30] Lauren Tan: So I feel like I'm already seeing that pay off a lot where, you know, designers and PMs are just able to ship features directly. And that just makes the Grok Bot team super fast, right? Where we can ship so quickly. And we have a lot planned. So I'm very excited to, you know, to ship more stuff.團隊採用建議
仍由人工手動測試 Agent 產出
先建置單機實機驗證與 Feature Map
安裝或參考 pstack 的 create-verification-skill,接通 CDP、瀏覽器或模擬器控制與預先驗證登入態,為核心畫面建立一功能一檔案的使用者視角 Feature Map,先讓 Agent 能獨立確認 0 筆 Console 報錯。
Agent 常未讀原始碼便瞎猜根因
導入證據查核技能與偽裝目錄盲測
展開日常失敗任務的 Tool Calls,編寫類似 how 的讀檔舉證技能;再以量化 Rubric、偽裝名稱的子 Agent 目錄與異構模型 Judge 搭配 /loop 迭代至 10/10,避免單憑感覺修改提示詞。
Vibe-Coded 專案開始失控或審查塞車
將功能內聚至單一目錄並把 PR 評論轉成硬性 CI
推動單一 Feature 資料夾封裝與保留檔名自動發現以減少合併衝突,並盤點重複出現的人工 Code Review 意見,改寫為禁用高風險 API、阻斷跨執行緒違規引用等會讓 CI 直接變紅的靜態檢查。