Our organization has accelerated software development significantly through AI-assisted coding, while also reducing engineering headcount and asking developers to take on more full-stack responsibility. The problem is that our DevOps and platform teams are now overwhelmed by infrastructure pull requests that were largely generated by AI tools.
We run a large, mostly EKS-based environment with Terraform and extensive IaC across multiple companies and business units. The infrastructure is organized, but it includes unavoidable complexity around Kubernetes, networking, IAM, security, CI/CD, observability, and shared platform architecture.
The generated Terraform often looks reasonable and may even validate successfully, but it frequently ignores dependencies, local conventions, security requirements, resource lifecycles, or the broader architecture. As a result, platform engineers spend much of their time reviewing changes, identifying hidden problems, explaining the environment, and reviewing multiple revisions of AI-generated code.
There is also a noticeable asymmetry: infrastructure engineers with software backgrounds can generally use AI to become productive in application code, while application developers using AI still struggle to understand the operational context behind infrastructure changes. The result is that application delivery has become faster, but the infrastructure review and validation process has become a severe bottleneck.
We are considering better internal tooling, more context for AI assistants, stronger abstractions, self-service infrastructure, and stricter boundaries around what application teams can change. Options might include opinionated Terraform modules, Kubernetes operators or CRDs, policy-as-code, internal developer platforms, or specialized AI tools that understand our environment.
Are other platform, DevOps, or SRE teams seeing the same pattern? How are you handling the increased volume of AI-generated infrastructure changes? Have you increased staffing, built paved roads, restricted direct access to Terraform, or found an effective way to provide agents with enough environment-specific context?
4 Answers
Context is probably the central issue. A repository instruction file can explain conventions, but it cannot fully describe current ownership, dependencies, deployment state, permissions, incidents, approved workflows, and the architectural reasons behind existing choices.
I would give the assistant read-only access to a structured source of truth for the environment, then require it to inspect that context before proposing changes. A read-only infrastructure discovery service or MCP-style interface could help, but it should supplement—not replace—strong boundaries and human review. Better context may reduce bad assumptions, but it will not make unrestricted changes safe.
The most effective solution is usually to stop exposing raw infrastructure as the primary developer interface. Build opinionated self-service modules or service specifications with a small number of safe inputs, then let the platform team own the Terraform, policies, and implementation underneath.
Developers can request a database, queue, service, route, or scaling policy without needing to understand every dependency in the cloud environment. The platform team still handles unusual cases, but routine requests stop arriving as bespoke infrastructure pull requests. Kubernetes CRDs, operators, Crossplane compositions, or a platform API can all work for this pattern.
In the short term, filter the queue before it reaches the platform team. Require every infrastructure change to include the plan output, a plain-language explanation of what changes, and a summary of creates, updates, deletes, and replacements. Automatically flag or block changes involving stateful resources, public exposure, wildcard IAM, unencrypted storage, unusual cost increases, or large blast radii.
Policy-as-code can catch a lot of structural mistakes without consuming reviewer time. You can also add plan-diff summaries, cost thresholds, drift checks, and mandatory platform approval for destructive changes. Treat AI-generated infrastructure like work from a fast junior engineer: useful, but never trusted simply because it is syntactically valid.
This is a predictable bottleneck shift. If AI lets developers produce changes faster but the same small platform team must validate every change, overall delivery does not actually speed up—the queue just moves downstream.
I would protect some platform capacity specifically for reducing review demand instead of letting the team spend all its time acting as a help desk. Track which requests consume the most review time, publish starter templates and documentation for those cases, and build self-service workflows around the most common 80 percent. For the remaining complex work, keep the review process and require the requesting team to own the service and its operational consequences.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures