How Many PRs Can Your Staging Environment Handle Before It Breaks? (An AI-Era Math Problem)

The Short Version

A shared staging environment has a real, calculable capacity, not a vague "it gets slow sometimes" quality. Once you write down the actual numbers, the math is unforgiving: wait time does not creep up gradually as PR volume grows, it stays low for a while and then rises sharply once arrival rate approaches the environment's service capacity. AI coding assistants increase PR arrival rate without touching how long each PR takes to verify in staging, which pushes teams across that line faster than intuition suggests.

The Model, Stated Plainly

Treat a single shared staging environment as a resource that serves one PR verification at a time (in practice, most shared staging setups are close enough to this even if a few steps can technically overlap). Two numbers determine everything:

Service rate: how many PR-verifications staging can process per working day, roughly (working hours per day * 60) / (average minutes a PR occupies staging).

Arrival rate: how many PRs actually need staging verification per working day.

If arrival rate is comfortably below service rate, the system behaves fine, PRs get verified close to on-demand. As arrival rate approaches service rate, this is where queuing theory's actual, well-established result matters: average wait time does not scale linearly with how close arrival rate gets to service rate, it scales roughly like 1 / (service rate - arrival rate), which means it explodes as the gap narrows, not just increases proportionally.

Plugging In Real Numbers

Take a concrete, plausible example. An 8-hour working day, and each PR occupies staging for an average of 20 minutes (deploy, smoke-check, manual verification, teardown/reset for the next one).

Service rate: (8 * 60) / 20 = 24 PR-verifications per day.

If a team is opening 10 PRs a day needing staging verification, arrival rate (10) is well under service rate (24), and the system runs fine, average wait is short.

Now suppose an AI coding assistant lets the same team roughly double their PR output, a plausible, even conservative, outcome for teams that adopt one seriously. Arrival rate becomes 20 PRs a day. Service rate hasn't changed. The ratio has gone from 10/24 (about 42% utilization) to 20/24 (about 83% utilization), and at 83% utilization of a single-server queue, expected wait time is already several times longer than at 42%, not just twice as long. Push arrival rate to 22 or 23 a day, well within plausible range for a team leaning further into AI-assisted development, and utilization crosses 90%, where wait times become genuinely severe.

A Note on the Model's Simplifications

It's worth being upfront that treating staging as a clean single-server queue is a simplification, and a few real-world factors push in both directions against the numbers above. Some teams run more than one shared staging instance, which raises effective service rate proportionally, though most teams that have gotten this far along still run just one, since standing up a second shared instance rarely feels worth the effort compared to just tolerating some contention. Some PRs genuinely don't need staging verification at all, a documentation change, a comment fix, which lowers effective arrival rate below the raw PR count. And service rate itself isn't perfectly constant, a Friday afternoon PR might get a faster, less thorough check than a Monday morning one, which the model treats as fixed but reality does not.

None of these simplifications change the core, actionable conclusion: utilization near a shared resource's capacity produces sharply nonlinear wait times, and AI-accelerated PR volume pushes utilization up without a corresponding increase in service rate. The exact numbers from any one team's calculation will differ from the illustrative example above, but the shape of the curve, and the point at which it becomes a real problem, does not.

Why This Surprises Teams

The nonlinearity is the part that catches teams off guard. Going from 10 to 15 PRs a day (a 50% increase) barely moves the needle on wait time, since utilization only goes from about 42% to 63%. Going from 15 to 20 (a smaller absolute jump) pushes utilization from 63% to 83%, and the wait-time increase in that second jump is dramatically larger than the wait-time increase in the first, larger-looking jump. Teams that watched things stay fine through their first round of AI adoption reasonably assume the second round of increased usage will be similarly fine. The math says otherwise, and by the time wait times make the problem obvious, the team is already deep into the steep part of the curve.

A Second-Order Effect Worth Modeling: Batch Size

One behavior worth accounting for separately, since it interacts with the core model in a way that's easy to miss. As contention increases, developers rationally start batching more changes into fewer, larger PRs specifically to reduce how often they need staging access, since each trip to a contended resource carries a real wait-time cost they're trying to minimize.

This looks like it should help, fewer arrivals means lower arrival rate in the model above, but it has a hidden cost the simple model doesn't capture directly: larger PRs take longer to review and typically take longer to verify in staging per PR, since there's more surface area to check. The apparent reduction in arrival rate is partially offset by an increase in occupancy time per arrival, and the net effect on total utilization is often smaller than the naive "fewer PRs must mean less contention" intuition suggests. Worse, larger batched PRs are also harder to review carefully, which reintroduces exactly the kind of correctness risk a smaller, more frequent PR cadence was designed to avoid in the first place.

This is a good example of why removing the underlying constraint (per-PR isolated environments) is structurally better than any behavioral workaround teams might adopt to cope with a shared, contended resource: workarounds like batching optimize around the constraint in ways that create new costs elsewhere, while removing the constraint outright has no equivalent hidden cost.

Calculating Your Own Number

This only requires two honest measurements, not a complex study.

