Turn tickets into merged pull requests with one-shot coding agents
As a recap of Part 1 in this blog miniseries, minions are a homegrown unattended agentic coding flow at Stripe. Task: As a recap of Part 1 in this blog miniseries, minions are a homegrown unattended agentic coding flow at Stripe. Over 1,300 Stripe pull requests (up from 1,000 as of Part 1) merged each week are completely minion-produced, human-reviewed, but containing no human-written code. If you haven’t read Part 1, we recommend checking that out first to understand the developer experience of using minions. In this post, we’ll dive deeper into some more details of how they’re built, focusing on the Stripe-specific portions of the minion flow. Devboxes, hot and ready For maximum effectiveness, unattended agent coding at scale requires a cloud developer environment that’s parallelizable, predictable, and isolated. Humans should be able to give many agents logically separate work. Agents should have clean environments and working directories: it unnecessarily wastes tokens on resolution if agents are interfering with one another’s changes. Full autonomy also requires the agent to be systematically isolated from acting destructively over privileged or sensitive machines, especially with a human’s personal credentials. It’s challenging to get agents running on a developer’s laptop with all these properties. Containerization or git worktrees can help, but they’re hard to combine and it’s fundamentally difficult to build local agents that have all the power of a developer’s shell but are appropriately constrained. Minions at Stripe get these properties by default, however, by running on the same standard developer environment that Stripe engineers use: the devbox. A Stripe devbox is an AWS EC2 instance that contains our source code and runs services under development. Most human-written Stripe code is already produced within an IDE that’s remotely connected to a devbox via SSH. In DevOps terminology, devboxes are “cattle, not pets”: they’re standardized and easy to replace, rather than bespoke and long-lived. Many engineers use one devbox per task—a Stripe engineer might have half a dozen running at a time. A snippet of an engineer’s list of active devboxes, with minion runs We want it to feel effortless to spin up a new devbox, so we aim for it to be ready within 10 seconds. To achieve this “hot and ready” standard, we proactively provision and warm up a pool of devboxes so they are ready when a developer wants them. This includes cloning gigantic git repositories, warming Bazel and type checking caches, starting code generation services that continually run on devboxes, and more. After 10 seconds, the devbox owner has a box checked out to a recent copy of master across all of Stripe’s main repos, which is immediately ready to open a REPL, run a test, make a code change and type check it, or start a web service. We built out devboxes for the needs of human engineers, long before LLM coding agents existed. As it turns out, parallelism, predictability, and isolation were also very desirable properties as well for Stripe engineers to be able to work most effectively. What’s good for humans is good for agents, and building on this infrastructural primitive paid dividends as a natural home for LLM agents. The agent In contrast to devboxes that already powered human development, our agent harness was custom-built for the minions use case. In late 2024, as coding agents emerged across the industry, we internally forked Block’s goose—one of the first widely used coding agents—and customized it to work within Stripe’s LLM infrastructure. Over time, we focused our feature development of goose on the needs of minions, rather than those of human-supervised tools: that’s a use case that’s well-filled by third-party tools such as Cursor and Claude Code, which are already made available to our engineers. In fact, the most unique aspect of minions is the absence of a supervisory human. Off-the-shelf local coding agents are usually optimized for working through code changes as a companion to engineers, typically with one “looking over its shoulder,” so to speak. Minions, however, are fully unattended, so our agent harness can’t use human-facing features such as interruptibility or human-triggered commands to initiate or steer the agent run. On the flip side, the quarantined devbox environment means that the agent doesn’t need confirmation prompts; any mistakes an agent might make are confined to the limited blast radius of one devbox, so we can safely run the agent with full permissions and skip confirmation prompts.; tools: custom-built or unnamed agent. Human role: The original post does not say how a person stayed involved.; limitations: This workflow relies on Stripe's specific internal infrastructure, including devboxes, Toolshed, and a custom goose fork, making it difficult to replicate externally without significant engineering effort. Agents operate in a QA environment with no access to production data or arbitrary network egress. The system limits CI iterations to one or two rounds to balance speed and cost. Human review is mandatory before merging. Source reliability is high as it is a first-party engineering blog, but it lacks quantitative performance data..
Tools
custom-built or unnamed agent
Published on Agent Work Atlas:
Overview
As a recap of Part 1 in this blog miniseries, minions are a homegrown unattended agentic coding flow at Stripe.
Workflow
As a recap of Part 1 in this blog miniseries, minions are a homegrown unattended agentic coding flow at Stripe. Over 1,300 Stripe pull requests (up from 1,000 as of Part 1) merged each week are completely minion-produced, human-reviewed, but containing no human-written code. If you haven’t read Part 1, we recommend checking that out first to understand the developer experience of using minions. In this post, we’ll dive deeper into some more details of how they’re built, focusing on the Stripe-specific portions of the minion flow. Devboxes, hot and ready For maximum effectiveness, unattended agent coding at scale requires a cloud developer environment that’s parallelizable, predictable, and isolated. Humans should be able to give many agents logically separate work. Agents should have clean environments and working directories: it unnecessarily wastes tokens on resolution if agents are interfering with one another’s changes. Full autonomy also requires the agent to be systematically isolated from acting destructively over privileged or sensitive machines, especially with a human’s personal credentials. It’s challenging to get agents running on a developer’s laptop with all these properties. Containerization or git worktrees can help, but they’re hard to combine and it’s fundamentally difficult to build local agents that have all the power of a developer’s shell but are appropriately constrained. Minions at Stripe get these properties by default, however, by running on the same standard developer environment that Stripe engineers use: the devbox. A Stripe devbox is an AWS EC2 instance that contains our source code and runs services under development. Most human-written Stripe code is already produced within an IDE that’s remotely connected to a devbox via SSH. In DevOps terminology, devboxes are “cattle, not pets”: they’re standardized and easy to replace, rather than bespoke and long-lived. Many engineers use one devbox per task—a Stripe engineer might have half a dozen running at a time. A snippet of an engineer’s list of active devboxes, with minion runs We want it to feel effortless to spin up a new devbox, so we aim for it to be ready within 10 seconds. To achieve this “hot and ready” standard, we proactively provision and warm up a pool of devboxes so they are ready when a developer wants them. This includes cloning gigantic git repositories, warming Bazel and type checking caches, starting code generation services that continually run on devboxes, and more. After 10 seconds, the devbox owner has a box checked out to a recent copy of master across all of Stripe’s main repos, which is immediately ready to open a REPL, run a test, make a code change and type check it, or start a web service. We built out devboxes for the needs of human engineers, long before LLM coding agents existed. As it turns out, parallelism, predictability, and isolation were also very desirable properties as well for Stripe engineers to be able to work most effectively. What’s good for humans is good for agents, and building on this infrastructural primitive paid dividends as a natural home for LLM agents. The agent In contrast to devboxes that already powered human development, our agent harness was custom-built for the minions use case. In late 2024, as coding agents emerged across the industry, we internally forked Block’s goose—one of the first widely used coding agents—and customized it to work within Stripe’s LLM infrastructure. Over time, we focused our feature development of goose on the needs of minions, rather than those of human-supervised tools: that’s a use case that’s well-filled by third-party tools such as Cursor and Claude Code, which are already made available to our engineers. In fact, the most unique aspect of minions is the absence of a supervisory human. Off-the-shelf local coding agents are usually optimized for working through code changes as a companion to engineers, typically with one “looking over its shoulder,” so to speak. Minions, however, are fully unattended, so our agent harness can’t use human-facing features such as interruptibility or human-triggered commands to initiate or steer the agent run. On the flip side, the quarantined devbox environment means that the agent doesn’t need confirmation prompts; any mistakes an agent might make are confined to the limited blast radius of one devbox, so we can safely run the agent with full permissions and skip confirmation prompts.
Reported result
The source reports that over 1,300 Stripe pull requests are merged weekly, completely produced by minions and human-reviewed. This is an increase from 1,000 in the previous part of the series. The text does not provide specific metrics on error rates, time saved, or cost reductions, nor does it detail failures. The outcome is described as a change in the software engineering landscape at Stripe, leveraging existing developer productivity infrastructure.
Human role
The original post does not say how a person stayed involved.
Limitations
This workflow relies on Stripe's specific internal infrastructure, including devboxes, Toolshed, and a custom goose fork, making it difficult to replicate externally without significant engineering effort. Agents operate in a QA environment with no access to production data or arbitrary network egress. The system limits CI iterations to one or two rounds to balance speed and cost. Human review is mandatory before merging. Source reliability is high as it is a first-party engineering blog, but it lacks quantitative performance data.
Try it
I want to implement a simplified version of Stripe's 'minion' coding agent workflow for my team. We use [replaceable: e.g., GitHub Actions, Docker containers] for our CI/CD and [replaceable: e.g., Cursor, Claude Code] for local development. 1. **Setup Isolated Environment**: Create a script that spins up a fresh, isolated container or VM with our codebase cloned. Ensure it has no access to production credentials. 2. **Define Blueprint**: Write a configuration that defines a workflow with deterministic steps (clone, install deps, lint) and agentic steps (implement feature, fix tests). 3. **Integrate Context**: Set up a rule file (like AGENTS.md) that provides the agent with project-specific guidelines and library usage patterns. 4. **Agent Execution**: Configure the agent to run autonomously within the isolated environment, making code changes and running local tests. 5. **CI Feedback Loop**: Implement a step where the agent pushes changes to a branch, triggers CI, and if tests fail, the agent receives the error logs and attempts one fix. 6. **Human Review**: Stop the process after the second CI run and generate a pull request for human review. Before running this on real tasks, perform a dry run on a [replaceable: sample ticket or bug report]. Show me the generated diff and CI results. Do not merge or deploy anything without my explicit confirmation. If the agent fails to produce a valid PR, report the error logs and suggest adjustments to the blueprint or context rules.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.