What Is Vibe Coding and How to Start Building with It

Vibe coding is an iterative, intent-driven workflow where developers steer a code-generating LLM through natural language, testing, and refinement loops. The practice gained its name in February 2025, when Andrej Karpathy described a way to build software by explaining what you want, accepting generated code, and pasting errors back into the conversation.

You may already be working this way without using the label. It's Friday night, your app runs in a browser, and an LLM has written much of the latest feature. You remember the goal, but not every change. The interface looks promising, while the growing diff makes you wonder whether you're developing software or supervising a very fast junior collaborator.

That distinction matters. Vibe coding isn't autocomplete with a chat window. The developer delegates more of the implementation, then takes responsibility for intent, constraints, evaluation, and acceptance. The model writes code, but the human decides whether the resulting behavior is correct, maintainable, secure, and ready to ship.

The workflow has become part of a broader shift in software development. Multiple 2026 summaries report that 84% of developers globally either use or plan to use AI coding tools, while 92% of U.S. developers reportedly use them daily. One synthesis also estimates that 46% of new code globally is AI-generated, compared with about 10% in 2023, and projects the vibe-coding market at $4.7 billion, rising to $12.3 billion by 2027, with roughly 38% compound annual growth. These figures come from a 2026 synthesis of vibe-coding statistics, and they should be treated as adoption signals, not proof that every AI-generated change is good.

Table of Contents

• The Moment Vibe Coding Got a Name
  • From code as text to code as conversation
• A Mental Model for Intent-Driven Development
  • The two mental shifts
• Vibe Coding vs Prompt Engineering, Chaining, and Agents
  • Comparison table
• A First Walkthrough With Express, TypeScript, and Stripe
• A Real Production Example Built With Claude and MCP
  • The review boundary matters
• Tooling Patterns and a Practical Starter Checklist
  • A measured adoption sequence
• Common Pitfalls and Metrics Worth Tracking
• Deciding Whether Vibe Coding Fits Your Team

The Moment Vibe Coding Got a Name

The phrase became useful because it described a recognizable Friday-night experience. You've got a working app in front of you, an LLM has produced the latest screens and routes, and you're moving through the chat by saying things such as “make the empty state clearer” or “fix the error when the user refreshes.” The app improves, but you may not remember writing the most recent lines.

In February 2025, Andrej Karpathy described this emerging style of building software. His description centered on plain-language instructions, model-generated implementation, and an iterative habit of pasting errors back into the chat rather than manually inspecting every line. The moment is documented in Fortune's account of Karpathy and the origins of vibe coding.

The phrase captured a workflow that had been developing alongside large language models. It also gave people a way to distinguish conversational software creation from autocomplete-style assistance. Autocomplete suggests the next fragment. Vibe coding asks the model to handle a larger implementation while the developer judges whether the application behaves as intended.

From code as text to code as conversation

The important shift isn't the catchy wording. It's the location of human advantage.

Traditional development puts much of your attention on syntax, file navigation, implementation details, and line-by-line edits. Vibe coding moves more attention toward decisions. You describe an outcome, specify constraints, run the result, inspect what changed, and decide what the model should do next.

That shift helps explain why the term spread quickly through developer communities and mainstream technology coverage. Builders shared conversationally produced side projects and prototypes, and the label became a convenient shorthand for the workflow.

The label remains fuzzy, though. Recent independent coverage calls vibe coding “loosely defined,” while an empirical study describes programming through conversation with code-generating AI and “material disengagement.” A systematic mapping study also says the concept isn't formally defined. The research paper on vibe coding and its boundaries makes that ambiguity important for teams writing policy or evaluating tools.

A useful working boundary is simple: vibe coding happens when the model operates at the code-artifact level, the developer communicates primarily through intent, and the developer repeatedly evaluates the running result. If you're only accepting a suggested function name, that's closer to autocomplete. If an agent independently plans, schedules, and recovers across tools, you're moving toward agent orchestration.

For a broader view of how this shift connects to agentic work, see why building software now means managing AI systems.

A Mental Model for Intent-Driven Development

A practical way to understand vibe coding is as a four-step loop you could draw on a whiteboard:

1. Input
2. Model
3. Evaluation
4. Output

The first box holds your intent. It may be a natural-language description, screenshot, failing test, Slack message, or unfinished product idea. Useful input adds boundaries, examples, existing behavior, and acceptance criteria. “Build a dashboard” leaves many decisions open. “Add a read-only dashboard using the existing /reports endpoint, preserve the current loading state, and add a test for an empty response” gives the model a target it can check against.

