Lauren Tan: How I Merged 1000 PRs in a Month with Agents
⚡ 速览
Cursor 工程师 Lauren Tan(前 Meta React Compiler 成员、Netflix tech lead/工程经理)完整拆解了自己如何从熟悉代码库走到一个月合入 1000 个 PR。核心论点:AI 辅助工程的瓶颈不在生成、在验证——agent 不能自己跑产品、抓 CPU trace 和 heap 快照、按截图复现 bug,你就永远是那个串行的 verifier。她依次讲了让 agent 操作和验证 Cursor 本体的 Control Glass skill 与 feature map;像测代码一样测 skill 的 eval playbook(协调者拟 rubric、目录匿名防 agent 察觉、跨模型 judge 交叉打分、/loop 爬山到满分);自动复现所有 bug 报告的云 agent Benny;以及专为 agent 设计的 Dune 架构(Electron 版 Next.js)——靠硬约束(禁 useEffect、禁代码注释、import CI)让 agent 敢于自动合流 PR,甚至 PM 和设计师也能直接 ship 功能。
英文原文
Cursor engineer Lauren Tan (formerly React Compiler at Meta, tech lead and EM at Netflix) walks through how she went from learning the codebase to merging 1000 PRs in a month with coding agents. Her core claim: the bottleneck in AI-assisted engineering is not generation but verification — if your agent cannot run the product, take CPU traces and heap snapshots, or reproduce a bug from a screenshot, you remain the serial verifier. She covers the Control Glass skill and feature map that let agents operate and verify Cursor itself; the eval playbook (coordinator rubric, anonymized sub-agents, cross-model judge, /loop hill-climbing) she uses to test skills like code; Benny, the cloud agent that reproduces every incoming bug report; and Dune — a Next.js for Electron apps designed for agents — whose hard constraints (banned useEffect, banned code comments, import CI) let agents auto-merge PRs and even let PMs and designers ship features.
🗺 章节地图
💡 核心亮点
1. 信任曲线:从微观管理到一觉醒来 20 个 PR
Lauren 把 agent 落地描述成一条个人信任曲线,与管理同构:不信任导致微观管理。早期你盯着一两个 agent 的每份输出;五个月后她的 agent 自动合 PR——一觉醒来 20 个已落地,直接在 main 上审查。上个月 ship 了 1000 个 PR,本月 12 号已近 800。她的警告:别从低信任直接跳到开一千个 agent,那是纯烧 token。
EN original
The Trust Curve: From Micromanaging to Overnight Auto-Merges
Lauren frames agent adoption as a personal trust curve that mirrors engineering management: distrust breeds micromanagement. Early on you watch every output of a handful of agents; five months in, her agents auto-merge PRs — she woke up to 20 landed PRs and reviewed them on main. Last month: 1000 PRs shipped; day 12 of this month: almost 800. Her warning: don't jump from distrust to spawning a thousand agents — you'll just burn tokens.
2. 验证是与 agent 协作的第一技能
工具箱里最重要的技能是验证:agent 能真正运行代码、抓 CPU trace、打 heap 快照、打开 iOS 模拟器——应用以什么方式呈现给用户,agent 就能以同样方式真实运行。它不保证好代码,但保证正确代码,这是建立信任的关键一步。没有它,你自己就是 verifier、就是瓶颈,并行无从谈起。
EN original
Verification Is the #1 Agent Skill
The most important skill in your agent toolbox is verification: the agent's ability to actually run the code, take CPU traces or heap snapshots, or open an iOS simulator — however your app is exposed to users, the agent runs it for real. It doesn't guarantee good code, but it guarantees correct code, which is the big step toward trust. Without it, you are the verifier and the bottleneck, and parallelizing is impossible.
3. feature map:把模糊截图变成可复现 bug
她的 Control Glass skill 附带一张 feature map:教 agent 每个功能是什么、UI 上怎么到达、快捷键、以及 CDP 选择用的 DOM 属性。有了它,Slack 里一张截图加三个问号的报告也能落地:agent 自己导航到功能处复现问题。PStack 的 create/maintain verification skill 可以给你的代码库生成并持续维护这张图。
EN original
The Feature Map: From Vague Screenshots to Reproducible Bugs
Her Control Glass skill ships with a feature map — a file teaching the agent every feature, how to reach it in the UI, the keyboard shortcuts, and the DOM attributes used for CDP selection. With it, even a Slack report that is just a screenshot and three question marks becomes actionable: the agent navigates to the feature and reproduces the issue. PStack's create and maintain verification skills can build and keep this map current for your own codebase.
4. 像测代码一样测 skill:eval playbook
每种观察到的失败模式都沉淀成 skill;每个 skill 都用 eval 做单元测试。她的 playbook:协调 agent 拟 rubric,在巧妙命名的目录里开一批 sub-agent(让它们察觉不到被评测——agent 察觉后会改变行为),用不同模型的 judge 交叉核对防偏,再用 /loop 爬山直到全 10 分——并跑遍 Cursor 支持的模型矩阵,尤其是你常用的模型。维护 skill 很难:极吃品味,要像后座司机一样盯着每个 tool call。
EN original
Test Skills Like Code: The Eval Playbook
Every observed agent failure mode becomes a skill, and every skill is unit-tested with evals. Her playbook: a coordinator agent writes a rubric and spawns many sub-agents in cleverly-named directories so they can't tell they're being evaluated (agents change behavior when they know), a judge of a different model cross-checks for bias, and /loop hill-climbs until everything scores 10/10 — run across Cursor's whole model matrix, especially the models you use. Maintaining skills is hard: it takes taste and backseat-driving observation of every tool call.
5. Benny:自动复现所有 bug 报告的云 agent
Benny 接走每一条进来的 bug 报告,开出自己的云端桌面、在上面跑 Cursor,用同一套控制 skill 复现问题。她的例子里,Benny 复现了 bug 但发现 main 上已修——Lauren 要做的只是再发一版。验证 skill 的回报是全团队级的:先在能观察的本地起步,再扩展到能自主行动的云 agent 和自动化。
EN original
Benny: A Cloud Agent That Reproduces Every Bug Report
Benny takes every incoming bug report, spins up its own cloud desktop, runs Cursor there, and uses the same control skills to reproduce the report. In her example it reproduced the bug but found it already fixed on main — all Lauren had to do was ship another build. Verification skills pay team-wide dividends: start local where you can observe, then scale to cloud agents and automations that act on their own.
6. Dune:Electron 版 Next.js,禁 useEffect 禁注释
Dune(Grokbot 架构的诨名)是「为 agent 设计的 Electron 版 Next.js」。CI 直接禁用 useEffect(React 最大的坑),连代码注释都禁——99% 的 agent 注释是「Lauren 说过别这么干」式的无关历史。electron-main/electron-renderer 目录隔离由检查依赖图的 import CI 强制,再加上针对坏模式的 lint 和 BugBot 审查规则。
EN original
Dune: Next.js for Electron, Banned useEffect and Comments
Dune, the cheeky codename for Grokbot's architecture, is 'Next.js for Electron apps, designed for agents.' Its CI bans useEffect (React's biggest footgun) and even code comments — 99% of agent-written comments are irrelevant history like 'Lauren said never do this.' The electron-main / electron-renderer directory split is enforced by an import CI that checks the dependency graph, plus lint for observed bad patterns and BugBot review rules.
7. 分层约束:架构与 CI 优先于规则
约束分几层:约定俗成的架构(feature 单目录,agent 爱照抄现有模式)最强,其次是静态分析和 CI,再次 lint 与编译器诊断,最软的是 rules/skills/BugBot/风格指南——agent 会忘,绝不能单独依赖。Rust 重新流行正因为编译器给硬保证。最糟的位置是困在 code review 国、靠人留言执行不变量:每条这样的留言都是 code smell,该变成 lint 规则、CI 失败,或整类消灭。
EN original
Layered Enforcement: Architecture and CI Over Rules
Enforcement has layers: conventional architecture (each feature co-located in one directory; agents love copying existing patterns) is strongest, then static analysis and CI, then lint and compiler diagnostics, with rules / skills / BugBot / style guides the softest — agents forget those, so never rely on them alone. Rust is popular again precisely because its compiler gives hard guarantees. The worst place to be is code-review land, enforcing invariants by human comment: every such comment is a code smell — turn it into a lint rule, a CI failure, or eliminate the problem class entirely.
🎤 金句
今天早上我醒来,已经有 20 个 PR 落进 main 了,我直接在 main 上审查——它们已经合进去了,而且质量都很好。
EN original
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.
如果你用 agent 做开发却没有验证 skill——你就是那个 verifier,你就是瓶颈……你始终被摁在循环里当瓶颈,根本没法并行。
EN original
If you've ever done development with an agent where you don't have a verification skill — you are the verifier. You're the bottleneck... you're constantly just in the loop and being a bottleneck. So there's really no way to parallelize.
我经常开玩笑:AI slop 之前,我们早就有 human slop 了。
EN original
I often joke that before AI slop, we had human slop.
我给这套框架定的核心原则之一是:最短路径就是最优路径……agent 就是爱抄近道……既然如此,为什么不让最短路径直接成为最好的解法?
EN original
One of the key principles I have for this framework is: the shortest path is the best path... agents love to take shortcuts... so why not make that the best way to solve the problem?
如果你的代码库只有 rules、BugBot、skills 和风格指南,它变成彻底的垃圾堆只是时间问题。
EN original
If you only have rules and BugBot and skills and a style guide for your code, it's only a matter of time before your code base looks like complete trash.
每当你不得不靠在 PR 里留言来执行一条不变量,就该把它当成 code smell……与其在 PR 里留言,不如想想:怎么把它变成硬规则?
EN original
Every time you have to enforce an invariant by commenting on a PR, you should consider that as a code smell... instead of me commenting on the PR, how do I turn this into a hard rule?
以前做不到的事是:靠我一个人把这种级别的约束灌进一个代码库。我只是一个人——自己做要花上好几年。
EN original
The thing I couldn't do before is enforce this level of constraints in a code base by myself. I'm just a single person — it would have taken me years.
在我看来,Grokbot 就是给非科技从业者的「Cursor 时刻」。
EN original
Grokbot is basically the Cursor moment for people who are not in tech.
🧭 行动建议
- 1 先建验证 skill 7:52
在规模化 agent 之前,先教会一个 agent 端到端运行你的产品——Web/Electron 用 Chrome DevTools 协议,模拟器用 Apple 工具——抓 trace 和 heap 快照。先求正确再求优雅;正确性才解锁信任与并行。
EN original
Before scaling up agents, teach one to run your product end-to-end — Chrome DevTools Protocol for web/Electron, Apple utilities for the simulator — taking traces and heap snapshots. Aim for correct code before good code; correctness is what unlocks trust and parallelism.
- 2 建立并维护 feature map 13:21
把每个功能映射到 UI 位置、快捷键和 DOM/CDP 选择器,让 agent 能对模糊报告和裸截图采取行动。用 maintain verification skill 保持更新;PStack 的 create verification skill 能通过探索代码库自动生成。
EN original
Map every feature to its UI location, keyboard shortcuts, and DOM/CDP selectors so agents can act on vague reports and bare screenshots. Keep it fresh with a maintain-verification skill; PStack's create-verification skill can bootstrap one by exploring the codebase.
- 3 失败模式沉淀为 skill,再做 eval 19:58
打开所有 tool call,观察 agent 在哪幻觉、跳过读代码、瞎猜;把每种失败模式写成 skill。然后像测代码一样测它:协调者拟 rubric、目录匿名开 sub-agent、跨模型 judge 交叉打分——迭代到 skill 确实按你以为的方式工作。
EN original
Open every tool call, watch where agents hallucinate, skip reading code, or guess; write each failure mode as a skill. Then test it like code: coordinator rubric, anonymized sub-agent directories, cross-model judge — iterate until the skill does what you think it does.
- 4 用 /loop 爬山优化 eval 23:47
让协调 agent 产出分数、不同模型的 judge 查偏、然后循环 eval 直到全 10 分——跑在你实际使用的模型矩阵上,因为 skill 在不同模型上表现不同。同一个闭环让她的 Control Glass skill 几乎免维护地越用越强。
EN original
Have a coordinator produce a score, a different-model judge check for bias, and loop the eval until everything is 10/10 — across the model matrix you actually use, since skills perform differently per model. The same loop built and hardened her Control Glass skill with almost no hands-on maintenance.
- 5 本地起步,再上云 26:25
先在本地建验证——那里你能观察 agent 怎么与应用和 API 交互。建立信任后再上云 agent 和自动化——比如 Benny,它接走每条 bug 报告,在自己的云端桌面复现,并报告是否已修复。
EN original
Build verification locally first, where you can observe how the agent interacts with the app and its APIs. Once trusted, move to cloud agents and automations — like Benny, which takes every bug report, reproduces it in its own cloud desktop, and reports whether it's already fixed.
- 6 硬约束优先于软规则 45:24
把不变量编码进架构约定、CI 检查、lint 和编译器;把每条人工 code review 留言当作候选项——变成 lint 规则或 CI 失败。只靠 rules 和风格指南维系的代码库,迟早被 agent 毁掉。
EN original
Encode invariants in architecture conventions, CI checks, lint and compilers; treat every human code-review comment as a candidate lint rule or CI failure. If a codebase is only held together by rules and style guides, agents will trash it eventually.
- 7 把 token 开销算成 ROI 51:40
重构和约束代码库的前期 token 成本(Grokbot 迁移 Dune 花 600+ PR)替代的是招聘,还能让非旗舰模型也贡献高质量代码——并赋能 PM 和设计师直接 ship。Lauren 的账:投资完成后,她彻底不用再看代码。
EN original
The upfront token cost of refactoring and constraining a codebase (600+ PRs to migrate Grokbot to Dune) replaces headcount and lets even non-flagship models contribute well — and it empowers PMs and designers to ship. Lauren's math: after the investment, she no longer reads the code at all.
📖 全文
0:00 · Intro: From React Compiler to Cursor
0:00Hi everyone. I am Lauren Lauren Tan I guess not many people know my last name I am Potato on Twitter Potato with spelled with an E and I have been at Cursor for about five months previously I was at Meta where I worked on the React team specifically working on the React compiler which was a whole lot of fun I'm still on the on the core team and and, contributing to open. Source here and there so that that's really nice that they still let me do that and before Meta, I was at Netflix where I was, both a tech lead and I transitioned to be be an engineering manager for about two years So I've had a I've had a lot of experience going between engineering management and being an individual contributor and I think something I've noticed actually which is quite interesting is that there are so many parallels with you know management skills and how to like manage agents and that's actually a a big part about what I wanted to chat with you and everybody else about today but yeah, that's, that's me I do have some like very light slides But, it's not gonna be
1:21just rambling. So let me just share my screen and hope that I don't leak anything Oh no, I need to allow permissions No worries. Okay, take your time There's always tech, tech, tech trouble give me one second to rejoin Yeah, go for it I see many of you already know Lauren from from the looks of the chat here so yeah it's exciting to to get a chance to chat with her and and go through some of her her recent work. As you guys heard you know a lot of recent experience from from Netflix to to Meta and then now over at Cursor we're going to chat a little bit about Grokbot as well So that'll be exciting. I don't know if you guys saw that was a recent release I think literally maybe yesterday or the day before from the Cursor team which is kind of like let's call it like Agents for Everyone You can go check it out if you want and learn a bit a little bit more about the product But, but yeah, we'll we'll explore that a little bit today as well Alrighty, welcome back And Lauren, you're just on mute there if you want to hop off of mute if you're chatting Yeah, sorry. No worries It's 2026 and I still don't know how to use Zoom That's all good okay, so I assume you can see my screen?
2:54 · The Trust Problem and the Management Analogy
2:54Yes. Yeah, we're good So yeah, today, yeah, I think 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 And when you lose when you don't have much trust in your agents I feel like you you really can't get the most out of them And for me the parallel is like with management so if I'm an a manager, an engineering 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 gonna be in is gonna be like micromanagement right? I'll have to spend a lot of time looking over my report's shoulders and checking that they're doing their work well that they're not shipping bugs to production And so, I drew this chart because it's not, 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 I think you you 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 fig 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
5:07 · The Trust Curve: 1000 PRs and Overnight Auto-Merges
5:07you don't again you don't have that trust right 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, it makes me sound like a slop artist but I, 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 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 gotta show this this chart where No, do, do not trust, to someone requested to control my computer probably won't do that but, yeah, so this chart I think I, I I'm showing 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 it sort of like inversely matches the contributions I've been able to land cursor So I joined five months ago Then five months ago like I, you know my first month I was like not very productive'cause I was you know, I was learning the code base Didn't know what the heck was going on
6:47And as I got more confident in 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 you, you, I, I'm I swear a lot of you will definitely be questioning like how how much of this code is actually really good and I think yeah like that's definitely fair to question but yeah I think 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
7:35 · Verification Is the #1 Skill
7:35we do that so for me, I think I'm curious like, I guess call it 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 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 it don't 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 I will, I can share one example that we have within Cursor oops Where? Let me open this. Let me just make this bigger make my full screen There you go so for The, for Cursor's agent window
9:09 · Control Glass and the Feature Map
9:09so 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 I was asked to basically help out with the agent window work but there wasn't really a lot of like skills to help me so I just found myself that okay agent's window is going to launch in like a week 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 performant the 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 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 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 I would download trace I would send it to it and it'd be like "Yeah, it kinda looks like this," you know? and it would like confidently state like "It's this thing." And then I'd try to fix that 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 right? You, you're the bottleneck You, you, 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 doesn't work." Then you got 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 and being a bottleneck. So there's really no way to parallelize So the control glass skill is like one
11:17of the first skills I built for Cursor and Glass, by the way is the code name for agent's window that we use internally but it's just Cursor I guess and so this skill Is, I guess the, the the code itself is not super interesting Your agent can very easily make one for you where if 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 but one thing I actually want to talk about is the this thing where is to 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 So, you know, like someone would say like "Oh, the the left sidebar is like laggy or something like that." Or you know, the right side, the 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 Just go locally and, you know it would spawn a dev build but then it'd just be churning Like, I just try to click here It it wouldn't know how to get to things and it was just an awful experience so, who's putting arrows on my screen?
13:21so, 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 I've made, if you search for PStack cursor on Google you'll, you'll find it 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 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 you can actually map even like a vague report or even a screenshot 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 Rockbot 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 like and then someone just says question mark question mark question mark like what is this? And you know like without this for agents I have no clue 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 here's where to, how to get to it all the different keyboard shortcuts even like the the what do you call it the DOM elements or yeah like the attributes that you use for selecting things through the CDP are all there so again yeah this is like really really powerful for for agents and NFPs that ships that create verification skill but also a maintain verification skill so you can keep this up to date Cool Yeah, I was just gonna ask how you created that So, do you mind sharing a little bit more about that, that process in the context of PStack?
15:39 · PStack: Failures Become Skills
15:39And maybe just what PStack is for the folks who aren't familiar Yeah, so PStack is pretty interesting because well, first of all, the name is kinda goofy Like, the P, the P in PStack is like potato potato stack Because I, so, there's a pretty, famous person, Gary Tan who is the CEO of Y Combinator and he's come up with this plugin called GStack GaryStack And, funnily enough, we share the last name We have no relation but I thought it'd be funny to kind of you know poke fun at Gary and make PStack my version of of, of, of his plugin but kind of just tailor it to my own set of prac- engineering practices but I honestly actually never set out to build PStack. But 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 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?
17:04And 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 and that made me just extremely suspicious And at that point I was just like I'm not gonna, I can't trust any this agent anymore,'cause 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 you don't know how to help your agents succeed But, like, again, I think the, the the management analogy is super helpful because like imagine if you were a manager of an engineering team and you had an engineer on your team who was a really good coder no business context whatsoever. You know they, they just, you just hired them and they 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 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 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 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. Yeah, I built PStack very very incrementally so, started with just really observing how agents you know, all the fail, different failure modes of of that agents were having And every time I saw that I just, okay I'm just gonna make that a skill Right? Like, stop hallucinating, actually go and search up look up the code use a lot of sub-agents and yeah, stop guessing Yeah, that makes sense. One
19:17one 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 that 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 in, you know you can trust that the verif- verification loops that you've built are gonna I guess, you trust that the outputs when, when they're done yeah, maybe I'll talk about I think I have somewhat related maybe I'll start with this one first So, like, how do I maintain these skills?
19:58 · Evals: Unit-Testing Your Skills
19:58So, if you're not familiar with this concept an eval is essentially like a way to well, I 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 my screen is red Yeah, there's a little button Sorry Oh, the drawing, like disabling the drawing or something? I, I can't see my screen Yeah, sorry. If you guys could not draw on the screen that'd be great. But there's a little button in the Yeah, the, the little drop down 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 Potato Mode, there's a playbook, if you search for it called eval playbook and it's it's like not, it's actually pretty pretty rigorous, the way it's done 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 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 but it does a bunch of stuff like that to essentially, yeah like 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 are we, we support so many different models So you can actually eval your skill across all sorts of different models and, you know get a sense of how well it performs across that different matrix especially for the models that you use
22:15so I do this a lot Every time I, I modify a skill I will run one of these like the email playbook and make sure that you know 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 do pair if you've ever done pair programming for example and you watch a coworker code and you just like you, you could probably do this better You know, you could do, you know like why did you not do this right? You you ask a lot of questions to your coworker And it's kind of a similar thing here You like you don't want to just be a passive observer of the agent. You want to be very in the driver seat in the initial stages when you're building up your own set of skills you know, obviously you can use something like P-Stack but if you're building your own set of skills it's very, I think, you know, opening up the all the tool calls and like reading the code and reading all the the agent behavior and their thinking blocks is a really great way to see where they they fail 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
23:47So 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? a score that you can get your coordinator to produce but also comp- 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 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 in that skill and over time it's gotten really good but yeah it was definitely not super move 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 but I think of it like you know as a as a engineer now you're sort of more like you like maybe a manager or the analogy I like is like you're like a 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 you're in charge of setting up the kitchen you're in charge of you know, like giving tasks to different people
25:37So yeah, it's a very interesting way of working but yeah, that's, that's how I've basically built these verification skills Yeah, just, just one follow-up there on like I had to go try to go one layer deeper So, are you, let's say we wanted to build an, an eval or a skill for for something and we wanted to kind of get better on its own which is, is what, what I think You're suggesting are you doing that in like a worktree kind of isolated with like the sub-agents and and then the reviewer agent and and all that? Is it happening like in some type of cloud-hosted environment? Like, what's the, 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?
26:25 · Start Local, Then Cloud Agents and Benny
26:25I 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 the application You can see it you know, how it calls like the different APIs that that allow it to interact with the the application but, for me personally I have basically been kind of all in mostly all in on cloud agents because they're extremely powerful 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 and even your whole company because you can actually start thinking about cloud agency and start thinking about automations that automatically do things. Like I'll, I get, I I kind of talk about this a bit later but I'll just kind of Get into it where, where, you know, for example, like I talk a lot about this agent we have called Benny right? Who, who, you know takes all of the bug reports that we get and it automatically goes off in the cloud opens up a cloud its, you know, its 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 or the user report right? And this is so so powerful because at once I can immediately I I get so much information from this automatically Like here in this example you can see that the Benny actually reproduced the bug 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 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 figure like is this fixed? Is this not fixed?
28:49So you, you, you gain back so much time but, you know everybody on my team benefits from this Everybody in the company benefits from this so definitely think that you know, keeping these, Using Claudians is super powerful but yeah, it's like a journey You have to trust it first right? Before you, you get to this point And that's it goes back to what I was saying here where you know, it's very hard, it's 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 wanna jump to like I'm gonna spawn a hundred of thou- or a thousands of Claudians right now because you're just gonna waste a lot of tokens and That's gonna be extremely expensive 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 just start with verification 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 is 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 the actual behavior in the app and so on and then once we trust it locally then we can start to think about scaling into the cloud and running 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 and give us back a PR I think maybe the last step is like auto-merging the PRs which is where you're at and maybe not where I want to go and then and reviewing them on main but is that is that about right Yeah exactly. I think, yeah, that's why I drew this this, this, this curve, right? Because that, this, this basically describes my journey of you know, when I started, barely could use a couple 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? obviously, you know, as a, as engineer you don't want to just slop code into production So how do you actually build up that trust takes a lot of I guess taste and judgment but
31:01you know like I think plugins like Pstack definitely can help you get up to speed much quicker 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 but if you don't trust me and I I definitely would not encourage people to blindly trust me you know if you build up your own set of skills that you can obviously you know take a look at PSAT and kind of fork it make it your own improve the skills definitely encourage that but for me it's really all about it it just keeps coming back to trust you know every one of us here in this chat have a different standard for engineering and there are different things that are important for us in our code base and when you are able to encode all of that into skills and you can verify that your agent Actually doing them That allows you to really kind of ascend this curve and you know, start automating things there's another piece I wanted to talk about if there's. Yeah, go for it
32:07 · Rewrites, Human Slop, and Greenfield Risk
32:07I'll I'll pick up more questions as I go But yeah. I think there's a 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 I guess most controversial one of the most controversial topics in the industry I think is like should you rewrite your app or not 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 oh man this is shit 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, and I guess arguably even now people will definitely discourage you from re-rewriting stuff But I'm actually here to make a case for why you might want to consider it because I think it really depends you know brownfield applications I think are actually in a pretty good spot especially if they're set up well already and like recently I've been talking to some people but, you know, I I was just observing I I just noticed this parallel which is that a lot of big tech company problems are now everybody's problems 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 and shipping code And A lot of really great engineers at Meta but, I'll say like, you know you'll be surprised that the code quality is actually not that good and so, I often joke that like you know, before AI slop, we had human slop and so, you know I think a lot of big tech infra like, like what Meta has or Google you know, you know really big tech companies are actually designed for that Where you, you're sort of like you're catering to the the, you know, like, sound, this sounds so bad to say but like the, the least capable engineer on your team 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 there's, 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
34:35the guardrails are already in place for agents to not cause havoc or not cause too much havoc in your code base and you can always add more you know, guardrails but I think like greenfield applications especially are, you know like the brand new applications are like the biggest risk in my opinion, and also the greatest opportunity Because, you know, if you vibe code a project a prototype, like we did for Grokbot you know, Grokbot was spun up very very, very quickly and if you, if you haven't heard of of Grokbot, it's like our a new application we just launched yesterday it's, it's really cool lets you orchestrate your create like individual agents that have their own identity and you can kinda orchestrate them It's super cool. Definitely check it out 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, I had this tweet recently where I said something about organic architecture maybe I'll find it but the idea is that when you have a completely vibe coded application you essentially have no guardrails whatsoever so 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 situation where you have a code base that is spiraling out of control because you don't understand it your agents understand it I guess in a way but like they've built something that is you know optimized for short, for shortcuts and you know, it will, you will suffer you have a lot of of issues with that application so I think starting your codebase with like very strong constraints is very much needed because like when you have a codebase that you can trust right? When you have guardrails that actually help you help your agents, right? Good code You can get into the
36:50you know, like into this part of the curve where I I, where I, like I, I said, you know I woke up today and I had like 20 PRs merged by my agents And that's because I invested a lot a lot of time over 600 PRs I I, I calculated yesterday when I refactored all of Grokbot to this new architecture that I've been building And yeah, I've, I've gotten to a point where I I don't really look I really don't look at the code anymore And, I say that not just you know, to sell you tokens but because it I you know it 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 but I'm very excited because you know the potential where you know it's not just this doesn't just benefit me it benefits everyone contributing to Grokbot and it also empowers you know designers and product managers and you know people even GTM people to add features to Grokbot and I don't have to worry You know I love to, to wake up at night in in the middle of the night and worry like "Oh shit someone's just merged a perf regression." Right? I have a ton of constraints and CI It's like, it's actually very annoying to write code in in GraphQL but like agents absorb all of that annoyance but yeah I'm happy to talk about what exactly that is Yeah, I think one question
38:20Yeah? 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 a, you know, kind of a, a glance It doesn't have to be like mathematically average but just a, you know like what generally the size of the a PR is if it's only a couple lines of code or you know yeah I think it depends on the I'm trying to do this in a way where I'm not gonna like Yeah you don't have to share the actual number Like, the actual average. Just Benchmark But like we have So okay This is not that interesting but well fun fact is that virtualization in Grokbot and in Cursor is actually powered by Pretext which is a sort of new library that someone's built That's really interesting. You should you should check it out But that's not really that important I think the average PR size I actually don't know. I pro- I don't know if I want to click on these 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 so like here I'm actually like deleting a bunch of files So I expect that it's just this like mostly deletion but yeah, it, it kind of varies There's no like yeah. There's no like hard cap or hard limit or they're all like 50 line PRs?
39:53There's no hard cap. There's definitely no hard cap but I I do encourage my agents to split up their work into multiple PRs I do that mostly because 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 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 this it's here. It's not in this 40,000 line PR where who knows what landed in there but yeah I don't have a hard cap on PR size Cool. And then, yeah also quick question on like CI So again, you don't have to go into like the screen share like your your CI does, but just generally w- would you describe what the CI kind of looks like or how strict it is?
40:57 · Dune: Hard Constraints for Agents
40:57yeah. So well, specifically for Grokbot So, Dune is the, is the sort of cheeky code code name for the architecture that we've built for Grokbot the CI looks pretty annoying because there's checks for everything So, like, literally I have, well, if you've written any React for example, you know you know that one of the biggest footguns in React is useEffect so in Dune, and in Grokbot, we've banned use effect So, Dune is just an you can, the, the mental model of what Dune is you can kind of think of it as like Next.js for Electron apps and it's designed for agents to write and it's like custom for you know, our agent-powered applications so the CI checks are very like specific to that Like, you know, don't use use effect It's, it's it's banned. Like, CI will fail 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 which is very interesting 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 like it will often say like you know oh Lauren said you should never do this and it's now in in a code comment like what like why what that 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 agents don't really understand this that well surprisingly 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 so one example that we actually suffer a lot in the agents window is We have you know, you know, if you've used Agents Window you've definitely seen performance issues and you know, we're constantly trying to fix them but it's like a it's a never-ending struggle because there's so many pull requests that get merged
43:10Every any one of them could just regress performance or stability or reliability 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 but, it just reg- That's super often because, there's just one example is like we have very poor isolation between processes 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 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 So very, very small, you know, deadline per frame if you want, you know a very smooth product and when you start building bringing in ex- bringing in you know things that are like very computationally heavy or they have a lot of IO then you just get into like a lot of jank And your, your FPS really drops You start, you know, losing frames You get long tasks that take more than 16 milliseconds and you just get this really choppy experience 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 Grokbot we literally have a directory called electron main electron renderer, and we have, import CI, I guess where we actually check the dependency graph to make sure they're not accidentally importing code from one directory to another so that's enforced by CI as well as bug bot which is our, which cursors like code review tool that runs on CI you know, in our agent's MD It's everywhere. Like, so I, I, I I, I have this thing here where I I talk about like
45:24 · Layers of Enforcement
45:24you know, like there are multiple layers I think, for building a good code base obviously the code base is one where if you have an architecture like this where it's extremely strict 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 So one example of this in Rockbot 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 in a single directory as an example And so all of the code that contributes to that feature lives in one directory So it's all co-located in one place Makes it super easy. You know agents don't have to like wrap 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 Grokbot I'm just gonna work in this directory." And for 80% of the work it's mostly just very encapsulated there But like it's like very it's like design again for you know like the dumbest agent 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 because that plays exactly to how agents love to rank us Like, they like to take shortcuts really You know, they'll they find the quickest way to solve the problem
47:05So why not make that the best way to solve the problem? so I, I I probably won't get into all the specific details and, the, the this framework's really more of a collection of ideas and principles rather than something that will open source you can, you can, you know, screenshot this, I guess, if you want, and tell your agent to do some, build, build something like this for you too yeah, but it's really all about the layers you know, like the the code base is one part with features and directories and, you know, import, blocking import dependencies, that shouldn't be imported but, and, and it all enforces that in static analysis So, like, there's CI checks We have a lot of lint for bad patterns that we observe compiler diagnostics there's also rules in BugBot which are I think like three four, five are more soft right? These two actually f- make Make CI read right? So that, you know there's a hard constraint where the agent can just write crappy code For rules and skills and Bogbot Your agents can still forget right? 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?
48:36And 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 sorry to say that But, I definitely recommend Yeah like, you know, investing in, you know things that can be hard and forced right? And this is why you know, maybe the choice of tech stack that you use is also very important Like I think for example Rust is sort of making you know it's like getting super popular again 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 you can more or less feel somewhat confident that if the code compiles it probably works and it's good by using 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 you know you you rely on code and static analysis to actually make that a lot smoother and I 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 invariance in your code base by literally the human person saying you know reading the code I'm like, okay, you should not do this Right? Every time you have to do that you should consider that as a code smell like a, a anti-pattern And you should say okay, instead of me commenting on the PR how do I turn this into a hard rule?
50:17Right? 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 entirely? I, I can talk about another migration I've done but I'll probably pause here 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 so I have some things to go do after this session in terms of being able to scale my agents I'm, I'm definitely on, like, the you know, maybe a couple of parallel ones locally staged, like two to three locally And I'm sure most people here are on the same So, yeah I know we only have a couple minutes left Lauren, was there anything else that you wanted to to highlight? I, obviously there's lots of questions
51:00 · Token ROI and the Non-Tech Cursor Moment
51:00so I can grab more but I want to give you a few minutes if there's anything else you want to talk about Well, I think I've been yapping for quite a lot so I'm, maybe let's just do questions Okay, cool one question that had a couple of came up a couple of times was just around like, token usage So, the, the question is, like, is is what you're describing a realistic thing for people who are on you know, a a normal set of token usage? They don't have you know, basically unlimited tokens, to work with? Oh, I think that's a really good point I mean, like, obviously, you know I work at a AI lab where we have unlimited tokens So, 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 I think that maybe it's a question of ROI and it's like, yes you spend a lot of money on tokens in the upfront stage You know like refactoring your code base is gonna take a lot of tokens adding all these things is gonna 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 wanna have to hire you don't wanna be you don't wanna become like Meta right? Like, I mean, like, in terms of you don't wanna become a 10,000-person engineering org because I mean that's a cool problem to have But also, you, you have so much overhead There's like planning, you know, like, you, it, it's, it's personally, I, I wouldn't, it, it's not super fun But, I think you wanna stay very nimble right? And you wanna you wanna be, like agents are all about allowing you to do things that you couldn't do before That's really, to me, like, the value of agents You know it's not just storing tokens on every single little thing But, to me, like, the thing I couldn't before is like enforce this level of constraints in a code base by myself Right? Like, I'm just a single person You know it would have taken me years to build this framework and do all the refactoring and test everything myself and verify you know, like run. Imagine if there it was just me right? No, in, in pre-agent era just like running, you know, by my 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 you the dumbest agents can do a good job And when you actually get to this point
53:53like even agents that are not you know fable size do an excellent job of writing code And this pays a lot of dividends as well for me personally where I have empowered not just myself but again, like PMs, designers engineers who are not familiar with Grokbot 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's like free for sure and tokens are pretty expensive but oh actually I I I don't know how many of you have seen this but we actually announced Grok 4.6 today 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 anything 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 SpaceX AI try to really optimize for like that Pareto frontier of you know, cost versus intelligence 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 It it'll 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
55:52and bug fixes, you know, every day Right? Like, that is pretty exciting Cool one last question before we wrap up this one is for the people in product on the on the call So let's say we do have an army of engineers who are shipping like lore in 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, 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 I think this is where Grokbot has been actually exceedingly powerful where, so before Grokbot, like, you know obviously Cursor only had Cursor Like, we only had agent's window We had a CLI. We had an IDE And these are really like, power user tools, right? Like, they, they are designed for developers So, it's very, very developer-centric You can do knowledge work in them but it, like the UI is not really optimized for that So, we actually didn't really have well, I, I think like a lot of people in 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 Grokbot it's become Grokbot is basically like the cursor moment for people who are not in tech in my opinion. Like
57:18it's like, it's like a very very accessible way to use agents in a very comfortable very familiar interface. 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 with in a very like natural way where you can sort of you know each agent's like a person and now you got a team of agents like working on, you have one 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 and then now you know what I did right? So I think our PMs are leveraging that a lot And their shipping code too so you know I 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 that I think that shows that you know the the Dune architecture is holding up right? The all the the really strict constraints allow people who are not experts in engineering to contribute at a high level so I'm I feel like I'm already seeing that pay off a lot where you know designers and PMs are just able to to to ship features directly
58:31and that just makes the Grokbot 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, to ship more, ship more stuff Yeah, that's awesome we, we are at time so, I guess, Lauren, if, if folks want to support you maybe go try out Grokbot try out, 4.6 and you know, get, get, provide some feedback But yeah, this was awesome Really appreciate you taking the time thanks everyone for all the messages in the chat. lots of good questions I know we didn't get through everything but as kind of sort of the top way more questions than than we could get through But, yeah, really, really thanks, thanks for for joining. Thanks everyone for joining and, hopefully you, you enjoyed the session Yep Yeah, I see Thanks for having me. And if you have any more questions yeah, just DM me on Twitter I'll I'll open them up I guess. I'll let the You're going to get a lot of DMs Yeah, I'll open the floodgates So yeah DM me Maybe I'll do like a Twitter space at some point as well for more questions But really appreciate everyone for showing up you know taking an hour out of your day Yeah. All right. Thanks all I'll see you the next one Okay, thanks everyone. Bye
0:00 · Intro: From React Compiler to Cursor
0:00大家好,我是 Lauren Tan——估计没多少人知道我的姓。我在 Twitter 上叫 poteto,就是 potato 把 a 换成 e 的拼法。我加入 Cursor 大约五个月了。之前我在 Meta 的 React 团队,具体做 React Compiler,特别有意思。我现在还在核心团队里,时不时给开源做点贡献,他们还允许我继续做,这点很好。在 Meta 之前我在 Netflix,做过 tech lead,后来转岗做了大约两年的工程经理。所以我在工程管理和独立贡献者(IC)之间来回切换过很多次。我发现一件很有意思的事:管理技能和「管理 agent」之间有特别多的相通之处——这也是我今天想和大家聊的重点之一。嗯,这就是我。我有一些很轻量的 slides,不过不会全程照着念。
1:21我共享一下屏幕,希望别泄露什么不该泄露的——哦不,我得先开屏幕权限。——没事,慢慢来。总是有技术故障,给我一秒重新加入。——好,你弄。从聊天区看你们很多人都认识 Lauren 了,能有这个机会跟她聊聊、过一遍她最近的工作,很让人兴奋。刚才你们也听到了,她从 Netflix 到 Meta,现在在 Cursor。我们还会聊聊 Grokbot,那也很值得期待。不知道你们有没有看到,Cursor 团队刚发布了新品,大概就是昨天或前天的事。可以叫它「人人可用的 Agents」,有兴趣可以去了解。今天我们也会展开聊聊。好,欢迎回来。——Lauren,你静音了,要说话记得开麦。——抱歉。——没事。都 2026 年了我还不会用 Zoom。——哈哈没关系。好,大家应该能看到我的屏幕了吧?
2:54 · The Trust Problem and the Management Analogy
2:54——可以的,没问题。好,今天的大主题是:用 agent 写代码(我相信你们很多人有同样的体验),核心问题就是——你怎么信任它?尤其是如果你是写了很多年代码的工程师,你对怎么做好工程有一堆自己的观点和经验教训。然后你看着 agent 在那儿瞎蒙、猜测、产生幻觉,第一百次信心满满地宣布「找到真凶了」,结果根本不是真正的问题——你的信任就这么被消耗光了。一旦你对 agent 没有信任,就真的没办法把它们的能力发挥出来。对我来说,这和管理很像:如果我是一个团队的工程经理,手下一堆工程师,但我不信任他们,那我的运作模式必然是微观管理——花大量时间盯着下属干活,检查活干得好不好、有没有把 bug 发到生产环境。所以我画了这张图,因为——这张图不太科学,但这就是我使用 agent 历程的写照。往回倒个一年左右,那时候还没什么人用 agent 写代码,你会进入这样一种模式:和一两个、最多一小撮 agent 深度人肉循环,不停地试图搞明白 agent 在干什么。你深度参与每一个环节,盯着每一份输出,坐在那儿不停打 prompt。你没法在这之上再并行,因为
5:07 · The Trust Curve: 1000 PRs and Overnight Auto-Merges
5:07你还是没有那份信任——连一个 agent 的输出都不信,怎么可能一口气开一百个?过去五个月,我觉得自己真正爬上了这条信任曲线。现在我已经到了这一步——说出来有点吓人,而且显得我像个 slop 制造者,但我保证我不是:我的 agent 现在会自动帮我合 PR。这话听着很离谱。今天早上我醒来,已经有 20 个 PR 落进 main 了,我直接在 main 上做的审查——它们已经合进去了,而且质量都很好。那我是怎么走到这一步的?这就是我今天想讲的。对了 Colin,有问题随时打断我。——好的。我得展示这张图了——不,图上写着「不要信任」——还有有人申请远程控制我的电脑,这个大概不行。总之展示这张图不是为了炫耀,而是为了展示这段历程。你可以看到这条曲线,它和我这段时间落进 Cursor 的贡献大体是反向匹配的。我五个月前入职,第一个月产出很低,因为都在学代码库,完全摸不着头脑。
6:47随着我对 agent 越来越有信心,产出也一路爬升。上个月我 ship 了一千个 PR——这数字很夸张——然后这个月,今天才 12 号,我已经合了差不多 800 个 PR,速度确实很快。我敢肯定你们很多人会质疑:这些代码到底有多少是真正的好代码?这个质疑完全合理。但我的观点是:只要把 agent 配置好,你完全能达到类似的水平。接下来我就讲讲怎么做到。
7:35 · Verification Is the #1 Skill
7:35先问问你们的经验。对我来说,与 agent 协作时工具箱里最重要的技能,是验证(verification)。所谓验证,是指 agent 能真正把代码跑起来、抓 CPU trace、打 heap 快照、打开 iOS 模拟器——总之,你的应用以什么方式呈现给用户,agent 就能以同样的方式真实地运行它、测试它、验证它到底工不工作。因为这才是真正把闭环闭上的东西。它不能保证 agent 写出好代码,但至少能保证写出正确的代码——这对建立信任来说已经是一大步。我分享一个 Cursor 内部的例子。在 Cursor 里面……咦,在哪来着?我打开一下,放大到全屏。好,就讲 Cursor 的 Agent Window。
9:09 · Control Glass and the Feature Map
9:09说起来有意思:五个月前入职 Cursor 时,我本来要进的是另一个团队——Cloud Agents 团队。但因为我在 React 上经验很深,而 Agent Window 是个 React 应用,就被拉去支援 Agent Window 的工作。但当时真的没什么现成的 skill 能帮我。Agent Window 一周后就要发布,deadline 极紧。我就坐在那儿想:行吧,我直接打开 Chrome DevTools 的性能面板,抓个trace,自己看懂这个火焰图。要知道那才是我入职的第一周,看着这东西一头雾水。好吧,也不是完全没头绪,但代码库对我来说全新。然后我发现我的agent 也一样懵:我把 trace 下载下来、截图发给它,它就说「嗯,看起来大概是这么回事」,然后斩钉截铁地说「就是这个问题」。我照着修,结果发现根本不是。这个过程非常非常慢。如果你自己做过性能优化,或者用 agent 做开发但没配验证 skill,你就是那个 verifier,你就是瓶颈。你让 agent 干活,它去写代码;你打开本地 dev 构建,发现「咦,不 work」;然后你得复制粘贴截图、console 报错什么的,喂给 agent,它慢慢消化、试图理解、再修。但你始终被摁在循环里当瓶颈,根本没法并行。所以 Control Glass 这个 skill 算是我
11:17最早给 Cursor 建的 skill 之一。顺便说,Glass 是 Agent Window 的内部代号,对外就是 Cursor。这个 skill 本身——代码没什么特别的,你的 agent 很容易就能给你做一个:做 Electron 应用、Web 应用甚至 iOS 应用,都可以教 agent 用 Chrome DevTools 协议,或者用Apple 的工具来跑模拟器、抓 trace、做程序化控制,非常实用。不过我真正想讲的是另一个东西————这是在给我演示吗?——这个 skill 自带一个非常独特的文件,叫 feature map(功能地图)。故事是这样的:我把 skill 建好之后,agent 确实能把 Agent Window 跑起来、抓 trace 了,但它压根不知道 Agent Window 是什么。比如有人说「左边栏好像很卡」或者「右边的 PR 标签页不 work」,agent 就只能瞎扑腾——花大量时间翻代码找这个功能在哪、UI 上怎么进去,基本等于没用。我本地跑起来,它会起一个 dev 构建,然后就原地打转,想点这儿试试,却不知道怎么到达各个功能,体验糟糕透了。——谁在我屏幕上画箭头?
13:21总之,这个 feature map 特别有用:它教会 agent 怎么到达产品里的每一个功能。在我做的 PStack 插件里——Google 搜「PStack cursor」就能找到——有一个 create verification skill,可以帮你给自己搭一套,包括 feature map:它会探索代码库,把这张图建出来,告诉你的 agent怎么到达所有功能。这威力极大,因为用户报告进来之后,哪怕是一段模糊描述甚至一张截图,你都能对上号。比如我们Cursor 内部有个 Slack 频道,一堆人给 Agent Window 和 Grokbot 提反馈,报告质量经常很差,比如有人直接丢一张截图,配三个问号,就这样——这是啥???没有 feature map 的话 agent 也一头雾水。但有了它,agent 就有足够的上下文,知道怎么导航、怎么到达各个功能。举个例子,比如侧边栏——侧边栏是什么?里面有哪些子功能?从用户视角怎么进去?所有键盘快捷键,甚至那个叫什么来着——DOM 元素、通过 CDP 选取元素所用的属性,全都在里面。所以这对 agent 来说真的非常强大。PStack 里 ship 的不只是 create verification skill,还有一个 maintain verification skill,让它保持最新。——正好想问你是怎么创建的,能展开讲讲 PStack 里的过程吗?
15:39 · PStack: Failures Become Skills
15:39顺便给不熟悉的人介绍下 PStack 是什么。——好。PStack 挺有意思的。首先名字挺逗的,P 是 potato 的 P——potato stack。因为有位名人 Gary Tan,Y Combinator 的 CEO,他搞了个插件叫 GStack(Gary Stack)。巧的是我们同姓——完全沾亲不带故——我就觉得拿这个开个玩笑、做个 PStack 当我自己版的插件挺好玩的,只是把内容换成我自己那套工程实践。说实话我一开始根本没打算做 PStack,它就是从一堆 skill 开始长出来的。比如最早是 Control Glass,然后又做了个叫 how 的 skill——同样是在观察 agent 时发现的。早期爬这条信任阶梯时,我全程深度盯梢、对 agent 挑剔到了极点。我会跟它说:这个功能坏了,这是 bug 报告,为什么不 work?
17:04而 agent 经常斩钉截铁地说:「肯定是这个,就是这个问题。」但我去翻它的实际 tool call 记录,发现它根本没读我觉得该读的代码。这让我极度起疑。到那个节点我就想:这个 agent 没法再信了,因为它就是在纯纯地产生幻觉。这种不信任感很容易越积越深,然后你觉得无助——不知道怎么帮 agent 成功。但我再重复一遍,管理类比在这里特别有用:想象你是工程团队的经理,团队里有个工程师代码写得很好,但完全没有业务上下文——五秒钟前刚入职的那种,你怎么让这个人变得高效?答案就是通过 skill。skill 嘛,本质就是 markdown,对吧?但它编码了大量信息和指令,能激发出 agent 的很多智能——Twitter 上有人管这叫「把 agent 拉到另一个隐空间」,说白了就是:LLM 本质在做下一个 token 预测,你先给它一批高质量的开头 token,它就能在更高的空间上做模式匹配,表现得更聪明。这是个很有意思的模型。总之 PStack 是我非常渐进式攒出来的:起点就是观察 agent 的各种失败模式,每看到一种,我就说:行,这事儿变成一个 skill。比如「别幻觉」「真的去把代码翻出来读」「多用 sub-agent」「别瞎猜」。——有道理。
19:17我——替自己和聊天区的一堆人追问一下,问题有两部分。第一,这些 skill 怎么维护?产品一直在变,显然有很多人往这个代码库上 ship 代码,skill 怎么跟着更新?第二,你怎么知道你的验证够不够好?——就是你怎么信任自己搭的验证闭环、信任它吐出来的结果?——好,这两块我可能——我想想,先从第一个讲吧:怎么维护 skill。
19:58 · Evals: Unit-Testing Your Skills
19:58如果你们不熟悉这个概念——eval,我心智模型里它就是给 agent 写的单元测试。你完全可以自己做 eval,不需要什么特殊框架,想做多科学多严谨都行。——我屏幕怎么红了?——有个小按钮,抱歉。——是涂鸦?要关掉画笔吗?——我看不到自己屏幕了。——抱歉,麻烦大家别在屏幕上画画。——在下拉菜单里。——好了,行了。——完美,继续。对,eval 就是给你的 skill 做单元测试的手段。实际上 PStack 在 Potato Mode 下还 ship 了一个 playbook,搜「eval playbook」就能找到。这套做法相当严谨:我开一大堆不同的 sub-agent,让主协调 agent 先给这个 skill 拟一份 rubric(评分标准),然后由它把 sub-agent 拉起来,给每个建独立目录——目录名会巧妙伪装,不让 sub-agent 察觉自己正在被评测。因为 agent 真的能察觉,一旦察觉,它们就会改变行为。总之用这类手段来测:我正在做或正在改的 skill,到底是不是按我以为的方式在工作。Cursor 还有个很大的优势:我们支持非常多不同的模型,所以你可以让同一个 skill 在一整个模型矩阵上跑 eval,看它在不同模型上的表现——尤其是你自己常用的那几个。
22:15这事我做得非常勤,每次改 skill 都会跑一遍 eval playbook,确认结果真的是我要的。但我得说,维护 skill 其实挺难的,非常考验品味和观察力。你得是一个很好的「后座司机」,懂我意思吗?就像结对编程时你看同事写代码,心里想「换我肯定这么写」「你这儿为什么不那样处理」——你不停向同事发问。跟这儿是一回事:你不能只当 agent 的被动旁观者。在积累自己那套 skill 的初期,你要牢牢坐在驾驶位上——当然可以直接用 PStack,但如果自建,很重要的一点是打开所有 tool call,去读代码、读 agent 的行为和思考块,这是发现它们在哪失败的最佳方式。然后你就可以针对性建一个skill。至于怎么信任验证本身——也是类似的迭代闭环,我对「验证 skill」本身也做了同样的验证。
23:47eval 有个很有意思的特性:可以爬山优化。你的 eval 可以产出一个分数,对吧?分数可以让协调 agent 来打,但你还应该再拉一个不同模型的 judge agent 交叉核对,确认第一个模型没有偏袒——就是那个给所有 sub-agent打分的模型。在此基础上还能爬山:在 Cursor 里用 /loop,跟它说「在这个 eval 上一直循环,直到全部 10 分」,Control skill 我用的基本就是这套方法,全程其实相当放手。我就是这么把这个 skill 连同里面的 CLI 一起建出来的,随着时间推移它变得非常好用。当然一开始绝不是这个水准,迭代了很多轮。这里有个类比——后面在另一张 slide 上我还会画——现在做工程师,你更像一个经理。或者用我喜欢的类比:你是餐厅的主厨,不再亲自炒每一道菜,你手下有一整个厨师团队——普通厨师、副主厨、各个工位。你的职责是设计环境:把厨房搭好,把任务分派给不同的人。
25:37这是一种很有意思的工作方式,我的验证 skill 基本就是这么建出来的。——我再追问深一层。假设我们要给某件事建一个 eval 或 skill,还想让它自己变得越来越好——你说的就是这个意思吧——那是在 worktree 之类的隔离环境里、用 sub-agent 跑吗?再加上 reviewer agent 那一套?还是跑在某种云端托管环境里?实操步骤到底是什么?如果我想现在就动手给自己搭一套验证系统,从哪儿开始?
26:25 · Start Local, Then Cloud Agents and Benny
26:25我认为最好的起点是本地,因为在本地你能观察——真真切切看到 agent 在干什么。给自己建验证 skill 的话,一定从本地开始:让 agent 把应用拉起来,不管是 CLI 还是桌面应用,你都能观察它怎么跟应用交互、怎么调用各种API 去操作应用。但对我个人来说,我基本已经大部分 all in 在 Cloud Agents 上了,因为它们实在太强。Cursor 真正强大的地方在于:只要前期花点时间把环境配好,这些控制 skill、验证 skill 的回报极其丰厚。它不只是让你一个工程师变强,而是把整个团队甚至整个公司都抬升一个层级——你可以开始考虑云上 agent 编排、考虑全自动执行的自动化。这个我后面还会讲,这里先剧透一个例子:我们有个 agent 叫 Benny,它接走我们收到的所有 bug 报告,自动到云端开出自己的桌面,在自己那台电脑上跑 Cursor,用同一套控制 skill 去操作应用,尝试复现这个 bug 或用户报告。这威力巨大,因为一瞬间我就能自动拿到大量信息。比如这个例子:Benny 真的复现了 bug,但发现 main 上已经修了——等于确认我们已经修掉了这个问题,我要做的只是再发一版 Cursor 而已。这信息太值钱了:我不用再陪一个 agent 坐一小时,掰扯「到底修没修」。
28:49省下的时间非常可观,而且我团队、公司里的每个人都受益。所以用 Claudians(云上 Claude agent)真的威力无穷,但说到底这是一段旅程,你得先建立信任,才能走到这一步。这又绕回我前面说的:如果你还停留在低信任区间,几乎不可能、我也强烈建议别直接跳到「现在就开一百个、一千个 agent」——那纯属浪费 token,贵得离谱。——好,小结一下:如果想走完这段旅程,就是从验证起步:建一些 skill 和一些手段,确认 agent 至少产出正确的代码——好不好另说,但技术上确实解决了问题,判断依据是看stack trace、看应用里的真实行为等等。等本地建立信任后,再考虑扩到云端、跑更多 agent,让它们自主接活——bug 报告进来就自己认领——把问题解决掉、交回一个 PR。我想最后一步大概就是让 PR 自动合流——你现在就在这一步,也是我还没到的一步——然后直接在 main 上审查。对吧?——完全正确。所以我才画了这条曲线,因为它就是我这段历程的写照:刚起步时勉强同时用几个 agent,事事亲盯。从那一端走到这一端,我认为没有捷径,因为这本质上是你个人对 agent 的信任程度。显然,作为工程师你不会想把 slop 代码直接灌进生产。所以怎么建立这份信任?很吃品味和判断力。
31:01不过 PStack 这类插件确实能帮你快很多地上道。说白了就是:如果你信任我、信任 PStack,那大概可以延伸着信任你的 agent;但如果你不信任我——我也绝不鼓励任何人盲目信任我——你可以自己攒一套 skill,或者看看 PStack、fork 掉、改成你自己的、继续改进,这个我百分百鼓励。对我来说,一切归根结底还是信任。聊天区里每个人对工程的标准都不一样,各自看重的东西也不一样。而当你能把这一切都编码进skill、还能验证 agent 真的照做时,你就能爬上这条曲线,开始搞自动化。——我还想讲另一块。——请讲。
32:07 · Rewrites, Human Slop, and Greenfield Risk
32:07我边讲边收问题。其实还有第三部分没讲,挺有意思的:重构和重写。这大概是行业里最有争议的话题之一:到底该不该重写你的应用。工程师特别容易犯这毛病——尤其刚入职一家公司,看到代码库就倒吸凉气:我的天,这写的什么玩意儿?谁写的?太烂了,我想全部重写。这种冲动非常普遍。在 agent 出现之前——甚至可以说现在也是——大多数人都会劝你别重写。但我今天恰恰要为重写讲几句好话,因为真的要视情况而定。存量(brownfield)应用的处境其实相当好,尤其是本身搭得就比较规范的。最近我跟一些人聊过,也是在这个过程中我注意到一个平行现象:很多大厂的问题,现在成了所有人的问题。大厂的问题是这样的,比如我在 Meta 时,我们有一个巨型 monorepo,成千上万的工程师在上面敲键盘、疯狂 ship 代码。Meta 有很多非常优秀的工程师,但我得说,代码质量其实没那么好,说出来你会吃惊。所以我经常开玩笑:AI slop 之前,我们早就有 human slop 了。我认为很多大厂基建,比如 Meta 和 Google 的,本来就是为这个设计的——说难听点,你在伺候团队里能力最弱的那位工程师。你建框架、建规范、建护栏,限制凭证权限,免得实习生把生产数据库一锅端。如果你的基建已经有这个水平,那你的 agent 其实已经能干得相当漂亮了,因为
34:35防止 agent 在代码库里大闹天宫的护栏已经就位,而且你随时可以加更多。但全新(greenfield)的应用,我认为风险最大,同时也是最大的机会。比如你用 vibe coding 拉一个原型——我们做 Grokbot 就是这么干的,它被极其快速地拉了出来。如果你还没听说过 Grokbot,它是我们昨天刚发布的新应用,真的很酷:你可以创建有自己身份的独立 agent,还能编排它们。超级好玩,强烈推荐去看看。它是一个非常——典型的 greenfield 应用,和大多数原型一样,vibe coding 极速堆出来的,人类根本没读过代码。我最近发了条推,讲「有机架构」(organic architecture)——大概能翻出来。核心意思是:一个纯 vibe coding 出来的应用,等于没有任何护栏。你给 agent 一个任务,它就会用最顺手的方式解决。时间一长,代码库就螺旋式失控——因为你不理解它;agent 勉强算理解,但它们造出来的是为捷径优化的东西,之后你会吃尽苦头,一堆问题层出不穷。所以我认为,起步时就给代码库配上极强的约束非常有必要。因为当你有一个可以信任的代码库、有真正帮得上 agent 的护栏、代码质量过关,你就能进入
36:50曲线的另一端——就是我说的,早上一醒来 agent 已经合了 20 个 PR。这背后是我砸了巨量时间,超过 600 个 PR。这是昨天算的——我把整个 Grokbot 重构到了我一直在打磨的新架构上。是的,我已经到了基本不看代码、真的不看代码的地步。说这话不是为了卖你 token,而是走到这一步真的很费工夫——我烧了大量 token 才把代码库调教到不用再亲自看。但我特别兴奋,因为这不只让我一个人受益:每个给 Grokbot 贡献代码的人、设计师、产品经理、甚至 GTM 的同事,都能往上加功能。而我不用再半夜惊醒、担心「糟了,有人合了个性能回归进来」。我有一大堆约束和 CI。用 GraphQL 写代码其实烦得要死,但 agent 把这些烦全吸收了。——乐意展开讲讲。——我有个问题。
38:20在进入这部分之前,先问下你的 CI 长什么样、有哪些约束,还有平均 PR 大小——之前聊天区有人问。给大家一个直观感受就行,不用数学意义上的精确平均。PR 一般多大?是几行的那种还是……——这个得看情况,我尽量挑个不涉密的角度说。——你不用给具体数字,给个量级就行。——好,说个不算太有意思的花絮:Grokbot 和Cursor 的虚拟化其实是用一个叫 Pretext 的新库驱动的,挺有意思,你们可以去看看。不过这不重要。PR 平均大小的话——我还真不知道。这些我不确定要不要点开,应该可以吧。我的感受是:小到 50 行,大到上千行都有,取决于任务本身。比如这里我其实在删一堆文件,所以这条基本全是删除。总之大小很浮动。——没有硬上限?不会都是 50 行的小 PR 吧?
39:53没有硬上限,绝对没有。不过我确实会鼓励 agent 把工作拆成多个 PR,主要是因为——在 agent 时代提交多得数不清,但我还是看重这个理念:Git 历史是极丰富的上下文来源,我希望每个 PR 都原子化地描述那一小块改动。这也让回滚和定位更容易:哦,我 ship 了个 bug,就是它,就在这儿——而不是藏在一个四万行的巨型 PR 里天知道落了什么进去。总之 PR 大小我没有硬上限。好,再快速问下 CI。不用对着屏幕讲细节,大致描述下你们的 CI 长什么样、有多严格就行。
40:57 · Dune: Hard Constraints for Agents
40:57好,就说 Grokbot 的。Dune 是我们给 Grokbot 搭的这套架构的诨名。CI 相当「烦人」,因为什么都有检查。比如你只要写过 React 就知道,最大的坑之一就是 useEffect。所以在 Dune 和 Grokbot 里,我们直接禁了 useEffect。Dune 你可以把心智模型理解成「Electron 应用版的 Next.js」:它是为 agent 写代码而设计的,专门服务我们这种 agent 驱动的应用。所以 CI 检查也高度定制:比如不许用 useEffect——直接禁用,用了 CI 就红给你看。还有些更让人挑眉的:我连代码注释都禁了。这个很有意思,因为我发现 99% 的情况下,agent 写的注释都在描述某段历史八卦,跟眼前代码毫无关系。比如经常出现「哦,Lauren 说过千万别这么干」——然后就刻进代码注释里了。拜托,我那句话不是什么永恒的全局规则,我只是说「你这个 PR 这部分不行,改掉」。说来意外,agent 对这种语境的理解很差,再不然就是自作主张,用很蠢的方式干活。所以干脆一刀切:凡是 agent 容易犯蠢的地方,全禁。举个我们深受其苦的例子:Agent Window。用过的人都见过性能问题,我们一直在修,但这是场打不完的仗,因为合进来的 PR 实在太多,
43:10任何一条都可能让性能、稳定性或可靠性倒退。Agent Window 还没有这套架构——我计划把这些经验带回去、整体重构——但回归就是家常便饭。举个例子:我们进程间隔离做得很差。Electron 里渲染 UI 的是 renderer 线程,另外还有 main 线程可以跑别的代码,本不该阻塞 renderer。但我们分得不干净,于是经常有代码不小心被拉到 renderer 线程上跑,突然之间你就开始和renderer 抢资源。想要 60 FPS,每一帧必须在 16 毫秒内画完——每帧的 deadline 极紧,产品才顺滑。可一旦你把计算量很大或 IO 很重的东西塞进来,就会开始卡顿:FPS 掉、丢帧、出现超过 16 毫秒的 long task,体验变得一卡一卡。这些做 Electron 应用踩过的坑,我们全部编码进了框架,变成硬性失败。Grokbot 里是真的有一个目录叫 electron-main、一个叫 electron-renderer,还有「import CI」:检查依赖图,确保两边不会不小心互相 import 代码。这全由 CI 强制执行,再加上 BugBot——Cursor 自家的代码审查工具,跑在 CI 上,还写进了我们的 AGENTS.md。无处不在。我这边专门有一页讲——
45:24 · Layers of Enforcement
45:24建好代码库其实分好几层。首先是架构层:像这样极其严格的架构,让加功能的方式变得非常约定俗成,这是最强的一层约束。因为 agent 特别爱照抄现有模式。Grokbot 里比如我们有 feature 这个概念,还有 entry point、transcript card——就是聊天里那些卡片——这些相当于框架里的「名词」,创建方式高度模板化。比如一个 feature 的全部代码都在同一个目录里。所有为这个 feature 服务的代码共处一地,agent 不用绕着代码库找东西在哪,一看 feature 就明白:「哦,好,我在做 Grokbot 的 onboarding 功能,那我就只在这个目录里干活。」80% 的工作都封闭在这个目录里。这套设计再次是为「最笨的 agent」服务的——不用动脑。我给这套框架定的核心原则之一是:最短路径就是最优路径。因为这正好顺着 agent 的天性——它们就是爱抄近道,永远找最快的问题解法。
47:05既然如此,为什么不让最短路径直接成为最好的解法?细节我不展开——这套框架更像一堆理念和原则的集合,不打算开源。你们可以截图,然后让自己的 agent 照着也搭一套。重点是分层:代码库层是一部分——feature、目录划分、import 边界拦截,全部用静态分析强制执行。所以有 CI 检查,还有一堆针对我们观察到的坏模式的 lint、编译器诊断。另外还有 BugBot 规则——第三四五六层就偏软了。前两层是真正让 CI 变红的硬约束。有了硬约束,agent 才写不了垃圾代码。而 rules、skills、BugBot 这些软层,agent 是会忘的,执行起来也不总是稳定。所以我会分层叠加,但绝不把软层当成唯一防线——因为它们真的太软了。
48:36如果你的代码库只有 rules、BugBot、skills 和风格指南,我跟你讲,它变成彻底的垃圾堆只是时间问题。话糙理不糙。我真心建议你投资那些能硬性强制的东西。这也是为什么技术栈选型非常重要。比如 Rust 现在又火回来了,很大程度上是因为编译器足够严格:它强制约束一大堆东西,还有 borrow checker 要伺候。只要你确保 agent 不写 unsafe 代码块,编译通过约等于代码能 work、质量过关——这种信任让你这个人类工程师不必再亲自检查,你靠代码和静态分析就完成了兜底。最糟的处境是困在「code review 国」:代码库所有约束、所有不变量,全靠一个人类读着代码口头执行。「喂,这里不能这么写」——每当你不得不说这句话,就应该把它当成 code smell、当成反模式:与其在 PR 里留言,不如想想怎么把它变成硬规则?
50:17怎么变成 lint 规则?怎么变成 CI 失败?甚至,怎么把这类问题从根上彻底消灭?我还做过别的迁移,先到这儿。——老实说这就是我现在的位置:这些规则我都还没配齐,今天这场结束后我有好些活要干,才能把 agent 规模化。我现在大概就是本地并行两三个 agent 的水平,估计在场大多数人跟我差不多。Lauren,只剩几分钟了,还有什么想强调的?问题真的很多。
51:00 · Token ROI and the Non-Tech Cursor Moment
51:00——我已经讲了太多,直接进提问吧。——好,一个被问了好几次的问题:token 用量。问题是:你描述的这套,对 token 预算正常的人现实吗?他们可没有基本无限的 token 可烧。这个问题问得特别好。显然我在 AI 实验室上班,token 随便烧,所以我绝不能说每个人都该照搬我的做法。不破产也能走到这一步,是可能的。但如果你是工程负责人或者创业公司领导,那这就变成一个ROI 问题。是的,前期你会烧掉很多 token:重构代码库要烧,加这些约束也要烧。但如果行业正走向 agent 写掉所有代码的世界,你会想保持精简——不想被迫扩招,不想变成 Meta 那样、上万人的工程组织。当然那也算幸福的烦恼,但管理开销巨大:无穷的规划……反正我个人不觉得那有多好玩。你会想保持敏捷,会想——agent 的全部价值就在于让你做到以前做不到的事,而不只是每件小事上省 token。对我来说,以前做不到的事是:靠我一个人,把这种级别的约束灌进一个代码库。我只是一个人。要在前 agent 时代靠自己做——建框架、重构、全部测试、全部验证——得花不知道多少年,而我的工资可不便宜。所以工程负责人真正该问的问题是:到底是招一个人来干这事,还是花 token 把代码库调教到连最笨的 agent 都能干好?而一旦你真到了这一步,
53:53即便不是旗舰级的大模型,agent 也能写出极好的代码。这对我的回报也巨大:被我赋能的不只我自己,还有 PM、设计师、以及不熟悉 Grokbot 的工程师——大家都能以可持续的方式贡献代码。所以这确实是个权衡:天下没有免费的午餐,token 也不便宜。不过说起来——不知道你们看没看到,我们今天刚发布了 Grok 4.6,终于出了,很激动。Grok 4.6 非常非常聪明,benchmark 表现很好,而且 token——但愿我没在泄密——单价和 4.5 一样,等于同样的钱买到更多智能。这是 Cursor 和 xAI 着力优化的方向:成本与智能的帕累托前沿。我们不一定非要做史上最大的模型——那推理起来贵得吓人。关键是找到那个甜点位:你不需要庞然大物,但足够聪明、推理又不贵。总结一下:如果你自己算这笔账,我认为结论是相当正面的——投资这些的 ROI 相当可观:它赋能的不只是你个人,而是让整个团队的生产力大幅跃升。
55:52想象你有一支像我这样的工程师大军,每天 ship 那么多改进和修复——这就很带感了。——收尾前最后一个问题,问给电话会上的产品同学:假设真有这样一支 Lauren 大军在疯狂 ship,你们的产品团队和其他职能是怎么跟上的?他们是不是也在更多用 AI 干活?——量力回答就行,我知道你不在这个岗位,纯粹好奇。——这正是 Grokbot 大显身手的地方。Grokbot 之前,Cursor 就只有 Cursor:只有 Agent Window、CLI 和 IDE,这些都是 power user 工具。为开发者设计、以开发者为中心。知识工作也能做,但 UI 根本没为此优化。所以在那之前,GTM、产品这些同事可能也用 Cursor 干过活,但体验肯定谈不上愉悦。现在有了 Grokbot,在我看来,Grokbot 就是给非科技从业者的「Cursor 时刻」。
57:18它是一种门槛极低的 agent 使用方式,界面舒适又熟悉——长得就像 iMessage,还很好玩。你可以给 agent 起个逗比名字,还能做编排:每个 agent 像一个人,你就有了一支 agent 团队。比如每个客户账号配一个 agent;或者你是 PM,可以让一个 agent 把 Lauren 昨晚干的活全总结一遍,第二天就知道我做了什么。我觉得我们的 PM 在大量这么用。而且他们也在 ship 代码——经常有人跑来说:这儿有个 bug,我修了,你看看?我过去一审,直接就能过,我盖个章就完事。这说明 Dune 架构是真的扛住了。那些极其严格的约束,让非工程专业的人也能高水平地贡献。回报已经肉眼可见:设计师和 PM 能直接 ship 功能。
58:31这让 Grokbot 团队快到飞起——我们能极速 ship,后面还排了一大堆计划,我特别期待继续发发发。太棒了,时间也到了。想支持 Lauren 的话,去试试 Grokbot、试试 4.6,多提反馈。今天非常精彩,真心感谢你抽时间,也谢谢大家的留言。聊天区问题多到问不完,没能全过一遍。真的非常感谢大家参与,希望你们享受这场。谢谢邀请。还有问题的话直接 Twitter DM 我,我把闸门打开。——你 DM 要爆了。——开就开吧,回头也许再搞场 Twitter Space 答疑。真的感谢大家来捧场,抽出宝贵一小时。好,谢谢大家,我们下期见。——好,谢谢各位,拜拜。
Cursor engineer Lauren Tan (formerly React Compiler at Meta, tech lead and EM at Netflix) walks through how she went from learning the codebase to merging 1000 PRs in a month with coding agents. Her core claim: the bottleneck in AI-assisted engineering is not generation but verification — if your agent cannot run the product, take CPU traces and heap snapshots, or reproduce a bug from a screenshot, you remain the serial verifier. She covers the Control Glass skill and feature map that let agents operate and verify Cursor itself; the eval playbook (coordinator rubric, anonymized sub-agents, cross-model judge, /loop hill-climbing) she uses to test skills like code; Benny, the cloud agent that reproduces every incoming bug report; and Dune — a Next.js for Electron apps designed for agents — whose hard constraints (banned useEffect, banned code comments, import CI) let agents auto-merge PRs and even let PMs and designers ship features.
Cursor 工程师 Lauren Tan(前 Meta React Compiler 成员、Netflix tech lead/工程经理)完整拆解了自己如何从熟悉代码库走到一个月合入 1000 个 PR。核心论点:AI 辅助工程的瓶颈不在生成、在验证——agent 不能自己跑产品、抓 CPU trace 和 heap 快照、按截图复现 bug,你就永远是那个串行的 verifier。她依次讲了让 agent 操作和验证 Cursor 本体的 Control Glass skill 与 feature map;像测代码一样测 skill 的 eval playbook(协调者拟 rubric、目录匿名防 agent 察觉、跨模型 judge 交叉打分、/loop 爬山到满分);自动复现所有 bug 报告的云 agent Benny;以及专为 agent 设计的 Dune 架构(Electron 版 Next.js)——靠硬约束(禁 useEffect、禁代码注释、import CI)让 agent 敢于自动合流 PR,甚至 PM 和设计师也能直接 ship 功能。