1000 PRs a Month: How a Cursor Engineer Built Trust in AI Agents

From Micromanagement to Letting Go: A Trust Curve

A Cursor engineer recently shared a striking number: last month he merged 1,000 PRs, and by the 12th of this month, nearly 800 had already landed. Even more remarkable — he now lets agents auto-merge PRs, waking up each morning to find roughly 20 changes already committed to main.

This might sound like mass-producing garbage code, but he insists the opposite is true. Getting there wasn't mainly about the models getting smarter — it was about climbing a "trust curve" step by step.

He used a fitting analogy: managing a team. An engineering manager who doesn't trust their reports will inevitably micromanage — spending enormous time looking over shoulders, checking that bugs don't reach production. Working with agents is no different. A year ago, hardly anyone was actually using agents to write code. You were locked in a tight loop with one or two agents, scrutinizing every output, rewriting prompts over and over, with no ability to parallelize — because if you couldn't trust a single agent's output, how could you spin up 100 at once?

He's candid about this: engineers who've written code for years have strong opinions about what good engineering looks like. When you watch an agent confidently hallucinate, or declare for the hundredth time that it's found "definitive proof" of a problem that turns out to be nothing, trust erodes fast. And without trust, agents have no value.

Verification: The Most Important Tool in the Agent Toolbox

In his view, the most critical capability when working with agents is verification — giving agents the ability to actually run the code: grab CPU traces, take heap snapshots, open the iOS simulator, and exercise the app the way a real user would.

"This is what actually closes the loop. It doesn't guarantee the agent writes good code, but it at least lets the agent write correct code."

He shared a real story from inside Cursor. Five months ago, shortly after joining, he was pulled in to help with agent window (internally codenamed Glass) React work — with only a week until launch. His only option was to stare at flame graphs in Chrome DevTools, feeding trace screenshots and files to the agent. The agent would confidently declare "that's the problem," but fixing it never helped. The whole process was painfully slow — you were the one doing verification, and you were the bottleneck.

