Grok Bot in Practice: Lauren Tan's Methodology for Autonomous AI Code Delivery

From "Manual Verification" to "Waking Up to 20 Merged PRs"

Cursor engineer Lauren Tan opened her talk with a scenario that excites and unnerves many engineers in equal measure: she woke up one morning to find that her agent had automatically merged about 20 PRs, all of decent quality. Last month she personally merged around 1,000 PRs; this month, by the 12th, she was already approaching 800.

This sounds like the extreme case of an "AI slop-code factory," but her core argument is the opposite: high velocity depends first on building trust in the agent, and trust comes from verifiable engineering constraints. She compares this path to engineering management—if you don't trust the engineers on your team, you can only micromanage, watching everyone's screen; only once trust is established can you truly parallelize and hand work off to more executors.

This "trust curve" almost inversely tracks her contribution volume over five months at Cursor: when she first joined, unfamiliar with the codebase and distrustful of the agent, her output was low; only as verification capabilities and the constraint system matured did output climb rapidly.

Verification Is the Most Important Fundamental Skill

Lauren believes the most critical skill when working with agents is verification: enabling the agent to actually run code, capture CPU traces, generate heap snapshots, launch the iOS simulator, and test in every way a user touches the product.

Verification can't guarantee the agent writes "good code," but it can guarantee it writes "correct code"—the precondition for trust. She illustrated the cost of missing verification with her own experience: in her first week at Cursor she was pulled into performance optimization for the agent window, manually opening Chrome DevTools to capture traces and read flame graphs, then sending screenshots to the agent. Each time the agent "confidently" pointed to the problem, but after the fix it turned out that wasn't the cause at all.

Without a verification skill, the human is the verifier and the bottleneck of the entire process. You have the agent write code, then open the local dev build yourself to check, then copy screenshots and console errors back to the agent, looping endlessly—this can't possibly be parallelized, let alone scaled to dozens or hundreds of agents.

Chrome DevTools Protocol (CDP) is a set of low-level debugging interfaces exposed by Chromium browsers, allowing programs to control the browser, inspect the DOM, capture performance traces, simulate user input, and more. In agent collaboration scenarios, CDP lets agents open DevTools, record performance profiles, and read console errors just like human developers—without manual screenshot forwarding. Similarly, Apple's simulator tools (such as xcrun simctl) let agents launch the iOS simulator, install apps, take screenshots, and inject events. These interfaces turn verification actions that once depended on human eyes and hands into tools agents can call—the technical foundation for building automated verification skills.

Two Key Skills: Controlling the App + a Feature Map

Lauren built the first control-type skill for Cursor's internal agent window, codenamed Glass: teaching the agent to programmatically control the app and capture traces via the Chrome DevTools Protocol or Apple's simulator tools.

But being able to control the app wasn't enough. Although the agent could launch the dev build, it didn't know what "left sidebar" referred to or how to navigate to a given feature in the UI, so it just clicked around randomly. So she introduced a feature map: a file telling the agent how to reach every feature, including user-facing entry points, keyboard shortcuts, and even the DOM attributes used to select elements via CDP.

This combination is powerful in real workflows. Cursor has an internal Slack channel for collecting feedback, and many reports are terrible—a screenshot and three question marks. With the feature map, the agent can map vague reports to specific feature modules and actually reproduce the problem.

She packaged these capabilities into a plugin called PStack (a playful nod to GStack, named after Y Combinator CEO Gary Tan—same surname, no relation). PStack provides the ability to create and continuously maintain verification skills, and can automatically explore the codebase to generate an initial feature map.

Testing Skills with Evals, Like Unit Tests

A skill is essentially a markdown file carrying instructions and context. Lauren quotes the community: giving the agent a high-quality token opening is like "pulling it into a smarter latent space" for pattern matching.

But skills go stale as the product evolves, so you need evals. Her mental model is "an eval is a unit test for the agent," and the eval playbook in PStack is quite rigorous: a main orchestrator agent first produces a scoring rubric, then spawns multiple sub-agents to execute tasks in their own directories, with directory names deliberately chosen so sub-agents don't realize they're being evaluated—because once an agent notices, its behavior changes.

