You're Probably Vibe Coding in Production

I managed enterprise IT projects starting in 2003, well before “vibe coding” was a phrase and before AI wrote a line of code for anyone. One habit from that world never left me: I don’t touch the version of an app that real customers are using. I build in one place, test in a second place, and only then does anything reach the third: production. The live thing.

I’d bet most people vibe coding an app or a small SaaS today skip straight to that third one. Not because they’re careless. Because nobody ever told them there’s supposed to be stages.

Here’s the gap, in plain terms. “Production” (or “prod”) is the live version of your app or website, the one your customers are actually touching right now. When you ask your AI to “add a feature” or “fix that bug” and you’re pointed at the same URL your users bookmark, the same database holding their real records, you’re not testing anything. That’s doing surgery on a patient who’s awake and walking around.

Enterprise teams solve this with separate copies of the same app:

• Dev. Your sandbox. Break it constantly. Nobody sees it but you and your AI.
• QA (also called “staging”). A copy that looks and behaves like the real thing, where you click through the new feature before customers ever see it.
• Prod. The live version. Nothing touches it until it’s already been proven safe somewhere else.

None of that requires hiring an IT department. If you’re using a modern hosting platform, Vercel, Netlify, Railway, most of what today’s vibe-coding tools push you toward, you likely already have “preview” or “branch” deployments turned on and don’t know it. Every version of your code that isn’t your main branch gets its own throwaway URL automatically, no extra setup required. That’s a Dev environment just waiting for you to use it.

This also goes one level deeper, the database. Your code can live in three neat little branches, but if all three point at the same database, you have all the same risks of messing up your website, or service or SaaS. This is the part I see skipped most often, because setting up a second database takes a few extra minutes and few vibe-coding tutorials that I’ve seen ever mention it.

Ask your AI directly: “Are we coding in production? Or do we have staged environments for Dev, QA, and Prod? How about our database(s)?” If you’ve read this far, go ahead and assume you’re not using staged environments. Ask your AI what the risks are of how you’re currently working and how much effort it will be to move to staged environments.

Just about any story you read about someone’s AI deleting all their customer records… is because they were vibe coding on their production data. Not good. They probably didn’t know that’s not how the IT world works.

You don’t necessarily need all three environments today, or perhaps ever, if your project is small enough that the only real risk is your own time. But the moment real people, real money, or a customer’s data touches what you’re building, that story changes.

If you’re vibe coding something that matters, the next prompt worth typing isn’t “add this feature.” It’s “let’s discuss the pros and cons of setting up separate Dev, QA, and Prod environments for this app, including the database. Teach me how this should work.”

Mark Zuckerburg coined, “Move fast and break things.” He was known to edit live code on Facebook in the early days while millions of users were using the site live. Unless you’re him… don’t try to be him.