Anand Naidu is a leading authority in cloud infrastructure and DevOps governance, specializing in the intersection of autonomous systems and sustainable engineering. With extensive experience in both frontend and backend development, he has witnessed firsthand how the transition from human-centric to agentic development cycles can either streamline operations or create unprecedented levels of digital waste. As organizations increasingly rely on AI to generate everything from Terraform configurations to Kubernetes manifests, Naidu’s work focuses on embedding rigorous policy checks directly into the software development lifecycle. By shifting governance from a reactive, operational task to a proactive, specification-driven requirement, he provides a roadmap for leaders to scale their infrastructure without also scaling their carbon footprint or cloud expenditure.
This conversation explores the hidden costs of AI-generated code, specifically how autonomous agents tend to favor over-provisioned, “safe” infrastructure patterns that result in massive inefficiencies. We discuss the critical role of structured specifications in correcting the biases of AI training data, the specific infrastructure domains where waste is most prevalent—such as bloated Docker base images and oversized Kubernetes pod requests—and the four-stage pipeline architecture required for automated enforcement. Finally, we look at the broader environmental and regulatory landscape, highlighting why the time to implement these “green” guardrails is now, before agentic pipelines reach full organizational scale.
AI agents often default to over-provisioned infrastructure patterns because their training data reflects common industry practices rather than optimized ones. How can engineering leaders shift this behavior from the start?
The fundamental challenge we face is that these autonomous agents are essentially mirrors of our own historical habits, and those habits haven’t exactly been lean. When you look at the training data these models are built on, it is dominated by patterns where “availability” is the only metric that matters, often at the expense of efficiency. This is why we see agents consistently defaulting to a three-node GKE cluster using n2-standard-16 machines for workloads that could comfortably run on a single e2-medium node. That represents a 32x over-provisioning of compute resources right out of the gate. To shift this behavior, leaders must move away from the idea that sustainability is a “nice-to-have” manual review step and instead treat it as a first-class constraint within the specification itself. We have to give the agent a structural instruction set, like GS-INFRA-001, which explicitly mandates selecting the smallest machine type that satisfies a workload’s measured resource ceiling. When the agent is prompted with these hard constraints, it doesn’t try to reason about the morality of carbon emissions; it simply executes the specification as written. This turns sustainability from an aspirational goal into a structural, automated reality of the code generation process.
You’ve mentioned that “post-deploy remediation” is no longer a viable strategy in the age of agentic pipelines. Why does the scale of AI generation make our traditional ways of “right-sizing” infrastructure obsolete?
In the past, a human team might ship a few dozen services a month, and an operations team could retrospectively go in and tune those containers or right-size the clusters. But the pace of AI-driven development is accelerating sharply, with projections already suggesting that more than a quarter of all new production code and configuration is generated by AI. When you move from AI-assisted coding to fully autonomous agentic pipelines—where agents generate Terraform, Helm charts, and Docker configurations end-to-end—the sheer volume of output makes manual oversight impossible. If you have an agent industrializing inefficient patterns across every environment it touches, the “bloat” compounds at a scale that breaks traditional operational models. Gartner predicts that by 2027, only 30% of large enterprises will have sustainability embedded in their non-functional requirements. That leaves a staggering 70% of organizations generating code that lacks any sustainability intent. If we wait until after the deployment to fix these issues, we are essentially trying to mop up a flood while the taps are running at full blast; the only effective intervention is to shut the tap at the source, which is the specification layer.
Which specific areas of cloud infrastructure are currently the biggest culprits for this “autonomous bloat,” and what specific constraints should be applied to them to curb waste?
There are three primary domains where we see the most significant impact, starting with Infrastructure as Code (IaC) and cloud provisioning. As I mentioned, the tendency to over-specify instance families for resilience over efficiency leads to massive compute gaps that are billed and emitting carbon continuously in production. The second area is Kubernetes pod resource configuration, which is particularly insidious because of how the scheduler works. When an agent generates a pod spec with a 4-CPU and 8GB memory request for a service that actually peaks at 200 milli-cores and 256MB, the scheduler reserves that unused capacity, leaving it “stranded.” This means a node that could host eight pods might only host two, forcing the underlying VM to run at incredibly low utilization while you pay for the whole thing. Finally, we have container base image selection. Agents gravitate toward familiar, full-featured images like Ubuntu or Debian because they are “safe,” but these are often an order of magnitude larger than a distroless or Alpine-based equivalent. By enforcing a constraint that requires minimal base images by default, we can eliminate a massive amount of unnecessary storage, memory, and transfer bandwidth usage across hundreds of services.
How can a DevOps team integrate these sustainability checks into their existing CI/CD pipelines without creating friction that slows down the development speed of these AI agents?
The beauty of this approach is that most organizations already have the necessary toolchain in place; they just aren’t using it for sustainability yet. You can use static analysis tools like Checkov, tfsec, KICS, or Trivy to analyze Terraform and YAML files against configurable policy rules. This happens at the second stage of the pipeline, immediately after the agent generates the artifact but before it ever hits a deployment gate. If a Checkov policy flags a node pool that exceeds a certain threshold without justification, the violation surfaces as structured CI output. Crucially, this must be a “blocking” quality gate. Sustainability violations should fail the build, just like a security vulnerability would. Because these gates operate on the output—the actual Terraform or Dockerfile—the process is entirely agent-agnostic. It doesn’t matter if the code was written by a human, an internal scaffolding agent, or a sophisticated LLM; the policy is applied identically. This creates a reliable enforcement architecture where the governance layer doesn’t care about the “who” or the “how,” only the “what,” ensuring that only sustainable artifacts move toward production.
The environmental impact of AI is often discussed in terms of training models, but you focus on the “runtime” of the generated infrastructure. How do the emissions of companies like Microsoft and Google highlight the urgency of this shift?
The numbers are quite startling when you look at the recent reports from the tech giants. Microsoft’s emissions have risen by 23% since their 2020 baseline, and Google’s have climbed a staggering 51% since 2019, with AI infrastructure cited as the primary driver. While much of the public conversation is focused on the energy required to train a model, the long-lived infrastructure decisions encoded into the artifacts these agents generate represent a massive, compounding load. Global data centers are on track to consume more electricity than the entire country of Japan by 2030. A significant fraction of that electricity is powering over-provisioned infrastructure that was generated by a script or an agent that was never told to prioritize efficiency. This isn’t just an abstract architectural concern; it’s a looming regulatory and financial crisis. Organizations that govern this generation upstream will see efficiency gains compound with every agent run, while those who wait will find that remediation at scale is not just expensive—it’s practically impossible.
For a team looking to get started this week, what are the first practical steps to bridge the gap between their current “safe” defaults and a truly sustainable specification?
I recommend a three-step approach that can be initiated almost immediately. First, conduct an audit of your current IaC specifications. Open up your active Terraform modules or Helm charts and look at your machine type and pod resource defaults; you’ll likely find they are set to “safe” values with no real efficiency rationale. Define three initial constraints: a machine type ceiling, a pod request ceiling based on p95 consumption data, and a minimal base image policy. Second, implement a single blocking policy in your CI pipeline—for example, use Checkov’s custom check API to flag any node pool configured above an e2-standard-4 threshold. This can be done in under an hour and provides immediate enforcement. Finally, you must embed these constraints now, before you scale your agentic pipelines any further. Retrofitting governance onto hundreds of already-running, agent-generated services is an order of magnitude harder than simply constraining the generation at the source. If you start now, you build efficient, cost-controlled infrastructure by construction rather than by accident.
What is your forecast for the future of cloud governance as AI agents become the primary authors of our digital world?
I believe we are heading toward a world where “infrastructure debt” will be a more significant bottleneck than traditional technical debt. As agents generate configuration at a pace human teams can’t match, the organizations that will thrive are those that have successfully decoupled their governance from human review. We will see a shift toward “closed-loop” governance, where runtime telemetry—actual resource utilization and carbon intensity data—feeds directly back into the specification constraints. Imagine an environment where a constraint like GS-K8S-001 isn’t static, but is automatically refined based on the previous week’s empirical p95 consumption. This level of automated, self-correcting governance will become the standard. If we don’t move in this direction, the cost—both financial and environmental—of over-provisioned AI-generated infrastructure will become a systemic drag on innovation. Compliance with sustainability reporting, especially with the accelerating mandates in the EU, will transition from a crisis-mode program to a natural, automated output of a well-governed engineering pipeline. The choice for leaders is simple: govern the agent at the specification level today, or spend the next decade trying to fix what the agent broke in a single afternoon.
