The Secret Behind 2000 PRs a Month: Lauren's AI Agent Trust Workflow

SpaceX AI engineer Lauren (known on X as "Potato"), who works on the Grokbot team, dropped a striking number in a recent talk: last month, she merged over 2,000 Pull Requests into production. There's no "better prompts" magic behind that number — just a carefully constructed Agent workflow built around one idea: trust.

Her core argument is straightforward: if you build a good enough environment for your Agent to operate in, you end up with something like a "personal — or even team-level — software factory" that produces high-quality code at a pace previously unimaginable. That said, Lauren herself dislikes the "software factory" framing. She prefers the analogy of a Michelin-starred kitchen — the engineer is still responsible for the final dish, and how you configure your "kitchen" (sous chefs, line cooks, equipment, training) determines the quality of what comes out.

From Manual Performance Tuning to 2000 PRs

Lauren's transformation began about six months ago when she joined Cursor (later absorbed into SpaceX AI). She came from the React team and was tasked with fixing performance issues in the Cursor Agent window. She quickly found that PRs were flooding in at a suffocating pace, and her method for detecting performance regressions was painfully primitive — staring at Chrome DevTools, manually taking performance traces and heap snapshots.

"Wait, we have Agents. What am I doing?" That realization was the turning point. She began asking: what if an Agent could run the app itself, capture traces, identify hot spots, and automatically optimize performance? Six months later, her productivity had "gone vertical."

Lauren is clear that 2,000 PRs was never the goal. The real insight was: "I was the bottleneck." Engineers need to transfer their accumulated knowledge into the Agent team so they don't have to be a blocking point for everything. And all of that comes down to one word — trust.

Breaking Out of Babysitting Mode: The Trust Ladder

Lauren divides Agent usage into different stages. Most people start somewhere between 1 and 5: watching every conversation, constantly correcting and intervening, and knowing that the moment they step away, the Agent will do something wrong. She believes this stage is the hardest to break through, precisely because the way out isn't obvious.

Spinning up hundreds of sub-Agents without trust just produces a pile of bad PRs

Why can't you scale from a handful of Agents to hundreds? Because you don't trust their work. If you force-launch a hundred sub-Agents or cloud Agents in parallel without that trust foundation, you'll end up with an avalanche of garbage PRs, regressions, and bugs — and nobody will be happy. The question then becomes: how do you build enough trust in your Agents?

Verification Skills: Let the Agent Prove the Code Works

Lauren's first answer is Verification. Verification exists on a spectrum: at the lower end are "verification skills" — teaching the Agent how to run your application, use tools like the Chrome DevTools Protocol for debugging, capture performance traces and heap snapshots. At the higher end are formal methods like Lean and TLA+, used to verify business logic invariants. She admits formal verification remains an open problem, but verification skills alone can take you surprisingly far.

The first verification skill she built at Cursor is called "Control," and it has two key components:

CLI: Lets the Agent run the application reproducibly, collect traces and empirical evidence — instead of ad-hoc scripting each session. The CLI lives in a skills directory and the Agent calls it directly every time.
Feature Map: A concept Lauren invented, inspired by sitemaps. It's essentially "materialized memory" — a record of what features the app has, how users reach them (keyboard shortcuts, which DOM element to click), and what each feature does.

The P-Stack plugin distills workflows Lauren has built up across years of software engineering practice

When CLI and Feature Map are combined, the results are remarkable: the Agent can not only control the app and capture traces reproducibly, but also interpret vague requests from internal and external users (like a Slack screenshot showing a tiny corner of the UI with three question marks). This verification skill became critical team infrastructure.

Verification addresses correctness — does the feature actually do what you want (does the checkout button actually check out?). But it can't speak to performance or code quality. For that, Lauren built a plugin called P-Stack, which distills her years of debugging, feature development, and prototyping workflows into a skills library — teaching Agents to write code the way you'd want it written.

The Chrome DevTools Protocol (CDP) is a low-level debugging interface open-sourced by Google. It lets external programs control Chrome/Chromium directly over WebSocket — enabling page navigation, DOM manipulation, network request interception, JavaScript execution, performance tracing, and heap snapshots. Compared to a human manually poking around in DevTools, CDP makes all these debugging actions programmable and reproducible. That's the technical foundation of what Lauren calls "verification skills." When an Agent calls CDP through the CLI, it gains a pair of hands that can operate the browser autonomously — running the app, collecting performance data, and feeding results back to itself for analysis and optimization, all without human supervision.

Lean and TLA+ are the formal verification tools Lauren mentions. Lean is an interactive theorem prover that can verify code logic with mathematical-level correctness guarantees. TLA+, designed by Turing Award winner Leslie Lamport, is a specification language widely used to verify protocols and state machines in distributed systems. Both can mathematically guarantee that business logic invariants hold for all possible inputs — far beyond what testing can cover — but the learning curve is steep, and both remain on the frontier of mainstream engineering practice.

Making the Codebase the Agent's Memory

Lauren describes a "trust ladder" with five levels, ordered by importance (descending) and enforceability (also descending):

The codebase itself: The best form of memory. LLMs tend to follow patterns they see in their context window, and the files an Agent reads and opens are its context. So the Agent extends existing patterns rather than refactoring on every PR.
Static analysis: Linters, compiler diagnostics, and CI are enforceable constraints. When an Agent keeps making the same mistake, rather than correcting it every time, add a lint rule — or better yet, refactor the codebase so the mistake is structurally impossible.
Rules, Bug Bots, and skills: These operate at the "guidance" level. Agents will mostly follow them, but they might forget to read the rules, or operators might skip them — less enforceable.
Style guides: Can only be enforced through human code review.

