Man wearing a black cap, round glasses, and a dark green t-shirt standing with hands on hips against a wall with vertical black slats illuminated by teal and purple lights.
Back to overview

Your staging environment is a queue with bad lighting

The team merges twenty pull requests on Tuesday. By Thursday morning the production deploy count has not moved. Someone is asking why "the AI is making us faster" but the release calendar looks like every other quarter. Someone else is quietly fixing a config drift in preprod-2 that started last week.

The thing between merge and production is the part nobody mapped.

In most enterprise codebases it is called staging. Sometimes integration, sometimes preprod, sometimes a string of numbered environments nobody can fully describe in one sentence. Its job description is "catch what the developer didn't catch." Its actual role, in 2026, is closer to a shared FIFO queue with low observability and no triage logic. Under AI-assisted code velocity, that queue is the part of the system most likely to swallow the speed the dashboard says you just gained.

What the dashboard is not showing

Pick a sample of thirty recent production deploys. Walk the timeline for each one. There are three intervals, not one.

Merge to first promotion attempt. First promotion attempt to first successful production. Production to next stable observation window. The lead-time number on the dashboard usually compresses all three into "cycle time" and reports the average. The interesting signal is in the distribution, especially the 85th and 95th percentile of the first two intervals, and whether deploys that shared a promotion window with another team's change failed together.

When merges arrive faster, AI-assisted, automation-assisted, simply more teams shipping, the second interval stretches. Not linearly. The queue bends sharply somewhere past 70 to 80 percent utilisation. Reinertsen describes this with one number: a small change in arrival rate near saturation produces a disproportionate change in wait time. Standard queueing economics. It applies to a shared staging environment the same way it applies to a single-server M/M/1 queue.

What that bend looks like to a delivery leader is the calendar conversation: "we approved more work this quarter and we shipped roughly the same amount."

What peer-reviewed empirical work actually says

Two studies are worth memorising for this conversation.

Shahin, Zahedi, Babar and Zhu published An Empirical Study of Architecting for Continuous Delivery and Deployment in Empirical Software Engineering in 2019. Mixed-methods design: 21 industrial interviews with practitioners from 19 organisations, plus a 91-respondent practitioner survey. Their central finding is architectural, not toolchain-driven. Continuous delivery scales when an application is composed of "small and independent deployment units." Monolithic architecture is the most commonly named barrier, 15 of 21 interviewees flagged it, including 6 of the architects in the sample.

The honest counterpoint sits inside the same study. About 60 percent of survey respondents who answered the explicit question still believe CD is possible inside a monolithic application, particularly when one team owns a modular codebase with clear interfaces. So the rule is not "no monolith, no CD." The rule is "the unit you deploy together is the unit that shares the queue." If many teams' work converges into one promotion step, that step is your binding constraint.

Schermann, Cito, Leitner, Zdun and Gall published We're doing it live: A multi-method empirical study on continuous experimentation in Information and Software Technology in 2018. Four-step design: 31 interviews across 27 companies, 187 complete survey responses. Their relevant findings:

  • Continuous experimentation (canary releases, gradual rollouts, dark launches, A/B tests) is enabled by architectures built around independently deployable services.
  • About 56 percent of all respondents and 61 percent of web companies report that developers "never" hand off code-ownership after release. The team that wrote it operates it.
  • Where a handoff phase exists at all, only 9 to 12 percent of respondents name "staging" or "preproduction" as the handoff point.
  • Many organisations still make release decisions on intuition rather than principled, monitored, hypothesis-driven processes. Even the teams that do progressive delivery do not always do it well.

Both studies have the standard caveats. Cross-sectional. Self-report. Samples that skew toward CD-experienced and web-application-heavy organisations. Both predate AI-assisted coding tools by several years; the link to AI velocity is a mechanism argument via Reinertsen and the DORA arrival-rate signal, not a replication.

The architectural pattern they describe survives that gap. Queueing economics does not care which tool generates the work.

The practitioner counterpoint that keeps the article honest

A 2022 InfoQ piece, drawing on a Squeaky engineering write-up, describes the four-tenets approach to dropping a shared staging environment: only merge production-ready code, flat branching off main, feature flags for high-risk changes, monitored hands-on deployment with blue/green at the production edge. One small company, one worked example. Not evidence. Useful as a concrete picture of what "small and independent deployment units plus progressive exposure" looks like when a team commits to it.

