Everyone's vibe coding right now.
You open Lovable, Bolt, or Cursor, describe your idea, and watch code appear. It feels like magic. And honestly, for a demo, a prototype, or a quick experiment, it kind of is.
But there's a gap between a demo that works in a browser tab and a product that handles real users, real data, real edge cases, and real traffic. We've seen what happens when founders try to ship "vibed" code straight to production. It's not pretty.
We build MVPs for a living. We use Claude Code for development and tools like Claude, ChatGPT, and Perplexity for research, scoping, and ideation every single day. Here's what we've learned about the difference between using AI well and using AI recklessly.
What Vibe Coding Actually Is
Vibe coding is what happens when you treat AI as a replacement for thinking rather than a tool that amplifies it. You describe what you want, accept what comes out, and keep prompting until it looks right. No architecture decisions. No review. No understanding of what the code actually does.
It produces output fast. That's the seductive part.
The problem is that AI models optimise for code that looks correct and runs locally. They don't optimise for code that scales, that's secure, or an architecture that's maintainable six months from now, or that won't fall apart when two things happen at once.
Vibe coding at its worst is just technical debt at the speed of light.
Where AI Genuinely Helps in an MVP Build
Before we get into what not to do, AI is genuinely transformative when used right. Here's where it actually moves the needle for us:
Boilerplate and scaffolding. Setting up a Next.js project with auth, database connections, API routes, and a component library used to take days. With Claude Code, it takes hours. This is pure acceleration with almost no downside.
CRUD and standard patterns. Forms, data tables, list views, detail pages, the bread and butter of most MVPs. AI handles these well because they're well-represented in training data and follow predictable patterns.
Debugging with context. Pasting an error and relevant code into Claude and getting a precise diagnosis is genuinely faster than most Stack Overflow searches. We use this constantly.
First drafts of complex logic. When we need to write something non-trivial, a matching algorithm, a pricing calculation, a webhook handler, AI gives us a solid first draft that we can review, test, and refine. It's not the final answer, but it's a much better starting point than a blank file.
Where Vibe Coding Breaks Production MVPs
Here's where things go wrong if you just vibe and ship:
Authentication and security. AI will write auth flows that work. It will not always write auth flows that are secure. Session handling, token expiry, permission checks, CSRF protection, these require deliberate review. We've seen AI-generated auth code that technically "worked" but had holes you could drive a truck through.
Database design. Asking AI to generate a schema based on a feature description often produces something that works for the demo but creates problems at scale. Missing indexes, wrong relationships, no soft delete pattern, no audit trail. Changing a schema after users have real data is painful. Get this right upfront.
Error handling. Vibe-coded apps fail silently. A properly built MVP fails loudly, with clear error states, user-facing messages, and server-side logging you can actually debug. AI won't add this unless you explicitly ask for it and review what it produces.
State management and race conditions. Two users hitting the same endpoint at the same time. A webhook arriving twice. A payment completing while a user refreshes. These edge cases are where vibe-coded apps break in the real world. You have to think through them yourself, AI will help you implement the solution, but it won't proactively identify the problem.
Architecture and File Structure Before You Touch AI
This is the step most founders skip, and it's the one that causes the most pain later.
When you jump straight into Claude Code without a clear architecture, you end up with a codebase that's held together with duct tape. AI generates code that works in isolation but doesn't fit together cleanly. You get duplicated logic scattered across files, inconsistent patterns between features, and shared utilities that get rewritten three different ways because nobody decided where they lived. Adding anything new becomes slower than it should be.
Before we write a single line of code on a new project, we define the structure: what the folder layout looks like, how data flows between the frontend and backend, where shared logic and utilities live, what the naming conventions are, and how components are organized. We use Claude and ChatGPT heavily in this phase, not to write code, but to pressure-test the architecture, think through data models, and spot the decisions that are much harder to reverse later.
Once that foundation is set, AI becomes dramatically more useful. It's generating code into a structure it can follow consistently, rather than making up new patterns every time. The output is cleaner, easier to review, and far easier to extend as the product grows. You also end up reviewing AI output faster because you know exactly where something should live and what it should look like. Anything that doesn't fit the pattern is immediately visible.
The architecture phase doesn't take long. A few hours on a new project. But skipping it costs you days later.
How We Actually Use AI at Toggle
We're not anti-AI. We're the opposite. But we use it with a structure that keeps the output production-quality.
We architect first, then use AI to build. Before we write a line of code on a new feature, we've already decided: what's the data model, what are the API contracts, what are the edge cases, what could go wrong. We use Claude, ChatGPT, and Perplexity heavily in this phase for research, scoping, and thinking through the design. Claude Code then helps us implement that design quickly. The thinking isn't delegated.
We review everything it writes. Not line-by-line for every component, but we always understand what the code is doing and why. If we can't explain a block of AI-generated code, we don't ship it.
We write tests for anything that matters. Critical flows, auth, payments, data mutations, get tested. AI is actually great at writing tests once you give it the right context. This is one of the highest-leverage uses of AI in a production codebase.
We use AI for speed, not for skipping judgment. The goal is to ship a production-ready product in 2 weeks, not to ship 2 weeks of vibed code. Those are very different things.
The Right Mental Model
Think of AI tools the way a senior developer thinks about a junior developer who types very fast.
You'd give that junior developer clear direction. You'd review their PRs. You'd catch the things they missed. You wouldn't merge everything they wrote without looking at it just because they shipped it quickly.
AI is that junior developer, incredibly fast, broadly capable, occasionally overconfident, and not responsible for the consequences of what it produces. You are.
The founders who get this right ship faster and more reliably. The ones who don't end up with a product that works in the demo and breaks in production, which is exactly what you don't want when real users are depending on it.
We've shipped 20+ production MVPs using AI tools throughout the build. If you want to know how we'd approach yours, let's talk.
