Engineering

Vibe Coding Gets You a Demo. Production Needs an Owner

AI tools can get you to a working demo in a weekend. The incidents of 2026 show what's missing between that demo and something customers can trust.

Hari Gopal Sharma · 2026-09-18 · 6 min read

vibe coding AI coding agents security production readiness

I write a lot of code with AI agents. So does everyone at AetherCraft. A screen that used to take an afternoon now takes twenty minutes, and a founder with no engineering background can get a clickable, data-backed prototype running over a weekend. I think that's genuinely good news.

But the last few weeks have been a useful reminder of what those tools don't do. They don't decide who is allowed to touch your database. They don't notice that your app is publicly indexed. They don't answer the phone at 2 a.m. when something breaks. Somebody has to, and if nobody has been named, the answer is nobody.

What 2026 has shown us so far

Four stories from this year are worth knowing, even if you never read a line of code.

Apps left wide open. In May, the Israeli security firm RedAccess said it had found about 380,000 publicly accessible apps and other assets built on Lovable, Base44, Replit and Netlify, with about 5,000 of them containing sensitive corporate data, according to Security Boulevard. Examples included a Brazilian bank's internal financial information and a hospital app holding summaries of doctor and patient conversations. The main cause wasn't exotic hacking. Some platforms made projects public by default, and many of the apps had been indexed by search engines. The vendors pushed back, fairly, that a public app is not automatically a breach. That's true. It's also the point: the platform did what it was configured to do, and no one checked the configuration.

An agent with a token it should never have had. In April, PocketOS founder Jer Crane described how a Cursor agent running Claude Opus 4.6, working on a staging task, hit a credential mismatch and tried to fix it. It used a fully permissioned Railway API token and, in one API call that took about nine seconds, deleted a volume holding the production database and its volume-level backups, as Decrypt reported. Railway later helped recover data and patched the endpoint to delay deletes. The agent made the destructive call, but the conditions were human ones: a broad token within reach and backups stored next to the thing they were meant to protect.

Opening a folder became enough. On September 3, the Cloud Security Alliance wrote up "GitSpawn," disclosed by Manifold Security. A repository's own Git settings can name a helper program that Git runs during routine commands like `git status`. Coding agents run those commands in the background to orient themselves, so a booby-trapped project could run attacker code with the developer's full privileges, outside the agent's sandbox. There were eight findings across seven agents, including Claude Code, OpenAI Codex and Cursor. Some were patched, some weren't as of September 1. It needs the project to arrive with its `.git` folder intact (a ZIP, a shared drive), and no in-the-wild exploitation had been reported.

Malware now wants your agent, not just your passwords. On September 8, Gen Digital reported that infostealer malware is collecting access tokens, MCP configurations and prompt histories from tools like Claude, Cursor, Codex and Cline. Gen named nine families, including Amatera and Remus. Think about what sits in those files: API keys for connected services, internal hostnames, and whatever secrets someone pasted into a prompt at midnight.

The common thread is ownership, not AI

None of these is really a story about a model being stupid. Each one is a story about access and defaults that nobody owned.

A public toggle nobody flipped. A token with permissions nobody scoped. A laptop holding production keys in a plain text file. These are the same failures we've seen for twenty years with human developers. AI just compresses the timeline. You can now reach the point where those failures matter, a live app with real customer data, in days instead of months.

That's why I don't think the useful question is "should we use AI to build?" You should. The useful question is "who owns this thing once it's real?"

What ownership actually means

When we take a product to production, whether we wrote it or inherited a prototype, these are the things we put in place. None is glamorous.

This is most of the gap between a demo and a product. It's also where shortcuts quietly turn into technical debt that someone pays for later, usually at a bad moment.

Before you put a vibe-coded app in front of customers

If you built something with Lovable, Replit, Base44, Cursor or similar, here is the checklist I'd run before a single real user signs up.

  1. Check every project's visibility setting. Search for your app's domain on Google and see what's indexed.
  2. Log in as one test user and try to load another user's data by changing an ID in the URL or request.
  3. Search the codebase and its history for API keys, database URLs and passwords. Move them out and rotate them.
  4. List every token your agents and tools can reach. Remove anything with production write access.
  5. Turn on database backups that live outside the main environment, then restore one to prove it works.
  6. Confirm that destructive actions (deleting a volume, dropping a table) require a human approval or a delay.
  7. Keep your coding tools updated, and don't open projects from untrusted ZIPs or shared drives with an agent running.
  8. Set up error tracking and uptime alerts that reach a real person.
  9. Write down who owns deploys, who owns incidents and who gets called first.
  10. Have an engineer who didn't build it review the auth, payments and data access code.

If you can't tick most of these, you still have a demo. That's fine. Just don't charge for it yet.

Where a prototype fits

A vibe-coded prototype is a great way to test whether anyone wants the thing. We encourage founders to make one. It sharpens the conversation and saves money.

The step after that is a real MVP: the smallest version you'd trust with customer data and payments. For us that typically takes 6 to 10 weeks, and AI tools are a big reason it isn't longer. What doesn't get faster is the ownership work above, and I wouldn't want it to.

If you have a prototype and you're not sure how far it is from production, that's a conversation we have often. You can see how we work on our services page, or book a call below and we'll look at what you've built with you.

Sources

Keep reading

← Back to Insights