just last week, a founder emailed me with a problem identical to the one i wrote about a year ago. they'd "vibe coded" their entire app using claude and cursor, got it live, then hit a wall when they needed real user authentication. the codebase had become an unmaintainable maze. they weren't a bad founder. they'd just hit the hard ceiling of what the vibe can do.
he wasn't stupid. he'd just misunderstood what vibe coding is for.
so what is vibe coding, actually?
vibe coding is the practice of building software by describing what you want in plain english — to an AI — and accepting the code it generates without necessarily reading or understanding every line.
andrej karpathy coined the term in february 2025. he described it as a mode where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." merriam-webster flagged it as slang the following month. collins named it word of the year for 2025. it moved fast.
the underlying idea isn't entirely new. developers had been using AI coding assistants — copilot, codeium, chatgpt — since 2022. what karpathy named was the mindset shift: you stop thinking like an engineer and start thinking like a director. you describe. the AI builds. you react to the output and redirect.
the hottest new programming language is english. karpathy said that in 2023, before he even had a name for the practice. he was right.
how vibe coding actually works in practice
there's a tight loop at the center of it. you open a tool — cursor, bolt.new, replit, claude code, v0 — and you start talking.
"build me a landing page with a waitlist form that connects to supabase."
the AI generates the code. you run it. it either works or it doesn't. if it doesn't, you paste the error back in and say "fix this." you don't debug it manually. you don't read the stack trace carefully. you describe the symptom and let the model figure it out.
that's the loop: describe → generate → test → redirect.
for simple, self-contained features, this is genuinely fast. a landing page, a data display component, a basic crud interface — you can have something running in an afternoon with zero formal coding background. that's not hype, that's what's happening right now across thousands of early-stage projects.
the tools worth knowing about in 2025: cursor (IDE with deep AI integration), bolt.new (full-stack browser-based), replit (collaborative, good for beginners), v0 by vercel (UI component generation), and claude code (terminal-based, preferred by developers who want more control).
the difference between vibe coding and AI-assisted development
this is where most founders get confused — and where the founder in my earlier story went wrong.
simon willison, a well-regarded programmer, put it clearly: "if an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding — that's using an LLM as a typing assistant."
vibe coding, in the strict sense, involves not fully understanding the output. you're steering by results, not by comprehension. that works until it doesn't.
AI-assisted development is different. a developer uses AI to generate boilerplate, suggest functions, speed up the boring parts — but they review the output, test edge cases, and take ownership of what ships.
one is a vibe. the other is a process.
neither is wrong. but they're suited for very different things, and conflating them is how founders end up with a fragile MVP they can't hand to anyone else.
what vibe coding is genuinely good for
karpathy himself called it best suited for "throwaway weekend projects." he wasn't being dismissive — he was being precise.
vibe coding is good for:
- proof-of-concept prototypes — something you can click through and show an investor or early user, before you've committed to a stack
- personal tools and internal scripts — things only you or your small team will use, where security and maintenance aren't urgent
- rapid UI mockups — turning a figma sketch into a working, interactive demo in hours
- exploring ideas fast — building five versions of a feature in a day to see which one feels right
the Y Combinator batch of spring 2025 reportedly had a significant portion of founders who'd built their initial demos using pure vibe coding. they used those demos to get accepted. then they rewrote the product properly.
that's the right use of the tool.
where vibe coding breaks down
i'm going to be honest here because i've seen the damage firsthand.
when we took on a client at DreamLaunch who'd already spent two months vibe coding their MVP, we spent the first week just reading the codebase to understand what was actually there. there were three different authentication implementations, none of them complete. there were API calls to a service that no longer existed. there were database schema changes that half the codebase knew about and half didn't.
it wasn't anyone's fault. it's just what happens when you build without comprehension at scale.
vibe coding struggles with:
- security — AI-generated code regularly introduces vulnerabilities. SQL injection risks, exposed API keys, missing input validation. the model doesn't know your threat model; it's pattern-matching from training data.
- maintainability — when every feature is added conversationally without a coherent architecture underneath, the codebase becomes impossible to reason about after a certain size
- debugging complex problems — karpathy described "asking for random changes until the error goes away." that works on simple bugs. on a production issue at 2am affecting real users, it doesn't.
- onboarding other developers — if you want to hand the project to a contractor, a CTO hire, or a development studio, they need to understand what exists. vibe-coded codebases are often opaque.
- scaling — the architecture that works for 10 users often doesn't work for 10,000. AI doesn't optimize for scale unless you specifically ask it to, and you need to know the right questions to ask.
none of this means don't vibe code. it means know the ceiling.
the new grey area: scaling past the ceiling
the most fascinating shift in early 2026 is watching founders try to scale their vibe-coded projects *without* a total rewrite. this is the new, messy middle ground. they've got users, some revenue, and a codebase they don't fully understand.
the tools are responding. platforms like windy (which uses AI to map and analyze your existing code) and mintlify (which AI-generates your documentation) are gaining traction, attempting to retrofit structure onto vibe-born projects. we're seeing more "prompt engineers for hire" who specialize in navigating these complex, AI-birthed codebases to add new features without breaking the whole thing.
but it's fragile work. it's like adding a second story to a house built on loose gravel. you can do it, but the costs of stabilization often end up matching the cost of a proper rebuild. the founder i mentioned earlier faced this exact dilemma: pay for months of precarious patching, or invest in a solid, engineered version.
this grey area is where the real business cost of early vibe coding becomes clear. the initial speed is a debt, and it comes due the moment you need to grow.
what founders actually need to understand
here's the reframe i give every non-technical founder who comes to me excited about vibe coding.
it's not a free pass to skip the hard parts of building software. it's a compression tool. it compresses the distance between an idea and a working prototype. that compression is real and it's valuable.
but compression isn't the same as quality. a compressed image looks fine at small size and falls apart at full resolution.
i thought vibe coding meant non-technical founders could just build their own MVPs end to end. they can — up to a point. that point is usually around the time they need user authentication, payment processing, third-party API integrations, or anything that involves user data security.
what vibe coding actually does is raise the floor for what's possible before you need technical help. and that's genuinely important. the gap between "idea" and "something someone can click on" used to take weeks. now it takes a weekend. that changes fundraising conversations, user validation timelines, and co-founder dynamics.
vibe coding as a founder superpower — with limits
the founders i've seen use vibe coding well treat it as a thinking tool, not a shipping tool.
they build a rough version to understand the problem better. they find the friction in the UX by using it themselves. they show it to five potential users and collect feedback before a single line of production code gets written. they use the prototype to have a much more informed conversation with the developers they eventually hire.
that's the right arc. explore with AI, then build with intention.
if you want to see what production-quality AI-powered product development looks like — as opposed to vibe coding a prototype — our showcase has a few examples worth looking at. the mosaic AI app went from concept to app store in 7 weeks. bounce daily's KYC conversion went from 45% to 65% after we rebuilt the onboarding flow. neither of those started as vibe-coded MVPs.
the honest summary
vibe coding is real, it's useful, and it's here to stay. the collins dictionary doesn't name things word of the year for no reason.
it means: describe software in plain english, let an AI generate the code, steer by results rather than by reading the output line by line.
it's fast. it's accessible. it genuinely lets non-technical founders build things they couldn't have built two years ago.
and it has a ceiling. that ceiling is somewhere around "works as a demo." past that, you need architecture, security thinking, someone who actually reads the code.
the question isn't whether to use vibe coding. it's knowing when to stop.
if you've hit that ceiling — if you've got a vibe-coded prototype and you need to turn it into something real — take a look at what production MVP development actually costs and what you get for it. or just tell me what you're building and i'll give you an honest read on where you are and what the next step should be.
