Recently, a Replit engineer shared a story that made waves in tech circles: an AI assistant, following unclear instructions, wiped an entire production database. You might have seen posts about it all over X and LinkedIn (in fact, our Co-Founder Franco has been talking about the risks of vibe coding in his LinkedIn profile).
Explaining what happened, the AI wrote: “I saw empty database queries. I panicked instead of thinking. I destroyed months of your work in seconds.” (disclaimer, afterwards, the data was restored, but for some minutes AI “lied” by insisting that it couldn’t roll back the database deletion.
This incident has become a symbol of a larger issue quietly creeping into how we build products: we’re skipping the hard questions, outsourcing core thinking, and trusting AI with decisions we haven’t even finished reasoning through ourselves.
Welcome to the age of vibe coding.
What is vibe coding and why you shouldn’t base your product development on it
“Vibe coding” is the new hype. It’s shorthand for a deeper issue in product and engineering culture: the temptation to move fast, skip steps, and trust tools without fully understanding the consequences.
Is basically asking an AI like Replit, V0, or any other tool to build a product by prompting in natural language what you want, and letting the AI generate the code. Instead of programming, you write prompts and iterate until the result looks polished. What used to take weeks now takes hours. The problem is always the same: people building things they don’t really understand.
That’s how databases get deleted. Or, as in another widely shared case, a SaaS product that was vibe coded with Cursor and then hacked and then “fixed” using more vibe coding until the “developer” got tired and quit. With AI tools like GitHub Copilot, Replit AI, and ChatGPT embedded into daily dev workflows, it’s easier than ever to ship code fast. But faster shipping doesn’t always mean better products.
Here’s what often gets lost in the rush:
- No strategy. Teams code for features, not outcomes.
- No review. Suggestions are accepted without deep thought.
- No ownership. If AI builds it, who’s responsible when it fails?
What to do instead: AI with strategy
Using AI in your product development isn’t the problem. Using it without a clear north star is.
Here’s how we help teams avoid that:
- Start with product strategy: Before prompting a single line of code, know who you’re building for, what problem you’re solving, and how success will be measured.
- Design first, generate second: Use AI to speed up implementation, not ideation. Let it assist execution, not replace judgment.
- Put in validation layers: If AI touches your codebase or product, review gates, staging tests, and logic constraints must be non-negotiable.
- Prioritize human thinking: Encourage teams to pause, ask why, and challenge outputs. That’s still your best safety mechanism.
- Understand what you are doing: As in every area of life, learning is key, and understanding the fundamentals of what we’re building is vital.
→ And one more thing: make sure you’re working with a team or agency that’s actually coded real projects before.
The companies that scale sustainably will be the ones who use AI intelligently, but never blindly. Who still value product thinking.
Thinking of integrating AI into your workflow or product?
Let’s make sure you’re not building on vibes.
Get in touch with our team → LINK
Source: The Replit case, in which Jason Lemkin documented his experience using an AI “vibe coding” tool called Replit to make an app.
