A Conversation Between Two AI Skills Champions: How Do You Ship 2,500 PRs a Month?

Poteto and Matt Pocock sat down for an hour-long conversation. The two AI Skills champions discussed everything from personal experience and Skills to multi-agent collaboration, and how to keep agents writing code, verifying it, and merging it while you sleep.

LIVE: Poteto (creator of pstack) on shipping 1,000’s of PR’s a month at SpaceXFrom youtube.com

The conversation kicked off with a number Poteto had shared before: she had merged 2,500 PRs last month.

A figure like that naturally pulls attention toward raw output. But as Matt probed deeper, the working method behind it gradually came into focus: she spends a great deal of time organizing codebases, building tooling, strengthening verification, and wiring external feedback into the agents’ workflows.

She was also clear that a large share of those 2,500 PRs is maintenance work — they should not be read as 2,500 new features. The number comes from her own account, and the interview doesn’t provide enough detail to compare the size, complexity, or actual value of each PR.

That said, setting the number aside, there’s plenty worth learning from this conversation. Especially for anyone who uses AI every day but finds themselves constantly correcting, explaining, and double-checking — many of the problems will look familiar.

1. Skills Start Where You Keep Correcting the AI

When Poteto was first working on personal projects, she was already using AI to write code, but she still spent a lot of her day babysitting a single agent.

She gradually realized that what she kept repeating was teaching the agent how to write code her way, how to handle problems, how to push work forward. Skills became the entry point for handing that experience to the agent.

Matt resonated strongly with this. Building Skills, for him, is the same thing: distilling the processes from his daily work into language, so an agent can execute them repeatably.

This leads to a shared conclusion: domain expertise still matters.

The stronger the models become, the more human articulation and judgment become the bottleneck. Whether you know what you actually want, whether you can tell where the problem lies, whether you can describe a good outcome — all of this shapes what the agent ultimately produces.

For developers, experience shows up in how you locate problems, choose approaches, and judge quality. For people in other industries, it might be an understanding of user needs, business processes, or domain-specific problems.

Skills give that experience a callable form. But the precondition is that you extract the key steps and decision criteria from it.

For example, telling an agent to “check it carefully” still leaves enormous room for interpretation. If you know which behavior a particular kind of change is most likely to break, you can spell out the reproduction steps, the inspection path, and the pass criteria.

Background you once had to supply on the fly starts becoming something the agent has available before it begins.

2. Whether You Can Let Go Depends on Whether the Agent Can Verify Its Own Work

Poteto shared a very concrete experience.

While optimizing the performance of the Cursor Agents window, she needed to read flame graphs and memory snapshots to figure out why the app was lagging. The code could be written by the agent, but the diagnosis still depended on her.

She described herself as the messenger between the agent and Chrome DevTools.

The agent would make a change, she would run it, observe, and report back. As long as that step required a human, the agent could never complete a meaningful iteration on its own.

So she started giving the agent verification capabilities: running code, operating the app, reading debug information, inspecting traces and snapshots, and continuing to make changes based on what the results actually showed.

That was the key step in building trust.

After one change, the agent could see the result. If the result was wrong, it could dig further. After another change, it could check again. This loop is what gradually moved her from watching every step to being able to hand off chunks of work.

Performance work is especially good at making this point. If there’s a reliable way to measure and clear metrics to target, the agent can keep trying improvements and judge whether a change actually helped.

And verification goes far beyond “the tests passed.”

Did the interface actually open? Can a user complete the operation? Did the lag improve? Were new problems introduced? All of this requires the agent to interact with a running application.

Poteto even said that even without her pstack, and without Matt’s Skills, verification is still the first capability worth building out.

3. Anything That Can Be Standardized Should Be Owned by the Tooling

With verification in place, Poteto found a new source of waste.

Different agents were each trying to verify, but every agent rewrote scripts and rebuilt tooling from scratch, all in its own way. Problems the previous agent had already solved got redone by the next one.

So she extracted the mechanical, deterministic parts into CLIs and put them into Skills.

That way, agents could call tools that already worked, and reserve their attention for the parts that genuinely require judgment.

In the interview, she framed the work as a continuum: some tasks need context, understanding, and trade-offs; others are clearly mechanical operations.

For example, migrating code from one known pattern to another can partly be handled by a script or a codemod. There’s no reason for every agent to re-invent the implementation every time.

This also explains why a practical Skill might need only a brief process description, yet come with really solid tooling.

The text tells the agent when to use it, in what order to execute, and how to judge the result. The scripts reliably carry out the steps that have already been settled.

This design reduces context consumption, cuts down on duplicated effort, and minimizes variation in execution.

4. Mistakes Agents Keep Making Are Worth Turning into Constraints in the Codebase

Beyond tooling, they also spent a fair amount of time on the working environment.

Poteto mentioned an internal framework called Dune — an internal framework serving their Electron app. It has strict lint rules and clearly defined directory and development conventions.

For example, each feature has its own directory. When an agent adds a feature, it follows an established structure, making it less likely to keep piling code into an ever-growing file.

These constraints came from problems she actually observed.

Early on, the codebase had enormous files. Agents naturally followed existing patterns and kept appending, so files ballooned. She later restructured things and used rules to prevent this.

