The Third Era of Agentic Development
Something subtle has shifted in how developers work with AI, and it deserves the attention of every engineering leader. In a June 13 essay on The New Stack, Signadot chief executive Arjun Iyer argued that we have entered what he calls a third era of agentic development, one in which loops are replacing prompts. The first era was autocomplete, a model suggesting the next line. The second was the prompt, a developer asking for a function and pasting the result. The third is the loop: an agent that generates code, runs it, observes the outcome, and iterates without a human in the seat for each cycle. This is not a cosmetic change to the developer experience. It is a structural change to where engineering effort actually goes.
The consequence Iyer draws is sharp and, we think, correct. When generation becomes cheap and continuous, the bottleneck does not disappear, it moves. It moves downstream, to verification. An agent can produce a hundred candidate changes in the time a human once produced one, but each of those candidates still has to be proven correct against the real system. Iyer, who brings more than twenty-five years in the cloud-native field, frames the heart of the problem plainly: an agent can only validate its work against the environment it has access to, and for teams building cloud-native systems, that environment is rarely good enough to prove the code will actually work in production.
Why Verification Is a Runtime Problem
The deepest insight in the argument is that for cloud-native software, verification is not a static analysis problem or a unit-test problem. It is a runtime problem. A function that passes every local test can still fail when it talks to a real service mesh, a real database with production-shaped data, real authentication, and real network latency. Distributed systems exhibit behaviors that simply do not appear on a laptop or in a mocked test harness. So when an agent claims its change works, the only honest way to confirm that claim is to run the change inside an environment that behaves like production, and to do so for every iteration of the loop, not just once at the end.
This is where traditional infrastructure buckles. Staging environments and conventional CI/CD pipelines were designed for human-paced change, perhaps a few dozen meaningful builds a day. They were never built for the volume and concurrency of agentic development, where dozens of loops may each want a faithful environment at the same moment. Spinning up a full duplicate of a complex microservice stack for every agent iteration is financially and operationally absurd. The result is that teams either let agents verify against environments too thin to be trustworthy, which produces confident but wrong code, or they throttle the agents back to human speed, which throws away the entire advantage.
The Signadot Approach and Its Trade-Offs
Iyer is not a neutral observer, and readers should weigh the argument accordingly. Signadot sells a Kubernetes-native platform built precisely for this verification gap. Rather than duplicating an entire infrastructure stack per environment, its approach virtualizes environments inside a single Kubernetes cluster by duplicating only the services a given change touches, while sharing everything else. That technique, sometimes called request-level isolation, is what allows the company to claim thousands of concurrent isolated environments without the cost explosion of full-stack cloning. The pitch is that agent loops can prove their changes against the real system, in seconds, inside the inner development loop rather than at the end of a slow pipeline.
Whether or not a team adopts Signadot specifically, the underlying architectural claim is worth taking seriously. The economics of agentic development only close if verification environments can be made cheap, fast, and faithful at the same time, and those three properties are in genuine tension. Full duplication is faithful but expensive. Mocking is cheap but unfaithful. Sharing a single staging environment is cheap but serializes everyone behind one queue. The interesting engineering question of 2026 is which technique each organization uses to escape that triangle, and we expect this to become a defining axis of platform strategy rather than a niche tooling preference.
What This Means for Engineering Organizations
For leaders, the operational implication is that investment priorities should shift to match where the bottleneck now sits. Many organizations have spent the past year buying coding assistants and measuring success by lines generated or pull requests opened. If Iyer is right, those metrics increasingly measure the wrong thing. A team that can generate ten times more code but cannot verify it ten times faster has not become ten times more productive, it has accumulated a backlog of unverified changes and a new kind of risk. The throughput of the verification layer, not the generation layer, becomes the real constraint on how much agentic development a company can safely absorb.
There is also a governance angle that engineering leaders should not overlook. As agents take on more autonomous loops, the verification environment becomes the place where trust is actually established before code reaches production. That makes it a control point, not just a performance concern. Who can spin up these environments, what production-like data they expose, and how their results gate a merge are all decisions that belong to platform and security teams, not to individual agents. The shift from prompts to loops is genuinely exciting, but it quietly relocates the most important question in software delivery from how fast can we write code to how confidently can we prove it works.
A Healthy Dose of Skepticism
We would temper the enthusiasm with a caution. Vendor essays that diagnose a problem and then happen to sell the cure deserve scrutiny, and this one fits that pattern. The era framing is tidy, perhaps too tidy, and not every organization runs the kind of sprawling cloud-native estate where runtime verification is the dominant cost. A team with a modest monolith and a strong test suite may find that conventional CI handles agentic output perfectly well for some time. The right response is to measure rather than assume: instrument where agent-generated changes actually fail, and whether those failures are the kind that only a production-like runtime would have caught.
That said, the trajectory is hard to dispute. As models grow more capable and loops run with less human supervision, the question of how a change earns the right to ship will only grow in importance. The strongest version of Iyer's argument is not that any single vendor has the answer, but that verification is becoming a first-class infrastructure concern that deserves the same architectural attention teams once gave to build pipelines and deployment automation. Engineering leaders who internalize that now, and who treat their verification layer as a deliberate design decision rather than an afterthought, will be the ones whose agentic ambitions survive contact with production.
