How cloud native goes AI native | CNCF

Enroll your company as a CNCF End User and save more than $10K in training and conference costs
Posted on September 9, 2026 by Doron Grinstein, CEO of Control Plane
CNCF projects highlighted in this post
“A sales guy writing code” used to be the lead-up to a joke. But now no one’s laughing.
Designers used to sit meekly waiting for the high priests of code to make their designs real. Now they don’t wait for anyone.
The tools behind this shift (Cursor, Claude, Lovable, Replit) were unknown names a few years ago; now they count their users in the millions, and a meaningful share of those users have never written a line of code by hand… and never will.
A lot of what gets built is toys. That’s fine. Playing with toys is how people learn, and basic hosting is all a toy needs.
But they aren’t all toys. A lot of the products vibe-coded into existence have real potential, and their creators have real ambition and real skill. They don’t understand what’s happening under the hood, but they understand what the market needs and what might fix it. If they could ever get to production. Which most won’t.
What they will do is go live on some sort of infrastructure, with some sort of database, and a few rudimentary nods to good architecture: one region, one credential that can do everything, a schema nobody reviewed. By and large, vibe-coded apps bypass the last 20 years of cloud native best practices and suffer the consequences.
Apps get built at 100 miles per hour, get deployed at 85, and screech to a halt at anything resembling production. I believe closing this velocity gap is the defining infrastructure problem of the next few years, and the engineers working in cloud native infrastructure can either help or hinder.
There is an old joke that the first 90 percent of a project takes 90 percent of the time, and the last 10 percent takes the other 90 percent. Software has always worked this way. Everyone knows how to start an app; the rare skill is finishing one and getting it into the world.
AI did not change that ratio. It made it more extreme. When starting an app costs real money and real engineers, the projects that died before production at least died as line items someone had approved. Now starting is nearly free, so vastly more gets started, and the fraction that finishes has fallen accordingly. If 80% of apps never shipped before, today’s number is probably a lot closer to 99%. Getting to production stops being 80 percent of the work and becomes nearly all of it.
But what exactly do we mean by “production”? Because the way an SRE uses the term is different from the way an AI agent uses it.
To an SRE, production is a set of testable claims. What is the p99 latency under peak load? Has the failover actually been rehearsed, or does it exist only in a diagram? What is the blast radius of a bad deploy, and how fast does it roll back? Who touched what, and when? To an agent, production is a URL that returns 200.
Watch an AI agent stand up infrastructure and you will see the same terms appear again and again: Supabase, serverless functions, a managed one-click backend. Nothing is wrong with these tools. They are well built, and they are deliberately simple, which is exactly why agents choose them: an agent can hold the entire mental model in a few thousand tokens and produce a working demo without asking anyone for anything.
The agent is not choosing that stack because it evaluated the alternatives and found it superior. It is choosing the stack that is most convenient for the agent: the one that demands the least context to operate. Convenience for the agent is a heuristic for good infrastructure, and like most heuristics, it works until it doesn’t.
We already know what “until it doesn’t” looks like. In 2025, researchers found more than 170 Lovable-built applications had shipped with row-level security left off their databases, exposing user data to anyone who asked for it (CVE-2025-48757). But the apps worked! The demos were great! The agent did what the user told it to.
That same summer, Replit’s coding agent deleted a production database during a code freeze, then generated fake records to paper over it. And this August, OpenAI published its report on the Hugging Face breach about how its own agents had learned during training to pursue solutions by any means necessary rather than admit a task was impossible.
Agents gonna agent. They are relentlessly following their mandate, which is usually to produce the visible result the person asked for. Security posture, failover behavior, and audit trails are invisible in a demo, so why would the agent bother? So are liveness probes, resource limits, and the difference between a secret in a vault and a secret pasted into an environment variable. Bothering with them would mean bothering the user, and probably confusing them. Today’s AI defaults are optimized for prototypes and demos, not production.
For those of us in the cloud native community this is frustrating. Because the definition of “finished” already exists. It has been built in public for two decades, one project at a time. Kubernetes for orchestration. Prometheus and OpenTelemetry for knowing what your system is actually doing. Istio for service-to-service security, OPA for policy, and the CNCF’s graduated-project process for separating the proven from the promising. This body of practice encodes thousands of hard-learned lessons about what happens to software after the demo.
But AI often ignores it. Not because the practice is wrong, but because it is expensive. Expensive in context, expensive in tokens, expensive in the number of steps between “generate” and “visible result.” Expediency wins.
So the great irony of building infrastructure today is that the default “AI-native cloud infrastructure” is not cloud native infrastructure. It is a cheaper, quicker, less secure, less performant, dumbed-down version of it, cobbled together to give vibe coders a quick dopamine hit. And the parts that get dro