# What is vibe coding?

Vibe coding is building software by describing the result to an AI and accepting the code it writes without reading it, judging it by how the app behaves.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define vibe coding and where the term came from
-   Explain what vibe coding skips compared with engineering
-   Identify checks a vibe-coded app needs before launch

## Related content

-   [What is a coding agent?](https://specstory.com/learning/ai-coding/coding-agent)
-   [What is spec-driven development?](https://specstory.com/learning/ai-coding/spec-driven-development)
-   [What is AI coding session history?](https://specstory.com/learning/ai-coding/ai-coding-session-history)

## What is vibe coding?

Vibe coding is a way of building software in which a person tells an AI what to build and accepts the code without reading it. The person checks the result by using the app, not by reviewing the code or writing tests. When something breaks, the person pastes the error back and asks the AI to fix it.

[Wikipedia's entry](https://en.wikipedia.org/wiki/Vibe_coding) credits the term to the computer scientist Andrej Karpathy, who coined it in February 2025. He said the approach was not too bad for throwaway weekend projects.

People use the term in a narrow sense and a loose one. The narrow sense, which Karpathy described, means that nobody reviews the code. The loose sense covers any programming with AI help. Here it means the narrow sense.

The code usually comes from a chat assistant or from a [coding agent](https://specstory.com/learning/ai-coding/coding-agent) that edits files and runs commands on its own, e.g. Claude Code.

## How does vibe coding work?

Vibe coding runs as a loop of prompts and quick looks at the app:

1.  The person describes a feature in plain language, e.g. "Add a dark mode to the settings page."
2.  A [large language model](https://specstory.com/learning/glossary#llm) (LLM) generates the code, and a coding agent writes it into the project's files, or the person pastes it in.
3.  The person runs the app and looks at the page that changed.
4.  If the page looks right, the person accepts the changes without reading them.
5.  If an error appears, the person pastes the error message into the next prompt, and the loop repeats.

Diagram: The vibe coding loop and what it skips

The loop checks one thing, how the app looks on the path the person tried. The dashed checks sit outside the loop.

Nothing in the loop reads the code, writes a test, or tries another path. The loop needs no programming knowledge, so people who do not write code can build apps with it.

## What is an example of vibe coding?

Here is an illustrative example. Acme Co. sells furniture online. A developer at Acme makes one change to the store by vibe coding:

1.  The developer asks a coding agent to "Let customers edit their delivery address during checkout."
2.  The agent edits 4 files and replies that the feature is "done."
3.  The developer opens a preview at `shop.example.com` as a guest, adds one chair to the cart, and changes the address to "12 Elm Street."
4.  The chair and the changed address appear on the review step, so the developer accepts the changes unread and publishes the store.
5.  A customer who is signed in changes the delivery address with 2 items in the cart. The address saved, but the cart emptied.
6.  The developer pastes the customer's complaint into the agent, and the agent edits the checkout code again.
7.  The developer tries the preview once more while signed in, the cart keeps its items, and the developer publishes again.

The check in step 3 passed because it tried one path, as a guest. Nobody read the line that cleared the cart for customers who are signed in, and nothing checked the rest of checkout after the second edit. This example is simplified. A real store has many more paths that a quick look misses, e.g. a discount code at checkout.

## What does vibe coding skip?

Compared with engineering, vibe coding leaves out the practices that check code before users do:

-   **Reading the change.** Nobody reads what the AI wrote, so no [code review](https://specstory.com/learning/code-review/code-review) takes place. A reviewer could have spotted the line that clears the cart.
-   **Writing down what the software must do.** The request stays a single sentence in a prompt. [Spec-driven development](https://specstory.com/learning/ai-coding/spec-driven-development) writes the expected behavior down first, e.g. "The cart keeps its items when the address changes."
-   **Writing tests that check results.** No test states what must stay true, so nothing fails when the cart empties. An [end-to-end test](https://specstory.com/learning/testing/end-to-end-testing) that signs in and checks the cart after an address change would fail.
-   **Rechecking what worked before.** Each prompt can change code that older features depend on. [Regression testing](https://specstory.com/learning/testing/regression-testing) reruns the old checks after a change.
-   **Trying the paths a demo skips.** Error cases, bad input, and a second user account go untried. [Exploratory testing](https://specstory.com/learning/testing/exploratory-testing) looks for failures on paths that nobody planned.

A coding agent widens what one prompt can change. In one turn, an agent can edit many files, install packages, and run commands. It can also follow instructions hidden in a web page it reads, which is [prompt injection](https://specstory.com/learning/environments/prompt-injection-in-coding-agents), and in vibe coding nobody reads the change that results.

A coding agent's "done" reply is a [completion claim](https://specstory.com/learning/verification/coding-agent-done-claims), not a check. Code that grows through changes nobody reviews can become [AI slop](https://specstory.com/learning/verification/ai-slop), which looks finished but repeats itself and checks little.

## What are the limits of vibe coding?

Vibe coding is not bad in itself. It suits software where a broken path costs little, e.g. a prototype. Its limits show once an app holds real users' data or money.

AI-generated code is often close to correct but wrong in one place. In [Stack Overflow's 2025 survey](https://survey.stackoverflow.co/2025/ai), the most common problem developers reported with AI tools was answers that are almost right but still wrong. Of the developers who answered that question, 66% had run into it. A quick look at the app does not show which part is wrong.

[METR disclosed](https://metr.org/blog/2026-08-31-security-update/) that a researcher's dashboard, which METR calls "the vibe-coded app," had authentication that silently failed open. An attacker used it to extract an API key and ran up about $600,000 in model usage over three weeks. A fail-open check lets requests through when the check itself breaks. To a person who checks by using the app, an app with this bug looks the same as a working one.

The codebase also grows faster than anyone reads it, so [technical debt](https://specstory.com/learning/code-review/technical-debt) builds up and a fix can break a feature that worked before. [Vibe coding bugs](https://specstory.com/learning/verification/vibe-coding-bugs) are usually ordinary gaps, e.g. data that any user who has logged in can read.

## How is vibe coding different from agentic engineering?

[Agentic engineering](https://specstory.com/learning/ai-coding/agentic-engineering) is a way of building software in which people direct coding agents and keep engineering practices, from written requirements to tests and code review. It can use the same agents as vibe coding.

The difference is what the person adds around the agent's work, from a spec written first to a review and tests of the output. One developer can do both, e.g. vibe coding a prototype and then engineering the version that customers use. The comparison of [agentic coding](https://specstory.com/learning/ai-coding/agentic-coding-vs-vibe-coding) and vibe coding covers when to use each.

## How do you get evidence that a vibe-coded app works?

Evidence comes from running the app on more than the path a demo tried. Write down the workflows the app must support, e.g. checkout. After a change, run each one in a running copy of the app, with a second account and with bad input.

Keep each failure as a repeatable test, so the test fails if the bug returns. Read the code that handles user data or money, even if nothing else gets read. The steps to [test AI-generated code](https://specstory.com/learning/verification/ai-generated-code-testing) apply to a vibe-coded app too.

RunStory runs your software in a separate environment, tries relevant workflows, and checks the results. When something breaks, your coding agent receives the actions RunStory took and evidence of the unexpected result. It is in private alpha for CLIs and web apps.

[Join the RunStory alpha →](https://specstory.com/runstory#alpha)

## FAQs

### Is vibe coding the same as using a coding agent?

Vibe coding is not the same as using a coding agent. A coding agent is a tool, and vibe coding is one way of using AI tools, in which a person accepts the code without reading it. Agentic engineering uses the same agents with review and tests.

### Do you need to read the code if the app works?

Reading the code is still needed for the parts that handle user data or money, even when the app works. A check that fails open looks the same as a working one when someone uses the app. For the rest, running the main workflows after each change gives evidence that one demo cannot.

### How do you maintain a vibe-coded codebase?

A vibe-coded codebase stays maintainable when a person reads each change before accepting it and can explain the code that later fixes will touch. Written requirements give each later change something to check against, and repeatable tests keep fixed bugs from returning unnoticed.

### Can a vibe-coded app grow into a real product?

A vibe-coded app can grow into a real product when the team adds the practices that vibe coding skips. Those practices are written requirements, code review, and tests that run again after each change. That shift is the move from vibe coding to agentic engineering.

---

Source: [What is vibe coding? | Vibe coding meaning | SpecStory](https://specstory.com/learning/ai-coding/vibe-coding)
