2026-05-15 · ["vibe coding", "ai development", "cursor", "claude code", "indie hackers"]

What Is Vibe Coding? The 2026 Guide to Building Software by Conversation

Vibe coding is the practice of writing software by talking to an AI rather than typing every line of code. Origins, tools, workflows, who is doing it, and where the limits are.

---

What Is Vibe Coding? The 2026 Guide to Building Software by Conversation

Vibe coding is the practice of building software primarily by describing what you want to an AI model in natural language, rather than typing the code yourself. You stay in the loop as the director and reviewer; the model produces the actual lines, files, refactors, and tests.

The term entered the mainstream in early 2025 after Andrej Karpathy used it on X to describe building small projects with Cursor's agent mode and Claude. The phrase stuck because it captured the shift in posture that existing language ("AI-assisted coding," "pair programming with an LLM") had failed to name. You are no longer typing code with autocomplete help — you are telling a competent collaborator what you want and steering the result.

This article is the explainer we wish existed when founders, indie hackers, and product designers started asking "should I be vibe coding?" — what it is, where it came from, what tools matter, how the workflow actually goes, and what it cannot yet do.

The shortest possible definition

Vibe coding is software development where the human supplies intent and judgment, and the AI supplies syntax, structure, and execution. You describe a feature, the model produces a working implementation, you read it, you run it, you steer the next iteration. The code in your repo is largely AI-generated; the decisions about what should exist are yours.

This is a meaningful distinction from earlier categories:

Mode	Human writes	AI does	Human reviews
Manual coding	Every line	Nothing	Their own work
Autocomplete (Copilot 2021-style)	Most lines	Suggests next token	Inline, instantly
Pair programming with AI	Outline + key parts	Fills in implementation	Each block as it appears
Vibe coding	Almost nothing	Whole files, refactors, tests	After generation, in chunks
Fully autonomous agent	Nothing	Everything including planning	Final output only

Vibe coding sits between pair programming and full autonomy. The human is in the loop on every chunk of work, but the loop is a review loop, not a typing loop.

Where the term came from

Karpathy posted in early February 2025 something like: "There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He described building throwaway projects with Cursor's agent mode, accepting the diff without reading carefully, and steering by feel — fun, lossy, good enough for personal projects.

The framing landed because it named something many engineers had been quietly doing for months and was honest about the tradeoffs. "Forget that the code even exists" is not a serious recommendation for production systems; it is a recognition that for a certain class of work, micromanaging the model costs more than occasionally regenerating the output. The term has since spread to cover a spectrum from "I trust the AI completely" to "I work with AI as my primary interface but I review carefully." Most professional vibe coding sits closer to the careful end.

The tools that made it possible

Vibe coding only works because a small set of tools matured between 2023 and 2026 to the point where the conversation-to-code loop became reliable. The main ones, with honest assessment:

Cursor — A fork of VS Code with deep model integration: chat panel, inline edits, agent mode that proposes multi-file diffs and runs terminal commands. The default IDE for most professional vibe coders in 2026. Strength: seamless file context and diff review. Weakness: expensive at heavy usage; agent mode can drift on large codebases.

Claude Code — Anthropic's official CLI. Runs in terminal, reads your project, executes shell commands, edits files. More agent-shaped than Cursor: less IDE, more teammate via chat. Preferred by engineers who want a clean separation between editor and agent. More cautious and verbose, which professionals appreciate and impatient indie hackers do not.

v0 by Vercel — Web-based UI generator. Describe what you want, get React components using shadcn/ui and Tailwind. Excellent for "I need a settings page that looks decent" and limited beyond that.

Lovable — Web-based platform that builds full apps from a prompt. The smallest gap between idea and running app. Tradeoff: less control and a tendency toward architecturally similar outputs (you can spot a Lovable app from across the room).

Bolt.new — Conceptually similar to Lovable. Leans on Vite, React, TypeScript. Useful for prototypes and demos.

Replit Agent — Replit's evolution from online IDE to agent that builds in an online IDE. Hosting and dev environment included, appealing for non-technical builders.

Aider — CLI that pairs git tightly with an AI coding loop. Each edit becomes a commit. Beloved by terminal-native engineers who want reproducibility and minimum surprise.

