把 Agent 当成
米其林后厨

Hi, I'm Lauren. You might know me as poteto on X, and I work on Grok Bot at SpaceX AI.

Last month I did something pretty crazy: I shipped a couple thousand pull requests to production. A lot of how I'm able to do this comes down to trust — trusting my agents to produce high-quality work even when I'm not there.

My thesis for this talk is simple: if you set up the environment for your agents really, really well, you end up with something that looks more like a personal — or even team-wide — software factory, producing very high-quality code at a much greater rate than before.

But I'm not a fan of the term “software factory.” I like the analogy of a Michelin kitchen much better.

As technologists, we're not mass-producing a product on an assembly line. The work we do is creative — it's the act of building a product, and in some sense it's art. Even though with agents we're no longer cooking the individual components that go into the product, we're still responsible for the final outcome, and for thinking about how our kitchen is set up.

Depending on how you set up your line cooks, your sous chefs, the equipment they have, the training they get, the dishwashers, and the ratio of line cooks to dishwashers — all of these ingredients go into making the final product. I think that analogy is really apt.

I want to tell a story before we begin. Six months ago, when I first joined Cursor — before we were part of SpaceX AI — I had no agent skills to use. I'd just joined the company; it was a fresh codebase and a fresh product.

At the time, Cursor was building the replacement for the Cursor IDE: the new agents window. Before I joined, it had quite a lot of performance issues, and my manager asked if I could help. Since I'd spent some time on the React team before joining Cursor, it seemed like a good fit.

But when I started, I quickly realized how manual the process was. I'd done performance work before, but at the rate pull requests were landing, it felt like an insurmountable wall of PRs that just kept coming in — and I had no idea whether the app's performance would regress.

A lot of my early time on the Cursor team was spent looking at Chrome DevTools, doing performance traces and taking heap snapshots. It was extremely, extremely manual. It got to the point where I was frustrated and started thinking: wait, we have agents. What am I doing?

So I started thinking about verification skills. What if my agent could run the application itself, take the traces for me, understand them, find the hotspots, and basically hill-climb toward better performance automatically?

Over the last six months at Cursor and SpaceX AI, my productivity has skyrocketed. I never set out to ship thousands of pull requests a month — that was not a goal at all. But I realized that all the skills, tools, and codebase changes I was making laddered up to this idea of trust.

I had this thought in the back of my head: I am the bottleneck. I need to take all the knowledge I have as an engineer and impart it to my team of agents, so that I don't have to be the blocker for everything. And you can clearly see that it's paid off.

So it really comes down to trust. But how exactly do you build that trust, and where do you start?

When I started, I was in the one-to-five-agent range. You still feel like you have to babysit every chat and conversation, constantly course-correcting, intervening so the agent does the right thing. If you're not there, basically nothing happens — or the agent does the wrong thing.

I'd argue this phase is actually the hardest to get out of, because it's not always clear how. Again, it just comes down to trust.

The reason you're unable to go from one-to-five agents to something more like a hundred is that you don't have trust in your agent's work yet. If you don't have trust and you try to spawn a hundred sub-agents or cloud agents, you'll quickly find that you get a ton of slop-filled PRs, a bunch of regressions, and a bunch of bugs shipping. No one's going to be very happy with that.

How do you trust your agents more? For me, it started when I joined the Cursor team and began working on performance, where I realized the need for verification.

Verification has levels. At the lower end are the verification skills I'll talk about: you teach your agent how to run your application, using the Chrome DevTools Protocol or whatever debugging protocol you have, and how to debug, take performance traces, take heap snapshots, and so on.

At the opposite end of the spectrum — much, much harder, and still very much an open question — is formal verification. Maybe you rely on formal methods, or languages like Lean or TLA+, to check that your business-logic invariants always hold, and to formally verify that your application is always in a correct state.

But even if you don't have the ability to run formal methods — and very few people really do — verification skills can get you very far.

When I joined Cursor and started working on the agents window, the first skill I built was called control-glass. It's a verification skill that teaches the agent how to run the application and take traces through the Chrome DevTools Protocol.