One clever touch is leveraging Cursor's multi-model support to evaluate the same skill across a matrix of different models. Judge agents from different models can cross-check to avoid scoring bias. Going further, /loop can keep the eval cycling uphill until everything reaches a perfect score.

She admits maintaining skills is hard and requires a lot of "taste and observation"—you have to keep probing like sitting next to a colleague during pair programming, rather than being a passive observer. Turn on all tool calls and read the agent's thinking blocks to discover where it cuts corners and where it guesses.

Latent space is the high-dimensional vector space of a neural network's internal representations. During generation, input tokens map to a region of that space, and subsequent outputs are pattern-matched from there. Giving the agent high-quality instructions and context (such as carefully written skill markdown) steers it toward regions where better patterns from the training data reside, improving output quality. That's the meaning of the "pull the agent into a smarter latent space" metaphor—the model itself doesn't get smarter; the input distribution activates more reliable generation paths.

LLM-as-a-judge refers to using another large model to score or compare target outputs, replacing human evaluation. In evals, a judge agent scores according to a rubric. To avoid a single model's preference bias, different models can cross-check, taking consensus or an average. Note that the judge itself may have position bias, verbosity preference, and other issues, so rubric design and judge calibration matter just as much.

Cloud Agents and Auto-Merge: The Leverage of Trust

The value of verification skills goes beyond personal efficiency. Lauren has largely shifted to cloud agents, because cloud agents amplify individual capability across the whole team.

She gives the example of an internal agent called "Benny": Benny receives all bug reports, runs Cursor in an isolated desktop environment in the cloud, and uses the same control skills to operate the app and reproduce issues. Once Benny successfully reproduced a bug and simultaneously found it was already fixed on the current branch, so all that was needed was another build—a conclusion that would otherwise have required a human to sit down and spend an hour confirming.

On pacing, she lays out a clear path: first build verification capability locally and observe how the agent interacts with the app; once trust is established, expand to cloud agents and automation; only then let agents auto-merge PRs and do post-hoc review on main yourself. She specifically warns against skipping stages—spawning hundreds of cloud agents before trust in a single agent is established only wastes enormous tokens at high cost.

Refactoring and "Organic Architecture": Constraints Are Productivity

Lauren offers a counterintuitive view: brownfield apps are actually in an advantageous position, while greenfield apps carry the most risk.

Big-company infrastructure is designed for "the least capable engineer on the team"—frameworks, conventions, guardrails, credential restrictions—all meant to prevent an intern from wiping the production database. These constraints work just as well, even better, for agents, because agents are extremely good at imitating existing patterns.

The real danger comes from prototypes built through vibe coding. Grok Bot is a typical case: rapidly assembled in a very short time, with humans barely reading the code. She calls this "organic architecture"—the agent always chooses the easiest way to solve a problem, and over time the codebase spirals out of control because no one truly understands it.

Her solution was to build an architecture called Dune for Grok Bot—think "Next.js for Electron apps"—designed specifically for agents to write. The core idea is making the shortest path exactly the best path: since agents love shortcuts, design the correct approach to be the shortcut.

Specific constraints include:

• All code for each feature lives in a single directory, with 80% of work completed within the encapsulated scope
• useEffect is banned—React's biggest foot gun—and CI fails immediately
• Code comments are banned—she found that 99% of the time, comments written by the agent describe irrelevant historical information, or even treat a temporary review comment as a permanent rule
• Imports between the ElectronMain and ElectronRenderer directories are blocked by CI checks on the dependency graph, preventing compute- or IO-intensive code from accidentally running on the render thread and eating into the 16ms frame budget
• Extensive lint, compiler diagnostics, and BugBot rules configured for known bad patterns