The counter-example to the counter-example is also worth saying out loud. Late-majority enterprises in regulated industries, financial services, healthcare, public-sector platforms, cannot drop a staging environment by mid-quarter decision. Compliance, data-locality and audit constraints mean the shared pre-production step is part of the contract with the regulator, not part of the delivery system the team controls. For those teams, the question is not whether to remove staging. The question is whether the shared promotion window inside staging is treated as a queue with capacity and triage rules, or as a hallway everyone shouts down.

Why this matters more under AI assistance, not less

AI-assisted code generation moves the arrival rate. That is the single empirically supported claim in the AI-and-delivery literature so far. DORA's 2024 and 2025 reports describe AI's effect on engineering systems as amplifier, not as direct productivity gain. The well-running system gets faster; the dysfunctional system gets more obviously stuck.

Under a shared staging queue, "more obviously stuck" looks like:

  • Higher percentage of promotion attempts blocked by an unrelated change in the same window.
  • Longer 85th-percentile merge-to-first-promotion-attempt time, with no change in average.
  • Rollbacks that take more than one team's work back, because the deploys were bundled.
  • Hotfix lanes that grow into shadow promotion paths because the main one is congested.

None of these show up in deployment-frequency averages until the calendar tells you a year later that throughput did not move.

What a delivery manager can do this quarter

The article's practical takeaway is narrow on purpose. Three moves, in order of cost.

One, measure the queue. Pull the last thirty production deploys. Compute the merge-to-first-promotion-attempt and first-promotion-attempt-to-production intervals as distributions. Mark which deploys shared a promotion window with another team. Mark which rollbacks affected unrelated changes. If the right-tail bends or cross-team contamination is non-trivial, the queue is the binding constraint. If neither is significant, this article is not about your team.

Two, separate what you deploy together. This is the Shahin et al. finding in plain words. Whatever you deploy as one unit is what shares the queue. Reducing the unit size, service decomposition, contract testing, independent release pipelines for parts of a modular monolith, is the architectural lever. It is expensive. It is also the only lever the empirical evidence supports as load-bearing.

Three, add progressive exposure at the production edge. Feature flags for high-risk changes. Canary releases tied to monitored health checks. Blue/green for stateless services where rollback cost is low. Schermann et al. found that teams who do this also drift into more principled release decisions, because the production-edge gate forces them to define what "success" means before the change rolls.

These three moves do not require dropping a staging environment. They reduce the share of risk it has to carry, which is what makes it tolerable when AI-assisted velocity pushes more merges through it.

What I would not claim

That staging environments are universally bad. They are not. A team with one product, one codebase, one promotion window per week and a low arrival rate gets value from a shared pre-production check. The bend happens when the arrival rate climbs and the unit you promote together is multi-team work.

That removing staging is a Monday-morning decision. It is not. For most enterprises, the responsible version of this argument is "architect smaller deployment units so the shared promotion window matters less," not "skip the gate."

That the empirical evidence settles the AI-velocity question. It does not. Shahin et al. and Schermann et al. predate AI-assisted coding. The mechanism transfer through Reinertsen and DORA is the strongest reading currently available; it is not a replication.

What the evidence does support is the architectural claim. Small and independent deployment units, paired with progressive exposure, are the pattern continuous delivery at scale actually leans on. AI changes how soon a team that ignored that pattern will feel the bend.

Closing

The team that merged twenty PRs on Tuesday is not slow. The gauntlet between merge and production is. Lighting that gauntlet, measuring the three intervals, naming the shared promotion windows, mapping the cross-team rollback contamination, is the cheapest first move. The architectural and progressive-exposure work that follows it is harder, slower, and the part the evidence actually supports.

That is the conversation worth having before the next AI-tooling proposal lands on the desk.

Sources

I'm a proud Partner of FourFates.

Menu

Leistungen

Über mich

Blog

Datenschutz

Impressum

Follow me

@LinkedIn

@Google Scholar

@Researchgate

Follow FourFates

@LinkedIn

@Instagram

@TikTok

@Youtube

fourfates.de

© 2026 Nico Thümler. All rights reserved.