The Father of GrokBot: Merging a Thousand PRs a Month — Engineering Principles Behind Agent-Driven Auto-Merges

A SpaceX-background AI engineer shared a set of staggering numbers: last month, he submitted and merged roughly 1,000 PRs, and by the 12th of the current month, nearly 800 had already been merged. More importantly, he woke up to find about 20 PRs automatically merged into the main branch by agents, and the quality was solid. Behind this workflow is not some mysterious tool, but an engineering system built around "trust."

From "In the Loop" to the "Trust Curve": The Engineer's Role Shifts

The speaker used a hand-drawn diagram to describe his evolution over five months: early on, he was deeply involved, watching every output from one or two agents, constantly writing prompts, unable to parallelize. The reason was simple — if you don't trust even one agent's output, you can't scale to a hundred. He likened this to management: an engineering manager who doesn't trust their team can only micromanage, spending enormous time checking every detail.

As trust grew, he gradually let agents take on more responsibilities, until they were auto-merging PRs. Interestingly, the curve of Cursor's merged contributions roughly inversely correlates with the trust curve — the higher the trust, the less he intervened personally. He positioned himself as "the agents' engineering manager," with core responsibilities shifting from writing code to designing environments, setting constraints, and verifying results.

Verification Skills: Making Agents Actually "Run"

The skill he considers most important in the entire methodology is verification. Verification means the agent can actually run code, capture CPU traces, open an iOS simulator, or control the app through the Chrome DevTools Protocol — however the app is presented to the user, the agent can operate it the same way. This doesn't guarantee good code, but at least it enables correct code, and it's a key step in building trust.

He shared an early case: in his first week at Cursor, he was pulled in to help with Agent Window, with a tight deadline and a completely unfamiliar codebase. At the time, he could only open the performance panel himself, capture traces, look at flame graphs, and send screenshots to the agent. The agent confidently identified the problem, but was actually way off. During that period, he was the bottleneck, unable to parallelize. Later, the Control Glass skill he built allowed the agent to programmatically run the app, capture traces, and pinpoint issues, truly closing the loop.

A special design in the skill is the "feature map": it teaches the agent how to reach every feature entry point in the product, including sidebar sub-features, keyboard shortcuts, and attributes used when selecting elements via CDP. Without it, the agent would spin its wheels when facing vague user feedback. With it, a screenshot or even a "???" can be mapped to a specific feature. The PStack plugin he developed includes a creation page that can automatically scan code to generate an initial feature map, along with a process for creating and maintaining verification skills.

EVAL: Unit Tests for Skills

Skills become outdated as products iterate — how to maintain them? His answer is to treat EVAL as unit tests for skills. The process roughly: a coordinator agent first defines scoring criteria for the skill, then spawns multiple sub-agents to execute tests. Sub-agent directory names are deliberately chosen so they don't realize they're being evaluated — because once agents realize, they change behavior. The same skill can be evaluated across multiple models, especially those actually used.

Evaluation can also enable hill-climbing optimization: iteratively raise scores, cross-check with reviewer agents from different models to avoid bias, and use Cursor's slash loop to cycle until full marks. He used the same process to refine the Control Glass skill and command-line interface skills, requiring extensive iteration.

Maintaining skills, he describes, requires "taste and observation," similar to pair programming where you sit beside and constantly ask "why didn't you do this?" In the early stages of building skills, you must sit firmly in the driver's seat, expand all tool calls, read code, read the agent's thought blocks, and see exactly where it fails. He specifically noted an observation: agents often confidently claim the problem is somewhere, but checking the actual tool call records reveals they never read the affected code — this hallucination is the starting point of trust collapse.

EVAL (Evaluation) in the context of AI agents refers to a test suite for systematically evaluating agent behavior, similar to unit tests or regression tests in software engineering. Its core lies in defining clear rubrics and running multiple times to verify whether the agent's performance on specific tasks is stable and reliable. Unlike traditional tests, EVAL often must handle the non-determinism of natural language output, so strategies like multi-model cross-review and multiple sampling averaging are used to reduce evaluation bias. Hill-climbing optimization borrows from optimization algorithms: after each iteration, adjust the skill description or prompt based on the score, gradually approaching better performance. This evaluation-driven development approach allows agent skills to be continuously iterated and version-managed like code.

Cloud Agents and Dune Architecture: Hardcoding Constraints into CI

Once local trust is established, he recommends shifting focus to cloud agents. An agent called Benny receives all defect reports, automatically runs Cursor in a cloud desktop environment, and uses the same control skills to reproduce issues. In one case, Benny confirmed a defect was already fixed on the main branch, and he only needed to publish a new build, saving an hour of manual reproduction. He emphasizes not skipping steps: if you don't yet trust agents locally, rashly spawning thousands of agents will only waste massive tokens and be extremely expensive.

The architecture used by GrokBot, codenamed Dune, he describes as "Next.js for Electron apps," designed specifically for agents writing code. CI is strictly "annoying": React's useEffect is disabled, and even code comments are banned — because agent-written comments often describe historical situations unrelated to the code, such as treating a temporary comment for a specific PR as a global rule in comments. The directory structure separates Electron main process and renderer process, and import-checking CI validates dependency graphs and import boundaries to prevent cross-directory misreferences. These rules are synchronized in BugBot code reviews and agents.md.

