AI-Native Infrastructure: The Next Cloud, or Heroku All Over Again?

AI-Native Infrastructure: The Next Cloud, or Heroku All Over Again?
August 13, 2026 · Woojae

Every few years, the infrastructure industry announces that infrastructure is finally going away.

Heroku told us to git push. Cloud computing told us we didn’t need servers. Containers told us applications could run anywhere. Kubernetes was going to make those containers easy to operate. Serverless told us we didn’t even need to think about the servers.

Somehow, after all of this innovation, we ended up with more infrastructure engineers than ever, and a truly impressive amount of YAML.

Now AI is promising another transformation. But this time, something may actually be different.

The AI revolution isn’t just changing how software gets written. It is beginning to change who consumes infrastructure.

And that could be a much bigger deal.

A New Infrastructure Layer Is Emerging

A new generation of infrastructure companies has grown up alongside AI coding tools. Vercel abstracts deployment. Supabase abstracts much of the backend. Neon rethinks Postgres around serverless compute and instant provisioning. Upstash provides serverless Redis, messaging, and workflows. Cloudflare increasingly bundles networking, compute, storage, databases, and AI services at the edge.

Individually, none of these ideas is revolutionary. Platform-as-a-Service has existed for decades. Together, however, they suggest a different application stack.

The traditional cloud-native stack looks something like:

Developer
   ↓
Terraform / Helm / CI/CD
   ↓
Kubernetes / Serverless
   ↓
AWS / GCP / Azure

The emerging stack increasingly looks like:

Developer
   ↓
AI coding agent
   ↓
Vercel / Supabase / Neon / Upstash
   ↓
AWS / GCP / Azure

The infrastructure hasn’t disappeared. We’ve simply added another abstraction layer.

Which raises an uncomfortable question: haven’t we tried this before?

The Ghost of Heroku

Heroku had an incredible developer experience. Instead of provisioning servers, configuring networking, and building deployment pipelines, developers could essentially say:

git push heroku

It was magical. Until the application became large.

Then organizations started asking uncomfortable questions about cost, control, networking, and vendor lock-in. Eventually somebody opened the AWS calculator. Shortly afterward, a platform team appeared.

The same movie is easy to imagine today. A startup builds an AI application on Vercel, Supabase, Upstash, and Cloudflare. No Kubernetes, no Terraform, possibly no infrastructure engineer at all. Then the company succeeds, the monthly bills get large, and somebody asks:

Why are we paying another company’s margin on top of AWS?

Vercel becomes Kubernetes or Cloud Run. Supabase becomes RDS. Upstash becomes ElastiCache. The Great Infrastructure Migration begins. Again.

If that’s the consistent pattern, then AI-native infrastructure isn’t the next cloud. It’s Heroku 2.0: an incredible place to start applications, but not where large applications stay.

But Something Really Is Different This Time

Heroku’s primary customer was a human developer. The new platforms increasingly have another customer:

software agents.

That’s an important distinction. A human engineer might create a few databases. An AI agent could create thousands. A human might deploy a few times a day. An organization running thousands of coding agents could produce tens of thousands of deployments.

The economics of abstraction change when the consumer operates at machine speed.

A human infrastructure engineer can tolerate Terraform → IAM → VPC → subnet → security group → RDS → parameter group → secrets → DNS. They configure it once and operate it for years.

An agent wants:

createDatabase()

and expects a connection string back.

This is where a company like Neon becomes particularly interesting. Serverless compute, instant provisioning, database branching, API-driven everything, usage-based pricing, scale-to-zero—these aren’t merely nice developer experiences. They are almost exactly the properties an autonomous software agent wants from infrastructure.

Infrastructure Designed for Machines

Cloud infrastructure was designed for infrastructure engineers. AI-native infrastructure is increasingly designed for machines.

Machines don’t want dashboards. They want APIs. Machines don’t want provisioning guides. They want structured interfaces. Machines don’t particularly care which availability zone contains their database. They care whether the application’s requirements are satisfied.

That could eventually move infrastructure from configuration-driven to intent-driven.

Today an infrastructure engineer says:

Create three replicas in us-central1 with this CPU request and this autoscaling configuration.

Tomorrow they may say:

Keep P99 latency under 200 milliseconds, survive a zone failure, keep customer data in the United States, and spend less than $20,000 per month.

An agent determines everything underneath. That would be a much bigger transition than replacing Terraform with AI-generated Terraform.

Five Futures

There are several ways this could play out.

1. Heroku 2.0

Vercel, Supabase, Neon, and Upstash dominate prototypes and startups. Once companies reach sufficient scale, economics take over and they migrate toward AWS, GCP, Azure, and Kubernetes. AI-native infrastructure becomes an enormously useful on-ramp to the cloud, but doesn’t replace the cloud.

2. The New Cloud Layer

The platforms solve their cost and scalability problems, and companies don’t migrate away as they grow. AWS, GCP, and Azure remain enormous but become invisible infrastructure underneath developer platforms. AWS becomes something like Intel Inside: most developers know it’s there, very few interact with it directly.

3. The Hyperscalers Eat the Layer

AWS, Microsoft, and Google aren’t exactly known for ignoring large infrastructure markets. Suppose AWS eventually lets you tell an agent:

Deploy this application globally, make it highly available, and keep it under $5,000 per month.

The agent chooses between Lambda, ECS, EKS, Aurora, ElastiCache, S3, and CloudFront automatically. Suddenly AWS offers Vercel-like simplicity without another company’s margin. The hyperscalers absorb the abstraction layer just as they absorbed many previous infrastructure innovations.

4. Kubernetes Wins. Again.

