Former Cursor Engineer's 5-Month Experiment: How to Get AI Agents to Auto-Merge PRs

When an engineer who spent five months at Cursor woke up to find 20 PRs had been automatically merged by AI agents, it was the result of a complete methodology built around a "trust curve." Lauren, a former Cursor engineer, shared his experience on Bilibili: from initially hovering over a single agent to now letting agents auto-merge PRs, the key lies in verification and environmental constraints.

From "Human Bottleneck" to "Auto-Merge": A Trust Curve

Lauren showed a hand-drawn chart: time on the horizontal axis, trust level on the vertical axis, with the curve inversely proportional to his contribution volume at Cursor. In the first month, output was extremely low due to unfamiliarity with the codebase. As his trust in agents grew, he merged 1,000 PRs last month, and in just 12 days this month he's already near 800.

"Trust" is the keyword throughout. He draws an analogy to managing a team: if you don't trust your subordinates, you fall into micromanagement, spending enormous time checking every line of code. Similarly, without trusting agents, engineers become the verification bottleneck—the agent writes code, the human opens a local environment to test, screenshots the error and pastes it back, and the cycle repeats without any parallelism.

The first piece of the puzzle: Verification skills let agents run on their own

Verification is what Lauren considers the most important skill for collaborating with agents. He wants agents to actually run code, capture CPU traces, open the iOS simulator, and test like a user.

He gave the example of Cursor Agent Window. In his first week on the job, the team faced pressure to ship in a week, and he needed to optimize performance but knew nothing about the codebase. He opened Chrome DevTools to capture a trace, screenshotted it and sent it to the agent, which confidently pointed to "this is the spot"—but after the fix, the problem persisted. The agent was guessing.

So Lauren built the "Control Glass" skill, letting the agent control the Electron app and capture traces via the Chrome DevTools Protocol. But a new problem emerged: the agent could run the app but didn't know where the "left sidebar" was, or how to navigate to a specific feature.

This gave rise to the "Feature Map"—a document teaching the agent how to reach every feature, including user-perspective paths, keyboard shortcuts, and DOM elements and attributes for CDP selection. With it, even when facing a vague user report like "???", the agent can understand the context and autonomously reproduce the issue.

Chrome DevTools Protocol (CDP) is a WebSocket-based debugging interface exposed by the Chrome browser. Developers can use it to remotely control the browser: launch pages, execute JavaScript, capture performance traces, read the DOM and network requests, and more. What Lauren means by "letting the agent control the Electron app via CDP" is essentially plugging the agent into this interface so it can click buttons, read state, and collect performance data like an automated test script—rather than guessing where the problem is from code alone. Electron apps also embed Chromium internally, so they natively support CDP, which is the prerequisite for this approach to work.

PStack: Encoding engineering taste into skills