His core principle is "the shortest path is the best path": since agents naturally love shortcuts, design the shortcuts to be the correct approach. Feature modules are all contained in a single directory; when the agent works on an onboarding feature, it only modifies that directory, and 80% of the work is done within encapsulated isolation. He repeatedly emphasizes layering: the codebase and static analysis are hard constraints, while rules, skills, and BugBot are soft — relying solely on the latter will eventually let the codebase spiral out of control. Tech stack choice also matters — the Rust compiler is strict, and the borrow checker provides extra confidence; as long as you ensure no unsafe blocks are written, if the code compiles, it probably works.

CI (Continuous Integration) here is expanded to act as the "enforcer of hard constraints." Traditional CI mainly focuses on building and testing, but the CI in this article adds rules like disabling specific React Hooks, banning comments, and import boundary checks, encoding architectural decisions and coding standards as automated checks. This essentially transforms "social constraints" into "machine-executable verification," ensuring agents cannot bypass rules when submitting code. The borrow checker is a core feature of the Rust language; it statically analyzes memory ownership and lifetimes at compile time to prevent data races and dangling pointers. For agent-generated code, a strict compiler means many potential errors are intercepted at compile time, reducing manual review burden — which is why the author emphasizes "if the code compiles, it probably works."

Rewrite or Refactor: The Biggest Risk and Opportunity for New Projects

He mentions an often-avoided topic: when to rewrite. Existing applications are actually in good shape, especially when infrastructure already has big-tech-level guardrails — he saw massive monorepos and collaboration among thousands of engineers at Meta, where frameworks, conventions, and permission restrictions were designed to accommodate the weakest engineer on the team. Under such guardrails, agents are less likely to mess up the codebase.

The biggest risk is brand-new projects starting from scratch. GrokBot itself was rapidly generated by vibe coding, with humans barely reading code; without guardrails, agents solve problems in the most convenient way, and the codebase gradually spirals out of control. He did the math: being able to wake up to 20 PRs auto-merged came from investing enormous time across 600 PRs. After migrating GrokBot to the new architecture, he basically no longer reads code, but that's bought with massive tokens and continuously reinforced constraints.

Average PR size ranges from 50 lines to a few hundred lines to about 1,000 lines; there's no hard limit, but he encourages agents to break work into multiple atomic PRs for easier rollback and issue localization — the Git history itself is a rich source of context.

Vibe coding refers to a development mode where humans describe intent in natural language and agents rapidly generate code while humans barely read or review details. This mode can greatly increase speed early on, but without guardrails, agents choose the most convenient path, leading to hidden debt and structural chaos accumulating in the codebase. The article points out that existing projects, with mature frameworks and conventions as guardrails, are actually lower risk; brand-new projects lack these constraints and are more prone to chaos. Therefore, the author recommends investing time early in establishing hard constraints (like CI rules, directory boundaries) rather than remediating later. This also explains why he could reach the trust level of "waking up to 20 auto-merged PRs" only after iterating through 600 PRs.

The Hidden Value of Tech Stack Choices

He mentions that GrokBot and Cursor's virtualization is supported by a new library called Pretax, but that's not the point. What's truly intriguing is his instrumental judgment of tech stacks: strong typing and strict compilers mean more invariants enforced by machines, reducing manual review burden. The worst situation is relying on humans reading code line by line in code review to enforce constraints — every time you have to do this, it should be seen as an anti-pattern, and you should ask: can this be turned into a static check rule, a CI failure, or simply eliminated by design?

Non-Engineers Can Deliver: GrokBot's Organizational Significance

The end of the talk discusses how product teams can keep up with delivery speed. GrokBot gives non-technical people their first handy agent entry point: the interface is like iMessage, you can name agents, and orchestrate them like managing a small team. Each account has 11 agents managed by the user; product managers can ask agents to summarize last night's engineering progress, or directly say "there's a bug here, let me fix it," then hand it to engineers for review. Designers and product managers can now directly deliver features, and this strictly constrained architecture has stood the test.

Regarding token cost concerns, his response is an ROI perspective: spending a lot on model calls early on buys constraint strength that one person couldn't achieve alone. Doing everything yourself — setting up frameworks, refactoring, testing and verification — would take years, and his salary isn't low. For engineering leaders, the real question is whether to hire people or spend tokens building a codebase where even the dumbest agent can perform well. He chose the latter because it empowers himself, the team, and non-engineering roles simultaneously.

Key Takeaways

Start with verification skills, build local trust first, then expand to cloud agents, and only finally move to auto-merging. There are no shortcuts, because trust cannot be faked. Hard constraints take precedence over soft rules, shortest paths over flexible design, machine enforcement over manual review. The underlying logic of this philosophy is to encode engineering standards into something agents can execute and verify — then you dare hand the main branch to it while you sleep.

One-line Summary

A SpaceX-background engineer shares how to build trust in agents through verification skills, EVAL, and hard constraints to achieve auto-merged PRs.

Paragraph Summary

A SpaceX-background AI engineer shared his workflow of submitting about 1,000 PRs over five months, centered on building an engineering system around "trust." He proposes engineers should transition to "agents' engineering manager," focusing on designing environments, setting constraints, and verifying results. Verification skills let agents actually run apps, capture traces, operate simulators, forming a closed loop; EVAL serves as unit tests for skills, combined with multi-model cross-review for continuous optimization. Cloud agents and the Dune architecture hardcode constraints into CI, such as disabling useEffect and comments, import checks, ensuring agents take the "shortest path as the correct path." He emphasizes hard constraints over soft rules, viewing token investment as ROI, ultimately empowering non-engineering roles to deliver features directly.