What Is Vibe Coding? A Practical 2026 Guide for Indie Founders (Tools, Workflow & Risks)

What is vibe coding? Vibe coding is building software by describing what you want to an AI model, running what it produces, and asking for changes, without reading the code it writes. You judge the result by whether the app works, not by how the code looks. It’s the fastest way I know to turn an idea into something clickable, and it’s also the fastest way to ship an app with an open database to the internet.

This guide covers where the term came from, what it means in 2026 (it has drifted), which vibe coding tools fit which kind of founder, a workflow you can copy today, and the exact point where you should stop vibing and start checking.

What is vibe coding? The short definition

Andrej Karpathy coined the term in a post on X in February 2025. His description: you “fully give in to the vibes” and “forget that the code even exists.” He accepted every change without reading the diffs, pasted error messages back to the model with no comment, and worked around bugs the model couldn’t fix. He also said it was fine for throwaway weekend projects. That last part tends to get dropped.

So the original meaning has three parts:

1. You prompt instead of type. The AI writes the code.
2. You don’t read the code. You look at the running app.
3. You loop on symptoms. Something breaks, you paste the error, the AI tries again.

Martin Fowler’s definition (May 2026) is close to this: building an app by prompting, trying it, prompting for changes, without looking at the generated code. He adds the warning that the result often has maintainability, correctness and security problems, so it’s best for disposable software with a small audience.

If you’re a semi-technical founder, here’s the version I find most useful: vibe coding is AI-built software where nobody has checked how it works, only that it seems to work.

How the meaning drifted in 2026

Go read any r/AskProgramming thread asking “how do you define vibe coding?” and you’ll get a dozen answers. Roughly three camps show up:

• Strict: it only counts if you never read the code. Asking an AI questions or reviewing its diffs is just AI-assisted coding.
• Loose: any code an LLM generated that you merged is vibe coding, no matter how senior you are.
• Process-based: vibe coding is letting the AI make design decisions with no spec, no constraints and no tests. A staff engineer who hands the agent a proper spec and reviews the result is doing something else.

The process-based camp is closest to how the industry now talks about it. In February 2026, a year after the original post, Karpathy said that for professionals, coding through LLM agents was becoming the default, with more oversight and scrutiny, and that his favorite name for that was agentic engineering. Fowler draws the same line: if you care about the code, review it and pay attention to its structure, you’re not forgetting it exists, so it isn’t vibe coding.

Vibe coding vs agentic engineering

	Vibe coding	Agentic engineering
Who writes the code	The AI	The AI (mostly)
Do you read diffs?	No	Yes, or you have checks that do
Spec before building	Optional, usually a one-line idea	A written brief or plan the agent follows
How you know it works	Clicking around	Tests, type checks, a second-account test, logs
Good for	Prototypes, internal tools, demos, learning	Anything with users, payments or personal data
Main risk	Hidden security holes, unmaintainable code	Slower, needs some literacy

You don’t have to pick one forever. Most indie products I see start as vibe code and need to graduate before real users show up. The rest of this guide is about doing that on purpose.

Is vibe coding good or bad?

Both camps in the forums are right about something.

The enthusiasts are right that the speed is real. One of the most-upvoted Reddit threads about AI coding in early October 2026 was a developer saying their small team built in two months what used to take a year, and the replies were split between “development as I knew it is dead” and “this frees me to think about the product.” Nobody in that thread argued the tools were slow.

The critics are right that speed without review produces fragile apps. A recurring r/SideProject and r/nocode theme in September 2026 was founders asking how to tell whether their Lovable or Bolt app is actually secure. The answers kept coming back to the same failures: database row-level security that isn’t on, a secret key shipped to the browser, and one user being able to read another user’s data. One r/SideProject poster summarized third-party scan reports as finding at least one vulnerability in the large majority of vibe-coded apps tested. I haven’t verified that figure, so treat it as a forum claim, but the failure list matches what I covered in the vibe-coded app security checklist.

The most honest take I found was an r/indiehackers founder with a small paying health app, built with almost no coding background. Their lesson, paraphrased: AI gets you to “demo ready,” not “production ready.” Stripe looked fine until real payments failed on webhook handling, and queries were fine until a few hundred users showed up. What fixed it wasn’t a better model. It was logging the critical flows, testing with real cards, and learning just enough fundamentals (indexes, webhooks, sessions vs tokens) to know what to ask.