Lauren organized his skill collection into an open-source plugin called PStack (a play on Y Combinator CEO Garry Tan's GStack). Its core is incremental building: observe the agent's failure modes, and write a corresponding skill each time you find one.

For example, he noticed the agent often confidently said "the problem must be here," but after checking the tool-call log, it had never even read the relevant code. Thus the "How" skill was born—forcing the agent to search the code first, use sub-agents, and prohibit guessing.

PStack also provides "create verification skill" and "maintain verification skill," the latter relying on an Evals mechanism. Lauren compares Eval to unit tests for agents: the main orchestrator agent generates scoring criteria, then spawns multiple sub-agents to execute tasks in separate directories, with directory names deliberately obfuscated so the agent doesn't realize it's being evaluated—because "agents can notice and change their behavior." Even better, Eval supports hill climbing—using the /loop command in Cursor to iterate until all scores reach 10.

Hill climbing is a classic local search optimization method: starting from the current solution, continuously trying neighboring candidate solutions, keeping only the one with the higher score, and iterating until no further improvement is possible. Lauren applies it to Eval by fixing the scoring criteria and letting the agent repeatedly generate new solutions and keep the higher-scoring versions, using the /loop command to automatically cycle through multiple rounds. It doesn't guarantee finding the global optimum, but it's simple to implement and delivers measurable improvement each round—perfect for scenarios like "letting the agent grind a certain type of task from 6 points to 10 points on its own."

Three layers of constraints: Let the codebase police the agent itself

When asked how GrokBot (Cursor's newly released agent orchestration app) manages code quality, Lauren proposed a three-layer constraint model.

Hard constraints come from architecture. GrokBot uses a framework called "Dune," described as "Next.js for Electron, designed for agents to write." It enforces co-location of feature code by directory, prohibits useEffect, and even prohibits code comments—because agents write meaningless historical comments like "Lauren said not to do this." CI checks the dependency graph and blocks accidental imports between electron main and electron renderer directories, preventing the render thread from being blocked and causing dropped frames.

Soft constraints are rules and prompts. BugBot runs code review on CI, and .cursorrules are scattered everywhere. But Lauren stresses that soft constraints cannot be relied on alone: "If you only have rules and BugBot, the codebase will eventually turn into garbage."

The worst is human review. He makes a sharp point: every time you leave a comment on a PR saying "this shouldn't be done here," it should be treated as a code smell. The right approach is to ask yourself: how can I turn this constraint into a hard rule? How can I turn it into a lint rule or a CI failure?

Co-location means putting a feature's components, logic, styles, and tests in the same directory, rather than layering by technical type (e.g., all components in one place, all hooks in another). For agents, co-location significantly reduces the cost of "finding the relevant code": when modifying a feature, you only need to read and edit within one directory, reducing cross-directory searching and omissions. This is also the core of the "designed for agents to write" architectural philosophy—the directory structure itself is a constraint that makes the agent's search space smaller and its behavior more predictable, thereby improving correctness without adding manual review.

The refactoring debate: Greenfield is the biggest risk

Lauren gives a counterintuitive take on "should you rewrite?": Brownfield apps are actually safer, because big tech companies' infrastructure—permission restrictions, guardrails, conventions—was designed for "the least experienced engineer," and agents benefit from it too.

The real risk is Greenfield. A fully vibe-coded prototype has no guardrails whatsoever; the agent will solve problems in the most convenient way, and the codebase gradually spirals out of control. He reveals he spent over 600 PRs refactoring GrokBot into the "Dune" architecture, and now he no longer looks at the code—"I spent a lot of tokens to get the codebase into this state."

Cost and return: Tokens are not an expense, they're an investment

Faced with the objection that "ordinary people don't have unlimited tokens," Lauren acknowledges the resource advantage of working at an AI lab, but stresses this is an ROI question. Early refactoring and establishing constraints require a lot of tokens, but the return is a boost in overall team efficiency—designers, product managers, and even GTM staff can directly submit features.

"Agents let me do things I couldn't do before," he says. "I couldn't possibly have spent years building this framework alone." He uses a chef analogy for the current engineer role: no longer cooking the dishes yourself, but designing the kitchen, assigning tasks, and ensuring the environment runs efficiently.

New possibilities for cross-functional teams

The conversation finally turns to how product teams can keep up. Lauren believes GrokBot has become the "Cursor moment" for non-technical people—an iMessage-style interface, nameable agents, and natural orchestration let PMs and designers contribute code in a sustainable way. "Strict constraints let non-engineering experts participate at a high level," he says. "That excites me enormously."

From watching a single agent closely to letting 20 PRs auto-merge, there are no shortcuts on this path—only building trust through verification, then cementing that trust with architectural constraints. As Lauren repeatedly emphasizes: everything ultimately comes back to trust.

One-line Summary

A former Cursor engineer uses verification skills and three-layer architectural constraints to push trust in AI agents from micromanagement to automatic PR merging.

Paragraph Summary

Lauren, a former Cursor engineer, shared his methodology for collaborating with AI agents: at its core is a "trust curve"—the higher the trust, the less engineers need to serve as a verification bottleneck, with himself having merged nearly 800 PRs in 12 days. The path has two parts: first, "verification skills" that let the agent actually run the app and capture traces via the Chrome DevTools Protocol, combined with a "Feature Map" so the agent can understand vague reports and autonomously reproduce issues—these skills are packaged as the open-source plugin PStack and continuously refined with an Eval mechanism like unit tests. Second, "three-layer constraints": hard constraints from architecture and CI, soft constraints from rules and BugBot, and the worst being human review, where every PR comment should be converted into a hard rule. He also points out that Greenfield prototypes carry more risk than Brownfield, and early token investment pays off in overall team ROI.