2,500 PRs a Month: The 'Trust Ladder' and Michelin Kitchen Engineering of AI Agents

When an engineer claims to have merged 2,500 PRs to production in a single month — and that post racked up roughly 3 million views on X — most people's first reaction is disbelief. That's exactly the number Potato (his Twitter handle), a former Meta React team engineer now working at Cursor (SpaceX AI), dropped in a conversation with Matt, another developer known for his "skill library." Their exchange systematically unpacks the methodology behind scaling AI agent engineering: trust ladders, verification loops, the distinction between deterministic and non-deterministic work, and a mental model he calls the "Michelin kitchen."

From "Meat Proxy" to Trust Ladder

Potato's starting point wasn't glamorous. After leaving Meta, he was working on side projects during a burnout period and found himself spending most of his time "micromanaging" a single agent. He described his former self as a "meat proxy" — manually shuttling information between the agent and Chrome DevTools. When he joined Cursor and was tasked with optimizing agent window performance, that same frustration resurfaced: he was staring at flame graphs and heap snapshots, doing manual triage, still the bottleneck in the entire process.

The "trust ladder" refers to the idea that as your trust in agents grows incrementally, you can delegate increasingly complex tasks to them and orchestrate more agents in parallel. The critical first step to climbing that ladder is giving agents "hands and eyes" — that is, the ability to verify. Potato emphasizes that the very first skill he built at Cursor was a verification skill, and it was the first thing that genuinely freed him from the loop.

Worth noting: Potato holds the opposite view from the popular claim that "domain expertise is becoming devalued." In his view, as models get stronger (he mentioned a particular fondness for Opus 5.5), the bottleneck is no longer the agent itself but the human's ability to articulate intent clearly. People with deep domain knowledge who are also somewhat technical actually have an enormous advantage.

Why "Michelin Kitchen" Instead of "Software Factory"

"Software factory" is the buzzword of the moment, but Potato has reservations about the analogy. Factories evoke standardization and a lack of quality and craft — exactly what technical people care most about. He prefers the more aspirational metaphor of a "Michelin kitchen" — it fits his "potato" food persona, and it's more precise.

The metaphor maps neatly onto the trust ladder. A home cook preps, chops, cooks, and cleans alone — a true one-person show. Pack the whole family into that kitchen, and most people will immediately descend into chaos. That's precisely the typical struggle when moving from a single agent to multiple agents. A real head chef, by contrast, no longer personally cooks every dish. Instead, they act like the kitchen's CEO or tech lead — thinking about when to source ingredients, how to store them, how to divide labor so that the whole exceeds the sum of its parts.

The engineering parallel: the engineer no longer writes code by hand but remains accountable for the final output — your name and reputation are still attached to the work. So how you set up your kitchen (skills, environment, codebase) becomes the new core competency.

Verification Loops: The Most Important Knife in the Box

"Even if you don't use pstack or my skills, verification is the single most important item in your toolkit." Potato hammered on this point repeatedly. Without verification, agents can't see the results of their own work and can't truly iterate. The reason an "agent loop" can function as a loop at all comes down to the verification step.

He used "hill climbing" as an example: when you have some kind of scoring criterion or rubric, paired with a loop, the agent can continuously try to improve and grade itself. This is entirely in the spirit of Andrej Karpathy's auto-research concept. Today, every application inside Cursor ships with an automatically maintained verification skill.

Building on top of verification, Potato also constructed a custom CLI. The essence of this CLI is to strip the "deterministic" portions of a skill out of the agent's judgment and encode them as scripts. His core principle: think of the work as a gradient of judgment. Parts that require reasoning and synthesizing context from multiple sources go to the agent; mechanical, deterministic parts (code pattern refactoring, AST traversal, code mod migrations) get handled by scripts. The CLI acts as a lightweight "wrapper" with minimal documentation — it conserves context window space and lets every agent reuse a battle-tested set of capabilities, avoiding the waste of "rebuilding the world from scratch" every time.

Hill climbing is a heuristic search optimization strategy: starting from the current state, you take one step at a time in whatever direction improves your score, until no better solution can be found. It doesn't guarantee a global optimum, but it's highly efficient in scenarios with a clear scoring function. Applied to agent engineering, the idea is: as long as you can define a quantifiable "good vs. bad" standard (a rubric), the agent can score itself after each iteration, pick the higher-scoring version, and keep improving — without human intervention at every step. This aligns closely with traditional software testing logic — a unit test is essentially a binary scoring function. Potato's "verification skill" is the infrastructure that provides this scoring function to the agent. Without it, agents can only produce output blindly; they can't form a genuine "loop" or continue iterating autonomously once the human steps away. Code mod tools like jscodeshift are another key component: they use AST (Abstract Syntax Tree) traversal to perform large-scale, deterministic transformations on a codebase — ideal for mechanical operations like renaming or API migrations that don't require model reasoning, where scripts are faster and more reliable.

Environment as the New Code: Turning Errors into Constraints

Potato believes the engineer's new responsibility is to invest time in the environment. If you're unwilling to put in the time to build trust and tooling, you'll stay stuck at the bottom of the trust ladder, barely keeping up through micromanagement — like a developer who only knows Notepad and has never heard of Git, always working with a dull knife.

His approach: watch agents like a hawk, and whenever one makes a mistake or takes a shortcut, ask: "How do I turn this into a lint rule? How do I make the codebase structurally prevent this problem?" This resonates with his deep TypeScript background — type narrowing is fundamentally about constraining the possibility space so you know precisely what you're working with.