It's no longer just engineers contributing code — designers, PMs, and CEOs can too

Lauren specifically warns: if you rely only on style guides, your review process will develop massive blind spots — humans have to scrutinize every single line of every change, which simply isn't possible at this PR velocity. Conversely, if the codebase already contains anti-patterns, they spread like viruses. A small workaround or explanatory comment is something Agents love to copy — within days or weeks, it becomes the de facto standard across all your Agents.

She uses a garden metaphor: the codebase is like a garden, and seemingly harmless workarounds get copied until they grow into an unmaintainable, poorly-performing "vibe-coded" mess. Every team needs a dedicated gardener who prunes weeds before they take root.

The Dune Framework: Turning Shortcuts into the Right Path

The Grokbot codebase is built on a framework called Dune. Its core principle: since Agents love to take shortcuts, design a framework where the easiest path is the correct path.

This kind of codebase might feel "locked down and annoying" to humans, but it's ideal for Agents — especially Agents operating with minimal context. Because contributors to modern codebases aren't just engineers anymore; they're designers, PMs, even CEOs, and you need Agents driven by time-constrained, low-context operators to do the right thing by default.

In a Dune app, features are concentrated in a single folder with strict boundary constraints

Dune is built around three principles:

Delete existing technical debt
Enforce a single "paved road": There's exactly one conventional way to do any given thing. The Agent doesn't have to guess.
When you spot technical debt, write a lint rule first: You don't have to clean it up immediately, but at least you stop the bleeding — preventing it from spreading further.

One striking extreme: Dune bans code comments. Lauren initially thought Agent-written comments were harmless — after all, humans leave comments in tricky spots too. But she observed that Agents often use comments as an excuse to avoid actually solving the problem, papering over a temporary hack with a note. To prevent this pattern from propagating, the team simply banned comments altogether.

Dune also enforces boundaries through import and dependency graphs — for example, prohibiting main-process code from being imported into the renderer thread. This lesson came directly from the Cursor Agent window: once slow code bleeds into the renderer thread, it's impossible to maintain the 16ms (60fps) or 8ms (120fps) frame budget. This class of pattern — capable of causing serious performance regressions — is eliminated at the architecture level.

The "renderer thread frame budget" Lauren references comes from a hard constraint in the browser rendering pipeline. Browsers draw frames at a fixed refresh rate: 60fps requires all layout, painting, and compositing to complete within 16.67ms; 120fps compresses that window to 8.33ms. If compute-heavy or I/O-blocking "main process code" gets mixed into the Renderer Process, frames will miss their deadline — and users experience stuttering and dropped animations. Electron's architecture (Cursor is built on Electron) enforces strict isolation between the main process and renderer process for exactly this reason. Dune uses static analysis of the import graph to intercept incorrect cross-boundary imports at commit time, fundamentally preventing this class of performance regression — without relying on human code review to catch it.

Inner and Outer Loops: How Grokbot and Cursor Work Together

In Lauren's system, Grokbot handles the Outer Loop: it connects to Slack, Datadog, Sentry, PlanetScale, and other connectors, aggregates information, and makes decisions based on it. Some people call it the "company brain," but Lauren thinks you don't need to overcomplicate it — Agents are already good at using tools, so you wire up those tools to Grokbot and let it automatically trigger cloud Agents.

Add Grokbot Routines (subscriptions to Slack threads and Sentry alerts that auto-trigger tasks), stack them on top of the codebase, rules, and skills you've already built, and these elements compound on each other. Grokbot automatically responds to outer-loop events and spins up cloud Agents; you can also use Cursor Automations and the SDK to build more bots that reuse this infrastructure for increasingly complex tasks. The end result: automatically reproducing bug reports and automatically opening PRs — continuously creating value for the entire team.

The distinction Lauren draws between Outer Loop and Inner Loop is an important architectural concept in Agent workflows. The Inner Loop refers to the closed cycle of a single coding task: receive requirements → generate/modify code → run verification → submit PR. This is handled by local IDE-level Agents like Cursor. The Outer Loop is the layer that drives the inner loop: it listens to Slack messages, Sentry alerts, Datadog anomalies, and other external events, decides whether a new coding task should be triggered, and schedules cloud Agents to execute it. Grokbot acts as an "event router" at the outer-loop layer — it doesn't write code directly, but senses system state, aggregates context, and decides "which Agent should do what." This layered design allows the entire system to respond automatically to production alerts with no human supervision, while the codebase, rules, and skills infrastructure guarantee output quality.

One Thing to Remember: Climb the Trust Ladder

If there's one thing Lauren wants people to take away from this talk, it's the trust ladder slide. Whenever you catch yourself correcting or intervening with an Agent, think through the five levels and find the most effective place to invest:

First, invest time in making bad patterns structurally impossible through the codebase, architecture, and data structures. Then lean on static analysis. Layer in rules, Bug Bots, and skills. Style guides come last.

Get these layers solid, and you'll be able to trust the entire environment — letting Agents run freely and empowering every engineer on your team. Lauren puts it plainly: "There's no secret here. It's just a lot of hard work." But it's exactly that hard work that lets her run her own Michelin-starred kitchen.