The second box is the code-capable LLM. In a simple setup, it generates or edits text. With repository access, it may read files, run shell commands, inspect test output, or call external tools. It does not understand your goal in the human sense. It predicts an implementation from the context supplied, so repository conventions and explicit constraints shape the result.

The third box is evaluation. Run the code, inspect the diff, read logs, reject weak changes, and refine the next prompt. The research on vibe coding as an iterative workflow identifies accepting or rejecting generated code, testing the application, discovering bugs, and refining prompts as central activities. This loop is the boundary that separates intent-driven development from requesting a code fragment.

The final box is a software artifact that can be checked:

• A diff: The model changes an existing route or component.
• A file: It creates a focused module with a defined responsibility.
• A test: It adds coverage for an observed behavior.
• A refactor: It changes structure while preserving behavior.
• An endpoint: It produces a callable interface that passes verification.

The two mental shifts

Vibe coding differs from autocomplete in two ways. The model proposes whole solutions, rather than only the next token or line, and the developer evaluates outcomes, rather than isolated lines.

Review still includes the implementation. Start with behavior, then examine the code closely enough to find unsafe assumptions, unnecessary dependencies, weak error handling, and changes that could make later work harder. The goal is to shift the first question from “does this line look plausible?” to “does this artifact meet the requested behavior?”

The loop maps cleanly onto ordinary engineering work:

• A product brief is input.
• A repository-aware coding model is the model.
• Tests and a preview are evaluation.
• A pull request is output.

The flowchart-to-code workflow applies the same idea. A diagram or description expresses intent, while the generated implementation remains provisional until the developer checks it against expected behavior.

Practical rule: If you can't describe how you'll verify the generated result, the prompt isn't ready.

Vibe Coding vs Prompt Engineering, Chaining, and Agents

These practices overlap, but they differ along four dimensions:

• Granularity of control: How large is the thing the human directs?
• Human review: When does a person inspect or approve the result?
• Unit of work: What does one request produce?
• State movement: How does context pass between steps?

The table makes the boundary clearer. Prompt engineering improves one request. Prompt chaining connects requests so that each step consumes the previous output. Agent orchestration gives a planner or controller responsibility for choosing tools, scheduling tasks, and handling failures.

Vibe coding can use all three techniques, yet its defining unit is the software artifact under iterative human judgment. The developer is directing a feature, fix, route, component, or related change, then checking whether that change behaves as required.

Comparison table

Practice	Granularity of Control	Where Human Review Happens	Unit of Work	How State Moves
Vibe coding	A feature, fix, component, route, or other code artifact	Throughout the build and before acceptance	A working or nearly working code change	Through conversation, files, diffs, tests, and runtime feedback
Prompt engineering	A single model request	After one response or generation	An answer, code fragment, or instruction	Inside the prompt and model context
Prompt chaining	A sequence of defined transformations	At selected checkpoints or at the end	A pipeline of intermediate outputs	One prompt consumes the previous prompt's output
Agent orchestration	A multi-step objective across tools and tasks	At approval gates, exceptions, or final review	A plan executed through tools and sub-tasks	Shared state, tool results, memory, and recovery logic

Consider the same feature across the four practices. A developer practicing vibe coding might ask an LLM to add a form, run the tests, inspect a failing response, and revise the implementation. A prompt engineer might refine the request that produces the form specification. A chained workflow might generate a schema, pass it to a validation step, and then create test cases. An orchestrated agent might choose which files to inspect, which command to run, and whether another attempt is needed.

The boundaries are practical rather than tribal. A vibe-coding session can use carefully engineered prompts. A chain can produce a code artifact. An agent can participate in the evaluation loop. The label depends on where control and review sit, not on which model or tool writes the code.

The useful question is who controls the next action. In vibe coding, the developer remains the editor and judge, even when the model performs most of the typing. Agent orchestration shifts more scheduling and recovery to the system. Prompt engineering stays focused on improving a request.

Teams can evaluate the distinction by tracking review checkpoints, accepted artifacts, failed verification runs, and the amount of rework after generation. For a practical comparison with agent workflows, see how to build an AI agent.

A First Walkthrough With Express, TypeScript, and Stripe

A good first exercise has a narrow contract. Don't ask an AI tool to “build a payments app.” Ask it to add one Stripe Checkout endpoint to an existing Express and TypeScript project, then verify the behavior yourself.

Start with a health check. Confirm that the project installs, the current tests run, the type checker works, and the development server starts. Ask the model to inspect the repository before changing anything:

