Cursor Power User in Action: How GrokBot Engineer Merged 2,000 PRs in One Month

SpaceX AI's GrokBot engineer Lauren (known on X as Poteto) dropped a jaw-dropping number in a recent tech talk: last month, she merged 2,000 pull requests into production. This wasn't the result of burning the midnight oil — it was built on a complete system of "trust" that channels her entire engineering knowledge into a team of AI Agents.

She rejects the term "software factory," preferring the analogy of a Michelin-star kitchen: engineers no longer chop every ingredient by hand, but they're still responsible for the final dish. The real craft lies in how you set up the kitchen, train the cooks, and configure the equipment. This article distills the core methodology from her talk.

Trust Is Everything

Lauren argues that the biggest barrier to scaling from "1–5 Agents" to "100 Agents" isn't compute or tooling — it's trust. In the early stages, you have to watch every conversation and constantly correct Agents; the moment you step away, things fall apart. She admits this phase is "the hardest to escape" because the path forward isn't obvious.

If you don't trust an Agent's output but you go ahead and spin up 100 sub-Agents or cloud Agents anyway, you'll end up with a flood of regression bugs and code nobody's happy with. So the real question is: How do you build enough trust in your Agents to let go?

Her answer breaks down into several actionable layers — and this framework is the underlying logic that made 2,000 PRs in a month possible. As she put it: "I realized I was the bottleneck. I needed to pour my engineering knowledge into my Agent team so I wouldn't have to be a blocker on everything."

Verification Skills: Let Agents Prove the Code Works

When Lauren joined Cursor six months ago, she was tasked with optimizing performance in the Cursor Agent window. She quickly realized that manually profiling with Chrome DevTools against a constant stream of incoming PRs was like pushing against a wall that never moved.

So she built her first verification skill, codenamed Control. It uses the Chrome DevTools Protocol to teach Agents how to run the application themselves, collect performance traces, capture memory snapshots, and pinpoint performance hotspots. The skill has two key components:

• A CLI: Stored in the skill directory so Agents can reproducibly run the app and collect verified evidence that "the code actually works" — rather than writing ad hoc scripts each time and getting inconsistent results across sessions.
• A Feature Map: A concept Lauren invented, analogous to a website's sitemap. It's a form of "materialized memory" that records what features the app has, how users reach them (keyboard shortcuts, which DOM elements to click), what each feature does — and is kept up to date by automation.

