Ask an engineer to write a Terraform module, explain a Kubernetes deployment, investigate a failing test, or review a pull request, and there is a good chance an AI tool is involved somewhere in the process. The question of whether engineers are using AI has been settled. The more useful question is how far into the infrastructure stack it has actually reached.
That distinction matters because generating infrastructure code and operating infrastructure are different problems.
I have seen the first one work extremely well. Give a model a reasonably clear requirement and it produces a Terraform module, Kubernetes manifest, Helm values file, or CI configuration that looks completely reasonable. Then you run it. The plan reveals a resource dependency the model did not account for. A manifest references a field that does not exist in the installed API version. An IAM policy applies successfully and gives a workload considerably more access than it needs.
Nothing about the generated code looked wrong, and that is the problem.
Infrastructure has a particularly nasty definition of correct. Code can look right and even runnable and still be wrong in ways that only become visible when it interacts with the actual system. The industry spent much of 2025 talking about AI as if generating plausible code was equivalent to automating software engineering. The more interesting story in 2026 is what happens after generation.
##The Three Layers of AI Adoption
It is easy to talk about AI adoption as a single figure, and that is probably the least useful way to look at it. A team using autocomplete on a function and a team letting an agent investigate a production incident both count as AI users. Operationally, they have almost nothing in common. I find it more useful to think about three layers.
The Assistant Layer
This is the AI most engineers already know. It writes Terraform, explains an unfamiliar Kubernetes resource, generates a Dockerfile, reviews a pull request, and turns a vague error message into a list of possible causes. The workflow still has a human at the center.
This layer is now mainstream. DORA's 2025 research found that 90% of technology professionals surveyed use AI at work and more than 80% believe it has increased their productivity, while 30% report little or no trust in AI-generated code. That combination is the interesting part. People are not waiting for AI to become trustworthy before using it. They are using it while maintaining a verification step, and the human remains the deployment boundary.
The Operator Layer
This is where things get more interesting. An operator agent does not just generate a kubectl command. It inspects the cluster, reads logs, checks recent deployments, queries metrics, compares current state against desired state, and correlates a deployment with an incident. It can then tell you that latency increased immediately after deployment, that the affected pods are running the new version, that the error rate is concentrated on requests using the payments API, and that here are three likely causes and the rollback it recommends.
That is a fundamentally different capability from code generation. The model is no longer producing text in isolation. It has operational context. The human is still involved, but the role shifts from author to supervisor: engineer, agent, live context, investigation, proposed action, approval.
The Autonomous Layer
This removes the human from the immediate loop. The agent detects an incident, investigates, decides, and executes the remediation. This is where the industry's language becomes considerably more aggressive than its actual operating model. Genuine examples exist, but production autonomy is almost always bounded by permissions, workflows, policies, environment scope, and the specific kinds of changes an agent is trusted to make. Which points to something worth stating plainly: autonomy is not a switch; it is a permission boundary.
##The Adoption Numbers are Impressive. They are Also Easy to Misread.
DORA's 90% figure is solid, but the problem is what people infer from it. If 90% of engineers use AI, that does not mean 90% of infrastructure teams have autonomous agents operating production systems. The two claims measure completely different things.
The Pragmatic Engineer's 2026 survey provides a useful second data point: 95% of respondents reported using AI tools weekly, while 55% said they regularly use AI agents, rising to 63.5% among staff-plus engineers. That is a substantial jump from a year earlier, but notice the language. Regularly using AI agents is not the same as giving AI agents production authority. The most common agent use cases in that survey were code review and validation, automating manual tasks, bug investigation, debugging, and code investigation. One respondent described using an agent for almost all coding work while staying in the loop for review. That sits much closer to the operator layer than to autonomy.
The distinction is worth preserving because agent adoption is moving quickly enough that individual percentages go stale almost as soon as they are published. When I read an AI adoption survey now, I care about four things: who was surveyed, who paid for the research, what "adoption" actually meant in the question, and when the fieldwork happened. A survey conducted in early 2026 can describe an ecosystem that looks noticeably different a few months later. The trend matters more than false precision.
##AI is an Amplifier, and Infrastructure Makes That Obvious
One of the strongest findings in DORA's research is also one of the easiest to miss. AI adoption is associated with increased software delivery throughput and increased delivery instability at the same time. The researchers describe a tension where time saved during generation gets reallocated to auditing and verification.
That is the verification tax. You generate something faster, then you have to check whether it is actually correct. It sounds obvious, but infrastructure makes the cost much higher. A bad application-code suggestion creates a bug. A bad infrastructure suggestion can expose a database to the internet, grant a workload excessive IAM permissions, or turn a single mistake into an organization-wide pattern.
The blast radius changes the economics of verification entirely, which is why "AI writes infrastructure" is a far less interesting claim than "AI can safely operate infrastructure." The second problem requires context. The system needs access to the current state; it needs to know what changed, understand dependencies and policies, distinguish disposable resources from business-critical ones, and know what it is allowed to touch.
None of that is a prompting problem. It is a platform problem.
##Platform Engineering Quietly Became the Control Plane
This is the biggest shift I see in the infrastructure conversation. The discussion started with models, moved to agents, and is now moving toward the systems surrounding those agents.
DORA reports that 90% of organizations have adopted at least one internal platform, and finds a direct relationship between platform quality and the ability to unlock value from AI. That makes sense, because a good internal platform already provides most of what an agent needs: standardized workflows, known deployment paths, consistent environments, identity, observability, policy enforcement, self-service APIs, GitOps, rollback, audit trails, and clear ownership.
Now put an agent on top of that. Instead of arbitrary cluster access, the platform exposes a controlled operation like deploy_service(service, version, environment) , or instead of arbitrary IAM changes, it exposes a constrained workflow like request_role(service, environment, permissions). The platform becomes the boundary between what the agent wants to do and what the infrastructure permits.
That creates a set of new platform engineering responsibilities.
Agent Identity
Agents need identities of their own. A shared service account used by several agents makes attribution impossible and creates a massive blast radius. If an agent changes a production deployment, you should be able to answer which agent, which version, which user initiated it, which tools it called, which permissions it held, and what it changed.
Scoped Credentials
The default should never be agent-to-cluster-admin. It should be agent-to-namespace with allowed operations. If the agent only needs to restart pods, it should not be able to create cluster roles. The smaller the permission boundary, the smaller the failure domain.
Agent Observability
Traditional telemetry tells you what the application did. Agent observability needs to tell you what the agent decided to do, so that you can reconstruct the path from user request through agent decision, tool invocation, policy evaluation, infrastructure change, and result. The model's internal reasoning does not need to become your audit log. The action path does.
Approval Paths
For high-risk operations, the agent should produce a plan or a diff, and that artifact becomes the interface between agent and engineer. This is why GitOps fits the agentic model so well. The agent opens a pull request containing the Terraform diff, then the policy and security checks run before a human finally approves. Ultimately, the agent gets most of the speed without becoming an unrestricted production administrator.
##The Infrastructure Itself is Still the Hard Part
There is a useful reality check buried in infrastructure-as-code research: AI is much better at generating code that looks right than at generating infrastructure that works.
A deployability-focused study introduced DPIaC-Eval, a benchmark of 153 real-world infrastructure scenarios. First-attempt deployment success rates for the evaluated models were low, and security compliance was even harder, with only a small fraction of outputs passing the security criterion. The benchmark is not claiming that AI cannot generate infrastructure. It is showing that deployment success is a far harder target than having correct syntax.
Several properties of infrastructure make it difficult for models.
Correctness happens late. You can read a Terraform file and decide it looks valid, but some correctness properties only surface during plan or apply, when the system interacts with real providers and real state.
In addition, when dealing with providers, uncertainty can happen at any time. For instance, APIs can move, cloud providers can change defaults, resources can gain fields, providers can deprecate attributes, Kubernetes APIs can evolve, and versions can drift. This means a model can produce technically valid configuration but still be built on an outdated pattern.
All of these changes point to one thing: infrastructure teams need to evaluate AI-generated IaC carefully. The generated HCL is not the final product and shouldn’t be treated as one. The resulting code still needs to be reviewed carefully and monitored once it is applied. Policy-as-code, security scanning, drift detection, cost checks, and deployment validation become even more important when a generator enters the workflow, not less.
##MCP Gives Agents Infrastructure Context, but Adds Another Attack Surface
A strong model can walk through Kubernetes in general. That does not mean it knows what is happening in your cluster right now. This is where tools such as MCP become useful.
Instead of pasting Grafana screenshots, kubectl output, or ArgoCD errors into a prompt, an agent can query those systems directly through controlled interfaces. The workflow shifts from “here is some information about my infrastructure” to “here is an interface through which you can inspect my infrastructure.”
That makes agents considerably more useful, but it also introduces a new security consideration. MCP is not a security boundary on its own. Once an agent can access your cluster, monitoring systems, cloud resources, or deployment platforms, those connections become privileged API surfaces that need proper authentication, authorization, scoped permissions, and network controls.
There is also a less obvious benefit. Making infrastructure queryable by agents puts more pressure on platforms to expose consistent, well-designed APIs. In that sense, agents could become another forcing function for better platform engineering.
The important point is that giving an agent more context does not automatically make it safer. It makes the permissions and interfaces around that context more important.
##What the Cloud Vendors Actually Shipped
There is a temptation to read the arrival of AWS DevOps Agent and Azure SRE Agent as proof that autonomous SRE has arrived. Azure SRE Agent reached general availability on 10 March 2026. AWS DevOps Agent followed on 31 March, after a preview that opened at re:Invent in December 2025. Both are built around deep operational context, connecting telemetry, code, deployment data, incidents, resource relationships, and knowledge bases, with MCP and A2A interfaces extending their reach.
And both deliberately chose investigation and recommendation over automated action. That is worth sitting with. These are the two organizations with the most capital, the most telemetry, the most operational data, and the strongest commercial incentive to ship autonomous remediation. They shipped agents that investigate and propose. The constraint is not marketing caution. The persistent gap in these systems is service-level and code-level context: knowing which components constitute a business-critical path, which shared library carries downstream risk, which architectural patterns govern communication between services. An agent can see that latency rose. Knowing what that means for the business is a different problem.
What stands out about these products is not that vendors built them. It is how much infrastructure they need around the model. Telemetry, source code, deployment history, runbooks, incident history, service relationships, credentials, permissions, tool integrations, environment knowledge, policy. The model is one component. The operational context is the product.
This is why I get skeptical when "self-healing infrastructure" is used as though it means an LLM was given shell access and told to fix production. Real autonomous operations look much more like a control system. The agent observes, forms a hypothesis, gathers more information, and proposes an action.
##The Bottleneck is Integration, and the Gap is Accountability
The 2026 State of AI Agents research puts a number on something infrastructure engineers already understand: 46% of respondents cited integration with existing systems as a primary obstacle to agent adoption, with data access and quality close behind.
The model is not the bottleneck. The wiring is. An agent needs to know which cluster, namespace, environment, and service it is dealing with, who owns the deployment, which team is on call, which alert is authoritative, which API to call, which credential to use, what it can change automatically, what needs approval, how to roll back, and where the audit trail lives.
These questions sound boring. They are also the actual work. They are the part vendor demos tend to hide because watching an agent type into a terminal is more exciting than watching a team standardize service ownership metadata.
Underneath the integration problem sits a harder one. Suppose an agent makes a production change. Who owns it operationally? Who gets paged, who reviews the logs, who can disable it, who approves its permissions, and who investigates the incident?
This gets sharper as organizations move from individual assistants to fleets of agents. Recent industry research suggests agent deployment is moving faster than monitoring and governance. The exact percentages vary by survey, but the direction is hard to dismiss: organizations are deploying agents faster than they are building the controls around them.
That creates a new platform requirement: every production agent needs a named owner. Not a team in the abstract, but someone who can say what the agent does, what it can access, what it can change, what happens when it fails, who approves changes to it, and who gets paged when it causes an incident.
The agent may be autonomous. The organization cannot.
##What Infrastructure Teams Should Actually Do
The good news is that none of this requires building a fully autonomous platform. I would argue against trying.
Start with Read-only
Give the agent enough context to investigate without enough authority to damage production. Let it query Kubernetes, Prometheus, Grafana, ArgoCD, cloud APIs, deployment history, logs, repositories, and incident systems. The useful output might be a diagnosis, a report, a Terraform plan, or a pull request. Read-only access is not a sign that an agent is immature. It is how you build confidence before widening its authority.
Scope Permissions
Give agents the smallest useful set of permissions. Specific environments, resources, and operations are easier to control than broad administrative access. Once that works reliably, add bounded write operations. Restarting a failed development pod, scaling a non-production workload, opening a pull request, updating staging configuration, or running a known diagnostic workflow are reasonable early automation. Modifying production IAM, changing network policy, deleting infrastructure, altering database configuration, or deploying arbitrary code to production are not.
Treat the Plan as the Interface.
For infrastructure changes, the output should be something a human and the platform can inspect: a Terraform plan, Kubernetes diff, commit, pull request, or deployment preview. The model does not need to own production. It needs to produce a proposal that existing systems can validate.
Instrument the Agent.
Agent activity belongs in the same operational ecosystem as everything else. If you cannot reconstruct what the agent did, which tools it called, which identity it used, what policy allowed the action, and what changed as a result, the agent is not ready for meaningful production authority.
Fix the Platform Before Buying Another Agent.
This is the one that matters the most. AI does not rescue a broken delivery system. It amplifies it. If deployments are inconsistent, AI makes it easier to produce inconsistent deployments. If environments are poorly defined, agents get confused faster. Likewise, where the golden paths are good, AI becomes considerably more useful because the platform gives the agent clear constraints to work within.
And before an agent gets serious production authority, decide who owns the pager. Do that before the first incident, not during it.
##The Autonomous Future will be Built out of Boring Infrastructure
The temptation is to respond to AI with another platform: another portal, another agent framework, another abstraction over Kubernetes. I think that misses the point. Most of the infrastructure needed for safe agent operation already exists. What changes is the requirement to make it explicit, consistent, observable, and usable by machines.
That means good IAM, well-defined APIs, golden paths, policy enforcement, observability, reversible changes, clear ownership, and useful failure signals. None of these are particularly exciting. They are also the things that determine whether an agent can safely operate production.
This gives us a more useful way to think about AI in infrastructure. The assistant layer is already widespread. The operator layer is expanding. The autonomous layer is still narrow, because autonomy is not just a model capability. It is a platform capability.
An agent cannot safely operate a system it cannot understand. It cannot understand a system it cannot observe. And it cannot safely act on what it observes without identity, permissions, policy, and accountability.
That entire chain lives outside the model. It lives in the platform.
AI has already reached infrastructure. Unrestricted autonomy has not, and that is probably a good thing.
When an agent eventually gets permission to touch production without a human in the loop, the question will stop being how smart the model is and become what happens when the model is wrong.