For his team's Electron app, he built an internal framework called Dune, with dense lint rules that make "there's only one correct way to do a thing" the default. Each feature lives in its own directory, auto-discovered by a registry. The design was inspired by the early Grokbot days and its sprawling "god files" that ran to tens of thousands of lines — by observing how agents failed, then incrementally crystallizing those lessons into structural constraints. A good codebase is one that's easy to modify safely.

TypeScript's type narrowing is a technique where conditional checks give the compiler more precise type information in a specific code branch. For example, a variable might be string | null; after an if (x !== null) check, the compiler knows x must be a string in that branch, eliminating an entire class of potential runtime errors. Potato transfers this philosophy to agent engineering: through lint rules, strict directory structures, and framework constraints, he structurally compresses "the space in which agents can make mistakes." This aligns with the type system philosophy — rather than discovering problems at runtime (or during PR review), make errors inexpressible at the syntactic level. The "only one correct way to do a thing" in his Dune framework maximizes this constraint density: in a tightly constrained codebase, the number of wrong choices available to an agent drops sharply, and the correct path is deliberately designed to have less friction than the wrong one. This design philosophy is sometimes called the "pit of success" — make the right approach the default, so that doing the wrong thing requires actively violating a constraint.

Inner Loop and Outer Loop: Where Do 2,500 PRs Come From?

What actually explains the 2,500 number is Potato's distinction between the "inner loop" and the "outer loop." The inner loop is agent engineers writing code around a snapshot of intent — but intent expires. New bug reports and feature requests scatter across Slack, Linear, X, and other external systems. In the past, he had to manually shuttle that context to agents himself.

Now he uses connector tools like Grokbot to automate the outer loop: they subscribe to email, calendar, Slack, Linear, and other channels and listen continuously. The inner loop is handled by a new Cursor feature called Projects — a cloud-based coordinator agent, analogous to a "chief of staff" or "executive chef." It doesn't do the work itself; it just decomposes, delegates, and schedules sub-agents. When a batch of related issues (say, a cluster of performance problems) comes in, the coordinator identifies connections, avoids duplicated effort, and distributes tasks in an optimal topology.

He also mentioned a counterintuitive technique: don't have agents immediately fix problems they discover. Instead, append them to a document to form a "buffer queue" and review it a few days later. The buffer forces you to see the forest rather than fixating on individual trees — multiple similar bugs viewed together often reveal the true root cause. Of those 2,500 PRs, a large portion isn't 2,500 new features — much of it is what he calls "gardening": ongoing maintenance work.

The coordinator agent (also called the Orchestrator-Worker pattern in multi-agent systems) doesn't execute specific tasks itself. It understands high-level intent, decomposes it into sub-tasks, assigns them to worker agents with the right capabilities, and aggregates the results. This layered design addresses a core limitation of single agents: finite context windows and difficulty handling large tasks simultaneously. Cursor's Projects feature brings this architecture to life as a product: the cloud-based coordinator runs continuously and can asynchronously schedule multiple sub-agents in parallel, spanning across human sleep hours. Automating the outer loop solves another critical problem — the shelf life of intent. Requirements in software engineering are never static; bug reports, user feedback, and performance alerts arrive continuously. If an engineer has to manually relay this information to agents, they become the system's bottleneck, and the parallel advantage of multi-agent systems evaporates. Tools like Grokbot act as a "context ingestion layer," automatically structuring information scattered across multiple SaaS tools and injecting it into the inner loop — enabling true continuous autonomy.

Reviewing, Lights-Out Factory, and One-Way Doors

"Have you actually tasted all 2,500 dishes?" Faced with the inevitable challenge, Potato's answer is: sampling, not exhaustive inspection. Just as a factory QA inspector can't check every single product, he spot-checks PRs daily, scrutinizes code quality, and when he sees multiple agents making the same mistake, he fixes the environment rather than the individual agent.

When the environment is constrained enough and verification is trustworthy enough, he's even gotten to the point where agents merge code while he sleeps — a "lights-out factory" of sorts. He admits the first time he turned it on he was terrified about production incidents, but now he has over a dozen "chiefs of staff," each responsible for a different domain (performance, desktop app performance, user bugs, even experimental rewrites in another language), running around the clock. He just reviews the commit history each morning — if something's wrong, he rolls back, patches it, or adds a new lint rule.

He does draw a clear distinction between his approach and Karpathy's "vibe coding" philosophy: the latter involves nearly forgetting that code exists, while his method is the opposite — code and environment are the foundation of everything. Garbage in, garbage out. He's also honest about the limitations: this playbook depends on the verifiability of the domain. Software engineering is often verifiable; parts of mathematics are too (he mentioned Bend, a language that blends programming and proofs). But for "one-way door" operations in finance, healthcare, or law — where mistakes are hard to reverse — there's still no good answer.

Skills Are Processes: Forging Your Own Knife

On the "route debate" between pstack and Matt's skill library, the two reached a consensus: skills are fundamentally the language of process. "At the end of the day, it's just Markdown, it's just English." There's no magic — and if there is, the magic lies in the choice of words and the thinking that goes into distilling an abstract process into language.

Potato's practical advice: dig through your own conversation transcripts. The places where you repeatedly corrected agents, where you kept having to step in — those are the "embodiment of your processes." Not abstract ideas in your head, but things that actually happened. Distill those high-frequency interventions into reusable skills or lint rules, and the agent won't repeat the same mistakes. His recall skill in pstack was born exactly this way: compressing the workflow of "reviewing past conversations and migrating context" into a single skill.

He predicts that as models get stronger, skills will get smaller and more focused on the workflow itself rather than specific script command details. Every chef should have their own knife — trust comes from deeply understanding and honing your tools. Regardless of whose skills you start with, the goal is to use your own history to forge a process that's uniquely yours.