Cursor Engineer Reveals: How to Take AI Agents from Babysitting to Auto-Merging PRs

Cursor engineer Lauren Tan (Twitter: @PotatoPotato) shared in an online talk how she spent her first five months at Cursor — after coming from Meta's React team — gradually building trust in AI agents, ultimately reaching the point where agents automatically merge code on her behalf. Her core argument is straightforward: managing AI agents and managing an engineering team are fundamentally the same, and trust is the through-line that runs across the entire journey.

The Trust Curve: From Micromanagement to Parallel Autonomy

Lauren sketched a hand-drawn diagram to describe her experience with agents. A year ago, most people using agents to write code were in a "high-intervention" mode — watching every line of output from one or two agents, constantly writing prompts, stuck in the work loop with no way out. The reason is simple: if you don't trust the output of even one agent, you can't possibly dispatch a hundred agents to work in parallel.

"It's very similar to team management," she said. "If I'm an engineering manager but I don't trust my engineers, I end up micromanaging — spending huge amounts of time watching everyone work and checking that bugs don't make it into production."

Over the past five months, Lauren has been climbing this trust curve. She openly admits she now lets agents automatically merge PRs on her behalf — "When I woke up today, about 20 PRs had already been auto-merged into main, and when I reviewed them afterward, the quality was solid." She mentioned submitting 1,000 PRs last month and merging nearly 800 by the 12th of this month. When asked "Is the code quality actually acceptable?", she acknowledged it's a fair question, but insists that high-quality automation is achievable.

Verification Skills: The Critical Link That Breaks Bottlenecks

Lauren argues that the most important capability in your toolkit when working with agents is verification — giving agents the ability to actually run code, capture CPU traces, take heap snapshots, or open an iOS simulator, so they can interact with the application the same way a user would and confirm features are working correctly. "This doesn't guarantee the agent writes good code, but it at least ensures the functionality is correct, and that dramatically increases your trust in it."

She shared a genuinely awkward situation from her first week on the job: she was developing the agent window (internally codenamed Glass), facing a completely unfamiliar codebase, unable to read flame graphs — and neither could the agent. She'd screenshot the directory, download traces, and send them to the agent, which would then confidently declare "the problem is right here" — and be completely wrong. "As long as verification skills are missing, the verifier becomes you, and you become the bottleneck."

To address this, she built the Control Glass skill, teaching agents to use the Chrome DevTools Protocol, Apple simulator tools, and similar interfaces for programmatic control. But what's truly unique is a file called the "Feature Map" — it proactively explores the codebase and tells the agent how to navigate to various features in the UI, what keyboard shortcuts exist, and which DOM elements correspond to what. That way, even if a user just pastes a screenshot complaining that "the left sidebar is laggy," the agent can map that to a specific feature rather than thrashing around and wasting time.

The Chrome DevTools Protocol (CDP) is a low-level debugging interface exposed by Google Chrome that allows external programs to programmatically control browser behavior — including capturing network requests, taking DOM snapshots, executing JavaScript, and recording performance traces (flame graphs / CPU traces). Automation frameworks like Puppeteer and Playwright both rely on CDP under the hood. In an agent context, giving agents CDP access means they can "truly see" page state like a human tester, rather than relying solely on static code analysis and inference — this is the technical foundation of what Lauren calls verification skills. Heap Snapshots are outputs from Chrome's memory analysis tools, used to identify JavaScript object memory usage and pinpoint leaks; they're a standard technique in frontend performance debugging.

PSTACK: Crystallizing Failure Patterns into Skills