The interesting thing — and I iterated my way to this; it didn't start out this way — is that a control or verification skill really has two components.

The first is a CLI. You want your agents to be able to reproducibly run the application, collect traces, and collect empirical evidence that the code is working and that your performance bar is being met. Rather than having agents create scripts every time — scripts that differ between sessions — you create a CLI inside the skill directory, and your agents use it every time. Of course, you have to invest in it and make it good enough to handle all sorts of use cases and run the application correctly.

Another thing that's also really important is the idea of a feature map. We started using these control skills at Cursor, and we quickly realized that a Slack report would come in and a user would post a very vague screenshot — a very small slice of the UI and just three question marks. Agents using our control skills had no idea. They could run the application, but they'd just be guessing at what the user meant.

So I had the idea for a feature map, inspired by a sitemap. It's a form of materialized memory: how exactly does your application work? What features does it have? How does a user reach them — keyboard shortcuts, which DOM elements to click — and what do all those features do? The feature map is stored in the skill itself, in the codebase, as part of the skill directory, and we have an automation that maintains it.

When we combined the CLI and the feature map, we quickly realized this combination was very powerful. Agents could not only reproducibly control the application and take traces, but also understand requests coming from internal and external users. The control and verification skills became more or less critical infrastructure for our team, and we maintain them constantly.

The ability for an agent to verify its own work is extremely powerful, and we've spent a lot of time on that skill. It's very powerful for building trust.

But verification is really about correctness. Correctness to me is: does the feature or the code do what you want it to do? Does the checkout button actually check out the cart? Verification is important for that because you get empirical evidence that the feature works. But it doesn't tell you much about the performance or the code quality of that feature.

That's where you start thinking about skills that teach agents to work like real software engineers.

I've built a plugin called pstack. I'm not going to talk about the plugin too much today, but a lot of its inspiration comes from workflows I've used myself across all sorts of tasks — debugging, feature development, prototyping. There's a whole set of playbooks and skills in pstack that teach your agents to write code the way you want them to.

This is where the more experienced engineers on your team can really contribute: set up a team repository of skills that makes your agents a lot smarter. Combine those skills with verification skills, and agents can verify not just that the work is correct, but that it's high quality. And because of verification, you can collect real performance metrics — real numbers, statistics, and telemetry on how the application performs. That's a really important part to invest in.

Another thing that's really important is refactoring and rewriting your architecture to be more agent-friendly. I almost want to say this is one of the most important things you can do as a software engineering team: if you truly believe agents are going to write all the code in the future, then we need to design our codebases so that they do the right thing by default.

There's a scale or a continuum between the different pieces of building trust. The codebase is really the best form of memory, because agents love to extend existing patterns. I think this is just the nature of how LLMs work: they're more likely to use whatever is in their context window to make changes — and the files the agent reads and opens are part of that context window.

So the codebase is a really important part of this, because agents aren't going to refactor your code in every single PR. They're going to look at what's already there and extend it.

The next level is static analysis: linters, compiler diagnostics, continuous integration. These are guidelines and constraints you can enforce in your codebase. When you correct your agent and find that it keeps making the same mistake, you can add a lint rule — or even better, refactor your codebase so that the mistake becomes categorically impossible.

Then, a step above that, you move from hard constraints to guidance: rules, Bugbot, skills. Agents will mostly use them when they're working, but there's a chance they forget to read a rule, or the person piloting the agent ignores them. They aren't quite as enforceable, but they're an important part of setting up an environment you can trust.

Finally there's the style guide, which is really only enforceable by humans in code review. You could put some of it into rules, Bugbot, and skills, but if you don't, you have a big glaring hole in your review process: humans have to look at every single changed line and remember to comment — and at the rate pull requests come in, that becomes impossible.

I definitely wouldn't recommend relying only on the style guide. It's a good place to start, in terms of seeing what's missing, but you should invest in the other four parts: your codebase, making things categorically impossible through better data structures or algorithms, static analysis, and then layering on rules, Bugbot, and skills.