So he wrote one of Cursor's earliest skills: control glass. The skill itself isn't complex — it teaches the agent to use the Chrome DevTools Protocol (or Apple's simulator tooling) to run the app.

Feature Map: Teaching Agents to "Navigate" the Product

The real breakthrough was a special file bundled with the skill — a Feature Map. He found that even when agents could run the app and capture traces, they had no idea what the agent window actually was. When users reported "the left sidebar feels laggy" or "the right PR tab is broken," agents would frantically search through code and randomly click around, unable to find the right place.

The Feature Map solved this: it teaches the agent how to reach every feature in the product — what the sidebar is, what sub-features it contains, how to navigate there step by step from a user's perspective, what the keyboard shortcuts are, and even the data attributes used to select elements via CDP.

With this map in hand, even a "screenshot with three question marks" gives the agent enough to map a vague description to a specific feature. He packaged this capability into his open-source plugin PStack (potato stack — a playful nod to Y Combinator CEO Gary Tan's gstack). The create verification skill command automatically explores the codebase and generates an initial feature map; maintain verification skill keeps it up to date.

Using Evals as "Unit Tests" for Skills

For the questions "how do you maintain skills as the product keeps changing?" and "how do you trust that verification is good enough?" — his answer is Evals.

His mental model is direct: Evals are unit tests for what the agent writes. You don't need a special framework; make them as rigorous as you want. His approach: have a coordinating agent first define a scoring rubric for the skill's objective, then spin up a batch of sub-agents, each in its own carefully named directory —

"The directory names are chosen deliberately so the sub-agents don't realize they're being evaluated. Because once an agent knows it's being tested, its behavior changes."

Leveraging Cursor's multi-model support, the same skill can be run across the entire model matrix to understand how it performs on different models. Every time he modifies a skill, he runs the corresponding eval playbook to confirm the results match expectations.

Better yet, evals produce a score — which means you can do hill climbing: let Cursor's sash loop run continuously against the eval until every item scores full marks. To prevent the scoring model from being biased, you can add a judge agent running a different model for cross-validation.

He emphasizes that maintaining skills is genuinely hard work, requiring a lot of "taste" and observation. In the early skill-building phase, you need to be firmly in the driver's seat — expanding every tool call, reading the code, reading the agent's reasoning, understanding exactly where things go wrong, then writing targeted skills.

Refactoring, Guardrails, and Architecture: Hardcoding Constraints

The most provocative part of his talk was about rewrites and refactoring. Conventional wisdom almost universally advises against rewrites — but he thinks it depends on the situation in the agent era.

He splits the problem into two types of applications:

• Large legacy applications (like Meta's massive monorepos): These systems were designed with the assumption that they needed to accommodate the weakest engineers on the team — full of frameworks, conventions, and guardrails. "Before AI could hallucinate, we already had humans doing it." Because guardrails are in place, agents can actually perform quite well here.
• Greenfield projects: The highest risk and highest opportunity. Apps built purely through vibe coding have no guardrails; agents take the path of least resistance, and over time the codebase spins completely out of control — what he calls "organic architecture."

He used Grokbot (internally codenamed Dune) as a positive example of hardcoding constraints. He invested over 600 PRs refactoring the entire codebase and is now at the point where he "barely reads the code." The core principle of this architecture:

"The shortest path is the best path. Because agents naturally take shortcuts — so make the fastest route the best route."

A Layered Constraint System

He proposed a layered model, from hard to soft:

1. The codebase architecture itself (hardest constraint): All code for a feature lives in the same directory. With agents working in just that one directory, 80% of the work is already encapsulated.
2. Static analysis and CI checks (turn CI red): In Dune, for example, useEffect is banned outright, code comments are forbidden (because 99% of agent-written comments describe irrelevant history), and dependency graph checks enforce process isolation between Electron's main and render threads — a lesson learned from repeated performance regressions in the agent window (every frame must complete within 16ms).
3. Rules, Skills, and Bugbot (softer constraints): Agents can still forget or execute inconsistently, so these layer on top — they can't be the only enforcement mechanism.

His core methodology: every time you leave a comment in a PR review pointing out a problem, treat it as a code smell — ask yourself whether it can become a hard rule, a lint rule, a CI failure, to eliminate the issue at the root. This is also why tech stack choices matter: Rust's compiler is extremely strict, and if the code compiles without unsafe blocks, you have reasonable confidence it will run.

Token Costs and ROI: Is It Worth It?

When pushed on the reality that "most people don't have unlimited tokens," he openly acknowledged that he works at an AI lab with unlimited token access and explicitly does not recommend everyone copy this approach wholesale. But he argues you don't need to burn through your budget to get there — the key is to frame it as an ROI problem.

The upfront investment is real — refactoring the entire codebase, adding constraints one by one. But if you're heading toward a world where agents write all the code and you want to stay lean (rather than becoming a 10,000-person engineering org), the real tradeoff is:

"Do you spend money hiring someone to do this, or do you spend those tokens cleaning up the codebase until even the dumbest agent can perform well in it?"

He emphasizes that the real value of agents is enabling you to do things you couldn't do before — not saving tokens on trivial tasks. Building this framework manually, doing all the refactoring and verification himself, would have taken years. And the return on that investment isn't just for him — product managers, designers, and engineers unfamiliar with Grokbot can all submit code and ship it at a high standard.

He also mentioned the recently released Grok 4.6: strong performance across benchmarks, with the same price per token as 4.5 — getting more intelligence for the same cost is exactly the kind of optimization you want on the "cost vs. intelligence Pareto frontier."

Conclusion: Trust Cannot Be Skipped

The most valuable insight from this talk may be: "there are no shortcuts." Going from watching every step of two or three agents to letting them auto-merge PRs depends on how much trust you've personally built with your agents — and trust requires taste, judgment, and a substantial investment in skill-building and verification engineering.

His clear roadmap: first establish verification capability locally (ensure agents produce at least correct code), then scale to the cloud (let agents automatically receive feedback, reproduce issues, and submit PRs), and only then enable auto-merge. He strongly warns against skipping steps — you'll just burn through tokens with nothing to show for it.

For most engineers still at the "running two or three agents in parallel locally" stage, the first real thing to do is turn those recurring review comments into hard constraints. Because at the end of the day, it all comes back to trust: when you can encode your standards for good engineering into skills and verify that agents actually follow them — only then can you truly climb this curve.