AI Is Making Infrastructure Easier to Create and Harder to Operate

AI is rapidly changing the economics of software engineering. Tasks that once required hours of engineering effort can increasingly be completed in minutes. An AI agent can write an application, generate Terraform, produce Kubernetes manifests, configure a CI/CD pipeline, and interact directly with cloud APIs.

For infrastructure teams, this sounds like an enormous productivity win. And on Day 1, it is. But generating infrastructure has never been the hardest part of running it.

Someone still needs to patch it, upgrade it, govern it, observe it, migrate it and eventually retire it. AI can dramatically increase the rate at which we create infrastructure without necessarily reducing the cost of owning that infrastructure afterwards.

We may be making Day 1 much easier while quietly making Day 2 much harder.

Day 1 is getting cheaper. Day 2 isn't.

Platform teams have already seen this problem. Infrastructure templates made it possible to encode good practices and give development teams a fast way to provision what they needed. Instead of waiting days for an infrastructure team, a developer could instantiate a template and get started. However, the difficulty came later.

Once a template has created hundreds of resources across an organisation, changing the template doesn't necessarily change everything it previously created. A vulnerability needs patching. A cloud provider releases a new version. Security requirements change. An organisation decides that a configuration previously considered acceptable is no longer permitted.

Suddenly, the platform team isn't managing a template. It's managing an estate.

In her 2025 KubeCon keynote, Abby Bangser described this as the "puppy for Christmas" problem. Giving someone infrastructure can feel great on the day they receive it, but somebody still owns the vet bills and 4 a.m. walks. At organisational scale, the result can become what she called a "mega litter": infrastructure distributed across the organisation that must now be found and maintained.

AI doesn't create this problem. It removes one of the natural constraints on how quickly it can grow.

The unit of reuse should be the capability

Consider a common platform requirement: PostgreSQL. An organisation might have spent significant engineering effort building a Terraform module that creates a compliant PostgreSQL instance. AI can potentially recreate much of that work on demand.

So why bother maintaining the abstraction? Why not give an agent sufficient context about the organisation, access to the cloud provider and permission to generate what is required?

Because the organisation doesn't really want generated PostgreSQL infrastructure; it wants a PostgreSQL capability. A developer should be able to say, "I need PostgreSQL with these characteristics," without needing to understand every decision required to provision and operate it correctly.

The implementation might use OpenTofu, Crossplane, a cloud API or something that hasn't been invented yet. Those implementation choices shouldn't have to become part of the consumer contract.

This becomes more important, not less, when the consumer is an AI agent. If every agent independently reasons from infrastructure primitives, organisational knowledge has to be repeatedly supplied as context: which regions are permitted, what backup policy applies, which database versions are supported, what needs approval, how resources should be tagged, and perhaps dozens of other decisions.

A platform capability gives that knowledge a more durable home.

AI makes platform APIs more important, not less

There is a tempting counterargument here. As models become more capable, perhaps we won't need these abstractions. Give an agent access to Terraform, Kubernetes and cloud APIs, describe the desired outcome, and let it determine how to get there. But better reasoning doesn't remove organisational constraints.

An agent still needs to know what it is allowed to request, what policies apply, which implementations are supported, when human approval is required and who will own what it creates. Without those boundaries, AI risks becoming an extremely efficient way of producing shadow infrastructure.

Abby made a similar point in her 2026 KubeCon keynote. Giving AI direct access to the cloud might remove an immediate bottleneck, but it recreates the familiar problems of shadow IT: compliance risk, security concerns and operational overload. AI simply increases the potential scale. Rather than lock agents out, we should give them better interfaces.

A platform API can separate intent from implementation. Humans, agents, portals and CLIs can all request the same capability through different interfaces while the organisation retains control over how that request is fulfilled.

The arrival of AI therefore doesn't make the platform API obsolete. It arguably makes having a well-defined one considerably more important.

The next platform bottleneck is lifecycle

This changes where platform teams should look for leverage. Imagine that creating 500 databases becomes effectively trivial. The interesting engineering problem is no longer whether we can create database number 501. It is whether we can change the backup policy across the previous 500 without manually tracking them down. Or upgrade them safely, determine which versions are running, migrate consumers when an implementation reaches end of life, roll back a change that didn't behave as expected, etc.

AI is exceptionally good at generating variation. Day 2 operations generally benefit from reducing unnecessary variation. That tension is likely to become increasingly important as agents participate more directly in software delivery.

In her 2026 keynote, Abby framed platform engineering in terms of system constraints: optimising one part of a system doesn't necessarily increase overall throughput if the bottleneck simply moves somewhere else. AI is dramatically increasing the rate at which software can be produced. That makes it even more important to ask what happens elsewhere in the delivery system as a consequence.

For platform teams, lifecycle management may increasingly become that constraint.

Don't give AI more infrastructure. Give it better platform contracts.

None of this means AI agents shouldn't interact with infrastructure. Instead, agents could become some of the most demanding and productive consumers our platforms have ever supported. But that makes the quality of the interfaces we provide them critical.

Instead of teaching every agent how to construct infrastructure from first principles, we can expose supported capabilities with explicit contracts. Those contracts can encode the organisation's requirements around security, compliance, ownership and operations. They can provide appropriate points for approval. Crucially, they can give the teams responsible for those capabilities a mechanism to evolve them over time.

That last part matters as platform engineering has spent much of the past decade improving self-service. AI means we now need to think just as seriously about what happens after self-service succeeds.

Creating infrastructure is rapidly becoming cheaper. Owning infrastructure isn't.

The question for platform teams is therefore changing. It is no longer simply, "How do we help developers create infrastructure faster?" AI is already helping answer that question.

The harder question is: How do we make everything they create operable five years from now? That is a problem better models alone won't solve.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!

Author Bio:

Daniel Bryant is the Head of Product Marketing at Syntasso. He is a long-time coder, platform engineer, and Java Champion, contributing to several open source projects. Daniel's technical expertise focuses on 'DevOps' tooling, cloud/container platforms, and microservice implementations. He also writes for InfoQ, O'Reilly, and The New Stack and regularly presents at international conferences such as KubeCon, QCon, and JavaOne. In his copious free time, he enjoys running and reading, and plays golf badly.