Codex CLI — OpenAI's CLI, conceptually similar to Claude Code. Strong on speed and ecosystem breadth, weaker on cautious file handling.

Tool	Best for	Surface	Skill floor
Cursor	Day-to-day professional development	IDE	Medium
Claude Code	Disciplined CLI-based development	Terminal	Medium-high
v0	UI components	Browser	Very low
Lovable	Full apps from idea, fastest possible	Browser	Very low
Bolt.new	Prototypes and demos	Browser	Very low
Replit Agent	Non-technical builders, hosted	Browser	Very low
Aider	Reproducible, git-native	Terminal	High
Codex CLI	Speed-first CLI work	Terminal	Medium

What the workflow actually looks like

Most professional vibe coding sessions follow a recognizable pattern, even though no two engineers describe it identically. The core loop:

1. Frame the task in writing. Not "add login" but "add email-and-password authentication using Supabase Auth, with a /login page that redirects to /dashboard on success and shows an inline error on failure. Reuse the existing Tailwind button styles."
2. Let the model propose. Wait for the diff or the file changes. Do not interrupt mid-stream unless you see something obviously wrong.
3. Read the diff. Every changed line. Yes, every line. The professional version of vibe coding is not "trust the AI"; it is "let the AI do the typing while you do the reading."
4. Run it. Locally if possible, in a sandbox if not. The model's claim that "this should work" is not evidence; the build passing is evidence.
5. Steer the next iteration. "The login redirect goes to /dashboard but the route does not exist yet — create it as a placeholder that just shows 'Welcome'."
6. Commit small. One coherent change per commit, with a real message. This is the single biggest separator between vibe coding that compounds and vibe coding that collapses.
7. Test what matters. Either ask the model to write tests as it goes, or write a thin layer of integration tests yourself for the critical paths.

The loop is fast. A session that would have been 6 hours of manual typing can be 90 minutes of vibe coding for an experienced practitioner. It can also be 14 hours of confused regeneration for someone treating the AI as a magic wand.

Who is actually doing this

The honest answer is: more people than admit it publicly, fewer than the hype suggests. The clearly identifiable groups in 2026:

• Indie hackers and solo SaaS founders. Vibe coding is the dominant mode of building among the "ship a product in a weekend" community. Sites like Indie Hackers, X, and Product Hunt are full of solo operators shipping real revenue-generating apps that were almost entirely AI-generated.
• Designers shipping production code. Possibly the biggest category gain. Designers who could previously prototype in Figma can now ship working web apps because the model handles the syntax. The output quality has surprised even skeptical engineers.
• Prototype builders inside larger companies. Internal hackweeks, throwaway demos for stakeholders, "what if we built X" experiments. Vibe coding is the new default for this work.
• Senior engineers, quietly. Many engineers with 10+ years of experience use vibe coding for the parts of their work they find tedious — boilerplate, glue code, tests, documentation. They tend not to call it vibe coding; they just do it.
• Junior engineers, less successfully. This is where the strongest cautions apply. Vibe coding without enough experience to know when the model is wrong tends to produce code that runs, looks fine, and breaks in ways the author cannot debug.

Where it has not taken over (yet): performance-critical systems, security-sensitive infrastructure, kernel and embedded development, large established codebases with strong conventions, and any domain where the model's training data is thin.

Strengths to be honest about

Vibe coding genuinely changes the economics of building software. Specifically:

• Speed of first version. A working prototype now exists in hours instead of days. This compounds into faster validation cycles and more shots on goal.
• Lower skill floor for entry. People who could not previously ship software can now ship software. This is a structural change in who gets to be a builder.
• Less context switching. You stay in flow. You do not break to read documentation for the third time, or to copy-paste from Stack Overflow, or to fight with a build system.
• Boilerplate erasure. The most boring 30% of every project (CRUD endpoints, form validation, configuration files, type definitions) takes a fraction of the time it used to.
• Better-than-junior code on common patterns. For well-trodden territory (a CRUD API, a Tailwind dashboard, a Next.js app router setup), the model's output is usually higher quality than what an inexperienced engineer would write.

Limits to be equally honest about

The same tools that produce the speed produce the failure modes. Vibe coding cannot yet:

