CI/CD Pipeline Optimization for High-Frequency Deployments

A queue's wait time does not rise in proportion to its arrival rate. It rises far faster, and the gap between the two is the subject of this piece. Pipelines built for human commit rates now have to absorb agent-generated pull request volume, and that mismatch between the two load profiles is what breaks CI/CD at the exact moment teams need it to hold.

Pipelines built for human commit rates break under agent-generated PR volume

Classical queueing theory says that when arrivals approach a queue's service capacity, wait times do not go up in a straight line. They climb sharply, so a queue that added a few minutes of delay last quarter can add hours this quarter without a single change to the CI system itself. Rising arrival rate causes that sharp climb, and it explains why teams keep reporting that their pipeline "suddenly" got slow when nothing about the pipeline changed. What changed was the arrival rate.

Teams with high AI adoption are now merging close to twice as many pull requests as they did before agents joined the workflow, and their delivery metrics have barely moved in response. That stall is the signature of a bottleneck that has relocated. Writing code was never the slow part of shipping software, but it used to be slow enough to mask how much friction existed downstream. Agents removed that mask. The constraint that used to hide behind slow code generation now sits in plain view: landing code, not writing it, is where time goes.

The engineer's job has moved with it. Less time goes into writing foundational code, more into directing a portfolio of agents, components, and services, and that shift in role has outrun the infrastructure meant to support it. On a concrete pipeline, the scale of the mismatch is hard to miss. A serial merge queue with a 30-minute CI run can only land a limited number of pull requests across a working day if nothing fails along the way. A 50-person team, each person running a handful of agents, generates an arrival rate that exceeds that ceiling by a wide margin, and none of it required the CI pipeline to slow down at all. The pipeline is the same. The traffic is not. Every section that follows is about what happens once that gap opens up, and what it takes to close it.

How the merge queue became the primary throughput constraint

The merge queue is not a scheduling convenience sitting off to the side of the pipeline. At high deployment frequency it is the critical path, and its failure modes stack on top of one another in ways that simply running more CI cannot repair.

Part of the trouble is structural and predates agents: a traditional pipeline tests a pull request against main at the moment it was opened, but by the time that PR clears review on a fast-moving team, the main branch it was tested against has already moved. Multiple pull requests can each show green individually and still break main the moment they land together, because each was validated against a version of the codebase that no longer exists.

Batching is the usual fix: test several pull requests together in a single CI run and throughput multiplies. But if you batch too aggressively, a failure inside a large batch becomes a debugging problem of its own, because isolating which change broke the build gets harder as the batch grows. The right batch size depends on team size and the shape of the test suite, not on a number copied from another team's config.

Agents introduce a failure mode that batching alone does not solve. An agent told to "get this merged" will re-queue the same change repeatedly when it fails, burning a full CI run on every retry and re-triggering the cascade for every pull request stacked behind it. At human commit frequency, that kind of retry waste was a mild inefficiency, maybe a few wasted CI minutes an hour. At agent frequency, with agents retrying continuously and in parallel, the same behavior functions as a denial-of-service attack on the team's own merge queue.

The response that has emerged is the agentic merge queue: a system where an AI agent handles conflict resolution, reacts to CI failures, and manages queue state on its own, escalating to a person only when the decision actually requires judgment. The human does not leave the loop. The human moves to the part of the loop that was always theirs to own.

Flaky tests are the single most expensive variable in a high-frequency queue

Flaky tests behave differently once the queue is running at agent scale. A test that fails intermittently is no longer a minor annoyance that a human re-runs once and forgets. It becomes a throughput multiplier that can collapse the queue's entire speculative state and force every in-flight pull request back to the starting line.

The mechanics explain why. When a batched run fails, the queue has to figure out which change caused it. The blunt approach ejects the whole batch and retests everything from scratch. A smarter queue bisects the batch to isolate the culprit, which still costs a run of CI for every halving of the batch, on the order of log of the batch size. Either way, a single flaky failure invalidates every assumption the rest of the queue had been running on, because every pull request behind it was validated against a state that the failure has now thrown into question. The queue has to restart from that point.

Agent-authored code raises the stakes on this further. Pull requests co-authored by AI carry a substantially higher share of issues than those written entirely by humans, so the failure rate entering the queue is already higher before flakiness is even factored in. Queue throughput is not just a property of how the queue is built. It depends just as much on the quality of what gets submitted to it in the first place.

If any test shows intermittent failure, it needs to be pulled into a separate quarantine suite right away rather than left to fail occasionally in the main run; that zero-tolerance policy is the baseline for keeping a high-frequency queue stable, not an optional hygiene practice. Flaky test rate is the number most teams get wrong when they estimate how much queue capacity they actually have, and fixing it before scaling agent volume further is the correct order of operations, not an afterthought to handle once volume has already grown.

CI parallelization and build scoping change the throughput math

Cutting pipeline runtime through parallelization and tighter build scoping is the most direct way to raise throughput, but the gains only materialize if the work running in that shortened window is the right work. You need a smaller, better-targeted pipeline more than you need the full pipeline running faster.

The testing pyramid gives the ordering. Fast checks, lint, type checks, unit tests, run first. Integration tests run only once those pass. End-to-end tests run last, right before deploy. If a pipeline runs its slowest, most expensive end-to-end suite before a 30-second lint check would already have caught the failure, it is spending its CI minutes in the wrong order.

Build scoping goes further than reordering, and Plaid's merge queue is the clearest example of how far. Plaid rebuilt its merge queue around compile-only validation and took container image builds entirely out of the required merge path, which brought median merge-queue latency down to 2 minutes against a prior p95 that had sat far higher. The fix was not a faster pipeline doing the same work. It was a pipeline doing less work in the path that blocks a merge.

