Something shifted in the AI coding discourse this month. The argument is no longer about whether agents can write production code or which model is best. It is about who, or what, should be prompting them. The phrase that captured it, "design loops that prompt your agents," set off a week of discussion that Matt Van Horn synthesized well. Strip away the noise, and the signal is clear: a third era of agentic development is taking shape, and it raises significant questions about what engineers do, what software delivery costs, and what infrastructure must exist beneath it. For teams building cloud-native applications on Kubernetes, the answers to those three questions are about to matter a great deal.
This evolving landscape represents a fundamental re-evaluation of the developer’s role and the economic implications of AI-driven software development. What began as a tool to augment individual developer productivity has matured into a system that demands a rethinking of how software is built, tested, and deployed, particularly within complex cloud-native environments.
Three Eras, One Direction: The Evolution of Agentic Development
Agentic development has, at each stage, moved the human up one level of abstraction at a time, progressively automating more of the development lifecycle. This progression can be broadly categorized into three distinct eras:
The First Era: Prompt-Driven Development
This initial phase was characterized by direct human interaction with AI models. Developers would sit within the loop, meticulously typing instructions (prompts), analyzing the AI’s output, and then providing corrections. The developer’s attention span and skill in crafting precise prompts were the primary bottlenecks, capping the throughput of this development model. This era, while groundbreaking for its time, was limited by the direct, iterative engagement required from the human.
The Second Era: Spec-Driven Development
The current dominant paradigm for many adopting teams is spec-driven development. In this phase, developers invest significant upfront effort in creating detailed specifications, comprehensive context documents, and encoding conventions directly into the code repository. The AI agent then executes against these detailed blueprints, and the human intervenes for review of completed tasks. The unit of work expanded from a single prompt to a defined task, offering greater efficiency but still requiring substantial human oversight for task definition. This era marked a significant leap in scale, allowing for more complex tasks to be delegated to AI.
The Third Era: Loop-Driven Development
The emerging third era redefines the unit of work itself. In this paradigm, the "loop" becomes the fundamental building block. A loop is essentially a small, autonomous program designed to prompt an AI agent, evaluate its response, determine if the objective has been met, and, if not, prompt again with learned insights. These loops operate on a schedule rather than solely on human attention, and critically, they can dispatch and manage other loops. This signifies a profound shift: developers are no longer primarily writing code or even detailed tasks. Instead, they are focused on constructing the sophisticated systems that generate, evaluate, and iteratively refine the work performed by AI agents. This era moves the developer’s focus from execution to orchestration and system design.
Skeptics have drawn parallels between this new model and a "cron job with better marketing." While this comparison highlights the automated, scheduled nature of the work, it crucially misses the core innovation. A cron job executes a fixed script without deviation. In contrast, a loop incorporates a decision-making component, typically an AI model, that reads the current state of the work and dynamically chooses the next action. The engineering challenge then shifts to building the robust surrounding infrastructure that ensures these loops converge on correct outcomes rather than wandering aimlessly through unproductive iterations.
What the Developer Becomes: From Coder to Architect of Intent
The evolving nature of agentic development necessitates a transformation in the developer’s role and the source of their leverage within the software development process.
From Steering to Intent: The Prompt and Spec Eras
In the prompt-driven world, a developer’s primary leverage stemmed from their skill in steering the AI – their ability to craft precise and effective prompts. In the spec-driven world, this leverage shifted to the clarity and comprehensiveness of their intent, articulated through detailed specifications.
The Loop-Driven Paradigm: Architecting the System
In the emerging loop-driven world, leverage is derived from the quality and intelligence of the system built around the AI agent. The critical engineering questions become: What specific checks does a loop perform before declaring success? What kind of feedback does it receive when it fails? Under what conditions does it cease execution?
These questions effectively bifurcate the developer role. Application developers increasingly become authors of intent and loops. They are responsible for defining the high-level goals of the software and encoding these objectives into the logic of the autonomous loops. Platform engineers, on the other hand, become the arbiters of what done means. They are responsible for defining and maintaining the consistent standards, environments, and verification mechanisms that all loops must adhere to.
The checks a loop executes, the environments in which it runs, the budgetary constraints it operates under, and the evidence it attaches to its output must be consistent across the entire organization. This cannot be an ad-hoc, per-loop improvisation. This pattern mirrors a familiar evolution in software engineering. A decade ago, platform teams transformed Continuous Integration and Continuous Deployment (CI/CD) from a disparate set of individual team hacks into a standardized, streamlined process. The verification layer for agent loops represents a similar transition, but crucially, it operates within the "inner loop" of development, preceding traditional pull requests and operating at the parallelism generated by the loops themselves.
The Economics of Loops: Convergence or Burn
The initial assumption that AI agents would make code generation inherently cheap is proving to be an oversimplification. While agents have indeed accelerated the generation process and made it more cost-effective than pure human hours, the consumption of AI model tokens is a tangible and escalating expense. An agent running for hours represents a significant expenditure, and by design, loops are engineered to run potentially indefinitely. Budgets that comfortably accommodated interactive AI sessions may struggle to absorb the sustained costs of continuous loop execution.
The immediate response to this economic reality involves implementing guardrails. These include iteration caps to prevent runaway processes, mechanisms for detecting a lack of progress, and strict spend ceilings. While these measures are essential for bounding potential damage, they primarily serve to limit losses rather than inherently optimize efficiency.
True loop efficiency is a product of two interconnected dimensions, and their multiplicative effect is where significant cost savings can be realized:
1. Feedback Quality: This dimension directly dictates the number of iterations a loop requires. A loop receiving vague failure signals must resort to guesswork, leading to repeated, inefficient attempts. Conversely, a loop that receives precise, contextualized error messages from the actual system can accurately pinpoint the cause of failure and proceed to a resolution efficiently. The quality of feedback also sets an upper bound on the accuracy a loop can achieve; it can only converge on a solution that its feedback mechanisms can perceive.
2. Location of Loop Closure: This determines the cost associated with each iteration. If a loop’s feedback cycle is completed within the Continuous Integration (CI) pipeline or after a pull request has been submitted, each cycle incurs the overhead of pipeline execution and queuing, resulting in cadences measured in minutes to hours. However, if the loop can close its feedback cycle within the "inner loop" – directly interacting with a runtime environment accessible to the agent – the cadence can be compressed to mere seconds.
The total cost of a loop is thus the product of the iterations required to achieve verified success multiplied by the cost per iteration. These dimensions are not independent; they influence each other. Pushing highly granular, truthful feedback to CI, for instance, can slow down each cycle as the agent grapples with partial signals. Conversely, bringing this feedback mechanism into the inner loop compresses both terms simultaneously, dramatically reducing the overall cost.
Cloud-Native Raises the Bar for "Done"
For self-contained applications, achieving a comprehensive understanding of correctness is relatively straightforward. Local test suites can execute in seconds, providing complete truth because the entire system’s state is contained within the local environment.
However, the distributed nature of cloud-native systems introduces significant complexity. A change is deemed correct or incorrect not in isolation, but based on its interaction with a myriad of other services, data stores, queues, and underlying routing and policy layers.
The feedback an agent can quickly access, such as local tests and stubs, is inherently partial. The feedback that truly reflects correctness traditionally resides in CI pipelines and shared staging environments, where execution cycles are slow and resources are contended. Cloud-native teams are therefore forced into a difficult choice: embrace a fast loop that might converge on an incorrect target, or opt for a truthful but slow loop that iterates at the pace of the entire pipeline.
Previous analyses have highlighted the shortcomings of traditional environment provisioning at the scale required by AI agents. The critical conclusion for cloud-native systems is that an agent loop’s feedback must originate from a production-like runtime, and this runtime must be directly accessible from the inner loop. Consequently, the architecture of a cloud-native agent loop is largely dictated by the nature of the verification surface provided to it.
The Four Layers of a Cloud-Native Agent Loop
The complete system enabling efficient and reliable loop-driven development is comprised of four interconnected layers, with the loop itself representing the smallest component:
1. The Runtime Layer: This layer provides the loop with an environment for each iteration that accurately mimics production behavior without incurring production-level costs. The solution lies in lightweight, ephemeral environments provisioned on a shared cluster. This approach involves deploying only the specific services that a given change touches. By leveraging request routing within a single shared cluster, an agent’s traffic can be directed through these ephemeral environments and through a live, shared baseline for all other dependencies. These environments materialize in seconds, with marginal costs tied directly to the changed pods rather than the entire application stack. Crucially, this allows feedback to be derived from real dependencies and actual data paths, moving the point where the loop closes into the inner loop of development.
2. The Verification Interface: Agents should not be left to define their own criteria for success, nor should they be expected to navigate complex user interfaces. The checks a change must pass should be encapsulated within declarative workflows. These workflows are defined, versioned, and maintained by platform teams, serving as the sanctioned mechanism for agents to prove the correctness of their work. This ensures that the organization, rather than the agent, defines what "passing" entails. The evidence generated by these processes is auditable by humans, allowing human review to focus on higher-level aspects like intent and architectural design.
3. The Feedback Layer: This is the engine of convergence. A simple pass/fail signal is insufficient to guide a loop toward improvement; it may prompt a retry but offers no insight into what needs to change. The runtime must deliver structured results, including specific check failures, logs and traces precisely scoped to the loop’s own requests, and detailed behavior diffs at the boundaries where errors occurred. Every increment in feedback precision eliminates guesswork, and the removal of guesswork directly translates to reduced costs.
4. The Control Layer: This layer provides the necessary governance and management for scaled agentic development. It encompasses mechanisms for budget control, iteration ceilings, no-progress detection, and the maintenance of a durable record of each loop’s execution and proof of work. This layer empowers an organization to run numerous loops with confidence, rather than a single loop accompanied by persistent anxiety. When expenditure is bounded and convergence is rigorously measured, agentic development transforms from an unpredictable expense into a predictable and manageable capacity.
The imperative to "write loops, not prompts" is the visible manifestation of a broader assertion: an organization’s leverage now resides within the shared verification system that its loops utilize, and this system falls under the purview of the platform engineering organization.
Where to Start: Building the Foundation for Loop-Driven Development
The transition to loop-based development will not occur as a singular, decisive event. Instead, it will likely emerge organically, perhaps beginning with a team whose experiments converge rapidly and successfully, contrasted with another team whose efforts consume a significant portion of their budget while producing untrustworthy changes. The decisive factor distinguishing these outcomes will be the robustness of the underlying four layers, not merely the ingenuity of the loops themselves.
For teams operating within cloud-native environments, the runtime layer represents the most critical starting point. The efficacy of all other layers is fundamentally dependent on this foundation. Verification workflows are only as meaningful as the environments in which they execute, and feedback is only as truthful as the system that generates it.
This foundational layer, encompassing Kubernetes-native lightweight ephemeral environments and governed validation workflows, is precisely what is being developed at Signadot. These tools empower agent loops to rigorously prove changes against the real system, achieving this validation in seconds and directly within the inner loop of development. Organizations whose AI agents are generating code at a pace that outstrips their ability to ensure its trustworthiness are receiving a clear signal: a crucial layer is missing from their agentic development pipeline.
