How cloud native goes AI native

“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.

Starting was never the hard part

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.

Agents gonna agent

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.

Does cloud native get replaced?

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 dropped are exactly the parts a demo never exercises. Things like mutual TLS between services, least-privilege identity, autoscaling tuned against real load, and telemetry.

But surely as this space evolves, the definition of AI-native infrastructure must be no less secure, no less scalable, and no less observable than what a good platform team builds by hand. AI-generated infrastructure that drops the standards a human team would have held is a regression, not progress. And the way to clear the bar is not to abandon the cloud native stack for whatever an agent finds most convenient. It is to make two decades of accumulated practice as cheap for an agent to use as the shortcuts are: declarative interfaces an agent can operate deterministically, policy engines that reject a bad manifest before it ships, and the same reconciliation loop that keeps a human honest keeping the agent honest too.

Vibe coders are builders too

The other thing standing between where we are now and AI-native infrastructure that is also cloud native is not technical at all.

The people building this new flood of software are, increasingly, not developers. Gartner was predicting years ago that citizen developers would outnumber professional ones four to one, and the AI tools have blown past every low-code forecast since.

This is actually great news. Really, it is. Let me explain.

For my whole career, the people who understood the problem best (the operations manager, the salesperson, the designer) had to pass their knowledge through filters: requirements documents, tickets, a game of telephone that stripped out half the insight before an engineer ever saw it.

Now, those filters are gone. The person with the domain experience builds the workflow themselves, and the designer ships the interaction they intended instead of an approximation of it. This has produced a lot of AI slop, but it’s also produced some software that’s closer to the user, closer to solving the problem.

If we bring the same time, skill, and attention to detail to AI-built apps that we brought to hand-built ones, vibe-coded software should end up better for its users, because it is finally shaped by the people who understand them and work with them. Sometimes it’s built by the users themselves.

But our workflows have not caught up with this. Everything about the path to production (Git, YAML, CI gates, review queues) was designed by engineers for engineers.

We used to be able to treat non-developers like children. We kept them away from anything sharp, patted their heads when they had an idea, handed them a finished product, and complained that they didn’t use it.

But non-developers are building the software now, and we’ve got to start treating them like adults… like equal participants in the development process. Getting through this period requires a collaborative framework in which vibe coders, professional developers, and SREs work as one community of builders. The domain expert supplies the intent, the platform supplies guardrails instead of gates, and operational discipline lives in the paved road rather than at a tollbooth.

BYOD has become BYOApp

If this feels threatening, I understand. It felt threatening the last time, too.

Fifteen years ago, employees started carrying their own iPhones and laptops into corporate networks, and IT departments were alarmed. They had good reasons. They would be the ones on the hook if corporate data walked out the door with a user’s laptop.

The problem was, the teams that responded by banning everything got bypassed. People used their devices anyway, invisibly, which was far worse.

The teams that adapted, with device management, sensible policies, and clear boundaries, ended up somewhere better than the locked-down world they lost. They got a more dynamic workplace where people took real responsibility for their own technology.

AI and vibe coding are at the same stage BYOD was around 2010. It’s young, messy, and growing regardless of anyone’s permission.

The cloud native community gets the same choice IT got. We can hold the new builders at arm’s length and watch a generation of software default to whatever agents find convenient. Or we can do what this community has always done best: encode hard-won operational judgment into open, shared infrastructure, and this time make it legible to agents and non-developers too.

Doron Grinstein is CEO of Control Plane, which builds AI-native cloud infrastructure on the cloud native stack. Learn more at controlplane.com.