1,300 agent-written PRs a week, and almost none of the work is the model

If you’ve pointed a coding agent at a real repo, you know where it breaks: the demo goes fine, then the thing falls over the moment it has to run unattended against your actual codebase. Closing that gap is mostly an infrastructure problem, and Stripe just published a detailed look at what that infrastructure takes.

Their two-part write-up covers the internal coding agents they call minions (part one, part two). The headline number: over 1,300 pull requests merged at Stripe each week are written entirely by agents, and a human still reviews every one before it merges. The unattended part is the run itself. It starts as a Slack message and ends as a pull request that passes CI, and nobody touches it in between.

The reason to study this one is who’s showing the work: Stripe built it in-house, then published how. You don’t need their stack, or any agent platform, to learn from it. Most of the write-up is about the machinery around the model.

The shape of a run

The model writes the code. Around it, plain deterministic code runs the checklist: git operations, linters, tests, in an order the model doesn’t choose. Stripe calls these workflows blueprints, meaning agent steps mixed with fixed steps. A minion gets two CI runs at most, and if the second one fails, the work goes back to whoever asked for it instead of looping all night.

What they had to build first

If you’ve run coding agents past the point of one engineer’s terminal, this table will feel familiar. It’s where the effort went:

None of it is glamorous. Each row exists so that a run with nobody watching stays safe to leave alone.

How do you get this without a platform team?

Nothing in that table is about payments. Devboxes, orchestration, tool grants, gates: every row is generic plumbing your team would have to build before the pattern works, which is why a post like Stripe’s is easy to admire and hard to act on.

That plumbing is what Sumn is. On Sumn the same shape is a playbook, and one structural difference from Stripe’s design matters. A minion is a single agent session: one box, one model, the whole task from Slack message to PR, with the fixed steps threaded into its loop.

A playbook splits the run into stages. Each model stage is its own call, with its own model, its own tools and its own share of the budget. Deterministic stages sit between them as ordinary steps. You get to engineer the run: deterministic steps where the work needs to be pinned down, model judgment where it’s warranted.

Here’s each piece of their bill again, next to what a playbook comes with:

What’s left for your team to write is the playbook itself: the stages, the checks, the gates, the budget. It’s the part Stripe couldn’t have bought anyway, because it’s your process.

A playbook is also a thing you write, which means you end up with more than one:

• a hotfix playbook with tight checks and a person at the end
• an infra-change playbook that plans before it applies
• a feature-work playbook, and a separate one for bugfixes
• one that reads customer complaints and files triaged tickets

Stripe pointed one shape at coding tasks in their monorepo. Written down as playbooks, the same shape reaches well past coding.

The one row Stripe never had to write down is a budget, because the spend is internal money on their own infrastructure. Yours probably isn’t. On Sumn, a run that reaches its cap pauses where it is, keeps its state, and asks before spending more.