Lauren Tan, an engineer on GrokBot at SpaceXAI, said she’s now running more than 20 agents in parallel. Last month, those systems shipped more than 1,000 pull requests. Her August target: double it.
She also showed a GitHub contribution graph with more than 3,000 PRs across five months. By her telling, agents now take over much of the whole chain themselves: opening pull requests, running checks, and landing code on the main branch, all without her personally walking through every handoff.
Tan put it like this: "I wake up, and 20 PRs are already sitting on the main branch." Then she acknowledged why that sounds like a reason to doubt the quality, and followed it with: "That makes me sound like some kind of mass producer of garbage code. I promise I’m not."
Her setup uses more than 20 GrokBot instances inside pstack, an open-source project she built. She pairs them with /loop, /goal, and /swarm so one agent can take a task end to end: own it, do it, verify it, and submit it.
Tan previously worked at Cursor. Before that, she spent time at Meta and Netflix. At Netflix, she was an engineering manager for two years. She laid out this workflow during a GrokBot team workshop.
From hovering over one agent to trusting 10 to 20 at a time
Tan said AI writing code isn’t the interesting bit anymore. What matters, in her view, is how one person can ship more than 1,000 PRs in a month, push toward 2,000, and not turn the repo into a disaster.
She showed what she called a trust curve. Not science, she said. Just a record of how her own thinking shifted over five months. The vertical axis was trust. The horizontal axis was how many agents she could run at once, from one to thousands.
Looking back a year, she said almost nobody was using agents to write code at scale. The normal pattern was simple: stare at one agent, maybe a few, and inspect every line as it appeared. That did not parallelize. Why would it? There was no trust. If you can’t trust one agent’s output, there’s no road to running 100.
She said anyone who has worked with agents has watched trust collapse. In one example, she filed a bug and asked an agent why a feature wasn’t working. The agent gave a confident explanation. But when she checked the tool-call log, it had never even read the code that actually mattered.
After seeing that a few times, Tan said she reached a blunt conclusion: the agent was guessing, and it didn’t know it was guessing. She compared that to managing people. If you’re an engineering manager and you don’t trust your reports, there’s only one mode left: stand over them and make sure they don’t ship bugs to production.
Tan said that in her two years as an engineering manager at Netflix, and in technical leadership jobs more broadly, she found that a lot of the same methods used to manage people also work for managing agents.
When she joined Cursor five months earlier, her first month was low-output because the codebase was unfamiliar and hard to read. Five months later, she said, she had moved herself from the far left side of that curve into the range where she could run 10 to 20 agents at once.
The first thing that unlocked that wasn’t prompt design. It was verification.
Verification starts by letting the agent see and operate the product
Tan defined verification in plain terms: make the agent actually run the code. That means collecting CPU traces, capturing memory snapshots, opening an iOS simulator, stepping through the same actions a user would take in the product, and then testing and validating by itself.
Without that layer, she said, the human is the real bottleneck. The loop is familiar. You ask the agent to change something. It writes a draft. You open a local build and see it’s wrong. Then you take screenshots, copy console errors, paste them back, wait for it to catch up, and ask for another pass. In that setup, the human becomes what she called a manual conveyor belt. Even one instance is too much work. Parallelism never arrives.
One of the first skills she built after joining Cursor was called control glass. It teaches the agent to use the Chrome DevTools Protocol, boot the app, take screenshots, click around, and read the console on its own.
But that still wasn’t enough. Once the agent could run the application, Tan found it often still didn’t understand what the application actually was.
She gave examples. A user might say the left sidebar was lagging. Or that the PR tab on the right side wasn’t working. Without more structure, the agent could drift around the UI and codebase for a long time and still fail to find where that feature lived or how to reach it.
So she built a file called feature map. It records how each feature is reached from the user’s point of view, what shortcuts are involved, and even which attributes should be used when selecting elements.
Tan said the effect showed up right away. Cursor had an internal Slack channel for user feedback, and a lot of the reports were low quality. Some people posted nothing but a screenshot and three question marks. Even then, with the feature map in place, agents could still trace the problem.
Benny was built to answer bug reports with proof
The next piece was Benny. Tan described Benny as an automated agent she built to receive bug reports in Slack.
It spins up its own cloud machine, runs Cursor there, uses the same control glass skill set, and tries to reproduce the issue by itself.
In one example she shared, Benny replied that it could reproduce the issue on the commit before the fix, and that the issue disappeared after the fix. It also attached a link to the cloud run so anyone could inspect the record.
That mattered because it wasn’t basically saying the bug was probably fixed. It was returning evidence that people could compare directly. Tan said a reply like that saved her the hour she might otherwise burn going back and forth with an agent just to establish what happened.
She also said Benny came before GrokBot. The original goal was simple: she wanted an agent that could fix bug reports while she slept. Later, people kept asking how she built it, and those questions eventually turned into what became GrokBot.
She hides evaluation conditions from agents and brings in another model family to judge
Tan also explained how she tests the skills themselves. Her method is to send out a set of sub-agents to run evaluations in directories with names that do not reveal they are being tested.
The reason, she said, is simple: agents can tell when they’re under evaluation, and once they notice, their behavior changes.
She then assigns another agent from a different model family to act as judge and cross-check the results, so self-review doesn’t skew the score. If the score still isn’t high enough, she keeps iterating with /loop until it reaches 10.
Her takeaway was narrow, but it matters: verification can’t guarantee an agent writes good code, but it can guarantee the code is correct. For her, that’s the base layer of trust.
The shift came from tougher guardrails, not just better models
Tan said she’s willing to let go because the guardrails got tougher, not because the model suddenly became dramatically better.
She poured major effort into the repository itself. Part of that work has been open-sourced as pstack in Cursor’s official plugin repository. GrokBot’s architecture also has an internal codename: Dune. She described it as something like Next.js for Electron applications, built specifically for agent-written code.
The constraints are strict. Developers who know React already know useEffect often turns into a headache. In Dune, useEffect is banned. If it appears, CI goes red.
Comments are banned too. Tan said that in 99% of cases, agent-written comments describe old fragments that aren’t really tied to what the code does. An agent might write something like, Lauren said never do this, when what she had actually meant at the time was that one specific PR was bad and needed revision, not that some eternal rule had been declared.
Her view was blunt: agents don’t understand humans very well, and they love inventing context. If they’re predictably bad at something, she’d rather ban it.
Below that is process isolation. Electron has a renderer thread and a main thread, but she said agents often blur the line and pull code into the renderer when it has no business being there. At 60 frames per second, the frame budget is 16 milliseconds. Heavy computation or too much I/O in the wrong place creates visible lag.
Dune handles that by splitting code into electron main and electron renderer directories. CI then checks the dependency graph, and any improper cross-directory reference fails on the spot.
She connected those controls to a layered model.
- The hardest layer is the repository architecture itself. Agents naturally copy existing patterns, she said, so if the right pattern is the only one available, that’s the one they’ll follow.
- The next layer is CI, lint rules, and compiler diagnostics. Hard constraints. They can turn the build red.
- The softest layer is rules, skills, and code review bots. In her view, agents forget them, skip them, and apply them unevenly.
She said it plainly: "If all you have are rules, bots, skills, and a code style guide, it’s only a matter of time before your codebase turns into a pile of garbage."
The operating philosophy behind the architecture is short: the shortest path is the best path. Since agents will always drift toward the easiest route, that route should be made the correct one.
Tan said she had recently done the math. Refactoring GrokBot into this architecture took more than 600 PRs. A lot of that work, in her account, was paying back technical debt.
GrokBot started as a prototype built through what she called vibe coding. It moved fast. Nobody read the code closely. And once agents were assigned tasks, they naturally picked the easiest route. The result was a codebase that expanded wildly and drifted out of control.
She often jokes that before AI garbage code, there was human garbage code.
At Meta, she said, tens of thousands of engineers shared one giant repository, and the code quality there was not automatically pristine. But the frameworks, conventions, and permission boundaries large companies built for their least experienced engineers turned out to be exactly the guardrails agents need now. Stuff once dismissed as bureaucracy has become an asset. Brand-new greenfield projects look more exposed by comparison.
If the same review comment shows up three times, it should become a failing rule
Where should teams start when adding guardrails? Tan offered a simple test. If you’re typing in code review that something should not be written a certain way, that alone is a code smell.
She said the right next question is how to turn that feedback into a lint rule, a CI failure, or better yet, an architectural decision that makes the mistake impossible in the first place.
Her rule of thumb is direct: if you’ve written the same comment in PR review three times, it should become a rule that can turn the build red.
After 1,000 PRs a month, the engineer becomes the head chef
When Tan was asked what’s left for engineers after this kind of automation, she answered with one word: chef.
She said she no longer has to cook every dish herself. Instead, there are prep stations, second cooks, and multiple burners. Her job shifts toward designing the kitchen, setting up the stations, and assigning the work.
According to Tan, product managers and designers on the GrokBot team now submit code directly. People come to her and say they fixed a bug and want her to take a look. She opens the change, checks that it’s fine, and approves it.
In her view, when someone with no front-end background can land code in main, the important point is not that the person suddenly became a front-end engineer. The point is that a strict, sometimes annoying architecture absorbed the risk.
Automatic merging hasn’t removed the PR step, she said. That process is still there.
So for Tan, the story isn’t that programmers vanish. The role moves up a level. Machines take on more of the execution work, progress tracking, test running, and PR watching. Humans move toward setting goals, designing permissions, and defining acceptance criteria.
What keeps programmers at the table, she said, is shifting from I can write code to I can judge what it means for code to be written correctly.
References and attribution
The references cited in the shared material were:
- https://maven.com/p/e23d9c/how-cursor-turned-ai-agents-into-better-engineers
- https://github.com/cursor/plugins/tree/main/pstack
The article cited by MarsBit said the piece came from the WeChat public account Xinzhiyuan, with ASI Qishilu listed as the author. MarsBit’s page says the story was published on Aug. 31, 2026.