My opinion: vibe coding is a great way to find out whether an idea is worth building properly. It’s a bad way to run something people pay for.

Vibe coding tools in 2026: pick your lane

The tools split into two groups. App builders generate a whole app from chat in the browser. Coding agents work inside a real project folder on your machine and assume you’ll at least skim what they do.

Tool	Type	Best for	Entry price (checked Oct 22, 2026)
Lovable	Browser app builder	Non-coders who want a polished UI fast	Free: 5 build credits a day (up to 30/month); paid plans are credit-based
Bolt.new	Browser app builder	Fast prototypes, peeking at the code	Free: 1M tokens/month (300K/day); Pro from $18/month billed annually
Replit	Browser IDE + agent + hosting	Full-stack apps with a built-in database	Core $20/month ($18 annual), Pro $100/month ($90 annual)
Claude Code	Coding agent (terminal, desktop app, IDE)	Multi-file work on a real codebase	Claude Pro $20/month; see Claude Code pricing
Cursor	AI code editor	People who want to stay in an editor	Free tier plus paid plans; details in Claude Code vs Codex vs Cursor
OpenCode, Cline, Aider	Open-source coding agents	Tight budgets, bring your own model	Free tools; you pay for the model

Prices change often, so check each pricing page before you pay. A few honest notes on these:

• Credits and tokens are the hidden cost. Lovable’s own pricing page says credits per message vary with task complexity. Bolt’s FAQ says most token usage comes from syncing your project files to the AI, so bigger projects cost more per message. A free plan that feels generous on day one gets tight on day ten.
• Code ownership matters. Lovable states that you own the code you build there. Whatever you pick, connect GitHub early so the code lives somewhere you control.
• Graduating is normal. A common path is: prototype in Lovable or Bolt, export to GitHub, then keep building with Claude Code or Cursor once the app has real logic. If you’ve never touched a terminal, my Claude Code for non-developers guide walks through that move. If $20 a month is too much right now, see the free Claude Code alternatives.

A vibe coding workflow you can copy

This is the workflow I’d hand a semi-technical founder. It keeps the speed of vibe coding for the first version and adds guardrails before anything goes public.

Step 1: Write a one-page brief first

The single biggest difference between a vibe-coded mess and a clean prototype is whether the AI knew what it was building. Paste this into the tool before asking for any code:

I'm building [app name]: [one sentence on what it does] for [who].

Must have for v1 (nothing else):
1. [feature]
2. [feature]
3. [feature]

Not in v1: [things you are tempted to add]

Stack: Next.js + Supabase + Stripe (or: keep whatever you pick boring and popular).
Users log in with email. Each user can only ever see their own data.

Before writing code, reply with:
- the pages and database tables you plan to create
- anything in my brief that is unclear
Then wait for my OK.

That last instruction does most of the work. It turns “build me an app” into a plan you can sanity-check in two minutes. In Claude Code, Plan mode does the same thing.

Step 2: Give the agent standing rules

Coding agents read a project instructions file on every session. A short one stops the most common vibe-coding damage. Put this in CLAUDE.md (Claude Code) or AGENTS.md (Codex, Cursor and others):

# Working agreement
- I'm not a professional developer. Explain each change in one or two plain sentences.
- Work in small steps. After each step, tell me exactly how to test it in the browser.
- Never put secret keys in frontend code. Secrets go in .env, and .env stays out of git.
- Every database table with user data needs row-level security that limits rows to their owner.
- Don't add new libraries without asking me first.
- If a fix fails twice, stop and explain the problem instead of trying random changes.

That last rule fights the “ask for random changes until it goes away” loop from Karpathy’s original description, which is fine for a weekend toy and terrible for anything you’ll maintain. For a fuller template see my CLAUDE.md template for indie SaaS projects.

Step 3: Build in small, testable slices

Ask for one feature at a time, test it yourself, then commit. A good rhythm:

Build only feature 1 from the brief. When done:
1. List the files you changed.
2. Tell me the exact steps to test it.
3. Don't start feature 2.

After each slice works, ask the agent to commit with a clear message. If the next slice goes sideways, you can roll back to a version that worked instead of untangling a pile of half-fixes.