“Inspect this Express and TypeScript project. First summarize the existing route structure, package scripts, environment-variable conventions, test setup, and relevant payment code. Do not modify files yet. Then propose the smallest change needed for a Stripe Checkout endpoint.”

Next, require contracts before implementation:

“Define the request shape, required environment variables, success response, validation failures, and provider errors. Use Stripe test mode. Don't invent secrets, endpoints, or project conventions. After I approve the plan, make isolated changes and add focused tests.”

The practical loop should stay short. A published vibe-coding tutorial with an Express and TypeScript workflow demonstrates the pattern of generating a minimal app, running npm install and npm run dev, inspecting a failing route, prompting a fix that reads a Stripe key from process.env, adding graceful error handling, and repeating focused fixes until CI passes locally.

For your version, refine one concern at a time:

• “Place the route beside the existing checkout routes and preserve their response conventions.”
• “Validate required fields before calling Stripe.”
• “Explain how duplicate submissions are handled and add idempotency if the current design supports it.”
• “Return safe client-facing errors without exposing provider details.”
• “Add tests for invalid input, missing configuration, provider failure, and a successful test-mode response.”

Run the project's actual checks, including npm test, npm run typecheck, and the local endpoint. Inspect the diff, generated dependencies, logs, and test-mode behavior. Then ask for a second review:

“Review the current diff as a security-focused maintainer. Identify missing validation, unsafe logging, secret exposure, duplicate-payment risks, untested branches, and unnecessary dependencies. Don't change code yet. List each issue with a proposed test.”

The model can suggest a plausible implementation. Your job is to prove that requests validate, duplicate submissions behave safely, secrets stay out of source, and successful test-mode payments return the expected status.

Only after those checks should you ask for a commit summary:

“Summarize only the changes verified by tests and local endpoint checks. List commands that passed and any known limitations. Don't claim production readiness.”

The developer remains the final reviewer. That boundary is the difference between using generated code and outsourcing accountability.

A Real Production Example Built With Claude and MCP

A practical example comes from a real-estate broker who used Claude plus Zapier MCP to create an AI agent named Russ for daily brokerage operations. The example is useful because it involves a named operational system rather than a toy interface. It also shows how vibe coding can move from generating screens to shaping a business process.

The broker described the business goal, gave Claude access to connected services through MCP, reviewed proposed actions, and refined the workflow when real tasks exposed missing steps or permissions. Zapier connected operational systems, while MCP provided a structured way to expose tools and data to the model. The reported Russ workflow presents it as an operational example, not merely a generated demo.

The review boundary matters

An operations agent can draft records, coordinate information, and perform multi-step work, but consequential actions still need governance. A team should decide which actions require approval, which credentials the agent can access, what gets logged, and how an exception reaches a human.

That means the valuable output isn't just code. It's a chain:

1. A human states the business intent.
2. Claude interprets the task.
3. MCP exposes approved tools and data.
4. Zapier connects operational services.
5. The agent proposes or performs bounded actions.
6. A human reviews sensitive outcomes.
7. Logs and exceptions feed the next refinement.

Vibe coding meets agent design. The model may generate implementation details, but the team defines permissions, failure handling, and acceptance criteria. A useful guide to building an MCP server can help clarify what an integration exposes and what it should keep private.

Russ demonstrates a broader lesson: the artifact under development may be a governed workflow, not only a web page or source file. The same evaluation discipline still applies. State the goal, expose narrow capabilities, test real tasks, inspect failures, and keep people accountable for consequential decisions.

Tooling Patterns and a Practical Starter Checklist

Choose tools by role, not by fashion. A coding GPT can explain unfamiliar code, draft an edit, create tests, or suggest a refactor. A repository copilot can work against project context and produce changes inside an established workflow. An AI agent can plan and execute a bounded sequence, such as inspecting a route, modifying a file, running tests, and reporting the result.

Orchestration frameworks coordinate more complicated work. LangGraph, CrewAI, and Semantic Kernel can help manage state, tools, retries, and approval points. Temporal is another option when durable workflow execution and recovery matter. MCP servers expose tools and resources through a common interface, while Zapier-style integrations and custom servers can connect systems such as Stripe, databases, and internal services.

The surrounding delivery controls remain essential:

• Version control: Use Git so every generated change can be reviewed or reverted.
• Continuous integration: Run formatting, type checks, tests, and security checks automatically.
• Secret management: Keep credentials outside prompts, source files, and generated logs.
• Sandboxes: Let unfamiliar agents work in disposable environments first.
• Observability: Record tool calls, failures, approvals, and important state transitions.

