Make the Shortcut the Right Path: Lauren Tan on Trusting Agents
Lauren Tan (@poteto) — Grok Bot, SpaceX AI — talk recorded by Raner, NjoZoUm85x0
Lauren Tan says she shipped 2,000 pull requests last month. That number is hers, from a talk she gave after joining Cursor and then SpaceX AI to work on Grok Bot. She did not set out to hit it. The claim underneath is narrower and more interesting: you cannot scale from babysitting one chat to a hundred agents until the environment makes the easy thing the correct thing. Spawn without that trust and you get slop PRs, regressions, and a team that is not happy.
She is not a disinterested critic. She builds Grok Bot, previously worked on Cursor’s agents window, and is describing infrastructure she wants you to want. Treat the 2,000 as a self-report. Treat the kitchen as the actual argument.
Not a factory. A Michelin line.
She dislikes “software factory.” Assembly lines mass-produce. The work she wants still looks like building a product — creative, closer to art. Agents are no longer cooking every component by hand. Humans are still responsible for the plate. The analogy that fits is a Michelin kitchen: line cooks, sous chefs, equipment, training, dishwashers, the ratio of cooks to dishwashers. Change the setup and you change what comes out, even if you never touch the pan.
Six months earlier she had joined Cursor, before the SpaceX AI combination, with no agent skills and a fresh codebase. Cursor was replacing the IDE with the new agents window. The window had performance problems. Her manager asked her to help. She had been on the React team; it looked like a fit. It did not look like a fit once she saw the landing rate of PRs. She had no idea whether the app was regressing. Early weeks were Chrome DevTools, performance traces, heap snapshots — so manual she got frustrated and asked the obvious question: we have agents, what am I doing?
That is when she started thinking about verification skills: an agent that runs the app, takes the traces, finds the hot spots, and hill-climbs performance without her. She did not know yet that every skill, tool, and codebase change was laddering up to trust. She did know she was the bottleneck, and that the knowledge in her head had to live in a team of agents or she would block everything.
The one-to-five trap
Most people, she said, start in the one-to-five range. You babysit every conversation. You course-correct. If you walk away, nothing useful happens, or the wrong thing happens. That phase is the hardest to leave, because the exit is not obvious. The reason you cannot jump to a hundred sub-agents or cloud agents is not missing prompts. It is missing trust.
Verification has a scale. On the low end: teach the agent to run the application, speak Chrome DevTools Protocol or whatever debug protocol you have, take traces and heap snapshots. On the far end, still an open question and available to almost nobody: formal methods, Lean, TLA+, invariants that stay true. She is not claiming you need the far end. Verification skills, she said, get you very far.
The first skill she built on the agents window was Control Glass. It teaches the agent to run the app and take traces over CDP. It did not start in its final shape. It now has two parts. One is a CLI that lives in the skill directory, so agents do not invent a slightly different script every session. You have to invest in that CLI until it actually handles the use cases. The other is a feature map — a term she coined, sitemap-inspired, materialized memory of how the application works: features, how a user reaches them, keyboard shortcuts, DOM targets, what each feature does. It lives in the skill directory. An automation maintains it.
The map existed because Slack reports arrived as a tiny screenshot and three question marks. Control skills could run the app and still guess. CLI plus feature map meant agents could reproduce traces and interpret internal and external requests. The combination became critical infrastructure the team constantly maintains. An agent that can verify its own work is, in her telling, the thing that makes trust possible.
Verification answers correctness: does the checkout button check out the cart? It does not answer performance or code quality. For that she built a plugin she called Pystack, a collection of skills and playbooks from her own workflows — debugging, feature work, prototyping — that teach agents to write code the way the team wants. Experienced engineers, she said, should fill a team repository of those skills. Combined with verification, agents can collect real numbers, not just a green path through the UI.
Five layers, in order
If you believe agents will write all the code, the codebase has to make the right thing the default. She drew a continuum, and she wants you to climb it in this order whenever you catch yourself correcting an agent.
The codebase is the best memory. Agents extend patterns in context. They will not refactor the world in every PR; they will open files and continue what they see. Static analysis is next: linters, compiler diagnostics, CI. When the agent keeps making the same mistake, add a lint rule — or, better, refactor until the mistake is categorically impossible. Above that, guidance rather than enforcement: rules, Bugbot, skills. Agents mostly use them and sometimes forget; a user piloting the agent can ignore them. Last is the style guide, enforceable only by humans in review. At the PR rates she is talking about, asking humans to remember every comment on every line is already impossible. Start from what reviews keep catching. Do not stop there.
On Grok Bot they invested in Dune, an agent-friendly client framework whose key principle came out of the agents-window performance work: agents love shortcuts. Design the framework so the shortcut is the right path. The resulting codebase may be annoying for humans — locked down about what you can and cannot do — and that is the point. Not every contributor will be an engineer. Designers, PMs, CEOs will ship. An agent with minimal context, piloted by a busy person, still has to do a good job by default.
The reverse of “extend good patterns” is also true. Anti-patterns spread like a virus. One workaround, one comment explaining it, and in days or weeks agents have copied it into a de facto house style. Innocent-looking comments were the example that surprised her. Humans leave comments for edge cases and notes to colleagues. In the Cursor codebase, agents used nearby comments as justification for not solving the problem — a band-aid, a short-term path. Dune banned comments so that pattern could not propagate.
Every team, she argued, needs a gardener. She does not know much about gardening. She knows weeds. Nip them before they copy. Dune’s three principles: delete the tech debt you already have; keep a single paved path for blessed patterns, with enough CI and lint that agents do not guess; and when you see a bad pattern, write a lint rule. You do not always have to clean up immediately. A lint rule stops the bleeding. Then send agents to clean, so the snapshot they will copy is one you would be happy to see copied.
Encode the tribal knowledge in the import graph
Dune is not the lesson. Encoding is. Features live in one folder. There is a React entry point that behaves like a route, transcript cards in the Grok Bot UI, a host on the Grok Bot VM, a client. Strict boundaries: code on Electron’s main process is not allowed on the renderer. They enforce it through the import graph. The lesson came from Cursor’s agents window, where slow code accidentally imported into the renderer. The renderer has to stay chunked: no long tasks over 16 milliseconds if you want 60 fps, 8 milliseconds for 120. That class of footgun is now architecturally gone, not a review comment.
Take what used to live in style guides and in engineers leaving notes on other engineers’ work, and extract it into the framework. The codebase becomes a materialized snapshot of the state you want the next agent to extend. Spend enough time and you get the kitchen: codebase, lint, diagnostics, rules, Bugbot, skills compounding until even a low-context, low-reasoning agent writes acceptable code because it cannot easily write the other kind.
If a cook keeps tripping over something, you fix the floor. You do not lecture the next shift. Same mindset.
Outer loop, then parallelize
Grok Bot and Cursor, in her telling, split inner and outer loop. Grok Bot connects Slack, Datadog, Sentry, PlanetScale, aggregates, decides. Some people call that a company brain. She does not think you need anything that sophisticated; agents are already good at tools. Connect the tools, let Grok Bot auto-kick cloud agents, subscribe routines to Slack threads and Sentry alerts. Cursor automations and the SDK can add more bots on the same agent infra. Screenshots she showed: automatically reproducing bug reports, automatically opening PRs. She presented that as value for the whole team, not a personal leaderboard.
Zoom out and the talk is a trust graph. Correcting and intervening should push you to the cheapest durable layer: make the pattern impossible in architecture and data structures; then static analysis; then rules, Bugbot, skills; plus quality skills so you trust the environment enough that agents can be free. That, she said, is the secret, except it is not a secret. It is a lot of hard work on Grok Bot’s codebase. Reach her on X as poteto — potato with an e. Have fun in your own mission kitchen.