Lots of people want to run 100 agents at once. In this roughly hour-long Maven workshop, Lauren Tan (Cursor) makes a quieter point: if you can’t trust one agent’s output, more agents just means more work for you to check. Her order is verification first, then guardrails in the codebase, then scale. These are my long-form notes on what she covered.
Watch the workshop
Video source: YouTube · shared on X by @0xlangeai · workshop page on Maven.
These notes are based on an auto-generated transcript. Names, product names and numbers may be misheard — check the video before quoting them.
Who Lauren Tan is
Lauren Tan (known online as “Potato”) had been at Cursor for about five months at the time of the workshop. Before that she was on the React team at Meta, working on the React compiler, and earlier spent about two years at Netflix as both a tech lead and an engineering manager. That manager background shapes how she talks about agents.
The real bottleneck is trust
She compares managing agents to managing people. If you don’t trust your team, you micromanage: you check everything because you expect bugs. Agents are the same. When an agent confidently “finds the problem” for the hundredth time and is wrong again, trust drops, and you end up watching every output.
She also frames AI as a pair-programming partner, not a replacement for thinking. It can save time writing code and then cost more time in review. One habit she recommends: have the agent write a spec first, review the spec, then let it build.
Climbing the trust curve
Lauren describes her own path as a “trust curve”. A year earlier she worked with one or a few agents, prompting and checking constantly, with no real parallel work. Over her months at Cursor that changed: some of her agents now merge pull requests on their own. She said she woke up to about 20 merged PRs and reviewed them on main afterwards.
Her first month at Cursor was slow — she was still learning the codebase. As trust grew, so did output: she mentions about 1,000 PRs in one month, and close to 800 by the 12th day of the following month. She is open that raw PR count says nothing about quality; her claim is that the checks didn’t disappear, they moved into the system.
Verification is the key skill
The skill she ranks highest is verification: the agent should be able to use the app the way users do. Run it for real, take CPU traces or heap snapshots, open an iOS simulator, walk through key flows. That doesn’t guarantee beautiful code, but it pushes the agent toward correct code.
Without it, you become the verifier and the bottleneck. You ask for a change, the agent writes code, you run it, something breaks, you paste screenshots and console errors back, and repeat. Nothing runs in parallel because everything waits on you.
Her example is Cursor’s agent window. When she joined, it was a React app with little tooling and a tight launch deadline. She’d take Chrome DevTools traces, hand them to the agent, and get confident but wrong guesses about the cause.
Two things she built in response:
- Control Glass: a skill that teaches the agent to drive the app — Chrome DevTools Protocol for web and Electron, Apple’s tools for the iOS simulator, plus scripts. The code isn’t fancy; the repeatable process is the point.
- A feature map: a file that describes, from the user’s point of view, where each feature lives, its sub-features, keyboard shortcuts and DOM selectors. With it, even a vague bug report (“left sidebar is laggy”, or a screenshot with three question marks) can be tied to the right part of the app.
P-Stack: turning failures into skills
These pieces grew into P-Stack, a plugin for Cursor (“P” for potato, a joke on Garry Tan’s GStack). It ships skills to create a verification skill and feature map for your codebase, and to keep them up to date as the app changes.
Lauren built it incrementally by watching agents fail. In one case an agent confidently blamed a component without ever reading the code it touched — she only noticed by opening its tool calls. That became a rule: stop guessing, read the code. Others followed: actually search the codebase, use subagents, don’t claim a fix you haven’t verified.
Her management analogy: treat the agent like a strong engineer hired five seconds ago with zero business context. A skill is just Markdown, but it is how you hand that person the context they lack.
Testing skills with evals
How do you know a skill still works after the product changes? Lauren treats evals as unit tests for agents, and says you don’t need a special framework.
Her playbook: a coordinator agent writes a rubric for what the skill should do, then launches sub-agents in neutrally named folders so they don’t realise they’re being tested (agents can behave differently when they know). The coordinator scores the results. Because Cursor supports many models, she runs the same eval across a model matrix, and reruns it every time a skill changes — sometimes looping until results hit 10 out of 10.
Her other advice is to be a “backseat driver”: open the tool calls and read why the agent did what it did, instead of judging only the final answer.
Turn review comments into hard rules
If you keep leaving the same review comment, you’re acting as a human linter. Lauren’s suggestion: treat every repeated comment as a smell, and ask how to turn it into a lint rule, a CI failure, or a structure where the bad pattern can’t exist.
Examples she gives from the Grok Bot codebase, built on a framework called Dune:
- React
useEffectis banned; CI fails if it appears. - Code comments are banned, because agents keep writing stale history like “Lauren said never to do this.”
- Electron main-process and renderer code live in separate folders, and a CI import check stops heavy work from sneaking into the UI thread — which is what causes dropped frames and jank.
- Each feature lives in one folder, so the shortest path is also the right path. Agents like shortcuts; the framework makes the shortcut correct.
She describes this as layers. Written rules, skills and style guides are soft — agents forget them. Static analysis and red CI are hard. She also points out why strict languages like Rust are popular with agent-heavy teams: if it compiles, a lot has already been checked.
Is it worth the tokens?
Someone asked whether this is realistic on a normal budget. Lauren acknowledges she works somewhere with effectively unlimited tokens, and that the Grok Bot refactor took 600+ PRs. She frames it as an ROI question: the up-front cost is real, but once the codebase is strict, even non-frontier models write good code there, and the alternative would have been years of manual work.
Start local, then go cloud
Her advice is to begin on your own machine, where you can watch what the agent does. Once that’s reliable, cloud agents can pick up signals on their own. Her example is Benny, an agent that takes incoming bug reports, opens Cursor in the cloud and tries to reproduce them — once finding the fix was already on main, saving someone an hour.
Not just for engineers
With these guardrails in place, PMs and designers on her team file bugs, have an agent fix them, and send the PR to an engineer for review. Lauren sees that as the test of the architecture: people who aren’t engineering specialists can contribute without the codebase degrading.
My take
I run YepSoso mostly on my own, so “100 agents” isn’t my problem. What sticks is the order: make one agent’s work checkable first. For me that means writing down how I’ll check a change before I ask for it, and every time I repeat the same correction, asking whether a script or check could catch it instead. I wrote about the same idea in feedback loops and asking AI better questions.
Related reading
- Feedback loops
- How to ask AI better questions
- Personal AI agent vs chatbot: what’s the difference?
- How Kimi’s founder scales AI with agent swarms
- Want notes like these from any video? Try the YepSoso subtitle tool.