On the codebase front, in the Grok Bot codebase we've invested in something we call Dune, our agent-friendly framework.

The inspiration came from a lot of the performance issues we were seeing in the Cursor agents window. A lot of lessons came out of that exploration, but the key principle we landed on is this: agents love taking shortcuts. So what if we design the framework such that the shortcut — the easy path — is the right path for agents?

And also a codebase that might be pretty annoying for humans to work in, because it's so locked down in terms of what you can and can't do — but it creates the perfect environment for agents, especially ones that have very minimal context.

Not every contributor to your codebase is going to be an engineer anymore. You can have designers, product managers, CEOs going into the codebase and shipping features. So we really need to think about how we invest in and set up our codebases so that even agents piloted by busy people with not a lot of context can do a good job by default.

Your codebase is a form of memory for agents because they love to extend the existing patterns they see. The reverse is also true: if you have existing anti-patterns, they will spread like a virus.

You have one small workaround, or a comment explaining a workaround, and agents love to copy it. In a matter of a few days or weeks, that workaround has spread everywhere and become a de facto pattern for all agents. That's a really, really bad place to be.

That goes back to why, whenever you're correcting your agents, you should invest time in codebase changes and static analysis, and layer them with good rules, Bugbot, and skills.

Another analogy I like, in addition to the Michelin kitchen, is that your codebase is a garden. Workarounds seem innocent at first, but because agents copy patterns over and over, you quickly end up with a very vibe-coded codebase that's a pain to maintain and has a lot of performance issues.

In my opinion, the perfect agent codebase is so locked down that it's really annoying for humans to write code in, but so conventional and standardized that even innocent-looking patterns are forgotten.

The best example is something that looks very innocent but is actually really bad: agents leaving comments in the code. When I first saw agents doing this, I thought a lot of it was slop, but I also thought it wasn't necessarily a bad thing. As humans, we leave comments when we see edge cases, when we need to make a workaround, or to leave a note to ourselves or a colleague on a particularly tricky part of the codebase.

But what I quickly realized in the Cursor codebase was that agents were using the comments around the code as justification for why they weren't going to solve the actual problem — and instead papered over it with a band-aid or a short-term solution. So in Dune, we made the choice to ban comments, so agents wouldn't copy that pattern and propagate it everywhere.

My pitch is that every team really needs a role I'm calling a gardener. In a real garden, you need someone thinking about the things that creep in and grow where you don't want them — weeds, pests, organic growth. I don't know gardening that well, but you get the idea. Unwanted things creep into your codebase, and you want to nip them in the bud before they propagate everywhere.

A lot of the principles behind Dune center on three things.

First, we want to delete the tech debt we already have, for the reasons I just mentioned.

Second, we want to enforce a single paved path for most blessed patterns. There should be one conventional way to do things, so agents don't have to guess, and there should be enough guidance in the codebase, in CI, and in lint rules to steer agents onto that path.

Third, whenever you see tech debt or bad patterns, your instinct should be: I need to write a lint rule against it. You don't always have to clean it up immediately, because a lint rule at least stops the bleeding. It doesn't solve the problem entirely, but it prevents it from growing.

So I definitely recommend thinking hard about how to guard against anti-patterns so they don't spread like a virus, and then spending time getting your agents to clean them up — so your codebase is constantly in a state you'd be happy for an agent to copy.

I won't go through all the implementation details, but I'll gloss over some interesting parts. Dune is the architecture, the client framework we built to power Grok Bot. We've invested a lot in conventions: where code should live, and how and where code should be imported between places.

In Dune applications there are different concepts. Features are co-located in a single folder. There's an entry point in the React part that works like a route. There are transcript pods that show up in the Grok Bot application. There's a host that runs on the Grok Bot virtual machine. And there's the client that powers the overall Dune application.

We have strict boundaries between these. For example, things that run on the main process — the main thread in Electron — aren't allowed to run on the renderer thread. We keep that separation very intentionally, because of lessons from Cursor's agents window, where code would accidentally get imported into the renderer and slow it down.

