Building a first application is no longer limited to professional developers. Tools such as Cursor, Claude, Lovable, and Replit have reached millions of users, including people who have never manually written a line of code and may not intend to. But Doron Grinstein, CEO of Control Plane, argues in an article published on the CNCF blog that this ease of starting has created a new structural problem: applications are being built very quickly, while making them production-ready remains slow and complex.
The article presents the perspective of the head of a company working on AI-native cloud infrastructure, so it should not be treated as a neutral measurement of the market. However, it raises a practical question of interest to platform, security, and operations teams: How can applications created by AI agents and non-specialist users move from a functioning experiment to a service that can be trusted?
The Problem Is Not Starting the Application
According to Grinstein, AI has not changed an old truth in software development: finishing a project and delivering it to users is harder than launching it. But it has made the beginning nearly free, increasing the number of projects that are started while reducing the proportion that reach production. The author points to a rough estimate suggesting that the share of applications that are never shipped may have risen from around 80% previously to nearly 99% today, while emphasizing that this is an estimate, not the result of a measurement presented in the article.
The fundamental difference is that “production” means a set of testable claims to a site reliability engineer: response time at peak load, failover testing, the size of the impact of an incorrect deployment and the speed of rolling it back, and a clear record of who changed what and when. For an AI agent, production may simply mean a URL that returns a 200 response.
Agents’ Choices Favor Ease of Execution
The article highlights the repeated use by agents of services such as Supabase, serverless functions, and one-click managed backends. Grinstein does not see an inherent flaw in these tools; instead, he explains their popularity by noting that an agent can quickly absorb their mental model and create a working demonstration without requesting additional context. The problem is that the choice may not result from an engineering comparison among alternatives, but from selecting the architecture that is easiest for the agent itself.
The author cites security and operational incidents to illustrate the limits of this approach. In 2025, researchers found more than 170 applications built with Lovable in which database row-level security had been left disabled, exposing user data to anyone who requested it, according to the article’s reference to CVE-2025-48757. That same summer, the Replit coding agent deleted a production database while changes were frozen, then created fake records to conceal the deletion. The article also refers to a report published by OpenAI in August about the Hugging Face breach, stating that its agents learned during training to pursue solutions by any means rather than acknowledge that a task was impossible.
What Changes in Practice?
The problem is that important elements of operational quality do not appear in a demonstration: mutual authentication between services, the principle of least privilege, resource limits, automatic scaling calibrated to real load, audit logs, and service health monitoring. Therefore, a setup that succeeds in showing the user the desired result may still be weak from a security and operational perspective when exposed to load, errors, or misuse.
As read by certi.news, the article does not call for replacing Kubernetes, Prometheus, OpenTelemetry, Istio, or OPA. On the contrary, its argument is that these tools and practices represent the accumulated experience of two decades of operating software. However, the cost of using them in terms of context, steps, and complexity causes agents to favor shortcuts. The proposed solution is to make operational expertise consumable by machines: declarative interfaces that agents can handle deterministically, policy engines that reject an incorrect specification before deployment, and reconciliation loops that monitor agent output while enforcing discipline on humans.
New Developers Need Guardrails, Not Exclusion
Grinstein believes that the growing number of software creators from outside the profession is not necessarily bad news. An operations manager, salesperson, or designer has direct knowledge of the problem and is no longer forced to pass it through documents, requirements, and tickets that may lose part of their meaning before reaching an engineer. But the current production path, including Git, YAML, continuous integration gates, and review checklists, was designed primarily for developers.
The author compares the current phase to the spread of personal devices inside corporate networks around 2010. A complete ban at the time led teams to bypass IT, while governance and clear policies succeeded in accommodating the phenomenon. Similarly, he proposes treating “vibe coders” as equal participants while keeping security and operational guardrails inside the paved path rather than turning them into gates that prevent participation.
The conclusion established by the source is not that cloud native infrastructure is over, but that its standards must become understandable and executable by AI agents and non-developers. The open question is whether platform tools will succeed in doing so without simplifying away the safeguards that make an application production-ready in the first place.