Step 4: When something breaks, give context, not just the error

Pasting a raw error is pure vibe coding, and it often works. When it doesn’t work twice in a row, switch to this:

This is still broken. Don't change code yet.
1. Explain in plain English what you think is happening.
2. Add logging so we can see the actual values at each step.
3. Tell me what to click, then I'll paste the log output back to you.

Logs turn guessing into debugging. It’s the habit the r/indiehackers founder above said made the biggest difference.

Step 5: Run a pre-launch check before real users

This is where you stop vibing. Before you share the link publicly, ask the agent for an audit and then verify the big items yourself:

Do a pre-launch review of this project. Report problems only, don't fix yet:
- Any secret or service-role key reachable from the browser?
- Does every table with user data have row-level security enabled, with owner-only policies?
- Can a logged-in user read or change another user's data through any API route?
- Are payment webhooks verified with the signing secret?
- Any admin page or API route without an auth check?
Give me a table: problem, file, severity, suggested fix.

Then do the one test no AI can fake for you: make two accounts, log in as the second one, and try to open the first one’s data by changing IDs in the URL. My security checklist has all 12 checks with copy-paste prompts.

If you use Claude Code, you can turn the “never edit .env” rule from a polite request into a hard block with a hook. See these Claude Code hooks examples.

When vibe coding breaks (and what to do instead)

From the threads I read, these are the points where pure vibe coding stops paying off:

Symptom	What’s really going on	What to do
Every fix breaks something else	The code has outgrown what the AI can hold in context at once	Ask for a short architecture summary, then refactor one area at a time with tests
Works on your laptop, fails after deploy	Env variables, auth redirect URLs or a localhost leftover	Check hosting env vars and auth redirect settings, then redeploy
Payments “work” but some customers aren’t upgraded	Webhooks not handled or not verified	Log every webhook event; test with real cards in test mode
App slows to a crawl with a few hundred users	Loading whole tables, no indexes	Ask the agent to find unbounded queries and add pagination and indexes
Monthly AI bill or credits vanish	Huge context re-sent every message	Trim instruction files and start fresh sessions; see how to reduce Claude Code token usage

None of these mean you need to become a senior engineer. They mean you need to read a bit of what the AI wrote in the parts where mistakes cost money or data: auth, payments and database access.

Can you make money with a vibe-coded app?

Yes, and the forums have plenty of examples of people with little coding background getting paying users. The pattern across the honest posts is consistent, though:

• Building was rarely the hard part. A designer on r/vibecoding who built a product mostly with Claude and Codex said figuring out what people would pay for and getting it in front of them mattered more than the code.
• The ones selling to other builders often didn’t vibe code the core. One founder selling a security scanner for vibe-coded apps said they hand-built the security logic and used AI for the frontend and boilerplate. That’s the agentic engineering split in practice.
• AI tool costs stay small next to revenue once you’re on flat plans, which is why I track the whole stack in the real monthly cost of an AI indie dev stack.

Vibe code the prototype, validate with real people, then harden the parts that touch money and data before you scale.

FAQ

Who coined the term vibe coding?

Andrej Karpathy, in a post on X in February 2025. He described accepting all AI changes without reading the diffs and said it was fine for throwaway weekend projects.

Is vibe coding the same as using AI to code?

Not in the strict sense. Using AI while you review and test its output is usually called AI-assisted coding or agentic engineering. Vibe coding specifically means not looking at the code. In everyday use the terms blur, so ask people what they mean.

Do I need to know how to code to vibe code?

No, which is the appeal. You do need to learn a few concepts before launching anything with users: environment variables, row-level security, webhooks, and how to read a log. You can learn those as you go by asking the agent to explain each one.

What are the best vibe coding tools for beginners?

Browser app builders like Lovable, Bolt.new or Replit are the easiest start because there’s nothing to install. Once your app has real logic, a coding agent like Claude Code or Cursor working on a GitHub repo gives you more control. The table above lists the trade-offs.

Is vibe-coded code safe to put in production?

Not by default. Treat it like code from a fast junior developer you’ve never met: assume something is missing until you’ve checked secrets, database access rules, auth on every route and payment webhooks. Then it can be as safe as anything else.