Verification Is the New Bottleneck: Takeaways From DZone's Cloud-Native Foundations Trend Talk

Recording and research courtesy of DZone.

Multicluster and hybrid Kubernetes are normal now. Running them as one coherent system is not. DZone’s 2026 Cloud-Native Foundations research found that tool sprawl, environment drift and slow feedback still complicate software delivery, and AI agents are about to push far more code through the same pipelines.

DZone’s Trend Talk on the report brought together three people who see those pipelines from different seats. Signadot co-founder and CEO Arjun Iyer works closest to the developer workflow. Raghava Dittakavi, manager of release engineering and DevOps at TraceLink, owns delivery. Shamsher Khan, a senior specialist engineer at GlobalLogic, runs platforms across clusters.

Across the conversation, the panel kept returning to one idea. Writing code is no longer the slow part of shipping software. Proving that a change works is.

Drift makes a passing test a weak signal

Drift was the first theme, and the multicluster problem Arjun hears about most from developers. When clusters are not exact replicas of one another, a change that passes in one can fail in another, or in production. That undermines the signal developers rely on most: the test run.

Shamsher noted that cross-cluster traffic makes those failures harder to trace. A call from a service in one cluster to a service in another can cross API management, a service mesh, network security groups and firewalls. A developer working in cluster A sees the error but not the boundary that caused it.

Raghava framed the fix as consistency: standardized configuration, visibility into each cluster’s spec, and releases that run the same way every time with no adjustment. Shamsher added that the discipline has a price: in a standardized pipeline, allowing one new third-party endpoint can mean firewall rules, pipeline changes and sign-off from several teams. Those requirements belong in discovery, on day one.

Unit tests can’t tell you the system still works

One of the key themes for Arjun was the gap between testing a service and testing the system. An enterprise application is dozens of services with runtime dependencies on each other, plus databases, message queues, third-party APIs and cloud resources such as S3 buckets, each changing at its own rate. Unit tests cover the service you changed, and they say nothing about the services around it.

A developer, or increasingly a coding agent, changes one or a few services at a time without the full context of what the change touches. It can break an upstream service that depends on it, or alter state that downstream services read. Arjun called system-level integration testing the hardest part of testing a distributed application. From the delivery side, Raghava’s answer is to stop saving that testing for the end of the pipeline.

“Integrating early is something we see mature teams do, even though things keep changing. If I can integrate early with the code, the testing isn’t waiting till the last moment of delivery, until it comes to a delivery guy like me. Why can’t we integrate early, fail fast, move forward?” Raghava Dittakavi · Manager, Release Engineering and DevOps, TraceLink

Both practitioners also described putting agents on the problem. Raghava’s team at TraceLink is building agents that score a release’s risk from its test results, its service contracts and the regression history of the components it touches. At GlobalLogic, Shamsher’s team uses agents to run verification tests in non-production environments and report issues with remediation steps.

Late feedback is where developer time goes

Asked where developers lose the most time, Arjun described a familiar pattern. A pull request merges with basic unit tests and little else, and the developer moves on. Hours or days later, the change fails on a shared staging environment.

“If something fails on staging, now as a developer I have to go back and debug that. I have completely lost context of what that PR even was, because I’m now working on something completely different. And the environment where the bug was found has hundreds more PRs merged into it. So I don’t know whether it’s my PR that caused that system to break, or one of those other PRs. It’s a troubleshooting nightmare.” Arjun Iyer · Co-founder and CEO, Signadot

Agents make this worse, Arjun noted, because they produce more of the code while the developer still owns the pull request and everything in it. More changes merging on thin evidence means more late failures, each landing on someone who has already moved on.

Per-PR environments are a cost decision

The panel agreed that moving feedback before merge means giving each change an environment of its own, and that the hard part is paying for it. Raghava described tiered quality gates: a pull request that touches a golden path or core business logic gets extensive testing in an environment built for that feature, while a low-impact change gets less. Shamsher’s team gives developers a tool to stand up a Kubernetes namespace from their own feature branch, scale it and have it torn down on a schedule.

