Vibe coding: build a real app using plain English
In 2025, "vibe coding" became the Collins Dictionary word of the year.
Vibe coding: build a real app using plain English
Part 8 of the "Build with AI" series
In 2025, "vibe coding" became the Collins Dictionary word of the year.
That's remarkable for a technical term — but it captures something real. The idea that you can describe what you want to build in plain language, and an AI will build it, has moved from science fiction to daily practice for millions of people in the span of about two years.
But here's what the hype doesn't tell you: most people who try vibe coding get frustrating results. Not because the tools don't work, but because they approach it the same way they approach prompting a chatbot. They describe what they want loosely, get something that looks almost right, patch it endlessly, and never quite get to something they'd show to anyone.
This post is about how to actually do it — the mindset, the workflow, and the practical steps to go from an idea to a working, deployable app without writing code yourself.
What vibe coding actually is
Vibe coding is using AI — specifically AI coding assistants and generative UI tools — to write the code for you, based on your natural language descriptions. You describe. The AI implements. You review, test, and iterate.
The name comes from the feeling of it: you get into a flow state where you're thinking about what to build and why, not how the code works. The implementation layer almost disappears.
But "vibe" is a bit misleading. The best vibe coders aren't just winging it. They're precise about what they want, systematic about testing, and disciplined about iteration. The vibe is in the experience — not in the approach.
The term was coined by Andrej Karpathy, one of the founders of OpenAI and former AI director at Tesla. His description was precise: describe what you want, the AI generates code, you run it, describe what's wrong or what you want next, and iterate. You're not writing code. You're directing it.
What made this possible
Three things converged to make vibe coding genuinely viable.
Models got good enough at code. Today's frontier models — Claude Opus 4.6, GPT-5.2 — write production-quality code in dozens of languages, debug their own mistakes, and reason about architecture. They don't just autocomplete; they architect.
Context windows got large enough. An entire codebase can now fit in a single context window. The AI sees everything at once — your components, your logic, your styles — and makes changes coherent across the whole system.
Purpose-built tools emerged. Cursor, Bolt, Lovable, Replit, and v0 are not just text editors with AI bolted on. They're environments designed around the vibe coding workflow — where your description is the primary input and code is the output you never have to fully understand.
The combination means the gap between "I have an idea" and "here is a working thing" has collapsed from months to hours.
The tools in 2026
The field has matured significantly. Here's what's actually being used:
For full-stack web apps (no setup required):
- Bolt.new — describe your app, get a full-stack application. Strong for rapid prototyping. One of the most beginner-friendly options.
- Lovable — similar to Bolt with a polished UI focus. Particularly good for consumer-facing products where visual quality matters.
- Vercel v0 — AI-powered component generation tightly integrated with the Vercel deployment ecosystem. Best if you're in the Next.js world.
For code-level building (more control):
- Cursor — VS Code fork with AI deeply integrated. You write prompts, Cursor writes, edits, and refactors code inline. The go-to for developers — but increasingly used by non-developers who want more control.
- Claude Code — Anthropic's agentic coding tool. Handles entire codebases, plans multi-file changes, and executes them. Particularly powerful for complex projects.
- Windsurf — a strong Cursor alternative with different strengths in agent-mode coding.
For specific use cases:
- Replit — browser-based, no local setup. Great for learning and quick experiments.
- Glide / AppSheet — data-driven apps and internal tools built directly on spreadsheets or databases.
The right choice: if you want something visible fast with no technical setup, use Bolt or Lovable. If you want more control and are willing to learn, try Cursor. For complex multi-file projects, Claude Code.
The vibe coding workflow
This is where most guides fall short. They show you the tool, not the process. Here's the actual workflow that produces real results:
Phase 1: define before you build
Go back to Post 5. Before you open any tool, write your one-paragraph problem definition. Know:
- What the app does (specifically)
- Who uses it (specifically)
- What a successful first version looks like (specifically)
- What it does not need to do yet
The MVP trap: most people try to build the full vision on their first attempt. Don't. Define the smallest version that would be genuinely useful. Everything else is version 2.
Phase 2: scaffold the structure first
Don't start by asking the AI to build the whole app. Start by asking it to plan.
"I want to build [your one-paragraph description]. Before writing any code, give me:
- The key screens or pages this app needs
- The main data it needs to store and display
- The user flow from first open to completing the main action
- Any potential complexity I should think about before building"
Review this. Push back on anything wrong. Add anything missed. Five minutes here prevents hours of rebuilding.
Phase 3: build in layers
Build incrementally — one feature at a time, tested before moving to the next.
- Layer 1: skeleton — navigation, basic screens, placeholder content. No logic yet.
- Layer 2: data — what gets stored, how it's organized, basic display of real data.
- Layer 3: core action — the single most important thing the app does. Working end to end.
- Layer 4: secondary features — everything else, added one at a time.
Each layer gets confirmed before the next begins. This is what separates a working app from an impressive demo that breaks as soon as you click anything unexpected.
Phase 4: the debugging mindset
Things will break. This is not failure — it's the nature of software.
When something breaks, don't patch randomly. Instead:
Describe precisely:
"When I click Submit, nothing happens. I expected it to save the entry and show a success message. The button appears and is clickable but has no effect."
Show the exact error: copy it verbatim from the browser console. Don't paraphrase.
Ask it to explain before fixing:
"Before fixing this, explain what you think is causing it and why."
If the AI diagnoses incorrectly, you catch the misdiagnosis before a wrong fix makes things worse. And you learn something about how your code works.
Phase 5: test like a user, not a builder
Builders test happy paths. Users find edge cases.
After each feature:
- What happens if you leave a required field empty?
- What happens if you click the same button twice quickly?
- What happens on a mobile screen?
- What happens if there's no data yet?
These aren't obscure edge cases. They're things real users do in the first five minutes.
A real walkthrough: building a lead tracker
Here's how you'd build a simple lead tracking tool for a consulting firm — from nothing to deployed in an afternoon.
The brief: A web app where our team can log new leads, record their stage (new / contacted / meeting scheduled / proposal sent / closed), add notes, and see all leads in a table sorted by stage.
Step 1: Open Bolt.new
Step 2: structure prompt
"I want to build a simple lead tracker web app. Before coding, tell me: what screens does it need, what data should it store, and what's the simplest first version?"
Review the response. Confirm and proceed.
Step 3: scaffold prompt
"Build the skeleton: a main page with a table showing leads, an Add Lead button, and a simple form with fields for: company name, contact name, email, phone, status (dropdown: New / Contacted / Meeting Scheduled / Proposal Sent / Closed Won / Closed Lost), and notes. Use placeholder data for now. Make it clean and professional."
Does it look structurally right? Good — move on.
Step 4: wire the data
"Make the Add Lead form actually work — when submitted, the new lead should appear in the table. Store in app state for now."
Test. Add a lead. Does it appear? Yes → proceed. No → debug first.
Step 5: add filtering
"Add the ability to filter leads by status. When I click a status, only those leads show. Add a 'Show All' option."
Test the filter. Does it work correctly?
Step 6: deploy Bolt has a built-in deploy button. Click it. Live URL in seconds, shareable with your team immediately.
Total time: 2–3 hours. Zero code written by you. A working, deployed app.
The honest limits
Vibe coding is powerful, but you'll hit these walls and should know they're coming.
Complex business logic — simple CRUD apps work well. Apps with complex conditional logic, multi-step calculations, or intricate state management are harder to build and much harder to maintain when things go wrong.
Production security — apps for internal use or prototypes are fine. Apps handling sensitive user data, payments, or requiring proper authentication need a developer involved, or a managed security platform (Supabase Auth, Clerk, Firebase).
Database at scale — in-memory state is fine for prototypes. When you need real persistence or user accounts across sessions, wiring in a proper database is a meaningful step up in complexity.
Long-term maintenance — vibe-coded apps accumulate technical debt. After many rounds of iteration the code can become inconsistent and hard to extend. Keep apps focused. When they need significant growth, consider a clean rewrite.
Who this actually benefits
The deeper shift vibe coding represents isn't about replacing developers. It's about who gets to build.
Before: if you had a problem that needed a software solution, you hired a developer, used a tool that didn't quite fit, or waited.
After: you build the tool that fits your exact situation. The internal tool your team actually needs. The prototype that shows investors what you're building. The customer-facing feature you've been requesting for months. In an afternoon.
The people who get the most from this are domain experts — people who understand a problem deeply but couldn't previously translate that understanding into software. A consultant who knows exactly what clients need. An operations manager who sees the inefficiency every day. A founder with the vision but not yet a technical co-founder.
That's who this is for. And the tools are good enough now.
What to take from this
The tools are good. What separates working results from frustrating ones is discipline: define before building, build in layers, test as you go.
Start with the smallest useful version. Build the MVP. Everything else is version 2. Over-scoping the first version is the most common reason vibe coding projects stall.
Each layer confirmed before the next: skeleton, data, core action, secondary features. Debug precisely, not randomly — describe the problem clearly, show the exact error, ask the AI to explain before it fixes.
The real shift isn't replacing developers. It's letting people who understand problems deeply build solutions themselves.
Want the full framework?
This post covers the vibe coding workflow. The AI Development Guide by Jaehee Song goes deeper — into how to maintain and extend vibe-coded apps, how to wire in databases and authentication, how to move from prototype to production, and how to work with developers when you hit the ceiling of no-code tools.
📱 Apple Books ▶️ Google Play Books 🌐 All Platforms (Books2Read)
Next in the series: "AI Code Assistants — Your New Pair Programming Partner" — how developers and non-developers alike can use AI coding tools to go deeper than vibe coding when the project demands it.