Brownfield and greenfield are metaphors from software engineering: brownfield means continuing development on an existing codebase, greenfield means a new project from scratch. Conventional wisdom holds that greenfield is more flexible and less risky, but in the agent collaboration context, brownfield projects come with years of accumulated architectural conventions, CI pipelines, lint rules, and permission constraints—these "guardrails" effectively limit an agent's free rein, actually reducing the risk of losing control. Greenfield projects lack these constraints, so agents tend to adopt the most convenient but unsustainable solutions, rapidly accumulating technical debt.

Vibe coding refers to a way of building software where developers barely read the generated code and drive AI purely through natural-language descriptions and runtime results. It's suitable for prototyping, but if used for long-term maintained products, the lack of human understanding and architectural constraints leads to "organic architecture"—code growing freely like an organism until no one can grasp the whole.

Layered Constraints: Hard Rules Beat Soft Rules

Lauren stresses that constraints are layered, with vastly different reliability.

The hardest layer is the codebase architecture itself—the established way of building things, since agents love to copy existing patterns—along with "hard failure" mechanisms like CI, lint, compiler diagnostics, and import blocking.

Softer are guidance-type constraints like rules, skills, and BugBot. They help, but agents may forget them or apply them inconsistently. Her judgment is blunt: with only rules, skills, and style guides, it's only a matter of time before the codebase turns to garbage.

She offers an actionable guideline: every time you tell someone in a PR comment "this shouldn't be written this way," treat it as a code smell—ask yourself whether you can turn that comment into a lint rule, a CI failure, or an architectural elimination of the problem altogether.

This also explains why she values the tech stack choice: the Rust compiler is strict and has a borrow checker; as long as you ensure the agent doesn't write unsafe blocks, a successful compile gives considerable confidence—the very confidence that lets you stop reviewing line by line yourself.

The borrow checker is part of the Rust compiler that statically checks reference ownership and lifetimes at compile time, ensuring memory safety with no data races. It forces developers to be explicit about resource ownership and rejects code with potential aliasing or dangling references. For agents, the borrow checker is an extremely hard failure gate: if it compiles, a large class of memory-safety and concurrency errors is ruled out, providing the basis for "considerable confidence without line-by-line review." Similarly, TypeScript's strict mode and Go's vet tool offer partial protection, but Rust's strictness stands out among systems-level languages.

Costs and Realistic Boundaries

Faced with the objection that "not everyone has unlimited tokens," Lauren acknowledges she works at an AI lab with unlimited tokens and can't ask everyone to copy her setup.

But her ROI framework is worth considering: the value isn't in saving tokens on every small task, but in doing things that were previously impossible. On her own, before agents, it would have taken years to build such a framework, complete the refactor, and verify everything one by one; now she has spent a lot of tokens and refactored about 600 PRs to push the codebase to the point where she "no longer needs to read the code herself."

The trade-off for engineering leaders is: hire a person, or spend tokens to build the codebase to the point where even the "dumbest" agent can write good code. The latter's payoff extends beyond yourself—designers, PMs, and GTM staff can all submit features directly without worrying about being woken at midnight by a performance regression.

She describes Grok Bot as "the Cursor moment for non-technical people": the interface feels like iMessage, agents can be named, have their own identity, and be orchestrated; a PM can ask an agent to summarize "what Lauren did last night," or fix a bug themselves and ask her to review it. She reports the actual experience was "basically perfect, stamped and approved."

Editor's Observations

The most valuable takeaway from this methodology isn't any specific rule but its causal structure: trust → parallelization → leverage. Most people get stuck at the first step because they treat the agent as a black box and use manual review as verification; Lauren's path is to engineer verification itself, then use hard constraints to make "the correct way" the agent's default path.

The skepticism worth keeping: her environment has a dedicated architecture team, unlimited tokens, and in-house code review tools—conditions a mid-sized team can't fully replicate. Also, "not reading the code" presupposes a constraint system that has been iterated and validated extensively; skipping the build-up phase to chase high PR counts is likely to yield only accelerated technical debt.

(This article is based on a public talk on Bilibili; the views belong to the speaker.)