When the CLI and Feature Map work together, Agents can not only reproducibly operate the app and collect data — they can also interpret vague requests from internal and external users (like a Slack report that's just a screenshot and three question marks). Control became critical team infrastructure.

Verification solves for correctness — does this feature actually work? Does the checkout button actually check out? But it doesn't handle performance or code quality.

---

What is the Chrome DevTools Protocol? The Chrome DevTools Protocol (CDP) is a low-level debugging interface exposed by the Chrome browser, allowing external programs to programmatically control nearly everything the browser does — including page navigation, DOM manipulation, network request interception, JavaScript execution, performance trace recording, and memory snapshot capture. Normally, developers have to manually open the DevTools UI to access this data. CDP makes it all automatable and programmable. Lauren's CDP-based CLI essentially gives AI Agents a pair of hands that can operate a browser and a set of eyes that can read performance data — Agents no longer need a human sitting beside them opening DevTools and relaying results. They can autonomously complete the full loop of run → collect → analyze. This is the technical foundation that makes verification skills scalable.

---

Teaching Agents to Write Code Like Real Software Engineers

Built on top of verification, Lauren created a plugin called P-Stack — essentially a collection of skills that distill years of her software engineering workflows across different platforms. Debugging, feature development, prototyping — each task type has a corresponding playbook and skill that teaches Agents to "write code the way you'd want it written."

She emphasizes that this is exactly where senior engineers on a team can add the most value: building a shared skill repository that instantly makes every Agent smarter. When quality skills are layered on top of verification skills, Agents can both prove code correctness and collect real performance metrics and telemetry data to ensure quality.

Five Levels of Trust: From Codebase to Style Guide

Lauren presents a "trust ladder" ranked from most to least effective — and this is also the order she recommends investing your time:

1. The codebase itself: This is the best form of memory for an Agent. LLMs naturally tend to extend existing patterns they see in context, and the files an Agent reads are part of that context. So make good patterns pervasive.
2. Static analysis: Linters, compiler diagnostics, CI. When an Agent keeps making the same mistake, encode it as a lint rule. Better yet, refactor the codebase so that mistake becomes categorically impossible.
3. Rules, Bug Bots, and skills: These are "nudges" rather than hard constraints. Agents usually follow them, but they might miss a rule.
4. Style guides: These can only be enforced by humans during code review. In a world of PR floods, expecting humans to review line by line is simply unrealistic.

Her key warning: don't rely on style guides alone. Human review is only useful for catching what's missing. The real investment should go into the first few layers.

The DUNE Framework: Make the Shortcut the Right Path

The underlying architecture powering GrokBot is called DUNE — an "Agent-friendly framework" the team built from scratch. Its core insight is: Agents love to take shortcuts. So what if the framework were designed so that the easiest path is also the correct one?

The tradeoff is that DUNE is not particularly human-friendly — it's highly opinionated and heavily constrained. But that's precisely what creates an ideal environment for Agents with limited context. Lauren notes that future codebase contributors won't just be engineers — they might be designers, product managers, or even the CEO. The system must ensure that even a busy person with minimal context defaults to writing good code.

DUNE also enforces hard boundaries between different parts of the system — for example, main process code in Electron is forbidden from being imported into the renderer process. This lesson came from the Cursor Agent window: once slow code accidentally leaked into the render thread, UI smoothness took a hit. Hitting 60fps means every frame must take under 16 milliseconds; 120fps means under 8ms. DUNE enforces these boundaries via import and dependency graphs.

---

What is Electron? Electron is a framework for building cross-platform desktop applications using web technologies (HTML/CSS/JavaScript). Its architecture has two types of processes: the main process handles OS-level tasks (file system access, native window management, inter-process communication, etc.), while the renderer process runs the UI code for each window — essentially a sandboxed Chromium browser instance. Communication between them requires IPC (inter-process communication). Cursor itself is an Electron-based editor, so its performance bottlenecks are directly tied to this architecture. If compute-heavy code (like file indexing or syntax analysis) accidentally ends up in the renderer process, it blocks the UI thread and causes dropped frames and jank. DUNE uses static analysis of import relationships to enforce separation between the two process types at build time, eliminating this class of error at the architecture level.

---

Anti-Patterns Spread Like Viruses — You Need a "Gardener"

Lauren uses the analogy of a garden: seemingly harmless workarounds in a codebase will spread rapidly because Agents love to copy existing patterns. Within days, a bad pattern becomes the de facto standard, leaving behind a hard-to-maintain, performance-degraded "vibe-coded" codebase.

She gives a counterintuitive example: Agents writing comments in code. At first it seemed like normal engineering behavior. But she quickly noticed that Agents often used comments as an excuse to avoid actually solving the problem — rationalizing a temporary patch with a one-liner explanation. So in DUNE, they simply banned comments entirely.

This is why she advocates for a dedicated "gardener" role on every team — someone who catches weeds and pests early, before they spread. DUNE's three guiding principles are:

• Delete existing technical debt;
• Enforce a single "paved path" for best practices, so Agents don't have to guess;
• The moment a bad pattern appears, write a lint rule to contain the bleeding — you don't have to clean it up immediately, but at minimum, stop it from spreading.

The goal is to keep the codebase in a state where "even if an Agent copies it wholesale, you'd be happy with the result."

The Outer Loop: GrokBot Ties It All Together

If Cursor powers the coding "inner loop," GrokBot excels at the outer loop. It connects to Slack, Datadog, Sentry, PlanetScale, and other services to aggregate information and make decisions. Some call it the "company brain," but Lauren thinks that framing is overcomplicated — Agents are already naturally good at using tools.

Through GrokBot Routines, you can subscribe to Slack threads and Sentry alerts to automatically trigger cloud Agents. Combined with Cursor Automations and the SDK, you can build additional bots that reuse the same Agent infrastructure. The automation examples she demonstrated include automatically reproducing bug reports and automatically opening PRs — continuously generating value for the whole team.

She closes by emphasizing that none of this requires massive infrastructure investment. These compounding components — the codebase, rules, and skills — are enough to build yourself a "personal Michelin kitchen."

---

Inner Loop vs. Outer Loop These are standard software engineering terms for describing development rhythm. The inner loop refers to the high-frequency iteration a single developer does locally: write code, run tests, debug, repeat — typically measured in seconds or minutes. The outer loop refers to low-frequency collaborative processes that cross team and system boundaries: code review, CI/CD pipelines, monitoring and alert response, cross-service data aggregation — typically measured in hours or days. Cursor, as an AI coding assistant, primarily accelerates the inner loop — helping engineers write and revise code faster. GrokBot focuses on outer loop automation: it listens to team discussions in Slack, error alerts from Sentry, and performance metrics from Datadog, then automatically triggers Agents to analyze and respond — freeing engineers from the repetitive work of "information shuttling and initial triage." The organic combination of both loops is what makes Lauren's one-person, 2,000-PR month possible.

---

The One Slide to Remember

Lauren says if you only take one thing away, it's this: every time you find yourself correcting or intervening with an Agent, work through the hierarchy — codebase architecture → static analysis → rules/Bug Bots/skills — and find the most effective lever to increase trust. When you've built out all these layers, the environment becomes trustworthy enough for your Agents to run free.

There's no secret here. It's a lot of solid, unglamorous engineering work. And it's exactly this system that made 2,000 high-quality PRs from a single person in a single month a reality.