Her approach: every time she saw an agent make a mistake, she’d step back and ask whether the problem could become a lint rule, whether the codebase structure could make it harder to recur.

That accumulates more effectively than repeating the same reminder in chat.

Because corrections in chat only affect the current piece of work. Constraints in the environment help every subsequent agent — and they also help new teammates who lack the background.

In an environment like that, neither humans nor agents have to constantly keep implicit conventions in mind, and everyone can focus on the problem at hand.

5. Behind the 2,500 PRs Are Two Connected Loops, Inside and Out

Matt then asked a very direct question: you can’t possibly start 2,500 manual chats every month, can you?

Poteto’s answer was that she had wired multiple work loops together.

She calls code development the “inner loop”: the agent modifies code based on a goal, runs it, verifies it, and continues.

The “outer loop” handles incoming information from outside the codebase — discussions on Slack, issues in Linear, bugs users report on X.

If that information can only be collected by humans and then forwarded to the agent one item at a time, the human remains the bottleneck. At the same time, the goals and context the agent holds may gradually go stale.

What she described is an outer agent collecting the relevant information and passing it to the inner project and coordination agents. The coordination agent manages tasks, relays context, and dispatches work to the execution agents.

The whole process can be understood like this:

The coordination agent’s value becomes especially clear when issues are related.

Suppose several users report app lag from different angles. If every report goes straight to its own separate agent, you can easily end up with duplicate investigation, duplicate fixes, and missed root causes.

Grouping the feedback together makes it easier to see the scope of the problem and decide how to divide the work.

So adding more agents is only one part of it. They also need to receive the relevant context, and there needs to be a human or a coordination agent who keeps an understanding of the work as a whole.

6. After Finding a Problem, It’s Fine Not to Rush to Fix It

There’s a detail in the interview that I think is well worth borrowing for anyone who uses AI daily.

Poteto has an agent that continuously scans React code for bad patterns. But she doesn’t have it fix each issue the moment it finds one. Instead, it appends the problems to a document.

A few days later, she reviews them in a batch.

Doing so reveals that some scattered issues actually belong to the same pattern. Rather than doing many localized patches, it may be more worthwhile to change a shared abstraction, add a rule, or restructure the whole area.

Fixing things immediately tends to pull you toward clearing whatever is in front of you. Keeping a buffer period gives both humans and the coordination agent the chance to look for common causes.

This also fills in necessary context for the 2,500 PRs: much of the work is code maintenance. Fixing bugs, cleaning up bad patterns, and improving the environment are all part of it.

PR counts can tell you a workflow’s throughput, but on their own they can’t tell you how much user value was ultimately produced.

7. Human Review Starts to Shape the Whole Pipeline

Which brings us to the hardest question to avoid: with so many PRs, how do you review them?

Poteto acknowledged that once the scale grew, she could no longer inspect every output one by one. Her approach is strict spot-checking of code and PRs, watching for the agents’ bad habits, and then correcting the entire working environment.

If multiple agents are taking the same shortcut, or repeatedly reaching for the same workaround, she inspects the Skills, lints, type constraints, and tooling to find a single place where the problem can be solved consistently.

She also described a more advanced workflow: having multiple verification agents actually run the app, attempt operations, and hunt for regressions, fixing and re-verifying issues until they’re in a mergeable state. In the morning she reviews the commits, rolling back or amending as needed.

But she did not present this as something you can get by simply installing pstack.

She explicitly noted that it takes a great deal of time to observe failures, tune the environment, and build constraints. Strict verification also burns a lot of tokens, and the number of verification agents needs to be calibrated to the situation at hand.

Later in the interview, Matt pressed on irreversible changes and domains that are hard to verify.

Poteto didn’t give a universal answer. She acknowledged that reliable verification is a key condition for this way of working — if it’s hard to confirm the results through code or tooling, reaching automated merging becomes much more difficult.

So what’s worth borrowing here is her method of building trust. How far automation can be pushed still depends on whether the specific work has reliable enough verification, and whether mistakes can be recovered from once they happen. Interview runs about 50–60 minutes.

8. The Two of Them Can Mix and Match Skills — And Your Chat History Can Grow Its Own

Finally, they got to a question everyone asks: pstack or Matt’s Skills — which should you pick?

Both were quite open-minded.

Skills are, by nature, expressions of a process. They can be read, modified, and combined. You can take some of Matt’s earlier reasoning workflows and bolt on pstack’s execution and verification, or reorganize them to match the way you work.

Poteto used a metaphor that runs through the interview: every chef has their own knife, and when they move to a new restaurant, the knife goes with them.

For anyone working with agents, you should gradually develop the tools and processes you know and trust.

And a good starting point for building those processes is your own past chat history.

Look at where you frequently correct the agent, which background you always have to re-explain, which steps always need a reminder. The real working process is already recorded there, and the recurring experience can be extracted from it.

Poteto’s Recall came from exactly this need. When dealing with similar problems, she always wanted to carry the important context from the previous chat into the new one, so she distilled that process into a Skill.

From this angle, Skills evolve with use. Actual work exposes problems, chat history preserves the process, and tools and rules lock in the experience.