A measured adoption sequence

1. Choose one low-risk repetitive task. Pick a small internal feature, test addition, documentation update, or read-only workflow.
2. Define its contract. Write inputs, outputs, exclusions, failure behavior, and acceptance tests before selecting the model.
3. Give the system minimal access. Start with one model, read-only repository context, and narrow tools.
4. Use a disposable environment. Require a branch, sandbox, or temporary workspace.
5. Keep human approval mandatory. Don't allow generated code or agent actions to reach sensitive systems without review.
6. Measure quality and cycle time. Track review effort, test coverage, iterations, and failures instead of relying on enthusiasm.
7. Expand permissions cautiously. Add write access or additional tools only after the workflow produces stable, inspectable results.

The AI agent stack guide from Flaex.ai provides a starting point for comparing GPTs, agents, MCP servers, and orchestration choices. Your final checklist should ask: Can we roll this back? Can we audit what happened? What data enters the model? Who approves sensitive actions? Who remains accountable when the generated code or agent action fails?

Common Pitfalls and Metrics Worth Tracking

Vibe coding doesn't remove engineering rigor. It moves rigor toward specification, verification, review, and governance. Teams get into trouble when a convincing prototype creates the illusion that the implementation has earned production trust.

Generated code can introduce silent regressions, repeat a mistaken assumption from an earlier prompt, or add dependencies without a clear reason. A developer may also skip review because the feature appears to work in one happy-path demonstration.

Common failure modes include:

• Unread generated code: The team ships a change nobody can explain or maintain.
• Missing tests: LLM-written paths work in the demo but fail on empty input, retries, permissions, or provider errors.
• Secret leakage: A developer pastes credentials, private data, or sensitive logs into a model session.
• Dependency sprawl: An autonomous tool installs packages that duplicate existing capabilities or expand the attack surface.
• Prompt drift: The goal changes during several iterations, but the acceptance criteria never get rewritten.
• Governance gaps: An agent can call tools or alter systems without a clear approval boundary.

Track metrics that reveal whether the workflow is helping rather than turning them into a simplistic productivity scoreboard.

Pitfall	What Goes Wrong	Metric to Track	Target Signal
Unread generated code	Reviewers spend excessive time reconstructing intent	Code-review turnaround time for AI-generated diffs	Reviews remain timely and produce actionable findings
Missing tests	Important generated paths lack behavioral coverage	Percentage of generated code covered by tests	Coverage grows with the risk of the change
Prompt drift	The implementation solves a moving target	Mean iterations to green build	Iterations stabilize after better contracts are introduced
Hallucinated APIs	The model calls interfaces that don't exist or don't match	Hallucinated API rate from static analysis	Invalid references become uncommon and visible before merge
Slow setup	A new feature takes too long to reach a reviewable state	Time-to-first-commit for new features	Developers reach a meaningful, reviewable change sooner
Governance blind spots	People lose confidence in generated changes	Developer-reported trust score	Trust reflects verified behavior, not novelty

A useful metric is not automatically a good target. A team can reduce time-to-first-commit by creating more cleanup work later. Pair each speed signal with a quality signal, then review the relationship between them.

The right question isn't “How much code did AI write?” It's “How much verified software did the team accept, and what did review cost?”

Deciding Whether Vibe Coding Fits Your Team

Before adopting vibe coding, ask three questions that reveal whether your workflow can support it.

1. Can someone write precise acceptance criteria before opening the model?
2. Can the team inspect and test every meaningful artifact?
3. Can the project absorb a wrong implementation without creating disproportionate risk?

Start with a bounded pilot: pair one developer with one project for two weeks. Instrument review time, test coverage, iteration count, API validation, delivery, and trust using the metrics described earlier. Review the diffs together. Expand only when evidence shows the team is accepting reliable changes, rather than producing more drafts.

Greenfield prototypes, internal tools, interface experiments, and glue code offer safer starting points. Their boundaries can stay narrow, and incorrect changes are usually easier to reverse. Regulated systems, safety-critical software, and hard-realtime behavior require stricter review, testing, traceability, and approval. AI assistance may still help, but generated implementation should remain inside those controls.

Vibe coding is a workflow category, not a substitute for engineering judgment. The model generates quickly; the team remains responsible for deciding what to merge, deploy, and support.

Flaex.ai helps teams discover and compare GPTs, AI agents, MCP servers, and related tools, including prompt-based app development options such as VibeCode. Visit Flaex.ai to evaluate tools for a bounded pilot and assemble a stack with clearer implementation and governance choices.