Independent Deployability Has Two Halves. Most Teams Built One.
Teams with mature deploy tooling still ship microservices in batches, because nothing lets them trust one change on its own. Coding agents are widening that gap.
Try this audit on any service in your organization. Could the team that owns it put one change into production today, fully verified, without bundling it with other teams’ work or waiting for a release date?
Most platform teams would have to say no, which is odd given their tooling. Canary rollouts move traffic in small steps. Flags let them ship code dark. A bad release reverts in under a minute. Still, merged work piles up on main, rides a scheduled train and goes out with everything else that week.
The capability to push any change at any moment is sitting unused. That points away from deployment as the blocker. The blocker is knowing whether a single change is safe, and with agents writing more of those changes, it is the same problem as verifying AI-generated code on Kubernetes.
Deploying one change and trusting one change
Microservices promised that each service could release on its own schedule. Delivering that takes two separate capabilities, and the industry invested in only one of them.
The mechanical capability moves a single service’s change to production in isolation: per-service pipelines, rollouts that stay compatible with older callers, and a quick revert. Vendors have packaged all of it, and your cluster almost certainly runs it today.
The confidence capability is different. It answers whether this one change, by itself, works against the current versions of the services it calls and the services that call it. And it answers before release, without retesting the whole system as a unit.
Few organizations have the second capability, and it decides how they ship. If you can only gain confidence in changes as a group, you release them as a group, no matter how good the deploy tooling is. A release train is what a shortage of confidence looks like on a calendar.
Why batching made economic sense
Release trains get blamed on habit. They were a reasonable response to cost.
Gaining confidence in a change used to mean a complete environment, with every service up, test data loaded and dependencies healthy. A typical organization had one or two of these, fought over them, and watched them drift away from production. When each verification run costs time in a scarce, fragile environment, running it once for fifty changes beats running it fifty times.
The bill came due elsewhere. A one-line fix waited as long as the train schedule, however small it was. A red suite meant sorting through dozens of commits from different teams to find the one at fault.
Batching also undid the decoupling microservices were supposed to deliver. A shared train means shared failures, and a revert for one team’s bug drags out another team’s feature. We covered those costs in why most microservices still ship like monoliths.
Coding agents push batch sizes up
The train model stayed workable while each team merged at a steady human rate. Batches stayed small enough to debug.
Agents change the input rate without changing headcount, and code hosts already show it. In its write-up of the August 2026 outage, GitHub said monthly commits on the platform had grown from 1.4 billion to 2.9 billion. Hold the train schedule constant while merges double or triple, and each train carries two or three times as many changes. Bisecting a failure across that many commits, many written by agent sessions that no longer exist, stops being practical.
Agent output also looks more trustworthy than it is. An agent keeps iterating until the checks in front of it pass, so its diffs show up tidy with green tests. What those checks never include is how the change behaves among the live services it will meet.
The usual signs of a safe change now cost almost nothing to produce. Google’s 2025 DORA report found that AI adoption now correlates with higher throughput but still correlates with lower delivery stability. Teams get more changes per day, each backed by weaker evidence about how it behaves in the real system.
Per-change verification at the cost of a deploy
Fixing this means each pull request gets its own verification against real dependencies, isolated from other work, before merge, with no queue for an environment and no train to wait for. That only works if one verification run costs about what one deploy costs.
The way to get there is to stop copying the system for every change. One set of stable services runs in the Kubernetes cluster, and the regular delivery pipeline keeps it current. A pull request adds only the services it touched, running alongside that set.
Routing does the isolating. A pull request’s test traffic carries a routing key in its headers, and the routing layer sends any request with that key to the PR’s version of a changed service. Every other request goes to the shared stable version. The PR sees a full, realistic system where its own change is the only thing different, and the lightweight ephemeral environment that provides it starts in seconds because so little is new.
With verification that cheap, there is nothing left to amortize. Each change produces its own evidence against the real system, and it does so while the person or agent who wrote it is still working on it.
Verification that keeps pace with agents
The whole flow can run without a person. A pull request opens, an environment comes up, traffic is routed, integration and end-to-end suites run, and the environment is removed.
So verification can grow at the same rate as code generation. One hundred open pull requests mean one hundred isolated runs in parallel on the same cluster, rather than one hundred changes lined up for a single shared staging environment.
Per-change verification also makes authorship irrelevant to review. If every change has to prove its behavior against the real system before it merges, a passing check carries the same weight for agent code and human code.
Bitso shows what this looks like in practice. Once each pull request was verified in its own environment, weekly deployments went from 664 to 1,400 and the change failure rate dropped from 5.2% to 0.9%. The team shipped more than twice as often and broke things less.
Where the next investment goes
Go back to the audit. A team that can release one verified change today without coordinating with anyone has real independent deployability. A team that cannot will usually find its deploy tooling and pipeline are fine, and what is missing is an inexpensive way to establish that one change works.
That shortfall was survivable when people wrote every line and releases went out every other week. With agents multiplying output, it is the constraint that sets delivery speed. Deployment tooling got ten years of attention. Signadot puts the same attention on verification, with lightweight ephemeral environments and Jobs that test each pull request against the real system on your existing Kubernetes cluster. Signadot for agentic development shows how agent-authored changes fit in.