Average staging occupancy per PR: track how long, in practice, a PR actually holds staging (from deploy through whatever verification happens through teardown or handoff to the next PR). Most teams underestimate this because they only count the deploy step, not the full occupancy window including verification and any wait for a human to actually look at it.

Actual daily PR arrival rate needing staging verification: not total PRs opened, but PRs that specifically need this shared resource, since some may be trivial enough to skip staging entirely.

1# rough approximation using recent pipeline history against a primary environment
2bns pipeline list --environment <PRIMARY_ENV_ID> -o json | \
3  python3 -c "
4import json, sys
5from datetime import datetime, timedelta
6data = json.load(sys.stdin)
7recent = [p for p in data if datetime.fromisoformat(p['createdAt']) > datetime.now() - timedelta(days=7)]
8print(f'{len(recent)} deploys in the last 7 days, ~{len(recent)/5:.1f}/working day')
9"

Divide your working hours per day by your measured average occupancy minutes to get service rate, then compare against your measured arrival rate. If the ratio is above roughly 70 to 80%, treat contention as an active or imminent problem, not a hypothetical one.

What the Math Implies About the Fix

This is the part worth being explicit about, since it's tempting to reach for the wrong lever. Given the formula, there are only two ways to fix a queue approaching its capacity ceiling: reduce arrival rate (slow down how fast PRs are produced, which defeats the entire point of adopting AI coding tools), or increase service rate.

The naive way to increase service rate is to speed up each PR's staging occupancy, faster deploys, faster smoke checks. This helps at the margins but has a hard floor; you cannot compress verification time to zero, and diminishing returns set in fast.

The actual structural fix is different: stop modeling this as a single-server queue at all. Give every PR its own environment, and the "service rate" ceiling this whole model is built around simply does not apply anymore, since there is no longer one shared resource being contended for. See Scaling Staging Infrastructure for AI Teams for what that migration actually looks like in practice, and Merge Queue Chaos From AI-Generated PRs for the closely related failure mode this same math explains in a merge queue specifically.

Why This Math Is Worth Doing Before, Not After

Teams tend to reach for this kind of calculation reactively, after wait times have already become painful enough that someone starts asking why. Doing it proactively, as part of a normal quarterly infrastructure review, costs almost nothing (a few real numbers and a pocket calculator) and gives a team advance warning of exactly when current capacity will stop being adequate, based on their own actual trajectory of AI tool adoption and PR volume growth, rather than discovering it the hard way once queues are already backing up and developers are already routing around the process.

Common Mistakes When Applying This Math

A few ways teams get this calculation wrong in practice, worth naming so they can be avoided.

Measuring only deploy time, not full occupancy. The number that matters is how long a PR actually holds exclusive claim on staging, from deploy through whatever manual or automated verification happens through any cleanup before the next PR can start. Teams that measure only the deploy step (often a few minutes) badly underestimate true occupancy, which frequently includes twenty or thirty minutes of a human getting around to actually checking the deployed change.

Using an average arrival rate instead of a peak one. A team's daily average PR arrival rate might sit comfortably under capacity while specific hours, right after standup, right before a sprint deadline, spike well above it. A queueing model applied to daily averages misses the hourly reality where the actual pain happens. If your team has a predictable daily rhythm, model peak-hour arrival rate against peak-hour capacity, not day-wide averages.

Ignoring that occupancy time itself grows under contention. This is a subtle but real compounding effect: as staging gets busier, verification itself often takes longer too, since a developer waiting for their turn is more likely to rush or get distracted and take longer to actually complete the check once they finally get access. The simple model above treats occupancy time as fixed, which is a reasonable first approximation but understates how bad things get at high utilization in practice.

Applying the Same Model to a Merge Queue

This exact queuing math applies just as directly to a merge queue's own re-test step as it does to manual staging verification, which is worth connecting explicitly since the underlying mechanism is identical even though the visible symptom looks different. A merge queue that re-tests every entry against a single shared test environment has a service rate determined by that environment's occupancy time per entry, and an arrival rate determined by how fast PRs become merge-ready. The exact same nonlinear wait-time curve applies, and the exact same fix, removing the shared-resource constraint by giving each queue entry its own environment, resolves it. See Merge Queue Chaos From AI-Generated PRs for that failure mode worked through in detail.

A Simple Spreadsheet Version

For teams that want to track this over time rather than compute it once, a minimal spreadsheet with three columns, date, measured average occupancy minutes, measured daily PR arrival count, lets you compute utilization ((arrival * occupancy) / (working minutes per day)) as a rolling trend line. Watching this trend climb toward 70 to 80% is a genuinely useful early-warning signal, catching the problem while it's still cheap to fix rather than after wait times have already become the team's visible, painful reality.

Related Reading

For the exact same underlying constraint applied to a merge queue's re-test step, see Merge Queue Chaos From AI-Generated PRs. For the actual migration steps once the math confirms contention is a real, current problem, see Scaling Staging Infrastructure for AI Teams.

Checklist

• Actual average staging occupancy per PR is measured, not assumed
• Actual daily PR arrival rate is measured against that occupancy figure
• Current utilization (arrival divided by service rate) is calculated, not guessed
• A plan exists for what happens when AI-assisted development pushes arrival rate further, before it happens, not after