The plugin Lauren developed is called PSTACK (P for Potato, inspired by YC CEO Gary Tan's GaryStack). At its core, it's a collection of skills that can be found via Google search. She emphasizes that these skills are essentially markdown documents, but they can encode a rich amount of information and instructions that fully unlock an agent's capabilities.

She explained the underlying mental model: LLMs fundamentally predict the next token. If you feed them a batch of high-quality tokens from the start, they can pattern-match at a higher level and enter a "smarter state." On Twitter, people have described this as "pulling the agent into a different latent space."

PSTACK was built incrementally: every time she observed a failure pattern — like an agent making wild guesses without reading the code — she turned it into a skill, such as "don't guess, actually search and read the code." She particularly emphasizes the importance of not being a passive observer: "Just like in pair programming, when you're sitting next to someone thinking 'this could actually be written better,' you have to keep a firm hand on the wheel with agents too."

The phrase "pulling the agent into a different latent space" stems from an intuitive description of how large language models work. LLMs learn a probability distribution over token sequences during training, and the quality of their reasoning is heavily dependent on the "knowledge regions" activated by the input context (prompt). When you inject high-quality, well-structured background information at the start of a prompt, the model samples from a probability distribution that is closer to an "expert state" when decoding subsequent tokens — effectively shifting the model's reasoning starting point to a higher-quality region of the parameter space. This is the underlying reason why system prompt engineering, few-shot examples, and structured skill documents can significantly improve agent output quality — it's not simply a matter of "providing more information."

Using EVALs to Write "Unit Tests" for Skills

How do you maintain and trust these skills? Lauren's answer is EVAL — essentially writing unit tests for your agents. PSTACK comes with a built-in methodology (search for "EVAL Playbook" in PotatoMode).

The approach involves having a primary coordinator agent define a scoring rubric, spin up multiple sub-agents, and create cleverly named isolated directories for each — so the sub-agents "don't know they're being evaluated," since awareness would change their behavior. Cursor supports multiple models, so you can evaluate skill performance across the entire model matrix.

What's even more interesting is continuous optimization using "hill climbing": EVAL produces a score, then a judge agent using a different model cross-checks it, and then a Loop runs the whole cycle repeatedly until every item scores a 10. "Control Glass was essentially built this way, with very little intervention from me throughout the process."

"Hill Climbing" is a classic local search optimization algorithm: starting from the current solution, it iteratively attempts small modifications, accepting a new solution if it scores higher and retaining the original otherwise, repeating until no further improvement is possible. In machine learning, this approach is widely used for hyperparameter tuning and prompt optimization. Lauren applies it to skill iteration: EVAL produces a quantitative score, the Loop continuously generates variants and scores them, retaining only higher-scoring versions, gradually pushing skill quality toward a perfect score. The advantage of this method is that it eliminates the need for manual review of each change — but it also carries the risk of getting stuck in a local optimum, where a skill version is "optimal" under the current scoring rubric but doesn't necessarily perform best in real-world scenarios. This is why the quality of the scoring criteria themselves is critical.

Layered Guardrails: Getting Even the Weakest Agents to Write Good Code

Lauren offered a pragmatic take on the controversial question of "should you rewrite your app." Using Meta's massive mono repo as an example, she pointed out that large tech companies' infrastructure is actually designed around "taking care of the weakest person on the team" — building frameworks, establishing standards, restricting permissions to prevent interns from accidentally dropping production databases. "Long before AI slop existed, humans were already writing slop." She believes that once guardrails like these are in place, agents won't cause disasters in the codebase.

For greenfield projects written quickly via vibe coding (like GrokBot, which was just released yesterday), she warned of the "organic architecture" risk: without guardrails, agents will always take the path of least resistance, and the codebase will gradually spiral out of control.

She designed multiple layers of constraints for GrokBot (internally codenamed Dune, which she described as "Next.js for Electron apps"):

• Codebase architecture (hard constraint): Feature code is consolidated in a single directory, with the core principle being "the shortest path is the best path" — aligning with agents' natural tendency to take shortcuts.
• Import rules (hard constraint): Static analysis checks the dependency graph and prohibits cross-directory imports, strictly isolating ElectronMain and ElectronRender to prevent performance regressions.
• Rules, skills, bug bot (soft constraints): Cursor's Bug Bot performs code review in CI.

She even disabled useEffect and code comments directly in CI — because in 99% of cases, the comments agents write only document irrelevant historical context, and agents treat casual remarks as global rules to follow. Her advice: invest as much as possible in mechanisms that can be hard-enforced. This is also why Rust is enjoying a resurgence — "if the code compiles, it will probably run correctly."

A "Greenfield Project" refers to building something entirely from scratch without the constraints of any legacy code, as opposed to a "Brownfield Project," which involves iterating on an existing system. Greenfield projects are especially worth paying attention to in AI-assisted development: with no existing architectural constraints, agents organize code entirely along the "path of least resistance." Development speed is extremely fast in the short term, but as features accumulate, code structure degrades rapidly without a unified standard — this is exactly the source of the "organic architecture" risk Lauren describes. Dune (GrokBot's internal codename) is analogized to "Next.js for Electron apps," meaning it attempts to provide Electron desktop applications with the same convention-over-configuration framework that Next.js provides for React web apps, locking in architectural boundaries right from the greenfield stage.

From Local to Cloud: Automated Agents Like Benny

Lauren recommends building your verification system locally first, so you can clearly observe how agents interact with the application and which APIs they call. But she herself has fully moved to cloud-based agents. She gave the example of an agent named Benny: it takes over all bug reports, automatically spins up a desktop environment in the cloud, and uses control skills to reproduce issues. "For example, Benny successfully reproduced a particular bug and confirmed it was already fixed on the main branch — I just needed to cut another build. That information is extremely valuable and saves a huge amount of time."

She repeatedly emphasized that this is an incremental process: "You have to trust it first before you can get to this point. Don't start by spinning up hundreds or thousands of cloud agents — that will just burn through an enormous number of tokens and be incredibly expensive."

Token Costs and Return on Investment

On the question of whether this is realistic for ordinary users with limited token quotas, Lauren was candid: "Nothing is free, and tokens are not cheap." Refactoring a codebase and filling in guardrail mechanisms both consume large numbers of tokens — she submitted over 600 PRs to refactor GrokBot into the new architecture.

But she frames this as an ROI question: rather than hiring an engineer at a significant salary to spend years building a framework, it's worth spending tokens to build out the codebase properly so that even the most basic agents can do the job well. And the return extends beyond her own work — product managers and designers can now submit code directly for her to review. "The code is perfectly fine, and I just approve it." This proves the architectural constraints have held up under pressure.

She also mentioned that Grok 4.6, released that same day, is priced the same as 4.5 but is smarter — "essentially getting more intelligence for the same cost" — and that what Cursor and xAI are really optimizing is "the frontier boundary between cost and intelligence."

Head Chef, Not Line Cook

Lauren closed with an apt analogy: engineers are now more like the head chef in a restaurant. They no longer cook every dish personally; instead, they design the entire kitchen, build the working environment, and assign tasks to different stations. She believes teams should stay lean and agile, using agents to accomplish things that were previously out of reach.

For those who want to replicate her path, she laid out a clear three-step process: first, build verification capabilities locally and confirm that code functionality is correct; then expand to running more agents in the cloud to capture signals on their own; and finally, let PRs auto-merge. "There's no shortcut from one end to the other — it depends entirely on how much you personally trust your agents."