· ai-devtools

AI Made Building Apps Easy, but Who Really Runs Them?


A product manager once shared a story: they launched a client reporting application over a weekend using an AI coding tool, allowing customers to try it. Everything functioned splendidly until the team discovered the authentication was broken and the application's admin interface was discoverable by anyone.

This scenario is no longer rare. We are observing an increasing trend where non-engineers construct applications in mere hours to test concepts, subsequently deploying them without deeply considering security, performance, or scaling. Typically, an AI-generated application prioritizes speed and functionality, leaving its creator without the time or background knowledge necessary to ensure robustness and security.

These applications often run completely exposed on public infrastructure. The builders are not intentionally negligent; the tools make achieving "it works" so simple that the subsequent operational concerns are often overlooked. Stack Overflow reported that 84% of respondents utilize or intend to use AI tools. Furthermore, Gartner projects that by 2028, 40% of new enterprise production software will emerge from vibe coding techniques and tools.

What remains largely unaddressed is the moment an application must withstand interaction with actual end-users. The people deploying these apps have transformed, yet the underlying infrastructure has not adapted. Much of the existing infrastructure assumes the deployer understands the environment they are putting the application onto.

Now, product managers, founders, and domain experts—prompting their way to functional software—are shipping more production apps. While these individuals are capable builders, they are not required to be infrastructure specialists. Nevertheless, their applications still demand uptime, patching, and a strategy for handling traffic surges. Gartner forecasts that prompt-to-app methods adopted by citizen developers will escalate software defects by 2,500% by 2028.

The established trade-off is obsolete. Teams deploying AI-built applications today face choices ill-suited to the pace of vibe-coding. Serverless platforms offer an easy starting point, but trouble arises with unpredictable traffic, such as a viral social media post or bots hitting an unprotected endpoint. The usage-based pricing model makes cost prediction difficult under such patterns; a demo's affordable appearance can turn costly in production, potentially forcing scaling changes based on platform limits rather than application needs.

Conversely, a self-managed VPS keeps costs predictable, but it places the burden of continuous administrative tasks—patching, monitoring, scaling, and security—onto someone, demanding a level of operational capacity. Most small teams and solo builders lack these resources, causing patches to slip unnoticed until an outage or breach occurs.

The infrastructure sector has long observed costly, unpredictable failures stemming from this mismatch between who manages a system and what that management entails. A necessary shift demands a managed layer that transcends the simple division between serverless and VPS. This next infrastructure layer must be evaluated against four key questions.

These questions include: Is cost predictable during a spike? A successful launch should not result in a surprise invoice; one must ask what the bill looks like at ten times normal traffic. Can it operate securely without a dedicated operations hire? This requires checking how quickly OS and runtime security patches are applied and confirming backups function automatically and restore successfully. Can the app scale without a complete rebuild? Growth from 100 to 100,000 users should not necessitate a full rebuild, so one must assess where each layer hits a ceiling.

Finally, are the security defaults sound? Given the risks inherent in AI-generated code, infrastructure defense is vital, though it cannot mend application authentication flaws. One must verify if databases are private by default or accessible from the Internet, and look for basic defenses against bots and role-based access to prevent a single leaked credential from causing total exposure. Many current platforms excel at only one or two of these aspects, a trade-off that was acceptable when the platform selector possessed deep infrastructure knowledge, but it is riskier when that expertise is absent.

Practitioners do not need to await market convergence. The most effective action is to simplify the safer route. AI accelerated software creation far faster than the industry adapted how that software runs. This imbalance is not yet fully priced in. While the creation tools are radically more accessible, the infrastructure supporting them has not matched that velocity. Closing this gap represents the next significant infrastructure challenge, and the teams that solve it first will drastically reduce the time spent cleaning up after AI-assisted builds.

Related coverage

Also worth reading

  1. next.js 16.5.0-canary.35 released
  2. next.js 16.5.0-canary.33 released
  3. angular 22.2.4 released
  4. LibreOffice's 'no AI' stance meets LLM-assisted code
  5. “Urgency is an inherently subjective call”: Anthropic tells TNS how it grades Claude Duet