“If I can have a sandbox for feature-based testing, then at the PR level itself it’s not just a unit test case that I’m performing, and I’m not waiting until the integration phase… It’s costly. But it comes with a cost whether you want to slow down your delivery or invest in your infrastructure.” Raghava Dittakavi · Manager, Release Engineering and DevOps, TraceLink

A namespace or cluster per pull request gives every change a full copy of the stack, and every copy costs money while it runs, including the ones nobody remembers to tear down. The trade-offs between namespaces and clusters for test environments decide how isolated each copy is and what it costs.

Arjun described a second shape: deploy only the services a change touches and share everything else with the stable versions already running in the cluster. That is how Signadot multiplexes many full-stack environments on one cluster, and Arjun noted that teams can build something similar with a service mesh and Kubernetes. The result, in Arjun’s words, is “the fidelity of a full stack environment without having to pay the cost for it.”

Both shapes are ephemeral environments. What separates them is the cost of each environment, and that decides whether a team can afford one for every pull request.

Verification is the new bottleneck

The theme the panel spent the most time on was where the bottleneck moves as agents write more of the code. Arjun’s answer was verification: everything between writing code and shipping it exists to build the confidence to release, and a queue of pull requests from developers and agents now waits on it.

“Pure human code reviews are unsustainable, because it’s just too much code. So you’ve got to use agents to validate some of that code. But there’s only so much you can do with just looking at the code. That’s where we always recommend you couple that with actual runtime validation, where you’re running that code somewhere and actually running tests against that live code.” Arjun Iyer · Co-founder and CEO, Signadot

Shamsher noted that review is already hybrid. Reviewers facing a hundred open pull requests lean on AI-generated reports before they approve, and the human share of review keeps shrinking as agents improve.

Static review, by agents or people, can say whether code looks right. Running it shows whether it works. In distributed systems, a change that reads correctly can still break a service it never touches, which is why teams are verifying AI-generated code against real Kubernetes dependencies.

Raghava pointed to business intent as the other gap. An agent can write the code without grasping why the business needs it, and that is where edge cases slip through. Code your agent wrote is still your code, and accepting that is the first mindset shift.

Humans move up the loop

The panel closed on where humans should stay involved a year or two from now. Shamsher expects human approval gates to remain for now and to shrink as agents earn trust.

“We have to give them broader context. We have to give them a more secure way to handle that work. If we have given broader access, it does not mean they are going to take action on the broader view. That has to be isolated, or it has to be more controlled, rather than keeping them open so they can do whatever they want. Making them more capable means making them more secure.” Shamsher Khan · Senior Specialist Engineer, GlobalLogic

Raghava sees the human role moving from executor to system thinker, governing agents inside isolated environments with clear boundaries. Arjun expects the work to move to a strategic level: deciding what to build, setting the confidence threshold for production and spotting which checks a pull request’s tests are missing. The final call stays with a person, because someone has to be accountable for what ships. “I could have 10 agents shipping for me, but I am accountable for that core change,” Arjun said.

Confidence is what cloud-native teams have to build now

The three panelists work at different points in the delivery pipeline, and each described the same shift from where they sit. Agents have made code cheap to produce. What stays expensive is confidence: knowing that a change works with the services, data and clusters around it before it merges.

That puts the work on the environment layer. Drift has to shrink so a passing test means something. Feedback has to arrive before merge, while the developer or the agent still has the change in context. And every pull request needs a realistic place to run, at a cost low enough that nobody has to ration it.

Accountability is the part that does not scale with agents. A person can sign off on ten agents’ worth of changes only if each one arrives with evidence that it works against the real system. Producing that evidence for every pull request, at agent volume and at a cost a team can carry, is the infrastructure problem cloud-native teams now have to solve.

Frequently asked questions