• Reliably refactor a large codebase. The context window is the constraint. Models still struggle when changes touch many files and require deep architectural understanding.
• Handle truly novel problems. If the problem is unique to your domain and not represented in training data, the model is likely to confidently produce wrong code. This is the dangerous mode.
• Substitute for security expertise. The model knows generic security patterns; it does not know your threat model. Authentication, authorization, secret handling, and input validation deserve human attention even in heavily vibe-coded projects.
• Manage a long project on its own. The "agent runs unattended for days" demos look impressive in clips and unravel in reality. Professional vibe coding involves a human in the loop, frequently.
• Write code you cannot read. If you cannot read the output, you cannot debug the output, and the project is on a timer until something breaks badly.

We have a separate article going deep on these failure modes (see the linked piece on vibe coding problems). The short version: vibe coding is a tool, not a replacement for engineering judgment.

Vibe coding vs. traditional development: a practical comparison

Dimension	Traditional development	Vibe coding
Time to first working version	Days to weeks	Hours to days
Cost per feature	Engineer time	Engineer time + API tokens
Code quality on common patterns	Variable, depends on engineer	Usually solid, sometimes brilliant
Code quality on novel problems	Depends on engineer	Higher risk of confident mistakes
Refactoring ability	Strong with experience	Weak on large codebases
Debugging	Direct, you know the code	Indirect, you must read what was written
Onboarding new developers	Months	Days, if vibe coding is allowed
Long-term maintenance	Predictable	Less predictable, especially for messy projects

The honest takeaway is not that one is better. The honest takeaway is that they are different tools and most professional engineers in 2026 use both, deliberately, depending on the task.

Should you be vibe coding?

If you are shipping a prototype, a side project, an internal tool, a UI-heavy application, or a CRUD-heavy product — yes, almost certainly. The productivity gain is too large to ignore.

If you are working on a regulated codebase, a performance-critical system, embedded firmware, or a research-grade algorithm — be cautious. The model is a competent generalist, not a competent specialist.

If you are a founder building a SaaS landing page (or marketing infrastructure around a SaaS), vibe coding will get you 80% of the way there in a few days, and the last 20% is where craft matters most. That last 20% is what we do at Launq — premium SaaS landing pages designed and shipped in 5 to 10 days, async, by humans with serious design taste, not AI generators. We use AI internally for the boring parts and humans for the parts that decide whether your page converts.

---

FAQ

What does "vibe coding" actually mean? Vibe coding means writing software primarily by describing what you want to an AI model in natural language rather than typing the code yourself. You stay in the loop as the reviewer and director; the AI produces the implementation. The term was popularized by Andrej Karpathy in early 2025.

Who invented the term vibe coding? The phrase was popularized by Andrej Karpathy in a February 2025 post on X (formerly Twitter), where he described his experience using Cursor's agent mode to build small projects. The phrase captured a workflow many engineers had already adopted but had not named.

What tools do people use for vibe coding in 2026? The dominant tools are Cursor, Claude Code, v0, Lovable, Bolt.new, Replit Agent, Aider, and Codex CLI. Cursor and Claude Code are the most common in professional use; Lovable and v0 are popular among non-engineers and designers.

How is vibe coding different from using GitHub Copilot? Copilot is autocomplete: you type, it suggests the next token or line. Vibe coding is conversational: you describe the intent of a feature or change, and the AI produces complete files or multi-file diffs. Vibe coding is a higher level of abstraction.

Is vibe coding suitable for production software? For UI, prototypes, internal tools, and CRUD-heavy applications, yes — many production systems in 2026 are heavily vibe-coded. For security-critical, performance-critical, or highly novel problem domains, vibe coding alone is insufficient and must be paired with experienced engineering review.

Can a non-developer learn to vibe code? Yes, the skill floor is lower than traditional development. Tools like Lovable, Bolt.new, and Replit Agent are designed for non-developers. The realistic ceiling for non-developers is "useful internal tools and prototypes," not "production-grade complex systems," but that ceiling is high enough to be transformative.

Does vibe coding replace software engineers? No. It changes what software engineers spend their time on. Less typing, more reviewing, more architectural and product thinking, more domain expertise. Engineers who learn to direct AI well are dramatically more productive; engineers who refuse to engage with the tools are losing ground quickly.

---

---

— Romain at Launq