On the renderer thread you want the UI to be smooth and performant. You need to make sure there are no long tasks over 16 milliseconds if you want 60 frames per second, or 8 milliseconds if you want 120. The renderer has to be constantly chunking up the work rather than doing it all at once. Dune enforces these boundaries through the import dependency graph.

That's just one example of a pattern that led to really bad performance and that we categorically eliminated through the architecture of Dune.

The core theme here isn't Dune. It's that an agent-friendly framework of your own is very, very powerful: you can encode all the learnings and tribal knowledge of your best engineers. The lesson is to take what used to live in the style guide and in engineers reviewing each other's code and leaving comments, extract that knowledge, and encode it into the framework — into the codebase itself.

The codebase is the memory. It's the materialized snapshot of the state in which you want your agents to extend. You want it so pristine, so great, that the next agent that comes along is very likely to continue that pattern and keep it really, really good.

If you spend enough time on this process, you can really set up a Michelin kitchen or a software factory. You've spent so much time on all these pieces that let you trust your agents — the codebase, lint rules, diagnostics, rules, Bugbot, skills — and these layers come together and provide a lot of trust.

Imagine for a moment you're working in the Grok Bot codebase. It's super locked down — almost impossible to write bad code. Even an agent with very little context, or not a lot of reasoning, can come in and write good code.

Going back to the Michelin analogy: we're setting up our agents and bots with skills and tools, training them, setting up our kitchen in a way that makes sense for them to do the right thing by default. If one of our cooks or dishwashers is constantly tripping over something, we fix it so others don't trip too. A kitchen is a dangerous place; you don't want anyone hurt. It's the same mindset we should have with our codebases: how do we set it up so that even agents without a lot of knowledge can do a good job?

Grok Bot and Cursor play an interesting role together. Grok Bot is really great at providing what I call the outer loop. You can connect it to lots of different connectors — Slack, Datadog, Sentry, PlanetScale, whatever services you use — and aggregate all that information to make really good decisions for itself. Some people call this a company brain. I personally don't think you need anything that sophisticated, because agents are really good at using tools.

If you connect these tools through Grok Bot, and have it automatically kick off things like cloud agents, you'll find you don't really have to invest in a lot of infrastructure to build a software factory. In fact, I'll cross out that term — I don't like it. You can set up this personal Michelin kitchen for yourself through things like Grok Bot routines, which let you subscribe to Slack threads or Sentry alerts and kick things off automatically.

When you combine all of these things — your codebase, your rules, your skills — they compound. Grok Bot can automatically respond to events from the outer loop and kick off cloud agents. You can also set up Cursor automations and use our SDK to set up additional bots that reuse a lot of this agent infrastructure and do much more complicated tasks.

If you've done all this, you get to a point — I have screenshots of some of our automations and agents working on Cursor — where we're automatically reproducing bug reports, automatically opening pull requests, essentially adding a lot of value to the entire team, because all of these things compound.

To close: if you spend a lot of time thinking about all the pieces you need to ascend the trust graph, you get to a place where you can really trust your agents more, parallelize your work, and empower your entire team to build on top of these pieces of infrastructure — every engineer, every builder, extremely productive and able to write high-quality code.

The last thing I want to leave you with is this slide. If there's only one thing you take away from this talk, it should be this: these are the activities that will help you build toward a high-trust environment. Whenever you find yourself correcting and intervening with your agent, think about these five pieces and where the most effective step is in the sequence to make your agent much more trustworthy.

I definitely recommend thinking about it in this order. Either invest the time to make that pattern categorically impossible through your codebase, architecture, and data structures — or start looking at static analysis, and then layer that with rules, Bugbot, and skills.

If you do all of that, and you also spend some time thinking about your code quality in terms of skills, you get to a place where you trust the environment so much that your agents can just be free.

Personally, I've spent a lot of time on Grok Bot's codebase. This is really the secret. Well — it's not really a secret; it's a lot of hard work. I hope you found this talk useful. Please reach out to me on X — my handle is poteto, with an E — and I hope you'll have a lot of fun and success building your own Michelin kitchen. Thanks for watching.