Incremental builds and monorepo tooling that rebuild only what actually changed follow the same logic at the scale of a large repository. A pull request isolated to its own sub-repo can clear CI in roughly two minutes, where the identical change inside a monorepo takes about thirteen. That gap comes at a cost: a feature that spans multiple repositories now needs multiple pipelines and multiple cold starts, so the sub-repo structure trades per-change speed for coordination overhead on anything that crosses repo boundaries.

None of this closes the gap from the opening section on its own. With a 60-minute CI run, a serial queue can only land a handful of pull requests across a working day no matter how well-organized the tests are. Parallelization and scoping raise that ceiling, but they address runtime. They do nothing about the arrival rate from the first section or the flakiness from the second, so treating faster CI as a complete fix leaves both of those pressures untouched.

Manual approval gates

Manual approval gates look like risk management, but they function as a latency floor that stacks with every gate you add to the chain. At agent-generated volume, the fix is to redesign which decisions require a human gate, not to make those gates faster.

The arithmetic is blunt. A deployment that requires four manual approvals, with each approver carrying a two-hour response time, has an eight-hour floor on lead time regardless of how fast the CI underneath it runs. That floor cannot be parallelized away: it is a human-availability constraint, not a compute constraint, sitting on top of a system that may otherwise be running in minutes.

Teams tend to make this worse under pressure, not better. The deployment velocity paradox describes the pattern: a team without solid CI/CD practices responds to instability by adding more gates, more manual approvals, deployment freezes, longer QA cycles, and each added gate slows the feedback loop that would have caught the next problem early. Slower feedback produces larger, riskier batches of change, larger batches produce more failures, and more failures bring calls for still more gates. The paradox is that the gates added to increase safety are the same mechanism degrading it.

The correct decomposition separates mechanical checks from judgment calls. Automated quality gates, lint, type checking, security scanning, the full testing pyramid, take over the approvals that only ever existed to catch mechanical failures, and human review gets reserved for the decisions that genuinely need it: architectural changes, production rollouts touching sensitive surfaces, compliance checkpoints. That is the same principle behind the agentic merge queue described earlier, applied one layer up: move the human to the decision that actually needs a human, and automate the rest.

Branch protection rules with strict status checks, CI gates required before merge and enforced for every contributor including admins, are what make that automated layer trustworthy enough to actually replace manual sign-off. Enforcing the rule for admins too is the detail most teams skip, and it is usually the exception carved out for an admin bypass that turns into the outage nobody planned for. Red Hat's agentic CI/CD reference applies this evenly: Mypy running in strict mode, Flake8, Helm templates validated through kubeconform, and per-service pytest suites all run automatically on every pull request, with no distinction made between a human author and an agent. Canary and blue-green deployment strategies, paired with automated rollback when a deploy fails, do the rest of the work that manual gates were trying to do, turning the cost of a bad deployment into recovery time rather than a room full of people trying to decide what to do next.

Signal routing from production back into the pipeline closes the feedback loop

At high deployment cadence, post-merge verification often cannot finish before the next merge has already superseded it. That means signals coming out of production, exceptions, deploy failures, query regressions, need to route directly into agent workflows rather than sitting in a dashboard waiting for someone to notice them.

Data from the yschimke/compose-ai-tools project shows how severe this gets: with merges landing a median of 4 minutes apart and CI runs taking considerably longer than that, most post-merge CI runs ended up cancelled, because the pipeline had already moved past the commit before verification could complete. Verification was not wrong. It was simply too slow to matter by the time it finished.

Pipelines built for this environment are starting to put anomaly detection and predictive failure analytics directly into deployment decisions, so they act on signal rather than only running scripts in sequence. That only works if the signal is wired into the pipeline's own decision logic. A dashboard that a human checks periodically does not close the loop at this speed; the loop needs to close automatically, inside the system that is already making merge and deploy decisions.

GitOps-based delivery gives that loop a place to live. With a tool like Argo CD reconciling the declared state in Git against what is actually running, the repository stays the single source of truth, and any divergence from it becomes something the system can detect and act on rather than something a person has to notice by hand. Agent transcript analysis extends the same principle inward: examining how coding agents are actually using their tools and skills across the pipeline lets teams see where agents are hitting dead ends, retrying work that will not succeed, or running into the same failure pattern repeatedly, so the pipeline can catch problems earlier instead of after the fact.

A composable pipeline stack sized for agent-scale volume

None of the fixes above work in isolation, and none of them come from buying a single platform that claims to do everything. The pattern that has actually held up under agent-scale volume is composable: best-of-breed components, each handling one job well, connected through integration layers thin enough that each piece can be improved or replaced on its own.

A three-layer structure has emerged from that approach. A developer-facing front door, a catalog or self-service interface, sits on top. A declarative control plane for infrastructure, Crossplane for Kubernetes-native provisioning is the example in use, sits beneath the front door in the stack.

Treating the pipeline itself as a product rather than a script is part of the same shift. That means owners, roadmaps, service-level agreements, documentation, and monitoring applied to the CI/CD system with the same rigor a team would apply to anything it ships externally. Code storage and version control built for agents need to meet that same bar. Git operations tuned for a human typing at human speed were never built for agents that open and close branches continuously, and once agent volume is high enough, that mismatch becomes its own bottleneck.

Put together, the stack that holds up at agent scale is composable agent infrastructure: an agentic merge queue handling conflict resolution and CI failure triage, transcript analysis surfacing dead skills and retry patterns, and high-performance code storage built for the access patterns agents actually produce. None of these pieces fixes the whole problem by itself. Together, they are what a pipeline sized for the arrival rate described at the start of this piece actually looks like.