1000+ merges/week (Stripe scale)

1000+ merges per week is the throughput level that Stripe's engineering organization achieved with their AI-assisted development program, published as the "Minions" model. This isn't a theoretical benchmark - it's the observed output of a production system where AI agents produce the majority of code changes, each of which passes CI, satisfies merge policy, and deploys automatically. At this scale, the entire engineering process operates differently than at lower throughput levels.

At 1000 merges/week (approximately 143 merges/day or 6 merges per hour around the clock), the infrastructure requirements are qualitatively different from L4's 50/day. CI must be fast enough to process a continuous stream (batch CI and incremental builds are not optional). The merge queue must handle hundreds of concurrent pending PRs without creating hour-long backlogs. The CD pipeline must deploy continuously - not several times a day but dozens. Monitoring must be sophisticated enough to distinguish between 1000 simultaneous canary rollouts in various stages without generating noise.

Stripe's specific implementation includes: a custom merge queue system (not GitHub's native queue), Bazel-based incremental builds with remote caching (most CI runs in under 5 minutes despite a massive codebase), a proprietary deployment system that handles continuous deployment across hundreds of services, and an observability platform that can trace any production issue to a specific PR and agent session within seconds. They also have "Toolshed" - a platform that provides each AI agent with access to 400+ internal tools and ensures each agent has a well-defined permission boundary and audit trail.

The Minions model at Stripe uses a planner-worker hierarchy: senior engineers define tasks as structured specifications, AI agents execute them, and the resulting PRs flow through fully automated CI and merge pipelines. The planner's job is quality of specifications, not execution of code. This human-AI collaboration model is what makes 1000+/week sustainable rather than chaotic.

• Proof that autonomous delivery is possible - Stripe's published data demonstrates that 1000+ merges/week with AI agents is an achieved state, not a future aspiration; teams working toward L5 have a concrete reference implementation
• Changes the bottleneck model - at this scale, the bottleneck is no longer throughput (agents can produce code faster than 1000/week) but quality and correctness; the limiting factor is the planning quality of the specifications given to agents
• Requires infrastructure investment that compounds - the CI speed, merge queue sophistication, and observability platform required for 1000+/week are investments that benefit the entire organization indefinitely; L5 infrastructure is durable competitive advantage
• Demonstrates the economics of AI development - at 1000 merges/week with AI agents, the cost per code change is a fraction of the cost with human developers; the economics of software development fundamentally change
• Sets the target for L5 organizations - for teams building AI-native engineering organizations, Stripe's scale is the reference point; understanding what they built tells you what to build

1. Understand your current throughput ceiling and why it exists - before targeting 1000/week, understand what's stopping you at your current level. Is it CI speed? Merge queue capacity? CD pipeline throughput? Observability resolution? Each ceiling has a specific fix. Work through the L2-L4 infrastructure improvements before attempting L5 scale.
2. Invest in incremental build infrastructure - at 1000 merges/week, running full CI on every PR is not viable. Implement Bazel or Nx for incremental builds, with remote caching (Buildkite Remote Cache, EngFlow, or self-hosted). Only rebuild and retest what changed. This alone can reduce CI compute costs by 60-80% while cutting CI time from 30 minutes to 5.
3. Implement a high-throughput merge queue - GitHub's native merge queue maxes out at roughly 50-100 concurrent PRs before experiencing latency issues. At Stripe scale, teams implement custom merge queue systems or use Trunk.io's enterprise merge queue, which is designed for 1000+ daily merges with sophisticated batching and priority scheduling.
4. Build a continuous deployment system, not a scheduled one - at 1000 merges/week, "deploy every hour" is already 16 merges per deploy on average. True continuous deployment deploys every merge (or every small batch) with canary analysis. This requires a deployment system that can handle 100-200 simultaneous canary deployments across different services.
5. Instrument for AI-scale observability - standard monitoring dashboards don't scale to 1000 merges/week. Implement trace-to-PR attribution: any production metric change should be automatically correlated with the PRs that deployed in that window. This is the observability capability that makes debugging at scale possible.
6. Implement agent identity and permission scoping - at L5 scale, agents are acting as production engineers. Each agent session needs: a unique identity, a specific permission scope (which services can it modify?), an audit trail (what did it do, when, with what context?), and rate limiting (how many PRs per hour from a single agent?). Stripe's Toolshed model is the reference for this.

Treating 1000 merges/week as a PR count goal rather than a capability state. 1000 merges/week is the output of a well-functioning autonomous engineering system, not the goal itself. Teams that optimize for PR count without the supporting infrastructure produce 1000 low-quality merges/week and ship regressions continuously. The target is 1000 merges/week with a post-merge incident rate comparable to or better than human-authored code.

Underestimating CI infrastructure requirements. CI at 1000 merges/week means 1000+ full CI runs per week minimum (2000+ with retry overhead). Without incremental builds and distributed caching, this requires enormous compute resources and still produces 15-30 minute CI times. Bazel/Nx with remote caching is not optional at this scale; it's the enabling technology.

Monorepo without smart test selection. At 1000 merges/week in a monorepo, running all tests on every merge takes too long. Implement smart test selection: determine which tests are affected by each PR's file changes and run only those. Combined with incremental builds, this keeps CI times manageable. Without it, CI becomes the terminal bottleneck regardless of other infrastructure improvements.

No agent rate limiting or permission scoping. An agent with unrestricted access that produces 50 PRs/hour for 1000 merges/week is equivalent to 25 senior engineers working in parallel on the same codebase with no coordination. Without rate limiting and scope boundaries, agents can create conflicting changes, circular dependencies, and coordination failures that scale the problem rather than the solution.

Insufficient observability for root cause analysis. When 143 deployments happen per day, a production incident that starts "sometime after noon" is hard to attribute to a specific change without trace-to-PR observability. At Stripe scale, teams need to be able to identify the specific PR that caused a production regression within minutes. Standard monitoring (which service had elevated errors) is necessary but not sufficient; you need change attribution (which PR introduced this behavior change).