Perhaps the industry decides it loves the new developer experience but doesn’t love the lock-in. An open agent-infrastructure standard emerges. Agents target a portable API rather than Vercel, AWS, or Google directly, and underneath it runs Kubernetes, Postgres, Redis, and object storage across providers.

We spend ten years trying to escape Kubernetes only to discover that Kubernetes is underneath everything anyway. Nature is healing.

5. Agents Become the Control Plane

This is the scenario I find most interesting. Perhaps “Vercel vs. AWS” and “Kubernetes vs. serverless” are the wrong questions, because an AI agent will eventually make those choices itself.

A company provides requirements:

99.99% availability. US data residency. PCI compliant. P99 below 150 ms. Maximum budget of $50,000/month.

The agent decides: Cloudflare for networking, AWS for compute, Neon for Postgres, Upstash for Redis, someone else for GPU inference. Six months later it changes those decisions because pricing or workload characteristics changed.

The agent becomes a scheduler—not merely across machines, but across infrastructure providers. That starts looking like a genuine infrastructure transition.

What Happens to Kubernetes?

Probably what happened to Linux.

Linux didn’t disappear when cloud computing arrived. It became more important while becoming less visible. Most developers never think about kernel configuration, yet Linux runs underneath an enormous portion of the cloud.

Kubernetes could experience the same transformation. Instead of Developer → Kubernetes, we get Developer → Agent → Platform → Kubernetes. Developers interact with it less. Even infrastructure engineers interact with it less. But Kubernetes—or something resembling it—keeps running enormous amounts of infrastructure underneath.

Kubernetes doesn’t lose. It simply disappears behind another abstraction.

So What Happens to the Lowly DevOps Engineer?

This is where things get personal.

Every infrastructure revolution has supposedly been the one that finally eliminates infrastructure engineers. Cloud eliminated sysadmins—then companies hired cloud engineers. Containers simplified deployment—then companies hired Kubernetes engineers. Kubernetes automated infrastructure—then companies hired platform engineers to operate Kubernetes.

Now AI will automate platform engineering. I fully expect a job posting around 2030 for:

Senior Agent Infrastructure Engineer — 8+ years experience required.

The uncomfortable truth, however, is that AI probably will eliminate a significant amount of infrastructure work. Writing Terraform. Generating Helm charts. Building CI/CD configurations. Provisioning databases. Writing IAM policies. Updating Kubernetes manifests. Those are exactly the structured tasks at which coding agents are becoming extremely capable.

Companies may need fewer infrastructure engineers per developer. But that doesn’t mean infrastructure engineering becomes less important. It means the job changes.

DevOps Becomes the Control Plane

Imagine an organization with 500 developers, 2,000 coding agents, 20,000 deployments per day, thousands of temporary environments, and millions of infrastructure changes.

The primary infrastructure problem is no longer:

How do we provision infrastructure?

It’s:

How do we stop 2,000 autonomous agents from doing something incredibly stupid?

Someone has to determine what an agent can provision, what data it can access, how much money it can spend, whether it can deploy to production, what happens when it fails, how its decisions get audited and rolled back—and why Claude just created 347 Redis databases.

Congratulations. DevOps is back.

Except now the job looks like Platform Engineering + SRE + Security + FinOps + AI Governance. The infrastructure engineer becomes less responsible for manually creating infrastructure and more responsible for defining the system within which machines are allowed to create infrastructure.

The Same AI Could Also Destroy Platform Lock-In

There is another twist.

One reason companies stay on expensive platforms is migration cost. Maybe Vercel costs more than running directly on AWS—but if migrating requires six engineers and nine months, paying Vercel is still cheaper.

AI changes that calculation too. Imagine telling an infrastructure agent:

Migrate this Vercel application to GKE and Cloud SQL while maintaining 99.99% availability.

It analyzes the application, generates the Terraform and Helm charts, configures networking, builds CI/CD, migrates the database, runs compatibility tests, and produces a migration plan. Suddenly the cost of leaving proprietary platforms drops dramatically.

The same AI revolution making these platforms valuable could therefore weaken their lock-in. That is one of the strongest arguments against assuming today’s AI-native infrastructure companies automatically become tomorrow’s cloud giants.

The Question That Matters

The important question isn’t whether Vercel is the next AWS or whether Neon replaces RDS. It’s:

Does this new abstraction remain valuable when applications become large?

Heroku often failed that test. Cloud passed it. Kubernetes passed it. As systems grew, their value generally increased rather than disappeared.

AI-native infrastructure has to prove the same thing. If the lifecycle is prototype on Vercel and Neon, graduate to AWS and Kubernetes, we’ve built a better Heroku—a valuable business, but not a new infrastructure era.

If instead ten agents use AI-native infrastructure, and then ten thousand agents still use it—because humans can no longer reasonably manage the quantity of infrastructure machines create—something much more significant has happened.

Infrastructure May Finally Disappear—Sort Of

For decades, we’ve been trying to make infrastructure disappear. Cloud hid the physical servers. Containers hid the operating system. Kubernetes hid the individual machines. Serverless hid the servers. Developer platforms hid Kubernetes. AI agents may eventually hide the infrastructure APIs themselves.

But none of those underlying layers actually disappeared. They became somebody else’s problem.

The future of infrastructure may not actually be serverless. It may be operatorless.

Servers will still exist. Databases will still fail. Networks will still partition. Certificates will still expire at midnight. Cloud bills will still mysteriously increase by $700,000. The difference is that humans may no longer be the primary operators of those systems.

And somewhere underneath all those abstractions, when the agent can’t figure out why production is down, somebody will receive a message:

“Can you take a quick look at this?”

And thus, against all odds, the DevOps engineer survives another infrastructure revolution.